分享嘉宾：钟云云 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. 流量来源的划分

对于来源划分，采用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个阶段，在商业数仓第一阶段主要建设数据稳定性、准确性和及时性