共计 4677 个字符，预计需要花费 12 分钟才能阅读完成。
作者 | 郑德来
导读 ：本文次要介绍如何基于流批一体的技术架构构建实时数仓，在严格的资源老本限度下，满足业务对于数据时效性、准确性的需要。文章整体蕴含 4 个局部，首先会介绍下大数据架构演进，从经典架构到 Lambda 架构再到 Kappa 架构；而后会介绍下咱们做流批一体实时数仓的背景，旧架构面临的次要问题；第三会介绍下咱们流批一体实时数仓的技术计划，关键问题的冲破；最初一部分是总结和布局，咱们的技术计划达成了什么样的业务成果。
全文 4735 字，预计浏览工夫 12 分钟。
一、大数据架构演进
1. 经典离线数仓架构介绍
经典的离线数据仓库次要分为 4 层：
1）操作数据层（Operational Data Store），存储根底数据，做简略数据荡涤。
2）明细数据层（Data Warehouse Detail），构建最细粒度的明细层事实表。
3）汇总数据层（Data Warehouse Summary），依照主题，对明细数据进行汇总。
4）利用数据层（Application Data Store），寄存业务个性化统计指标，面向最终展现。
经典的离线数仓的优缺点非常清晰，长处是架构简略，开发成本低，资源成本低，数据易治理，数据差异小；毛病是数据时效性差、短少实时数据。
2.Lambda 架构介绍
lambda 架构是由 Storm 作者 Nathan Marz 于 2011 年提出的实时数仓架构，初衷也是补救经典数仓架构时效性差的问题。整个架构会分三层：
1）Batch Layer：批处理层，这一层其实根本是复用了经典数仓分层架构，数据也是基于 ods、dwd、dws、ads 的构造进行组织，也就保留了经典数仓数据精确、全面的特点。应用技术栈也是跟经典数仓统一，次要以 mr、hive、spark 等离线计算框架为主。
2）Speed Layer：减速解决层，这一层的重点在于产出高时效性的数据，对于数据的准确性和完整性可能会有一些降级，个别会采纳 kafka 等消息中间件进行数据传输和存储，采纳一些像 Storm、Spark streaming、Flink 等流式计算框架进行数据计算。
3）Serving Layer：服务层，这一层会将 speed layer 和 batch layer 层的数据进行合并和替换，输入到一些数据库或者 olap 引擎中，撑持下层的数据利用。
相比于经典数仓，Lambda 架构因为引入了 speed layer，可能把数据的时效性大大提前，因为同时具备 speed layer 和 batch layer，使得 Lambda 架构可能同时兼顾数据准确性和数据的时效性，另外 batch layer 根本兼容了经典数据架构，所以在从经典数仓架构迁徙 Lambda 架构的时候，能够省去一部分惨重的历史包袱，至于毛病嘛，也是因为 Lambda 架构同时具备 speed layer 和 batch layer，那就会导致这么几个问题：
1）一个需要会有两套代码，同时开发两遍，也就会造成开发成本的节约。
2）资源须要两份，一份离线的资源，一份流式的资源，整体资源占用比拟多。
3）数据差别问题，离线和实时的数据总是有差别，对不齐，体验比拟差。
3.Kappa 架构介绍
随着流式计算框架的一直倒退，尤其是针对不重不丢语义的反对越来越好，Confluent 公司 CEO Jay Kreps 于 2014 年提出了 kappa 架构。Kappa 架构的核心思想是去掉 Lambda 架构的 batch layer，实时计算和离线计算应用同一套代码。通过一套架构来同时满足业务对于准确性、全面性、时效性的要求。
首先，kappa 架构必定是解决了 Lambda 架构的几个毛病，因为实时离线应用一套代码，整个开发成本大大的升高，资源的老本也有了肯定的节俭，同时最要害的是实时和离线的统计做到了对立，打消了各类在离线数据 diff 问题。那当然，kappa 架构也不是完满的，它也有一些毛病：
1）数据回溯的问题，业务口径的变更会带来数据回溯，kappa 架构没有离线数据流，回溯的老本是很高的。
2）随着业务的复杂度减少，数据源的复杂度也减少，流式计算环节会面临各种简单关联场景的挑战，开发和保护的老本十分高。
一些新业务，数仓能够从 0 开始建，Lambda 架构的落地老本还是能够承受的。然而大多数状况下，咱们的数仓建设都有惨重的历史包袱，好多存量逻辑面临实时化的革新，而这些革新往往是老本高，收益小。
二、背景
首先介绍一下旧的架构，依据后面讲的大数据架构演进，能够看进去旧的架构是一个 Lambda 架构。旧的架构也是基于经典数仓架构演变而来，新增了实时流局部，满足业务的高时效性诉求。深蓝的局部是离线流，浅蓝局部是实时流：
1）离线流
最底层是数据源，次要有两类，一类来源于日志打点，比方一些展示日志、点击日志，一类来源于业务的数据库，比方一些订单数据、物料数据。日志打点的数据通过日志采集工具小时或天级采集到文件系统上，业务数据库的数据通过 dump 工具天级别采集到文件系统上，再通过离线的数据荡涤，构建数据仓库。数据仓库也是经典的分层数仓，数仓下层次要是承接多维分析和报表需要。
2）实时流
日志打点这块通过实时的数据采集，将有时效性要求的数据写入到音讯队列，业务数据库的数据也通过采集 binlog 等变更流信息，将有时效性要求的数据写入到音讯队列，音讯队列之后就是流式计算环节，这个环节会依照需要，别离进行数据加工，满足策略信号、实时报表、实时利用的诉求。
旧架构在理论的应用过程中，也遇到了一系列的问题：
1）因为业务比较复杂，采纳分层建模，数据表量级在千张级别，表关联场景多，一次查问可能须要关联几十张表，查问时效慢，均匀时效在几十分钟级别。
2）数据提早重大，大部分数据都是天级产出，个别小时级的数据产出也要提早几个小时。
3）实时和离线数据存在差别，不能对齐，每次须要开发两套代码，保护老本高。
三、技术计划
1. 整体架构
咱们的流批一体实时数仓整体架构，整体上是一种 Lambda 和 kappa 的混合架构：
1）最要害的变动其实是数据荡涤和数据仓库环节，每个字段会依据应用场景的时效性要求，来确定数据流是走实时还是离线。一个字段要么走实时，要么走离线，实时和离线不再是补充关系而是替换关系。这样也就防止了 Lambda 架构典型问题，实时离线两套代码、在离线数据不统一。同时没有时效性诉求的字段还是持续保留离线的解决逻辑，没必要强行切换到实时，减少资源老本和开发保护老本。
2）整个数据仓库也由之前的分层建模变成了宽表建模，实时字段和离线字段通过分钟级的 merge 合并成一张宽表。整体的建模思路也不再面向数据源建模，而是面向应用建模，保障业务方在应用的时候表尽量少，缩小表的关联，升高查问耗时。
2. 关键问题冲破
1）数据更新问题
针对实时数仓，其实比较简单的是纯日志场景，一个典型的日志场景的实时数仓计划大略是这样的，原始的日志通过实时采集写入到音讯队列中，再在流式计算环节，通过固定的工夫窗口写入到文件中就好了，日志数据其实是不会变动的，日志打印那一刻数据就固定了，然而数据库数据是不一样的，他是会更新的，像比如说订单的状态，物料的属性，都可能会发生变化，然而分布式的文件系统往往是不反对更新的，那随着计算窗口的变大，吞吐能力和可维护性都变差。
咱们的解决方案大略是这样的，对于数据库数据，咱们首先采集变更信息 binlog，写入到音讯队列中，而后采纳 CopyOnWrite 机制，通过滚动 5 分钟合并过程，将 base 文件和 delta 文件进行合并，一直产生最新的可用版本。没有采纳 MergeOnRead 计划，要害起因还是满足业务的诉求，业务对查问的时效性特地敏感，必须是秒级别，而对数据导入的时效性没有特地敏感，分钟级是能够满足需要的。
2）多表关联问题
离线场景典型的数据关联计划大略是这样的，有一张 db 主表，几张关联表，通过 spark 或者其余的离线计算框架关联到一起，再写入到文件系统中，供查问引擎进行查问。每一个表的数据量可能都很大，就会触发 shuffle join，关联性能十分差。
来看一下咱们的解决方案，这个计划能够简略形容为三次关联：
每一张表都可能依据问题一的解决方案产生 base 文件和 delta 文件，base 文件就蕴含了主表或者关联表的截止到某一个时刻的全副记录，那 delta 文件就蕴含了主表或者关联表在某个工夫窗口内的变更记录。因为通常这种状况下，数据库的数据只是存量的记录比拟多，然而增量的更新绝对较少。所以每一个表的 delta 文件都是绝对较小的，那这三次关联都是存在小数据集的，尽管关联了屡次，但整体的时效还是满足预期的。
3）数据库和日志关联问题
对于数据库和日志关联的问题，典型的解决方案大略是这样的，将数据库数据全量写入一个高性能缓存中，将日志数据在流式计算环节进行解决，而后通过查问高性能缓存的形式将数据库相干字段进行拼接，最终再通过固定的窗口写入到文件系统中，供查问引擎查问。那这个计划次要有这样的问题，存量的数据库记录十分多，这就要求缓存要有很大的容量，再一个是日志的吞吐特地高，这就会导致拼接的过程须要频繁查问缓存，也就是说，对缓存的读 qps 和容量都有比拟高的要求，这就导致缓存的资源老本十分高。
对于日志数据，通过日志采集写入到音讯队列中，在流式计算环节通过固定的窗口产生 delta 文件，对于数据库数据，采纳多表关联解决方案，可能滚动的产出可查问的版本，有变动的是采取了一个冷热数据拆散的计划，日志的 delta 文件分钟级滚动合并的时候，只合并热数据，对于冷的数据进行天级别的合并。这个实现的降级其实也次要是以最低的老本，来满足业务最外围的诉求，业务最次要的诉求就是热数据可能疾速查到，数据精确统一。这个计划整体上也是参考了一些 Lambda 架构的思维，尽管有冷热数据两次不同的合并，然而合并的逻辑是统一的不须要写两份代码，只不过资源层面会新增一份全量数据的关联，然而从整体看，既满足了需要，资源又没有减少太多。
4）数据水位问题
后面也说了，咱们的建模从之前的分层建模改成了宽表建模，而宽表建模有个最大的问题就是数据到位工夫问题，那通常状况下所有的依赖表数据都产出之后，宽表能力产出。
理论状况下，咱们的数据源往往是简单的，比方有一部分表能实时产出，分钟级提早，但有些表因为一些非凡的逻辑只能 T +1，甚至 T + 2 产出。
总体的计划就是数据按版本产出，字段按需实时化, 原始的日志、数据库数据，通过后面讲的三个解决方案，可能保障实时的字段分钟级产出可查问版本, 对于一些时效性不敏感的字段可能是 T + 1 产出, 对于一些简单计算或者第三方回传的字段可能是 T + 2 产出，然而整体的展示模式是一张宽表, 同时在业务应用宽表的时候展现字段可用状态。
四、总结和布局
流批一体的实时数仓架构，大幅度降低了数据的导入提早和数据查问的耗时。
数据的导入提早从之前的小时级别、天级别优化到分钟级别，数据查问的耗时从之前的分钟级别优化到秒级别，极大的晋升了业务对于数据的时效性体验。另外实时离线逻辑对立，不再须要同时开发两套代码解决雷同的逻辑，升高了开发和保护老本，也打消了长期困扰业务的在离线数据差别问题。
咱们的后续布局有引擎查问性能继续晋升，下层查问工具体验优化等方向，也欢送业界感兴趣的同行们一起探讨。
———- END ———-
举荐浏览【技术加油站】系列：
ffplay 视频播放原理剖析
百度工程师眼中的云原生可观测性追踪技术
应用百度开发者工具 4.0 搭建专属的小程序 IDE
百度工程师教你玩转设计模式（观察者模式）
揭秘百度智能测试在测试主动执行畛域实际
H.265 编码原理入门
