数据仓库—stg层_有赞数据仓库实践之路

原标题：有赞数据仓库实践之路

一、大数据环境下的有赞数仓

关于数据仓库，在维基百科中将它定义为 用于报表和数据分析的系统，是商务智能 Business Intelligence 的核心部分。在数据仓库诞生之初， 它只被设计成面向管理层所需要的决策支持系统，并不对业务方(这里指各应用系统)提供数据支持。

然而在大数据环境的背景下，当 Hadoop 生态已然成为大数据现实意义上的载体，以 Hive 为基础的数据仓库已经不能仅仅只提供决策支持的需求了—— 它需要同时满足某些业务上对数据的统计需求。

因此，当下的数据仓库应该有一个新的定义： 大数据环境下的数据仓库是指对 全局数据(包含时间和空间：历史的以及所有业务部门的)的 存储及使用的一整套 方法论。

有赞的数据仓库就是在这样一个大数据环境下，同时需要满足内部分析数据和商家侧数据的各类需求。

二、发展历程

有赞的数据仓库经历了混沌期、建设期，目前在成熟期中蜕变着……

2.1 混沌期2.1.1 背景

在有赞大数据的初期，严格来说是没有数仓概念的：没有分层，没有主题域，也没有规范。

当整个 Hive 里就只有一个 st 库，并且不做规范性命名的时候，便会出现两个同名的 mysql 表先后导入同一个库，后者把前者的表结构和数据都覆盖了。

只有一个 st 库的混沌期

没有 ETL 工具，没有工作流的概念(或者说所有任务就是一个工作流)，没有调度平台，当然更不会有数据字典和血缘关系了。

所有的数据处理任务都是用 python 写的，SQL 自然也就都作为字符串写在 python 文件里了。在一个大 python 项目里，任务之间的依赖关系，则是维护在一个配置文件里的。

2.1.2 痛点

可以说在缺乏方法论的混沌期，数仓在稳定性和可用性方面都是存在问题的。

业务方单方面修改了表结构，我们凌晨收到告警；业务方修改枚举值未通知到位，我们凌晨收到告警；集群资源分配不合理，我们凌晨也会收到告警……频繁的凌晨告警、延迟的数据产出、不准确的数据结果、分析人员对数据的吐槽……各类问题交织着，令我们焦头烂额。

2.1.3 Action

随着有赞业务的快速发展，这种烟囱式的开发模式已经支撑不了每天增长的各式各样的数据需求了。

尽管没有用 Informatica 这类商业化的 ETL 工具，但是调度 scheduler 和监控 monitor 的能力却是数据仓库任务必不可少的。于是，在2016年的最后一个季度，有赞开始了基于 airflow 二次开发的数据平台建设，随之也开启了数据仓库的规范之路。

2.2 建设期

2017年初，有赞正式踏上了数据仓库规范之路。伴随着有赞大数据开发平台 的内测，数据仓库首当其冲成为新平台第一个吃螃蟹的人。

2017年6月，我们开始将之前由一堆 Python 文件维护的数据任务开始往大数据平台迁移。迁移持续到了2017年8月，而数据仓库的规范直到今天还在演进……

数据仓库规范首先要考虑的是 分层问题以及随之而来的 主题域划分。伴随着数据仓库的不断建设， 数据权限、 数据字典， 任务资源分配等需求都浮出水面。

2.2.1 数仓的分层

分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。

总体来说，我们将数仓划分为了数据落地层、数据仓库层和数据集市层三部分。作为历史遗迹的 st 层，在迁移过程中被保留了下来——有太多杂乱的任务无法清除，最终在2017年底，被快刀斩乱麻式的一刀切掉了。

数据仓库分层架构图

(1)ODS 落地层

落地层 (Staging Area)