盐析白兔

这个屌丝很懒，什么也没留下！

热门标签

Doris实战——结合Flink构建极速易用的实时数仓_flink doris(1)_flink sql 中创建doris表

作者：盐析白兔 | 2024-05-30 18:42:53

踩

flink sql 中创建doris表

解决了数据同步过程中源数据⼀致性的保证、全量数据和增量数据的同步以及 DDL 数据的变更后，一个完整的数据同步⽅案就基本形成了。

3.2 如何基于Flink实现多种数据集成

除了上文中所提及的基于 Flink CDC 进行数据增量/全量同步外，我们还可以基于 Flink Job 和 Doris 来构建多种不同的数据集成方式：

将Mysql中两个表的数据同步到Flink后，在Flink内部进行多流Join完成数据打宽，后将大宽表同步到Doris中。
对上游的Kafka数据进行清洗，在Flinkjob完成清洗后，通过Doris-Sink写入到Doris中。
对Mysql数据和Kafka数据在Flink内部进行多流Join，将Join后的宽表结果写入Doris中。
在Doris侧预先创建宽表，将上游RDS中的数据根据Key写入，使用Doris的部分列更新将多列数据写入到Doris的大宽表中。

3.3 如何选择数据模型

Doris针对不同场景，提供了不同的数据模型，分别为明细模型、聚合模型、主键模型。

3.3.1 DUPLICATE 明细模型

在某些多维分析场景下，数据既没有主键，也没有聚合需求，Duplicate 数据模型可以满足这类需求。明细模型主要用于需要保留原始数据的场景，如日志分析，用户行为分析等场景。明细模型适合任意维度的 Ad-hoc 查询（即席查询）。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列）。

3.3.2 AGGREGATE 聚合模型

在企业实际业务中有很多需要对数据进行统计和汇总操作的场景，如需要分析网站和 APP 访问流量、统计用户的访问总时长、访问总次数，或者像厂商需要为广告主提供广告点击的总流量、展示总量、消费统计等指标。在这些不需要召回明细数据的场景，通常可以使用聚合模型，比如上图中需要根据门店 ID 和时间对每个门店的销售额实时进行统计。

3.3.3 UNIQUE KEY 主键模型

在某些场景下用户对数据更新和数据全局唯一性有去重的需求，通常使用UNIQUE KEY 模型。在 UNIQUE 模型中，会根据表中的主键进⾏Upsert 操作：对于已有的主键做 Update 操作，更新 value 列，没有的主键做 Insert 操作，比如图中我们以订单id为唯一主键，对订单上的其他数据（时间和状态）进行更新。

3.4 如何构建数仓分层

由于数据量级普遍较大，如果直接查询数仓中的原始数据，需要访问的表数量和底层文件的数量都较多，不同层级对数据或指标做不同粒度的抽象，通过复用数据模型来简化数据管理压力，利用血缘关系来定位数据链路的异常，同时进一步提升数据分析的效率，在Doris 中可以通过以下多种思路来构建数据仓库分层：

3.4.1 微批调度

通过INSERT INTO SELECT 可以将原始表的数据进行处理和过滤并写入到目标表中，这种SQL抽取数据的行为一把是以微批形式进行（例如15分钟一次的ETL计算任务），通常发生在从ODS到dwd层数据的抽取过程中，因此需要借助外部的调度工具例如Dolphinscheduler等来对ETL SQL进行调度。

3.4.2 物化视图与Rollup

物化视图本质是一个预先计算的过程，可以在Base表上，创建不同的物化视图或Rollup来对Base表进行聚合计算。通常在明细层到汇总层（例如dwd层到dws层或 dws层到ads层）的汇聚过程中，可以使用物化视图，以此实现指标的高度聚合。同时物化视图的计算是实时进行的，因此站在计算的角度，也可以将物化视图理解为一个单表上的实时计算过程。

3.4.3 多表物化视图

Doris 2.0将实现多表物化视图这一功能，可以将带有 Join 的查询结果固化以供用户直接查询，支持定时自动或手动触发的方式进行全量更新查询结果。基于多表物化视图这一功能的实现，可以做更复杂的数据流处理，比如数据源侧有 TableA、TableB、TableC，在多表物化视图的情况下，用户就可以将 TableA 和 TableB 的数据进行实时Join 计算后物化到 MV1 中。在这个角度上来看，多表物化视图更像一个多流数据实时 Join 的过程。

3.5 如何应对数据更新

在实时数仓构建的过程中，还需面临高并发写入和实时更新的挑战，如何在亿级数据中快速找到需要更新的数据，并对其进行更新，⼀直都是大数据领域不断追寻的答案。

3.5.1 高并发数据更新

在Doris中通过Unique Key 模型来满足数据更新的需求，同时通过MVCC多版本并发机制来实现数据的读写隔离。当新数据写入时，如果不存在相同key的数据则会直接写入，如果有相同key的数据则增加版本，此时数据将多个版本的形式存在。后台会启动异步的Compaction进程对历史版本的数据进行清理，当用户在查询时，Doris会将最新版本对应的数据返回给用户，这种设计解决了海量数据的更新问题。

在Doris中提供了Merge-on-Read和Merge-on-Write两种数据更新模式。

在此我们以订单数据的写入为例介绍 Merge-on-Read 的数据写入与查询流程，三条订单数据均以 Append 的形式写⼊ Doris 表中：

数据 Insert：首先写入 ID 为 1,2,3 的三条数据；
数据 Update：当我们将订单 1 的 Cost 更新为 30 时，其实是写⼊⼀条 ID 为 1，Cost 为 30 的新版本数据，数据通过 Append的形式写⼊ Doris；
数据 Delete：当我们对订单 2 的数据进行删除时，仍然通过 Append ⽅式，将数据多版本写⼊ Doris ，并将 _DORIS_DELETE_SIGN 字段变为 1 ，则表示这条数据被删除了。当 Doris 读取数据时，发现最新版本的数据被标记删除，就会将该数据从查询结果中进⾏过滤。

Merge-on-Read的特点是写入速度比较快，但是在数据读取过程中由于需要进行多路归并排序，存在着大量非必要的CPU计算资源消耗和IO开销。

在1.2.0 版本中，Doris在原有的Unique Key数据模型上增加了 Merge-on-Write的数据更新模式。Merge-on-Write兼顾了写入和查询性能，在写入过程中引入了Delete Bitmap数据结构，使用Delete Bitmap标记Rowset中某一行是否被删除，为了保持Unique Key原有的语义，Delete Bitmap也支持多版本。另外使用了兼顾性能和存储空间的 Row Bitmap，将Bitmap中的MemTable一起存储在BE中，每个Segment会对应⼀个 Bitmap。

写入流程：

DeltaWriter先将数据Flush到磁盘
批量检查所有 Key，在点查过程中经过区间树，查找到对应的 RowSet。
在 RowSet 内部通过 BloomFilter 和 index进行高效查询。

当查询到 Key 对应的 RowSet 后，便会覆盖 RowSet Key 对应的 Bitmap，接着在 Publish 阶段更新 Bitmap，从而保证批量点查 Key 和更新 Bitmap 期间不会有新的可见 RowSet，以保证 Bitmap 在更新过程中数据的正确性。除此之外，如果某个 Segment 没有被修改，则不会有对应版本的 Bitmap 记录。

查询流程：

当查询某⼀版本数据时， Doris 会从 LRU Cache Delete Bitmap 中查找该版本对应的缓存。
如果缓存不存在，再去 RowSet 中读取对应的 Bitmap。
使⽤ Delete Bitmap 对 RowSet 中的数据进行过滤，将结果返回。

Merge-on-Write该模式不需要在读取的时候通过归并排序来对主键进行去重，这对于高频写入的场景而言，大大减少了查询执行时的额外消耗。此外还能够支持谓词下推，并能够很好利用Doris丰富的索引，在数据IO层面就能够进行充分的数据裁剪，大大减少数据的读取量和计算量，因此在很多场景的查询中都有非常明显的性能提升。在真实场景的测试中，通过 Merge-on-Write可以在保证数万QPS的高频Upsert 操作的同时，可以实现性能 3-10 倍的提升。

3.5.2 部分列更新

部分列更新是一个比较普遍的需求，例如广告业务中需要在不同的时间点对同一个广告行为（展示、点击、转换等）数据的更新。可以通过 Aggregate Key模型的replace_if_not_null实现。

3.6 如何进一步提升查询性能

3.6.1智能物化视图

物化视图除了可以作为高度聚合的汇总层外，更广泛的定位是加速相对固定的聚合分析场景。物化视图是指根据预定义的SQL分析语句执行预计算，并将结算结果持久化到另一张对用户透明（用户无感知）但有实际存储的表中，在需要同时查询聚合数据和明细数据以及匹配不同前缀索引的场景，命中物化视图时可以获得更快的查询性能。

在使用物化视图时需要建立Base表并基于此建⽴物化视图，同⼀张 Base表可以构建多个不同的物化视图，从不同的维度进⾏统计。如果数据再物化视图中存在会直接查询物化视图，如果在物化视图中不存在才会查询Base表。

在数据写入或更新时，数据会在写入Base表的同时会写入物化视图，从而保证物化视图和Base 表数据的完全⼀致性。

智能路由选择遵循最小匹配原则，只有查询的数据集⽐物化视图集合⼩时，才可能⾛物化视图。如上图所示智能选择过程包括选择最优和查询改写两个部分：

选择最优：

在过滤候选集过程中，被执行的 SQL 语句通过 Where 条件进⾏判断，Where 条件为advertiser=1。由此可⻅物化视图和 Base 表都有该字段，这时的选集是物化视图和 Base 表。
Group By 计算，Group By 字段是 advertiser 和 channel，这两个字段同时在物化视图和 Base 表中，这时过滤的候选集仍然是物化视图和 Base表。
过滤计算函数，比如执⾏ count(distinctuser_id)，然后对数据进⾏计算，由于 Count Distinct 的字段 user_id 在物化视图和 Base 表中都存在，因此过滤结果仍是物化视图和 Base 表。
选择最优，通过⼀系列计算，发现查询条件⽆论是 Where 、Group By 还是 Agg Function 关联的字段，结果都有 Base 表和物化视图，因此需要进⾏最优选择。Doris 经过计算发现 Base 表的数据远⼤于物化视图，即物化视图的数据更⼩。

由此过程可⻅，如果通过物化视图进行查询，查询效率更⾼。当我们找到最优查询计划，就可以进⾏⼦查询改写，将 Count Distinct 改写成 Bitmap ，从⽽完成物化视图的智能路由。完成智能路由之后，我们会将 Doris ⽣成的查询 SQL 发送到 BE 进⾏分布式查询计算。

3.6.2 分区分桶裁剪

Doris 数据分为两级分区存储，第一层为分区(Partition)，目前支持 RANGE 分区和 LIST 分区两种类型, 第二层为 HASH 分桶(Bucket)，可以按照时间对数据进⾏分区，再按照分桶列将⼀个分区的数据进行 Hash 分到不同的桶⾥。在查询时则可以通过分区分桶裁剪来快速定位数据，加速查询性能的同时实现高并发。

3.6.3 索引查询加速

除了分区分桶裁剪，还可以通过存储层索引来裁剪需要读取的数据量，仅以加速查询：

前缀索引：在排序的基础上快速定位数据
Zone Map 索引：维护列中 min/max/null 信息
Bitmap 索引：通过 Bitmap加速去重、交并查询
Bloom Filter 索引：快速判断元素是否属于集合；
Invert 倒排索引：支持字符串类型的全文检索；

3.6.4 执行层查询加速

Doris 的MPP查询框架、向量化执行引擎以及查询优化器也提供了许多性能优化方式，在此仅列出部分、不做详细展开：

算子下推：Limit、谓词过滤等算子下推到存储层；
向量化引擎：基于 SIMD 指令集优化，充分释放 CPU 计算能力；
Join 优化：Bucket Shuffle Join、Colocate Join 以及 Runtime Filter 等；

四、行业最佳实践

4.1 跨境电商

基于 Doris 构建实时数仓，上游数据源来自 RDS 业务库、⽂件系统数据以及埋点日志数据。在数据接⼊过程中通过 DataX 进⾏离线数据同步以及通过 Flink CDC 进⾏实时数据同步，在 Doris 内部构建不同的数据分层；最后在上层构建不同的数据应⽤，比如自助报表、数据⼤屏。除此之外，它基于应用平台构建了数据开发与治理平台，完成了源数据管理、数据分析等操作。

使用收益**：**

业务计算耗时从之前的两⼩时降低到三分钟。
全链路的更新报表的时间从周级别更新到⼗分钟级别。
Doris 高度兼容 MySQL，报表迁移无压力，开发周期从周级别降低至天级别。

4.2 运营服务商

数仓架构是通过 Flink CDC 将RDS的数据同步到 Doris 中，同时通过 Routine Load 直接订阅 Kafka 中接入的日志数据，然后在 Doris 内部构建实时数仓。在数据调度时，通过开源 DolphinScheduler 完成数据调度；使⽤ Prometheus+Grafana 进⾏数据监控。

使用收益：

采⽤ Flink+Doris 架构体系后，架构简洁、组件减少，解决了多架构下的数据的冗余存储，服务器资源节省了 30%，数据存储磁盘占⽤节省了 60%，运营成本⼤幅降低。基于该数仓架构，在⽤户的业务场景上，可以支持数万次的⽤户在线查询和分析。

4.3 供应链企业

在过去该企业采取了 Hadoop 体系，使用组件⽐较繁多，有 RDS、HBase、Hive、HDFS、Yarn、Kafka 等多个技术栈，在该架构下，查询性能无法得到有效快速的提升，维护和开发成本一直居高不下。

使用收益：

引入 Doris 之后，将 RDS 的数据通过 Flink CDC 实时同步到 Doris ⾥，服务器资源成本得到了很⼤的降低。数据的查询时间从 Spark 的 2~5 ⼩时，缩短到⼗分钟，查询效率也⼤⼤提升。在数据的同步过程中，使⽤了 Flink CDC+MySQL 全量加增量的数据同步⽅式，同时还利⽤ Doris 的 Light Schema Change（轻量表结构变更）特性实时同步 Binlog里的DDL表结构变更，实现数据接⼊数仓零开发成本。

轻量表结构变更Light Schema Change：在Doris1.2版本中，对数据表的加减列操作，不需要同步更改数据文件，仅需要在FE中更新元数据即可，从而实现毫秒级的Schema Change操作。与此同时，使得Doris在面对上游数据表维度变化时，可以更加快速稳定实现表结构同步，保证系统的高效且平稳运转。通过 Flink CDC，可实现上游数据库到 Doris 的 DML 和 DDL 同步，进一步提升了实时数仓数据处理和分析链路的时效性与便捷性。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数大数据工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。