湖仓一体

LakeHouse ?

做一名主要从事OLAP内核研发，对现有湖仓理解做个总结；欢迎批评/指正/讨论

1 为什么湖仓一体这么热：

湖、仓定义这里就不赘述了，大家可以去搜

我理解就是各类数据爆发的公司当前数据平台架构遇到了各类各样的问题，寻求一个适配公司、平台的数据架构，一站式解决，但是大家对湖、仓本质的理解可能都不太一样，那又怎么谈湖仓一体呢。

我也一样，理解一定是片面的，我吸收的内容和我个人脑海呈现的画面也是不一样的，只能尽自己所能，表达清楚对湖仓一体的理解，和面对什么样的业务背景下，我们应该如何围绕我们的平台去做自己的湖仓一体。

首先如果您的数据平台数据在百TB以下，未来数据膨胀有限，我想你没必要看这类文章，围绕自己的理解搭建一套MPP存算一体实时数仓大概率就解决了。

2 分析角度分类：

我想我们首先应该对数据组件分类，然后从应用的角度给尝试他们分类；欢迎大家批评改正：

从数据引擎角度，我们可以将他们分为：数据库，数仓，数据湖。他们也有由于数据膨胀而演化而来的；

从软件架构角度，我们可以将他们分为：单机数据库，分布式数据库，高并发数据库，Serverless；

从数据类型角度，我们可以将他们分为：关系型数据库，非关系型数据库；

关系型数据库，主要是（TP、ROLAP），非关系型数据库，主要是（数据湖，MOLAP)；

从技术复杂度出发，我们将他们分为：事务型数据库：高并发，隔离性强的数据 数仓：没有事务，非严格一致的数据库；

从实效性角度，我们可以讲他们分为：在线数据库(数据库，实时数仓)，离线数据库(数据湖，离线数仓)；

从数据处理的方式/或者说从使用的角度出发，又分为，流式处理和批处理，流又表现出了 在线、实时的特性， 批表现出了 离线、非实时的特性；

从存储性能角度出发：我们分为 寄存器、Cache、Mem、Nvme、SSD、HDD、云硬盘、云盘、对象存储、文档存储、（热、温、冷存)

已经失败的尝试：TP,AP->HTAP 已经宣布了失败，即数据之不可能三角：成本、新鲜度、性能可能同一时刻满足。

3 大数据组件分类：

大数据组件：

MySQL(存算引擎，单机、关系型、实时、结构化数据，事务型数据库)

Flink(存算引擎，流式计算引擎，实时，结构化、半结构化)

OLAP（Doris ClickHouse ADB-MySQL)(存算引擎，实时、关系型，结构化，半结构化，实时数仓)

Trino、MaxCompute(计算引擎，实时、离线)

Spark(计算引擎，批处理、离线、结构化、半结构化)

Iceberg、Hudi、Paimon、DeltaLake (存储引擎，实时、离线、结构化、半结构化、非结构化)

Hadoop(存储引擎，离线、半实时，结构化、半结构化、非结构化)

SnowFlake/DataBricks/RedShift 湖仓一体？

4 从单个产品应用角度分类：

从上面来看，或者从传统数仓角度来看，将上面组件进行了具体分类，即看山是山、看水是水；

我们从产品出发：比如你想到的

ClickHouse 架构一定是：Zookeeper + ClickHouse + 本地存储

ByConity 架构一定是： FDB + ByConity + 分布式存储

Impala 架构一定是： HiveMetaStore + Impala + Kudu/分布式存储

ADB 架构一定是： ADB + 存储/分布式存储

Iceberg 架构一定是： Iceberg + 分布式存储

所以大家有没有发现，一个大家印象中的产品 一定是包含了 元数据 数据 引擎 三个部分的。这里还是要在大脑架构中有清晰的分辨，或者你要将他们理解为就是一样的，都可；

5 演进思考：

接下来就进入，看山不是山，看水不是水环节：

湖仓一体/离在线一体/云原生 是不是一个意思：

从产品角度出发，我认为比如 Iceberg(Iceberg+hdfs/s3)就是湖，大家也可以去搜索下数据湖的定义

离在线一体，很多是表现为产品本身的一体化： 比如

元数据一体化,比如各类自家商业化引擎+一堆External/Multi/Unity/Unified Catalog

引擎一体化：引擎本身跟多事执行模式：如BSP、MPP混合，或者叫智能引擎，目前从文章来看ByConity已经实现；

存储一体化：所有数据统一存储和管理，具体存是否一致，一致管理，这里可能没有限制

云原生：它更多是想表达的服务的ServerLess化，比如引擎本身实现了弹性伸缩，多租户，存储本身实现了按量计费，更多是在云厂商来体现。

最具代表的产品就是 AWS S3,腾讯云COS ...

6 Why湖仓一体

问题：

能力不对等：不同引擎的使用场景、功能支持、性能特点、优化策略、最佳实践..不同；

选型困难：多个引擎意味着技术选型存在多样性，是好事，也是坏事。坏事就是使得决策过程更加复杂，需要权衡不同引擎的优缺点已经现有平台的兼容性；

难长期规划：多引擎工作，会使得在制定长期的技术发展规划过程中更加困难；

数据孤岛：同步引擎之间数据无法有效共享和整合，限制数据分析和业务洞察的能力。

运维成本高：多引擎维护过程中，如部署、兼容、调优、排障、扩缩容 消耗大量时间和精力，使得研发人员的工作变得复杂和繁琐，一旦出现故障，需要快速定位和解决。

易用性低：用户希望自己只关注自身核心业务，而非底层技术，渴望拥有一个简单易用的平台；

使用代价高：底层引擎变更时，用户不愿因为底层引擎的变更而影响他的使用姿势，我们也存在着细粒度的数据访问权限；

问题总结：为了解决问题需要在原有架构上不断引入新的组件，随着业务规模上涨，整体架构难以维系；

行业总结：这些问题是共性，大模型到来为下一代数据平台演进指引了方向；

6 How/What 湖仓一体

我理解它更是一层抽象的逻辑,不解释，接着看您

比如开始MPP叫实时数仓、叫数仓、叫数据库大家可能开始甚至现在都在模糊和怀疑。

长时间内：大概率还是 olap + 数仓 + 数据湖，但是他们之间又存在着千变万化，比如Trino自身是一个查询引擎，但是StarRocks却将其按照一个功能来发展，交互发生了变换，产品也就发生了变化。那么现在是以联邦查询、方言转换的形式出现，那么未来我相信一定是统一。

从产品/应用角度出发，当前可落地方案：

1 从数据湖Adhoc场景，进行平台简单搭建 ：您可以围绕HDFS + Iceberg + Trino + Doris 来快速搭建，HDFS存储，Iceberg 负责元数据和数据格式，Trino负责加速，StarRocks 负责MPP加速， 即湖加速；再加上Doris 自身的MPP能力，也有了批任务回写的能力，进行轻量化ETL;

2 从实时BI报表(离线+实时 传统数仓平台已经已经具备)： 您可以围绕 HDFS + Iceberg + Doris，利用StarRocks 异步物化视图，实现数据聚合和加速，即湖上建仓。

3 从融合角度出发：数据服务统一 Doris统一接受写读服务，数据进行冷热分层，热数据本地，冷数据落入湖，既然是融合的，就需要将冷数据转换为Iceberg Parquet等格式入湖，然后再利用union view,进行冷热数据的聚合；达到数据的一个统一视图，即仓上挂湖,冷热分层；

4 从真正意识上的湖仓一体，那就是云原生了：

One Data：同时支持离线处理和在线分离，解决数据的一致性和实效性；即数据可以不开源；

One Service: 查询服务层，请求入口；

One Engine: 通知支持MPP/BSP调度方式，解决计算吞吐和高性能问题，完全弹性，资源隔离；

从查询角度的出发：以上的使用方式，逻辑上都以OLAP为出口，已经实现了统一查询

从读写角度出发：可能只有第3，4个方案，就实现了完全统一，但是目前国内数仓又或多或少缺少一些能力，包括内部组织架构的一些问题，对进一步迭代有了潜移默化的影响。

希望在对阅读得您有所启发！