持续输出  敬请关注

大数据架构  湖仓一体化  流批一体 离线+实时数仓 

各种大数据解决方案  各种大数据新技术实践

持续输出  敬请关注

第一篇  ⼤数据平台基础架构及解决⽅案

提示：基础架构重在基础平台选型，重在基础软件。 

目录

1.1 ⼤数据架构发展历程

1.1.1 基础架构变迁史

1.1.1.1 前Hadoop时代(2003-2007)

1.1.1.2 后Hadoop时代(2008-2014)

1.1.1.3 Hadoop商业发⾏版时代（ 2011-2020）

​1.1.1.4 国产化开源发⾏版时代(2021开始)

1.1.1.5 总结

1.1.2 ⼤数据计算引擎技术变迁

1.1.2.1 ⼀代：离线处理引擎

1.1.2.2 ⼆代：⽀持DAG的计算引擎

​1.1.2.3 三代：内置DAG的计算引擎

1.1.2.4 四代：统⼀计算引擎

1.1.3 流处理引擎变迁

1.1.3.1 ⼀代： Storm

1.1.3.2 ⼆代： Spark Streaming

1.1.3.3 三代： Flink

1.1.4 流处理技术横向对⽐

1.1.4.1 不同流派流处理技术对⽐

1.1.4.2 Flink VS Spark

1.2 常⻅Hadoop发⾏版

1.2.1 Apache原⽣版本

1.2.2 CDH+HDP=CDP

1.2.2.1 CDH的套路

1.2.2.2 HDP难逃⼀“死”

1.2.2.3 CDH+HDP=CDP

 1.3 云原⽣套件

 1.3.1 阿⾥云

 1.3.2 腾讯云

 1.3.3 百度云

 1.3.4 华为云

1.4 Ambari + Bigtop Stack

【下一篇】新⼀代USDP开源套件

1.1 ⼤数据架构发展历程

1.1.1 基础架构变迁史

1.1.1.1 前Hadoop时代(2003-2007)

       标志事件是⾕歌三⼤论⽂及Doug Cutting发布Hadoop、 Hbase。这个时代的⼀些⼤事件如下：1998年9⽉4⽇， Google公司在美国硅⾕成⽴，以做搜索引擎起家。⼏乎是同⼀时期，美国有个名不⻅经传的⼯程师名叫Doug Cutting，他疯狂迷恋搜索引擎技术，于是他做了⼀个⽤于⽂本搜索的函数库（姑且理解为软件的功能组件），命名为Lucene。

       Lucene是用Java写的，⽬标就是为各种中⼩型应⽤轻松加⼊全⽂检索的功能，因为开源⼜好⽤，因此⾮常受程序员欢迎。早期的时候，这个项⽬被发布在Doug Cutting的个⼈⽹站和SourceForge(⼀个开源软件⽹站)。 2001年底，Lucene成为了Apache软件基⾦会Jakarta项⽬的⼀个⼦项⽬(https://baike.baidu.com/item/Jakarta/15952232?fr=aladdin)。

        2004年， Doug Cutting在Lucene的基础上开发⼀款当时可以媲美主流搜索引擎的开源搜索引擎，命名为Nutch。

        Nutch基于Lucene实现全⽂检索，并增加了⽹络爬⾍和⼀些⽹⻚相关的功能，就像⾕歌搜索引擎⼀样。 Nutch的影响⼒甚⾄超过Luncene。
        随着时间推移，⽆论⾕歌还是Nutch都⾯临海量数据的问题，尤其是⾕歌，作为互联⽹搜索引擎，需要存储⼤量⽹⻚，所以需要不断优化算法。在这个过程中⾕歌找到不少好办法，并以论⽂的形式⽆私分享出来。

        2003年，也就是Nutch诞⽣的前⼀年，⾕歌发表技术论⽂，公开介绍了⾃⼰的⽂件系统GFS (Google File System)，这就是⾕歌为存储海量搜索数据⽽设计的专⽤⽂件系统。
        2004年， Doug Cutting基于⾕歌的GFS论⽂实现了分布式⽂件系统，取名NDFS（ Nutch Distributed File System）。

         还是2004年， Google发表学术论⽂，介绍⾃⼰的MapReduce编程模型，这个模型⽤于⼤规模分布式计算。
         2005年， Doug Cutting基于MapReduce在Nutch中实现了该功能。

       2006年， Yahoo公司招安了Doug Cutting。招安的背景是，雅⻁2004年之前⼀直使⽤⾕歌的搜索引擎作为⾃⼰的搜索服务， 2004年开始⾃研搜索引擎。

       加盟Yahoo之后， Doug cutting将NDFS和MapReduce进⾏升级改造，重命名为Hadoop(他⼉⼦的⼀个玩具⼤象的名字)。

       还是在2006年， Google⼜发论⽂了，这次介绍的是⾃⼰的BigTable，⼀种分布式的数据存储系统，⽤于存储海量数据的⾮关系型数据库。
       Doug Cutting当然没放过，在⾃⼰的Hadoop系统基于BigTable的思想开发了Hbase。

         Doug Cutting后来成为了ASF理事，搜索引擎专家，任职Cloudera， 被誉为Hadoop之⽗。

1.1.1.2 后Hadoop时代(2008-2014)

       后Hadoop时代以Hadoop、 Hive、 Hbase为代表，各种⼤数据组件层出不穷。
        标志性时间是Hadoop在2008年成功上位，成为Apache基⾦会顶级项⽬。同年， Facebook贡献Hive到开源社区。
        2008年， Hadoop商业公司Cloudera成⽴，发布套件CDH。

        2010年Hbase成为顶级项⽬。
        2012年， Yarn正式亮相。
        2014年， Spark、 Flink、 Storm纷纷成为Apache顶级项⽬，流处理⼤⾏其道。

1.1.1.3 Hadoop商业发⾏版时代（ 2011-2020）

        2011年Hortonworks成⽴，开始跟Cloudera展开竞争，发布套件HDP。各种商业的云原⽣Hadoop套件也相继出现，主要是”四⼤云“：

1.1.1.4 国产化开源发⾏版时代(2021开始)

        2018年Cloudera和Hortonworks公司宣布合并。

        2020年2⽉， Cloudera宣布，从CDH 6.3.3版本开始，将不会再提供免费版。国内使⽤CDH和HDP的⼤部分公司，以后将⽆法再使⽤免费的午餐。
        可喜的是， Ucloud团队发布了可以免费试⽤的Hadoop发⾏版。

1.1.1.5 总结

发展阶段	关键词	特点
前Hadoop时代 (2003-2007)	三⼤论⽂、 DougCutting、 Hadoop	萌芽阶段，谈不上架构
后Hadoop时代 (2008-2014)	Hadoop、 Hbase、 Hive、 Pig、 Sqoop等百花⻬放，眼花缭乱	各种组件层出不穷，相互之间的兼容性管理 混乱，使⽤者可选择性多，但是很乱
Hadoop商业发⾏版 时代（ 2011-2020）	商业发⾏版、 CDH、 HDP、 Mapr 等等，云原⽣套件出现	标准的发⾏版⼤⾏其道，提供免费版本，云 原⽣商业版如⽕如荼
国产化开源发⾏版时 代(2021开始)	USDP	标准发⾏版纷纷收费，国产化开源发⾏版势 在必⾏

1.1.2 ⼤数据计算引擎技术变迁

        众所周知，在开源世界第⼀个流⾏的⼤数据处理引擎是Hadoop MapReduce。实际上经过这么多年的发展，⼤数据处理引擎已经发展到了第四代。

1.1.2.1 ⼀代：离线处理引擎

        以Hadoop MapReduce为代表，采⽤分⽽治之的思想将计算分为两个阶段，分别为 Map 和 Reduce。 Hive严格意义上来说不能算是独⽴的计算引擎，它只是MapReduce的SQL引擎层，起到翻译SQL为MapReduce进⽽降低开发成本的作⽤。
       Job拆分为Map 和 Reduce虽然解决了⼤数据计算的问题，但对于上层应⽤来说，就不得不想⽅设法去拆分算法，甚⾄不得不在上层应⽤实现多个 Job 的串联，以完成⼀个完整的算法，例如迭代计算。

1.1.2.2 ⼆代：⽀持DAG的计算引擎

       DAG框架（ Tez） + MapReduce为代表。 MapReduce逼着上层应⽤拆分算法的弊端催⽣了⽀持DAG计算框架的产⽣。因此，⽀持 DAG 的框架被划分为第⼆代计算引擎。如Tez+MapReduce ，或者多个MapReduce通过Oozie/Azkaban这些调度引擎来配置DAG 。弊端是⼤多还是批处理。

1.2.2.3三代：内置DAG的计算引擎

        以 Spark 为代表的第三代的计算引擎的特点主要是 Job 内部的 DAG ⽀持（不跨越 Job），批处理、流处理、 SQL⾼层API⽀持，内存迭代计算、性能较之前⼤幅提升。
        当然，Storm在整个计算引擎中也可以归到第三代，只不过它专注于流处理，内⽀持DAG。

 1.2.2.4 四代：统⼀计算引擎

       主要是Flink，这个“统⼀的引擎”包括流、批处理、机器学习、图计算等等。 Flink被归在了第四代主要表现在 Flink对流计算的⽀持更加完善，性能更⾼，尤其是窗⼝计算，状态和容错。当然 Flink 也可以⽀持 Batch 的任务，以及DAG 的运算。Spark随着⾃身发展，新的版本也出现了第四代的影⼦，甚⾄在机器学习算法库⽅⾯暂时⽐Flink还要领先。

1.1.3 流处理引擎变迁

        如果单看流处理引擎，⽬前发展经过了三代：

1.1.3.1 ⼀代： Storm

        第⼀个流⾏的流处理引擎是Apache Storm，它提供了低延迟的流处理，但是为了实时性牺牲了吞吐量，且很难原⽣实现exactly-once语义（恰好⼀次），需要借助外部组件相当⼤的开销才能保证正确级别。

1.1.3.2  ⼆代： Spark Streaming

       在低延迟的同时保证⾼吞吐，还得保证正确性和容错性是⾮常困难的。很快⼈们想到⼀种折中的办法：将流处理中连续的事件流分割成微⼩的批处理作业（微批处理），只要分的⾜够⼩就可以接近流处理，借此实现秒级甚⾄亚秒级延迟。 Spark处理引擎在这个思路下推出了Spark Streaming，这就是第⼆代流处理引擎。
       另外， Spark Streaming微批处理在容错⽅⾯有了进步，可以实现exactly-once语义。如果某⼀个微批处理job失败，它只需要重新计算这⼀⼩批数据即可，开销降低很多。
       Storm Trident是对Storm的扩展和改进的产物，他也是微批处理引擎的代表，同样实现了exactly-once语义，延迟上也损伤不⼩。
       Spark Streaming和Storm Trident的微批处理⽅案只能按照时间的倍数对事件进⾏切分，对于乱序、延迟敏感的作业需要开发者额外花费⼤量时间来处理，开发运维成本⾼。

1.1.3.3 三代： Flink

       第三代流处理引擎Flink避免了前两代的弊端，兼具各家所⻓做到了：⾼吞吐+低延迟+⾼压⼒下的容错性+多语义窗⼝。
       特别说明：分代各有各的⻅解，我觉得其实这并不重要，重要的是体会各个框架的差异，以及更适合的场景。技术⽆好坏，没有银弹可以覆盖所有场景，就像Spark 没有完全取代Hadoop，当然 Flink也不可能完全取代 Spark，它们都将在各⾃适合的场景发挥更加的价值。

1.1.4 流处理技术横向对⽐

1.4.1.1 不同流派流处理技术对⽐

在⽐较Flink和Spark两⼤巨头之前，先把不同流派的流处理技术做⼀个对⽐：

 1.4.1.2 Flink VS Spark

（1）API对比

（2）⽣态系统对比
         ⽣态系统上Flink已经追上了Spark。

（3）运⾏时环境对比
         运⾏时环境⼆者处于伯仲之间。

（4）社区⽀持对比
        Spark 社区在规模和活跃程度上都是领先的，毕竟多了⼏年发展时间，同时背后的商业公司Databricks由于本⼟优势使得Spark在美国的影响⼒明显优于Flink。
       ⽽Flink作为⼀个德国公司， Data Artisans 想在美国扩⼤影响⼒要更难⼀些。不过 Flink 社区也有⼀批稳定的⽀持者，达到了可持续发展的规模。
       在中国情况可能会稍有不⼀样。⽐起美国公司，中国公司做事情速度更快，更愿意尝试新技术。中国的⼀些创新场景也对实时性有更⾼的需求。这些都对 Flink 更友好⼀些。尤其是Flink收购Flink⺟公司Data Artisans之后，对Flink的社区⽀持⼒度不断加⼤。

（5）对⽐结论
        Spark 和 Flink 都是通⽤的开源⼤规模处理引擎，⽬标是在⼀个系统中⽀持所有的数据处理以带来效能的提升。

        两者都有相对⽐较成熟的⽣态系统。是下⼀代⼤数据引擎最有⼒的竞争者。
        Spark 的⽣态总体更完善⼀些，在机器学习的集成和易⽤性上暂时领先。
        Flink 在流计算上有明显优势，核⼼架构和模型也更透彻和灵活⼀些。
        没有谁强谁弱，只有哪个更适合当前的场景以及⼿头可⽤的开发资源。

1.2 常⻅Hadoop发⾏版

注意：这⾥的Hadoop的是⼴义的Hadoop，代表整个⼤数据基础平台。

1.2.1 Apache原⽣版本

        Hadoop⽣态的组件绝⼤部分都是Apache开源项⽬，各⾃都有⾃⼰的开发者群体在维护，因此在版本相互之间的兼容性⽅⾯很难把控。

 1.2.2 CDH+HDP=CDP

 1.2.2.1 CDH的套路

        在今年2⽉份的时候， Cloudera宣布，从CDH 6.3.3版本开始，将不会再提供免费（Cloudera Express）：https://community.cloudera.com/t5/ProductAnnouncements/ANNOUNCE-Cloudera-Enterprise-6-3-3-Released/td-p/289016
       其实现在来看，完全就是⼀个温⽔煮⻘蛙的过程，我们看⼀下他的套路：免费版不限制节点数量 -> CDH 6.x 免费版限制节点数量 -> CDH 6.3.3 没有免费版，只能试⽤90天，最终就是要花钱。

1.2.2.2 HDP难逃⼀“死”

       另⼀个免费午餐， Hortonworks 的 HDP，在 Cloudera 和 Hortonworks 合并之后，恐怕是危矣，虽然⽬前没有什么确切的消息指明 HDP 的更新⼀定会停⽌，但事实上现在所有指向 HDP 的官⽅链接，都在⽆时⽆刻的向你推销，告诉你赶紧升级到 CDP。
       从商业的⻆度看，合并之后如果还继续更新 HDP，是增加内耗，毕竟本来就是为了报团取暖才进⾏的合并。

1.2.2.3 CDH+HDP=CDP

Cloudera 和 Hortonworks 合并之后推出的产品，上来就是收费的。

 1.3 云原⽣套件

 1.3.1 阿⾥云

 1.3.2 腾讯云

 1.3.3 百度云

 1.3.4 华为云

1.4 Ambari + Bigtop Stack

        Apache Ambari⼤家都⽐较熟悉，作为 Hortonworks 贡献给社区的项⽬， HDP虽然没了，但是Ambari 是Apache的，不可能收费，所以完全可以使⽤Ambari 降低了集群的安装、部署、运维的难度，且可以 扩展Ambari去⽀持更多的组件。
        什么是 Stack 呢？实际上就是⼀组预定义好的组件服务和命令脚本的集合。⽽ Apache Ambari 和 Cloudera Manager ⼀样，都属于⼀个“管理界⾯⼯具”，在 Apache Ambari 的架构中，实际上 Ambari Stack 是完全可以将HDP Stack 替换为第三⽅提供的 Stack，或者是你⾃⼰定义的 Stack 的。
       ⾃⼰定义的 Stack是⾮常难的， Hadoop ⽣态圈的项⽬众多，各种编译依赖⼜特别复杂，并且不同组件版本之间还有乱作⼀团麻的版本兼容性问题，如果你再考虑到⽬标硬件平台的话，个⼈开发者肯定是没有办法从头去构建⼀个⾃定义的 Stack 的。
       这个时候就需要使⽤到 Apache BigTop （ https://bigtop.apache.org/）了。
 

【下一篇】大开眼界，新⼀代USDP开源套件