随着大数据的迅猛发展,企业越来越重视数据的价值,这就意味着需要数据尽快到达企业分析决策人员,以最大化发挥数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的快速探索。在业务建设过程中,实时数仓需要支持数据实时写入与更新、业务敏捷快速响应、数据自助分析、运维操作便捷、云原生弹性扩缩容等一列需求,而这就依赖一款强大的实时数仓引擎。 阿里云Hologres作为新一代一站式实时数仓引擎能同时解决OLAP多维分析、在线服务、离线数据加速等多个业务查询场景,阿里云Flink提供全增量一体化数据同步技术、强大的流式ETL等能力,支持海量数据实时写入Hologres。通过阿里云Flink与Hologres的强强结合,实现全链路的数据探索实时化、数据分析敏捷化,快速助力业务构建企业级一站式实时数仓,实现更具时效更智能的业务决策。
通过本文我们将会介绍阿里云Flink、阿里云Hologres在构建实时数仓上所具备的核心能力以及二者结合的最佳解决方案。我们期望通过阿里云Flink+Hologres实时数仓解决方案,降低数仓建设门槛,让数据发挥更大的价值,助力各行各业实现数字化升级!
一、Flink CDC 核心能力
Apache Flink 是开源的大数据流式计算引擎,支持处理数据库、Binlog、在线日志等多种实时数据,提供端到端亚秒级实时数据分析能力,并通过标准 SQL 降低实时业务开发门槛。伴随着实时化浪潮的发展和深化,Flink 已逐步演进为流处理的领军角色和事实标准,并蝉联 Apache 社区最活跃项目。
Flink CDC 是阿里云计算平台事业部2020年7月开源的一款数据集成框架,与 Flink 生态深度融合,具有全增量一体化、无锁读取、并发读取、分布式架构等技术优势,既可以替代传统的 DataX 和 Canal 工具做数据同步,也支持数据库数据实时入湖入仓,同时还具备强大的数据加工能力。
在构建实时数仓的过程中,数据采集是必需的组件。在传统的ETL架构里,采集层国外用户通常选择 Debezium,国内用户则习惯用 DataX 和 Canal,采集工具负责采集数据库的全量数据和增量数据。采集到的数据会输出到消息中间件如 Kafka,然后通过 Flink 计算引擎实时消费消息中间件数据做计算层的数据清洗和数据加工,加工完成后再写入目的端(装载层),通常是各种数据库、数据湖和数据仓库。在传统 ETL 链路中,数据采集工具与消息队列是比较重的组件,可能维护在不同的团队,在上游的数据源有业务变更或者这些组件需要升级维护时,整个链路的维护成本会非常大。
通过使用 Flink CDC 去替换上图中的数据采集组件与消息队列,去掉采集层的采集组件和消息队列,将采集层(Extraction)和计算层(Transformation)合并,简化了整个 ETL 分析链路,用户可以使用更少的组件完成数据链路的搭建,整体架构带来更低的运维开销和更少的硬件成本、更好的数据链路稳定性、以及降低端到端的数据延迟。除了稳定性的提升,Flink CDC 的另一个优势就是用户只需要写 SQL 脚本就能完成 CDC 数据的清洗,加工和同步,极大地降低了用户使用门槛。 除全增量一体化同步能力外,在阿里云上,Flink CDC 还提供了表结构变更自动同步、整库同步、分库分表合并同步等诸多企业级特性,方便用户快速打通数据孤岛,实现业务价值。
1.1 全增量一体化同步
Flink CDC 通过增量快照读取算法在开源数据集成领域率先支持了无锁读取、并行读取、断点续传、不丢不重四个重要特性。其中无锁读取彻底解决了数据同步对上游业务数据库的死锁风险,并行读取很好地满足了海量数据同步的需求,断点续传和不丢不重特性则是提升了同步链路的稳定性和可靠性。
增量快照读取算法的核心思路就是在全量读取阶段把表分成一个个 chunk 进行并发读取,在进入增量阶段后只需要一个 task 进行单并发读取 Binlog 日志,在全量和增量自动切换时,通过无锁算法保障一致性。这种设计在提高读取效率的同时,进一步节约了资源,实现了全增量一体化的数据同步。配合阿里云实时计算产品提供的资源自动调优特性,Flink CDC 作业的资源的可以做到自动扩缩容,无需手动介入。
1.2 表结构变更自动同步
随着业务的迭代和发展,数据源的表结构变更是经常会发生的操作。用户需要及时地去修改数据同步作业以适配最新的表结构,这一方面带来了较大的运维成本,也影响了同步管道的稳定性和数据的时效性。阿里云Flink支持通过 Catalog 来实现元数据的自动发现和管理,配合 CTAS (Create Table AS)语法,用户可以通过一行 SQL 实现数据的同步和表结构变更自动同步。
Flink SQL> USE CATALOG holo;Flink SQL>CREATETABLE user ASTABLE mysql.`order_db`.`user`;
CTAS 语句会解析成一个 Flink 作业执行,这个 Flink 作业源头支持读取数据变更和表结构变更并同步到下游,数据和表结构变更都可以保证顺序,上述 CTAS 语句运行时结构变更同步的效果如下图所示。
示例如果在上游MySQL的 user 表中新增一列 age,并插入一条 id 为 27,年龄为30的记录。
MySQL> ALTER TABLE `user` ADD COLUMN `age` INT; MySQL> INSERT INTO `user` (id, name, age) VALUES (27, 'Tony', 30);
user表上的数据和结构变更都能实时地自动同步到下游 Hologres 的 user 表中,id 为 12,16和19的历史数据,新增的列会自动补 NULL 值。
1.3 整库同步
在实时数仓构建中,用户经常需要将整个数据库同步到数仓中做进一步的分析,一张表一个同步作业的方式不但浪费资源,也会给上游数据库产生较大的压力。针对这类用户痛点,阿里云 Flink CDC 提供了整库同步特性。整库同步功能通过 CDAS (Create Database AS) 语法配合 Catalog 实现。
Flink SQL> USE CATALOG holo;Flink SQL>CREATE DATABASE holo_order AS DATABASE mysql.`order_db` INCLUDING ALL TABLES;
例如 MySQL Catalog 和 Hologres Catalog 配合 CDAS 语法,可以完成 MySQL 到 Hologres 的全增量数据同步。CDAS 语句会解析成一个 Flink 作业执行,这个 Flink 作业自动解析源表的表结构及相应的参数,并将指定的一个或多个数据库同步到下游 Hologres 数仓中,整个过程用户无需手写 DDL 语句,无需用户在 Hologres 提前创建表,就能快速实现数据的整库同步。
CDAS 作业默认提供表结构变更同步能力,所有表的结构变更都会按照发生顺序同步至下游 Hologres 实时数仓,CDAS 语法也支持过滤不需要同步的表。
1.4 分库分表合并同步
分库分表是高并发业务系统采用的经典数据库设计,通常我们需要将分库分表的业务数据汇聚到一张数仓中的大表,方便后续的数据分析,即分库分表合并同步的场景。针对这种场景,阿里云Flink CDC 提供了分库分表合并同步特性,通过在 CTAS 语法支持源库和源表的正则表达式,源数据库的分表可以高效地合并同步到下游 Hologres 数仓中。
Flink SQL> USE CATALOG holo;Flink SQL>CREATETABLEorderASTABLE mysql.`order_db.*`.`order_.*`;
上述 CTAS 语句中的源库名 order_db.* 是个正则表达式,可以匹配当前 MySQL实例下的order_db01,order_db02 和 order_db03 三个库,源表名 order_* 也是个正则表达式,可以匹配三个库下所有以order_打头的表。
针对分库分表同步场景,用户只需要提供分库分表的正则表达式就可以将这多张分库分表合并同步到下游 Hologres 数仓的 ordder 表中。与其他CDAS 语句一样,分库分表同步场景默认提供表结构变更自动同步特性,下游 Hologres 表的 schema 为所有分表合并后的最宽 schema。分库分表同步时每行记录所属的库名和表名会作为额外的两个字段自动写入到 user 表中,库名(上图中 db 列)、表名(上图中 tbl 列)和原主键(上图中 id 列) 会一起作为下游 Hologres user 表的联合主键,保证Hologres user 表上主键的唯一性。
二、Hologres 核心能力
阿里云Hologres是自研的一站式实时数据仓库引擎,支持海量数据实时写入、实时更新、实时分析,支持标准SQL(兼容PostgreSQL协议),提供PB级数据多维分析(OLAP)与即席分析以及高并发低延迟的在线数据服务(Serving),与阿里云Flink、MaxCompute、DataWorks等深度融合,为企业提供离在线一体化全栈数仓解决方案。
2.1 高性能实时写入与更新
数据写入的时效性是实时数仓的重要能力之一。对于BI类等延迟不敏感的业务查询,如果写入时延几秒甚至几分钟可能是可以接受的。而对于很多生产系统,如实时风控、实时大屏等场景,要求数据写入即可见。如果写入出现延迟,就会查询不到最新的数据,严重影响线上业务决策。在实时数仓整个数据处理链路中,Hologres作为一站式实时数据仓库引擎,提供海量数据高性能的实时写入,数据写入即可查询,无延迟。
同时在数仓场景上,数据来源复杂,会涉及到非常多的数据更新、修正的场景,Hologres可以通过主键(Primary Key, PK)提供高性能的Upsert能力,整个写入和更新过程确保Exactly Once,满足对对数据的合并、更新等需求。
下图为Hologres 128C实例下,10个并发实时写入20列的列存表的测试结果。其中竖轴表示每秒写入记录数,横轴为4个写入场景:
- Append Only:写入表无主键,写入能力230万+的RPS。
- INSERT: 写入表有主键,如果主键冲突就丢弃新行,写入能力200万RPS
- UPDATE-1: 写入表有主键,表中原始数据量为2亿,按照主键Upsert,写入能力80万的RPS。
- UPDATE-2: 写入表有主键,表中数据量为20亿,按照主键做Upsert,写入能力70万的RPS。
2.2 实时OLAP分析
Hologres采用可扩展的MPP全并行计算,支持行存、列存、行列共存等多种存储模式,同时支持多种索引类型。通过分布式处理SQL以及向量化的算子,能够将CPU资源发挥到极致,从而支持海量数据亚秒级分析,无需预计算,就能支持实时多维分析,即席分析等多种实时OLAP分析的场景,再直接无缝对接上层应用/服务,满足所见即所得的分析体验。
下图为Hologres 128C实例下,TPCH 100G标准数据集下的测试结果,横轴表示query,纵轴是响应时间:
2.3 高性能在线服务
随着实时数仓的广泛应用,越来越多的企业把实时数仓作为在线服务系统提供在线查询。Hologres作为HSAP(Hybrid Serving and Analytics Processing, 服务与分析一体化)的最佳落地实践,除了具备处理分析型Query的能力外,还具备十分强大的在线服务Serving能力(高QPS点查),例如KV点查与向量检索。在KV点查场景中,Holgres通过SQL接口可以支持百万级的QPS吞吐与极低的延时。通过Hologres能够做到一套系统、一份数据支持同时OLAP分析和在线服务两种场景,简化数据架构。
下图为Hologres 128C实例下,CPU消耗25%的点查测试性能:
2.4 读写分离高可用
实时数据仓库Hologres提供高QPS低延迟的写入能力,支持在线服务的查询场景,还支持复杂的多维分析OLAP查询。当不同类型,不同复杂的任务请求到Hologres实例上时,Hologres不仅需要确保任务的正常运行,还要确保系统的稳定性。当前Hologres支持通过共享存储的一主多从子实例的高可用架构,实现了完整的读写分离功能,保障不同业务场景的SLA。
- 读写分离:实现了完整的读写分离功能,保障不同业务场景的SLA,在高吞吐的数据写入和复杂的ETL作业、OLAP查询、AdHoc查询、在线服务等场景中,系统负载物理上完全隔离,不会因写入任务产生了查询任务的抖动。
- 多类型负载资源隔离:一个主实例可以配置四个只读实例,实例之间可以根据业务情况配置不同规格,系统负载物理上完全隔离,避免相互影响而带来抖动。
- 实例间数据毫秒级异步同步延迟:P99 5ms内。
2.5 Binlog订阅
类似于传统数据库MySQL中的Binlog概念,Binlog用来记录数据库中表数据的修改记录,比如Insert/Delete/Update的操作。在Hologres中,表的Binlog是一种强Schema格式的数据,Binlog记录的序列号(BigInt),在单shard内单调递增,类似于Kafka中的Offset概念。通过阿里云Flink消费Hologres Binlog,可以实现数仓分层间的全链路实时开发,在分层治理的前提下,缩短数据加工端到端延迟,同时提升实时数仓分层的开发效率。
三、阿里云 Flink x Hologres 一站式企业级实时数仓解决方案
3.1 实时数仓ETL
ETL( Extract-Transform-Load)是比较传统的数据仓库建设方法,业务库的数据Binlog经过阿里云Flink的ETL处理之后,数据写入到实时数仓Hologres中,然后进行各类数据查询分析。ETL的方法核心是需要在数仓中具备完善的数仓模型分层,从ODS(Operational Data Source)>DWD(Data Ware Detail)>DWS(Data Warehouse Summary)>ADS(Application Data Service)模型,整个数仓链路比较完善。
在这个链路中,需要将数据源比如MySQL的Binlog数据通过阿里云 Flink CDC同步到消息队列Kafka,再通过阿里云Flink将ODS的数据进行过滤,清晰,逻辑转化等操作,形成对不同的业务主题模型的DWD数据明细层,同时将数据发送到Kafka集群,之后再通过阿里云Flink将DWD的数据进行轻度的汇总操作,形成业务上更加方便查询的DWS轻度汇总层数据,同时将数据写入Kafka集群。最后再面向业务具体的应用层的需求,在DWS层基础上通过阿里云Flink实时处理形成ADS数据应用层,写入实时数仓Hologres进行存储和分析,支持业务各种不同类型的报表,画像等业务场景。
实时数仓ETL的处理优点是数仓各种层次比较完备,职责清晰,但是缺点是Flink结合Kafka集群维护复杂,处理链路比较长,历史数据修正复杂,ADS应用层的数据实时性会弱,其次数据在各个Kafka中不便于查询,不便于检查数据质量,也不便于schema的动态变化。
3.2 实时数仓ELT
随着业务对数据的时效性要求越来越高时,相较于ETL复杂繁杂的处理链路,业务需要更快速的将数据实时入仓,因此ELT变成了比较流行的处理方法。ELT 是英文 Extract-Load-Transform 的缩写,我们可将 ELT 理解为一个数据迁移集成的过程。在这个过程中,我们可以对数据源关系型数据库比如MySQL,PostgresSQL和非关系型数据库比如HBase,Cassandra等业务库的Binlog,消息队列比如Datahub、Kafka中的埋点采集日志等数据,经过阿里云Flink实时抽取,然后加载到Hologres中进行相关的OLAP分析和在线服务。
在这个链路中,阿里云Flink只做简单的数据清洗,清洗后直接将数据实时写入Hologres,由Hologres直接存储明细数据,在Hologres中可以简化分层,以明细层为主,按需搭配其他汇总层,通过Hologres强大的数据处理能力直接对接报表、应用等上层查询服务,满足实时即席分析的需求。
实时数仓中采取ELT的方式进行建设,会给数据和业务带来比较大的收益,详细如下:
- 灵活性:将原始的业务数据直接入仓,形成ODS层的数据,在数仓中就可以比较灵活的进行各数据的逻辑转换(Transformation)的处理,提供应用层
- 成本低:数据仓库的架构比较清晰,链路比较短,运维成本比较低。
- 实时性:数据不经过中间链路的各种转换,直接实时入仓,提供业务分析的时效性更加,数据业务价值更大
3.3 实时数仓分层(Streaming Warehouse方案)
按照传统数仓的开发方法论,采用ODS>DWD>DWS>ADS开发的方法,通过阿里云Flink和Hologres Binlog的组合关系,支持层与层之间有状态的全链路事件实时驱动。在该方案中,数据通过阿里云Flink CDC实时入仓至Hologres,再通过阿里云Flink订阅Hologres Binlog,实现数据在不同层次之间的连续加工,最后写入Hologres对接应用查询。
通过这个方案,Hologres可以达到像Kafka、Datahub等消息队列同等的能力,增加数据复用的能力,一个Table的数据既可以提供给下游阿里云Flink任务消费,还可以对接上游OLAP/在线服务查询,不仅节省了成本,还简化数仓架构,同时也让数仓中的每一个层次都可以实时构建、实时查询,提升数据的流转效率。
3.4 流批一体数仓
在实时数仓中,流计算任务和批处理任务都是分两条工作流进行开发的,也即是Kappa架构模式。在这套数仓架构中,会存在人力成本过高,数据链路冗余,数据口径不一致,开发效率低下的一些问题。
为了解决这些问题,阿里云Flink+Hologres提供了流批一体的能力。在该场景中,将输入层统一变成Hologres,通过一套业务逻辑代码达到流和批处理的能力,其中Flink SQL的Stream任务消费Hologres Binlog提供流式处理,Flink SQL的Batch任务读取Hologres表的原始数据达到批处理能力,经过Flink统一的计算处理之后,统一写入存储至Hologres。
阿里云Flink结合Hologres的流批一体技术,统一了数据输入层、实时离线计算层和数据分析存储层,极大的提升了数据开发的效率,保证了数据的质量。
四、典型应用场景
阿里云Flink与Hologres深度集成,助力企业快速构建一站式实时数仓:
- 可通过阿里云Flink实时写入Hologres,高性能写入与更新,数据写入即可见,无延迟,满足实时数仓高性能低延迟写入需求。
- 可通过阿里云Flink能全量读取、Binlog读取、CDC读取、全增量一体化等多种方式读取Hologres源表数据,无需额外组件,统一计算和存储,加速数据流转效率
- 可通过阿里云Flink读取Hologres维表,助力高性能维表关联、数据打宽等多种应用场景
- 阿里云Flink与Hologres元数据打通,通过Hologres Catalog,实现元数据自动发现,极大提升作业开发效率和正确性
通过阿里云Flink与Hologres的实时数仓标准解决方案,能够支撑多种实时数仓应用场景,如实时推荐、实时风控等,满足企业的实时分析需求。下面我们将会介绍阿里云 Flink + Hologres的典型应用场景,助力业务更加高效的搭建实时数仓。
4.1 实时 UV 统计
用户画像分析是实时数仓非常热门的一个场景,它通过对用户全方位特征加工、画像分析,为运营分析人员提供实时人群分析、圈选能力,从而辅助优化运营策略,助力业务精细化增长。实时数仓在画像分析场景上往往由于数据复杂度、数据量级和查询模式等因素导致系统可稳定性、运维性、可扩展性面临重重困难。
Hologres兼容PostgreSQL生态,原生支持RoaringBitmap数据类型,通过对标签表构建索引,将用户ID编码后以RoaringBitmap格式保存,将关系运算转化Bitmap的交并差运算,进而加速实时计算性能。在实时数仓中,可以通过Flink和Hologres方式,基于RoaringBitmap,实时对用户标签等数据进行去重,就可以实时计算出UV,PV等数据。
Flink将流式数据转化为表与维表进行JOIN操作,再转化为流式数据。此举可以利用Hologres维表的insertIfNotExists特性结合自增字段实现高效的uid映射。Flink把关联的结果数据按照时间窗口进行处理,根据查询维度使用RoaringBitmap进行聚合,并将查询维度以及聚合的uid存放在聚合结果表,其中聚合出的uid结果放入Hologres的RoaringBitmap类型的字段中。
Flink+Hologres的方案,可以使得实时精确计算基数的数据链路更简单,支持任意维度灵活计算,只需要一份Bitmap存储,也没有存储爆炸问题,还能保证实时更新,从而实现更实时、开发更灵活、功能更完善的多维分析数仓,轻松支持画像分析的场景。
4.2 宽表 Merge
数据仓库中我们通常需要关心的就是建模,数据模型通常分为四种:宽表模型、星型模型、雪花模型、星座模型(Hologres均支持),在这里我们重点要提到的是宽表模型的建设。宽表模型通常是指将业务主体相关的指标、维表、属性关联在一起的模型表,也可以泛指将多个事实表和多个维度表相关联到一起形成的宽表。
宽表建设通常的做法就是通过阿里云Flink的双流Join来实现,包括Regular Join,Interval Join,Temporal Join。对于主键关联的场景(即Join条件分别是两条流的主键),我们可以将 Join 的工作下沉到 Hologres 去做,通过 Hologres的局部更新功能来实现宽表 Merge,从而省去了 Flink Join 的状态维护成本。比如广告场景中,一个Flink任务处理广告曝光数据流,将宽表中需要的字段数据以Insert Or Update的模式更新到宽表中,另一个Flink任务来处理广告点击数据流,将宽表中需要的字段数据以Insert Or Update模式更新到宽表中,并不需要进行双流的 Join,最终 Hologres会自己进行一个数据的组装。
使用Hologres宽表的Merge能力,可以大大提升流作业的开发效率,以及减少流作业所需要的资源消耗,也能够更容易的维护各个流作业,让作业之间不会相互影响,同时也减少了因为流作业窗口状态有限造成的晚来数据窗口超期的更新问题。从双流Join到改为Hologres的宽表Merge的实现如下图。
CREATETABLE ods_topicA( product_id INT,click_id bigint,click_time timestamp)with('connector'='DATAHUB');CREATETABLE ods_topicB( id INT,imp_int bigint,imp_time timestamp)with('connector'='DATAHUB');CREATETABLE ods_sink( product_id INT,imp_id bigint,imp_int bigint)with('connector'='Hologres','insertOrUpdate'='true');INSERTINTO ods_sink SELECT A.product_id,COUNT(DISTINCT click_id)AS click_cnt FROM ods_topicA;INSERTINTO ods_sink SELECT B.product_id,COUNT(DISTINCT imp_id)AS imp_cnt FROM ods_topicB;
4.3 实时维表Lookup
在实时数仓中,在构建DWD层的数据过程中,一般都是通过Flink来读取消息队列比如Datahub上的ODS数据,同时需要关联维表来形成DWD层。在Flink任务的计算过程中,需要高效的读取维表的能力,Hologres可以通过高QPS低延迟的点查能力来满足实现这类场景需求。比如我们需要通过ODS的数据去Join维表形成DWD层的时候,就可以利用Hologres提供的点查能力,在该模式中,通常使用行存表的主键点查模式提高维表的Lookup效率。具体的实现类似如下:
五、典型用户案例
依托Flink+Hologres解决方案,企业可以快速构建一站式实时数仓,助力实时推荐、实时风控、实时大屏等多种业务场景,实现对数据的快速处理,极速探索查询。目前该方案已在阿里巴巴内部、众多云上企业生产落地,成为当之无愧的实时数仓界“王炸组合”。
以某知名全球TOP20游戏公司业务为例,其通过阿里云Flink+Hologres实时数仓方案,替换开源Flink+Presto+HBase+ClickHouse架构,简化数据处理链路、统一数仓架构、统一存储、查询性能提升100%甚至更多,完美支撑数据分析、广告投放、实时决策等多个场景,助力业务快速增长。
5.1 业务困难:ETL链路复杂、OLAP查询慢
客户原数仓架构使用全套开源组件,架构图如下。其中开源Flink做ETL处理,处理后写入ClickHouse、Starocks等OLAP引擎。
这套架构遇见的主要痛点有:
1、ETL链路复杂
- 为了解决数据实时ETL,客户通过Flink CDC+Hudi做流批一体。但由于上游业务数据经常变更表结构,而开源Flink无Schema Evolution,每次表结构变更都需要任务重新启动,操作非常麻烦,浪费大量开发时间。
- Hudi的查询性能不满足业务需求,还需要再加一个Presto做加速查询,造成链路冗余。
2、OLAP架构冗余,查询慢
客户主要是靠买量发行作为游戏推广的重要手段,为了解决广告归因的实时决策场景对查询加速的需要,于是部署了开源Presto、ClickHouse、HBase等多套集群搭建混合OLAP平台。带来的问题有:
- 平台需要维护多套集群,导致运维变得非常复杂。
- 开发需要在各种SQL中切换,为开发团队带来了许多困扰。
- 由于ClickHouse缺乏主键,在归因分析时需要使用Last Click模型,带来了大量的额外工作。
- 同时OLAP引擎的查询性能没有办法很好的满足业务需求,没办法根据数据实时决策。
- 数据需要在多个OLAP系统中存储,造成存储冗余,导致成本压力剧增。
基于上面的痛点,客户开始重新做技术选型,并使用阿里云Flink+Hologres来替换现有的开源数仓架构。
5.2 架构升级:阿里云Flink+Hologres统一数据存储与服务
通过阿里云Flink+Hologres替换后的数据链路如下:
- 数据源数据通过Flink CDC能力写入Kafka做前置清洗,清洗后通过Flink进行ETL处理。
- Flink ETL后的数据实时写入Hologres,通过 Hologres 替换了Kafka作为实时数仓的中间数据层,统一了流批存储。
- 在Hologres中根据ODS > DWD > DWS层汇总加工。在ODS层,Flink订阅Hologres Binlog,计算后写入Hologres DWD层,DWD层在Hologres中汇总成DWS层,最后DWS对接上层报表和数据服务等业务。
- 为了存储的统一,也将原离线Hive数据替换成阿里云MaxCompute,以MaxCompute为离线主要链路。因Hologres与MaxCompute的高效互通能力,Hologres通过外表离线加速查询MaxCompute,并将历史数据定期归档至MaxCompute。
5.3 业务收益:架构统一,性能提升100%
通过架构升级后,客户的显著业务收益如下:
- 依托Flink+Hologres,数据可以实时写入Hologres,写入即可见,并且Hologres有主键,能够支撑高性能的写入更新能力,百万级更新毫秒级延迟。
- 阿里云Flink提供Schema Evolution的能力,自动感知上游表结构变更并同步Hologres,改造后的实时ETL链路通过订阅Hologres Binlog日志来完成,降低链路维护成本。
- 通过Hologres统一了数据查询查询出口,经过客户实测相同的查询Hologres相比开源ClickHouse达毫秒级延迟,性能提升100%甚至更多,JOIN查询性能快10倍。
- 升级后数仓架构变得更加灵活简洁,统一了存储,只需要一套系统就能满足业务需求,降低运维压力和运维成本。
了解更多:
阿里云实时计算Flink:https://www.aliyun.com/product/bigdata/sc
阿里云实时数仓Hologres:https://www.aliyun.com/product/bigdata/hologram
Flink X Hologres联合解决方案:https://developer.aliyun.com/article/786306