共计 8214 个字符，预计需要花费 21 分钟才能阅读完成。
简介： 近几年里，大数据行业发展势头迅猛，故而相应的分布式产品和架构层出不穷，本文分享作者在大数据系统实际过程中接触过的一些工具及应用感触，抛砖引玉，和同学们一起构建一个分布式产品的全景图。
下图是由驰名的数据观察家 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
