58商业数仓建设实践早在多年以前在Hadoop系列分布

早在多年以前在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小节用来提高准确性。