关于mongdb:Tapdata肖贝贝实时数据引擎系列三-流处理引擎
摘要:本文将选取市面上一些流计算框架包含 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分, 是否还在倒退与保护比照后果为了防止有些同学不喜爱看简短的测试过程, 先把评测后果提前放在这里。 ...