这不仅是技术革新,更是认知跃迁——数据世界正以'批流一体'为核心进行板块级重构。 Flink将批处理视为特殊流处理的方法在理论上实现了批流一体,但是损失了一些批处理场景的性能,并且实际上的使用门槛更高。 笔者遇到的大量客户中,大多数批流一体方案是采用 Lambda 架构: Spark/Hive/MPP 数据库等实现离线分析,而使用 Flink 等实现实时计算。 2. YMatrix Domino 内核级创新实现“批流真一体” 无论是 Lambda 架构还是 Kappa 架构,抑或是十年来业界对于流计算技术的探索,在实现“批流一体”的进程中,总是存在多种技术或组件的拼接 Domino 架构通过数据库内核级的融合,实现了批流一体的真正突破,重新定义了批流一体的数据处理范式。
摘要: 在实时数据处理领域,“批流一体”与“流批一体”概念常被混淆。 正文 一、概念辨析:批流一体 vs 流批一体 1. 典型场景:历史报表生成(批)与实时监控(流)并存的业务。 2. 案例:某电商平台曾因批流数据不一致导致“双11”销量统计误差达12%。 2. 多引擎统一:Spark与Presto兼容,支持批流混合查询。 智能治理:自动合并小文件,优化存储效率。 2.
Table API / SQL 正在以流批统一的方式成为分析型用例的主要 API。 DataStream API 是数据驱动应用程序和数据管道的主要API。 TeraSort 本质上是分布式排序问题,它由以下几个阶 段组成: (1) 读取阶段:从 HDFS 文件中读取数据分区; (2) 本地排序阶段:对上述分区进行部分排序; (3) 混洗阶段:将数据按照 key 结果显示,Flink 仍然是速度最快的系统,它所用的时间分别是 Tez 和 Spark 的 1/2 和 1/4. ? 相反,MapReduce、Tez 和 Spark 是基于批的,这意味着数据在通过网络传输之前必须先被写入磁盘。该测试说明,在使用Flink 时,系统空闲时间和磁盘访问操作更少。 因此,Flink 可以用同一个数据处理框架来处理无限数据流和有限数据流,并且不会牺牲性能。
Table API / SQL 正在以流批统一的方式成为分析型用例的主要 API。 DataStream API 是数据驱动应用程序和数据管道的主要API。 TeraSort 本质上是分布式排序问题,它由以下几个阶 段组成: (1) 读取阶段:从 HDFS 文件中读取数据分区; (2) 本地排序阶段:对上述分区进行部分排序; (3) 混洗阶段:将数据按照 key 结果显示,Flink 仍然是速度最快的系统,它所用的时间分别是 Tez 和 Spark 的 1/2 和 1/4. ? 相反,MapReduce、Tez 和 Spark 是基于批的,这意味着数据在通过网络传输之前必须先被写入磁盘。该测试说明,在使用Flink 时,系统空闲时间和磁盘访问操作更少。 因此,Flink 可以用同一个数据处理框架来处理无限数据流和有限数据流,并且不会牺牲性能。
Flink如何做到流批一体 流批一体的理念 2020年,阿里巴巴实时计算团队提出“流批一体”的理念,期望依托Flink框架解决企业数据分析的3个核心问题,理念中包含三个着力点,分别是一套班子、一套系统、 一套班子:统一开发人员角色,现阶段企业数据分析有两个团队,一个团队负责实时开发,一个团队负责离线开发,在流批一体的理念中,期望促进两个团队的融合。 流批一体的理念即使用同一套 API、同一套开发范式来实现大数据的流计算和批计算,进而保证处理过程与结果的一致性。 何时需要流批一体 举例: 在抖音中,实时统计一个短视频的播放量、点赞数,也包括抖音直播间的实时观看人数等(流) 在抖音中,按天统计创造者的一些数据信息,比如昨天的播放量有多少、评论量多少、广告收入多少( Apache Flink主要从以下模块来实流批一体化: 1.SQL层:支持bound和unbound数据集的处理; 2.DataStream API层统一,批和流都可以使用DataStream ApI来开发
Flink使用HiveCatalog可以通过批或者流的方式来处理Hive中的表。 这就意味着Flink既可以作为Hive的一个批处理引擎,也可以通过流处理的方式来读写Hive中的表,从而为实时数仓的应用和流批一体的落地实践奠定了坚实的基础。 批处理模式写入 向非分区表写入数据 Flink SQL> use catalog myhive; -- 使用catalog Flink SQL> INSERT INTO users SELECT 2,' tom'; Flink SQL> set execution.type=batch; -- 使用批处理模式 Flink SQL> INSERT OVERWRITE users SELECT 2,'tom h',-- 每12小时加载一次最新分区数据 'streaming-source.partition-order' = 'partition-name', -- 按照分区名排序 -- 方式2:
,随后将相同的计算逻辑分别在流和批系统中实现,并且在查询阶段合并流和批的计算视图并展示给用户。 流批融合的 Lambda 架构 针对 Lambda 架构的问题3,计算逻辑需要分别在流批框架中实现和运行的问题,不少计算引擎已经开始往流批统一的方向去发展,例如 Spark 和 Flink,从而简化lambda 实现流批统一通常需要支持: 1.以相同的处理引擎来处理实时事件和历史回放事件; 2.支持 exactly once 语义,保证有无故障情况下计算结果完全相同; 3.支持以事件发生时间而不是处理时间进行窗口化 图4 Kafka + Flink + ElasticSearch的混合分析系统 Lambda plus:Tablestore + Blink 流批一体处理框架 Lambda plus 是基于 Tablestore 表格存储支持用户 tp 系统低延迟读写更新,同时也提供了索引功能 ad-hoc 查询分析,数据利用率高,容量型表格存储实例也可以保证数据存储成本可控; 计算上,Lambda plus 利用 Blink 流批一体计算引擎
01 整体思考 提到流批一体,不得不提传统的大数据平台 —— Lambda 架构。 通过一套数据链路来同时满足流和批的数据处理需求是最理想的情况,即流批一体。此外我们认为流批一体还存在一些中间阶段,比如只实现计算的统一或者只实现存储的统一也是有重大意义的。 上图是京东实时计算平台的全景图,也是我们实现流批一体能力的载体。中间的 Flink 基于开源社区版本深度定制。 而在流批一体模式下,开发模式变为了首先完成 SQL 的开发,其中包括逻辑的、物理的 DDL 的定义,以及它们之间的字段映射关系的指定,DML 的编写等,然后分别指定流批任务相关的配置,最后发布成流批两个任务 3.1 案例一 实时通用数据层 RDDM 流批一体化的建设。
❝每家数字化企业在目前遇到流批一体概念的时候,都会对这个概念抱有一些疑问,到底什么是流批一体?这个概念的来源?这个概念能为用户、开发人员以及企业带来什么样的好处?跟随着博主的理解和脑洞出发吧。 ❞ 前言 到底什么是流批一体? 批的来源?流的来源? 为什么要做流批一体? 从 数据开发的现状出发 探索理想中的流批一体能力支持 最终到数仓落地 go!!! ? ? ? ? ? ? ? n 年前的引擎能力(hive 等) 对文件、批量数据处理支持很友好 数据多是小时、天级别延迟 结论:批是在批式存储、处理引擎能力支持的角度提出的 ? ? 近几年的引擎能力(flink 等) 逐渐对流式数据处理、容错支持更好 数据可以做到秒、分钟级别延迟 结论:流是在流式存储、处理引擎能力支持的角度提出的 ? ? ? ? ? ? ? 博主理解的流批一体更多的是站在平台能力支持的角度上 所以这里重点说明引擎 + 工具链上的期望 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
数据湖可以汇集不同数据源(结构化、非结构化,离线批数据、实时流数据)和不同计算引擎(流计算引擎、批处理引擎,交互式分析引擎、机器学习引擎),是未来大数据的发展趋势,目前Hudi、Iceberg和DeltaLake 笔者基于对开源数据湖组件Hudi的研究和理解,思考在Iceberg、DeltaLake和Hudi等开源数据湖组件之上构建批流一体近实时数仓的可能性和思路。 03 批流一体 按照上述思路建设的近实时数仓同时还实现了批流一体:批量任务和流任务存储统一(通过Hudi/Iceberg/DeltaLake等湖组件存储在HDFS上)、计算统一(Flink/Spark作业 )、开发统一(Flink/Spark)、业务逻辑统一(同一套逻辑分为批和流)。 业务需求使用同一套加工逻辑开发代码,按照加工时效的粒度分为批和流两类加工,在统一的数据来源上在同一套计算环境分别进行批量和流式数据加工,四方面的统一保证批任务和流任务的数据结果一致性。
摘要:本文介绍了某零售企业用户基于 Dlink + FlinkSQL 构建批流一体数据平台的实践,主要为部署的分享。 地址 https://github.com/DataLinkDC/dlink 欢迎大家关注 Dlink 的发展~ 一、前言 由于公司需求,最近调研了很多的开源项目,最终发现 Dlink 在建立批流一体的数据平台上更满足需求 三.初始化数据库 在dlink根目录sql文件夹下有2个sql文件,分别是dlink.sql和dlink_history.sql。 #创建目录 cd /opt/dlink/ mkdir plugins 将Flink-shade-hadoop上传到到plugins文件目录下对于使用hadoop2 或者 hadoop 3 的均可使用 2.perjob和application模式推荐在生产使用,开启语句集,savepoint设置为最近一次。 3.local 不熟悉的话慎用,并不要执行流任务。
流批一体在 Shopee 的应用场景 2. 批处理能力的生产优化 3. 与离线生态的完全集成 4. 平台在流批一体上的建设和演进 Tips:点击「阅读原文」免费领取 5000CU*小时 Flink 云资源 01 流批一体在 Shopee 的应用场景 首先,先来了解一下 Flink 在 Shopee 上面介绍的都是 Shopee 内部流批一体应用场景的一些例子,我们内部还有很多团队也正在尝试 Flink 的流批一体,未来会使用的更广泛。 04 平台在流批一体上的建设和演进 最后我想介绍一下我们 Flink 平台在流批一体上的建设和演进。其实在上面介绍中,已经展示了不少平台的功能。 我们会加大 Flink 批任务的推广,探索更多流批一体的业务场景。同时跟社区一起,在合适的场景下,加速用户向 SQL 和流批一体的转型。
其中批处理用于检查流的有效性(lambda),或者我们需要将所有内容都考虑为流(kappa)。 但在战壕中,作为数据从业者,我们想要更多。 我们希望能够以简单的方式轻松整合现有企业数据源和高速/低延迟数据流。我们需要灵活地处理批处理 API 和流 API 以及无缝读取和写入它们的连接性。 从 CSA 1.4 开始,SSB 允许运行查询以连接和丰富来自有界和无界源的流。SSB 可以从 Kudu、Hive 和 JDBC 源加入以丰富流。随着时间的推移,我们将继续添加更多有界的源和接收器。 分布式实时数据仓库——通过物化视图将流数据作为事实与批量数据作为维度进行连接。例如,执行丰富的点击流分析,或将传感器数据与历史测量值结合起来。 例如,通过使用笔记本中 Python 模型的历史记录丰富行为流,为客户实时提供个性化体验。
- 随着大数据领域不断发展,企业对于业务场景的诉求也从离线的满足转到高实时性的要求,“t+0”形式呈现业务数据已是刚需。
基本语法为: table_name /*+ OPTIONS('k1'='v1', 'aa.bb.cc'='v2') */ OPTIONS 内的键值对会覆盖原表的 table options,用户可以在各种 例如: CREATE TABLE kafka_table1 (id BIGINT, name STRING, age INT) WITH (...); CREATE TABLE kafka_table2 /*+ OPTIONS('scan.startup.mode'='earliest-offset') */ t2 on t1.id = t2.id; -- override table options ;TableResult result = ss.execute(); tEnv.insertInto("sink1", table1)tEnv.insertInto("sink2", table2)tEnv.execute table/python/metrics.html 展望后续 在后续版本,易用性仍然是 Flink SQL 的核心主题,比如 schema 的易用性增强,Descriptor API 简化以及更丰富的流
流计算与批计算对比 数据时效性 流式计算实时、低延迟,流式计算适合以“t+0”的形式呈现业务数据; 批计算非实时、高延迟,批计算适合以“t+1”的形式呈现业务数据; 数据特征 流式计算数据一般是动态数据 ,数据是随时产生的; 批计算数据一般是静态数据,数据事先已经存储在各种介质中。 批计算应用在离线计算场景,如:数据分析、离线报表等。 运行方式 流式计算的任务是阻塞式的,一直持续运行中。 批计算的任务是一次性完成即结束。 ,然后将消息流与多个维表数据进行各种关联查询,最后输出融合查询结果集到目标源,常用在将多个维表数据与实时消息流关联后转换成一个大宽表的场景。 支持消息流数据传输过程中动态产生的数据与多种类型数据库之间的流计算查询。 融合查询语法遵循ANSI SQL标准。
性能较差 2. 架构优化升级 基于以上问题,我们在进行大量技术调研选型及POC之后,我们主要做了如下2部分大的架构优化升级。 2.2 Apache Hudi 我们需要有一种能够兼容S3存储之后,既支持大量数据的批处理又支持增加数据的流处理的数据湖解决方案。 从而实现流批一体架构而不是典型的Lambda架构。 2.我们现在有实时同步数据,离线rerun数据的场景,但当前使用的是Hudi 0.7.0版本,该版本还不支持多个job并发写Hudi表。 总结 我司基于Hudi实现流批一体数据湖架构上线生产环境已有半年多时间,在引入Hudi之后我们在以下各个方面都带来了一定收益: •成本: 引入Hudi数据湖方案之后,实现了S3数据增量查询和增量更新删除
二、流批一体到底是什么?要说流批一体,得先说说流批割裂的问题。 但在流批一体架构里:企业可以用同一套SQL或者代码定义计算逻辑。这样一来:不管是处理刚产生的实时数据(秒级延迟),还是回溯过去的历史数据(小时或天级延迟),逻辑都是一样的,结果自然也能对得上。2. 误区一:换个能同时支持流批的工具≠实现了流批一体有些企业觉得,只要把技术栈换成Flink这种能同时跑流和批的工具,就算实现流批一体了。 真正的流批一体,得从三个层面融合:数据模型层面,比如统一管理元数据;计算逻辑层面,比如用同一套SQL或代码;运维体系层面,比如统一监控告警。2. 流批一体架构得支持这种分层处理:四、大数据架构真的需要流批一体吗?回到开头的问题:大数据架构真的需要流批一体吗?我的答案是,不仅需要,而且会是未来3-5年企业数据架构的核心发展方向。为啥这么说?
由于Flink集成了批计算和流计算,因此可以使用Flink构建流批一体的系统架构,主要包含数据集成的流批一体架构、数仓架构的流批一体架构和数据湖的流批一体。 基于Flink流批一体整个数据集成的架构将不同。 在Flink流批一体架构的基础上,Flink CDC也是流批混合的,它可以先读取数据库全量数据同步到数仓中,然后自动切换到增量模式。 数据仓库的流批一体架构如下图所示。 视频讲解如下:三、数据湖的流批一体 Hive元数据的管理是性能的瓶颈,同时Hive也不支持数据的实时更新。Hive没有无法实现实时或者准实时化的数据处理能力。 数据湖存储与Flink结合,就可以将实时离线一体化的数仓架构演变成实时离线一体化的数据湖架构。数据湖的流批一体架构如下图所示。 视频讲解如下:
流批一体实时湖仓建设实践在具体展开之前,从结果导向出发,先明确下我们期望流批一体最后实现的效果是什么。从大的方面来说,大数据技术要回答的两个问题是:(1)海量数据如何存储?(2)海量数据如何计算? 这样底层明细数据是同一份(具体对应数仓中的DWD层),数据天然具备一致性,同时避免了在批处理层和流处理层使用两套不同存储系统带来的存储成本增加(2)计算层面流批一体,即我们写的同一套代码,只需要通过配置区分 流批一体实时湖仓”。 对于需求(1),我们需要用批处理保证结果的准确性,对于需求(2),我们需要用流处理保证结果的实时性。在流批一体实时湖仓架构下,我们会如下开发这两个需求的代码。 (2)计算层面流批一体,我们的批处理任务和流处理任务在主要计算逻辑上复用了同一份Flink SQL代码,只是在“统计时间窗口”的处理上略有不同,这也是需求所决定而避免不了的,从而不再需要开发两套代码在上述实践的过程中