湖仓一体电商项目（一）：项目背景和架构介绍

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [lansonli.blog.csdn.net](https://lansonli.blog.csdn.net/article/details/125926296)

![](https://img-blog.csdnimg.cn/ce34cf8cabdf4b5a97060e535e673daf.jpeg)

**文章目录**

[项目背景和架构介绍](#%E9%A1%B9%E7%9B%AE%E8%83%8C%E6%99%AF%E5%92%8C%E6%9E%B6%E6%9E%84%E4%BB%8B%E7%BB%8D)

[一、项目背景介绍](#t0)

[二、项目架构](#t1)

[1、实时数仓现状](#t2)

[2、项目架构及数据分层](#t3)

[3、项目可视化效果](#t4)

* * *

一、**项目背景介绍**
-------------------

湖仓一体实时电商项目是基于某宝商城电商项目的电商数据分析平台，本项目在技术方面涉及[大数据](https://so.csdn.net/so/search?q=%E5%A4%A7%E6%95%B0%E6%8D%AE&spm=1001.2101.3001.7020)技术组件搭建，湖仓一体分层数仓设计、实时到离线数据指标分析及数据大屏可视化，项目所用到的技术组件都从基础搭建开始，目的在于湖仓一体架构中数据仓库与数据湖融合打通，实现企业级项目离线与实时数据指标分析。在业务方面目前暂时涉及到会员主题与商品主题，分析指标有用户实时登录信息分析、实时浏览 pv/uv 分析、实时商品浏览信息分析、用户积分指标分析，后续还会继续增加业务指标和完善架构设计。

**二、项目架构**
------------------------

### **1、实时数仓现状**

当前基于 Hive 的离线[数据仓库](https://so.csdn.net/so/search?q=%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93&spm=1001.2101.3001.7020)已经非常成熟，随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于实时数仓建设。根据数仓架构演变过程，在 Lambda 架构中含有离线处理与实时处理两条链路，其架构图如下：

![](https://img-blog.csdnimg.cn/99657ea493084da0a8b2fe8ccb7f8adb.png)

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

![](https://img-blog.csdnimg.cn/e4480b14aaa2431ab5984977b713a774.png)

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 架构将变成个如下模样：

![](https://img-blog.csdnimg.cn/54ef873f94cb4873997b5639158a363c.png)

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

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

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

### **2、项目架构及数据分层**

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

![](https://img-blog.csdnimg.cn/0eadc1104d5b4b2796107b2a97b2bb7e.png)

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

整个架构是基于 Iceberg 构建数据仓库分层，经过 Kafka 处理数据都实时存储在对应的 Iceberg 分层中，实时数据结果经过最后分析存储在 Clickhouse 中，离线数据分析结果直接从 Iceberg-DWS 层中获取数据分析，分析结果存入 MySQL 中，Iceberg 其它层供临时性业务分析，最终 Clickhouse 和 MySQL 中的结果通过[可视化](https://so.csdn.net/so/search?q=%E5%8F%AF%E8%A7%86%E5%8C%96&spm=1001.2101.3001.7020)工具展示出来。

### **3、项目可视化效果**

**![](https://img-blog.csdnimg.cn/9a0686fd16f847528e4f14f86091c08b.jpeg)**

* * *

*   📢博客主页：[https://lansonli.blog.csdn.net](https://lansonli.blog.csdn.net/ "https://lansonli.blog.csdn.net")
*   📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
*   📢本文由 Lansonli 原创，首发于 CSDN 博客🙉
*   📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨