前言

互联网公司一般发展迅速. 一方面, 业务飞速发展, 当前应用的形式和模型每天都在变化; 企业的产品也在经历不断的下线上线过程. 数据仓库如何拥抱变化, 是难点之一.

互联网的运营人员从了解经营状况转化为精细化运营, 这就于要求数据仓库具有提供高效明细数据能力, 数据仓库如何在庞大数据量的前提下, 实现满足不同层次的数据提出和分析, 是难点之二.

数据经过ETL最终到达使用数据者手里; 提取数据和提出数据的需求往往来自不同的部门和出于不同的目的. 这一般会导致数据口径不一致, 数据含义模糊, 甚至数据正确性很难校验. 数据仓库如何保证数据口径一致, 数据路径可追溯性, 是难点之三.

数据仓库的应用领域除了各个业务部门还包括技术部门本身. 由于海量数据处理, 互联网的技术架构越来越依赖大数据平台的支持. 一个点上平台每天都会有数以万记的店铺和商品更新, 数以亿计的用户日志, 订单数据等. 这些数据在毫无保留的通过消息队列汇总到数据仓库中. 如果使用数据仓库进行再生产是技术架构重点考虑的事情. 数据仓库拥有其他数据平台无法比拟的横向扩展和迭代计算能力, 可以直接或者间接面向用户提供数据服务. 这也是大数据的机遇之一.

数据仓库设计

总体架构

存储层 主要解决ETL问题, 如何正确的埋点, 数据稳定正确的传输, 提供可靠的存储计算环境等等. 这部分内容比较复杂, 本文不重点阐述.

数据仓库层 主要提供数据模型和数据工具两个内容. 数据模型解决数据可用的问题, 数据工具解决数据易用的问题. 本文会重点介绍数据模型的设计方法和数据工具的作用.

数据分析层 主要解决各种角色如何使用数据仓库的问题. 后面有章节举例说明每个分析工具的优势和适用范围.

数据仓库实例

数据源主要有两种来源, 文件和DB. 通过消息队列收集到hadoop平台. 数据仓库的第一层是近源数据层, 这一层基本上和数据源保持一样的字段结构. 我们看一下一个例子. 这个例子阐述我们如何构造"订单商品中间层".

业务层有数十个基本表. 他们通过收集工具, 消息队列导入近源数据层中. 这个过程需要做如下几件事情:

1. 将物理分片的分布式DB映射成一个Hive表
2. 根据表的内容选择合适的Hive分区键
3. 对于缓慢变化维进行处理, 让数据表可以反映变化
4. 对于日志进行基本的处理映射成Hive表

近源数据层不做如下事情:

1. 脏数据处理;
2. 数据表间一致性处理;
3. 不同业务表的合并.

我们对于近源数据层的定位是可以"快速"的构建基础数据平台. 不做业务相关的处理可以让这部分的工作专注在大数据架构正确性和稳定性的问题.

近源数据层出现以后, 实际上我们已经可以开始主要的数据分析工作了. 但是我们引入了"中间层", 它的定位是"操作简单, 执行快速, 屏蔽错误, 统一口径".

这个过程主要完成如下几个事情:

1. 合并不同业务为统一过程;
   业务数据有很多独立的市场或者版本, 他们客户和用户不同, 但是工作过程是一样的. 再比如app和pc的日志独立记录, 但是可以在一定程度上合并.
2. 屏蔽脏数据, 比如典型的测试数据.
3. 冗余字段. 把常用的join操作在中间层封装.

我们看一下订单宽表的实现过程. 订单宽表是是以订单为主键的表. 它包含几方面的信息:

1. 基本的订单统计, 主要是订单主要信息表提供;
2. 订单的聚类分析, 比如订单的城市分布, 年龄分布分析, 主要是订单详细信息表提供;
3. 订单风险分析, 这就依靠维权订单表来提供;
4. 等等

这样我们产生的订单宽表在一定程度上满足绝大多数的数据分析问题.

首先, 是数据口径的问题, 计算宽表的时候会根据业务需求生成很多冗余字段, 比如对于疑似刷单交易, 很多业务如果都实现一遍的话, 势必会导致口径问题, 在设计订单宽表的时候我们根据风控模型加入一个字段是否为空壳交易. 这样在统计时候各方的口径都会一致. 同样脏数据问题也是通过这种方式解决.

其次, 多表join问题, 订单宽表一定程度上聚合常用的字段, 满足80%的数据分析需求. 加上合理的分区设计, 基本上查询是非常快速的.

最后需要说明的是, 我们没有为所有近源数据表都封装中间层. 购物车信息我们就没有完全封装, 因为他们的分析不常用. 订单宽表的设计需要做一个折中. 一方面设计完备的数据仓库是不现实的, 另一方面订单宽表的前提是足够常用, 对于不常用的数据我们的数据平台是支持直接操作的. 这符合互联网设计产品的一般思路.

基础指标层

基础指标层放映了对一个实体的基本衡量, 是BI分析的基础. 如上图所示, 在订单宽表的基础上我们提取出 消费者指标表, 商户指标表, 商品指标表 等. 比如在商品指标表中, 我们会针对商品的销量, 维权数等对商品做基本的画像, 这样应用就可以非常方便的筛选合适的商品.

分层的好处

我们可以看到, 从 近源层 到 指标层 层次越高易用性越强, 层次越低, 灵活性就越强. 这样的设计可以保证紧急的分析可以快速响应, 同时稳定的数据可以通过高层次的数据模型高质量保证.

同时, 我们意识到数仓模型是迭代的, 逐步完善的过程. 数据分析的工作不断的反馈到数仓建设中.

数仓工具

有了可供操作的数据模型. 基本上我们可以解决数据仓库的主要问题. 数据仓库另外一个问题是溯源问题.

一方面溯源有利于我们清晰的了解数据的血缘关系, 方便数据问题的追查.

另外一方面, 是数据质量的问题. 想建立一个稳定的数据质量体系保证数据仓库常年稳定有效实践过程中非常困难. 基础设施的问题, 业务的变迁, 脏数据的产生都会导致正在使用的数据仓库的质量问题. 数据仓库另外一个要求是随时可以跑全量数据.

我们看一下我们设计的数据地图的样子:

数据地图可以用于查看所有报表的路径和执行过程. 这样我们可以追查特定字段的数据来源, 广泛用于对账和对数.

数据地图可以提供数据任务间的依赖关系, 从而进行快速的全局数据的修补. 举个例子, 如果我们在10.30日发现9.1日的日志里面存在大量的攻击日志(无效日志)导致很多中间层, 报表数据不准, 我们只需要把近源数据表修复, 然后设定开始和结束的日期, 所有依赖它的任务都会重新执行.

数据仓库另外一个组件是元数据管理系统. 它的主要作用:

1. 提供帮助文档, 给出所有可用表格的规格和口径说明;
2. 规范报表的口径, 避免口径歧义.

数据仓库与数据分析

互联网的运营人员从了解经营状况转化为精细化运营. 精细化 首先体现在深度. 传统的高度汇总的知识性数据不能满足目前的日常需求, 更需要细粒度的探索性数据. 其次精细化体现在广度上面, 需要BI支持不仅仅是管理层或者决策人员. 普通的产品运营, 市场运营, 产品经理都会分析数据分析产品的受众, 分布等数据.

我们提供4种不同的工具来满足BI服务.

1. 即席查询系统
2. 多维分析系统
3. 搜索分析系统
4. 固定报表系统

即席查询系统

即席查询系统 的使用者是专业的数据分析人员. 它的定位是数据仓库的操作平台.这是使用最广泛的系统, 因为它不需要开发任何工作. 数据仓库ready后就可以使用. 数据仓库的良好设计和数据字典的文档作用使得即席查询系统非常容易上手.

这里我们强调一下BI过程和数据仓库设计的互动性. 对于重要的数据中间层, 我们提供基本的BI基础表. 比如订单指标表和商品指标表.

接着上面的例子, 我看一下BI过程如何利用数据仓库的. 假如我们需要分析店铺的各项指标.

这些指标可以非常迅速的从订单宽表中算出来. 不要考虑复杂的交易异常, 脏数据等问题.

另外由于店铺指标, 用户指标等这些常用的BI表又可以作为基础指标中间层沉淀下来, 用于更高纬度的数据分析.

因此我们看到数据仓库数据整合的3个层次:

1. 近源数据层作为数据源, 主要是不常用的, 简单的数据.
2. 数据中间层, 使用频率很高的基于主题的数据.
3. 基础指标中间层, 基于数据中间层的基础聚合, 使用频率更高. 简化复杂BI过程.

多维分析系统

多维分析系统 的使用者是一般运营人员. 它是特定的中间层图形化表达. 多维分析系统实现的是对某些指标的特定维度的聚合分析.

多维分析系统我们是基于kylin引擎做的, 是一种多维度联机查询系统. 对于每个主题(比如订单主题)提供基于维度筛选和各种聚合功能(比如最大, 最小, 求和等). 并通过表格和图形化方式展示.

接着上面的例子. 我们打算做一个订单主题的多维分析系统. OLAP模型如下:

这样我们就可以轻松的回答如下几个问题.

1. 3C类目的维权订单趋势是怎么样的?
   

2. 各种支付方式在每个省的分布式怎样的?

多维分析系统的缺点是没有即系查询系统灵活. 由于他需要预加载数据对于维度特别高的查询支持也不是很好.

搜索分析系统

搜索分析是基于对于纬度建立索引的查询系统. 他可以满足对于不同指标的多级筛选, 直到筛选出合适的候选集. 如下是一个例子.

我们需要对商品池进行筛选. 由于我们对商品的关键属性建立的索引, 首先可以根据销量和维权数筛选出优质高效(A类), 优质精品(B类), 劣质(C类)商品; 再在A类商品的基础上根据其他属性(品类, 客单价, 受众人群)等筛选出本次的目标商品集.

在这个过程中我们可以感受到, 搜索分析系统给我们的数据分析者一个很大的迭代筛选的平台, 可以通过不断的尝试和反馈, 提高自己的选品的质量.

固定报表系统

固定报表 一般是针对特征的数据需求. 这是最常见的BI需求. 比如我们的GMV报表, 店铺报表. 在固定报表的基础上的地动仪系统可以很好的支持我们的数据异常点. 比如如果每周一的订单数据都在100w单左右(举例), 如果突然一个周一变成200w单, 就可以发出报警.

我们来对比以下常用的BI工具.

数据仓库在信息检索中的应用

数据仓库不仅在用于BI, 数据仓库实际上充当着企业数据总线的作用. hadoop为存储介质的数据仓库简化了信息检索的成本. 包括数据的获取, 计算和加载.

信息检索系统应该和业务数据解耦. 我们回归一下传统的信息检索系统的构建过程. 传统的搜索工具一般都是基于倒排索引的, 或者kv的的系统, 一般都是单机模式 + 代理的分布式方案.

1. 传统的搜索引擎, kv引擎等数据与业务数据高度耦合. 业务数据一般存储在DB中, 我们经历过搜索引擎数据丢失的情况, 我们不得小心翼翼的与业务方配合追查, 一不小心一个sql就把业务服务器整垮了.

2. 数据无法保证完全性. 搜索引擎是一个庞大的系统, 数据经过很多环节才进入索引, 一般都是批处理或者实时构建. 补一个步骤都需要保证数据正确性. 否则索引数据就不准. 由于索引数据的非常宝贵. 搜索团队还要花费很多功力研究如何备份索引, 以防止以外丢失.

3. 搜索数据与业务数据不一致. 对数据是任何两个部分在处理同一份数据时候都会经历的问题.

我们还是以订单相关的业务为例. 通过"订单", "维权", "购物车", "状态变更"等基本事务过程产生相关的DB和日志数据; 我在在这些基本的数据上搭建"订单检索", "订单导出", "数据报表"等信息检索的业务. 和左侧的业务不同, 这些业务不需要交互和事务, 是一个"一写多读"的功能模块.

由于日志和DB是基于技术通用性设计的, 没有考虑各个业务的需求. 各个业务势必会有各自不同的业务处理代码. 比如订单检索和数据报表在理论上应该是可以进行精确的"对数"的. 但是由于各自的业务代码是独立的, 因此在数据一致性方面会遇到问题.

搜索引擎的搭建是一个庞大的工程, 首先我们要通过消息队列订阅所有的数据, 然后我们在业务处理层将数据进行整合, 然后建立索引. 这里我们会遇到横向扩展的问题. 我们不得不根据一个合适的主键讲消息队列的数据分流, 分别建立索引.

我们发现全量索引是昂贵的. 全量索引意味着导表, 我们不得不提供专门为搜索引擎使用的备库, 如果数据库本身是分片的, 那么每片我们都要导入.

如果我们引入大数据平台, 就可以完全把搜索引擎和DB解耦.

1. 数据平台是基础数据的完全镜像.

2. 数据平台非常的皮实. 不仅可以随时拉去海量数据不影响业务, 而且可以通过批量计算和迭代计算进行复杂的数据处理.

3. 大数据有逐渐成熟的解决方案体系. 包括批处理, nosql, 和搜索引擎(solr和elasticsearch).

我们看一下以数据仓库为中心的架构.

1. 数据仓库充当业务数据层. 数据仓库封装了重要的数据口径. 让业务处理更加关注上层的业务,不需要关注通用的数据处理和封装.

2. 大数据平台让各种数据引擎执行过程简单可靠. 大数据以透明拓展性和高度可计算性著称, 但是传统的搜索引擎, 本质上是单机程序, 他们的分布式解决方案需要代理层. 如何让他们享受大数据的优势, 很多人给出解决方案. 我们这里给出基于hadoop-elasticsearch的方案, 主要不是介绍相应的技术细节而是强调我们的思路.

3. 搜索算法可以有更多发挥空间. 基于数据仓库的算法平台, 充分spark等迭代计算的优势, 可以提供搜索引擎很多算法组件, 比如商品的质量度, 商品的类目, 反作弊数据等.

小结

我们介绍了大数据平台下的数据仓库. 数据仓库在设计上尽可能简单, 配合BI和信息检索的应用迭代优化. 为了保证数据仓库的可用性, 我们引入数据字典, 数据地图等工具. 在数据仓库上面, 我们搭建了几种BI工具, 即席查询, olap, 数据报表和搜索引擎, 根据不同的需求方和场景给出不同的解决方案. 最后我们介绍了数据仓库在信息检索领域的应用, 我们看到利用大数据平台的分布式能力, 强大的业务整合能力, 给我们的信息检索带来很大的业务和技术上的便利.

数据是一个企业最重要的资产之一, 如何利用数据价值变得越来越重要. 一个优秀的大数据平台的建设是一个重要的前提. 大数据平台越来越像一个企业的数据总线: 是所有数据的入口, 同时也是所有数据的出口. 像很多企业正在努力的一样, 我们希望能够构建一个灵活可靠的数据仓库. 它像一个企业的基础设施一样, 我们可以利用它提供的数据上, 工具上的服务来搭建我们需要的数据平台, 满足业务需求.

关于作者

洪斌, 有赞大数据团队负责人, 专注大数据和数据挖掘相关技术. 欢迎交流.