这是我的第五十八个原件
一位社团朋友问，很多传统的几仓朋友都想转型大数据几仓，不知道该怎么办。 我可以讲课吗？ 准备课程很辛苦，主要是需要非常系统地说话。 我这么一天比一天，已经把所有的时间都订满了。 那么，我每天写一点。 希望能帮助更多想变革大数据数仓的兄弟们。
概念和容器
为什么先说这个，其实很简单。 因为大部分人把这两个概念混淆了。 然后，就会出现各种各样的问题： oracle不是数据库，如何是数据仓库。 Hive不是数据仓库吗？ 怎么是数据库？
数据仓库、数据库是概念，是一些技术的集合。 和切菜包丁法和雕刻刀法一样
Oracel、DB2、MySQL和Hive是容器和工具。 和刀一样。
当我们谈论数据仓库时，我们在说什么？ 你使用的mysql还是oracle？ 你用的是Hive还是Kylin？ 是druid还是孝顺的海豚？ 都不是！ 因为这些都是实现数据仓库的工具！
说到数据仓库，我们实际上是一组面向主题、沉淀历史不变的信息、提供在线分析服务以进行决策的数据技术，总结详细的数据。
我们要实现数据仓库，需要数据仓库设计(数据库设计工具)、数据存储技术(数据库工具)、数据处理技术(ETL工具、监控报警)、数据管理技术)、元数据、数据
oracle、mysql、hadoop等只是数据存储技术之一。
数据仓库发展历史
1、数据仓库概念诞生
数据仓库之父yxdmt(billinmon )于1991年提出了数据仓库概念的第一个定义者。 到目前为止，所有业务运营和分析数据都存在于一个数据库中，没有分离。
这个inmon是inmon，kimball建仓方法论的inmon，熟悉吗？
和大多数新概念一样，初生的数据仓库也经历了巨大的失败。 inmon的建设理念是自上而下，它指向数据上游，而不是数据层次的上层。
大家都在做几仓。 你一定明白为什么一开始数据仓库的概念会惨败。 自上而下难以见效，必须把一切工作搞清楚，把所有系统的数据搞清楚，然后分主题一点一点地设计，再按照设计进行一层楼的建设。 而且，如果其中有什么变更的话，整个设计就会全部废除。 所以第一次吃螃蟹的公司基本上是大鼠。
2、数据集市概念诞生
这时，一位英雄站了起来。 这就是Kimball。 他写了本《TheDataWarehouseToolkit》，开启了数据集市的狂潮，开启了另一个数据仓库建设流派Kimball的自下而上流派。 这上面，下面也是上下游的意思。 Kimball建议，百鸟与其在林中，不如一鸟在手。 先做销售部门，把握销售部门的需求，就等于先封住下游的需求。 然后按照顺藤摸瓜的方式，设计几个仓库的各个楼层，最后接触业务系统(CRM ERP人力系统)，查找业务系统的数据，就完成了销售部门级的数据集市。
由于这种方法的需求少了，设计工作少了，难度也低了，相应的建设难度和工作量也少了，建设速度快了，效果也快了。 对工作的开展非常有利。 所以数据集市走了一条很大的路。
3、DWDM融合
两派吵架了很久，各有死忠，都有正确的理由，都说服不了对方。 双方都明白，“one size fits all”不可能一蹴而就。 终于在1998年，Inmon提出了新的BI架构cif (公司信息工厂)。
gn: left">上面这张图就是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架构（批流一体）。
另外，还有一些朋友一直在问，数据仓库、数据湖、数据中台都有啥区别啊？这些也都很火啊，能不能讲讲？这些也早已分享过了，
点击查看：一口气说穿数据中台-给你架构师的视角，数据库、数据仓库、数据湖、数据中台全给你讲清楚了。
点击查看：如何搭建一个数据仓库，给你完整的数仓建设流程。
点击查看：一口气讲完数据仓建模方法--数据仓库架构师碎碎念，给你所有建模方法。 点击查看：【资料包】数据仓库建设完整资料包，给你业务梳理、指标体系梳理、维度梳理、事实表梳理、命名规范、数据仓库设计文档，外加数仓维度建模电子书和大厂数仓建设实战经验。兄弟，祝你好运！转型成功！工资涨涨涨！
往期精彩回顾
干货 | 架构师的视角看透中台
热文 | 大数据工程师体系职业路径全解
干货 | 什么才叫做懂业务？分析的5个层次
如果你觉得有用，就请帮忙分享一下，
码字不易，我需要你的鼓励！