简介： 近几年里，大数据行业发展势头迅猛，故而相应的分布式产品和架构层出不穷，本文分享作者在大数据系统实际过程中接触过的一些工具及应用感触，抛砖引玉，和同学们一起构建一个分布式产品的全景图。
下图是由驰名的数据观察家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能够并行运行。
Spark不只是在批处理上有所问题，而是更加重视整个生态圈的建设，其领有流式解决框架SparkStreaming，采纳微批的模式达到相似流解决的成果，当初又推出了Structured Streaming，实现基于状态的流解决框架。此外还领有SparkSQL来帮忙非开发人员更加便捷的调用Spark的服务和Spark MLlib这个机器学习库。
Spark虽好，但其对内存资源耗费也很大，同时也使得他在稳定性上不如MapReduce，所以有些大公司数仓的日常工作仍旧采纳传统MapReduce的形式执行，不求最快，但求最稳。咱们的零碎在刚从MapReduce上切到Spark时，每天夜里也是工作异样频发，最初调整了工作和资源分配，再加上一个很粗犷的重试机制解决了。
Apache Flink
官网：https://flink.apache.org/
Flink是德国Data Artisans公司开发一款分布式计算零碎，该公司于19年初被阿里巴巴团体收买。包含Spark和Kafka，也都看到了将来流式计算的前景是十分微小的，纷纷建设属于本人的流式计算生态圈。
Flink和Spark Streaming相比，前者是真正的流式计算，而后者是微批处理，尽管批次足够小，但其本质毕竟还是批处理，这就导致有些场景SparkStreaming注定无奈满足，尽管Spark当初将重心转移到了Structured Streaming，它补救了Spark Streaming很多的有余，然而在解决流程上依然是微批处理。
而Flink在设计之初就同时思考了批处理和流解决这两种需要，所以使用者也能够只通过一个计算引擎，就能实现批处理和流解决两种计算场景，其次要几个须要分明的个性我感觉别离是：State状态治理，CheckPoint容错机制，Window滑动窗口，和Watermark乱序解决。这些内容网上都有很多介绍，不再论述。
Apache Impala
官网：https://impala.apache.org/
Impala是Cloudera公司用C++开发的反对SQL语义的查问零碎，能够用来查问HDFS、HBase、Kudu的内容，也反对多种序列化和压缩格局，因为也是基于内存的计算，比传统MapReduce快很多。不过因为曾经应用了Spark，所以组里并没有对Impala进行大规模的利用。通过一些零散的调研和理解，如同其它公司对Impala的利用也不是十分多。
Apache Zookeeper
官网：https://zookeeper.apache.org/
Zookeeper无论在数据系统还是在其它后端系统的应用场景都十分广，它能够用作分布式锁服务，能够用做零碎的配置核心，能够帮助实现一致性算法的选主过程，能够用于ZKFC做节点衰弱状况的探查，总之用途还有很多。而它的工作机制，根本就是ZAB协定的机制，一个反对解体复原的原子播送协定，其次要组成也是由一个Leader和多个Follower组成的，数据的提交遵循2PC协定。当Leader解体时，Follower会主动切换状态开始从新选主，从新选完之后再进行多节点的数据对齐。
Apache Sqoop
官网：https://sqoop.apache.org/
一款用于在传统关系型数据库和HDFS之间相互进行数据传递的工具，无论是import还是export都提供了大量的参数，因为是分布式执行，数据传输的速度也十分快。只是在应用的过程中须要留神数据源中的异样数据，会比拟容易造成数据传递过程中的异样退出。为了补救Sqoop的性能繁多，推出了Sqoop 2，架构上比Sqoop 1简单了很多，不过我没有用过。
Apache Flume
官网：http://flume.apache.org/
分布式数据传输工具，反对蕴含文件、Netcat、JMS、HTTP在内的多种数据源。其构造上分成Source、Channel、Sink三局部，Source将获取到的数据缓存在Channel中，这个Channel能够是文件，能够是内存，也能够应用JDBC，Sink从Channel生产数据，传递给零碎中的其余模块，比方HBase、HDFS、Kafka等等。
Apache Kafka
官网：http://kafka.apache.org/
已经是一款由Scala开发的分布式音讯队列产品，当初生态曾经扩大了，因为它推出了Kafka Streaming，所以当初也应该被称作是一个流解决平台了，但这里不说Kafka Streaming，因为没有用过和理解过。
Kafka的队列依照Topic划分，每个Topic下由多个Partition组成，在单个Partition中的音讯保障是有序的。这种构造下确保了音讯是在磁盘程序写入的，节俭了磁盘寻址的工夫，所以数据落盘的速度十分快。加之采纳了mmap的形式，缩小了用户态和内核态之间的数据拷贝次数，mmap是一种将文件内容和内存地址映射的技术，提效非常显著。Kafka和Flume的配合应用，造成了流式解决畛域里的经典框架。
Apache Ranger & Sentry
官网：http://ranger.apache.org/
官网：http://sentry.apache.org/
Ranger和Sentry都是分布式的数据安全工具，这两个产品的性能也根本是一样的，就是去治理大数据计算生态圈产品的权限，Sentry是采纳插件的模式，将本人集成到Impala、Hive、HDFS、Solr等产品上，当用户向这些产品发动申请，产品会先向Sentry Server进行校验，Sentry也能够和Kerberos配合应用，从而实现跨平台对立权限治理。而Ranger所提供的性能也相似，然而所反对的产品更加多样，包含HDFS、HBase、Hive、YARN、Storm、Solr、Kafka、Atlas等，其同样也是采纳一个Ranger Admin连贯多个集成到产品上的Ranger插件实现的权限验证过程。
Apache Atlas
官网：https://atlas.apache.org/
Apache Atlas是数据治理体系中比拟重要的一个产品，它次要负责元数据的治理，这个元数据就是指用来形容数据的数据，比方数据的类型、名称、属性、作用、生命周期、无效范畴、血缘关系等等，在大数据系统中，元数据有着十分大的价值，一个比拟成熟的数据系统中个别都会存在着这么一个元数据管理平台，元数据除了能让业务人员更加方便快捷了解咱们的数据和业务，也有着帮忙咱们晋升数据品质，打消信息不对称，以及疾速定位数据问题等作用，所以如何无效的利用好这些元数据，使这些数据产生更大的价值，也是很多人始终在思考的事件。当初Atlas反对的数据源有Hive、Sqoop、Storm，其导入形式有HOOK和Batch两种形式，首次应用是Batch的同步形式，之后Atlas会利用HOOK被动获取到数据源的变动，并更新本身数据。
Apache Kylin
官网：http://kylin.apache.org/
Kylin是一个为OLAP场景量身定制的分布式数据仓库产品，提供多维分析的性能，并能够和很多BI剖析工具无缝对接，比方Tableau、Superset等。Kylin提供了前端平台，使用者能够在该平台下来定义本人的数据维度，Kylin会定时残缺剖析所需数据的预计算，造成多个Cube，并将之保留在HBase中，所以部署Kylin的时候须要HBase环境的反对。在数据与计算的时候，对其所在设施的资源耗费也比拟大。
Apache Hive & Tez
官网：https://hive.apache.org/
官网：https://tez.apache.org/
Hive应该是最有名气的数据仓库工具了吧，他将HDFS上的数据组织成关系型数据库的模式，并提供了HiveSQL进行结构化查问，使得数据分析人员能够从传统的关系型数据库简直无缝的过渡到HDFS上，但其个别函数和传统SQL还是有区别的，并且默认也不反对update和delete操作。但开发人员能够开发UDF，为HiveSQL裁减属于本人的性能函数。Hive自身的计算是基于MapReduce的，起初为了应答SparkSQL的呈现，开发组推出了Hive on Spark，使得SQL的解释、剖析、优化还是在Hive上，而执行阶段交由Spark去实现，从而以达到和SparkSQL近似的速度。
Tez是对Hive的另一项优化，为其引入了DAG的概念，减少工作并行度从而晋升Hive的查问速度，但其本质仍旧是MapReduce，所以晋升成果相比Hive on Spark来讲并不足够显著。
Apache Presto
官网：https://prestodb.io/
Presto是由facebook公司开发的一款分布式查问引擎，其次要特点是反对了十分多的Connector，从而实现在一个平台上连贯多个数据源，并且能够将这些数据源的内容进行聚合计算，同时Presto也反对使用者自行开发新的Connector。并且Presto的计算过程全程是基于内存的，所以速度也是十分的快，但其实Presto也只是针对个别计算场景的性能优化会非常明显，网上有十分具体的剖析文章。之前应用该工具是为了将离线数仓和实时数仓的数据进行联结查问，提供给实时数据平台应用。
在应用过程中我感觉有点不好的中央有三点。一是因为Presto基于内存计算，所以在资源缓和的状况下常常Crash导致工作失败。二是Presto工作为串行提交，所以会呈现大工作阻塞小工作的状况呈现。或者通过调参能够解决该问题吧，但没有再深刻调研了。三是没有找到一个比拟好的Web平台去查问Presto，网上有Hue通过PostgreSQL去链接Presto的计划，感觉有点麻烦，看上去比拟成熟的Airpal平台也已不再更新了。最初应用了yanagishima，基本功能能够满足，但该平台没有用户治理性能，没法管制权限。
Apache Parquet & Orc
官网：https://parquet.apache.org/
官网：https://orc.apache.org/
Parquet和ORC是两种比拟利用比拟多的列式存储格局，列式存储不同于传统关系型数据库中行式存储的模式，这种次要的差异可能因为联机事务处理（OLTP）和联机剖析解决（OLAP）的需要场景不同所造成的。在OLTP场景多是须要存储系统能满足疾速的CRUD，这种操作对象都是以行为单位的。而在OLAP场景下，次要的特色是数据量微小，而对实时性的要求并不高。而列式存储正式满足了这一需要特色。因为当数据以列的形式存储，在查问的时候引擎所读取的数据量将会更小，而且同一列的数据往往内容相似，更加便于进行数据压缩，但列式存储不适于更新和删除频繁的场景。Parquet和Orc同为列式存储，但他们的存储格局并不相同，这种差别造成了两者在存储不同类型的数据时所呈现的性能差别，从网上的一些文章看，Orc的性能要比Parquet好一点，然而Impala是不反对Orc的，并且诸如Delta Lake这种数据湖产品，也是基于Parquet去做的。所以在抉择采纳哪种列式存储格局时，还是要依据本身的业务特点来决定。
Apache Griffin
官网：http://griffin.apache.org/
数据品质治理是数据系统中不可或缺的一环，初期的时候咱们往往在ETL的各个阶段，退出一些简略的脚本来对生成的数据进行查看，而Apache Griffin也是一款这样的产品，它是由eBay开发的一个数据品质监控平台，后回升为Apache顶级我的项目。它提供了数据校验和报警的性能，也反对一些参数的可视化展示，相干的配置步骤都能够在Griffin的页面上实现。除了能实现一些最根本最简略的诸如是否存在异样值的数据查看，也能实现一些诸如最值、中值的数据统计需要等等，并且提供了业余的图表报告。
Apache Zeppelin
官网：http://zeppelin.apache.org/
Zeppelin是一款十分不便的在线笔记本，应用体验有点像Python的Jupyter NoteBook，能够从图中看到使用者能够在线执行，并绘制简略的图表。并且Zeppelin有了用户的概念，使得多人协同工作更加不便。Zeppelin反对了十分多的数据源，通过该平台，能够调用Hive、Cassandra、R、Kylin、Flink、Spark、ElasticSearch、HBase、Python、Shell等等。
我在应用时呈现了Spark连贯不稳的状况，须要使用者重复登录才能够。但总之我还是十分喜爱这款工具的。
Apache Superset
官网：http://superset.apache.org/
Superset是一款开源的可视化工具，应用该工具能够不便疾速的创立数据Dashboard，同类型的产品还有Redash、Metabase，但调研过后集体还是更喜爱Superset一些。不过因为同期引入了Tableau，Superset并没有在理论我的项目中应用。
Tableau
官网：https://www.tableau.com/
和介绍的其它软件不同，Tableau是一款商用软件，依据购买的账号数量按年付费，之所以这里提到它，也是因为Tableau在BI畛域内的名气着实有点高。Tableau分为Server端和本地客户端，使用者通过在客户端上的拖拽，即可疾速生成一个数据Dashboard，使得Dashboard的开发工作从开发侧下放到了需求方。并且Tableau也提供了齐备的用户治理性能，还反对了十分多的数据源。商业软件和开源软件比起来，无论性能齐备性上还是应用体验上，确实都有显著的晋升。我感觉惟一的难度可能就是如何把这个开发保护的工作在需求方落地吧，毕竟它还是有一些学习老本的。
TPCx-BB
官网：http://www.tpc.org/
TPC全称是事务处理性能委员会，是由数十家公司组成的非盈利性组织，负责订制各个行业的基准测试标准，阿里巴巴的MaxCompute和OceanBase都加入过该项测试，并获得了十分好的问题。TPCx-BB是一个大数据基准测试工具，该工具模仿了一个网上批发的场景，首先工具会先向被测系统中插入预约好的表和数据，而后通过一系列的SQL操作，来对大数据集群的性能进行评估。TPC针对不同的被测场景，提供了很多现成的工具，能够供大家下载应用：
http://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp