2022年1月9日，StarRocks展示Flink Forward Asia 2021大会开源解决方案专场，StarRocks解决方案架构师谢寅做了题为“双剑合璧：Flink+StarRocks建立实时数仓解决方案”的专题演讲。本文以主讲嘉宾从技艺方案的方位，为社区的小伙伴带来最全、最具体的文字版实录回顾！

本文从之下5个方面推荐：

第一部分，实时数仓技艺的进行趋向和技艺挑战，以及为何Flink+StarRocks能够提供端到端的极速实时数仓体会。

第二部分，推荐甚么是StarRocks，它有哪些技艺特色，擅长的情景是甚么，以及为何作为OLAP层的极速剖析引擎，它能够很好与Flink技艺发展整合。

第三部分，要点推荐结合Flink和StarRocks两大技艺栈建立实时数仓的方法论。

第四部分，推荐少许应用Flink和StarRocks建立实时数仓的最好实践案例。

第五部分，展望了StarRocks在实时数仓方向以及Flink社区奉献等方面的延续规划。

1.实时数仓概述

随着各行各业对数据越来越重视，实时计算技艺也在不停的演进。从时效性上来说，关于小时级或许分钟级的计算曾经不行满足消费者营业的须要，要求渐渐从时窗驱动，进级到事故驱动，甚而每发生一条数据，都想尽快见到数据。ETL进程也从离线或许微批的ETL，变为Flink擅长的实时流式料理。

数据源上，早先只能扶持单一的数据源，全体的数据体现力较差。而当下，大家不但期望能对单一数据流发展剖析计算，还期望能结合若干数据源发展多流计算，为这不惜想尽一切法子，来让数据的体现力愈加丰富。

从工程效能的方位上看，技艺团队也渐渐意识到，工程代码开发的本钱高企不下，更期望能建立本人的平台化IDE用具，让营业人士能鉴于其上干脆发展FlinkSQL的开发。在这点演进的进程也渐渐浮现出少许技艺难点亟待解决，例如：

·乱序数据怎样更没有问题料理?

·经过Watermark之类的伎俩，是让往日的数据随即失效，仍是期望全部的明细数据全能入库?

·多流Join到底应当怎样做适合?

·维表是一次性加载进来，仍是放在外存储做热查询，除此之外另有无其它的技艺抉择?

·数据料理作业一朝重启，怎样确保在规复以后还能做到不丢不重的续接花费?

·怎样才能提升全体的营业开发效能，确保营业上线时无营业中断，更高雅快速便捷的发展营业逻辑迭代?

在此之外，另有一件事也是营业人士或平台架构师最关心的，那便是经过Flink那么强盛的实时计算引擎，费劲千辛万苦好很难把计算层效能从小时级或许分钟级的延迟提高到了秒级，结果现存的OLAP产物拖了后腿，查询耗费了好几分钟，辜负了计算团队的大批心血。

以上种种，充分声明了极速OLAP+实时计算的要紧性，以此咱们就能塑造一套端到端的极速实时数仓解决方案，即所谓“双剑合璧”！

谈到数仓，日前业界落地较多的仍是Lambda架构，也便是离线数仓和实时数仓分开建立。逻辑分层的方式，也根本造成了业界的共识。营业数据有的是RDBMS采集上来的，有的是日志采集上来的，有的是批量抽取上来的，有的是CDC或许流式写上来的。原始操作层(ODS)根本皆是维持数据原貌，接下来通过维度扩展、清洗过滤、转换，建立成明细层(DWD)。再往上层走，数据最初做轻度聚合，并有原子目标显露。最终依照专题或许利用的须要产出ADS层里的派生目标或许衍生目标。

公司建立实时数仓，为了让全体的逻辑清楚，平常概况下也会沿用这类分层形式，只只是受限于实时数据到达的先后概况以及营业须要，可能会有些档次的裁剪，不像离线数仓里那末丰富。当中的少许维度消息，可能会同一时间被离线数仓和实时数仓共享运用。最终将数据送入OLAP产物，供报表体系、接口或许Adhoc查询所调用。

鉴于前面临数仓典范逻辑分层的研究，难题也随之而来：

能否有一款OLAP产物能够很没有问题和Flink联合，满足持续的秒级的数据摄入和极速剖析查询能力?

谜底是必定的，StarRocks的定位正是要提供极速剖析查询能力，来适应各式各类的OLAP情景。

2.StarRocks是甚么

这是StarRocks的宏观架构图。

从左边咱们可行见到常见的Kafka、分布式文献体系、惯例关连型数据库，都可行作为StarRocks的数据源。

StarRocks提供了4种模子：

·假如营业情景只涉及数据的持续Append，可行抉择Duplicate明细模子，在其上可行实时建立物化视图提速DWS层查询；

·假如营业情景不关心明细的下钻，StarRocks另有Aggregate聚合模子表，差不多于数据干脆秒级打入DWS层，满足高并发的聚合目标查询；

·关于ODS层做营业库数据还原时，若涉及到数据革新的场合，可行采纳Unique模子，应用Flink的Append流Sink数据进来，达成ODS数据去重和革新；

·此外，StarRocks全新2.0版本提供的PrimaryKey主键模子，比Unique模子查询功能快3倍以上，内置了OP字段来标志Upsert/Delete操作，而且能够很没有问题吻合Flink的Retract回撤流语义，聚合计算不必非要开窗转为Append流来Sink，进一步加强了FlinkSQL的体现力。

StarRocks还提供了逻辑View和物化视图，提供了更丰富的建模能力。

在上图的右侧是StarRocks的物理架构，全体仍是十分简练的，最重要的便是两种角色：FE前端节点和BE后端节点。

·FE负责查询规划、元数据治理、集群高可用，并包涵CBO改良器，为分布式多表关联和繁杂Adhoc查询提供最优的执行规划。

·BE节点承载了列式存储引擎和周全向量化的执行引擎，保证在OLAP剖析情景中提供极速查询体会。

·对上层利用提供MySQL接连合同，可行用MySQL消费者端轻松连入发展开发和查询，和主流BI用具有很没有问题兼容性，也可行效劳于OLAP报表和API封装。

3.StarRocks擅长哪些情景

鉴于StarRocks的4种模子，可行提供明细查询和聚合查询，能够应对OLAP报表的上卷和下钻，例如在广告主报表情景应对高并发点查询。

StarRocks鉴于Roaring Bitmap提供了Bitmap数据构造，并配套有集合计算函数，可行用于精准去重计算和使用者画像的客群圈选营业。在实时方面，StarRocks可行用于支撑实时大屏看板、实时数仓，秒级延迟的表现营业原貌和数仓目标。

最终，鉴于CBO改良器，StarRorcks在OLAP情景下有很没有问题多表关联、子查询嵌套等繁杂查询的功能，可行用于自主BI平台、自主目标平台和即席数据探查等自主剖析情景。

StarRocks能足够使用于建立实时数仓，得益于他的三种实时数据摄入能力：

·可行干脆花费Kafka的信息。

·可行借助Flink-connecor实现Exactly-once语义的流式数据摄入。

·此外，联合Flink-CDC和PrimaryKey模子，可行实现从TP库Binlog实时同步Upsert和Delete等操作，更没有问题效劳于ODS层营业库还原。

应用Flink-Connector-StarRocks插件，可行实现从TP库Binlog实时同步Upsert和Delete等操作，更没有问题效劳于ODS层营业库还原。配套的SMT(StarRocks Migration Tool)用具，可行自动映射Flink中的TP库Source和StarRocks库的Sink建表语句，让得鉴于FlinkSQL的开发事业变得容易便利。

此外，Flink-Connector更要紧的功效是提供了通用Sink能力，开发者把依赖加入后，不论是工程编码仍是FlinkSQL都可行轻松Add Sink，保证数据秒级引入时效性。

联合Flink的Checkpoint体制和StarRocks的引入事务标签，还可行保证不丢不重的精确一次引入。

StarRocks的实时物化视图建立能力，联合Flink-Connector的持续增加数量数据引入，可行在流量类目标计算的建模中，实现DWD明细数据引入达成的同一时间，DWS聚合目标也同步增加数量建立达成，极大提高聚合目标产出效能，缩小分层ETL的旅程。

StarRocks提供的Replace_if_not_null能力相比有意思，正如语义所述，只需插入的数据非是null，那末就能去替换数据。

如图所示，右侧是个建显示例，内部维度列为日期和Uid，其余3列中SRC显示数据源，此外带了v1，v2两个Metric；

经过2个Insert语句咱们可行见到，来源2个Kafka专题的数据源的数据，轻松的实现了同一时间写入一张表的不同列。因而，这种功效提供了两种实时数仓能力：

1)Join on Load，也便是在引入的进程中，鉴于StarRocks来实现流式Join。

2)部分列革新能力。

StarRocks为了扶持更没有问题Upsert/Delete，提供了PrimaryKey表模子。

如上图所示，最左侧是经典的LSM模子，也便是Merge-on-Read的方式。这类模子写入时不用去判断既有键位，对写友好，但读取时须要Merge合并，是以对读取数据不友好。

而最右侧是Copy-on-Write的模子，典范的产物便是DeltaLake。这类模子和LSM正在相反，有相比没有问题读效能，可是关于写入非是很友好。

相比平衡读取和写入的，便是上图当中的两种Record等级冲突审查的模子，Kudu的Write Delta和StarRocks的Delete+Insert模子。

源于维护了内存表，PrimaryKey模子更符合冷热特征显著的场合，对热数据频繁的革新和删除更友好；

此外十分符合PrimaryKey不多的表(如使用者画像的宽表)，尽管列好多，可是主键本来唯有UUID这类字段。

StarRocks早期的Unique模子便是采纳了最左边的LSM模子，因而查询效能较差，而且关于Delete不友好，联合Flink开发利用时，只能运用Append流发展Sink。

StarRocks 2.0版本中新加加的PrimaryKey模子，提供了软删除字段，经过在内存中维护全新数据，让得查询时幸免了Merge的进程，从而极大提高了查询功能，而且既可行运用Append流也可行运用Retract流发展Sink，丰富了与Flink联合时的利用情景。

4.建立实时数仓的详细方法

众所周知，在依照逻辑分层自下而上的建立实时数仓时，多流Join是有必定的技艺门槛的。惯例的实时计算引擎如Storm、Spark Streaming在这方面做的都非是很好。而Flink本来提供了好多通用的解决方法，如：

·鉴于MapStat做状况计算，或许BroadcastStat将维度缓存广播出来；

·用Flink关联外部热存储，如HBase/Redis等；

·少许相对稳固、革新频次低的维度数据或许码表数据，可行应用RichFlatMapFunc的Open方法，在发动时就悉数加装到内存里；

不限于以上这点，本来Flink曾经在维度扩展上，给了开发者好多可行落地的抉择。然则有了StarRocks，咱们会有更多的想象体积。

例如应用前面推荐的Replace_if_not_null的能力，开发者可行实现若干数据源稀疏写入宽表的不同列，来实现Join-on-Load的成果。

此外StarRocks强悍的CBO改良器在多表关联查询能力方面也体现优异，假如数据量适中或许在查询并发不高的情景，甚而可行把Join的逻辑下推到OLAP层来做，这样可行解放掉Flink上的少许建立负荷，让Flink专注于清洗和稳固的数据引入，而多表关联和繁杂查询等营业逻辑在StarRocks上发展。

不但如许，还可行联合Join-on-Load和Join on StarRocks的两种方式，也便是稀疏写入局限张表，经过表之中做Colocation join战略，确保局限的表之中数据分布绝对，做Join的时刻无节点间Shuffle，在上层建立逻辑View面向查询。

双剑方案1.微批调整

Flink清洗引入Kafka的日志或许用Flink-CDC-StarRocks读取MySQL Binlog引入StarRocks，ETL进程中埋入批次料理时间，采纳外围调整体系，鉴于批次料理时间筛选数据，做分钟级微批调整，向上建立逻辑分层。

这类方案的最重要的特色是：StarRocks作为ETL的Source和Sink，计算逻辑在StarRocks侧，适用于分钟级延迟，数据体量适中的情景。

双剑方案2.Flink增加数量建立

实时信息畅通过Kafka接?，采纳Flink进?流式ETL、多流Join、增加数量聚合等，在内存中达成分层建立，接下来将相应的数据，层对层的经过Flink-connector写出到StarRocks对应表内。各层按需面往下游提供OLAP查询能力。

该方案的最重要的特色是：计算逻辑在Flink侧，适用于须要前导做较重ETL的情景，StarRocks不参加ETL，只承载OLAP查询，应对较高QPS查询负荷。

双剑方案3.StarRocksView视图

Flink清洗引入Kafka的日志或许用Flink-CDC-StarRocks用具读取MySQL Binlog引入StarRocks；依据须要采用明细、聚合、革新、主键各式模子，只物理落地ODS和DIM层，向上采纳View视图；应用StarRocks向量化极速查询和CBO改良器满足多表关联、嵌套子查询等繁杂SQL，查询时现场计算目标结果，确保目标上卷和下钻高度同源绝对。

该方案最重要的特色是：计算逻辑在StarRocks侧(现场查询)，适用于营业库高频数据革新的情景，实体数据只在ODS或DWD存储(未来StarRocks提供多表Materialized Views，将来会进一步提高查询功能)。

5.最好实践案例

前面咱们推荐了少许结合Flink和StarRocks建立实时数仓的几种方法论，下方咱们来看4个实质的消费者案例。

车子之家日前在智能介绍的成果剖析、物料敲击、曝光、计算敲击率、流量宽表等情景，对实时剖析的要求日渐强烈。通过多轮的探寻，终归选定StarRocks作为实时OLAP剖析引擎，实现了对数据的秒级实时剖析。

在数据料理过程上，SQLServer、MySQL、TiDB等数据源，经过CDC打入若干Topic专题，用FlinkSQL发展ETL清洗和聚合计算，接下来经过Flink-Connector引入StarRocks。早期抉择的Unique表模子，源于营业有好多Delete操作，而Merge-on-Read的模子对Delete扶持不好，假如只做Update而不做Delete，会形成结果数据比营业库多的难题。

全新的PrimaryKey模子扶持了OP字段(革新/删除操作)，改成PrimaryKey模子后，数据结果与上游营业十足绝对。

上图右侧是在硬件配置6x 48c 256G、数据量3500W+、有持续写入概况下，22个SQL用例的测试概况，查询功能也比Unique模子有大幅提高。

在合乎道理的选型和建模以后，车子之家在实时平台IDE上也做了好多事业，开发运维人士可行在页面里发展DDL建表，FlinkSQL开发，作业的起停、上线治理等事业。联合Flink-Connecotor，可行干脆经过FlinkSQL将加工后的数据引入StarRocks，达成端到端的实时平台集成。

此外，应用StarRocks提供的200若干监控Metric，车子之家庭用Prometheus和Grafana等组件做了充分的可见化监控，即时察看集群的统算目标，把握集群的健康状况。

第2个案例，顺丰科技的运单剖析情景实践。在2021年双11大促运动中，运单剖析情景应对了15w TPS信息体量的实时数据引入和革新。全体的料理过程如图所示，若干营业体系中的数据源打到几个Source Kafka，用Flink来对数据发展加工、字段补充、从新组织，接下来梳理后的数据打到多个个Sink Kafka专题，最终应用前面推荐的Join-on-Load的方式，将若干数据源的数据，稀疏的写入宽表的不同列，以此来实现宽表拼齐的进程。

在详细运用上，顺丰科技将运单的数据依据革新的频度，划分为了2张宽表，依照相同的数据分布做成Colocation组，确保Join的时刻无格外的节点Shuffle。一张表涉及的革新不多，命名为公表。另一张表涉及的革新较多，命名为私表。

每个子表都应用了Replace_if_not_null的部分列革新的能力，合乎道理的设置了维度和聚合目标，并导入了Bloom Filter索引提速筛选的效能，用日期做范畴分区，用定单号做数据分布，配置了动态分区，自动淘汰冷数据。对外经过逻辑View的方式关联成一张宽表，底层所以现场Join的方式，全体面向营业提供查询效劳。

第3个案例是来源多点DMALL的实时数仓实践。实时革新情景最重要的对实时监控经营的各项目标发展剖析，如当前时间段内的GMV、下单数量、妥投数量、目标完成、对照、环比等目标剖析，为消费者的经营决策提供更具时效性的参考根据。

早期，针对数据为实时(秒级)革新的情景，最重要的运用Impala on Kudu引擎，采纳Lambda架构，鉴于相同的主键，将流式的估计算的结果数据、批计算的结果数据，鉴于相同的主键发展Merge。

这种Case早期的架构如左图所示，ODS、DWD、DWS等分层在Kafka里承载，ADS层在Kudu/MySQL里，维表放到HBase里，采纳Flink查询外貌热存储的方式实现维度数据和实是信息的关联。如右图所示，通过整理和改装，顺丰科技将DWD到DWS的聚合料理从Flink下沉到OLAP层，用StarRocks替换了Kudu，简单化了预聚合链路，提高了开发效能。

第4个案例是来源一种某车联网公司的Fusion数仓建造。随着新燃料车子的普遍，车联网IOT数据的实时接入剖析的要求也越来越多。

营业逻辑如左图所示，传感器上报的仪表、空调、启动机、全车操控器、电池电压、电池温度等1000+传感器Metric要经过Flink做实时ETL清洗，同一时间要达成功效专题实时分拣、数据品质实时汇报，终归满足于时序数据概括剖析和可见化展现。技艺上，大批采纳Flink.Jar的工程代码开发，关于某些码值还涉及到Flink多流Join及状况计算。流量类的专题，采纳StarRocks的增加数量聚合模子出聚合目标。也应用FlinkSQL关于运营剖析类营业发展了实时数仓建立，将ADS层结果引入StarRocks供同一接口查询。

全体上也是依照Lambda模子设置的，FLink清洗整合后的合规数据，会经过落盘程序沉降到HDFS，用于持久存储、离线数仓发展跑批及更繁杂的模子训练，终归Hive的结果数据也会送到StarRocks供接口查询运用。

数据逻辑设置如右图所示，上面为离线数仓，下方为实时数仓逻辑分层。

可行见到实时清洗后的DWD层数据会成为离线数仓的ODS层，而离线数仓建立没有问题少许相对固定的维表数据，也会用于实时数仓的流式维度扩展。实时数仓的逻辑分层相较于离线数仓更为简约，DWD明细层会存留于独立的Kafka或许在Flink内存中，DWS层在FlinkSQL聚合达成后就干脆下沉到StarRocks了。

这边本来是发展了二次聚合，在Flink里发展了秒级的聚合，而StarRocks里的时间消息相干的维度列是到分钟或许15分钟的，应用StarRocks的聚合模子，将Flink汇聚的5-10s的聚合结果，再一次汇聚到分钟级键位。这样设置有两个好处，第一，能够降低LSM模子的Version版本，提高查询功能；第二，抽稀到分钟级后，更便于可见化展现，下降了前端取数的负担。

6.实时即未来，StarRocks延续规划

对于PrimaryKey模子，延续版本将要扶持部分列革新，进一步丰富TP营业库还原的能力；并在PrimaryKey模子上扶持Bloom Filter、Bitmap等索引能力，进一步提高数据查询功能。

资源隔离方面，延续StarRocks会发表自适应内存、CPU分配能力，消费者没再须要手动调度配置参数；未来也会扶持多租户资源隔离的Feature。

关于Apache Flink名目的奉献方面，当前Flink-Connector-StarRocks还只具有Sink能力，延续会在Source方面提供支撑，届时使用者可行经过Flink分布式读取StarRocks数据，用FlinkSQL做跑批任务。

此外，在CDC适配上，延续也会提供Oracle/PostgreSQL等更丰富的TP库的DDL自动映射能力，适应更多CDC利用。

在云原生时期，StarRocks曾经最初了踊跃探寻和实践，很快就会提供存储计算分离、异域容灾等能力，为消费者提供弹性、可靠的OLAP层查询剖析体会。

以上便是本次分享的悉数内容。实时即未来，欢迎大伙一同加入到Apache Flink和StarRocks社区建造，一同探寻出更多实时数仓的最好实践。