导读：早在多年以前在Hadoop系列分布式计算与存储、消息中间件还没有成熟的时候，数据仓库主要基于Oracle的数仓建设。但随着时间的推移，传统数据仓库的数据计算与存储，已经无法很好地支持海量数据的计算与存储，这样大数据 ( 分布式 ) 技术开始火热起来。本文将为大家介绍58数据仓库团队使用Hadoop开源技术软件从0-1以及1-N数仓的建设和演进过程。主要内容包括：
-
商业数仓介绍
-
商业数仓1.0
-
商业数仓2.0
-
商业数仓3.0
0158商业数仓介绍
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个阶段，在商业数仓第一阶段主要建设数据稳定性、准确性和及时性；第二阶段主要围绕数据丰富度进行建设；第三阶段主要是围数仓的体系化、产品化的建设。