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

2021-09-01 10:58Tapdata 技术合伙人肖贝贝

摘要:本文将选取市面上一些流计算框架包括 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 、Spark 、Hazelcast 的对比结果

(△ 流计算框架 Flink 、Spark 、Hazelcast 的对比结果)

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 微信服务号二维码



推荐阅读

Tapdata 推出“钛计划”公益项目,着力打通数据孤岛助推社会数字化升级

为响应数据要素市场化配置改革政策方向的指引,Tapdata 推出“钛计划”打通数据孤岛公益行动,面向非盈利机构(如各城市政务服务数据管理局、社会公益组织/项目等)以及为社会培养数据技术人才的相关培训机构,提供 Tapdata 实时数据服务平台的特殊免费授权,助推公共领域数据互通、共享与实时应用......

Tapdata 钛铂数据的产品理念

Tapdata 是全球首个基于数据即服务架构理念、面向 TP 场景的企业实时主数据服务平台,可以帮助企业快速实现主数据的统一管理和发布,并为所有数据库、数仓、大数据平台提供最实时的源数据,让数据随时可用。

Tapdata Cloud 是什么?

Tapdata Cloud 是钛铂数据自研的异构数据库实时同步工具 Tapdata Replicator 的云服务版本,现在免费提供所有开发者和企业使用Tapdata Cloud 目前支持 Oracle、MySQL、PostgreSQL、SQL Server、MongoDB、Elasticsearch 之间的数据迁移和同步,未来将陆续上线 DB2、Sybase ASE、Redis、Kafka 等。

什么是数据即服务(Data as a Service)?

数据即服务(DaaS)是一种数据管理策略,旨在利用数据作为业务资产来提高业务创新的敏捷性。它是自 1990 年代互联网高速发展以来越来越受欢迎的“一切皆服务”(XaaS)趋势下关于数据服务化的那一部分,介于 PaaS 和 SaaS 之间。与 SaaS 类似,DaaS 提供了一种方式来管理企业每天生成的大量数据,并在整个业务范围内提供这些有价值的信息,以便于进行数据驱动的商业决策。同时,我们也...

什么是数据虚拟化(Data Virtualization)?

本文将简单易懂地介绍数据虚拟化技术及数据虚拟化软件架构的实现方法,尽量避免教条主义。如需要了解虚拟化定义,可通过wiki 百科了解。先引用一段百度百科的文字来说明数据虚拟化的定义:数据虚拟化(data virtualization)是用来描述所有数据管理方法的涵盖性术语,这些方法允许应用程序检索并管理数据,且不需要数据相关的技术细节,例如它格式化的方式或物理位置所在。正如百科的定义,采用数据...

Tapdata 数据库实时同步的技术要点

Tapdata 专注于实时数据的处理技术,在数据库迁移和同步方面,Tapdata 的表现非常优秀,实时、多元、异构,尤其在关系数据库到非关系数据库之间的双向同步方面,无论是从操作上,还是效率上,都体现了业界领先的水平。本文重点阐述 Tapdata 在数据库实时同步方面的技术要点。

教育中台与第三方系统对接整合数据案例

最近, 南京秦淮区教育中台系统,成功地和市系统进行了一次圆满对接。通过教育中台提供的统一数据能力和低代码API对接能力,实现了对市系统数据的实时推送和拉取,以及各类业务逻辑上的处理。这次对接为南京市中小学生创客大赛的成功举办提供了及时可靠的数据支撑, 体现了中台系统在快速响应业务方面的优越性。

周生生 | 全渠道商品中心建设

通过Tapdata 构建全渠道商品中心,实现: - 支持中国大陆港澳台的上千家门店的生产环境; - 使用JS脚本来进行流处理计算,业务需求从开发到上线过程快至 1 天以内; - 任务配置与执行监测全程可视化操作,不懂技术也能完成操作,极大降低维护成本; - 一套产品可满足不同需求,根据业务需求产出不同类型的业务模型节省大量人力物力。

关系型数据库到MongoDB实时数据同步解决方案

使用MongoDB作为主机下行或新一代数据库的选择,将业务数据从已有主机或Oracle等关系型数据库复制到MongoDB; 使用Tapdata Replicator的CDC技术,实时监听现有业务库的数据变动并同步至MongoDB; 使用Tapdata 的RDM技术将关系型表合并转型到MongoDB JSON数据结构,并保持和源库的高度数据一致; 在MongoDB上进行新业务的开发。

Tapdata肖贝贝:实时数据引擎系列(一)-新鲜的数据流

前言2006 年诞生的 hadoop 和 她周边的生态, 在过去的这些年里为大数据的火热提供了足够的能量, 十几年过去了, 场景在变化, 技术在演变, 大家对数据的认知已经不再局限于 T+1 与 高吞吐高延迟 为主要特征的上一代框架理念, 在真实的场景里, 实时, 准确, 多变 的数据也发挥着越来越重要的作用为满足这些新的需求, 各种框架和中间件如雨后春笋般不断涌出hive 的出现让这头大象...
联络我们:
Email:team@tapdata.io    电话:0755-26656080
深圳市南山区临海大道香江金融中心 2410-13
官方服务号
Tapdata 微信公众号
扫码关注