广州云仓供应链电商基地（湖仓一体电商项目）

广州云仓供应链电商基地（湖仓一体电商项目）“湖仓一体”架构构建也是目前各大公司针对离线场景和实时场景统一处理计算的方式。例如：一些大型公司使用Iceberg作为存储，那么Kappa架构中很多问题都可以得到解决，Kappa架构将变成个如下模样：以上无论是在业务SQL使用上统一还是计算引擎上的统一，都是批流一体的一个方面，除此之外，批流一体还有一个最核心的方面就是存储层面上的统一。数据湖技术可以实现将批数据和实时数据统一存储，统一处理计算。我们可以将离线数仓中的数仓和实时数仓中的数仓数据存储统一合并到数据湖上，可以将Kappa架构中的数仓分层Kafka存储替换成数据湖技术存储，这样做到“湖仓一体”的构建。Kappa架构可以称为真正的实时数仓，目前在业界最常用实现就是Flink Kafka，然而基于Kafka Flink的实时数仓方案也有几个非常明显的缺陷，所以在目前很多企业中实时数仓构建中经常使用混合架构，没有实现所有业务都采用K

#头条创作挑战赛#

项目背景和架构介绍一、项目背景介绍

湖仓一体实时电商项目是基于某宝商城电商项目的电商数据分析平台，本项目在技术方面涉及大数据技术组件搭建，湖仓一体分层数仓设计、实时到离线数据指标分析及数据大屏可视化，项目所用到的技术组件都从基础搭建开始，目的在于湖仓一体架构中数据仓库与数据湖融合打通，实现企业级项目离线与实时数据指标分析。在业务方面目前暂时涉及到会员主题与商品主题，分析指标有用户实时登录信息分析、实时浏览pv/uv分析、实时商品浏览信息分析、用户积分指标分析，后续还会继续增加业务指标和完善架构设计。

二、​​​​​​​​​​​​​项目架构1、实时数仓现状

当前基于Hive的离线数据仓库已经非常成熟，随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于实时数仓建设。根据数仓架构演变过程，在Lambda架构中含有离线处理与实时处理两条链路，其架构图如下：

正是由于两条链路处理数据导致数据不一致等一些列问题所以才有了Kappa架构，Kappa架构如下：

Kappa架构可以称为真正的实时数仓，目前在业界最常用实现就是Flink Kafka，然而基于Kafka Flink的实时数仓方案也有几个非常明显的缺陷，所以在目前很多企业中实时数仓构建中经常使用混合架构，没有实现所有业务都采用Kappa架构中实时处理实现。Kappa架构缺陷如下：

• Kafka无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间的数据，比如最近一周，甚至最近一天。
• Kafka无法支持高效的OLAP查询，大多数业务都希望能在DWD\DWS层支持即席查询的，但是Kafka无法非常友好地支持这样的需求。
• 无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系。
• Kafka不支持update/upsert，目前Kafka仅支持append。实际场景中在DWS轻度汇聚层很多时候是需要更新的，DWD明细层到DWS轻度汇聚层一般会根据时间粒度以及维度进行一定的聚合，用于减少数据量，提升查询性能。假如原始数据是秒级数据，聚合窗口是1分钟，那就有可能产生某些延迟的数据经过时间窗口聚合之后需要更新之前数据的需求。这部分更新需求无法使用Kafka实现。

所以实时数仓发展到现在的架构，一定程度上解决了数据报表时效性问题，但是这样的架构依然存在不少问题，Kappa架构除了以上所说的问题之外，实时业务需求多的公司在选择Kappa架构后，也避免不了一些离线数据统一计算的场景，针对Kappa架构往往需要再针对某层Kafka数据重新编写实时程序进行统一计算，非常不方便。

随着数据湖技术的出现，使Kappa架构实现批量数据和实时数据统一计算成为可能。这就是我们今天听到的“批流一体” 在业界中很多人认为批和流在开发层面上都统一到相同的SQL上处理是批流一体，也有一些人认为在计算引擎层面上批和流可以集成在同一个计算引擎是批流一体，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在计算引擎层面上实现了批处理和流处理集成。

以上无论是在业务SQL使用上统一还是计算引擎上的统一，都是批流一体的一个方面，除此之外，批流一体还有一个最核心的方面就是存储层面上的统一。数据湖技术可以实现将批数据和实时数据统一存储，统一处理计算。我们可以将离线数仓中的数仓和实时数仓中的数仓数据存储统一合并到数据湖上，可以将Kappa架构中的数仓分层Kafka存储替换成数据湖技术存储，这样做到“湖仓一体”的构建。

“湖仓一体”架构构建也是目前各大公司针对离线场景和实时场景统一处理计算的方式。例如：一些大型公司使用Iceberg作为存储，那么Kappa架构中很多问题都可以得到解决，Kappa架构将变成个如下模样：

这条架构中无论是流处理还是批处理，数据存储都统一到数据湖Iceberg上，这一套结构将存储统一后，解决了Kappa架构很多痛点，解决方面如下：

• 可以解决Kafka存储数据量少的问题。目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。
• DW层数据依然可以支持OLAP查询。同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配就可以进行OLAP查询。
• 批流存储都基于Iceberg/HDFS存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。
• 实时数据的更新。

上述架构也可以认为是Kappa架构的变种，也有两条数据链路，一条是基于Spark的离线数据链路，一条是基于Flink的实时数据链路，通常数据都是直接走实时链路处理，而离线链路则更多的应用于数据修正等非常规场景。这样的架构要成为一个可以落地的实时数仓方案、可以做到实时报表产生。

2、项目架构及数据分层

此项目中我们使用的数据湖技术是Iceberg构建“湖仓一体”架构来实时和离线分析电商业务指标。项目整体架构图如下图所示：

项目中的数据来源有两类，一是MySQL业务库数据，另一类是用户日志数据，我们通过对应的方式将两类数据首先采集到Kafka各自topic中，通过Flink处理将业务和日志数据存储在Iceberg-ODS层中，由于目前Flink基于Iceberg处理实时数据不能很好保存数据消费位置信息，所以这里同时将数据存储在Kafka中，利用Flink消费Kafka数据自动维护offset的特性来保证程序停止重启后消费数据的正确性。

整个架构是基于Iceberg构建数据仓库分层，经过Kafka处理数据都实时存储在对应的Iceberg分层中，实时数据结果经过最后分析存储在Clickhouse中，离线数据分析结果直接从Iceberg-DWS层中获取数据分析，分析结果存入MySQL中，Iceberg其它层供临时性业务分析，最终Clickhouse和MySQL中的结果通过可视化工具展示出来。

3、​​​​​​​​​​​​​​项目可视化效果