数据湖构建服务搭配Delta Lake玩转CDC实时入湖
什么是CDC
Change Data Capture(CDC)用来跟踪捕获数据源的数据变化,并将这些变化同步到目标存储(如数据湖或数据仓库),用于数据备份或后续分析,同步过程可以是分钟/小时/天等粒度,也可以是实时同步。CDC方案分为侵入式(intrusive manner)和非倾入性(non-intrusive manner)两种。
侵入式
侵入式方案直接请求数据源系统(如通过JDBC读取数据),会给数据源系统带来性能压力。常见的方案如下:
最后更新时间(Last Modified)
源表需要有修改时间列,同步作业需要指定最后修改时间参数,表明同步某个时间点之后变更的数据。该方法不能同步删除记录的变更,同一条记录多次变更只能记录最后一次。
自增id列
源表需要有一个自增id列,同步作业需要指定上次同步的最大id值,同步上次之后新增的记录行。该方法也不能同步删除记录的变更,而且老记录的变更也无法感知。
非侵入式
非侵入性一般通过日志的方式记录数据源的数据变化(如数据库的binlog),源库需要开启binlog的功能。数据源的每次操作都会被记录到binlog中(如insert/update/delete等),能够实时跟踪数据插入/删除/数据多次更新/DDL操作等。
示例:
insert into table testdb.test values("hangzhou",1); update testdb.test set b=2 where a="hangzhou"; update testdb.test set b=3 where a="hangzhou"; delete from testdb.test where a="hangzhou";
通过将binlog日志有序的回放到目标存储中,从而实现对数据源的数据导出同步功能。
常见的CDC方案实现
开源常见的CDC方案实现主要有两种:
Sqoop离线同步
sqoop是一个开源的数据同步工具,它可以将数据库的数据同步到HDFS/Hive中,支持全量同步和增量同步,用户可以配置小时/天的调度作业来定时同步数据。
sqoop增量同步是一种侵入式的CDC方案,支持Last Modified和Append模式。
缺点:
直接jdbc请求源库拉取数据,影响源库性能
小时/天调度,实时性不高
无法同步源库的删除操作,Append模式还不支持数据更新操作
binlog实时同步
binlog日志可以通过一些工具实时同步到kafka等消息中间件中,然后通过Spark/Flink等流引擎实时的回放binlog到目标存储(如Kudu/HBase等)。
缺点:
Kudu/HBase运维成本高
Kudu在数据量大的有稳定性问题, HBase不支持高吞吐的分析
Spark Streaming实现回放binlog逻辑复杂,使用java/scala代码具有一定门槛
Streaming SQL+Delta Lake实时入湖方案
前面介绍了两种常见的CDC方案,各自都有一些缺点。阿里云E-MapReduce团队提供了一种新的CDC解决方案,利用自研的Streaming SQL搭配Delta Lake可以轻松实现CDC实时入湖。这套解决方案同时通过阿里云最新发布的数据湖构建(Data Lake Formation,DLF)服务提供一站式的入湖体验。
Streaming SQL
Spark Streaming SQL在Spark Structured Streaming之上提供了SQL能力,降低了实时业务开发的门槛,使得离线业务实时化更简单方便。
Spark Streaming SQL支持的语法如下:
下面以实时消费SLS为例:
# 创建loghub源表 spark-sql> CREATE TABLE loghub_intput_tbl(content string) > USING loghub > OPTIONS > (...) # 创建delta目标表 spark-sql> CREATE TABLE delta_output_tbl(content string) > USING delta > OPTIONS > (...); # 创建流式SCAN spark-sql> CREATE SCAN loghub_table_intput_test_stream > ON loghub_intput_tbl > USING STREAM; # 将loghub源表数据插入delta目标表 spark-sql> INSERT INTO delta_output_tbl SELECT content FROM loghub_table_intput_test_stream;
Delta Lake
Delta Lake是Databricks开源的一种数据湖格式,它在parquet格式之上,提供了ACID事务/元数据管理等能力,同时相比parquet具有更好的性能,能够支持更丰富的数据应用场景(如数据更新/schema演化等)。
E-MapReduce团队在开源Delta Lake基础上做了很多功能和性能的优化,如小文件合并Optimize/DataSkipping/Zorder,SparkSQL/Streaming SQL/Hive/Presto深度集成Delta等。
Streaming SQL+Delta Lake CDC实时入湖
Spark Streaming SQL提供了Merge Into 的语法,搭配Delta Lake的实时写入能力,可以很方便的实现CDC实时入湖方案。
如上图所示,只需要SQL就能完成CDC实时入湖,细节步骤详见E-MapReduce文档。
阿里云最新发布的数据湖构建(Data Lake Formation,DLF)服务,提供了完整的一站式入湖解决方案。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
阿里巴巴电商搜索推荐实时数仓演进之路
1. 业务背景 阿里巴巴电商搜索推荐实时数据仓库承载了阿里巴巴集团淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景,提供了包括实时大屏、实时报表、实时算法训练、实时A/B实验看板等多种数据应用支持。 数据的价值 我们认为数据处于阿里巴巴搜索推荐的大脑位置,这体现在算法迭代、产品运营和老板决策等多个方面。那么数据是怎样在搜索推荐业务场景中流转的呢?首先是信息采集,用户在使用手机淘宝的搜索和推荐功能时,会触发到服务端上的埋点信息;接下来会经过离线和实时的ETL加工,再装载到产品引擎里面;然后我们会基于引擎来构建分析系统,帮助算法、产品做分析决策;形成一次决策之后,会有一些新的内容上线,用户可以看到算法模型产出的一些业务形态;这样就产生了一轮新的数据采集、加工、装载和分析的过程。这样一来就可以利用数据形成一个完整的业务链路,其中每个环节都非常重要。 搜索推荐典型场景 实时数据在电商搜索推荐中有多种不同的应用场景,如实时分析、算法应用和精细化人群运营等。 1)实时分析和算法应用场景 在实时分析和算法应用场景中,我们利用实时数据仓库搭建分析报表、实时大屏、训练算法模型以及打造其他类型的数据产...
- 下一篇
云原生计算引擎挑战与解决方案
云原生背景介绍与思考 图一是基于ECS底座的EMR架构,这是一套非常完整的开源大数据生态,也是近10年来每个数字化企业必不可少的开源大数据解决方案。主要分为以下几层: ECS物理资源层,也就是Iaas层 数据接入层,例如实时的Kafka,离线的Sqoop 存储层,包括HDFS和OSS,以及EMR自研的缓存加速JindoFS 计算引擎层,包括熟知的Spark,Presto、Flink等这些计算引擎 数据应用层,如阿里自研的Dataworks、PAI以及开源的Zeppelin,Jupyter 每一层都有比较多的开源组件与之对应,这些层级组成了最经典的大数据解决方案,也就是EMR的架构。我们对此有以下思考: 是否能够做到更好用的弹性,也就是客户可以完全按照自己业务实际的峰值和低谷进行弹性扩容和缩容,保证速度足够快,资源足够充足 不考虑现有状况,看未来几年的发展方向,是否还需要支持所有的计算引擎和存储引擎。这个问题也非常实际,一方面是客户是否有能力维护这么多的引擎,另一方面是是否某些场景下用一种通用的引擎即可解决所有问题。举个例子说Hive和Mapreduce,诚然现有的一些客户还在用Hive...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- 设置Eclipse缩进为4个空格,增强代码规范