概念与容器

为什么先说这个，其实很简单：因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题：oracle不是数据库么，怎么又是数据仓库？Hive不是数据仓库么？怎么又是数据库？

数据仓库、数据库是一个概念，是一些技术的集合。类同于切菜刀法和雕刻刀法；

Oracel、DB2、MySQL、Hive是一个容器，是一种工具。类同于一把刀。

当我们在说数据仓库的时候，我们在说什么？说的是你用的mysql还是oracle？用的是Hive还是Kylin？用的是druid还是doris？都不是！因为这些是实现数据仓库的工具！

我们在说数据仓库的时候，我们实际上说的是一种面向主题，沉淀历史不可变信息，对明细数据进行汇总的，为决策提供在线分析服务的数据技术的集合。

我们在实现数据仓库的时候，需要用到数据仓库设计（数据库设计工具）、数据存储技术（数据库工具）、数据处理技术（ETL工具、监控报警）、数据管理技术（元数据、数据地图、血缘关系）等等技术。

而oracle、mysql、hadoop等都只是数据存储技术中的一种而已。

数据仓库发展历史

1、数据仓库概念诞生

数据仓库概念公认最早的定义者，是数据仓库之父比尔·恩门（Bill Inmon）在1991提出的。在此之前，所有的业务操作数据和分析数据都是存在一个数据库中的，并没有分开。

这个inmon就是inmon、kimball建仓方法论的inmon，是不是很熟悉？

如同绝大多数新概念一样，刚诞生的数据仓库同样遭受到了巨大的失败。inmon的建设理念是自上而下，这个上指的是数据的上游，不是数据分层的上层。

大家都是做数仓的，你肯定理解为什么一开始数据仓库概念会惨败。因为自上而下太难见效，得把所有的业务理清楚，把所有系统的数据理清楚，然后分主题分层一点点的设计，然后按照这个设计一层层的建。而且一旦其中有任何变动，整个设计全废。所以第一批吃螃蟹的那些公司基本上都是小白鼠。

2、数据集市概念诞生

这个时候，有个英雄站出来了，这就是Kimball，他写了一本书《The DataWarehouse Toolkit》，开启了数据集市的狂潮，也开创了另一种数据仓库建设的流派-Kimball的自下而上流派。这个上、下也是上下游的意思。Kimball建议，百鸟在林，不如一鸟在手。先搞一个销售部门，摸清销售部门的需求，等于把下游的需求先锁死。然后再顺藤摸瓜，把数仓的每一层设计好，最后再摸到业务系统（CRM+ERP+人力系统），找业务系统的数据，这样就建立了一个销售部门级的数据集市。

由于这种方法的需求少了，设计工作少，难度也就低了，对应的建设难度和工作量也少，建设速度就快，见效也就快啊，非常利于工作的开展。所以数据集市大行其道。

3、DWDM融合

两派吵了很久很久，各自都有死忠，也都有对的理由，各自也都说服不了对方。双方也明白了：“one size fits all”一码通用是不可能的。终于在1998年， Inmon提出了新的BI架构CIF(CorporationInformation Factory,企业信息工厂)。

上面这张图就是inmon老爷子画的，看上去很乱对吧？其实按照咱现在的视角看就很清晰了：

这个架构是不是很熟悉？对！这个架构从1998年到现在，就没变过！而且也是所有数据仓库建设的框架性指南。

4、实时数仓

一直到最近两年，实时处理技术的飞速发展，才将数据仓库的架构往前又推了一步，出现了实时数仓。实时数仓又分为批数据+流数据、批流一体两种架构。从这里开始，也就正式进入了大数据环境下的数据仓库范畴。

大数据环境下的数据仓库

1、离线数仓

刚转到大数据环境中的哥们会很奇怪，为啥有一个数仓叫离线数仓？从来没听过啊！

其实离线数仓就是咱以前做的传统数仓，数据以T+1的形式计算好放在那里，给前台的各种分析应用提供算好的数据。这也被称为“大数据的批处理”。只不过原本的单体环境工具（oracle、informatica等）基本都被替换成了大数据体系内（Hadoop、Hive、Sqoop、oozie等）的工具而已。

大数据环境中工具清单：

• 数据采集：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、实时计算

就是因为有实时数据处理，所以才会有离线数据处理。相对应的也就有实时数仓和离线数仓。实时数仓最开始是在日志数据分析业务中被广泛使用，后来在各种实时战报大屏的推动，实时数仓开始应用。

与离线计算相比，实时计算这边减少了数据落地，替换了数据计算引擎，目前纯流式数据处理基本上就只有Spark Streaming了。Storm会丢数据，Flink是批流一体的。实时数据计算好结果后，可以落地到各种数据库中，也可以直接对接到大屏进行展示。

大数据环境下的数据仓库架构

1、Lambda 架构

Lambda架构核心就三个：批数据处理层、流数据处理层和服务层。批数据处理层应对历史长时间数据计算，流数据处理层应对短时间实时数据计算。如果一个需求要历史到当前所有数据的累加结果，那就在服务层将两部分数据进行累加就好了。

Lambda架构需要维护两套计算引擎，如果需要历史到现在实时数据的累加，则需要在两边同时做相同的计算，然后还得加总一下，非常麻烦。因此就有了最近非常火热的Kappa架构。

2、Kappa 架构

Kappa架构的设计很有意思。Lambda架构反正还是分离线和实时两部分的，所以可以从离线库和实时消息队列取数，分别计算后，在服务层加总就可以了。

Kappa的设计理念是：干脆不要离线了，全部都进行流式计算。流式计算的数据来源是消息队列，那我把所有需要计算的数据放在消息队列里就好了，然后让流计算引擎计算所有数据不就好了？

因为所有数据都存在Kafka，上面接Flink批流一体数据处理引擎将kafka的数据计算好存在服务层的table n中。如果需求有变化了，就讲kafka的offset调整一下，Flink则重启一个任务重新计算，存在table N+1中，当N+1的数据进度赶上table n了，就停掉table n的任务。

3、Kappa 架构+查询+分析展示

Kappa架构只到数据服务层，Flink本身只是一个计算引擎，因此还需要一个提供快速查询的工具和一个展示的工具。所以现在的架构就变成了这样：

总结

综上所述，传统数仓和大数据环境下的数仓还是有很多区别的：

• 数仓设计的工具都是一样的，这个不会变；
• 由于大数据集群中，表关联的代价比较大，因此数仓建模会更多的使用宽表，所以这里会有一些变化；
• 数据处理和调度工具用kettle基本都OK，没啥太大变化，但是需要了解一下Flume、Kafka等工具；
• 数据存储这边需要深入了解一下，这是单体数据库和集群数据库的差别，会有分布式一致性的各种乱七八糟的问题；
• 数据计算引擎也有变化，也是单体数据库和集群数据库的差别。分布式计算会有数据倾斜、join代价高等问题，所以优化的方法和方向也不一样；
• 数据总体架构设计的时候也会有所变化，传统数仓整个BI套件就ok了，大数据环境下可能要面对更多的各种复杂需求，所需的大数据组件就变多了，需要系统学习。

建议传统数据仓库工程师的转型路线：

传统数仓-离线数仓（批数据处理）-实时数据处理（流数据处理）-lambda架构-kappa架构（批流一体）。

来源网络侵删