这是我的第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工具。
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架构(批流一体)。
另外,还有一些朋友一直在问,数据仓库、数据湖、数据中台都有啥区别啊?这些也都很火啊,能不能讲讲?这些也早已分享过了,
点击查看:一口气说穿数据中台-给你架构师的视角,数据库、数据仓库、数据湖、数据中台全给你讲清楚了。
点击查看:如何搭建一个数据仓库,给你完整的数仓建设流程。
点击查看:一口气讲完数据仓建模方法--数据仓库架构师碎碎念,给你所有建模方法。
点击查看:【资料包】数据仓库建设完整资料包,给你业务梳理、指标体系梳理、维度梳理、事实表梳理、命名规范、数据仓库设计文档,外加数仓维度建模电子书和大厂数仓建设实战经验。
兄弟,祝你好运!转型成功!工资涨涨涨!