甘肃肃第八建设集团网站,wordpress 添加内链,网站设置反爬虫的主要原因,营销网站的案例分析当前企业实时同步与分析场景中面临的挑战#xff1a;
随着业务发展需要#xff0c;实时分析成为企业目前的强需求#xff0c;成为支撑企业业务发展的必须项。
一般来说#xff0c;要满足数据实时分析的诉求#xff0c;通常有两种方案#xff1a;
第一种是直接使用源端…当前企业实时同步与分析场景中面临的挑战
随着业务发展需要实时分析成为企业目前的强需求成为支撑企业业务发展的必须项。
一般来说要满足数据实时分析的诉求通常有两种方案
第一种是直接使用源端的业务数据库对接 BI 分析工具进行查询。
这种方式比较简单直接但存在两项弊端其一在数据量特别大的时候且业务复杂度高的情况下涉及到比较复杂的关系查询比如多表 join 查询性能会遇到瓶颈一条 SQL 可能需要很长的时间才返回满足不了实时分析的交互诉求其二从稳定性和安全性两个维度考虑在企业中业务数据库通常归属业务方一般不愿意被直接用于数据分析使用限制了数据分析团队去查询使用。
第二种是把数据库里的数据先同步到数仓中利用数仓高性能的查询能力来对接 BI 功能进行分析。
这个方案能很好解决上一个方案面临的两个问题其自身最大挑战在于数据新鲜度。把数据从数据库同步到数仓传统方式通常采用 T1 或 H1 的离线方式时效性是一天或一小时的延迟这样的数据新鲜度越来越不能满足业务对数据进行实时分析的时效性要求。后来演进出实时数仓架构支持把数据实时写入到数仓时效性和新鲜度会有极大提高但实时数仓中常驻的实时同步任务会使得成本会有极大增加且数据写入数仓后为了满足 BI 报表查询响应的要求往往还需要再增加额外的 OLAP 引擎来做查询加速会使得成本又进一步增加。
总结来说实时同步与分析主要面临数据导入和分析在数据数据新鲜度和整体成本上的两个挑战。
云器Lakehouse简介
云器作为新一代数据平台的提供商为企业提供了一体化 DataAI 的整体解决方案。云器Lakehouse平台提供以下两大方面的核心产品能力
Single-Engine引擎可以统一批处理、流处理和交互分析全场景的作业负载诉求。一站式数据平台丰富的配套产品功能预置数据相关常用服务如数据同步、开发构建、运维监控、资产管理、数据质量等。
基于此形成一整套解决方案可以用一个引擎处理结构化和非结构化数据类型、不同的处理分析负载满足企业在数据构建方面全方位的诉求让数据处理更高效、更实时。 图1云器Singe-Engine引擎方案
在云器Lakehouse的实时同步和实时分析解决方案中支持源端多种数据源接入如MySQL、PgSQL、SQL Server 等。基于实时同步写入到数仓里的同一份数据可同时支撑 BI 报表进行实时查询。基于一个引擎Single-Engine一份数据从源端同步写入再支撑目标消费不再需要传统方案中额外新增的 OLAP 加速引擎可以简化整体架构进而极大地节约成本。 图2云器Lakehouse支持主流数据库接入
实时任务演示
下面用一个具体例子演示云器Lakehouse是怎样去应对源端的复杂挑战将数据实时同步并支持实时分析查询。
演示背景
本次演示中源端准备了四张各有 100 万行数据的表计划将这 400 万行数据同步到目标里。源端数据在 MySQL 的 RDS 数据库内采取分库分表的结构数据存在不同的分表通过云器的实时同步方案把数据同步进云器Lakehouse直接使用 BI 报表进行查询分析。 图3演示数据流程
本演示以常见的 SaaS 服务模式为例多租模式下其底层业务数据库中某些租户的信息会存在同一张分表内分表下包含租户定制的扩展字段即源端是基本相同的四张分表但部分表的字段存在细微差异如下图所示yellow_taxi_02 表包含扩展字段 2 。 图4演示表结构示意
实时同步任务配置
下面开始进入云器Lakehouse产品中为大家演示超大规模数据是如何实时同步并进行实时查询分析的。
多表异构同步配置
首先在云器Lakehouse任务开发里新建多表实时同步任务选择 MySQL 数据源。云器提供两类数据同步模式
第一类多表镜像把源端的数据表原原本本地镜像同步到数据仓库里。第二类是多表合并也是本次演示所中用到的场景。在源端数据量特别大、有分库分表场景的情况下同步过程中需要提前把需要 ETL 处理的 transform 过程完成多张表合并写入到同一张表中这样在后续查询中不需要再进行多表join为查询提速。
之后再选择存储了源端连接串信息的数据源。如下图 图5在云器Lakehouse中创建实时任务
接下来配置需要同步的对象。云器提供了丰富的过滤规则来筛选源端表比如命名的精确匹配、正则匹配等可以按需使用。在源端表字段存在不一致的情况下Lakehouse实时同步会自动检测识别提示用户开启异构表合并同步功能。异构表合并同步功能作用是在目标端的表中取源端表字段的并集进行建表确保源端所有的数据能被同步写入到目标端。 图6配置目标表
配置完成后可以对具体的表的字段进行预览检查确保扩展字段也被添加进来保证数据一致。 图7检查具体字段
如果使用镜像同步模式来代替多表合并模式会把源端表的结构完整映射到目标表上但还需要再进行 ETL 的处理加工、产出一张新的合并后的表供BI查询。增加表也附带增加了一个处理链路提升复杂度的同时会使得端到端的整个链路更长数据新鲜度和时效性会大打折扣成本也会提升。
通过扩展字段作为联合主键确保合并过程中数据不丢失
接下来看一个更复杂的情况前面提到源端数据是采用分表的方式存储但业务上常常会遇到一种情况同样一个主键字段在不同分表之间的数据会出现重复。
本次演示数据中也模拟设计了类似情况在源端两张表里去查询 ID 可以看到同样的主键 ID 取值在不同的表里分别会有一条记录这会给同步过程带来了挑战在合并写入到目标端时如果是只按 ID 作为主键这两条记录就会被尝试写入到一条记录中会产生数据冲突的情况。两条源端的记录依据先后顺序后到的源端表中的数据被把先到的源端表中的数据给覆盖掉。 图8同一字段在不同分表间的记录对比
面对这种情况Lakehouse 实时同步方案中提供了扩展字段的能力来保证数据准确性。通过标识源端数据来源比如将 server 、databasename 、 tablename 等字段设置为联合主键后那么这两条数据在目标端会被当成两条记录来对待。通过这种方式保证在即使源端出现分表中主键数据有重复的复杂情况下源端数据也能被准确地同步到目标端。 图9云器Lakehouse扩展字段功能
下一步在目标配置里选择数据源、目标数据源及计算集群。 图10目标表配置
接下来可以在映射关系中预览同步的字段配置可以看到扩展字段包含在内新增组件/联合主键也在这里有所体现。 图11预览目标表字段
云器Lakehouse实时同步中也提供了丰富同步规则策略用来动态适配源端数据库的变更Schema Evelution比如源端表删除、新增字段等情况下的应对策略。 图12配置同步规则
到这里整个同步任务就配置完成只需要简单五步选择数据源、圈定源端同步对象、设置高阶属性、选定目标端设定同步策略。
启动数据实时同步
云器Lakehouse提供了开发环境和生产环境两种模式要将该任务在生产环境运行起来需要先将其发布提交然后在运维中心再启动该任务。
任务启动时可以根据实际需求选择是否进行全量数据同步。首次同步的数据通常建议选择做一次全量数据同步然后再进行增量数据同步。 图13启动任务
我们可以通过BI报表来检查源端数据库的数据情况源端总共四张表各有 100 万行数据需要把这 400 万行数据同步到目标表里。在前面配置过程中可以看到每张表有20 多个字段而且字段类型大部分是 String 类型单条记录的size不算小是比较贴合真实生产上的业务数据库的情况。 图14源端数据的 BI 报表
在运维界面中可以看到任务正在全量同步阶段数据已经写入 200 万行速率在 25, 000 行/秒。 图15任务状态监控
特别的在云器Lakehouse的实时同步任务中仅需要在第一次启动时对源端做一次全量同步在此基础上根据源端的数据变更再进行增量同步。而且全量同步环节完成后无需手动更改任务会自动转入增量同步环节。
云器Lakehouse还提供数据资产管理的产品模块可以实时检查目标表的数据量的情况全量同步完成后可以看到目标端的数据条数和源端完全一致为400万行。 图16数据详情
数据变更
在实际应用中经常会出现因为业务需要使得源端数据库的表和结构出现变化的情况如源端表增加了字段删除了字段、或者字段的类型变化了。对于这类情况Lakehouse的实时同步也提供了对应的解决办法。
云器Lakehouse产品支持直接操纵源端数据库通过 SQL 来对源端数据库进行修改、查询等操作首先我们对源端数据进行变更先在源端添加一些新的字段ext_column_0 ext_column_1并在源端表里删掉一个字段同时更改一个字段类型从 int 改为 bigint 。 图17通过 SQL 调整源端表
接下来可以在监控页面中看到源端的数据变更已经被同步过来进行消费基于在同步任务中配置的Schema Evelution规则自动更新无需手动操作进行其它额外配置、或者重启任务这样能确保整个同步链路平滑运行。 图18监控运维界面
同步完成后也可以在任务运维界面中检查源端的变更是否被成功同步到目标端可以看到新增的字段 ext_column_0 ext_column_1已经被扩展进目标端更改的 bigint 字段也完成变更。 图19检查变更后数据
实时查询
在传统的离线数仓中数据进来做完 ETL 的各种处理加工后直接对接 BI 引擎查询会很慢所以通常会采用一些实时分析引擎比如 Clickhouse 等再做查询加速。但在云器的方案中完全不需要源端表能够被实时写入也能够被实时查询以及通过批处理加工后被实时查询分析。
下图为本次DEMO的 BI 报表示意展示源端 MySQL 数据行数的统计目标端是云器 Lakehouse 内的数据行数并做了一个复杂查询分析按照不同的乘客数量统计费用的平均值。实时同步写入的表跟查询的表是同一张表。
在下图分析看板是基于 Metabase 工具构建 图20BI 报表
云器产品里提供了作业历史产品模块可以看到提交给引擎的所有 SQL 明细。从下图中可以看到实时同步写入的是 yellow_taxi_demo 表在Metabase BI 看板里实时查询的也是该表。而且在演示的这个相对复杂的查询条件下进行了400万行数据的全表扫描能在 10 毫秒左右返回查询结果。云器Lakehouse的方案不需要新增额外的加速引擎来进行查询加速也省去了再同步复制一份数据所以能够极大地节约成本。 图21作业历史界面
我们接下来看下高并发下的查询响应情况。云器Lakehouse 采用存算分离架构在查询计算层面通过不同集群类型来支撑不同的查询负载
通用型集群面向批处理进行了针对性的优化。分析型集群对于在线的实时分查询非常友好。
云器也提供良好的资源弹性能力可以设定不同集群规格和弹性伸缩方式可以配置查询的并发数以及实例的副本个数来实现动态伸缩。比如源端有 8 个并发时只需要 1 个查询实例通过弹性设置为 2 个副本当并发数超过 8 个时系统会自动拉起扩容出第 2 个副本来承接超过 8 个以上的并发流量整个过程完全不需要人为干预。
此外云器Lakehouse还提供自动启停的功能整个产品的资源收费模型上在SaaS模式下采取按量付费的模式比如对于 BI 报表在夜间没有使用、没有流量时集群会被自动停止就会产生费用能避免资源的空置浪费、节约成本费用。 图22集群创建
稳定性和监控
实时同步和分析链路搭建完成后对于企业来讲最关心的问题之一就是整个链路的稳定性。
云器Lakehouse通过监控和告警的产品模块可以为整个同步链路的稳定性提供保障。云器Lakehouse为每个同步任务提供完善的监控信息展示比如同步状态、同步延迟等。面向同步链路里可能会发生的异常情况比如单条数据写入时发生异常、导致任务失败实时同步方案中也提供了任务的自动 Failover 能力任务失败以后会被自动拉起减少人为运维处理的投入。 图23指标监控界面
云器Lakehouse内置监控告警模块内置了丰富的状态和指标监控能力支持自定义配置监控规则来全面监控整个任务运行的状态包括任务实例运行失败、单表存量数据同步异常、实时同步任务端到端延迟、作业 failover 、源端数据读取的点位延迟等等一系列的监控事项都可以通过规则监控起来。 图24监控告警规则
本次演示中配置了一些监控规则可以看到下图告警通知会监控端到端同步的延迟是否超过了 10 秒在数量特别大时延迟上去会被监控捕获到并通过告警通知提醒负责人感知并及时处理。 图25监控告警界面
任务运维处置
在实际生产过程中经常会遇到各种各样的复杂问题为此云器实时同步方案中也提供了多种配套运维处置功能来进行支持。
例如在实时同步运行中源端数据发生了变化某个表中的数据出现了问题针对这种情况我们提供补数同步功能支持对特定表重新进行全量同步。在业务突发高峰源端变更流量非常大时多个表的变更数据的实时同步会相互影响。这两种情况下都可以通过全量补数同步的功能去加速数据同步过程。以下图为例对源端表 yellow_taxi_00 表重新进行补数全量同步其增量实时同步会被暂停后台会通过全量的方式把源端数据重新同步。补数修订的全量同步完成后增量同步会自动启动无需再手动操作。 图26补数同步功能 图27自动切换同步状态
此外云器Lakehouse还为日常运维提供优先执行功能当在有多张表需要同步而资源相对有限的条件下可选择业务上更重要的表优先分配资源在任务队列里面优先执行该表的数据同步可以在任务整体出现消费堆积、端到端延迟变大的情况下也能保证业务关键数据的新鲜度。 图28日常运维功能
性能与成本
性能和成本也是企业目前比较关注的问题在不考虑产品性能的情况下单独讨论成本是不合理的。企业在追求数据新鲜度时可能会面临成本的大幅增加如果优先考虑成本可能会牺牲数据同步和查询的性能导致数据新鲜度不足对此云器Lakehouse的解决方案希望能将性能与成本之间的平衡控制权交给企业。
对于企业来说业务上最开始构建时可能 t1 的时效性已经能满足业务初始启动使用的诉求但随着业务发展会需要越来越新鲜的数据如 h1 或者 m1 。
为此云器Lakehouse可以灵活地配置调度周期比如可以从每周执行调整为每天执行从每天执行一次改为执行多次调度频次也支持灵活设定间隔最小支持 1 分钟这是传统批处理的方式。 图29调度配置界面
云器Lakehouse 也提供了更高阶的产品特性Dynamic Table 其核心要点是可以只计算变化的数据来代替传统的批处理中的全量计算并内置刷新周期可以根据业务需要灵活调整。比如将 Dynamic Table 的刷新周期设置一个小时它可以根据源端的数据变化在一个小时内刷新一次更新表的数据计算结果供下游使用。如果业务诉求的新鲜度变得更高时只需把 Dynamic Table 的数据刷新频次调整的更高就可以实现数据新鲜度的“无级调速”。
上文也提到在计算集群规格上云器Lakehouse也支持灵活调整。当数据新鲜度刷新周期变得更高时每小批处理的数据量相应会变小可以使用相对来说更小的集群规格来满足数据处理的要求也能进一步节约成本。通过这样的灵活变化能够找到数据新鲜度和成本的一个精益平衡。
总结来说企业通常选择批处理都是因为其成本低代价是它的数据新鲜度不高。云器Lakehouse提供的的处理方式既能降低成本还解决了数据时效性的问题。或者反过来说以前企业为了高时效性可能就不控成本了但今天云器提供的这种方式在选择最适合的数据新鲜度和刷新周期下能获得很好的平衡。
云器服务了国内一家 CRM 行业的头部客户基于上述的实时同步和查询方案从整个源端的实时同步到后续的实时处理分析对照下来相比国内的头部云厂商的主流方案整个成本上能够节约 50% 以上。
了解更多请点击销售易基于Lakehouse的实时分析提升用户数据体验实践分享
总结
云器Lakehouse基于一站式产品能力提供了面向实时同步和实时分析场景的解决方案应对源端数据库的复杂情况。产品支持对接MySQL、 PGSQL、SQLServer 等各种数据源满足源端数据库存在异构情况下的同步要求提供相对完善的高性能同步能力和完善的配套运维监控能力保障数据的稳定生产。在成本方面云器相比头部云厂商的传统同步方案能够做到 50% 以上的整体成本节约。性能方面具备更低的端到端的同步延迟通常情况下可以做到 20 秒之内以及更快的分析查询响应的速度在复杂的情况下能够做到 10 毫秒的查询相应速度。
基于云器Lakehouse的产品能力可以为企业提供更好的数据新鲜度让业务决策快人一步在竞争中处于领先位置。
