StarRocks实战——百草味快消业务场景下的数仓搭建

吵吵叭火

已于 2024-03-24 11:12:57 修改

阅读量922

点赞数 7

分类专栏： # StarRocks 文章标签：数据仓库大数据

于 2024-03-12 20:40:59 首次发布

本文链接：https://blog.csdn.net/shwaitme/article/details/136662654

版权

StarRocks 专栏收录该内容

36 篇文章 4 订阅

订阅专栏

原文大佬的这篇StarRocks数仓构建有借鉴意义的，这些摘抄下来用作沉淀学习。如有侵权，请告知~

前言

作为百事的子公司，随着业务快速与集团接轨，百草味越来越多的业务需要通过数据来驱动，变得更加合理化、规范化以及高效化。xx老师主导百草味全渠道从0到1的数据平台建设，指标体系建设，数仓模型设计及优化工作。

一、数据平台演进心得

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.1 数字化流程

数字化流程大致的进程为：信息化-->数字化--> 再延伸到统一数据平台-->可视化分析。40 年前便有数据仓库的概念，慢慢延伸到数据湖和数据中台。目前企业中的实践，一般以数据仓库为底座，再向上层应用延展。流程需要先有信息化的建设，才有数字化的沉淀，然后进行数字化的赋能。

1.2 早期数据架构

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

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

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

例如，在ODS层，新更新的数据有可能是几个月之前的订单，比如订单的状态发生了变更，早期的架构是需要记录更新数据的的对应日期，并将对应日期的数据更新一遍，那么DWS和DWD也跟着进行变更，这样会带来很大性能问题。为了应对业务侧的频繁变更问题，使用Delta Lake，解决了频繁变更和小文件合并问题，但是也会引起ODS层的存储过大，需要不断扩展磁盘的问题。

1.3 新数据架构

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

过于冗余，强耦合
维护量大，成本高，计算效率低下

基于早期的数据架构，通过简化架构，缩短数据链路，采用了StarRocks搭建了新的架构，支撑了采集，存储计算和可视化。在数据采集模块，为了保证数据同步的准确和高效，选择采用CloudCanal，利用可视化的配置，将Apache Kafka，MongoDB，Redis 的数据同步到 StarRocks。CloudCanal+StarRocks 结合使用，带来了很多好处：

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

1.4 大数据常用组件

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

二、技术成长源于业务变更

2.1 不断变化的业务需求

上图是快消品行业按照不同场景划分的各种指标。面对庞大的业务体系，建立数据指标模型时主要有以下问题：

数据模型也要快速变化来应对繁杂多变的指标，贴合业务。
引入新的业务系统满足新的场景、对应的数据源也在不断增加。

2.1 业务建模

如上图所示，为了实现数据和指标之间的串联，增强部门之间的协作，借助StarRocks 搭建业务全景图，极大地减少了时间成本，效率相比传统方案有 10-100 倍性能提升，真正意义上实现用户只关注业务。主要流程是：从全公司部门业务需要的收集，指标文档的整理，确定计算口径和可视化的样式，到数据的采集和模型的搭建，ETL的计算，报表的呈现，给业务数据赋能。

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