核桃编程Delta Lake实时数仓应用实践

1.3 架构改造前方案

现有指标都是将Kafka/Mysql等的数据写入HDFS，使用Hive离线批处理，每10分钟执行一次，循环统计历史累计指标，再定时把数据同步到Mysql，提供给数据后台查询。如下图所示:

image

1.4 遇到的问题

随着计算的数据量越来越大，逐渐不能满足业务的更新频率要求。

使用Apache Sqoop做全量数据同步，会对业务Mysql库/HDFS造成压力。
使用Apache Sqoop做增量同步，一般只能使用某个时间字段(例如update time)来同步新修改的数据。这样在做分区表时，需要比较复杂的离线合并。
随着数据越来越大，同步以及处理时间会越来越长，满足不了业务实时性需求。

3.3 实时数仓方案

架构方案

基于Delta Lake+SparkStreaming SQL可以快速构建实时数仓的pipeline，如下所示：

image

ODS层
ODS的数据主要是实时埋点数据，CDC中的binlog日志等
DIM维表
DW层
DW层主要是一部分轻度汇总数据，例如用户维度的课程，作业等信息。

主要复用的是DW层数据，因此针对每一个指标，需要综合考虑是否聚合，聚合到哪一个维度，是否关联维表。

DW层分为两种

a.业务简单，基本不会变化。直接写入Kafka。

b.业务逻辑复杂，数据可能<频繁>变化，写入Delta Lake。实践上看，直接写入Kafka是最容易的方案，但是灵活性很低，历史数据无法追溯，也无法修改。DW层通过引入Delta Lake，可以实现流批统一数据源，历史分区数据恢复等功能。
DM层

DM层就是最后的报表展示指标了，可以将DW层delta表做为数据源，再次汇总后sink到展示用的DataBase

架构方案进一步说明

• 为什么不直接从ODS计算

以核桃的到课指标为例，数据源是Kafka的埋点topic，需要计算的指标有个人维度到课数据，学期维度，班级维度，学期维度，市场渠道维度。
每个维度都需要消费所有的埋点数据，从中挑出到课相关的事件。并且每个维度的计算程序都需要查询HBase/Mysql关联相关的学期，班级，unit等维表。
一旦有整体逻辑的调整，例如过滤测试班数据，不可能从ods层就把数据过滤掉(这样从底层就开始丢失数据，后期无法追查)，那么所有程序都需要重新调整，添加这个过滤逻辑。

• 怎么恢复数据

理想情况是，实时与离线使用同一套SQL，同一套计算逻辑，同一个数据源，这样随时可以用离线脚本重跑历史数据。但是现实是没有哪个框架支持。所谓流批一体，都是在引擎层面，例如Spark的streaming和SQL都是batch的方式，流只是更小的批。而Flink则希望用流的方式去处理批数据，批只是有边界的流。针对高阶的SQL API，流批都有很大的区别。基于Delta Lake的分区表，将dw层的实时数据按时间分区，这样可以随时用离线作业恢复历史分区的数据。而DW之上的汇总因为数据量相对较小，恢复之后可以用流作业从头消费。

业务效果

Delta Lake实时数仓在核桃编程部分数据仓库生产环境上线后，部分业务统计指标已基于新架构产出，指标更新延迟从几十分钟，提升到1分钟以内。班主任可以更快获取学生的学习状态，及时跟进学习进度,从而显著提升了教学质量。
在CDC应用后，数据同步延迟从半小时提升到30秒，同时解决了Sqoop高并发同步时对业务数据库的影响。数据分析人员Ad-Hoc查询时，可以获取实时的业务数据，明显提升了数据分析效果，并且可以更及时的指导业务发展