传统数仓和大数据数仓的区别是什么？
发布时间：2022-11-12 10:56:08 所属栏目：大数据 来源：
导读： 概念与容器
为什么先说这个，其实很简单：因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题：oracle不是数据库么，怎么又是数据仓库？Hive不是数据仓库么？怎么又是数据库？
为什么先说这个，其实很简单：因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题：oracle不是数据库么，怎么又是数据仓库？Hive不是数据仓库么？怎么又是数据库？
|
概念与容器 为什么先说这个，其实很简单：因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题：oracle不是数据库么，怎么又是数据仓库？Hive不是数据仓库么？怎么又是数据库？ 数据仓库、数据库是一个概念，是一些技术的集合。类同于切菜刀法和雕刻刀法； Oracel、DB2、MySQL、Hive是一个容器，是一种工具。类同于一把刀。 当我们在说数据仓库的时候，我们在说什么？说的是你用的mysql还是oracle？用的是Hive还是Kylin？用的是druid还是doris？都不是！因为这些是实现数据仓库的工具！ 我们在说数据仓库的时候，我们实际上说的是一种面向主题，沉淀历史不可变信息，对明细数据进行汇总的，为决策提供在线分析服务的数据技术的集合。 我们在实现数据仓库的时候，需要用到数据仓库设计（数据库设计工具）、数据存储技术（数据库工具）、数据处理技术（ETL工具、监控报警）、数据管理技术（元数据、数据地图、血缘关系）等等技术。 而oracle、mysql、hadoop等都只是数据存储技术中的一种而已。 数据仓库发展历史 1、数据仓库概念诞生 数据仓库概念公认最早的定义者，是数据仓库之父比尔·恩门（Bill Inmon）在1991提出的。在此之前，所有的业务操作数据和分析数据都是存在一个数据库中的，并没有分开。 mysql 大数据存储_大数据存储系统_大数据存储公司 这个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等）的工具而已。 大数据环境中工具清单： 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本身只是一个计算引擎，因此还需要一个提供快速查询的工具和一个展示的工具。所以现在的架构就变成了这样： 总结 综上所述，传统数仓和大数据环境下的数仓还是有很多区别的： 建议传统数据仓库工程师的转型路线： 传统数仓-离线数仓（批数据处理）-实时数据处理（流数据处理）-lambda架构-kappa架构（批流一体）。 （编辑：PHP编程网 - 襄阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330434号