数据处理层中数据仓库的建设

本文将重点探讨数据处理层中数据仓库的建设。早期的数据服务中存在不少问题，虽然在做运营Dashboard系统时，对后台数据服务进行了梳理，构建了数据处理的底层公共库等，但是仍然存在一些问题：

1.中间数据流失，计算结果没有共享。比如在很多数据报告中都会对同一个功能进行数据提取、分析，但是都是各自处理一遍，没有对结果进行共享。

2.数据分散在多个数据源，如MySQL、MongoDB、Elasticsearch，很难对多个源的数据进行联合使用、有效组织。

3.每个人都需要非常清楚产品业务逻辑才能正确地提取、处理数据，导致大家都将大量时间耗费在基础数据处理中。

于是，我们考虑建设一个适于分析的数据存储系统，该系统的工作应该包含两部分：第一，根据需求抽象出数据模型；第二，按照数据模型的定义，从各个数据源抽取数据，进行清洗、处理后存储下来。

虽然数据仓库的学术定义有很多版本，而且我们的系统也没有涉及到多部门的数据整合，但是符合上述两个特点的，应该可以归结到数据仓库的范畴了。

下图所示，为现阶段我们的数据仓库建设方案。数据主要来源于MySQL和MongoDB中的业务数据、Elasticsearch中的用户行为数据与日志数据；ETL过程通过编写Python脚本来完成，由Airflow负责任务流的管理；建立适于分析的多维数据模型，将形成的数据存入MySQL中，供数据应用层使用。

可以看到，数据仓库本身既不生产数据也不消费数据，只是作为一个中间平台集中存储数据，整个系统实现的重点在于数据建模与ETL过程，这也是日常维护中的重点。

存储选型

将数据落地到哪里是首先要考虑的问题，笔者考虑的因素主要有这么几点：一是数据量大小和增长速度，二是要能实现SQL或者类SQL操作，有多表联合、聚合分析功能，三是团队技术栈。可选的技术方案有MySQL、Oracle和Hive，最终选择了基于MYISAM存储引擎的MySQL，部分原因如下：

1.要不要Hadoop? 生产业务数据库与用户行为数据增长均比较缓慢，预计在接下来的一年里数据仓库的总存储量不会超过500GB 。因此现阶段接入Hadoop的意义不大，强行接入反而会降低工作效率。而且团队主要技术栈是Python，使用Python操作Hadoop本身就会有性能损耗。

2.为什么是MySQL? 相比Oracle，团队对MySQL更加熟悉

数据建模

根据数据分析的需求抽象出合适的数据模型，是数据仓库建设的一个重要环节。所谓数据模型，就是抽象出来的一组实体以及实体之间的关系，而数据建模，便是为了表达实际的业务特性与关系所进行的抽象。

数据建模是一个很宽泛的话题，有很多方法论值得研究，具体到业务上不同行业又会有不同的建模手法。这里主要结合我们的实践来简单地谈一些认识和方法。

目前业界有很多数据建模的方法，比如范式建模法、维度建模法等等。遵循三范式，我们在做业务数据库设计时经常会用到，这种方法对业务功能进行抽象，方便功能扩展，但是会额外增加分析的复杂度，因此笔者更倾向于维度建模法。

1.维度表与事实表。比如，分析“某地区某商品某季度的销量”，就是从地区、商品、时间（季度）三个角度来观察商品的销量，维度表有地区表、商品表和时间表，事实表为销量表。

2.星型模型与雪花模型。两种模型表达的是事实表与维度表之间的关系。二者的区别在于，雪花模型一定程度上降低了信息冗余度，但是合适的冗余信息能有效的帮助我们提高查询效率，因此，笔者更倾向于星型模型。

举个例子，业务场景是：一款做连锁企业招聘工作的产品，比如为麦当劳的所有连锁门店招聘员工，现在要分析“每家门店的招聘情况如何？”。

结合具体业务，我们引入六个维度：时间维度、地区维度、品牌维度、门店维度、职位维度、申请渠道；数据指标上，主要有申请工作人数、申请工作次数、聘用人数、拒绝人数，每个指标分别有增量值和总量值两种；数据粒度上，时间维度细分到以小时为单位，地区维度细分到市一级。

下图所示便是相应的星型模型，有三点值得一提：

1.可以看到我们只建立了四张维度表，地区维度和渠道维度是直接以字符串的形式放到事实表中的。这是维度设计中经常遇到的一个问题：如果这个维度只有一个属性，那么是作为单独的一张表还是作为事实表的一部分？其实并没有完全对与错的答案，只有是否适合自己的答案。这里，城市与渠道的信息并不会发生变化，所以放入事实表中可以避免联合查询。

2.建立了统一的时间维度，可以支持各种时间统计方案，避免在查询时进行时间值运算。

3.在品牌维度、门店维度、职位维度三张表中，都有prod_xxxx_id的字段，其值是产品业务数据库中相应数据的id，作用是为了与业务数据库中的信息进行同步。当业务数据库中的相关信息发生变化时，会通过ETL来更新数据仓库中的信息，因此我们需要这样的一个字段来进行唯一标识。

ETL

ETL这块，由于前期我们做了不少工作来构建底层数据分析公共库，能有效的帮助我们进行数据抽取与处理，因此，现阶段还没有引入诸如Kettle这样的开源工具，主要采用编写Python脚本来实现。这里主要谈谈增量更新机制与任务流管理两个问题的策略。

1、增量更新机制

增量更新的背景是这样的：第一，上面有提到，对于可变的维度表，我们添加了prod_xxxx_id字段来唯一标识，实现信息覆盖更新。

对于事实表，为了反映历史状态，表中的数据通常是不可逆的，只有插入操作，没有删除或者修改操作，表示在过去一段时间内完成的事实业务数据，更新的方法就是插入新的数据。

第二，ETL通常是近实时的，需要依赖schedule触发更新，因此每次需要更新的信息就是上一次更新时间与当前时间之间的变化数据。笔者采用的策略是：

建立一张temp表，表中有last_update_time与etl_name两个字段；

每次更新时，首先查询出相应的etl_name的最近一条记录，取其中的last_update_time作为起始时间，取当前时间为结束时间；

抽取数据源中在这段时间内变化的数据，作为ETL过程的输入，进行处理；

更新成功时，插入一条数据，last_update_time为当前时间。

2、Airflow任务流管理系统

在早期数据服务中，我们主要依靠crontab来运行各个任务，随着业务增多，任务的管理变得越来越吃力，体现在以下几方面：

查看任务的执行时间和进展不方便。每次需要查看某个任务的执行情况时，都要登录到服务器上去查看命令行的执行时间、log在哪里，通过ps来查看当前进程是否在运行等等。

任务跑失败后，没有通知与重试。

任务之间的依赖关系无法保证，完全靠预估，然后在crontab里设定执行时间间隔，经常出现上游还没有处理完，下游就启动了，导致脏数据的产生。

以上便是现阶段我们的数据仓库发展与建设方法，虽然比较简单，但是目前基本能满足需求。随着数据规模的增长和业务的复杂化，未来还有很多路要走：如何合理的建模？如何有效的利用数据？如何提高数据分析效率？期待更多的挑战！

但这一切都要基于一个好用的数据可视化平台。现在市面上流行的有FineBI、Power BI、DataV、鼎数，但权威机构IDC指出市场占有率第1的还是FineBI，这些都可以做数据分析。