zookeeper与hadoop,zookeeper与hadoop的关系 收藏 0

10分钟零基础就可搞懂的Hadoop架构原理，阿里架构师详解

我今天花了大半个下午的时间，写了这篇hadoop的架构，全篇都是以大白话的形式，也算是为后面更加详细的每一部分开了个好头吧，如果喜欢请点转发和关注，如果有疑问，直接在评论里说出来，大家一起解决，才能进步。

一、概念

Hadoop诞生于2006年，是一款支持数据密集型分布式应用并以Apache 2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据Google公司发表的MapReduce和Google档案系统的论文自行实作而成。

Hadoop与Google一样，都是小孩命名的，是一个虚构的名字，没有特别的含义。从计算机专业的角度看，Hadoop是一个分布式系统基础架构，由Apache基金会开发。Hadoop的主要目标是对分布式环境下的“大数据”以一种可靠、高效、可伸缩的方式处理。

Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式：应用程序被分割成许多小部分，而每个部分都能在集群中的任意节点上执行或重新执行。

Hadoop还提供了分布式文件系统，用以存储所有计算节点的数据，这为整个集群带来了非常高的带宽。MapReduce和分布式文件系统的设计，使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的电脑和PB级的数据。

二、组成

1.Hadoop的核心组件

分析：Hadoop的核心组件分为：HDFS（分布式文件系统）、MapRuduce（分布式运算编程框架）、YARN（运算资源调度系统）

2.HDFS的文件系统

HDFS

1.定义

整个Hadoop的体系结构主要是通过HDFS（Hadoop分布式文件系统）来实现对分布式存储的底层支持，并通过MR来实现对分布式并行任务处理的程序支持。

HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。

2.组成

HDFS采用主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。NameNode作为主服务器，管理文件系统命名空间和客户端对文件的访问操作。DataNode管理存储的数据。HDFS支持文件形式的数据。

从内部来看，文件被分成若干个数据块，这若干个数据块存放在一组DataNode上。NameNode执行文件系统的命名空间，如打开、关闭、重命名文件或目录等，也负责数据块到具体DataNode的映射。DataNode负责处理文件系统客户端的文件读写，并在NameNode的统一调度下进行数据库的创建、删除和复制工作。NameNode是所有HDFS元数据的管理者，用户数据永远不会经过NameNode。

分析：NameNode是管理者，DataNode是文件存储者、Client是需要获取分布式文件系统的应用程序。

MapReduce

1.定义

Hadoop MapReduce是google MapReduce 克隆版。

MapReduce是一种计算模型，用以进行大数据量的计算。其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce这样的功能划分，非常适合在大量计算机组成的分布式并行环境里进行数据处理。

2.组成

分析：

（1）JobTracker

JobTracker叫作业跟踪器，运行到主节点（Namenode）上的一个很重要的进程，是MapReduce体系的调度器。用于处理作业（用户提交的代码）的后台程序，决定有哪些文件参与作业的处理，然后把作业切割成为一个个的小task，并把它们分配到所需要的数据所在的子节点。

Hadoop的原则就是就近运行，数据和程序要在同一个物理节点里，数据在哪里，程序就跑去哪里运行。这个工作是JobTracker做的，监控task，还会重启失败的task（于不同的节点），每个集群只有唯一一个JobTracker，类似单点的NameNode，位于Master节点

（2）TaskTracker

TaskTracker叫任务跟踪器，MapReduce体系的最后一个后台进程，位于每个slave节点上，与datanode结合（代码与数据一起的原则），管理各自节点上的task（由jobtracker分配），

每个节点只有一个tasktracker，但一个tasktracker可以启动多个JVM，运行Map Task和Reduce Task；并与JobTracker交互，汇报任务状态，

Map Task：解析每条数据记录，传递给用户编写的map(),并执行，将输出结果写入本地磁盘(如果为map-only作业，直接写入HDFS)。

Reducer Task：从Map Task的执行结果中，远程读取输入数据，对数据进行排序，将数据按照分组传递给用户编写的reduce函数执行。

Hive

1.定义

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。

Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

2.组成

分析：Hive架构包括：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、WEB GUI、Metastore和Driver(Complier、Optimizer和Executor)，这些组件分为两大类：服务端组件和客户端组件

3.客户端与服务端组件

（1）客户端组件：

CLI：Command Line Interface，命令行接口。

Thrift客户端：上面的架构图里没有写上Thrift客户端，但是Hive架构的许多客户端接口是建立在Thrift客户端之上，包括JDBC和ODBC接口。

WEBGUI：Hive客户端提供了一种通过网页的方式访问Hive所提供的服务。这个接口对应Hive的HWI组件（Hive Web Interface），使用前要启动HWI服务。

（2）服务端组件：

Driver组件：该组件包括Complier、Optimizer和Executor，它的作用是将HiveQL（类SQL）语句进行解析、编译优化，生成执行计划，然后调用底层的MapReduce计算框架

Metastore组件：元数据服务组件，这个组件存储Hive的元数据，Hive的元数据存储在关系数据库里，Hive支持的关系数据库有Derby和Mysql。元数据对于Hive十分重要，因此Hive支持把Metastore服务独立出来，安装到远程的服务器集群里，从而解耦Hive服务和Metastore服务，保证Hive运行的健壮性；

Thrift服务：Thrift是Facebook开发的一个软件框架，它用来进行可扩展且跨语言的服务的开发，Hive集成了该服务，能让不同的编程语言调用Hive的接口。

4.Hive与传统数据库的异同

（1）查询语言

由于 SQL 被广泛的应用在数据仓库中，因此专门针对Hive的特性设计了类SQL的查询语言HQL。熟悉SQL开发的开发者可以很方便的使用Hive进行开发。

（2）数据存储位置

Hive是建立在Hadoop之上的，所有Hive的数据都是存储在HDFS中的。而数据库则可以将数据保存在块设备或者本地文件系统中。

（3）数据格式

Hive中没有定义专门的数据格式，数据格式可以由用户指定，用户定义数据格式需要指定三个属性：列分隔符（通常为空格、”\\t”、”\\x001″）、行分隔符（”\\n”）以及读取文件数据的方法（Hive中默认有三个文件格式TextFile，SequenceFile以及RCFile）。

（4）数据更新

由于Hive是针对数据仓库应用设计的，而数据仓库的内容是读多写少的。因此，Hive中不支持

对数据的改写和添加，所有的数据都是在加载的时候中确定好的。而数据库中的数据通常是需要经常进行修改的，因此可以使用INSERT INTO … VALUES添加数据，使用UPDATE … SET修改数据。

（5）索引

Hive在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些Key建立索引。Hive要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于MapReduce的引入， Hive可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive仍然可以体现出优势。数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。由于数据的访问延迟较高，决定了Hive不适合在线数据查询。

（6）执行

Hive中大多数查询的执行是通过Hadoop提供的MapReduce来实现的（类似select * from tbl的查询不需要MapReduce）。而数据库通常有自己的执行引擎。

（7）执行延迟

Hive在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致Hive执行延迟高的因素是MapReduce框架。由于MapReduce本身具有较高的延迟，因此在利用MapReduce执行Hive查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。

（8）可扩展性

由于Hive是建立在Hadoop之上的，因此Hive的可扩展性是和Hadoop的可扩展性是一致的（世界上最大的Hadoop集群在Yahoo!，2009年的规模在4000台节点左右）。而数据库由于ACID语义的严格限制，扩展行非常有限。目前最先进的并行数据库Oracle在理论上的扩展能力也只有100台左右。

（9）数据规模

由于Hive建立在集群上并可以利用MapReduce进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

Hbase

1.定义

HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；

Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；

Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为协同服务。

2.组成

分析：从上图可以看出：Hbase主要由Client、Zookeeper、HMaster和HRegionServer组成，由Hstore作存储系统。

• Client

HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与 HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC

• Zookeeper

Zookeeper Quorum 中除了存储了 -ROOT- 表的地址和 HMaster 的地址，HRegionServer 也会把自己以 Ephemeral 方式注册到 Zookeeper 中，使得 HMaster 可以随时感知到各个HRegionServer 的健康状态。

• HMaster

HMaster 没有单点问题，HBase 中可以启动多个 HMaster ，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行，HMaster 在功能上主要负责 Table和Region的管理工作：

• 管理用户对 Table 的增、删、改、查操作
• 管理 HRegionServer 的负载均衡，调整 Region 分布
• 在 Region Split 后，负责新 Region 的分配
• 在 HRegionServer 停机后，负责失效 HRegionServer 上的 Regions 迁移

HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。

MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）， 当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个 StoreFiles 合并成一个 StoreFile，合并过程中会进行版本合并和数据删除。

因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的 compact 过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了 HBase I/O 的高性能。

当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个 StoreFile 大小超过一定阈值后，会触发Split操作，同时把当前 Region Split成2个Region，父 Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer 上，使得原先1个Region的压力得以分流到2个Region上。

三、Hadoop的应用实例

1.回顾Hadoop的整体架构

2.Hadoop的应用——流量查询系统

（1）流量查询系统总体框架

（2）流量查询系统总体流程

（3）流量查询系统数据预处理功能框架

（4）流量查询系统数据预处理流程

（5）流量查询NoSQL数据库功能框架

（6）流量查询服务功能框架

（7）实时流计算数据处理流程图

本人才疏学浅，若有错，请指出，谢谢！ 如果你有更好的建议，可以留言我们一起讨论，共同进步！ 衷心的感谢您能耐心的读完本文！

深度解读：Kafka 放弃 ZooKeeper，消息系统兴起二次革命

作者 | Tina

采访嘉宾 | 韩欣、王国璋

“我对该版本感到非常兴奋，但我们的业务特性决定了我们不能停机升级…”

3 月 30 日，Kafka 背后的企业 Confluent 发布博客表示，在即将发布的 2.8 版本里，用户可在完全不需要 ZooKeeper 的情况下运行 Kafka，该版本将依赖于 ZooKeeper 的控制器改造成了基于 Kafka Raft 的 Quorm 控制器。

在之前的版本中，如果没有 ZooKeeper，Kafka 将无法运行。但管理部署两个不同的系统不仅让运维复杂度翻倍，还让 Kafka 变得沉重，进而限制了 Kafka 在轻量环境下的应用，同时 ZooKeeper 的分区特性也限制了 Kafka 的承载能力。

从 2019 年起，Confluent 就开始策划更换掉 ZooKeeper。这是一项相当大的工程，经过九个多月的开发，KIP-500 代码的早期访问已经提交到 trunk 中。

第一次，用户可以在没有 ZooKeeper 的情况下运行 Kafka。

这是一次架构上的重大升级，让一向“重量级”的 Kafka 从此变得简单了起来。轻量级的单进程部署可以作为 ActiveMQ 或 RabbitMQ 等的替代方案，同时也适合于边缘场景和使用轻量级硬件的场景。

ZooKeeper 是 Hadoop 的一个子项目，一般用来管理较大规模、结构复杂的服务器集群，具有自己的配置文件语法、管理工具和部署模式。Kafka 最初由 LinkedIn 开发，随后于 2011 年初开源，2014 年由主创人员组建企业 Confluent。

Broker 是 Kafka 集群的骨干，负责从生产者（producer）到消费者（consumer）的接收、存储和发送消息。在当前架构下，Kafka 进程在启动的时候需要往 ZooKeeper 集群中注册一些信息，比如 BrokerId，并组建集群。ZooKeeper 为 Kafka 提供了可靠的元数据存储，比如 Topic/分区的元数据、Broker 数据、ACL 信息等等。

同时 ZooKeeper 充当 Kafka 的领导者，以更新集群中的拓扑更改；根据 ZooKeeper 提供的通知，生产者和消费者发现整个 Kafka 集群中是否存在任何新 Broker 或 Broker 失败。大多数的运维操作，比如说扩容、分区迁移等等，都需要和 ZooKeeper 交互。

也就是说，Kafka 代码库中有很大一部分是负责实现在集群中多个 Broker 之间分配分区（即日志）、分配领导权、处理故障等分布式系统的功能。而早已经过业界广泛使用和验证过的 ZooKeeper 是分布式代码工作的关键部分。

假设没有 ZooKeeper 的话，Kafka 甚至无法启动进程。腾讯云中间件-微服务产品中心技术总监韩欣对 InfoQ 说，“在以前的版本中，ZooKeeper 可以说是 Kafka 集群的灵魂。”

但严重依赖 ZooKeeper，也给 Kafka 带来了掣肘。Kafka 一路发展过来，绕不开的两个话题就是集群运维的复杂度以及单集群可承载的分区规模，韩欣表示，比如腾讯云 Kafka 维护了上万节点的 Kafka 集群，主要遇到的问题也还是这两个。

首先从集群运维的角度来看，Kafka 本身就是一个分布式系统。但它又依赖另一个开源的分布式系统，而这个系统又是 Kafka 系统本身的核心。这就要求集群的研发和维护人员需要同时了解这两个开源系统，需要对其运行原理以及日常的运维（比如参数配置、扩缩容、监控告警等）都有足够的了解和运营经验。否则在集群出现问题的时候无法恢复，是不可接受的。所以，ZooKeeper 的存在增加了运维的成本。

其次从集群规模的角度来看，限制 Kafka 集群规模的一个核心指标就是集群可承载的分区数。集群的分区数对集群的影响主要有两点：ZooKeeper 上存储的元数据量和控制器变动效率。

Kafka 集群依赖于一个单一的 Controller 节点来处理绝大多数的 ZooKeeper 读写和运维操作，并在本地缓存所有 ZooKeeper 上的元数据。分区数增加，ZooKeeper 上需要存储的元数据就会增加，从而加大 ZooKeeper 的负载，给 ZooKeeper 集群带来压力，可能导致 Watch 的延时或丢失。

当 Controller 节点出现变动时，需要进行 Leader 切换、Controller 节点重新选举等行为，分区数越多需要进行越多的 ZooKeeper 操作：比如当一个 Kafka 节点关闭的时候，Controller 需要通过写 ZooKeeper 将这个节点的所有 Leader 分区迁移到其他节点；新的 Controller 节点启动时，首先需要将所有 ZooKeeper 上的元数据读进本地缓存，分区越多，数据量越多，故障恢复耗时也就越长。

Kafka 单集群可承载的分区数量对于一些业务来说，又特别重要。韩欣举例补充道，“腾讯云 Kafka 主要为公有云用户以及公司内部业务提供服务。我们遇到了很多需要支持百万分区的用户，比如腾讯云 Serverless、腾讯云的 CLS 日志服务、云上的一些客户等，他们面临的场景是一个客户需要一个 topic 来进行业务逻辑处理，当用户量达到百万千万量级的情况下，topic 带来的膨胀是非常恐怖的。在当前架构下，Kafka 单集群无法稳定承载百万分区稳定运行。这也是我对新的 KIP-500 版本感到非常兴奋的原因。”

为了改善 Kafka，去年起 Confluent 就开始重写 ZooKeeper 功能，将这部分代码集成到了 Kafka 内部。他们将新版本称为“ Kafka on Kafka”，意思是将元数据存储在 Kafka 本身，而不是存储 ZooKeeper 这样的外部系统中。Quorum 控制器使用新的 KRaft 协议来确保元数据在仲裁中被精确地复制。这个协议在很多方面与 ZooKeeper 的 ZAB 协议和 Raft 相似。这意味着，仲裁控制器在成为活动状态之前不需要从 ZooKeeper 加载状态。当领导权发生变化时，新的活动控制器已经在内存中拥有所有提交的元数据记录。

去除 ZooKeeper 后，Kafka 集群的运维复杂性直接减半。

在架构改进之前，一个最小的分布式 Kafka 集群也需要六个异构的节点：三个 ZooKeeper 节点，三个 Kafka 节点。而一个最简单的 Quickstart 演示也需要先启动一个 ZooKeeper 进程，然后再启动一个 Kafka 进程。在新的 KIP-500 版本中，一个分布式 Kafka 集群只需要三个节点，而 Quickstart 演示只需要一个 Kafka 进程就可以。

改进后同时提高了集群的延展性（scalability），大大增加了 Kafka 单集群可承载的分区数量。

在此之前，元数据管理一直是集群范围限制的主要瓶颈。特别是在集群规模比较大的时候，如果出现 Controller 节点失败涉及到的选举、Leader 分区迁移，以及将所有 ZooKeeper 的元数据读进本地缓存的操作，所有这些操作都会受限于单个 Controller 的读写带宽。因此一个 Kafka 集群可以管理的分区总数也会受限于这单个 Controller 的效率。

Confluent 流数据部门首席工程师王国璋解释道：“在 KIP-500 中，我们用一个 Quorum Controller 来代替和 ZooKeeper 交互的单个 Controller，这个 Quorum 里面的每个 Controller 节点都会通过 Raft 机制来备份所有元数据，而其中的 Leader 在写入新的元数据时，也可以借由批量写入（batch writes）Raft 日志来提高效率。我们的实验表明，在一个可以管理两百万个分区的集群中，Quorum Controller 的迁移过程可以从几分钟缩小至三十秒。”

减少依赖、扩大单集群承载能力，这肯定是一个很积极的改变方向。虽然目前的版本还未经过大流量检验，可能存在稳定性问题，这也是让广大开发者担心的一个方面。但从长期意义上来讲，KIP-500 对社区和用户都是一个很大的福音。

当版本稳定之后，最终大家就会涉及到“升级”的工作。但如何升级，却成了一个新的问题，在很多 Kafka 的使用场景中，是不允许业务停机的。韩欣拿腾讯云的业务举例说，“微信安全业务的消息管道就使用了腾讯云的 Kafka，假设发生停机，那么一些自动化的安全业务就会受到影响，从而严重影响客户体验。”

“就我们的经验而言，停机升级，在腾讯云上是一个非常敏感的词。腾讯云 Kafka 至今为止已经运营了六七年，服务了内外部几百家大客户，还未发生过一次停机升级的情况。如果需要停机才能升级，那么对客户的业务肯定会有影响的，影响的范围取决于客户业务的重要性。从云服务的角度来看，任何客户的业务的可持续性都是非常重要的、不可以被影响的。”

对于 Confluent 来讲，提供不需要停机的平滑升级方案是一件非常有必要的事情。

据王国璋介绍，“目前的设计方案是，在 2.8 版本之后的 3.0 版本会是一个特殊的搭桥版本（bridge release），在这个版本中，Quorum Controller 会和老版本的基于 ZooKeeper 的 Controller 共存，而在之后的版本我们才会去掉旧的 Controller 模块。”

对于用户而言，这意味着如果想要从 2.8 版本以下升级到 3.0 以后的某一个版本，比如说 3.1，则需要借由 3.0 版本实现两次“跳跃”，也就是说先在线平滑升级到 3.0，然后再一次在线平滑升级到 3.1。并且在整个过程中，Kafka 服务器端都可以和各种低版本的客户端进行交互，而不需要强制客户端的升级。

而像腾讯这样的企业，也会持续采用灰度的方式来进行业务的升级验证，韩欣说，“一般不会在存量集群上做大规模升级操作，而是会采用新建集群的方式，让一些有迫切诉求的业务先切量进行灰度验证，在保证线上业务稳定运行的情况下，逐步扩展新集群的规模，这样逐步将业务升级和迁移到新的架构上去。”

Apache Kafka 出现之后，很快击败其它的消息系统，成为最主流的应用。从 2011 年启动，经过十年发展，得到大规模应用之后，为什么现在又决定用“Raft 协议”替换 ZooKeeper 呢？对此，王国璋回复 InfoQ 说，Raft 是近年来很火的共识算法，但在 Kafka 设计之初（2011 年），不仅仅是 Raft 方案，就连一个成熟通用的共识机制（consensus）代码库也不存在。当时最直接的设计方案就是基于 ZooKeeper 这样一个高可用的同步服务项目。

在这十年里，Hadoop 生态中的不少软件都在被逐渐抛弃。如今，作为 Hadoop 生态中的一员，ZooKeeper 也开始过时了？韩欣给予了否认意见，“每一种架构或者软件都有其适合的应用场景，我不认可过时这个词。”

从技术的角度来看，历史的车轮在不断向前滚动，学术界和工业界的理论基础一直在不断进化，技术也要适应不断革新的业务不停去演进。不否认有一些软件会被一些新的软件所替代，或者说一些新的软件会更适合某些场景。比如流计算领域，Storm、Spark、Filnk 的演进。但是合适的组件总会出现在合适的地方，这就是架构师和研发人员的工作和责任。

Kafka 发展至今，虽然其体系结构不断被改进，比如引入自动缩放、多租户等功能，来满足用户发展的需求，但针对这次大的改进，且还存在需要验证的现状，网友在 HackerNews 上提出了一个灵魂发问：“如果现在还要设计一个新系统，那么是什么理由选择 Kafka 而不是 Pulsar？”

Confluent 的科林·麦凯布（Colin McCabe）回应这个争议说，起码去掉 ZooKeeper 对 Pulsar 来说是一个艰巨的挑战。Kafka 去除 ZooKeeper 依赖是个很大的卖点，意味着 Kafka 只有一个组件 Broker，而 Pulsar 则需要 ZooKeeper、Bookie、Broker（或者 proxy）等多个组件。但也正因为 抽离出一层存储层（Bookie），使得后起之秀的 Pulsar 在架构上天然具有了“计算存储分离”的优势。

总的来说，在企业加速上云的背景下，无论是 Kafka 还是 Pulsar，消息系统必须是要适应云原生的大趋势的，实现计算和存储分离的功能也是 Kafka 下一步的策略。Confluent 在另一个 KIP-405 版本中，实现了一个分层式的存储模式，利用在云架构下多种存储介质的实际情况，将计算层和存储层分离，将“冷数据”和“热数据”分离，使得 Kafka 的分区扩容、缩容、迁移等等操作更加高效和低耗，同时也使 Kafka 可以在理论上长时间保留数据流。

在发展趋势上，云原生的出现对消息系统的影响是比较大的，比如容器化和大规模云盘，为原本在单集群性能和堆积限制方面存在上限问题的 Kafka，在突破资源瓶颈这里带来了新的思路。Broker 的容器化，堆积的消息用大规模的云盘，再加上 KRaft 去掉了 ZooKeeper 给 Kafka 带来的元数据管理方面的限制，是否是给 Kafka 带来了二次的消息系统革命？容器化的消息系统是否会带来运营运维方面更多的自动化的能力？Serverless 是否是消息系统的未来趋势？云和云原生的发展，给传统的消息系统安上了新的翅膀，带来了新的想象空间。

采访嘉宾：

韩欣，腾讯云中间件-微服务产品中心技术总监，微服务平台 TSF、消息队列 CKafka / TDMQ、微服务观测平台 TSW 等中间件产品的负责人。负责中间件相关产品的规划，架构和落地实施，有超过十三年的研发架构经验。目前关注在云计算中间件相关领域，致力于整合 PaaS 技术资源，构建基于微服务的技术中台，为企业的数字化转型提供基础支持。

王国璋，现就职于 Confluent，任流数据部门首席工程师。Apache Kafka 项目管理委员会成员（PMC），Kafka Streams 作者。分别于复旦大学计算机系和美国康奈尔大学计算机系取得学士和博士学位，主要研究方向为数据库管理和分布式数据系统。此前曾就职于 LinkedIn 数据架构组任高级工程师，主要负责实时数据处理平台，包括 Apache Kafka 和 Apache Samza 系统的开发与维护。

概念认知：Hadoop——分布式计算平台

从单个服务器扩展到数千台服务器，每台机器提供本地计算和存储

使用Java实现的、分布式的、可横向扩展的分布式文件系统。可存储超大文件，采用流式数据访问模式，运行于通用X86服务器上。

NameNode，是HDFS集群的管理节点，负责管理和维护HDFS集群的命名空间以及元数据信息并管理集群中的数据节点。有两个重要的文件:

EditLog，用于记录针对文件的操作（文件的创建、删除、重命名）

FSImage，用于维护整个系统的命名空间，包括数据块到文件的映射和文件的属性等

SecondaryNameNode，并不是NameNode的备份，定期将EditLog合并到FSImage，以防止EditLog过大。保存合并后的FSImage的副本，作为NameNode的检查点，但是保存的状态滞后于NameNode，因此NameNode失效后会丢失部分数据

DataNode ，数据节点，根据系统的需要存储并检索数据块，HDFS集群启动和正常运行期间定期向NameNode发送存储的块列表和心跳信息

CheckpointNode，Hadoop2.x后加入，和Secondary NameNode作用一致

BackupNode，Hadoop2.x后加入，NameNode的完全备份

属于非关系型数据库，数据是基于列的而不是基于行，可在廉价服务器上搭建大规模结构化存储集群。

把一个复杂问题分解成处理子集的子问题。“Map”对子问题分别处理得到中间结果，“Reduce”把中间结果汇总，得到最终结果。

通用的资源管理模块，可以为上层应用提供统一的资源调度和管理。使Hadoop不仅可以使用MapReduce，还可以使用Storm、Spark等计算框架。

包含两种节点：ResourceManage负责资源调度，NodeManager负责具体事务

基于Hadoop的数据仓库工具，将结构化的数据文件映射为数据库表。操作本质是将SQL语句转换为MapReduce程序。

将数据从外部结构化数据存储导入Hive或HBase，也可以从Hadoop中提取数据，将其导出到外部结构化数据存储。

使用基于数据流的简单灵活的架构

ZooKeeper（分布式协调服务）

可以为分布式应用程序提供配置服务、域名服务、分布式同步等服务。

是一种Java Web应用程序，用于管理Hadoop作业的工作流调度。

基于共享秘钥对称加密，通过秘钥系统为客户机/服务器应用程序提供认证服务

提供被称为目录服务的信息服务，为应用程序提供访问、认证和授权的集中管理。

提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。使用高并发的MMP查询引擎，查询速度比Hive快得多。

企业搜索平台，基于标准的开放式接口（XML、JSON、HTTP），可实现强大的搜索匹配功能。

高吞吐量的分布式发布-订阅消息系统。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com