近几年里，大数据行业发展势头迅猛，故而相应的分布式产品和架构层出不穷，本文分享作者在大数据系统实践过程中接触过的一些工具及使用感受，抛砖引玉，和同学们一起构建一个分布式产品的全景图 。
下图是由著名的数据观察家Matt Turck在它的BLOG（https://mattturck.com/） 里发出的2019年人工智能和大数据产业图，他从2012年开始每年都会绘制一张，大致描述这个产业里的公司及其数据相关的产品，以及所属问题的领域 。 这里面大部分是商业软件，而对于绝大多数互联网公司，中间绿色的开源产品可能大家接触的更多一些，而这些产品里，绝大多数都属于Apache基金会 。
下面我从中挑选一些东西随便聊聊，因为是随便聊聊，所以知识点并不全，也不能帮助大家知道如何搭建和使用，以及如何避坑，只是谈谈我对这些东西的印象，描述一个大概的轮廓，如有使用需求可以搜索网上其它文章，资料还是很多的 。 当然，大家对其中的内容有兴趣可以随时找我交流讨论，对文中如有描述错误的地方也欢迎大家斧正，共同学习，谢谢 。
Apache Hadoop官网：http://hadoop.apache.org/
Hadoop项目下包含了很多子项目，从计算到存储都有，比如HDFS、MapReduce、YARN、HBase 。
HDFS全称叫做Hadoop分布式文件系统，其主要由一个NameNode(NN)和多个DataNode(DN)组成，数据文件会分成多个Block，这些Block按照不同主机，不同机架的策略以默认一备三的情况分布存储在各个节点 。 现在每个Block大小默认是128MB，以后随着磁盘寻址速度的增加，这个Block也会不断增大 。 而NN里面则存储了这些Block元数据的信息，这样客户端进行数据查询的时候，DN告知所需数据的位置 。 从这种结构上能看出一些比较明显的问题就是NN节点的单点问题，所以在Hadoop 2.x的时候，针对NN做了一些改进 。
首先是在系统可用性上，增加了一个StandBy状态的NN，作为服务中NN（Active NN）的备机，当服务中的NN挂掉后，由StandBy的NN自动接替工作 。 而NN节点状态的健康和服务切换，由ZKFC负责 。 主备NN之间的信息同步则由Quorum Journal Node负责 。
其次，由于单台NN中存储了大量的元数据信息，所以随着HDFS数据量的不断增加，显然NN必将成为系统的瓶颈，为了解决这个问题，Hadoop 2.x增加了Federation，该技术允许系统中有多台NN同时对外提供服务，这多台NN将DN中的所有文件路径进行了横向拆分，每个DN负责不同的路径，达到了横向扩展的效果 。
除了HDFS，Hadoop 2.x也引入了YARN，该工具负责对集群中的资源进行管理和任务的协调 。 该工具分成一个ResourceManager(RM)和多个NodeManager(NM)，当一个任务提交给YARN之后，会先在某一服务器上启动一个ApplicationMaster(AM)，AM向RM申请资源，RM通过NM寻找集群中空闲的资源，NM将资源打包成一个个Container，交给AM 。 AM将数据和程序分发到对应节点上处理，如果某个Container中的任务执行失败了，AM会重新向RM申请新的Container 。
Apache Hadoop HBase & Kudu官网：http://hbase.apache.org/
众所周知，HBase一个分布式列式存储系统，同样属于Hadoop的子项目，列式存储的优劣在这里不说了，提一下HBase的WAL和LSM，WAL全称为Write Ahead Log，只是在数据修改操作前，会先将此操作记录在日志中，这样一旦服务崩溃，通过该日志即可进行数据的恢复，提到这里有些人就会联想到MySQL，因为InnoDB引擎的redo log就是典型的WAL应用 。 而在HBase中该功能是由叫做HLog的模块所完成的 。 再说LSM，其全称为Log Structured Merge Trees，介绍原理的文章也有很多，在HBase中，LSM树是MemStore模块的底层存储结构，而MemStore有三个作用，一是当有数据写入的时候，直接写到MemStore中，从而提升写数据的效率 。 二是充当读取数据时的缓存 。 三是定期对数据操作去重，并进行数据落盘 。 HBase的主要角色分别有HMaster和HRegionServer，同样是一对多的关系，而各节点的状态全都交由Zookeeper负责 。 Kudu是一个和HBase非常类似的产品，其不同之处在于Kudu不依赖Zookeeper来管理自己的集群，并且HBase的数据是保存在HDFS上的，而Kudu拥有自己的数据文件格式 。
Apache Spark官网：https://spark.apache.org/
Spark是由加州大学伯克利分校推出的分布式计算引擎，在Spark的官方主页上有一张和Hadoop的性能对比图，姑且不谈这张图中数据的准确性，但是Spark的确将Hadoop（主要是指MapReduce）的性能提升了一个量级 。 我理解这主要得益于两个方面：第一个是Spark计算过程中生成的中间数据不再落盘，没有了Spill的阶段 。 第二个是引入DAG对任务进行拆解，一个完整的Job被分成多个Stage，每个Stage里面又有多个Task，通过一张有向无环图，使得没有依赖关系的Task可以并行运行 。
推荐阅读
- 我个人做出了以下6点思考 如何做好游戏用户运营？
- 分享推广品牌的几大方法 如何推广品牌？
- 给大家推荐13个既实用又好用的营销工具 新媒体营销分析工具有哪些？
- 推广创意的4大技巧 什么是推广创意？
- 写营销推广文案的2大内容 怎样写营销推广文案？
- 如何做饼干(饼干的做法烤箱新手做)
- DNF手游攻略大全让您技能天下无双
- 给宝宝适宜的环境刺激，促进大脑发育？
- 宝宝多大要戒除奶瓶？
- 分享整合营销的4大好处 整合营销的好处有哪些？