基于Flink+Hive+Kafka的流批一体数仓实践--01架构及思想

基于Flink+Hive+Kafka的流批一体数仓实践–01架构及思想

最近阅读了李劲松老师的一篇文章，决定基于他的思想实践一把。
为什么需要实时数仓？
基于 Hive 的离线数仓往往是企业大数据生产系统中不可缺少的一环。Hive 数仓有很高的成熟度和稳定性，但由于它是离线的，延时很大。在一些对延时要求比较高的场景，需要另外搭建基于 Flink 的实时数仓，将链路延时降低到秒级。但是一套离线数仓加一套实时数仓的架构会带来超过两倍的资源消耗，甚至导致重复开发。
想要搭建流式链路就必须得抛弃现有的 Hive 数仓吗？并不是，借助 Flink 可以实现已有的 Hive 离线数仓准实时化。
离线数仓架构的问题：

上图是一个典型的离线数仓，假设现在公司有一个需求，目前公司的数据量很大，需要每天出一个报表且输出到业务数据库中。首先是刚入库的业务数据，大致分为两种，一种是 MySQL 的 binlog，另外一种是业务系统中的业务打点，这个日志打点信息可以通过 Flume 等工具去采集，再离线入库到数仓中。然后随着业务越来越多，业务中的各个表可以做一些抽象，抽象的好处是更好的管理和更高效的数据复用和计算复用。所以数仓就分成了多层 (明细层、中间层、服务层等等)，每一层存的是数据表，数据表之间通过 HiveSQL 的计算来实现 ETL 转换。
不止是 HiveSQL ，Hive 只是静态的批计算，而业务每天都要出报表，这意味着每天都要进行计算，这种情况下会依赖于调度工具和血缘管理：
调度工具：按照某个策略把批计算调度起来。
血缘管理：一个任务是由许多个作业组合而成，可能有非常复杂的表结构层次，整个计算是一个非常复杂的拓扑，作业间的依赖关系非常复杂 (减少冗余存储和计算，也可以有较好的容错)，只有当一级结束后才能进行下一级的计算。

当任务十分庞大的时候，我们得出结果往往需要