编者按：近些年里，大统计数据行业增长势头十分迅速，故相应的分布式系统商品和构架不断涌现，责任编辑撷取作者在大统计数据分析实践过程中碰触过的许多辅助工具及采用体会，Jaunpur，和全校师生一起构筑两个分布式系统商品的微缩。
右图是由著名的统计数据分析家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)组成，统计CSV会分为数个Block，那些Block按照相同PS3，相同机壳的策略以预设一备三的情况分布储存在各个结点。现在每个Block大小预设是128MB，以后随着硬盘串行速度的减少，那个Block也会不断增大。而NN里头则储存了那些Block元统计数据的信息，这样应用程序进行统计数据查阅的这时候，DN知会所需统计数据的位置。从这种结构上要看出许多比较明显的难题就是NN结点的sizes难题，因此在Hadoop 2.x的这时候，针对NN做了许多改进。
首先是在系统易用性上，减少了两个StandBy状况的NN，作为服务项目中NN（Active NN）的U802，当服务项目中的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拥有自己的统计CSV格式。
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/
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是统计数据治理体系中比较重要的两个商品，它主要负责元统计数据的管理，那个元统计数据就是指用来叙述统计数据的统计数据，比如统计数据的类型、名称、属性、作用、生命周期、有效范围、血缘关系等等，在大统计数据分析中，元统计数据有着非常大的价值，两个比较成熟的统计数据分析中一般单厢存在着这么两个元统计数据管理平台，元统计数据除了能让业务人员更加方便快捷理解我们的统计数据和业务，也有着帮助我们提升统计数据质量，消除信息不对称，和快速定位统计数据难题等作用，因此怎样有效的利用好那些元统计数据，使那些统计数据产生更大的价值，也是许多人一化，并更新自身统计数据。
Apache Kylin
Kylin是两个为OLAP场景量身定制的分布式系统统计数据仓库商品，提供多维分析的功能，并能和许多BI分析工具无缝对接，比如Tableau、Superset等。Kylin提供了前端平台，采用者能在该平台上去定义自己的统计数据维度，Kylin会定时完整分析所需统计数据的预计算，形成数个Cube，并将之保存在HBase中，因此部署Kylin的这时候需要HBase环境的支持。在统计数据与计算的这时候，对其所在设备的资源消耗也比较大。
Apache Hive & Tez
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
和介绍的其它软件相同，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
温馨提示：
由阿里巴巴高德地图发起，阿里云天池平台作为支撑平台的AMAP-TECH算法大赛初赛已经开启，赛题为基于车载视频图像的动态路况分析，权威评委、丰厚奖金、终面通道、荣誉证书，热烈欢迎我们参与，一起用技术帮助更多人美好出行!
初赛（7月8日-8月31日，UTC+8）。赛题详情及参赛链接：
https://tianchi.aliyun.com/competition/entrance/531809/introduction
