高效易用的数据同步:阿里云瑶池 Zero-ETL服务来啦!

简介: 在大数据时代,企业有着大量分散在不同系统和平台上的业务数据。OLTP数据库不擅长复杂数据查询,不具备全局分析视角等能力,而OLAP数据仓库擅长多表join,可实现多源汇集,因此需要将TP数据库的数据同步到AP数据仓库进行分析处理。传统的ETL流程面临资源成本高、系统复杂度增加、数据实时性降低等挑战。为了解决这些问题,阿里云瑶池数据库提供了Zero-ETL服务,可以快速构建业务系统(OLTP)和数据仓库(OLAP)之间的数据同步链路,将业务系统的数据自动进行提取并加载到数据仓库,从而一站式完成数据同步和管理,实现事务处理和数据分析一体化,帮助客户专注于数据分析业务。

导读

在大数据时代,企业有着大量分散在不同系统和平台上的业务数据。OLTP数据库不擅长复杂数据查询,不具备全局分析视角等能力,而OLAP数据仓库擅长多表join,可实现多源汇集,因此需要将TP数据库的数据同步到AP数据仓库进行分析处理。传统的ETL流程面临资源成本高、系统复杂度增加、数据实时性降低等挑战。为了解决这些问题,阿里云瑶池数据库提供了Zero-ETL服务,可以快速构建业务系统(OLTP)和数据仓库(OLAP)之间的数据同步链路,将业务系统的数据自动进行提取并加载到数据仓库,从而一站式完成数据同步和管理,实现事务处理和数据分析一体化,帮助客户专注于数据分析业务。

OLTP数据库跑“分析”的痛点

OLTP是传统的关系型数据库的主要应用,擅长基本日常的事务处理,例如银行交易等。但是OLTP数据库不擅长复杂数据查询,不具备全局分析视角等能力,具体的痛点为:

  1. 负载无法隔离:AP分析业务对于资源的消耗,会影响TP在线业务,导致响应变长。
  2. 无法全局分析:业务数据通过分库分表(比如游戏行业按照区服)的方式存在不同TP数据库实例内,无法分析全部游戏玩家的行为。
  3. 无法复杂分析:分析业务通常需要多表JOIN关联,挖掘数据之间的关系。但TP架构并不适合做复杂分析,容易卡住。

OLAP如何解决以上痛点

OLAP数据库支持复杂的分析操作,擅长多表join,可实现多源汇集,侧重决策支持,并且提供直观易懂的查询结果,可以很好地解决OLTP数据库跑分析时的痛点:

  • 资源隔离:AP系统和TP系统在资源层面完全隔离,分析业务对在线业务0影响。
  • 多库合并:分库分表后多个TP数据库实例的数据,可以在数据同步过程中进行多库合并,将所有数据都放到一个AP数据仓库实例中进行全局分析。
  • 并行计算:AP数据仓库,采用MPP并行计算架构,可以把一个复杂大查询拆分成若干个小查询。

同时,OLAP数据库内置常用分析函数 ,能够高效挖掘数据价值

  • 漏斗分析函数:漏斗分析是一种分析用户在行为流中指定步骤转化情况的分析模型,它可以帮助分析师快速掌握一段时间内产品在各个步骤环节中的转化情况,从而达到查缺补漏,优化转化流程的目的。
  • 留存分析函数:留存分析主要分析用户的整体参与程度、活跃程度的情况,考查进行某项初始行为的用户中,会进行回访行为的人数和比例。
  • 路径分析函数:路径分析是一种分析行为顺序、行为偏好、关键节点、转化效率的探索型模型。

因此,为了对数据进行有效分析、提高企业决策效率,我们需要将数据从OLTP数据库同步至OLAP数据仓库。

image.png


传统数据同步的挑战

提到数据同步就不得不提“ETL”。ETL 是将上层业务系统的数据经过提取(Extract)、转换清洗(Transform)、加载(Load)到数据仓库的处理过程,目的是将上游分散、凌乱的数据整合到目标端数仓,通过在数仓中做进一步的计算分析,来为业务做有效的商业决策。

想象一下,你网购了一些商品,这些商品需要从卖家手中经过若干个环节最终送达到你的手里。传统的快递流程就像是ETL过程:首先,货物需要从卖家处提取(Extract),然后根据需要进行包装转换(Transform),最后通过物流送到买家手中(Load)。这个过程中包含了多个步骤,既耗时又增加了货物出错或者延迟到达的风险。传统ETL流程也有如下缺点:

  1. 资源成本增加:不同的数据源可能需要不同的ETL工具,搭建ETL链路会产生额外的资源成本
  2. 系统复杂度增加:用户需要自行维护ETL工具,增加了运维难度,无法专注于业务应用的开发
  3. 数据实时性降低:部分ETL流程涉及周期性的批量更新,在近实时的应用场景中,无法做到快速产出分析结果。

每当启动一个新的数据项目,都会引发一系列复杂的ETL任务,这些任务仿佛是资源消耗的无底洞,不断消耗着项目团队的精力与资源。

此外,传统数据同步链路开销较大,并且配置困难,眼花缭乱的源库和目标库、大而全带来的复杂配置、手动填写账密信息、手动指定目标表的主键/分布键等等使传统数据同步过程耗时且效率低下。

Zero-ETL服务诞生

传统的数据同步过程繁琐复杂,但是没关系,Zero-ETL服务已经诞生,来拯救“怕麻烦”的你啦!让你轻松完成一站式数据同步和管理,实现事务处理和数据分析一体化。

那么,什么是Zero-ETL呢?回到刚刚那个场景,Zero-ETL就好比是一种“即时送达”的闪送服务。你下单之后,商品就会从卖家那里快速送到你的手中,中间不需要其他繁琐的处理步骤。

在数据处理领域,Zero-ETL可以减少在不同服务间手动迁移或转换数据的工作,降低ETL的成本和复杂度,让用户不需要开发和关注ETL流程,专注于上层的应用开发和数据分析。无论企业和数据的规模有多大,复杂度有多高,通过为客户消除 ETL 和其它数据迁移任务,助力客户专注于分析数据,面向业务获取新的洞察。

阿里云瑶池提供的Zero-ETL服务

为了解决传统数据同步带来的挑战,阿里云瑶池数据库提供了全新Zero-ETL服务,免费帮你快速构建业务系统(OLTP)和数据仓库(OLAP)之间的数据同步链路,将业务系统的数据自动提取加载到数据仓库。不用再担心链路费用高、配置复杂的问题,让你轻松体验免费、易用的数据同步功能,一站式完成数据同步和管理,实现事务处理和数据分析一体化。

如下面的架构图所示,数据源端的OLTP可以是云数据库RDS、云原生数据库PolarDB,通过Zero-ETL将数据实时同步至目标端云原生数据仓库 AnalyticDB,只需要简单配置源端和目标端,便可完成同步任务的构建。

云原生数据仓库AnalyticDB MySQL基于湖仓一体架构打造,高度兼容MySQL,毫秒级更新,亚秒级查询,可以同时提供高吞吐离线处理和高性能在线分析。云原生数据仓库 AnalyticDB PostgreSQL 自研云原生存算分离架构,企业级能力完备,高性能的向量检索引擎,可提供流批一体的实时数据处理能力。

目前已上线的阿里云瑶池Zero-ETL链路为:

  • 云原生数据库 PolarDB MySQL 版  ==> 云原生数据仓库 AnalyticDB MySQL 版
  • 云原生数据库 PolarDB 分布式版  ==> 云原生数据仓库 AnalyticDB MySQL 版
  • 云原生数据库 RDS MySQL 版  ==> 云原生数据仓库 AnalyticDB MySQL 版
  • 云数据库 RDS PostgreSQL 版 ==> 云原生数据仓库 AnalyticDB PostgreSQL 版
  • 云原生数据库 PolarDB PostgreSQL 版  ==> 云原生数据仓库 AnalyticDB PostgreSQL 版

阿里云瑶池Zero-ETL的优势

阿里云瑶池数据库提供的Zero-ETL服务旨在实现事务处理和数据分析一体化,实现建仓成本的降低和建仓效率的提升,具体优势如下:

零成本:提供低成本的数据接入链路,用户可免费实现在AnalyticDB中对上游PolarDB\RDS数据进行分析处理。

易用性好:无需创建和维护执行ETL(提取、转换、加载操作)的复杂数据管道,仅需选择源端数据和目标端实例,自动创建实时数据同步链路,减少构建和管理数据管道所带来的挑战,专注上层应用开发

高效:采用弹性Serverless架构,同传统DTS链路性能相比,更好地应对源库流量高峰,Zero-ETL数据同步链路性能提升15%+

通过Zero-ETL服务将数据从RDS/PolarDB同步到AnalyticDB中后,即可进行相应的数据分析服务,具体场景有:

AnalyticDB MySQL 版:大数据量离线处理、开源Spark/hudi生态使用、游戏广告实时运营分析平台、数字营销平台建设、日志数据秒级分析等

AnalyticDB PostgreSQL 版:企业专属知识库、一站式实时数仓等

如何使用阿里云瑶池Zero-ETL服务

PolarDB MySQL+AnalyticDB MySQL

登陆PolarDB MySQL概览页-「联邦分析」进入该服务,进行数据实时同步。

  • 新建联邦分析链路:选择源端实例和目标端实例,默认同步整实例,打开「高级配置」后可以选择库表对象,也可以对大表进行分区键设置。


  • 编辑链路、查看链路:支持修改库表对象等,支持查看联邦分析任务的配置详情


RDS PG/PolarDB PG+ AnalyticDB PG

RDS PG/PolarDB PG ==> ADB PG的两条Zero-ETL链路都是在ADB PG的控制台进行操作。

  • 进入ADB PG的控制台页面,进入实例,在左侧导航栏,选择无感集成(Zero-ETL),然后单击左上角创建Zero-ETL任务。

  • 创建一个Zero-ETL任务,配置源库信息和目标库信息:

  • 测试连接以并进行下一步,进入配置Zero-ETL页面
  • 配置库表字段,完成后单击下一步保存任务并预检查

  • 预检查通过后,系统自动启动Zero-ETL任务,在任务列表就可以查看任务进度啦。



相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
17天前
|
运维 Cloud Native 安全
2024年度CCF-阿里云瑶池科研基金正式发布
欢迎申报“CCF-阿里云瑶池科研基金”。
2024年度CCF-阿里云瑶池科研基金正式发布
|
18天前
|
机器学习/深度学习 人工智能 测试技术
阿里云连续三年入围Gartner云AI开发者服务挑战者象限
Gartner正式发布了《云AI开发者服务魔力象限》报告(Magic Quadrant for Cloud AI Developer Services),阿里云成功入选,是唯一一家入围“挑战者”(Challengers)象限的中国厂商,并且保持连续三年入围。
|
20天前
|
存储 人工智能 运维
首批 I 阿里云通过算力服务成熟度增强级评估
近日,阿里云作为算力服务标准主要参编单位之一,参与了首批标准符合性验证,以阿里云飞天企业版为主要参评产品,完成了通用计算、智能计算和高性能计算三类计算服务能力的符合性评估。
|
21天前
|
弹性计算 Java 关系型数据库
最佳实践:阿里云倚天ECS在千寻位置时空智能服务的规模化应用
当前,千寻已有上千台倚天ECS实例在支撑线上核心业务。
|
21天前
|
弹性计算 运维 Java
最佳实践:阿里云倚天ECS在千寻位置时空智能服务的规模化应用
阿里云、平头哥及安谋科技联合举办的飞天技术沙龙探讨了倚天Arm架构在业务创新中的应用。活动中,千寻位置运维专家分享了将核心业务迁移到倚天处理器ECS实例的成功案例,强调了倚天处理器的高能效比和降本增效优势。迁移过程涉及操作系统、CICD系统和监控系统的适配,以及业务系统的性能测试。目前,千寻已迁移了上千台ECS实例到倚天处理器,实现了成本和效率的显著提升。未来计划继续扩展倚天处理器在核心业务和K8S中的应用。
|
21天前
|
Cloud Native 安全 Serverless
【阿里云云原生专栏】低代码开发在云原生平台的应用:阿里云低代码服务探索
【5月更文挑战第27天】在云原生时代,低代码开发凭借其图形化界面和预构建模块,简化了应用开发,提升了效率。阿里云积极探索低代码领域,推出函数计算FC和应用配置中心ACM等服务。FC让开发者无需关注基础设施,仅需少量代码即可实现应用部署,而ACM则提供动态配置管理,增强应用灵活性。阿里云的这些服务为企业数字化转型提供了高效、安全的解决方案,预示着低代码开发在云原生平台上的重要地位。
200 1
|
24天前
|
Cloud Native NoSQL 关系型数据库
动态精选|阿里云4月产品与服务更新盘点
动态精选|阿里云4月产品与服务更新盘点
67 1
|
25天前
|
存储 安全 大数据
蚂蚁数科MAPPIC密态计算云平台入驻阿里云计算巢,打造云上密态计算服务
蚂蚁数科MAPPIC密态计算云平台入驻阿里云计算巢,打造云上密态计算服务
|
25天前
|
域名解析 网络协议 安全
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK
【5月更文挑战第23天】此对比分析探讨了阿里云DNS、AWS Route 53和Azure DNS的服务特点。阿里云DNS以其智能解析和IPv6支持脱颖而出,适合中国地区用户;AWS Route 53凭借其强大的路由策略和与AWS生态的深度集成吸引高级用户;Azure DNS则以简洁管理和DNSSEC安全支持见长,与Azure平台集成良好。选择取决于具体需求,如功能、易用性、性能、安全性和成本。
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK

热门文章

最新文章