本文发表于： &{ new Date(1666195200000).toLocaleDateString() }

作者：朱齐天，百草味数据部负责人（本文为作者在 StarRocks Summit Asia 2022 上的分享，分享主题是“如何用数据赋能快消品行业提升业务能力”）

快消品的行业特点是“快”，其受众为年轻人，具有高频次、受众广、低客单的特点。百草味作为一家休闲食品品牌运营企业，具备全渠道运营能力（给用户多渠道的选择，包括线上平台和线下商超）。2020年加入百事后，作为百事的子公司，随着业务快速与集团接轨，百草味越来越多的业务需要通过数据来驱动，变得更加合理化、规范化以及高效化。

朱齐天老师主导百草味全渠道从 0 到 1 的数据平台建设、指标体系梳理、数仓模型设计及优化工作。本文主要介绍以下四个部分：

• 数据平台演进心得
• 技术成长源于业务变更
• 概念先行 OR 问题驱动
• 数据架构未来构想

#01 数据平台演进心得

首先和大家分享下百草味数据平台演进的情况：

• 2017 年：为了快速产出，基于 CDH 5.15.0 搭建了一套大数据平台，开发了一些基础功能和几百张报表，实时的报表直接使用了 Stream Computer 和 Quick BI，离线报表以 Apache Hive 为主。
• 2019 年：仍然以 CDH 为主，中间经过两次版本迭代，升级为 6.3.2. 实时数据换成了 Apache Spark 和 Apache Kafka，中间封装了一些工具供团队开发。
• 2020 年：被百事收购以后，线下机房由于不符合合规要求，于是选择上云。考虑维护成本，选择了 Databricks，采用 Data Lake Formation（DLF）和对象存储 OSS 的存储架构。
• 2022 年：由于业务对算力的要求，选择了 StarRocks 和 CloudCanal。

根据上面的探索总结出两种大数据开发平台的优劣：

• 基于 Hadoop 构建：链路长，组件多，数据多次拷贝，维护量大
• 基于 StarRocks 构建：链路短，效率高，开发人员专注业务

1 数字化流程

数字化流程大致的进程为信息化，数字化，再延伸到统一数据平台，可视化分析。

数字化何以在企业中广泛引用，离不开前期企业造词造势造概念和政策的支持与约束。40 年前便有数据仓库的概念，慢慢延伸到数据湖和数据中台。目前企业中的实践，一般以数据仓库为底座，再向上层应用延展。流程需要先有信息化的建设，才有数字化的沉淀，然后进行数字化的赋能。

2 早期数据架构

在数仓构建的过程中会遇到各种问题，例如业务侧发生表结构变更，在 ODS 层也需要变更，在 DWD 和 DWS 层只需要做逻辑层变更，做相对弹性的变更，不需要更新物理数据。
 

这是我们早期的数据架构情况，这是一套比较通用的模型，其优缺点分别为：

• 优点：开源组件比较灵活。
• 缺点：框架比较笨重，运维成本比较高。因为 Apache Hive 没有索引、缓存、组件等功能，业务侧如果发生表结构更新，比较难以操作。

例如，在 ODS 层，新更新的数据有可能是几个月之前的订单，比如订单的状态发生了变更，早期的架构是需要记录更新数据的对应日期，并将对应日期的数据更新一遍，那么 DWS 和 DWD 也要跟着进行变更，这样会带来很大性能问题。

为了应对业务侧的频繁变更问题，使用 Delta Lake，解决了频繁变更和小文件合并问题，但是也会引起 ODS 层的存储过大，需要不断扩展磁盘的问题。

3 新数据架构

传统 Hadoop 体系组件存在以下问题：

• 过于冗余，强耦合
• 数据湖的概念至今没有成熟的产品
• 维护量大，成本高，计算效率低下

基于早期的数据架构，通过简化架构，缩短数据链路，采用 StarRocks 搭建了新的架构。实现三两个组件完成采集、存储计算和可视化。

在数据采集模块，为了保证数据搬运的准确和高效，选择采用 CloudCanal，利用可视化的配置，将 Apache Kafka，MongoDB，Redis 的数据同步到 StarRocks。

CloudCanal+StarRocks 结合使用，带来了很多好处：

• 数据采集方面带来便利
• 使开发人员专注于业务本身，无需关心底层的实现
• 降低了存储成本，因为 DWD 和 DWS 将近一半的表是直接用视图做的，很大程度上减少了数据的拷贝带来的存储压力

4 大数据常用组件

数字化进程中，在初始阶段，没有太多业务流需接入，当各种业务繁杂，需要多种组件参与，涉及到以上多种大数据常用组件。

#02 技术成长源于业务变更

1 不断变化的业务需求

以上是快消品行业按照不同场景划分的各种指标。随着业务的庞杂，指标的计算会变得复杂，需要将数据的并入和计算做得高效，才能应对不断变更的业务需求。面对庞大的业务体系，建立数据指标模型时主要有以下问题：

• 数据模型也要快速变化一应对繁杂多变的指标，贴合业务
• 需求在增加，大数据组件也在增加实效性增强，硬件成本高
• 引入新的业务系统满足新的场景对应的数据源也在不断增加

2 业务建模

为实现数据和指标之间的串联，打破部门墙，增强部门之间的协作，启动全链路数字化项目，打造百草味业务全景图。主要流程为：

从全公司部门业务需求的收集，指标文档的整理，确定计算口径和可视化的样式，到数据的采集和模型的搭建，ETL 的计算，报表的呈现，给业务数据赋能。

借助 StarRocks 搭建业务全景图，极大地减少了时间成本，数据采集速率也提高了，效率相比传统方案有 10-100 倍性能提升，真正意义上实现用户只关注业务。

其中由于财务中心的指标有一套固定的计算准则，因此可以较固定的进行指标构建，而相对灵活的变更需求比较大的业务流程和运营中心，则提供比较好用和合理的模型即可。

3 例子：场景→模型→指标

对于快消行业来说，“进销存”三个环节非常重要。数据打通可以很好地解决控价和库存问题。进销存模型以商品流转的链路为主线，记录 SKU 的流转信息。

StarRocks 对企业数字化的赋能，主要针对两大块业务：前端控好价格，后端管好库存。实现了以下优势：

• 一半物理表一半逻辑视图，减少了一半的调度
• 降低了招聘要求和员工交接的技术成本
• 在数字化进程中，打破了概念先行，真正做到了问题驱动

#03 概念先行 OR 问题驱动

1 概念→产品→解决问题

概念推动产品落地，产品解决业务问题。随着这种开发逻辑的盛行，慢慢意识到开源与商业之间的问题和差距。因此慢慢地淡化一些概念，聚焦于问题本身，降低试错成本。为了解决问题而产生的问题：

• 一堆概念衍生一堆产品去解决一堆问题
• 产品间兼容性问题，高度耦合，到处拷贝
• 一个概念几年没成熟产品，换个新概念集众多产品优势于一身诞生新产品

我们应该多花时间在问题本身上，加速财务自动对账的效率，探索提效降本的可落地方案，完善会员营销的闭环流程，加速商品流转各种场景的数字化模型建设将是我们未来的研究课题。

优化三部曲：

• 改个 SQL，设置个 Session 参数，提高了一个作业的执行效率
• 改进全局参数，升级到更高的版本，加组件，加机器，提高了部分作业的执行效率
• 换一套产品，提高了整体的作业执行效率

#04 数据架构未来构想

StarRocks 可以从以下五个点进行改善和提升，会更有竞争力。

• 统一管理界面：多源增量采集，数据（指标）治理，程序开发调度，运维监控
• 灵活稳定的多表物化视图
• 数据模型可逻辑统一可物理统一，降低数仓模型的深度
• 主键模型（Primary Key Model）持久化索引，完善关系型数据库的 Catalog
• 更好的支持高频写入，加 Buffer 缓冲层，提高采集，计算和极速分析能力