传统数仓和⼤数据数仓的区别是什么？
这是我的第58篇原创
⼀个圈⾥的朋友问，有很多传统数仓的朋友想转型⼤数据数仓，不知道该怎么办。问我能不能给讲讲课。准备⼀个课⽐较费劲，主要是得⾮常系统的讲。我这样⽇更，已经把所有的时间都占满了。那我就每天写⼀点，希望能帮助更多想转型⼤数据数仓的兄弟们。
概念与容器
为什么先说这个，其实很简单：因为绝⼤多数⼈都把这两个概念混为⼀谈。然后就会出现各种各样的问题：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、DW\DM融合
两派吵了很久很久，各⾃都有死忠，也都有对的理由，各⾃也都说服不了对⽅。双⽅也明⽩了：“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⼯具。
大数据etl工具有哪些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本⾝只是⼀个计算引擎，因此还需要⼀个提供快速查询的⼯具和⼀
个展⽰的⼯具。所以现在的架构就变成了这样：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。