基于 Flink + Hive 构建流批一体准实时数仓

基于 Hive 的离线数仓往往是企业大数据生产系统中不可缺少的一环。Hive 数仓有很高的成熟度和稳定性，但由于它是离线的，延时很大。在一些对延时要求比较高的场景，需要另外搭建基于 Flink 的实时数仓，将链路延时降低到秒级。但是一套离线数仓加一套实时数仓的架构会带来超过两倍的资源消耗，甚至导致重复开发。

想要搭建流式链路就必须得抛弃现有的 Hive 数仓吗？并不是，借助 Flink 可以实现已有的 Hive 离线数仓准实时化。本文整理自 Apache Flink Committer、阿里巴巴技术专家李劲松的分享，文章将分析当前离线数仓实时化的难点，详解 Flink 如何解决 Hive 流批一体准实时数仓的难题，实现更高效、合理的资源配置。文章大纲如下：

1. 离线数仓实时化的难点
2. Flink 在流批一体的探索
3. 构建流批一体准实时数仓应用实践

离线数仓实时化的难点

离线数仓

上图是一个典型的离线数仓，假设现在公司有一个需求，目前公司的数据量很大，需要每天出一个报表且输出到业务数据库中。首先是刚入库的业务数据，大致分为两种，一种是 MySQL 的 binlog，另外一种是业务系统中的业务打点，这个日志打点信息可以通过 Flume 等工具去采集，再离线入库到数仓中。然后随着业务越来越多，业务中的各个表可以做一些抽象，抽象的好处是更好的管理和更高效的数据复用和计算复用。所以数仓就分成了多层 (明细层、中间层、服务层等等)，每一层存的是数据表，数据表之间通过 HiveSQL 的计算来实现 ETL 转换。

不止是 HiveSQL ，Hive 只是静态的批计算，而业务每天都要出报表，这意味着每天都要进行计算，这种情况下会依赖于调度工具和血缘管理：

• 调度工具：按照某个策略把批计算调度起来。
• 血缘管理：一个任务是由许多个作业组合而成，可能有非常复杂的表结构层次，整个计算是一个非常复杂的拓扑，作业间的依赖关系非常复杂 (减少冗余存储和计算，也可以有较好的容错)，只有当一级结束后才能进行下一级的计算。

当任务十分庞大的时候，我们得出结果往往需要很长的一段时间，也就是我们常说的 T+1，H+1 ，这就是离线数仓的问题。

第三方工具

上面说过，离线数仓不仅仅是简单的 Hive 计算，它还依赖了其它的第三方工具，比如：

• 使用 Flume 来入库，但存在一定的问题，首先，它的容错可能无法保证 Exactly-Once 效果，需要下游再次进行去重操作。其次，自定义逻辑需要通过一些手段，比如脚本来控制。第三，离线数仓并不具备良好的扩展能力，当数据剧增时，增加原本的并发数就比较困难了。
• 基于调度工具的作业调度会带来级联的计算延迟，比如凌晨 1 点开始计算昨天的数据，可能需要到早上 6、7 点才能做完，并且无法保证在设置的调度时间内数据可以完全 ready 。此外，级联的计算还会带来复杂的血缘管理问题，大任务的 Batch 计算可能会突然打满集群的资源，所以也要求我们对于负载管理进行考量，这些都会给业务增加负担。

无论是离线数仓还是第三方工具，其实主要的问题还是“慢”，如何解决慢的问题，此时就该实时数仓出场了。

实时数仓

实时数仓其实是从 Hive+HDFS 的组合换成了 Kafka，ETL 的功能通过 Flink 的流式处理解决。此时就不存在调度和血缘管理的问题了，通过实时不断的增量更新，最终输出到业务的 DB 中。

虽然延时降低了，但此时我们会面临另外一些问题：

• 历史数据丢失，因为