既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
在此背景下,需要构建⼀个“极速、易用、统一、实时”的数据架构来解决这些痛点:
- 极速:更快的查询速度,最大化提升业务分析人员的效率;
- 易用:对于用户侧的使用和运维侧的管控,都提供了极简的使用体验;
- 统一:异构数据与分析场景的统一,半结构化和结构化数据可以统一存储,多分析场景可以统一技术栈
- 实时:端到端的高时效性保证,发挥实时数据的价值
**二、**构建极速易用的实时数仓架构
采取Doris和Flink 来构建极速易用的实时数仓,具体架构如下图所示。多种数据源的数据经过flink cdc 集成或flink job加工件处理后,入库到Doris或者Hive等湖仓中,最终基于Doris提供统一的查询服务。
在数据同步上,通过Flink CDC将RDS的数据实时同步到Doris。通过Routine Load将kafka等消息系统的数据实时同步到Doris,在数仓分层上,ODS层通常选择明细模型构建,DWD层可以通过SQL调度任务,对ODS数据抽取并获取,DWS和ADS层则可以通过物化视图和Rollup进行构建。在数据湖上, Doris ⽀持为 Hive、Iceberg 、Hudi 以及Delta Lake(todo)提供联邦分析和湖仓加速的能⼒。在数据应用上,Apache Doris 既可以承载批量数据加工处理的需求,也可以承载高吞吐的 Ad-hoc(数据探索) 和高并发点查询等多种应⽤场景。
三、解决方案
3.1 如何实现数据的增量与全量同步
3.1.1 增量及全量数据同步
在全量数据和增量的同步上,采取了Flink CDC来实现。其原理非常简答,Flink CDC实现了基于Snapshot的全量数据同步,基于 BinLog的实时增量数据同步。全量数据同步和增量数据同步可以自动切换,因此在数据迁移过程中,只需要配置好同步的表即可。当Flink任务启动时,优先进行历史表的数据同步,同步完成后自动切换成实时同步。
3.1.2 数据一致性保证
如何保证数据一致性是大家重点关注的问题之一,那么在新架构是如何实现的呢?
数据⼀致性⼀般分为“最多⼀次” 、“⾄少⼀次”和“精确⼀次”三种模型。
- 最多⼀次(At-Most-Once):发送⽅仅发送消息,不期待任何回复。在这种模型中,数据的⽣产和消费过程中可能出现数据丢失的问题。
- ⾄少⼀次(At-Least-Once):发送⽅不断重试,直到对⽅收到为⽌。在这个模型中,⽣产和消费过程都可能出现数据重复。
- 精确⼀次(Exactly-Once):能够保证消息只被严格发送⼀次,并且只被严格处理⼀次。这种数据模型能够严格保证数据⽣产和消费过程中的准确⼀致性。
Flink CDC通过Flink Checkpoint 机制结合Doris两阶段提交可以实现端到端的Exactly Once语义,具体过程分为四步:
- 事务开启(Flink Job启动及Doris事务开启):当Flink任务启动后,Doris Sink 会发起 Precommit 请求,随后开启写⼊事务。
- 数据传输(Flink Job的运行和数据传输):在Flink Job运行过程中,Doris Sink不断从上游算子获取数据,并通过 HTTP Chunked 的⽅式持续将数据传输到 Doris。
- 事务预提交:当Flink开始进行Checkpoint时,Flink会发起Checkpoint请求,此时Flink各个算子会进行Barrier对齐和快照保存,Doris Sink发出停止 Stream Load 写⼊的请求,并发起一个事务提交请求到Doris。这步完成后,这批数据已经完全写入Doris BE中,但是BE没有进行数据发布前对用户是不可见的。
- 事务提交:当Flink的Checkpoint完成之后,将通知各个算子,Doris发起一次事务提交到Doris BE,BE对此次写入的数据进行发布,最终完成数据流的写入。
综上可知,利用 Flink CDC结合Doris 两阶段事务提交保证了数据写入一致性。需要注意的是,在该过程中可能遇到一个问题:如果事务预提交成功、但 Flink Checkpoint 失败了该怎么办?针对该问题,Doris 内部支持对写⼊数据进⾏回滚(Rollback),从⽽保证数据最终的⼀致性。
3.1.3 DDL 和 DML 同步
随着业务的发展,部分用户可能存在RDS Schema的变更需求。当RDS表结构发生变更时,用户期望Flink CDC不但能够将数据变化同步到Doris,也希望将 RDS 表结构的变更同步到 Doris,⽤户则无需担⼼ RDS 表结构和 Doris 表结构不⼀致的问题。
Apache Doris 1.2.0 已经实现了 Light Schema Change 功能,可满⾜ DDL 同步需求,快速⽀持 Schema 的变更。
Light Schema Change的实现原理相对简单,对数据表的加减列操作,不再需要同步更改数据文件,仅需要再FE中更新元数据即可,从而实现毫秒级的Schema Change 操作。由于 Light Schema Change 只修改了 FE的元数据,并没有同步给 BE。因此会产⽣ BE 和 FE Schema 不⼀致的问题。为了解决这种问题,我们对 BE 的写出流程进⾏了修改,具体包含三个⽅⾯。
(1)数据写入:FE会将 Schema 持久化到元数据中,当 FE 发起导⼊任务时,会把最新的 Schema 一起发给 Doris BE,BE 根据最新的Schema对数据进⾏写⼊,并与 RowSet 进⾏绑定。将该 Schema 持久化到 RowSet 的元数据中,实现了数据的各⾃解析,解决了写⼊过程中 Schema 不⼀致的问题。
**(2)数据读取:**FE ⽣成查询计划时,会把最新的 Schema 附在其中⼀起发送给 BE,BE 拿到最新的 Schema 后对数据进⾏读取,解决读取过程中 Schema 发⽣不⼀致的问题。
**(3)数据 Compaction:**当数据进⾏ Compaction 时,我们选取需要进⾏ Compaction 的 RowSet中最新的Schema作为之后RowSet 对应的 Schema,以此解决不同 Schema 上 RowSet 的合并问题
经过对 Light Schema Change 写出流程的优化后, 单个 Schema Chang 从 310 毫秒降低到了 7 毫秒,整体性能有近百倍的提升,彻底的解决了海量数据的 Schema Change 变化难的问题。
有了 上述Light Schema Change 的保证,Flink CDC 能够同时⽀持DML 和DDL 的数据同步。那么是如何实现的呢?
(1)开启 DDL 变更配置:在 Flink CDC 的 MySQL Source 侧开启同步 MySQL DDL 的变更配置,在 Doris 侧识别 DDL 的数据变更,并对其进⾏解析。
(2)识别及校验:当 Doris Sink 发现 DDL 语句后,Doris Sink 会对表结构进⾏验证,验证其是否⽀持 Light Schema Change。
(3)发起 Schema Change :当表结构验证通过后,Doris Sink 发起 Schema Change 请求到 Doris,从⽽完成此次 Schema Change 的变化。
解决了数据同步过程中源数据⼀致性的保证、全量数据和增量数据的同步以及 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年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
[外链图片转存中…(img-oZVH3IvM-1715609291411)]
[外链图片转存中…(img-qsqqvQq3-1715609291412)]
[外链图片转存中…(img-3NaOLkBJ-1715609291412)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新