共计 5061 个字符，预计需要花费 13 分钟才能阅读完成。
摘要：本文将选取市面上一些流计算框架包含 Flink、Spark、Hazelcast，从场景需要登程，在外围性能、资源与性能、用户体验、框架完整性、维护性等方面开展剖析和测评，分析实时数据框架的特色。
后面的两篇文章（实时数据引擎系列(一): 陈腐的数据流和实时数据引擎系列(二): 批流一体的数据）讲到了数据集成 CDC 的一些背景和问题, 在说流引擎之前, 咱们先拿市面上的一些流计算框架做一些剖析和评测, 实时数据框架的选手很多, 每家都有本人的特色, 这篇文章会依照咱们的场景需要, 从以下几个方面去做一些摸索:
- 外围性能: 数据集成与输入, 并表, 聚合
- 资源与性能: 不同场景下的资源耗费与性能
- 用户体验: 装置部署运维是否不便, 是否蕴含可视化工作构建与治理, 是否提供了客户端 SDK 与 SQL 接口
- 框架完整性: 是否蕴含任务调度, 分布式, 高可用, 是否提供了编程框架
- 维护性: 是否还在倒退与保护
评测选手
- Flink: 流计算框架顶流选手, 流数据第一公民开创者
- Spark: 大数据计算传统选手, Stream 框架反对流计算
- Hazelcast: 一个能够内嵌开发的轻量流计算框架, 以自带分布式内存作为亮点
具体测试内容
- 数据集成与输入: 10 分, 测试对接的数据源与指标的类型, 是否是批流, 是否不便二次开发
- 并表: 10 分, 在咱们的场景下, 对窗口的要求并不高, 要求对全数据进行并表, 同时, 每张表都可能是来自不同类型数据库的流数据, 并且每张表的更新不保障有序, 在这个场景下, 要求并表的后果与批量的后果可能最终统一
- 聚合: 10 分, 与并表的数据场景相似, 要求聚合的后果与批量计算的后果可能最终统一
- 资源耗费: 15 分, 每个场景下的 CPU 与 内存, IO 耗费, 测试 case 有三个, 10G 文本单词计数, 千万表 JOIN 百万表, 千万表增量聚合, 以最大的内存 RES 为准, 得分咱们以最低为满分, 每个场景 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 分满分, 其余按比例给分
- 装置部署运维: 10 分, 装置部署是否不便, 运维是否不便, 是否提供可视化界面
- 客户端 SDK 与 SQL 接口: 10 分, 客户端是否使用方便, 是否反对 SQL 计算
- 框架完整性: 10 分, 是否可嵌入, 是否蕴含任务调度, 分布式, 高可用
- 维护性: 10 分, 是否还在倒退与保护
比照后果
为了防止有些同学不喜爱看简短的测试过程, 先把评测后果提前放在这里。
Flink
数据集成与输入
在一开始, Flink 只反对从 kafka 输出数据, 这个设计上尽管很简洁, 然而落地上很苦楚, 使用者未免要写各种过程将数据灌入到 kafka 内, 起初开始有 官网和民间编写的各种 flink-**
-connectors 作为补充。
去年开始开源的 flink-cdc-connectors, 通过集成 debezium 的能力, 去除了 kafka 的依赖, 将数据从源端间接流入到计算框架内, 反对十数种数据库的 全量 + 增量 的间接集成。
debezium 的能力十分强, 然而作为开源产品固有的弊病, 在许多企业外部应用十分多然而标准不是特地规范和凋谢的数据库上, 比方 SQL Server, Oracle, DB2, GaussDB, Sybase 这些, 总体的支持性都比拟差。
Flink 的 数据输入反对十数种类型的场景, 对数据库的品种反对也不全面。
Flink 的数据集成与输入取得 5/10 分:*
- 具备根本的性能与框架 (3)
- 常见的开源数据库对接尚可, 品种有余 (1)
- 商业数据库对接能力有余 (1)
并表
Flink 间接反对带窗口的 双流 JOIN, 或者 流表维表 JOIN。
多流 INNER JOIN 须要应用多个双流 JOIN 实现, 多流 LEFT JOIN 须要本人实现 cogroup, 并且流的更新须要本人写逻辑存储状态, 框架自身没有很好地反对简单的并表逻辑。
然而下层的 Table API, 简直实现了大多数场景的 表合并, 体验十分好, 配合 CDC 源, 做到了真正的批流一体, 十分不便。
因而, 在并表这个场景上, Flink 能够失去 8/10 分
- 反对根本的两表 INNER JOIN, 反对乱序 (3)
- LEFT JOIN , 与数据流更新须要本人实现状态存储与事件逻辑 (2)
- 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 技术合伙人肖贝贝，源文地址。