手机如何创网站,品牌营销策划英文,seo排名关键词搜索结果,泰和县网站免费建站本文作者#xff1a;阿里云Flink SQL负责人#xff0c;伍翀#xff0c;Apache Flink PMC Member Committer 众多数据领域的专业人士都很熟悉Apache Flink#xff0c;它作为流式计算引擎#xff0c;流批一体#xff0c;其核心在于其强大的分布式流数据处理能力… 本文作者阿里云Flink SQL负责人伍翀Apache Flink PMC Member Committer 众多数据领域的专业人士都很熟悉Apache Flink它作为流式计算引擎流批一体其核心在于其强大的分布式流数据处理能力同时巧妙地融合了流计算与批计算的能力因此成为了众多企业在进行流式计算业务时的首选。
接下来本文将探讨Flink CDC与Apache Flink之间的关联与差异。更重要的是我们将如何巧妙地将Flink CDC与OceanBase数据库相结合构建一个实时数据仓库系统。 Flink CDC和Apache Flink是什么关系 从功能上来讲Flink在批处理能力外还能够实时读取数据源进行数据加工数据打宽和数据聚合以及下游的存储、分析、服务。Flink CDC是基于Flink流式计算引擎构建的一个实时数据同步和处理的框架。目前得益于日志变更技术Change Data CaptureFlink CDC已经支持了十来种常见的数据库比如MySQL、MongoDB、OceanBase等在将数据实时同步至数据仓库或数据湖时还能够实时进行数据加工、数据聚合、数据打宽等。 两个场景说明Flink CDC的由来 为什么会出现Flink CDC下面以两个场景举例说明。 场景一数据入仓。 传统的数据入仓方式我们要通过数据同步工具将数据同步到数仓中分析比如使用DataX对业务数据库进行以天为单位的定时全量数据同步但这种方式有几个比较明显的缺点。 首先全量数据同步可能会对在线业务造成一定影响其次天级别的产出可能无法满足下游业务的实时性需求。另外随着数据量的不断增长数据同步工具的性能瓶颈会越来越明显比如同步的延时以及对业务的影响。 很多应用方会在数据同步的基础上增设增量数据的同步也就是我们常说的Lambda架构常见的技术方案是采用Canal同步数据库增量数据到Kafka再通过其他的处理框架将数据实时同步到新的数据库如OceanBase。这种架构虽然减少了对在线业务的影响但引入了更多的组件使同步链路变得更长。同时手动管理全量和增量数据链路的切换也可能导致数据出现问题。 Flink CDC的出现很好地解决了上述问题它能够一体化地支持全量数据和增量数据的读取并且是在用户无感知的情况下自动发生的。在不影响业务稳定性的前提下保证了实时流式传输与毫秒级数据更新。对于全量数据和增量数据的切换Flink CDC能够保证数据的一致性用户不用再担心数据丢失的问题。另外从同步链路而言需要维护的组件更少降低了用户的维护成本与故障排查成本。 场景二ETL数据分析 传统的数据分析链路是把业务数据通过中间件同步到Canal再使用Kafka对数据进行加工、计算。这种方案难以保证数据的一致性其关键在于 Canal组件只支持同步增量数据不支持同步历史数据。而数据的聚合统计等分析操作如果没有历史数据支撑那么分析的结果也是有缺失的。 如果使用基于 Flink CDC 的 ETL 数据分析链路就可以用Flink CDC简单替换如Canal和Kafka的组件。例如我们现在需要将MySQL和 Postgres的表进行实时关联再写入OceanBase。我们只需要用Flink CDC写三段SQL一是定义MySQL实时订单表二是定义Postgres实时产品表三是定义Oceanbase结果表。然后用Flink的 Join 语法实时关联订单和产品数据并INSERT INTO 到OceanBase的结果表当中就完成了两张表的实时打宽和关联。整个过程实时地将MySQL和 Postgres的全量数据和增量数据读出来进行一致性关联后实时写入OceanBase。 Flink CDC的四个核心技术 上述两个场景中提到的功能涉及FlinkCDC四个核心技术
全增量一体化读取技术动态表Dynamic Table连续查询Continuous QueryChangelog Mechanism 1. 全增量一体化的读取技术。 旧版本Flink CDC的数据库变更读取能力是基于 Debezium 实现的。Debezium 是一个类似于 Canal 的捕获数据库变更数据的类库该类库提供了全量增量数据的一致性读取。但是该类库有两个核心问题。第一Debezium使用了数据库的全局锁来保证全量数据和增量数据的一致性但全局锁会导致数据无法写入对在线业务造成影响。第二Debezium只支持单并发读取当海量数据要入仓时耗时较长。如果全量数据同步失败还需要进行重新读取这会进一步拉长同步耗时。这非常影响系统的稳定性。 针对这些问题我们在2.0版本迭代时提出了增量快照读取算法。第一采用增量快照读取算法无需加锁就能保证全量数据到增量数据的一致性对业务影响降到最低。第二将大表切片切片之间可以并行读取大幅提升海量数据入仓效率。最后系统会追踪切片的读取进度支持按照切片的粒度进行失败回滚而无需全表重新读取提升了大规模数据同步场景的稳定性。 2. 动态表Dynamic Table。 在读取端将CDC数据读取进来后我们面对的问题是如何对它进行一致性的处理加工此处就涉及Flink CDC的第二个核心技术——动态表。 一枚硬币有两面数据库领域也是如此。动态表意味着数据会随着时间变化我们在观测动态表时表的所有变更都是数据流流和动态表是同一事物的二象性。我们将变更流物化就得到了一个动态表。我们去观测动态表上的变化就得到了一个变更流。 3. 连续查询Continuous Query。 连续查询和动态表是相辅相成的当我们在动态表上定义连续查询就会得到一个新的动态表。这从物理层面而言产生了一段持续的CDC的流这条流又可以通过下一个连续查询进行处理和加工再产生新的动态表从而编织起一个有分层的流式数仓。 4. Changelog Mechanism。 业界有很多支持流处理的框架但大多不支持处理CDC的数据关键原因在于缺乏完整的Changelog数据处理机制。 什么是Changelog数据处理机制举个例子现在有一个单词的数据源我们要对每个单词进行聚合并且对获取到的词频再进行聚合。比如单词是Hello和World经统计我们得到Hello出现一次World也出现一次那么词频为1的单词有两个即[cnt1, freq2]。这时数据源中又出现一个Hello那么Hello就出现了两次第一个聚合节点会输出一条Hello2的更新经过词频聚合后会输出词频为2的单词有1个即[cnt2, freq1]。但这是结果表中的[cnt1, freq2]是错误的。词频为1的单词少了一个Hello词频从2变成了1所以cnt2对应的freq应该为1才对。 因此我们引入数据处理机制修正错误结果最终得到正确结果[cnt1freq1]。当Hello的出现次数从一次变成两次我们会像传统数据库一样输出一个完整的更新前镜像和后镜像也就是先输出旧数据的撤回消息-[Helo, 1]再输出新数据的新增消息[Hello, 2]。撤回消息在到达聚合节点后就会对cnt1的 freq 做减一操作得到[cnt1, freq1]。新增消息会对cnt2的freq做加一操作得到[cnt2,freq1]。可以看到该结果与批处理的结果一致。通过这种方式能够保证CDC流处理语义的一致性。Changelog数据处理机制是保证 Streaming SQL 结果正确的关键机制不需要用户感知因为优化器会自动判断是否要输出和处理撤回消息update_before。 如何基于Flink CDC与OceanBase构建实时数仓 基于上文Flink CDC的四个核心能力结合OceanBase可以构建一个实时的数据仓库具体怎么做我们不妨先来了解传统的实时数仓方案。 传统的实时数据仓库基于流式队列方案构建我们称之为Streaming MQ方案是目前业界最典型、应用最广泛的方案。将MySQL的数据源同步到Kafka构建一个ODS数据层再进行数据打宽、数据清洗变为DWD的数据层然后进行聚合形成一个ADS数据层最后做数据加工放进KV层供下游进行消费查询。由于整个过程中数据不可被分析所以还会将数据同步到分析型数仓。 Streaming MQ方案的优势在于实践经验非常丰富层次分明每一个组件的分工明确。但它的劣势也比较明显比如链路复杂、数据冗余由于涉及组件较多排查问题时也非常困难。 因此我们开始尝试新的构建方案——Streaming OLAP方案既拥有流式队列的能力又具备OLAP的处理、分析、查询能力。这一方面基于Flink CDC的核心技术另一方面得益于OceanBase行列混存的HTAP特性可以在一套系统中支持交易处理和复杂查询分析的能力。 举个例子我们通过Flink CDC把MySQL的全量数据和增量数据同步到OceanBase形成一个ODS数据层供下游订阅。订阅的同时读取数据做加工和打宽然后写入下游的OceanBase形成DWD数据层通过聚合形成DWS数据层此时就可以为用户提供查询服务和消费提供。 Streaming OLAP方案的优势显而易见一是避免了Streaming MQ方案的数据冗余问题不需要再维护一个实时数仓数据可复用模型统一架构简单。二是简化了链路OceanBase替代了KV服务、分析服务、Kafka等组件。三是解决了排查困难的问题因为OceanBase每一层都是可查、可更新、可修正的比如某一层的数据出现问题可以直接排查该层的表数据并进行修正排查更高效。 该套实时数仓方案依赖于两项关键能力OceanBase的CDC读取能力、OceanBase的CDC写入能力。 1.OceanBase CDC读取的实现机制。 对于全量数据的同步因为OceanBase兼容MySQL所以我们可以基于JDBC完成全量数据的读取增量数据读取方面基于oblogproxy捕获binlog数据在数据源可以通过logproxy-client 订阅 oblogproxy 获取增量数据。因为OceanBase暂时不支持表锁也不支持行级的binlog位点所以在全量和增量切换时只能保证at-least-once读取。也就是说在切换的过程中会多读取数据不过Flink 会自动去重保证最终数据不重复、不丢失。 2.OceanBase CDC写入的实现机制。 由于OceanBase 兼容 MySQL 协议支持 MySQL 5.6和MySQL 5.7 的绝大多数语法因此在许多场景下可以将其视作 MySQL 使用比如作为 Flink 的目的端数据库可使用 flink-jdbc-connector 基于 MySQL 协议来写入支持插入、更新和删除。 OceanBase CDC的读取和写入将整个实时数仓多层之间的数据进行了流式串联。举个例子我们需要对订单明细表进行聚合写入DWS层的统计表中。获取每个店铺每天的销售量。只需要三段SQL就可以完成。 第一段命令是定义一个OceanBase CDC的数据源他是一个来自于orders的表有这样的一些字段。 第二使用FlinkCDC统计店铺销售额将JDBC的表写入OceanBase的表中形成了店铺指标的统计层。 第三段命令实时读取订单明细层dwd_orders的全量数据和增量数据并进行实时聚合、加工写入下游的OceanBase中dws_shops。该 dwd_shops 表又可以由另一个Flink进行读取再加工形成下一层的结果表。从而构建起整个流式数仓的分层概念。 Flink 与 Oceanbase 将全面集成 目前Flink与数据源之间的集成主要分成四个维度源表、维表、结果表、元数据。 在与OceanBase的集成中
源表支持全量数据的读取、增量数据的读取以及全增量一体化的读取下一步我们希望支持Exactly-Once 的读取。数据处理和加工过程中最常见的动作是数据补全和数据打宽在这方面OceanBase下一步可以作为维表供Flink远程查询。在结果表方面目前支持数据的实时写入和更新还有宽表Merge。下一步我们计划支持DDL的实时变更同步及整库的数据同步。在元数据方面OceanBase将对接Flink Catalog接口。用户填写OceanBase的地址及鉴权信息OceanBase所有的库表都可以进行实时写入和查询无需手动定义DDL。 通过这四个维度的集成Flink结合OceanBase可以打造一站式的实时数仓体验未来Flink希望与OceanBase更进一步进行全面集成。
