很可惜 T 。T 您现在还不是作者身份，不能自主发稿哦～
如有投稿需求，请把文章发送到邮箱tougao@appcpx.com，一经录用会有专人和您联系
咨询如何成为春羽作者请联系：鸟哥笔记小羽毛（ngbjxym）
这是我的第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架构（批流一体）。
另外，还有一些朋友一直在问，数据仓库、数据湖、数据中台都有啥区别啊？这些也都很火啊，能不能讲讲？这些也早已分享过了，
点击查看：一口气说穿数据中台-给你架构师的视角，数据库、数据仓库、数据湖、数据中台全给你讲清楚了。
点击查看：如何搭建一个数据仓库，给你完整的数仓建设流程。
兄弟，祝你好运！转型成功！工资涨涨涨！
往期精彩回顾
本文为作者独立观点，不代表鸟哥笔记立场，未经允许不得转载。
《鸟哥笔记版权及免责申明》 如对文章、图片、字体等版权有疑问，请点击 反馈举报
Powered by QINGMOB PTE. LTD. © 2010-2022 上海青墨信息科技有限公司 沪ICP备2021034055号-6
我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求，为完善跟帖评论自律管理，为了保护用户创造的内容、维护开放、真实、专业的平台氛围，我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容，同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。
一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规，对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息，主要表现为：
1)反对宪法所确定的基本原则；
2)危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一，损害国家荣誉和利益；
3)侮辱、滥用英烈形象，歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉；
4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动；
5)煽动民族仇恨、民族歧视，破坏民族团结；
6)破坏国家宗教政策，宣扬邪教和封建迷信；
7)散布谣言，扰乱社会秩序，破坏社会稳定；
8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪；
9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；
10)侮辱或者诽谤他人，侵害他人名誉、隐私和其他合法权益；
11)通过网络以文字、图片、音视频等形式，对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法规禁止的其他内容；
2. 不友善：不尊重用户及其所贡献内容的信息或行为。主要表现为：
1)轻蔑：贬低、轻视他人及其劳动成果；
2)诽谤：捏造、散布虚假事实，损害他人名誉；
3)嘲讽：以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述，以此来激怒他人；
4)挑衅：以不友好的方式激怒他人，意图使对方对自己的言论作出回应，蓄意制造事端；
5)羞辱：贬低他人的能力、行为、生理或身份特征，让对方难堪；
6)谩骂：以不文明的语言对他人进行负面评价；
7)歧视：煽动人群歧视、地域歧视等，针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击；
8)威胁：许诺以不良的后果来迫使他人服从自己的意志；
3. 发布垃圾广告信息：以推广曝光为目的，发布影响用户体验、扰乱本网站秩序的内容，或进行相关行为。主要表现为：
1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式：
2)单个帐号多次发布包含垃圾广告的内容；
3)多个广告帐号互相配合发布、传播包含垃圾广告的内容；
4)多次发布包含欺骗性外链的内容，如未注明的淘宝客链接、跳转网站等，诱骗用户点击链接
5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光；
6)购买或出售帐号之间虚假地互动，发布干扰网站秩序的推广内容及相关交易。
7)发布包含欺骗性的恶意营销内容，如通过伪造经历、冒充他人等方式进行恶意营销；
8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。
4. 色情低俗信息，主要表现为：
1)包含自己或他人性经验的细节描述或露骨的感受描述；
2)涉及色情段子、两性笑话的低俗内容；
3)配图、头图中包含庸俗或挑逗性图片的内容；
4)带有性暗示、性挑逗等易使人产生性联想；
5)展现血腥、惊悚、残忍等致人身心不适；
6)炒作绯闻、丑闻、劣迹等；
7)宣扬低俗、庸俗、媚俗内容。
5. 不实信息，主要表现为：
1)可能存在事实性错误或者造谣等内容；
2)存在事实夸大、伪造虚假经历等误导他人的内容；
3)伪造身份、冒充他人，通过头像、用户名等个人信息暗示自己具有特定身份，或与特定机构或个人存在关联。
6. 传播封建迷信，主要表现为：
1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病；
2)求推荐算命看相大师；
3)针对具体风水等问题进行求助或咨询；
4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失，包括通过占卜方法问婚姻、前程、运势，东西宠物丢了能不能找回、取名改名等；
7. 文章标题党，主要表现为：
1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户；
2)内容与标题之间存在严重不实或者原意扭曲；
3)使用夸张标题，内容与标题严重不符的。
8.「饭圈」乱象行为，主要表现为：
1)诱导未成年人应援集资、高额消费、投票打榜
2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
5)通过「蹭热点」、制造话题等形式干扰舆论，影响传播秩序
9. 其他危害行为或内容，主要表现为：
1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的；
2)不当评述自然灾害、重大事故等灾难的；
3)美化、粉饰侵略战争行为的；
4)法律、行政法规禁止，或可能对网络生态造成不良影响的其他内容。
二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时，本网站将依据相关用户违规情节严重程度，对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号，或者滥用多个帐号发布违规内容时，本网站将加重处罚。
三、申诉
随着平台管理经验的不断丰富，本网站出于维护本网站氛围和秩序的目的，将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议，可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)