知乎-用Flink取代Spark Streaming！知乎实时数仓架构演进[笔记]

知乎的实时数仓实践以及架构的演进：

• 实时数仓 1.0 版本，主题：ETL 逻辑实时化，技术方案：Spark Streaming。
• 实时数仓 2.0 版本，主题：数据分层，指标计算实时化，技术方案：Flink Streaming。
• 实时数仓未来展望：Streaming SQL 平台化，元信息管理系统化，结果验收自动化。

关于选型：

1.0

2016 年年初，业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架，Spark Streaming 用 Micro Batch 模拟流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了 Spark Streaming 作为实时数据的处理框架。

2.0

Flink 相比 Spark Streaming 有更明显的优势，主要体现在：低延迟、Exactly-once 语义支持、Streaming SQL 支持、状态管理、丰富的时间类型和窗口计算、CEP 支持等。

Flink 的 Streaming SQL 有以下优点：易于平台化、开发效率高、维度成本低等。

目前 Streaming SQL 使用起来也有一些缺陷：1. 语法和 Hive SQL 有一定区别，初使用时需要适应；

2.UDF 不如 Hive 丰富，写 UDF 的频率高于 Hive。

未来进一步提升方向：

• 1.Streaming SQL 平台化。目前 Streaming SQL 任务是以代码开发 maven 打包的方式提交任务，开发成本高，后期随着 Streaming SQL 平台的上线，实时数仓的开发方式也会由 Jar 包转变为 SQL 文件。
• 2.实时数据元信息管理系统化。对数仓元信息的管理可以大幅度降低使用数据的成本，离线数仓的元信息管理已经基本完善，实时数仓的元信息管理才刚刚开始。
• 3.实时数仓结果验收自动化。对实时结果的验收只能借助与离线数据指标对比的方式，以 Hive 和 Kafka 数据源为例，分别执行 Hive SQL 和 Flink SQL，统计结果并对比是否一致实现实时结果验收的自动化。