跟 Amazon 学入门级数据仓库架构

作者：Lewis Gavin

https://medium.com/@lewisdgavin/how-to-architect-the-perfect-data-warehouse-b3af2e01342e

近些年来，从表面上看，我们的数据应用架构都被NoSQL, Hadoop 等大数据热门词眼给霸占了，而传统的数据仓库理论很少有人再提起。从舆论上吞噬整个数仓市场的还有一些小众产品，比如图数据技术，流式计算，分布式存储等等。

我（Lewis Gavin）目前的工作角色是用 Amazon Redshift 来设计数据仓库。以我的经验，无论我们采用的是 Oracle 来搭建数仓，还是以 Hadoop 来搭建 Data Lack(数据湖），基础型的概念还是没有变。

虽然不可否认，NoSQL, Hadoop, Spark 代表的确实是先进的生产力，但万变不离其宗的，还是最底层的那些理论基础。

Preprocessing 

众所周知，在数据完美入库之前，都需要经历一道预处理的过程，它帮助我们清洗掉一些垃圾数据, 将无结构化或半结构化的数据整理成标准维度格式，尤其是数据来源于很多种不同的源头，比如 web, log 文件, 不同数据库厂商或者文本文件时，数据格式化规范显得更为重要。

列举一些常见的数据预处理场景：

1)    将 excel 数据转成 csv ;

2)    解析 Json 数据；

3)    清除有错误，不符合逻辑的数据

当这些预处理都完成的时候，我们把得到的结果集中地存储起来，以便完成数据仓库的数据入库。

项目中常用的集中处理地，可以是 Amazon S3, 也可以是 Redshift. 两者都可以灵活地，低成本地与各种技术集成。当然如果是本地服务器存储而非采用云端服务商技术，完全也没有问题。

Staging

Staging 是任何数据仓库项目都不可避免的一步。

大型的数据仓库都将采集多个不同的业务系统数据，而这些数据都有各自的命名风格或者数据格式。Staging 就是负责存储这些多样化数据的地方。

与平常卸货仓一样，主要负责承载货物，等货物卸载完毕之后，还需要被运往最终的目标仓库或者货架 https://medium.com/@lewisdgavin/how-to-architect-the-perfect-data-warehouse-b3af2e01342e

Staging 只负责简单的存储所有数据仓库范围内的初始化数据，进一步做数据处理和建模，并不在这里实现。

我的个人建议是在 Staging 这一步，我们应该尽量保持数据的原始性（尽管我们可能在预处理的时候，做了一些数据改动），最好表名，表字段都和源系统一模一样，以保证可决策或者报表的可追溯性。

为了更够让决策数据或者报表更加可靠，给数据逻辑问题留下更多证据，Staging 存储的数据，其生命周期应当有一个合理的时间范围，在这个时间范围内，数据是安全的。比如一个工作日，甚至一个月。之后，Staging 的数据可以清理。整体上来说，Staging 区域是一个非持久化的数据层。

脱离了 Staging 区域，数据开始变得格式化，这种格式更适应数据仓库模型的变化。

Master 

在这一层，数据开始发生一些实质性的转化。比如 schema 变得更加模型化，表结构命名更加规范，字段的名字、格式以及数据类型都明确定义正确。

正是这些规范，使得理解这些表以及字段更加容易，使用这些表也更加得心应手。就像老式的学校里归档文案一样方便高效。

当数据从 Staging 流入到 Master 层时，会经过一系列的清洗，比如：

1）标准化所有的时间格式，采用统一的时区；

2）合理的采用四舍五入法处理小数点；

3）处理字符串的大小写，或者去掉前后空格；

4）地址格式保持一致；

5）分割连续的字符串，或者解析 Json 数据

有些用作 Join 关系的字段，我会使他们保持一致。

举个例子，有些用户来自网络日志（ web log），这些用户数据被存在了 MongoDB 里面，而真正的用户广告行为数据，可能存在业务系统中，那么把这些用户抽取到数据仓库时，就要将各自的用户标识字段，命名成一样的名字，这样一目了然知道，这两者的用户是有关系可寻的。

作为一名数据工程师，这点建模功底是必须配备的，也是终极目标：

你必须确保数据被准确命名成可理解的业务逻辑，且保证你的数据模型可以很容易的被下游数据应用调用与计算。

Reporting

之前的基础工作已经做完，到此为止，我们已经完成了准备数据，采集数据，清洗数据，以及建立数据模型。接下来我们的目标就是将数据之金展现给世人去批判，把模型挖掘出来的信息，揭露给读者。这也就是 Reporting 的价值所在。

假如你采用的是 Oracle 的二维表数据仓库结构，此时你应该已经建好了事实表，数据集市(data marts).这些数据模型都非常适合用报表工具做展现，相信我你很快就能上手。

大多数的传统数据仓库采用 oracle 这样的产商来实施，因为其性能特别好。这些系统，优点在于 Join 非常出色，但本质上都是基于行做处理。哪怕只要处理其中很少的列（的数据），存储引擎还是读取整行数据，实际上浪费了不少性能资源。

如果你把数据仓库建立在类似 Amazon Redshift 的列式存储结构上，结果就变了。Redshift 结构下，即使使用宽表（Wide Table）或者多维度与事实共存一表，都能发挥其优秀的性能。

总结下 Redshift 建模的好处：

1）处理宽表的效率比处理复杂Join要高的多；

2）对数据分析师和最终用户更友好，因为他们不需要处理 Join;

3）所有的数据都在一张表里，降低了处理难度

假设，我们需要对用户行为做分析。在 Mastere 层，我们有了 customer, order, marketing log 表，也有了一些日志分析数据。

在 Redshift 的 Reorting 层，我们只需要建立一张 customer 表。

这张 customer 表可以保存很多客户数据，比如注册日期，邮编等（排除那些私人化的信息，比如不需要的联系地址，办公场地等）；

在这些客户基础数据之外，我们还将客户的注册渠道囊括进来，比如手机设备，移动电话应用或者桌面应用等；

在这张宽表里，我们还将客户的统计事实（即产生购物的统计数字），比如总计消费，第一单事件，最近一单时间或者总订单数，一起保存；

除此之外，我们还将市场营销的数据统计事实，比如总共发送的推销邮件数量，最常联系的方式等，一起拉进来保存。

至此，所有的客户维度信息，量化事实都存在了一张表里，借由 Redshift 的高效列式存储及计算功能，分析师可以很方便的计算出他想要的答案，比如购买频次，设备切换次数，是否具有高价值。

不用任何Join, 重活都干完了。

数据仓库的目标就是深挖数据来摘取信息，并不是以便宜的基建或成本取胜。我们要尽可能的用好它，让它更好的服务于我们的分析师，如果足够好，不仅是分析师，更多的潜在用户会选择使用它。

小结:

上面的步骤，讲解了从Preprocessing ( 数据预处理) ，到 Staging, Master, Reporting 的整个数据仓库的组成流。顺着这条路子，你能很容易的建立起一个使用的数据仓库项目。

但要深知，我们的目的不仅仅是可用，可扩展，还要易于用户的理解。

上面的讲述，Staging, Master, Reporting 是我个人的理解，倾向于把这三个步骤作为隔离的物理层来设计，方便每个阶段的输出可被量化。当然你也可以仅仅把他们当做是逻辑层来设计，只要你心中有数，在干什么。

猜你喜欢：

阿里面试题亿级表合并引发的思考之 SQL Bloom Filter(一）

本周阶段性的收获颇丰，我满意了