低延迟实时湖仓数据集成和高性能实时分析
本文档会介绍基于云器Lakehouse构建高稳定低延迟的实时湖仓数据集成方案和基于同一份湖仓数据的高性能实时分析两部分内容。
概述
随着企业业务的扩展，实时数据分析变得至关重要，它不仅是业务决策的支撑点，也是推动企业发展的必备条件。为了实现数据的实时分析，企业通常面临两种技术方案选择：
- 直接利用业务数据库进行BI分析：这种方法操作简便，能够快速实施。然而，它在处理大规模数据和复杂查询时会遇到性能瓶颈，特别是在需要执行多表连接等复杂操作时，查询响应时间会显著延长，无法满足实时分析的需求。此外，出于对稳定性和安全性的考虑，业务数据库通常不允许直接用于数据分析，这限制了数据分析团队的操作空间。
- 基于数据仓库的BI分析方案：该方案通过将数据从业务数据库同步到数据仓库，利用数据仓库的高性能处理能力来支持BI分析。这种方法有效解决了性能问题，但最大的挑战在于数据的实时性。传统的数据同步通常是T+1或H+1的批处理模式，无法满足业务对数据实时性的需求，往往还需要部署额外的OLAP引擎，这进一步增加了成本。
云器Lakehouse提供了一种高稳定性、低延迟的实时湖仓数据集成解决方案，它能够实现从多种源端数据源（如MySQL、PostgreSQL、SQL Server等）的实时数据同步，并直接支持BI报表的实时查询。这种方案通过在数仓中维护同一份数据，既支持数据的实时写入，也支持BI报表的实时查询，消除了传统方案中需要额外部署OLAP引擎的需求。这样的设计简化了数据架构，降低了成本，同时确保了数据的实时性和查询效率，为企业提供了一种既经济又高效的实时数据分析解决方案。
实时湖仓数据集成
此部分会展开介绍产品化的实时湖仓集成方案，如何便捷地将海量库表数据同步进入到Lakehouse湖仓。
场景和数据描述
本演示实践中，在源端MySQL数据库准备了四张各有 100 万行数据的表，计划将这 400 万行数据同步到目标云器Lakehouse的表中，然后直接使用 BI 报表进行查询分析。
本演示以常见的 SaaS 服务模式为例，在多租模式下，数据库采取分库分表的结构，数据存在不同的分表；某些租户的信息会存在同一张分表内，且不同分表中包含特定租户的定制扩展字段，即源端是基本相同的四张分表，但部分表的字段存在细微差异，如下图所示，yellow_taxi_02 表，相比yellow_taxi_00表，多出了一个扩展字段 ext_columm_2 。
前置准备：数据源配置
导航到管理 -> 数据源，单击”新建数据源“并选择MySQL，即可创建本案例中所需的数据源。填写必须的配置信息，尤其请注意选择正确的数据库所在时区，实时同步对时区敏感，配置错误会使得同步失败。
源端数据库的权限等高阶配置，可以参考此文档。
实时同步任务的配置
首先在任务开发里点击新建”多表实时同步任务“，选择正确的源端数据源类型，比如 MySQL。
实时同步任务提供两类数据同步模式：
- 第一类：多表镜像同步，把源端的数据表，原原本本地镜像同步到目标端。
- 第二类：多表合并同步，支持把源端多张表合并写入到目标端同一张表中，这也是本实践中用到的场景。源端数据量大、有分库分表的场景下，同步过程中把多张表合并写入到同一张表，在后续查询中就不再需要再进行多表JOIN、可以为查询提速。
选择好同步模式之后，选择存储了源端连接串信息的数据源，如下图所示：
接下来配置需要同步的数据对象。产品内提供了丰富的过滤规则来筛选源端表，比如命名的精确匹配、正则匹配等，可以按需使用。在源端表字段存在不一致的情况下，系统会自动检测进行识别、提示开启异构表合并同步功能。异构表合并同步功能作用是在目标端的表中，取源端表字段的并集进行建表，确保源端所有的数据能被同步写入到目标端。
配置完成后可以对具体的表的字段进行预览检查，确保扩展字段也被添加进来，保证数据一致。
如果使用镜像同步模式来代替多表合并模式，会把源端表的结构完整映射到目标表上，但还需要再进行 ETL 的处理加工、产出一张新的合并后的表供BI查询。增加表，也附带增加了一个处理链路，提升复杂度的同时会使得端到端的整个链路更长，数据新鲜度和时效性会大打折扣，成本也会提升。
上文提到源端数据是采用分库分表的方式存储数据，但常常会遇到一种更复杂的情况：源端主键字段相同的取值的记录，在不同分表中的数据会出现重复。本示例中的数据也模拟设计了类似情况，在源端两张表同样的主键 ID 取值，在不同的表里分别会有一条记录，这会给同步过程带来了挑战：在合并写入到目标端时，如果是只按 ID 作为主键，这两条记录就会被尝试写入到一条记录中，会产生数据冲突的情况，两条源端的记录依据先后顺序被处理，后到的源端表中的数据被把先到的源端表中的数据给覆盖掉。面对这种情况，Lakehouse 实时同步方案中，提供了扩展字段的能力，来保证数据准确性。通过标识源端数据来源，比如将 server、databasename、 tablename 等字段设置为联合主键后，这两条数据在目标端会被当成两条记录来对待。通过这种方式，保证在即使源端出现分表中主键数据有重复的复杂情况下，源端数据也能被准确地同步到目标端。
完成上述配置后，下一步在“目标配置”里设定目标数据源类型、数据源名称等配置项。
接下来可以在映射关系中预览同步的字段配置，可以看到扩展字段包含在内，扩展字段/联合主键也在这里有所体现。
云器Lakehouse实时同步中，也提供了丰富同步规则策略，用来动态适配源端数据库的变更（Schema Evelution），比如源端表删除、新增字段等情况下的应对策略，以及需要处理的源端变更消息类型等。
到这里，整个实时同步任务就已经配置完成，只需要简单四步：选择数据源、圈定源端同步对象、选定目标端，设定同步策略。
提交并启动数据实时同步
云器Lakehouse提供了开发环境和生产环境两种模式，要将该任务在生产环境运行起来，需要先将其发布提交，然后在运维中心启动该任务。
-
提交多表实时同步任务
-
运维多表实时同步任务
-
启动多表实时同步任务：启动时，可以根据实际需求，选择是否进行全量数据同步。首次同步的数据，通常建议选择做一次全量数据同步，然后再进行增量数据同步。
任务启动后，在运维界面中，可以看到任务会进入全量同步阶段，数据已经写入 200 万行，速率在 25, 000+ 行/秒。
特别地，多表实时同步任务仅需要在第一次启动时对源端做一次全量同步，全量同步完成后，无需手动更改，任务会自动转入增量同步环节，保持数据的无缝衔接。
验证数据变更的同步效果
在实际应用中，经常会出现因为业务需要使得源端数据库的表和结构出现变化的情况，如源端表增加了字段，删除了字段、或者字段的类型变化了。对于这类情况，Lakehouse的实时同步也提供了对应的解决办法。
云器Lakehouse产品支持直接操纵源端数据库，通过 SQL 来对源端数据库进行修改、查询等操作，首先我们对源端数据进行变更，先在源端添加一些新的字段：ext_column_0 & ext_column_1，并在源端表里删掉一个字段，同时更改一个字段类型从 int 改为 bigint 。
接下来可以在监控页面中看到，源端的数据变更已经被同步过来进行消费，基于在同步任务中配置的Schema Evelution规则，自动更新，无需手动操作进行其它额外配置、或者重启任务，这样能确保整个同步链路平滑运行。
同步完成后，也可以在任务运维界面中检查源端的变更是否被成功同步到目标端，可以看到，新增的字段 ext_column_0 & ext_column_1已经被扩展进目标端，更改的 bigint 字段也完成变更。
实时同步任务的稳定性和指标监控
实时同步和分析链路搭建完成后，最关心的问题之一就是整个链路的稳定性。我们的产品中，为每个多表同步任务提供了完善的监控信息展示，比如同步状态、同步延迟等。面向同步链路里可能会发生的异常情况，比如单条数据写入时发生异常导致任务失败，也提供了任务的自动 Failover 能力，任务失败以后会被自动拉起，减少人为运维处理的投入。
云器Lakehouse提供了监控告警产品模块，内置了丰富的状态和指标监控能力，支持自定义配置监控规则，来全面监控整个任务运行的状态，包括任务实例运行失败、单表存量数据同步异常、实时同步任务端到端延迟、作业 failover 、源端数据读取的点位延迟等等，一系列的监控事项，都可以通过配置对应的规则给监控起来。
本次实践演示中，配置了一些监控规则，可以看到下图告警通知，会监控端到端同步的延迟是否超过了 10 秒，在数量特别大时，延迟上去，会被监控捕获到，并通过告警通知提醒负责人感知并及时处理。
实时同步任务的运维处置
在实际生产过程中，经常会遇到各种各样的复杂问题，为此云器实时同步方案中也提供了多种配套运维处置功能来进行支持。例如在实时同步运行中，源端数据发生了变化，某个表中的数据出现了问题，针对这种情况，我们提供补数同步功能，支持对特定表重新进行全量同步。在业务突发高峰，源端变更流量非常大时，多个表的变更数据的实时同步会相互影响。这两种情况下，都可以通过全量补数同步的功能去加速数据同步过程。以下图为例，对源端表 yellow_taxi_00 表重新进行补数全量同步，其增量实时同步会被暂停，后台会通过全量的方式把源端数据重新同步。补数修订的全量同步完成后，增量同步会自动启动，无需再手动操作。
此外，云器Lakehouse还为日常运维提供优先执行功能，当在有多张表需要同步，而资源相对有限的条件下，可选择业务上更重要的表优先分配资源，在任务队列里面优先执行该表的数据同步，可以在任务整体出现消费堆积、端到端延迟变大的情况下，也能保证业务关键数据的新鲜度。
高性能实时分析
在传统离线数仓架构中，数据经过ETL处理后直接对接BI引擎进行查询，往往响应速度较慢。因此，企业通常会引入如Clickhouse等实时分析引擎来提升查询性能。云器科技的解决方案通过简化这一流程，实现了源端数据的实时写入与目标表的即时查询分析，无需额外的查询加速引擎。
在本次演示中，我们利用Metabase BI工具构建的报表展示了源端MySQL数据行数统计与云器Lakehouse内数据行数的对比，并进行了复杂查询分析，如根据不同乘客数量统计费用的平均值。这一过程中，数据的实时同步写入与查询分析均在同一张表上完成，云器方案在简化架构和提升效率方面优势明显。
通过产品中提供的“作业历史”产品模块，可以看到提交到Lakehouse引擎的所有 SQL 明细。从下图中可以看到，实时同步写入的是 yellow_taxi_demo 表，在Metabase BI 看板里实时查询的也是该表。而且在演示的这个相对复杂的查询条件下，进行了400万行数据的全表扫描，能在 11 毫秒就返回查询结果。云器Lakehouse的方案不需要新增额外的加速引擎来进行查询加速，省去了再同步复制一份数据，所以能够极大地节约整体成本。
我们接下来看下高并发下的查询响应情况。云器Lakehouse 采用存算分离架构，在查询计算层面，通过不同集群类型来支撑不同的查询负载：
- 通用型集群，面向批处理进行了针对性的优化。
- 分析型集群，对于在线的实时分查询非常友好。
云器也提供优秀的资源弹性能力，可以设定不同集群规格和弹性伸缩方式，可以配置查询的并发数以及实例的副本个数来实现动态伸缩。比如源端有 8 个并发时，只需要 1 个查询实例，通过弹性设置为 2 个副本，当并发数超过 8 个时，系统会自动拉起扩容出第 2 个副本来承接超过 8 个以上的并发流量，整个过程完全不需要人为干预。
此外，云器Lakehouse还提供自动启停的功能，整个产品的资源收费模型上，在SaaS模式下采取按量付费的模式，比如对于 BI 报表，在夜间没有使用、没有流量时，集群会被自动停止，就会产生费用，能避免资源的空置浪费、节约成本费用。
总结
云器Lakehouse基于一站式产品能力，提供了面向实时同步和实时分析场景的解决方案，应对源端数据库的复杂情况。产品支持对接MySQL、 PostgresSQL、SQLServer 等各种数据源，满足源端数据库存在异构情况下的同步要求，提供相对完善的高性能同步能力，和完善的配套运维监控能力保障数据的稳定生产。在成本方面，云器相比头部云厂商的传统同步方案，能够做到 50% 以上的整体成本节约。性能方面，具备更低的端到端的同步延迟，通常情况下可以做到 20 秒之内；以及更快的分析查询响应的速度，比如在较为复杂的查询SQL，也能够做到 10 毫秒的查询响应速度。基于云器Lakehouse的产品能力，可以为企业提供更好的数据新鲜度，让业务决策快人一步，在竞争中处于领先位置。
附录
关于多表实时同步功能的更详细的使用细节指南，请参考此帮助文档。