概念与容器
为什么先说这个,其实很简单:因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题:oracle不是数据库么,怎么又是数据仓库?Hive不是数据仓库么?怎么又是数据库?
数据仓库、数据库是一个概念,是一些技术的集合。类同于切菜刀法和雕刻刀法;
Oracel、DB2、MySQL、Hive是一个容器,是一种工具。类同于一把刀。
当我们在说数据仓库的时候,我们在说什么?说的是你用的mysql还是oracle?用的是Hive还是Kylin?用的是druid还是doris?都不是!因为这些是实现数据仓库的工具!
我们在说数据仓库的时候,我们实际上说的是一种面向主题,沉淀历史不可变信息,对明细数据进行汇总的,为决策提供在线分析服务的数据技术的集合。
我们在实现数据仓库的时候,需要用到数据仓库设计(数据库设计工具)、数据存储技术(数据库工具)、数据处理技术(ETL工具、监控报警)、数据管理技术(元数据、数据地图、血缘关系)等等技术。
而oracle、mysql、hadoop等都只是数据存储技术中的一种而已。
数据仓库发展历史
1、数据仓库概念诞生
数据仓库概念公认最早的定义者,是数据仓库之父比尔·恩门(Bill Inmon)在1991提出的。在此之前,所有的业务操作数据和分析数据都是存在一个数据库中的,并没有分开。
![ed339caea2652595b0f82de230847ad9.png](https://i-blog.csdnimg.cn/blog_migrate/adb715dbc49904b7c6f7f97cfdd0ad9e.jpeg)
这个inmon就是inmon、kimball建仓方法论的inmon,是不是很熟悉?
如同绝大多数新概念一样,刚诞生的数据仓库同样遭受到了巨大的失败。inmon的建设理念是自上而下,这个上指的是数据的上游,不是数据分层的上层。
![1be020385deb7fe653df6e441b2b7905.png](https://i-blog.csdnimg.cn/blog_migrate/5411ae9f01be673fc74bac52d39522bf.jpeg)
大家都是做数仓的,你肯定理解为什么一开始数据仓库概念会惨败。因为自上而下太难见效,得把所有的业务理清楚,把所有系统的数据理清楚,然后分主题分层一点点的设计,然后按照这个设计一层层的建。而且一旦其中有任何变动,整个设计全废。所以第一批吃螃蟹的那些公司基本上都是小白鼠。
2、数据集市概念诞生
这个时候,有个英雄站出来了,这就是Kimball,他写了一本书《The DataWarehouse Toolkit》,开启了数据集市的狂潮,也开创了另一种数据仓库建设的流派-Kimball的自下而上流派。这个上、下也是上下游的意思。Kimball建议,百鸟在林,不如一鸟在手。先搞一个销售部门,摸清销售部门的需求,等于把下游的需求先锁死。然后再顺藤摸瓜,把数仓的每一层设计好,最后再摸到业务系统(CRM+ERP+人力系统),找业务系统的数据,这样就建立了一个销售部门级的数据集市。
![17a0d3c6ee7fcb50a03066a6fa38a943.png](https://i-blog.csdnimg.cn/blog_migrate/393d66dccb07c805c39b1c8addba0762.jpeg)
由于这种方法的需求少了,设计工作少,难度也就低了,对应的建设难度和工作量也少,建设速度就快,见效也就快啊,非常利于工作的开展。所以数据集市大行其道。
3、DWDM融合
两派吵了很久很久,各自都有死忠,也都有对的理由,各自也都说服不了对方。双方也明白了:“one size fits all”一码通用是不可能的。终于在1998年, Inmon提出了新的BI架构CIF(CorporationInformation Factory,企业信息工厂)。
![13b15467dbb4ae0df7fedfbdc2c439f1.png](https://i-blog.csdnimg.cn/blog_migrate/17e6b6294ecc20a3672ac47be40fb509.jpeg)
上面这张图就是inmon老爷子画的,看上去很乱对吧?其实按照咱现在的视角看就很清晰了:
![cea0d0d57143e354950728afaa70d90c.png](https://i-blog.csdnimg.cn/blog_migrate/e315027b6c0fb0584fc1e7a4c8c97990.jpeg)
这个架构是不是很熟悉?对!这个架构从1998年到现在,就没变过!而且也是所有数据仓库建设的框架性指南。
4、实时数仓
一直到最近两年,实时处理技术的飞速发展,才将数据仓库的架构往前又推了一步,出现了实时数仓。实时数仓又分为批数据+流数据、批流一体两种架构。从这里开始,也就正式进入了大数据环境下的数据仓库范畴。
大数据环境下的数据仓库
1、离线数仓
刚转到大数据环境中的哥们会很奇怪,为啥有一个数仓叫离线数仓?从来没听过啊!
其实离线数仓就是咱以前做的传统数仓,数据以T+1的形式计算好放在那里,给前台的各种分析应用提供算好的数据。这也被称为“大数据的批处理”。只不过原本的单体环境工具(oracle、informatica等)基本都被替换成了大数据体系内(Hadoop、Hive、Sqoop、oozie等)的工具而已。
![d322a77e609d45720a2cdcdd4492a45d.png](https://i-blog.csdnimg.cn/blog_migrate/e26fc936cc8ad79baaa950232ffcb356.jpeg)
大数据环境中工具清单:
- 数据采集:flume/logstash+kafka,替代传统数仓的FTP;
- 批量数据同步:Sqoop、Kettle,跟传统数仓一样用Kettle,部分商用ETL工具也开始支持大数据集群;
- 大数据存储:Hadoop HDFS/Hive、TiDB、GP等MPP,替代传统数仓的Oracle、MySQL、MS SQL、DB2等;
- 大数据计算引擎:MapReduce、Spark、Tez,替代传统数仓的数据库执行引擎;
- OLAP引擎:Kylin/druid,(Molap,需预计算)、Presto/Impala,(Rolap,无需预计算),替代BO、Brio、MSTR等各种BI工具。
2、实时计算
就是因为有实时数据处理,所以才会有离线数据处理。相对应的也就有实时数仓和离线数仓。实时数仓最开始是在日志数据分析业务中被广泛使用,后来在各种实时战报大屏的推动,实时数仓开始应用。
![778a78735af211e48094549b43c3ee94.png](https://i-blog.csdnimg.cn/blog_migrate/6c41200f01bca2be8b8cf4894789dcd3.jpeg)
与离线计算相比,实时计算这边减少了数据落地,替换了数据计算引擎,目前纯流式数据处理基本上就只有Spark Streaming了。Storm会丢数据,Flink是批流一体的。实时数据计算好结果后,可以落地到各种数据库中,也可以直接对接到大屏进行展示。
大数据环境下的数据仓库架构
1、Lambda 架构
Lambda架构核心就三个:批数据处理层、流数据处理层和服务层。批数据处理层应对历史长时间数据计算,流数据处理层应对短时间实时数据计算。如果一个需求要历史到当前所有数据的累加结果,那就在服务层将两部分数据进行累加就好了。
![1e85718abbb782b32d627da572defaad.png](https://i-blog.csdnimg.cn/blog_migrate/994c978cea4af92f8652475676070566.jpeg)
Lambda架构需要维护两套计算引擎,如果需要历史到现在实时数据的累加,则需要在两边同时做相同的计算,然后还得加总一下,非常麻烦。因此就有了最近非常火热的Kappa架构。
2、Kappa 架构
Kappa架构的设计很有意思。Lambda架构反正还是分离线和实时两部分的,所以可以从离线库和实时消息队列取数,分别计算后,在服务层加总就可以了。
Kappa的设计理念是:干脆不要离线了,全部都进行流式计算。流式计算的数据来源是消息队列,那我把所有需要计算的数据放在消息队列里就好了,然后让流计算引擎计算所有数据不就好了?
![4b2c094ae3cb289b70cb6d75e29761b5.png](https://i-blog.csdnimg.cn/blog_migrate/6791ae23068a5d6551b6652497822bea.jpeg)
因为所有数据都存在Kafka,上面接Flink批流一体数据处理引擎将kafka的数据计算好存在服务层的table n中。如果需求有变化了,就讲kafka的offset调整一下,Flink则重启一个任务重新计算,存在table N+1中,当N+1的数据进度赶上table n了,就停掉table n的任务。
3、Kappa 架构+查询+分析展示
Kappa架构只到数据服务层,Flink本身只是一个计算引擎,因此还需要一个提供快速查询的工具和一个展示的工具。所以现在的架构就变成了这样:
![cccea504057dcc1ff04154b3ef80a0c7.png](https://i-blog.csdnimg.cn/blog_migrate/3c5efc7b46f24d55c65f5c7f245641f1.jpeg)
总结
综上所述,传统数仓和大数据环境下的数仓还是有很多区别的:
![8829f28a42bf42c3d55c1769cf753cbc.png](https://i-blog.csdnimg.cn/blog_migrate/97706ae05563d184737b2fa34cc36e11.jpeg)
- 数仓设计的工具都是一样的,这个不会变;
- 由于大数据集群中,表关联的代价比较大,因此数仓建模会更多的使用宽表,所以这里会有一些变化;
- 数据处理和调度工具用kettle基本都OK,没啥太大变化,但是需要了解一下Flume、Kafka等工具;
- 数据存储这边需要深入了解一下,这是单体数据库和集群数据库的差别,会有分布式一致性的各种乱七八糟的问题;
- 数据计算引擎也有变化,也是单体数据库和集群数据库的差别。分布式计算会有数据倾斜、join代价高等问题,所以优化的方法和方向也不一样;
- 数据总体架构设计的时候也会有所变化,传统数仓整个BI套件就ok了,大数据环境下可能要面对更多的各种复杂需求,所需的大数据组件就变多了,需要系统学习。
建议传统数据仓库工程师的转型路线:
传统数仓-离线数仓(批数据处理)-实时数据处理(流数据处理)-lambda架构-kappa架构(批流一体)。
作者:彭文华 大数据架构师 分享数据分析、大数据技术、数仓建设相关的技术、方法论、案例、解决方案。