Tapdata肖贝贝：实时数据引擎系列(三) - 流处理引擎

摘要：本文将选取市面上一些流计算框架包括 Flink 、Spark 、Hazelcast，从场景需求出发，在核心功能、资源与性能、用户体验、框架完整性、维护性等方面展开分析和测评，剖析实时数据框架的特色。

前面的两篇文章（实时数据引擎系列(一): 新鲜的数据流和实时数据引擎系列(二): 批流一体的数据）讲到了数据集成 CDC 的一些背景和问题, 在说流引擎之前, 我们先拿市面上的一些流计算框架做一些分析和评测, 实时数据框架的选手很多, 每家都有自己的特色, 这篇文章会按照我们的场景需求, 从以下几个方面去做一些探索:

1. 核心功能: 数据集成与输出, 并表, 聚合
2. 资源与性能: 不同场景下的资源消耗与性能
3. 用户体验: 安装部署运维是否方便, 是否包含可视化任务构建与管理, 是否提供了客户端 SDK 与 SQL 接口
4. 框架完整性: 是否包含任务调度, 分布式, 高可用, 是否提供了编程框架
5. 维护性: 是否还在发展与维护

评测选手

1. Flink: 流计算框架顶流选手, 流数据第一公民开创者
2. Spark: 大数据计算传统选手, Stream 框架支持流计算
3. Hazelcast: 一个可以内嵌开发的轻量流计算框架, 以自带分布式内存作为亮点

详细测试内容

1. 数据集成与输出: 10分, 测试对接的数据源与目标的类型, 是否是批流, 是否方便二次开发
2. 并表: 10 分, 在我们的场景下, 对窗口的要求并不高, 要求对全数据进行并表, 同时, 每张表都可能是来自不同类型数据库的流数据, 并且每张表的更新不保证有序, 在这个场景下, 要求并表的结果与批量的结果能够最终一致
3. 聚合: 10 分, 与并表的数据场景类似, 要求聚合的结果与批量计算的结果能够最终一致
4. 资源消耗: 15分, 每个场景下的 CPU 与 内存, IO 消耗, 测试 case 有三个, 10G 文本单词计数, 千万表 JOIN 百万表, 千万表增量聚合, 以最大的内存 RES 为准, 得分我们以最低为满分, 每个场景 5 分满分, 其余按比例给分
5. 性能: 15分, 吞吐与延迟, 测试 case 有三个, wordcount, 千万表数据 JOIN 百万表数据, 千万表聚合, 为测量延迟, 我们增加一个表同步, 通过数据库表字段的当前时间来判断延迟, 执行硬件环境为 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports), 处理器 2.3 GHz 双核Intel Core i5, 内存 8 GB 2133 MHz LPDDR3, 数据库测试环境为: 16C 64G SSD 环境, 网卡为千兆网卡, 任务开 4 并发, 性能的得分我们以最高为满分, 每个场景 5 分满分, 其余按比例给分
6. 安装部署运维: 10分, 安装部署是否方便, 运维是否方便, 是否提供可视化界面
7. 客户端 SDK 与 SQL 接口: 10分, 客户端是否使用方便, 是否支持 SQL 计算
8. 框架完整性: 10分, 是否可嵌入, 是否包含任务调度, 分布式, 高可用
9. 维护性: 10分, 是否还在发展与维护

对比结果

为了避免有些同学不喜欢看冗长的测试过程, 先把评测结果提前放在这里。

Flink

数据集成与输出

在一开始, Flink 只支持从 kafka 输入数据, 这个设计上虽然很简洁, 但是落地上很痛苦, 使用者不免要写各种过程将数据灌入到 kafka 内, 后来开始有官方和民间编写的各种 flink-**
-connectors 作为补充。

去年开始开源的 flink-cdc-connectors, 通过集成 debezium 的能力, 去除了 kafka 的依赖, 将数据从源端直接流入到计算框架内, 支持十数种数据库的 全量+增量 的直接集成。

debezium 的能力非常强, 但是作为开源产品固有的弊端, 在许多企业内部使用非常多但是规范不是特别标准和开放的数据库上, 比如 SQL Server, Oracle, DB2, GaussDB, Sybase 这些, 总体的支持性都比较差。

Flink 的 数据输出支持十数种类型的场景, 对数据库的种类支持也不全面。

Flink 的数据集成与输出获得 5/10 分:*

1. 具备基本的功能与框架 (3)
2. 常见的开源数据库对接尚可, 种类不足 (1)
3. 商业数据库对接能力不足 (1)

并表

Flink 直接支持带窗口的 双流 JOIN, 或者 流表维表 JOIN。

多流 INNER JOIN 需要使用多个双流 JOIN 实现, 多流 LEFT JOIN 需要自己实现 cogroup, 并且流的更新需要自己写逻辑存储状态, 框架本身没有很好地支持复杂的并表逻辑。

但是上层的 Table API, 几乎实现了大多数场景的 表合并, 体验非常好, 配合 CDC 源, 做到了真正的批流一体, 非常方便。

因此, 在并表这个场景上, Flink 可以得到 8/10 分

1. 支持基本的两表 INNER JOIN, 支持乱序 (3)
2. LEFT JOIN , 与数据流更新需要自己实现状态存储与事件逻辑 (2)
3. Table SQL 接口对常见的并表接口几乎完美实现 (3)

聚合

与并表支持程度高度类似, 但是 SQL 接口实现上, 在聚合上, 我们往往不需要批量的中间结果, 基于这个考虑, 给到 7/10 分。

资源消耗

我的测试场景里, taskmanager.memory.process.size 设置少于 1G,
jobmanager.memory.process.size 少于 800M 会报错, 这里这边给到 1G 到 jobmanager, 给到 800M 到 taskmanager, 测试任务运行过程中, 操作系统 RES 的变化:

10G 文本单词计数: 内存 300M

表同步: 内存 300M

后续的两个操作均因为内存不足无法完成, 大约 2G 的内存占用, 可以完成 300W 数据的加载, 考虑到单记录 50 字节, 放大系数大约为十倍
将状态存储后端修改为 RocksDB 后继续进行, 消耗了 200M 磁盘, 完成了 1100w 数据的加载

千万表数据 JOIN 百万表数据: 800M 内存, 200M 磁盘

千万表聚合: 800M 内存, 60M 磁盘

考虑一个场景, 在数据量继续增加时, rocksdb 会遇到单机存储的问题, 1e 条业务表, 每条 1KB, 单机状态就会达到数十GB, 多表合并的场景, 状态会达到数百GB, 在这种大小的规模下, rocksdb 自身的写放大问题会变得非常突出, 而在这个数量级继续提升的时候, 框架将不可用, 这种情况下需要使用者都通过外置 KV 存储服务来解决, 这个带来了额外的复杂性。

状态的存储一直是 Flink 很常遇见的瓶颈, 大多数使用者建议设置时序窗口来保证总的状态可控, 在基于日志, 用户行为的流合并场景, 窗口是好的选择, 但是 TAPDATA 面对的业务场景, 大多数都是 TP 型的, 业务型的数据, 这里大多数都是没有时间窗口的, 框架需要对全窗口, 百 GB 级别的多表进行流式并表, 在这种情况下, Flink 关于状态的设计会让框架无法实际落地。

考虑到这些问题, Flink 的资源消耗给到 9/15 分

性能

10G 文本单词计数: 17min 5s

千万表数据 JOIN 百万表数据速度: 源端写入 2000, 同步 1600

千万表数据 JOIN 百万表数据聚合 top10, 速度: 源端写入 2000, 同步 1600

表同步延迟: 单条大约延时 900ms, 源表同步写入 3min, 源表写入 279048 条, 目标表写入 200009, 总耗时 3 分钟 41 秒完成同步。

这个场景里, Flink 的表现, 包括延迟与性能都没有很好, 这个测试使用的 SQL 接口, 应该是实现上有些不合理的地方。

以整个过程表现最好的 Hazelcast 作为满分, Flink 的性能得分是 10/15 分

安装部署运维

Flink 总体的部署架构, 分为 一个任务分发进程, 一个执行进程, 非常通用的任务类架构设计, 部署上支持单机, 单分发多执行, 利用 ZK 的 HA 多分发, 利用 YARN 的高可用, 利用 k8s 的高可用, 支持很完善。

但是分布式部署上, 需要一些本地域名配置, 拷贝文件一类的操作, 产品化不够完善, 使用不方便
自身的 UI 主要用来做任务查看, 不具备运维管理能力。

Flink 安装部署运维打 4/10 分。

客户端 SDK 与 SQL

支持 JAVA 系 与 Python 的 SDK, 其他语言支持不好。

支持比较完整的 SQL给 7/10 分。

框架完整性

不可嵌入, 支持任务调度, 分布式, 高可用, 我们比较在意嵌入性特性, 主观给 7/10 分

维护性

Flink 的社区和开源发展非常活跃, 10/10 分

综上, 在这个评价体系下, Flink 可以得到 67 分。

Spark

数据集成与输出

Spark 支持一些批数据的接入, CDC 无法原生支持, 需要借助 kafka, 给 3/10 分。

并表

Spark 支持流式并表, 支持乱序容忍, 但是需要自己写一些 SQL, 易用性差一些, 不支持 CDC 上的直接 SQL, 给到 6/10 分。

聚合

支持流式聚合, 不支持 CDC 上的直接聚合, 给到 3/10 分。

资源消耗

10G 文本单词计数: 内存 900M
同步: 需要集成 kafka, 没有测试，其他未测试。

性能

10G 文本单词计数: 6min 30s。

安装部署运维

整体与 Flink 非常类似, 多了一个界面化的 SQL, 给到 5/10 分。

客户端 SDK 与 SQL

与 Flink 非常类似, 支持的语言和接口也类似。

框架完整性

与 Flink 非常类似。

维护性

官方还一直在更新, 但是实时计算领域, 热度被 Flink 盖过很多。

Hazelcast

数据集成与输出

基于 debezium 与 自研的部分接入, 较 Flink 少一些, 且看不到开源支持, 增量只有 Mysql 与 PG, 给到 4/10 分。

并表

Hazelcast 目前只支持批量并表, 或者批量并流式表, 不支持多流并表, 给到 3/10 分。

聚合

与并表类似, 给到 3/10 分。

资源消耗

10G 文本单词计数: 内存 150M
表同步: 内存 150M
千万表数据 JOIN 百万表数据: 不支持流 JOIN, 无可比性(通过全量加载百万表, 流式加载千万表完成)
千万表聚合: 内存 800M

性能

10G 文本单词计数: 6min 17s

千万表数据 JOIN 百万表数据速度: 源表 2000, 目标 2000

千万表数据聚合 top10, 速度: 源表 2000, 目标 2000

表同步延迟: 单条大约延时 500ms, 源表同步写入 3min, 源表写入 303709 条, 目标表写入 303454, 总耗时 3 分钟完成同步, 最终延迟在 500ms 左右
Hazelcast 在性能场景里, 全部表现都是最好的, 给到 15/15 分

安装部署运维

Hazelcast 支持单机, 分布式部署, 通过 P2P 方式配置, 任务可提交到到任意节点, 不需要修改任何宿主机配置, 也不需要依赖任何外部组件, 使用非常方便, 并且支持动态扩容。
由于自身为 P2P + 配置指定, 不需要额外组件协调, 与 k8s 的结合也非常方便, 但是本身没有提供云原生部署的方式, 需要自己做一些开发, 或者写一个 CRD。
这里给到 8/10 分。

客户端 SDK 与 SQL

Hazelcast 支持非常多的客户端, 8 种类型, 支持 Rest API
但是 SQL 接口目前还处在 BETA 阶段, 支持的功能非常有限，整体给到 6/10 分。

框架完整性

可嵌入, 支持任务调度, 分布式, 高可用, 给 9/10 分。

维护性

Hazelcast 分为社区版本与企业版, 社区版开源, 更新比较活跃, 但是贡献者主要为公司内部成员, Tech Partner 不多, 给到 6/10 分。

总结

Flink 在流处理的核心场景里, 从功能的实现完善程度来讲, Flink 依然是现有产品中的佼佼者, 在流处理上相比 Spark 的整体体验好很多, 但是对我们全数据流式并表, 流式聚合的场景, Flink 存在设计上的不适配, 原生流框架无法直接落地, 需要自己编写状态存储逻辑才能降低损耗, 在性能测试中, Flink 也由于一些原因没有取得太好的结果, 同时, Flink 在部署架构上相对还是原来大数据的一套模板, 上手易用性不是特别好

简而言之, Flink is good, but Far away from perfect。

Hazelcast 作为一个传统的分布式内存产品, 在最近的版本里开始加入流处理框架, 虽然现在的功能实现相对不完善, 但是在设计, 可嵌入性, 框架性能, 资源等方面, 我们看到了一个可能有些不一样的东西在里面, Tapdata 基于 Hazelcast 做了大量的改进, 作为我们产品的计算引擎。

Tapdata 自研了超过三十种数据库的实时集成, 并通过目标表与缓存表统一, 解决了全数据并表, 聚合的资源消耗问题, 将状态存储于外置 MongoDB 中, 解决了高可用时的状态恢复问题, 通过大量的幂等设计与精确一次的结合, 在保证最终结果一致性的基础上, 保证了极高的处理性能, 同时, 通过 UI 拖拉拽将任务构建可视化傻瓜化, 通过支持基于 JS/Python/Java 的自定义算子, 将数据处理流程简单化, 整套系统落地超过三十多个客户场景, 是对现有流计算框架产品的一个企业级补充。

Tapdata 的流计算引擎开源正在筹备中, 大家可以期待! 进一步了解 Tapdata 实时数据服务平台，更多技术文章可前往 Tapdata 技术博客。

本文作者：Tapdata 技术合伙人肖贝贝，源文地址。