我眼中的数据仓库

来源:互联网 发布:网络打印机添加xp 编辑:程序博客网 时间:2024/05/17 05:08

概述

作为一个在传统行业和互联网行业都打过杂的数据码农,今天简单谈一下个人对数据仓库的理解,以及传统行业和互联网行业之间数据仓库建设的区别,希望对刚接触数据仓库的同学起到积极的作用。有说的不对的地方欢迎评论指正。

一 数据仓库定义

数据仓库官方定义,数据仓库的定义在百度百科早已存在,这里暂且不表。说一下个人理解,数据仓库其实是一个相对抽象的概念,其对应的实体可以是数据库表也可以是一堆Excel或者TXT之类的数据文件(后者基本不会遇到,只是为了说明一下Oracle或者Hive之类的并不代表是数据仓库,它们仅仅是一个载体),它最基础目的是通过历史数据的变化趋势驱动企业决策和运营。

二 数据仓库组成

提到数据仓库就不得不提的一个概念就是ETL,它是对数据处理的一个定义,包括数据接入,数据处理(转化和清洗),数据加载。
除了说一下数据仓库的划分之外,本人简单的说一下常规ETL的几种实现。

1.数据划分     

数据仓库分主题和分层,先说一下分层。我们一般会根据数据不同粒度以及作用分以下几层:
  • 数据接入层:该层级跟业务系统同构,按照不同的处理逻辑,一般只存放当天的增量数据,表数据量小的话或者有特殊业务的可能会存放每天最新的全量数据
  • 数据明细层:该层级区分事实表和维表并基于3NF建模完成明细数据的整合,提供完整统一的基础明细数据。表的存储方式有以下几种:拉链表,快照表,流水表等
  • 数据模型层:该层级以分析业务需求为驱动进行模型设计,并通过业务划分主题进行关联计算或者轻度汇总,因此会有大量的多表关联汇总计算。比如一个电商系统,按订单,商家,用户等主题进行各自主题的数据模型建设。
  • 数据集市层:可能有一些同学会有疑问,数据集市不是数据仓库衍生出来的另一个概念么, 其实在这里也只是一个简单的概念,我们一般也会叫该层级的表为宽表,主要是为了构建多维CUBE计算,方便进行多维分析。
  • 数据应用层:该层级会粗粒度数据,主要是用来进行报表的展现。

注:可能有的同学习惯说ods层,dw层,这里因为每个公司可能对自己公司仓库层级的命名不太一致,所以使用接入层,明细层等更易于理解的词汇

2 数据接入

数据接入是数据仓库建设的一个基础工作,传统行业会使用各种ETL工具来实现自己仓库的数据接入。而互联网行业也会有相应的工具和方法,这里以互联网行业举例。
  • 离线接入:该方式一般会在一些中小型公司出现(ps.这里并没有歧视中小型公司的意思,主要还是业务决定。)比如我个人之前待过的某互金公司,虽然在我离开的时候已上市奋斗,在业务数据接入这块仍然延续了离线接入的方式。主要是用DataX或者Sqoop将前一天的增量数据加载到数据接入层并使用Hql脚本将数据加载到明细层。
  • 实时接入:一般技术相对成熟的公司会采用此方案,以业务系统在MySql存储为例。数据研发的同学会使用flume将业务系统的binlog以及行为日志sink到kafka集群,并通过storm或者sparkstreaming去消费kafka里的数据,进行计算存放到hbase等数据库进行一个实时的计算,或者使用camus程序将kafka里的数据消费到hdfs供hive进行离线计算。

3 数据处理

数据处理的主要内容是将接入后的数据进行加工的一个过程。实时数据处理就是笔者在数据接入中提到的使用storm去做一个接入和计算,主要作用于以下几个场景:实时大盘,线上风控等。
离线数据处理主要是对历史数据的一个计算用以进行趋势分析,留存分析等场景,主要是用Hql脚本来实现,会涉及拉链表的设计实现,模型设计等技术点。

三 数据仓库实现

这里简单说一下现在我们数据仓库的一个基础实现方案。由于我司技术相对成熟,所以采用了flum收集binlog和行为日志并sink到kafka集群供storm程序以及camus程序消费的方式,这块主要是由基础架构部的同事来实现和维护。数据处理这块延续了Hql脚本以及MR/RDD等离线脚本计算方式在我们自己研发的一个ETL平台来实现(包括调度),构建完成后的宽表,如果有多维分析的场景则会用Kylin或者hive中grouping sets方式进行多维计算,并用自己开发的可视化平台进行数据的展现以及多维分析(这块如果人力有限。个人建议也可以用superset来实现)。
了解过数仓历史的人都知道两位数仓的大神提出两种截然相反的设计模式,即自上而下和自下而上两种设计模式。我们目前采用的是并行的状态,其主要原因就是需求堆积太多,暂时无法按照需求分析,模型建设,模型实现这种方式一步步推进。毕竟互联网是个快速发展的时期,如果按照传统行业那种稳扎稳打的节奏,可能方案还没落地,项目已经黄了。所以我们一部分人主要以满足需求为主,会借鉴模型设计理论和规范,但在易用性以及通用性上会稍微欠缺。而另外一部分人则会根据前部分同事的经验再结合建模理论进行一个基建的实现。

总结

数据仓库说到底还是一个抽象的概念,其实现方式多种多样,个人还是建议用更合适的方法解决最急需解决的问题。