58 同城 | 商业数据仓库建设实践

分享嘉宾：钟云云 58 同城 数据架构师
编辑整理：李凯凯
出品平台：DataFunTalk、AI 启蒙者

导读： 早在多年以前在 Hadoop 系列分布式计算与存储、消息中间件还没有成熟的时候，数据仓库主要基于 Oracle 的数仓建设。但随着时间的推移，传统数据仓库的数据计算与存储，已经无法很好地支持海量数据的计算与存储，这样大数据 ( 分布式 ) 技术开始火热起来。本文将为大家介绍 58 数据仓库团队使用 Hadoop 开源技术软件从 0-1 以及 1-N 数仓的建设和演进过程。主要内容包括：

• 商业数仓介绍
• 商业数仓 1.0
• 商业数仓 2.0
• 商业数仓 3.0

01 58 商业数仓介绍

1. 58 数仓规模

随着数据量的不断增加，现在 58 数据仓库每天数据增量在 25TB+；在调度系统上，数据仓库的整体作业为 2000 多个；资源使用情况占用大数据平台整体资源的 1/3 左右；数仓团队人员规模为 15+。

2. 商业数仓架构

58 商业数仓架构分为四层：

• ODS ( 贴源层 )：其中包括埋点的数据采集、传输，离线、实时、多维分析所使用数据的源头；
• DWD ( 明细数据层 )：涵盖了业务数据仓库、客户数据仓库、广告数据仓库、全站用户行为数据仓库等等；
• DWA ( 汇总层 )：集中建设通用性的维度和指标，降低业务开发需求成本；
• APP 层 ( 应用层 )：主要涵盖了业务场景、分析主题、OLAP 多维分析引擎几方面，包括了智慧数、商家参谋、监控平台、效果数据、特征挖掘等应用。

02 商业数仓 1.0

1. 业务背景

① 处于业务初创时期，缺少数据

起步阶段，业务比较单一，所以造成缺少数据的情况。

② 拥有的数据呈爆发式增长

随着技术的发展以及企业和用户的需求，数据呈现爆发式的增长，数据量环比上月增加 100% 左右。在处理数据方面，主要围绕准确性、及时性、稳定性来做，保证数据仓库有准确的数据，并且可以及时看到数据。

2. 技术状况

当时数据传输使用的是 5 年前的技术——rsync ( 凌晨定时把文件 put 搭配 HDFS 文件系统上面，但是存在严重的及时性问题，在调度作业前需要把所有文件到传输到 HDFS 上面去 )；

调度方面——dsap ( 类似 crontab 定时器，可以在指定的时间调度起来作业，但是作业之间没有依赖，稳定性得不到保障 )；

研发方面——MapReduce ( 仓库整体都是使用 MR 代码来实现各项功能，其中开发的效率比较低 )。

3. 调度升级

针对 58 仓库 1.0 的问题，首先是需要解决的问题是稳定性问题，因为 dsap 是属于定时调度，存在超时问题，所以针对调度，短期采用文件依赖的方法，经过不断迭代，最终形成了的 58DP 工具平台。

4. 代码升级

由于底层 ODS、DWD 的数据格式多样，数据处理逻辑复杂，依旧沿用 MapReduce，到了 DWA、APP 层，逐渐改用 Hive SQL 来处理。

5. 传输升级

解决及时性问题上，rsync 换成了 Apache Flume + Kafka 来解决时性问题。

6. 代码优化

针对 ODS、DWD 层的 MR 进行 setup 优化、DistibutedCache 优化，在 APP 层采用通用的 Hive 优化方法进行性了一些优化。

7. 指标标准定义

在数据应用层发布了统一的数据标准，计算标准，指标逻辑含义清晰定义等。

8. 监控

增加了一系列的监控，比如说这个表的数据在某个时间点可以给提供下游，关键指标的监控、作业完成时间的监控、指标波动监控等。

9. 流量来源的划分

• 本文地址：58 同城 | 商业数据仓库建设实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

对于来源划分，采用 SPM 等参数的方式来区分；对于 SEO 等无法通过参数方式来区分的场景，58 这边采用的是通过 Nginx 日志获取一跳 URL，然后再根据相关逻辑进行流量来源划分。

10. 小结

在商业数仓第一阶段主要建设数据稳定性、准确性和及时性。其中 2、3、4 小节主要用来提升稳定性，5、6 小节提升及时性，7、8、9 小节用来提高准确性。

03 商业数仓 2.0

1. 背景

在商业数据仓库 1.0 中，存在两方面的问题：

• 其数据内容不够丰富 ( 不能让数据很好的实现商业变现 )，所以在数仓 2.0 中进行了迭代升级；
• 企业对于实时性的要求不断升级 ( 在数仓底层使用的 Flume+Kafka 组件已经可以支持实时的要求 )，实时和离线多维分析场景支持不够。

2. 全站行为数据建设

PC/M 端：根据用户的一次展现，通过 ID 传到列表页/详情页/行为页，这一套采用的是标准参数传递的方式进行传输。

APP 端：采用 sidDict 参数传递的方式进行数据传输。

主要问题：

• 参数传递涉及到的流程多，保证所有流程、步骤都正确传递的成本极高
• 受业务线迭代影响极大，出现问题排查成本极高
• 用户行为串连匹配率不高，并且已经到达了瓶颈

所以，我们采用状态机的方式，通过用户标识 ( Cookieid、imei ) 进行数据的串联。

效果：

• 串联比例大幅度提升、匹配率 95%+；
• 开发成本减低、可维护性高；
• 扩展性强

3. 息壤

在实时方面进行提升，可以从不同维度、不同粒度看到各个项的实时数据，以供企业、用户及时修正。

实时的技术架构采用的是 Kafka + Sparkstreaming + Druid；目前最新采用的是 Flink 技术。

04 商业数仓 3.0

1. 系统性

在数仓 3.0 阶段，对 DWD 层每个烟囱独立仓库进行整合，即开发数据中台，提高数据的复用性，把数据的能力进一步提升。

把相似的内容进行模型化建设，将异构的数据进行统一化的处理流程。

以 LEGO 广告系统流程为核心，对标到数据处理的流程上，制定标准 ODS 层数据格式，其余老系统数据映射到对应标准 ODS 层，再以数据漏斗形式，进行串联全流程数据，产出 DWD 层表。

2. 产品化

客户：

• 效果数据：客户推广效果数据展示、分析
• 商家参谋：针对供需指数，投放相应数据量的广告

分析决策： 智慧树 ( Dashboard、监控平台 )

技术分析： 实时 ab 测、洞察平台 ( 实时效果，实时监控 )。

05 总结

58 商业数仓目前经历了 3 个阶段，在商业数仓第一阶段主要建设数据稳定性、准确性和及时性；第二阶段主要围绕数据丰富度进行建设；第三阶段主要是围数仓的体系化、产品化的建设。