简介：作为一款全平台极速 MPP 架构，StarRocks 提供了多种性能优化伎俩与灵便的建模形式，在预聚合、宽表和星型 / 雪花等多种模型上，都能够取得极致的性能体验。通过 StarRocks 联合 Flink 构建开源实时数仓的计划，能够同时提供秒级数据同步和极速剖析查问的能力。同时，通过 StarRocks 主键模型，也能够更好地反对实时和频繁更新等场景。
作者：
王天宜 – StarRocks 解决方案架构师
周康 – 阿里云开源大数据 OLAP 团队
实时数仓建设背景
实时数仓需要
随着互联网行业的飞速发展，企业业务品种变得越来越多，数据量也变得越来越大。以 Apache Hadoop 生态为外围的数据看板业务个别只能实现离线的业务。在局部畛域，数据实时处理的能力曾经成为限度企业数据变现的重要瓶颈之一。搭建数据看板快节奏地进行数据分析，曾经成为了一种必然的抉择。
实时数仓倒退
实时数仓有三个驰名的分水岭：第一个分水岭是从无到有，Apache Storm 的呈现突破了 MapReduce 的繁多计算形式，让业务可能解决 T+0 的数据；第二个分水岭是从有到全，Lambda 与 Kappa 架构的呈现，使离线数仓向实时数仓迈进了一步，而 Lambda 架构到 Kappa 架构的演进，实现了离线数仓模型和实时数仓模型的紧密结合；第三个分水岭是从繁到简，Flink 技术栈的落地使实时数仓架构变得精简，并且是当初公认的流批一体最佳解决方案。
以 Flink 作为实时计算引擎实现的实时数仓，将一部分简单的计算转嫁给 OLAP 剖析引擎上，使得应用层的剖析需要更加灵便。但依然无奈扭转数据仓库变更数据的排挤。下一代的实时数仓平台，不仅要提供更为优良的性能，同时也须要更为欠缺的性能以匹配不同的业务。
作为一款全平台极速 MPP 架构，StarRocks 提供了多种性能优化伎俩与灵便的建模形式，在预聚合、宽表和星型 / 雪花等多种模型上，都能够取得极致的性能体验。通过 StarRocks 联合 Flink 构建开源实时数仓的计划，能够同时提供秒级数据同步和极速剖析查问的能力。同时，通过 StarRocks 主键模型，也能够更好地反对实时和频繁更新等场景。
基于 Flink 的开源实时数仓痛点
原有基于 Flink 构建施行数仓的计划中，因为数据源的多样性，须要应用不同的采集工具，如 Flume、Canal、Logstash。对于不同的业务，咱们通常会采纳不同的剖析引擎。比方，对于固定报表业务，依据已知的查问语句能够事后将事实表与维度表打平成宽表，充分利用 ClickHouse 弱小的单表查问能力；对于高并发的查问申请，能够应用 Apache Druid 接受大量用户顶峰期间集中应用带来的并发压力。通过技术栈重叠的形式的确能够满足业务要求，但也会让剖析层变得臃肿，减少开发与运维的老本。
1.png
一般来说，StarRocks X Flink 构建开源实时数仓生态架构分为五层：
第一层是数据源。数据源能够是多种多样的，比如说 MySQL Binlog、爬虫数据或者是立体文件；
第二层是数据采集层。用户应用多种不同的 CDC 工具，比方 Canal、Debezium 拉取上游的增量数据，通常会将数据写入到 Kafka 中，而后在通过 Flink 生产 Kafka 中的数据；
第三层是实时计算层。能够通过 Flink 的实时计算能力实现轻量级的 ETL 工作，如拼宽表或数据荡涤等；
第四层是数据存储层。Flink 相比其余的实时技术栈更加依赖 OLAP 引擎；
最初一层是后端应用层。能够是实时监控零碎，实时报表零碎，实时举荐零碎以及实时数据接口服务。
咱们常说，天下文治，唯快不破。以 Flink 为计算引擎构建的实时数仓零碎，最关怀的就是数据摄入速度足够快，提早足够低。在这样一套架构中，数据从数据源到 OLAP 剖析零碎路径采集工具层，音讯队列层，实时计算层。简短的链路给开发和运维带来了极大的危险，任何一个模块的阻塞都会对实时性产生影响。同时，在数据存储层上，咱们也会抉择不同的存储引擎适配不同的业务。对于下面的数据链路，咱们也面临着诸多的挑战，须要从时效性、功能性及可维护性上做更多的摸索，由此能够总结演绎出多个方面尚待优化：
CDC 组件不对立，链路过长，任何组件呈现瓶颈都会对时效性产生影响，组件过多，须要多部门合作保护，学习老本与保护老本成倍增长；
局部同步组件，如 Debezium 在保证数据一致性时，须要对读取的表加锁，可能会影响业务更新；
剖析层应用多种数据存储产品适应不同的业务类型，难以有一种产品可能适应大部分的业务；
去重操作对应逻辑简单，须要在 flink 外面减少 MapStat 逻辑。
Flink CDC，买通端到端链路
Flink CDC 是由 Flink 社区开发的集数据采集、数据转换、数据装载一体的组件，能够间接从 MySQL、PostgreSQL、Oracle 等数据源间接读取全量或增量数据并写入上游的 OLAP 数据存储系统。应用 Flink CDC 后，能够简略高效的抓取上游的数据变更，同步到上游的 OLAP 数据仓库中。
构建一体化数据传输链路
在传统的实时数仓建设中，数据采集工具是不可或缺的。因为上游的数据源不统一，通常来说咱们可能会在数据采集层接入不同的同步与采集工具，比方采集 Oracle 中的数据时，咱们通常抉择 GoldenGate，而对于 MySQL，咱们可能会抉择 Canal 或 Debezium。有些采集工具反对全量数据同步，有些反对增量数据同步。数据通过采集层后，会传输到音讯队列中如 Kafka，而后通过 Flink 生产 Kafka 中的增量数据再写入上游的 OLAP 数据仓库或者数据湖中。
2.png
在业务开发中，上游的数据源、消息中间件、Flink 以及上游的剖析性数据仓库通常在不同的部门进行保护。遇到业务变更或者故障调试时，可能须要多个部门合作解决，减少了业务开发与测试的难度。通过应用 Flink CDC 替换上图中的数据采集组件与音讯队列，将虚线框中的采集组件与音讯队列合并到计算层 Flink 中，从而简化剖析链路，升高保护老本。同时更少的组件也意味着更少的故障与传输瓶颈，数据实效性会进一步的进步。
3.png
在应用 Flink CDC 之后，数据链路中的组件变得更少，架构变得清晰简略，保护变得更不便。如在下面的例子中，咱们应用 Flink CDC 拉取 MySQL 中的增量数据，通过 Flink SQL 创立事实与维度的 MySQL CDC 表，并在 Flink 中进行打宽操作，将后果写入到上游的 StarRocks 中。通过一个 Flink CDC 作业就能够实现抓取，转换，装载的全过程。
全量 + 增量数据同步
在传统的数据同步框架中，咱们通常会分为两个阶段：
全量数据同步阶段：通过全量同步工具，如 DataX 或 sqoop 等，进行快照级别的表同步。
增量数据同步阶段：通过增量同步工具，如 Canal 或 GoldenGate 等，实时拉取快照之后的增量数据进行同步。
在全量数据同步时，为了放慢导入的速度，咱们能够抉择多线程的导入模式。在多线程模型下进行全量数据同步时，在对数据进行切分后，通过启动多个并发工作实现数据的同步。因为多个并发业务之间可能不属于同一个读事务，并且存在肯定的工夫距离，所以不能严格的保证数据的一致性。为了保证数据的一致性，从工程学与技术实现的角度做均衡，咱们有两种计划：
进行数据的写入操作，通过锁表等形式保障快照数据的动态性。但这将影响在线的业务。
采纳单线程同步的形式，不再对数据进行切片。但导入性能无奈保障。
通过 Flink CDC，能够对立全量 + 增量的数据同步工作。Flink CDC 1.x 版本中，采纳 Debezium 作为底层的采集工具，在全量的数据读取过程中，为了保证数据的一致性，也须要对库或表进行加锁操作。为了解决这个问题，Flink 2.0 中引入了 Chunk 切分算法保证数据的无锁读取。Chunk 的切分算法相似分库分表原理，通过表的主键对数据进行分片操作。
4.png
在通过 Chunk 数据分片后，每个 Chunk 只负责本人主键范畴内的数据，只有保障每个 Chunk 的读取一致性，这也是无锁算法的基本原理。
StarRocks，实时数据更新新计划
StarRocks 是一款极速全场景 MPP 企业级数据仓库产品，具备程度在线扩缩容能力，金融级高可用，兼容 MySQL 协定和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查问等重要个性。作为一款 MPP 架构的剖析性数据仓库，StarRocks 可能撑持 PB 级别的数据量，领有灵便的建模形式，能够通过物化视图、位图索引、稠密索引等优化伎俩构建极速对立的剖析层数据存储系统。
StarRocks 在 1.19 版本推出了主键模型（Primary Key model）。相较更新模型，主键模型能够更好地反对实时和频繁更新等场景。主键模型要求表有惟一的主键（传统数据仓库中的 primary key），反对对表中的行按主键进行更新和删除操作。
主键模型对实时数据变更的优化
在 OLAP 数据仓库中，可变数据通常是不受欢迎的。在传统数仓中，个别咱们会应用批量更新的形式解决大量数据变更的场景。对于数据的变更咱们有两种办法解决：
在新的分区中插入批改后的数据，通过分区替换实现数据变更。
局部 OLAP 数据仓库产品提供了基于 Merge on Read 模型的更新性能，实现数据变更。
分区替换数据更新模式
对于大部分的 OLAP 数据仓库产品，咱们能够通过操作分区的形式，将原有的分区删除掉，而后用新的分区代替，从而实现对大量数据的变更操作。一般来说须要经验三个步骤：
创立一张新的分区表，依据业务变更，将新的数据存储到新表中；
卸载并删除原有的分区；
将新表中的分区装载到指标表中。
通过替换分区来实现大规模数据变更是一个绝对较重的操作，实用于低频的批量数据更新。因为波及到了表定义的变更，一般来说开发人员无奈通过该计划独立实现数据变更。
Merge on Read 数据更新模式
局部的 OLAP 数据仓库提供了基于 Merge on Read 的数据变更模型，如 ClickHouse 提供了 MergeTree 引擎，能够实现异步更新，但无奈做到数据实时同步。在指定 FINAL 关键字后，ClickHouse 会在返回后果之前实现合并，从而实现准实时的数据更新同步操作。但因为 FINAL 操作昂扬的代价，不足以撑持实时数仓带来的频繁维度更新需要。同时，即使是在低频的更新场景中，也无奈将 ClickHouse Merge Tree 的计划复制到其余存储系统中。
StarRocks 提供了与 ClickHouse Merge Tree 相似的更新模型（Unique Key model），通过 Merge on Read 的模式实现数据的更新操作。在更新模型中，StarRocks 外部会给每一个批次导入的数据调配一个版本号，同一主键可能存在多个版本，在查问时进行版本合并，返回最新版本的记录。
5.png
Merge on Read 模式在写入时简略高效，但读取时会耗费大量的资源在版本合并上，同时因为 merge 算子的存在，使得谓词无奈下推、索引无奈应用，重大的影响了查问的性能。StarRocks 提供了基于 Delete and Insert 模式的主键模型，防止了因为版本合并导致的算子无奈下推的问题。主键模型适宜须要对数据进行实时更新的场景，能够更好的解决行级别的更新操作，撑持百万级别的 TPS，特地适宜 MySQL 或其余业务库同步到 StarRocks 的场景。
在 TPCH 规范测试集中，咱们选取了局部的查问进行比照，基于 Delete and Insert 模式的主键模型相较于基于 Merge on Read 的 Unique Key 模型，性能有显著的进步：
Query
数据量
Primary Key
(Delete and Insert)
Unique Key
(Merge on Read)
性能晋升
导入过程中
SELECT COUNT(*) FROM orders;
8000 万
0.24 sec
1.15 sec
6.29x
SELECT COUNT(*) FROM orders;
1.6 亿
0.31 sec
3.4 sec
10.97x
SELECT COUNT(*), SUM(quantify)
FROM orders WHERE revenue < 2000;
1000 万
0.23 sec
3.49 sec
15.17x
导入后
SELECT COUNT(*) FROM orders;
2 亿
0.32 sec
1.17 sec
3.66x
SELECT COUNT(*), SUM(quantify)
FROM orders WHERE revenue < 2000;
1200 万
0.34 sec
1.52 sec
4.47x
主键模型对去重操作的反对
打消反复数据是理论业务中常常遇到的难题。在数据仓库中，反复数据的删除有助于缩小存储所耗费的容量。在一些特定的场景中，反复数据也是不可承受的，比方在客群圈选与精准营销业务场景中，为了防止反复推送营销信息，个别会依据用户 ID 进行去重操作。在传统的离线计算中，能够通过 distinct 函数实现去重操作。在实时计算业务中，去重是一个增量和长期的过程，咱们能够在 Flink 中通过增加 MapState 逻辑进行去重操作。但通过 MapStat，少数状况下只能保障肯定的工夫窗口内数据去重，很难实现增量数据与 OLAP 库中的存量数据进行去重。随着工夫窗口的减少，Flink 中的去重操作会占用大量的内存资源，同时也会使计算层变得臃肿简单。
主键模型要求表领有惟一的主键，反对表中的行依照主键进行更新和删除操作。主键的唯一性与去重操作的需要高度匹配，在数据导入时，主键模型就曾经实现了去重操作，防止了手动去重带来的资源耗费。通过对业务逻辑的拆解，咱们能够选取适合去重列作为主键，在数据导入时通过 Delete and Insert 的形式实现“数据依据惟一主键进行去重”的需要。相比于在 Flink 中实现去重，StarRocks 主键模型能够节俭大量的硬件资源，操作更为简略，并且能够实现增量数据加存量数据的去重操作。
主键模型对宽表数据变更优化
在固定报表业务场景中，通常会依据固定的查问，在 Flink 中对数据进行简略的业务荡涤后打平成宽表，借用宽表极佳的多维分析性能，助力查问提速，同时也简化了分析师应用的数据模型。但因为宽表须要预聚合的属性，在遇到维度数据变更的状况，须要通过重跑宽表以实现数据更新。StarRocks 的主键模型不仅能够利用于数据变更场景，同时局部列更新的性能，也高度符合多种业务对宽表中不同字段进行局部更新的需要。
在宽表模型中，个别会有几十上百甚至上千列。这给通过 UPSERT 形式实现数据更新的主键模型带了肯定的挑战。咱们须要取得变更行的所有信息后，能力后实现宽表的数据更新。这使得变更操作会附带上回表读取的操作，须要从 StarRocks 中拉取变更的数据行，而后拼出插入的语句实现数据更新。这给 StarRocks 带来了极大的查问压力。局部列更新的性能（partical update）极大水平的简化 upsert 操作。在开启参数 partial_update 后，咱们能够依据主键，只批改局部指定的列，原有的 value 列放弃不变。
6.png
如上面的例子中，咱们能够通过 Routine Load 导入形式来生产 Kafka 中的数据。在 properties 中须要设置 “partial_update” = “true”，指定开启局部列更新模式，并指定须要更新的列名 COLUMN(id, name)。
CREATE ROUTINE LOAD routine_load_patical_update_demo on example_table COLUMNS (id, name), COLUMNS TERMINATED BY ‘,’ PROPERTIES (“partial_update” = “true”) FROM KAFKA (“kafka_broker_list” = “broker1:9092,broker2:9092,broker3:9092”, “kafka_topic” = “my_topic”, “kafka_partitions” = “0,1,2,3”, “kafka_offsets” = “101.0.0.200”);
StarRocks X Flink CDC，打造极速对立的开源实时数仓平台
Flink CDC 解决了数据链路简短的问题，而 StarRocks 在 OLAP 剖析层提供了极致的性能与一体化的数据存储计划以匹配不同的业务场景。通过 StarRocks 联合 Flink CDC 构建的实时数仓平台的计划，可能极大水平的缩小开发与运维的老本。
StarRocks X Flink CDC，宽表实时数仓架构
7.png
应用 StarRocks 与 Flink CDC 的联结解决方案，咱们能够较为清晰的将实时数仓布局成为四层构造：
数据源层，实时应用层，与原有架构雷同，未做调整
数据传输与计算层，通过引入 Flink CDC，将数据采集层，音讯队列与事实计算层都搁置在 Flink CDC 中，简化了数据链路，缩小了开发与运维老本。
数据分析与存储层，StarRocks 中作为剖析层数据存储引擎，可能提供不同的数据模型撑持不同类型的业务，简化了剖析层数据存储简单的技术栈。
在 ETL 不简单的场景，咱们能够将大部分 ETL 的操作放在 Flink 中实现。在某些场景下，业务模型绝对简略，事实数据与维度数据利用 Flink 多流 join 的能力打平成宽表，在 Flink 中实现了 DWD，DWS 与 ADS 层模型划分。同时对于非结构化的数据，也能够增量写入到 Iceberg、Hudi 或 Hive 中，利用 StarRocks 的表面性能实现湖仓一体的架构。
当 ETL 的过程中引入较为简单的业务逻辑是，可能会在 Flink 计算层占用大量的内存资源。同时，宽表的模式无奈应答查问不固定的多维度剖析场景。咱们能够抉择应用星型模型来替换宽表模型，将数据荡涤与建模的操作放到 StarRocks 中实现。
StarRocks X Flink CDC，实时数据变更架构
在某些简单的业务，如自助 BI 报表，经营剖析等场景中，分析师往往会从不同的维度进行数据探查。查问的随机性与灵活性要求 OLAP 剖析引擎对性能和多种建模形式都有良好的反对，以满足使用者近乎“随便”的在页面上拉去指标和维度，下钻、上卷和关联查问。
对于 StarRocks 而言，能够应用更为灵便的星型模型代替大宽表。为了加强多表实时关联能力，StarRocks 提供了不同的 join 形式，如 Boardcast Join、Shuffle Join、Bucket Join、Replica Shuffle Join、Colocation Join。CBO 会依据表的统计信息抉择 join reorder 与 join 的类型。同时也提供了多种优化伎俩，如谓词下推、limit 下推、提早物化等性能，进行多表关联的查问减速。
8.png
基于 StarRocks 的实时 join 能力，咱们能够将 ETL 操作后置到 StarRocks 中，在 StarRocks 通过实时 join 的形式实现数据建模。同时通过 Primary Key 模型对于数据变更的反对，能够在 StarRocks 中创立迟缓变动维实现维度数据变更。
9.png
通过星型 / 雪花模型构建的实时数仓，能够将计算层 Flink 的建模操作后置到 StarRocks 引擎中。在 Flink 中，只须要做 ODS 层数据的荡涤工作，维度表与事实表会通过 Flink CDC 同步写入到 StarRocks 中。StarRocks 中会在 ODS 层进行事实数据与维度数据的落地，通过聚合模型或物化视图实现与聚合操作。利用 StarRocks 的实时多表关联能力，配合智能 CBO 优化器，稠密索引及向量化引擎等多种优化伎俩，可能疾速计算查问后果，保障业务的在不同模型层的数据高度同源统一。
在现实生活中，维度的属性并非是静止的，会随着工夫的流逝产生迟缓的变动。星型模型能够将事实表与维度表独立存储，将维度数据从宽表中解藕，从而利用 StarRocks 的主键模型解决迟缓变动维的问题。一般来说，咱们有三种计划解决迟缓变动维的问题：
应用主键模型，间接依据主键笼罩原有的维度值。这种形式较为容易实现，然而没有保留历史数据，无奈剖析历史维度变动信息；
应用明细模型，间接增加维度行，通过 version 列来治理不同的维度属性版本，改种计划在查问是须要依据业务条件筛选出适合的维度 version
应用主键模型，在主键中引入 version 信息，混合应用间接批改与新增加维度行的办法，该办法较为简单，但也能更全面的解决简单的维度变动需要
StarRocks X Flink CDC 用户案例
在某出名电商平台业务中，通过应用 StarRocks 与 Flink CDC 极大水平的简化聊数据链路的复杂度。用户通过 StarRocks 构建实时数据看板平台，实现了多维度数据筛选、灵便漏斗剖析、不同维度上卷下钻的灵便剖析。
艰难与挑战
在电商数据看板平台中，最后抉择了 ClickHouse 作为数据分析层的存储引擎。但随着业务的倒退，ClickHouse 在局部场景中无奈无效的撑持，次要体现在以下几个方面：
依据用户下单的操作，局部订单的状态会发生变化。但一般来说，超过两周的订单状态根本不会发生变化；
局部变动的数据不适宜通过宽表的模式存储，局部的业务需要迭代较为频繁，宽表 + 星型模型的建模形式能够更好的服务于业务变更；
ClickHouse 扩缩容操作简单，无奈主动对表进行 rebalance 操作，须要较长的业务保护窗口。
为了解决以上的问题，该电商平台从新做了技术选型。通过一直的比照与压测，最终抉择应用 StarRocks 作为剖析层的数据存储引擎。
零碎架构
10.png
在实时看板业务中，次要能够划分成五个局部：
数据源层：数据源留神有两种，来自 Web 端与客户端的埋点日志，以及业务库中的订单数据；
Flink CDC：Flink CDC 抓取上游的埋点日志与业务数据，在 Flink CDC 中进行数据的荡涤与转换，写入到 StarRocks 中；
数据存储层：依据业务的需要，将 DWD 层中的事实数据联结维度数据拼成宽表，通过视图的形式写入到 DWS 层，在 ADS 层划分出不同的主题域；
数据服务层：蕴含了数据指标平台和漏斗剖析平台两局部，依据外部的指标、漏斗定义进行逻辑计算，最终生成报表供分析师查看；
数据中台：围绕大数据分析平台，提供稳定性保障、数据资产治理、数据服务体系等根底服务；
选型收益
数据传输层：通过 Flink CDC 能够间接拉取上游的埋点数据与 MySQL 订单库中的增量数据。相比于 MySQL -> Canal -> Kakfa -> Flink 的链路，架构更加清晰简略。特地是对于上游的 MySQL 分库分表订单交易库，能够在 Flink CDC 中通过 Mapping 的形式，将不同的库中的表和合并，通过荡涤后对立写入到上游的 StarRocks 中。省略了 Canal 与 Kafka 组件，缩小了硬件资源老本与人力保护老本。
数据存储层：通过 StarRocks 替换 ClickHouse，能够在业务建模时，不用限度于宽表的业务模型，通过更为灵便的星型模型拓展简单的业务。主键模型能够适配 MySQL 业务库中的订单数据变更，依据订单 ID 实时批改 StarRocks 中的存量数据。同时，在节点扩容时，StarRocks 更为简略，对业务没有侵入性，能够实现主动的数据重散布。
性能方面：单表 400 亿与四张百万维度表关联，均匀查问工夫 400ms，TP99 在 800ms 左右，相较于原有架构有大幅的性能晋升。替换 StarRocks 后，业务高峰期 CPU 应用从 70% 降落到 40%。节俭了硬件老本。
在极速对立上更进一步
一款优良的产品，只提供极致的性能是不够的。还须要丰盛的性能适配用户多样的需要。将来咱们也会对产品的性能进行进一步的拓展，同时也会在稳定性与易用性上做进一步的晋升。
日前，阿里云 E-MapReduce 与 StarRocks 社区单干，推出了首款 StarRocks 云上产品。咱们也能够在 EMR 上抉择相应规格的 Flink 与 StarRocks。为了提供更好的应用体验，阿里云 E-MapReduce 团队与 StarRocks 也在一直的对产品进行优化，在将来的几个月会提供以下的性能：
多表物化视图：StarRocks 将推出多表关联物化视图性能，进一步增强 StarRocks 的实时建模能力；
湖仓一体架构：StarRocks 进一步 Apache Iceberg 与 Apache Hudi 表面性能，打造 StarRocks 湖仓一体架构；
表构造变更同步：在实时同步数据的同时，还反对将源表的表构造变更（减少列信息等）实时同步到指标表中；
分库分表合并同步：反对应用正则表达式定义库名和表名，匹配数据源的多张分库分表，合并后同步到上游的一张表中；
自定义计算列同步：反对在源表上新增计算列，以反对您对源表的某些列进行转换计算；
一款优良的产品也离不开社区的生态，欢送大家参加 StarRocks 与 Flink 社区的共建，也欢送大家测试 StarRocks Primary Key X Flink CDC 的端到端实时数仓链路计划。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。