浅谈Hadoop体系和MPP体系

浅谈Hadoop体系和MPP体系

---

引言

---

如题，在大数据发展至今，为了应对日益繁多的数据分析处理，和解决客户各种奇思妙（怪）想需求，形形色色的大数据处理的框架和对应的数据存储手段层出不穷。有老当益壮的Hadoop体系，依靠Hadoop巨大的社区生态支撑，加上各种开源（白嫖）组件的组合，其通用性，易用性，对于很多数据量不是很大，同时不那么追求极致性能的公司很友好。同时还有各种各样的MPP大规模并行计算框架，去应付巨量数据的分析处理。下面就简单的说一说笔者在工作中对于这两者的一些使用感受，给大家提供一些思路。

---

Hadoop体系

Hadoop体系的大致组成：

• 文件存储系统：
• 数据采集系统：
• 分析计算系统：
• 任务调度系统：

---

其大致关系如下：

文件存储系统

众所周知，Hadoop体系最初来源于谷歌的file system , MapReduce ， big table三篇论文，其底层最基本的就是分布式文件存储系统HDFS，该系统将海量数据根据大小切分为固定大小的文件块，存储在由大量廉价机器组成的物理集群上的DataNode，通过元数据管理NameNode来管理HDFS上数据的操作。具体的文件的存储和读取流程这里不再阐述，网上一堆解释。在HDFS分布式文件系统之上，早期的数据分析工作主要是编写偏向HDFS文件系统底层的代码，即MapReduce程序来解决数据处理。随着技术的不断成熟，以及数据量的增大，增加大数据分析的便利性，在HDFS文件系统之上，又构建了多种不同特性的数据管理的框架，如后来应用巨广的HIVE，HBase，以及更上层的kylin，impala等等。根本原因是为了降低使用者的入门门槛，以及快速解决使用者五花八门的应用场景。

数据采集系统

数据采集系统，主要是将数据从传统的数据库，队列，以及五花八门的存储，移动到Hadoop体系或者其他的数据处理框架的存储中。与之对应的产生的技术有早期的sqoop，kettle，进化版的sqoop2，flume，Logstash，以及后来程序员们自己开发的datax，flinkx等等，可能不同的解决方案自己还有属于自己的数据采集工具（例如：gp的gpkafka gpload ）。但是通用性较强的还是前面说的那些。

通用的数据采集工具其实都有一个共同的特点：通用（是不是废话。）。是什么造就了他们的通用性呢，是他们的架构。大多数使用较多的数据采集工具都具有可拔插的架构模式，基本上都是由三部分组成，负责数据源对接的读操作，工具本身负责承接数据的容器，以及负责向目标存储对接的写操作，中间在夹杂着简单的数据的过滤操作的自定义处理，可以让使用者不用了解其内部原理，只用通过配置一些简单的配置文件即可玩转数据采集的复杂操作。同时，在应对复杂的数据源的变化，以及目标存储的切换的场景，这些数据采集工具的切换代价都很小，只需要改变配置文件即可。

举几个实际的例子，大多数应用较多的应当属于flume，datax。

• flume 即为三段式架构，source，channel，sink。使用者通过配置不同的source即可从不同的数据源获取到数据，例如文本，数据库，socket，kafka，接口等等。获取到数据后可以根据使用者配置的channel的类别选择将数据放在内存（memory channel）或者磁盘（file channel）或者队列（kafka channel）或者数据库（jdbc channel ）中，提供给sink获取。同时sink又可以根据配置的不同，将数据下发到下游的目标存储中去。用户可以根据简单的配置，形成复杂的数据采集的采集网络，完成复杂的数据采集工作。同时，面对用户的自定义需求，flume还提供了用户自定义的接口，满足用户不同的需求。
• datax 同样也为三段式的，reader，framework，writer。每个部分解决的也是同flume类似的问题。同样对于使用者的二开程度也很自由。
• 以及在datax之上利用flink作为核心开发的流式的数据采集工具flinkx，也都是三段式的架构。
  数据采集工具的选型还是要根据自身的业务场景进行选择，在易用性，性能，问题解决等多种场景进行衡量，选择适合自己的才是最好的。

分析计算系统

计算框架很多，还是挑主要的简单说说。从MapReduce到storm到spark到flink，发展趋势是计算越来越偏向于流批一体化。在各种计算框架之上衍生而出的各种解决方案业发展的越来越好。

• MapReduce MapReduce应当数据大数据上的helloworld，是最先出现的大数据下的处理方案，其核心思想就是依托于HDFS,将数据存储在多台机器上，split成分片，map将这些分片在分片内进行map的逻辑处理，然后将处理结果，通过shuffle输出给reduce，形成reduce的输入，reduce在进行聚合操作，最终形成外部的最终输出结果。在MapReduce之上，为了简化操作，避免写大量重复的代码，让使用者只关心于数据分析的业务逻辑，hive应运而生。他在MapReduce之上封装了一层sql执行的客户端，让使用者在进行MapReduce编程的时候，只需要使用sql的方式，通过hive的客户端编写业务sql,hive客户端会将用户的sql解析为对应的MapReduce任务，交给hdfs执行，最终将结果返回给hive客户端。hive的出现简化了MapReduce的编程的难度，使得大数据的分析更加易用。
• spark spark同mr最大的区别，一是统一了编程模型，二是spark在计算时，中间结果可以选择性的不用落磁盘，减少磁盘io，大大提高分析速度。同时spark也提供了sql的操作sparksql，简化编程。同时，随着技术的发展，像hive on spark，这样的方式，把原来的hive利用MapReduce引擎计算慢替换为spark做计算，提升了hive的计算速度。还有hive on tez。
• 说完了离线的计算方式，实时流的大数据处理方案又有哪些呢？早年的storm，发展较好的sparkstreaming，以及目前发展势头越来越好的flink。storm这里就不多做阐述，用的人确实少，（有幸重构过一次storm的代码，还是有点酸爽）。其实从易用性上考虑，sparkstreaming还是最优秀的，但是实时性上考虑，毕竟sparkstreaming还是微批处理，以及数据处理的性能上来说，flink还是更优秀的，只不过flink由于是最近几年才火起来，他的通用性以及社区没有sparkstreaming完善，（flink sql还是blink贡献的）。但是以后的发展趋势还是flink会越来越好（希望两者在相互抄袭的路上越来越优秀）。

任务调度系统

任务调度系统主要是在计算任务数量级以及数仓建立起来后，日常的数据处理可能会依赖于不同的处理逻辑，形成业务上的流程。此时，如果不使用调度管理工具去做管理的话，是一件很容易让人崩溃的事情。早些年自己写shell去做调度，现在各种很香的调度工具。有句话说的好，工具选的好，下班回得早。笔者使用过的调度工具，airflow，azikaban，easyscheduler（现在改名叫海豚调度）。还是强烈建议用小海豚。因为海豚调度是国人开源的Apache项目（自己的孩子，自己要支持），更符合国人使用习惯，同时社区沟通也更加流畅和友好。

MPP体系

到MPP了，mpp主要不同于Hadoop体系的是，mpp架构，会充分利用每台机器的物理资源，包括存储，cpu，内存。利用每台机器的资源，并行计算，最终将结果返回。每台机器的资源是独立的，无共享。而Hadoop体系则是将多台机器的资源共享起来，例如磁盘，cpu，内存。另外，最近几年的mpp架构在存储上基本采用的都是列存（或者列存是一个可选项），列存在巨量数据上具有更好的压缩性能，同时在olap中，通常只用关心某几列的分析中，会具有更好的性能表现。以及在计算上，mpp架构会选择向量化的计算引擎，利用cpu的simd指令集加速整个计算的速度，使得速度更快。

• 常见的mpp的处理的方案也有很多，早期的greenplum，就是利用postgre，组成的mpp的方案，但是greenplum不算是一个纯正的olap血统的mpp解决方案，一是olap性能不出众，二是他还支持OLTP的功能，啥都有，好处是，高并发支持比较好。以及依托于hdfs的impala，俄罗斯的彪悍的clickhouse，百度的Polo（改名为Doris），tidb（魔改mysql的mpp），华为的高斯（魔改postgre的mpp）and so on 。
• 笔者用过的mpp相关的，clickhouse，greenplum，Doris（测试阶段），相对来说，比较稳定的就是greenplum，他在大量数据的处理下，使用者合理的分区，合理的索引，合理的分布键，以及合理的sql下，计算能力还是很不错的，但是mpp的通病就是木桶效应，性能取决于集群中分析最慢的那一台机器，因此，数据分布倾斜，以及GP分析任务重的数据重分布是尽量要避免的，否则，就无法发挥gp的长处。另外，aoc（append only column ）表对于性能的提升也是巨大的，核心思想还是相较于传统的heap表，aoc利用了列存，数据压缩上效率更好，减少了数据扫描的IO，在巨量（数十亿级）数据下的分析性能提升明显。
• clickhouse ，俄罗斯人开发的，有点显而易见，就是快，缺点也显而易见，依赖于zk，维护起来也不是很好。另外相较于强大的单表分析的性能，他的join，以及他的并发，着实不好。所以clickhouse一般的应用场景基本都是形成大宽表面对业务分析人员，将他的性能优点发挥出来。避免join，避免高并发查。另外要时刻关注zk。
• Doris，由目前原来百度的polo进化而来，有开源版本的Apache Doris，还有商业版本的Doris。实际还没有上手。

结语

真的只是上班摸鱼时期的浅谈，简单说了一下大概的简介，后边有时间的话，结合具体场景在浅谈记录一下