Overview

记录一下大数据模型的架构演进

Breakdown

lambda

目前lambda的大数据类似这样, 一个flink作stream job. 一个spark作batch job来周期性获取stream job的多个output来作model training.

lambda, 当然这中间可以做出cascade的数据仓库分层模型⁴

lambda arch, credit: ref1

上层链路是离线数仓数据流转链路

下层链路是实时数仓数据流转链路

而这个结构里面有不少割裂点,

• compute engine, flink vs spark, 导致2套数据处理逻辑
• storage, stream(kafka) vs batch(s3), 数据没有统一存放, 导致2套schema, 2套数据metadata管理

kappa

• 如果engine处理得过来, 比如说spark streaming足够low latency, flink batch足够high throughput, 那么compute engine就可以统一起来
• 如果storage处理得过来, 比如low latency write和high throughput read. 支持stream incremental pulling, ACID, flying-CRUD

kappa arch, credit: ref1

上述架构图主要将离线处理链路上的HDFS换成了数据湖iceberg，就号称可以实现实时数仓¹

因此里面最重要的点就是数据湖iceberg. 为什么呢? 是iceberg足够low latency, 足够high throughput吗?

datalake architecture

数据湖技术目前比较famous的分别采用delta lake, iceberg, hudi⁵

这些table format用来协调上层compute engine与下层storage(metadata/format)而引入的中间层(又见架构里面银弹-中间层).

这类table format技术是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种”数据组织格式”, iceberg将其称之为”表格式”也是表达类似的含义. 它与底层的存储格式(比如ORC/Parquet之类的列式存储格式, avro等行式存储)最大的区别是它并不定义数据存储方式, 而是定义了数据、元数据的组织方式, 向上提供统一的”表”的语义⁶

它构建在数据存储格式之上, 其底层的数据存储仍然使用Parquet/ORC等进行存储. 当然底层存储介质依旧是hdfs/s3等⁶

iceberg arch

credit: thenewstack

delta arch

credit: databricks

hudi arch

credit: xenonstack

aws arch

credit: aws

azure arch

credit: azure

Reference

1. 一文了解实时数据仓库的发展、架构和趋势
2. 爱奇艺大数据生态的实时化建设
3. 图文带你理解Apache Iceberg时间旅行是如何实现的?
4. 数据建模是什么?
5. A Thorough Comparison of Delta Lake, Iceberg and Hudi
6. 大数据架构变革进行时：为什么腾讯看好 Apache Iceberg?
7. Apache Iceberg快速入门
8. 数据工程师眼中的 Delta lake
9. 基于Flink+Iceberg构建企业级实时数据湖
10. aws什么是数据湖?
11. 数据湖(Data Lake)总结