Flink vs Storm

[笔记]知乎-用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，统计结果并对比是否一致实现实时结果验收的自动化。

[笔记]从Storm到Flink，汽车之家基于Flink的实时SQL平台设计思路与实践

Storm Spout + Bolt 的编程模型比较简单，且集群稳定，但随着实时计算的需求日渐增多，数据规模逐步增大，Storm 在开发及维护成本上都凸显了不足，最突出的两个痛点:

1.翻译 SQL

我们一直是 Lambda 架构，会用 T+1 的离线数据修正实时数据，即最终以离线数据为准，所以计算口径实时要和离线完全保持一致，实时数据开发的需求文档就是离线的 SQL，实时开发人员的核心工作就是把离线的 SQL 翻译成 Storm 代码，期间虽然封装了一些通用的 bolt 来简化开发，但把离线动辄几百行的 SQL 精准的翻译成代码还是很有挑战的，并且每次运行都要经过打包，上传， 重启的一系列的繁琐操作，调试成本很高。

2.过于依赖外部存储

Storm 对状态支持的不好，通常需要借助 Redis，HBase 这类 kv 存储维护中间状态，我们之前是强依赖 Redis。比如常见的计算 UV 的场景， 最简单的办法是使用 Redis 的 sadd 命令判断 uid 是否为已经存在，但这种方法会占用大量内存，如果没有提前报备的大促或搞活动导致流量翻倍的情况，很容易把 Redis 内存搞满，运维同学也会被杀个措手不及，同时 Redis 的吞吐能力也限制了整个作业的吞吐量。

在此背景下我们封装了基于 BloomFilter 的 bolt，BloomFilter 本身也会作为状态定期持久化到 reids 中，但是在多维度高基数的场景下，很难精确控制每个 BloomFilter 的大小，同样会占用很大内存。同时，过于依赖 Redis，在 Redis 集群 rtt 过长或部分节点负载高时会导致 Storm 作业 failed。

  Flink 引擎对SQL的支持相对比较完备，天生对状态支持。

 

fxjwind

 

流计算技术实战 - CEP

CEP，Complex event processing

Wiki定义

“Complex event processing, or CEP, is event processing that combines data from multiple sources[2] to infer events or patterns that suggest more complicated circumstances. The goal of complex event processing is to identify meaningful events (such as opportunities or threats)[3] and respond to them as quickly as possible.”

通过上面的Wiki定义，可以看出CEP的特点主要是，
复杂性：多个流join，窗口聚合，事件序列或patterns检测
低延迟：秒或毫秒级别，比如做信用卡盗刷检测，或攻击检测
高吞吐：每秒上万条消息

CEP和数据库

CEP的概念出现比较早，用于解决传统数据库所无法解决的实时需求
传统数据库，数据是静态的，查询是动态的，但做不到实时和连续的输出查询结果
而CEP反其道而行之，查询是静态的，数据是动态的，这样就可以满足实现和连续查询的需求，但是无法满足ad hoc查询需求
所以CEP和传统数据库相结合，可以用于解决金融，商业，网络监控等领域的问题

复杂事件处理（CEP）解决了对连续传入事件进行模式匹配的问题。 匹配的结果通常是从输入事件派生的复杂事件。 与对存储数据执行查询的传统DBMS相比，CEP在存储的查询上执行数据。 可以立即丢弃与查询无关的所有数据。 考虑到CEP查询应用于潜在的无限数据流，这种方法的优势是显而易见的。 此外，输入立即处理。 一旦系统看到匹配序列的所有事件，结果就会立即发出。 这方面有效地带来了CEP的实时分析能力。
比如比较知名的Esper，功能非常强大，并提供EPL这样类sql语言，让用户感觉到类似使用数据库的体验

流计算下的CEP

流式计算概念可以认为是从Storm或