有赞大数据实践: 敏捷型数据仓库的构建及其应用

有赞大数据实践: 敏捷型数据仓库的构建及其应用

• 有赞大数据实践: 敏捷型数据平台的构建及其应用

  • 前言

  • 数据仓库设计

    • 整体架构

    • 数据仓库实例

    • 基础指标层

    • 分层的好处

    • 数仓工具

  • 数据仓库与数据分析

    • 即席查询系统

    • 多维分析系统

    • 搜索分析系统

    • 固定报表系统

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

  • 小结

前言

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

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

数据通过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. 等等

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

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

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

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

基础指标层

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

分层的好处

咱们能够看到, 从 近源层 到 指标层 层次越高易用性越强, 层次月底, 灵活性就越强. 这样的设计能够保证紧急的分析能够快速响应, 同事稳定的数据能够经过高层次的数据模型高质量保证.

同时, 咱们意识到数仓模型是迭代的, 逐步晚上的过程. 数据分析的工做不断的反馈到数仓建设中.

数仓工具

有了可供操做的数据模型. 基本上咱们能够解决数据仓库的主要问题. 数据仓库另一个问题是溯源问题.

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

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

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

1. 数据地图能够用于查看全部报表的路径和执行过程. 这样咱们能够追查特定字段的数据来源, 普遍用于对帐和对数.

2. 数据地图能够提供数据任务间的依赖关系, 从而进行快速的全局数据的修补. 举个例子, 若是咱们在10.30日发现9.1日的日志里面存在大量的攻击日志(无效日志)致使不少中间层, 报表数据不许, 咱们只须要把近源数据表修复, 而后设定开始和结束的日期, 全部依赖它的任务都会从新执行.

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

1. 提供帮助文档, 给出全部可用表格的规格和口径说明;

2. 规范报表的口径, 避免口径歧义.

数据仓库与数据分析

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

咱们提供4种不一样的工具来知足BI服务.

1. 即席查询系统

2. olap系统

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工具.

工具名称	基本技术	适用人群	速度	灵活性	适用场景
即席查询	hive	1. 数据分析人员 2. 有能力的运营人员	慢:10m~1h	强	全部数据分析场景
OLAP系统	olap	产品经理, 运营人员	较快: 10s~10min	中	特定主体的多维分析
搜索引擎	倒排索引	1. 目的性强	快: 10s如下	中	根据条件的主题检索
报表系统	mysql	报表相关人员	快: 10s如下	低	特定业务数据的查阅

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

数据仓库不只在用于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, 数据报表和搜索引擎, 根据不一样的需求方和场景给出不一样的解决方案. 最后咱们介绍了数据仓库在信息检索领域的应用, 咱们看到利用大数据平台的分布式能力, 强大的业务整合能力, 给咱们的信息检索带来很大的业务和技术上的便利.

数据是一个企业最重要的资产之一, 如何利用数据价值变得愈来愈重要. 一个优秀的大数据平台的建设是一个重要的前提. 大数据平台愈来愈像一个企业的数据总线: 是全部数据的入口, 同时也是全部数据的出口. 像不少企业正在努力的同样, 咱们但愿可以构建一个灵活可靠的数据仓库. 它像一个企业的基础设施同样, 咱们能够利用它提供的数据上, 工具上的服务来搭建咱们须要的数据平台, 知足业务需求.

关于做者

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

来自为知笔记(Wiz)