做网站要的图片斗鱼,合肥做淘宝网站推广,公司建设网站的请示,服务公司logo概念与容器为什么先说这个#xff0c;其实很简单#xff1a;因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题#xff1a;oracle不是数据库么#xff0c;怎么又是数据仓库#xff1f;Hive不是数据仓库么#xff1f;怎么又是数据库#xff1f;数据仓库…概念与容器为什么先说这个其实很简单因为绝大多数人都把这两个概念混为一谈。然后就会出现各种各样的问题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建议百鸟在林不如一鸟在手。先搞一个销售部门摸清销售部门的需求等于把下游的需求先锁死。然后再顺藤摸瓜把数仓的每一层设计好最后再摸到业务系统CRMERP人力系统找业务系统的数据这样就建立了一个销售部门级的数据集市。由于这种方法的需求少了设计工作少难度也就低了对应的建设难度和工作量也少建设速度就快见效也就快啊非常利于工作的开展。所以数据集市大行其道。3、DWDM融合两派吵了很久很久各自都有死忠也都有对的理由各自也都说服不了对方。双方也明白了“one size fits all”一码通用是不可能的。终于在1998年 Inmon提出了新的BI架构CIF(CorporationInformation Factory,企业信息工厂)。上面这张图就是inmon老爷子画的看上去很乱对吧其实按照咱现在的视角看就很清晰了这个架构是不是很熟悉对这个架构从1998年到现在就没变过而且也是所有数据仓库建设的框架性指南。4、实时数仓一直到最近两年实时处理技术的飞速发展才将数据仓库的架构往前又推了一步出现了实时数仓。实时数仓又分为批数据流数据、批流一体两种架构。从这里开始也就正式进入了大数据环境下的数据仓库范畴。大数据环境下的数据仓库1、离线数仓刚转到大数据环境中的哥们会很奇怪为啥有一个数仓叫离线数仓从来没听过啊其实离线数仓就是咱以前做的传统数仓数据以T1的形式计算好放在那里给前台的各种分析应用提供算好的数据。这也被称为“大数据的批处理”。只不过原本的单体环境工具oracle、informatica等基本都被替换成了大数据体系内Hadoop、Hive、Sqoop、oozie等的工具而已。大数据环境中工具清单数据采集flume/logstashkafka替代传统数仓的FTP批量数据同步Sqoop、Kettle跟传统数仓一样用Kettle部分商用ETL工具也开始支持大数据集群;大数据存储Hadoop HDFS/Hive、TiDB、GP等MPP替代传统数仓的Oracle、MySQL、MS SQL、DB2等大数据计算引擎MapReduce、Spark、Tez替代传统数仓的数据库执行引擎OLAP引擎Kylin/druidMolap需预计算、Presto/ImpalaRolap无需预计算替代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 N1中当N1的数据进度赶上table n了就停掉table n的任务。3、Kappa 架构查询分析展示Kappa架构只到数据服务层Flink本身只是一个计算引擎因此还需要一个提供快速查询的工具和一个展示的工具。所以现在的架构就变成了这样总结综上所述传统数仓和大数据环境下的数仓还是有很多区别的数仓设计的工具都是一样的这个不会变由于大数据集群中表关联的代价比较大因此数仓建模会更多的使用宽表所以这里会有一些变化数据处理和调度工具用kettle基本都OK没啥太大变化但是需要了解一下Flume、Kafka等工具数据存储这边需要深入了解一下这是单体数据库和集群数据库的差别会有分布式一致性的各种乱七八糟的问题数据计算引擎也有变化也是单体数据库和集群数据库的差别。分布式计算会有数据倾斜、join代价高等问题所以优化的方法和方向也不一样数据总体架构设计的时候也会有所变化传统数仓整个BI套件就ok了大数据环境下可能要面对更多的各种复杂需求所需的大数据组件就变多了需要系统学习。建议传统数据仓库工程师的转型路线传统数仓-离线数仓批数据处理-实时数据处理流数据处理-lambda架构-kappa架构批流一体。来源网络侵删