摘要：本文将选取市面上一些流计算框架包括 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

数据集成与输出

在一开始, 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肖贝贝：实时数据引擎系列(三) - 流处理引擎对比的更多相关文章

  1. {MySQL存储引擎介绍}一 存储引擎解释 二 MySQL存储引擎分类 三 不同存储引擎的使用

    MySQL存储引擎介绍 MySQL之存储引擎 本节目录 一 存储引擎解释 二 MySQL存储引擎分类 三 不同存储引擎的使用 一 存储引擎解释 首先确定一点,存储引擎的概念是MySQL里面才有的,不是 ...

  2. Tapdata 肖贝贝：实时数据引擎系列(四)-关于 Oracle 与 Oracle CDC

      摘要:想实现 Oracle 的 CDC,排除掉一些通用的比如全量比对, 标记字段获取之外, 真正的增量形式获取变更, 有三种办法: Logminer .XStream .裸日志解析,但不管哪种方法 ...

  3. Tapdata 肖贝贝：实时数据引擎系列(六)-从 PostgreSQL 实时数据集成看增量数据缓存层的必要性

      摘要:对于 PostgreSQL 的实时数据采集, 业界经常遇到了包括:对源库性能/存储影响较大, 采集性能受限, 时间回退重新同步不支持, 数据类型较复杂等等问题.Tapdata 在解决 Pos ...

  4. leaflet-webpack 入门开发系列三地图分屏对比(附源码下载)

    前言 leaflet-webpack 入门开发系列环境知识点了解: node 安装包下载webpack 打包管理工具需要依赖 node 环境,所以 node 安装包必须安装,上面链接是官网下载地址 w ...

  5. 基于 WebSocket 实现 WebGL 3D 拓扑图实时数据通讯同步（二）

    我们上一篇<基于 WebSocket 实现 WebGL 3D 拓扑图实时数据通讯同步(一)>主要讲解了如何搭建一个实时数据通讯服务器,客户端与服务端是如何通讯的,相信通过上一篇的讲解,再配 ...

  6. 通过 WebSocket 实现 WebGL 3D 拓扑图实时数据通讯同步（二）

    我们上一篇<基于 WebSocket 实现 WebGL 3D 拓扑图实时数据通讯同步(一)>主要讲解了如何搭建一个实时数据通讯服务器,客户端与服务端是如何通讯的,相信通过上一篇的讲解,再配 ...

  7. 实时数据引擎系列(五): 关于 SQL Server 与 SQL Server CDC

      摘要:在企业客户里, SQL Server 在传统的制造业依然散发着持久的生命力,SQL Server 的 CDC 复杂度相比 Oracle 较低, 因此标准的官方派做法就是直接使用这个 CDC ...

  8. Tapdata 实时数据融合平台解决方案（三）：数据中台的技术需求

    作者介绍:TJ,唐建法,Tapdata 钛铂数据 CTO,MongoDB中文社区主席,原MongoDB大中华区  首席架构师,极客时间MongoDB视频课程讲师. 我们讲完了这个中台的一个架构和它的逻 ...

  9. Tapdata 实时数据中台在智慧教育中的实践

      摘要:随着教育信息化的推进,智慧校园建设兴起,但在实施过程中面临数据孤岛.应用繁多.数据再利用等方面挑战,而 Tapdata 的实时数据中台解决方案,能够高效地解决智慧校园实施中的基础数据问题. ...

随机推荐

  1. selenium模块跳过用户名密码验证码输入，加载浏览器标签和cookie，进行翻页爬虫多页动态加载的数据（js)

    能解决登陆一次后,之后不需要二次登陆的动态加载数据,网页保存的cookie和标签,加入到selenium自动化测试浏览器中 1 from selenium import webdriver 2 imp ...

  2. 比 Navicat 还要好用、功能更强大的工具！

    DBeaver 是一个基于 Java 开发,免费开源的通用数据库管理和开发工具,使用非常友好的 ASL 协议.可以通过官方网站或者 Github 进行下载. 由于 DBeaver 基于 Java 开发 ...

  3. 源码解析Synchronous Queue 这种特立独行的队列

    摘要:Synchronous Queue 是一种特立独行的队列,其本身是没有容量的,比如调用者放一个数据到队列中,调用者是不能够立马返回的,调用者必须等待别人把我放进去的数据消费掉了,才能够返回. 本 ...

  4. dfs深搜

    一.01背包dfs //回溯法,01背包 #include<iostream> #include<algorithm> using namespace std; const i ...

  5. [笔记] $f(i)$ 为 $k$ 次多项式，$\sum_{i=0}^nf(i)\cdot q^i$ 的 $O(k\log k)$ 求法

    \(f(i)\) 为 \(k\) 次多项式,\(\sum_{i=0}^nf(i)\cdot q^i\) 的 \(O(k\log k)\) 求法 令 \(S(n)=\sum_{i=0}^{n-1}f(i ...

  6. AM57x 多核SoC开发板——GPMC的多通道AD采集综合案例手册（上）

    目 录 1 ----案例功能 2 ----操作说明 2.1 ----硬件连接 2.2 ----案例测试 2.3 ----使用CCS查看信号波形 2.3.1 ----加载Symbols信息表 2.3.2 ...

  7. 技术管理进阶——技术Leader如何拒绝业务方？

    原创不易,求分享.求一键三连 前段时间,有个粉丝在群里问了一个问题: 今天对接一个业务团队,要我帮他导数据,这种工作又臭又烦又没成长,而且边界模糊谁做都可以,我很想拒绝他,但又怕引起对方不满,大家有什 ...

  8. 559. Maximum Depth of N-ary Tree - LeetCode

    Question 559. Maximum Depth of N-ary Tree Solution 题目大意:N叉树求最大深度 思路:用递归做,树的深度 = 1 + 子树最大深度 Java实现: / ...

  9. 148_赠送300家门店260亿销售额的零售企业Power BI实战示例数据

    焦棚子的文章目录 一背景 2022年即将到来之际,笔者准备在Power BI中做一个实战专题,作为实战专题最基础的就是demo数据,于是我们赠送大家一个300家门店,260亿+销售额,360万行+的零 ...

  10. 论文解读（SCGC)）《Simple Contrastive Graph Clustering》

    论文信息 论文标题:Simple Contrastive Graph Clustering论文作者:Yue Liu, Xihong Yang, Sihang Zhou, Xinwang Liu论文来源 ...