大数据四大阵营之OLAP阵营

OLAP阵营主要有两大主流方向：

一个是基于MapReduce而构建的Hadoop生态圈
一个是MPP（大规模并行）数据库阵营
不过MPP数据库通常兼具OLAP与OLTP的能力，所以老孙仍旧把MPP数据库与OLAP类型大数据系统并列在OLAP阵营。

Hadoop的整体架构其实非常简单，用公式表达就是：

Hadoop=HDFS+MapReduce

其中，

HDFS 负责分布式存储
MapReduce 负责分布式计算

HDFS分布式文件系统的设计核心理念（设计目标）有三条：

（1）可以扩展到数以千计的节点
（2）假设硬件、软件的故障、失败十分普遍
（3）一次写入，多次读写（写在HDFS中特指文件添加操作）

前两条比较容易理解，几乎所有的新型分布式系统都秉持类似的设计理念，特别适合于用商用硬件构建高度可扩展的高性能系统。例如，实现随节点数增加的线性或近线性系统性能提升。

第三条指的是Hadoop HDFS适用于CRAP（Create-Read-Append-Process）类型文件操作，相对于RDBMS时代的CRUD（Create-Read-Update-Delete）类型数据集操作而言，CRAP对已建立的数据集主要为读操作，以及在尾部添加操作，而不是CRUD类型的更新与删除操作，其主要原因是更新与删除操作在分布式系统中通常代价都比较昂贵。以HDFS为例，对文件的更新或删除操作意味着多个Block可能需要被更新及跨主机、机架同步，随着存储系统越来越便宜，在HDFS上的数据基本上不用专门去删除。

HDFS中的文件由一组块（Blocks）组成，每个Block被单独存储在本地磁盘上。块的放置策略是Hadoop的一大特点，如下图所示：
图：Hadoop块放置策略示意图（复制系数3）

HDFS的默认块放置（3份拷贝）策略如下：

**·写亲和（Close-to-Writing-Source）：**放置第一份拷贝于创建文件节点（以保证数据获取速度） ·最小跨机架开销（Minimal Inter-Rack Traffic）：第二份拷贝写在与第一份同机架上的另一HDFS节点上
**·可容忍网络交换机故障（Switch-Failure Tolerance）：**第三份拷贝写在与第一、二份拷贝不同的机架上（以确保单一机架故障不会导致系统整体下线）

HDFS的数据存储冗余设计充分考虑了数据访问速度（可用性）与安全性（灾备），在后来的分布式处理架构中被广泛地借鉴和采用。

HDFS采用C/S架构，逻辑也非常简洁，如下图所示，由NameNode与DataNode两类节点组成，NameNode扮演服务器角色，DataNode集群扮演客户端角色。

NameNode主要负责HDFS文件系统中文件与目录的相关属性信息（访问权限、创建与修改时间等），以及维护命名空间（Namespace）中的文件与DataNode上的映射关系（如文件块在HDFS集群中的分布信息）。为了避免单点故障，NameNode可以设有BackupNode或CheckPointer节点，来保证高可用性。同时，用户数据不会流经NameNode，而通过DataNode与客户端直接交互。在写操作中，NameNode会根据复制系数告诉客户端直接把块文件传送给指定的DataNodes上；而在读取操作中，NameNode会把块文件的位置信息返回给客户端，然后客户端直接从多个DataNode中读取。

HDFS支持动态的DataNode的横向扩展与再平衡（Scale-Out and Re-balancing），当NameNode检测到新的DataNode加入集群后，文件块会根据现有策略自动复制到新节点以实现负载的均衡分布。

Hadoop MapReduce是用于分析存储在HDFS之上的大数据的编程框架，它包括库与运行时（libs & run-time）。MapReduce的工作也是由两部分组成：

MapReduce=Map()+Reduce()

其中，Map()负责分而治之，Reduce()负责合并及减少基数。调用者只需要实现Map()与Reduce()的接口。

MapReduce的理念在大数据管理与分析中非常具有代表性，我们可以称之为：大数据的分而治之法则！简而言之就是把一个大的问题（或数据集）切分（Map!）为多个小的子问题，在所有子问题上进行同样的操作，然后把操作结果合并生成（Reduce!）总的结果。

关于Hadoop，我们再了解一下其架构及其生态系统（见下图）。除了HDFS与Map Reduce，Hadoop的核心架构还有另外两样东西：Hadoop Common与Hadoop YARN，前者提供底层通用库与工具组件，后者是集群（Cluster）资源管理器。
图：Hadoop生态系统：技术栈

Hadoop在v2当中对v1的体系架构进行了大刀阔斧的革新，除了增加了对文件写的支持，还包括把MRv1（MapReduce v1）中原有的JobTracker 与TaskTracker功能（分别对应HDFS中的NameNode & DataNode）改变为YARN的ResourceManager/ApplicationMaster与NodeManager。在容错性方面YARN与HDFS一样被设计成支持高容错。

Hadoop生态系统基本上都是围绕着这些核心组件而衍生出来的，如Hive与Pig，可以让程序员仍旧使用他们熟悉的SQL编程方式来完成MapReduce编程。类似的还有Impala、HAWQ等；HBase则是基于HDFS的宽表数据库；Spark则是基于内存的集群计算架构，很多人把它理解为是Hadoop移入内存的解决方案，这是不准确的，应该说Spark在集群管理与分布式存储系统方面提供了与Hadoop兼容的选项（如YARN与HDFS），但是其架构设计本身已经完全摆脱Hadoop的束缚。
图：Hadoop vs NoSQL

Hadoop与NoSQL所使用的业务场景，架构特性等的异同用一张图来直观说明（见上图）。Hadoop与NoSQL的侧重点各有不同，一般而言，NoSQL侧重交互性与低延迟（非严格意义上的实时）数据分析，而Hadoop侧重海量数据的批处理分析（意味着高延迟，确切的说，Hadoop系统从来都不是高性能的，因此有任何人如果宣称他的系统是高性能Hadoop系统，也许他对于高性能的认知是值得推敲的），它们两者都对原有关系型数据库的限制有了突破，但是对于强一致性交易处理（Atomicity、Consistency、Isolation、Durability，ACID），两者都很难做到。随着技术与业务需求的发展，特别是对实时在线交易处理（OnLine Transaction Processing，OLTP）的ACID需求与日俱增，学术界与工业界都开始关注如何实现NewSQL类型数据库。工业界已经在2019年开始逐步趋同认知：Hadoop已经接近消亡，2021年6月初的Cloudera被收购，宣示着Hadoop系统进入”老年阶段”，而各行各业对于Hadoop的大规模部署已经基本可以画上句号了。当然，对于NoSQL、流数据处理与NewSQL未来会在功能上出现不少的融合，特别是对于HTAP等的支持，是个可以预见的明确的未来方向。

作为本小节的总结，下表列出了RDBMS、NoSQL、NewSQL与Hadoop四大类数据处理平台的四维度（数据处理量、数据多样性、数据处理速度、ACID支持）比较矩阵。

·文/ 老孙（孙宇熙：云计算、大数据、高性能存储与计算系统架构专家 ）
·END·