Kudu

《Kudu：构建高性能实时数据分析存储系统 新的应用场景》

kudu:支持逐行插入、低延迟随机读、快速分析和扫描以及更新

 

流式处理背后的思想是，在数据流中直接处理数据，而不是将数据保存到存储系统，然后再批量处理。

尽管诸如Apache Flume、Storm、Spark Streaming和Flink之类的处理框架提供了实时读取和处理事件的能力，但它们还需要倚赖外部系统来存储和访问外部上下文。例如，使用Spark Streaming可以每隔几秒从Kafka读取微批量事件，但如果你希望能够保存结果、读取外部上下文、计算风险评分和更新患者档案，存储系统就要满足以下

各种各样的需求：

逐行插入

当事件产生时，需要立即存储，并且可供其他工具和流程做分析。

低延迟随机读

当流式引擎处理一个事件时，它可能需要查找与该事件相关的参考数据。比如，如果该事件代表的是医疗设备产生的数据，很可能就需要查找与病人相关的上下文信息，比如病人所就诊诊所的名字，或者跟病情相关的特定信息。

快速分析和扫描

这个事件和历史数据有怎样的关联呢？对数据做快速分析和扫描或者SQL查询，得到历史的上下文信息，这种能力对应用来说通常是很重要的。

更新

上下文信息是会变化的。例如，来自OLTP（Online Transaction Processing，在线事务处理）应用的上下文信息可能会添加像联系人信息之类的参考数据，而病人的风险评分可能在新的信息被计算出来后发生变化。

当研究这些应用场景时，你肯定注意到了“实时能力”这个主题。你可能会指出，许多组织没有使用Kudu，但是他们也通过Hadoop成功实现这些应用。没错，分开来看，Hadoop的这些存储层可以处理快速插入数据、低延迟随机读、更新和快速扫描。

HBase能够处理数据的低延迟随机读/写。

那么，快速分析和扫描呢？HDFS可以做得很好。想要简单易用？没问题，使用一个HDFS命令就可以输入你所有的批处理数据文件。

问题是，当你想拥有所有这些特性时——逐行插入、低延迟随机读、快速分析和扫描以及更新，这个架构就会变得十分复杂而且难以维护，就像图1-7所示的这样。

同时满足这些存储特性对许多数据库系统来说是可能的，但是使用Hadoop和大数据技术来实现它们却非常困难。现实就是这么残酷，使用Hadoop来搭建这一类应用比较难，因为你选择的存储层只能满足这些特性中的一部分。

 

Kudu在大数据生态中的独特位置

和Hadoop中的其他组件一样，Kudu也被设计成可扩展和可容错的。Kudu仅仅是一个存储层，因此它并不处理数据，而是依赖外部的Hadoop处理引擎，比如MapReduce、Spark或Impala来处理。尽管Kudu能与许多其他Hadoop组件集成，但是它也能作为一个独立的存储引擎而运行，不依赖于HDFS或者ZooKeeper等其他框架。Kudu把数据按照自己的列存储格式存储在底层Linux文件系统中，不像HBase那样，Kudu不以任何方式使用HDFS。

Kudu的数据模型对于任何拥有RDBMS背景的人来说都是熟悉的。尽管Kudu本身不是SQL引擎，但它的数据模型与数据库的相似。表是由固定数量的拥有类型的列组成的，这些列的子集将构成主键。像在RDBMS中一样，主键保证了行的唯一性。Kudu在磁盘上使用列式存储格式，这样能保证对一部分列进行高效的编码和快速扫描。为了实现可扩展性和容错，Kudu的表被水平分割成很多块，称为tablet，其写操作使用Raft一致性算法在tablet之间复制数据。

图1-8 Kudu填补了分析能力的空白

Kudu的设计源自对当今Hadoop的复杂架构和局限的敏锐理解，以及开发人员和架构师在选择存储引擎时做出的截然不同的决定。Kudu的目标是成为一种各方面条件都适中的选择，既拥有强大而广泛的功能，又对多种负载有较好的性能。具体而言，就是Kudu将低延迟随机访问、逐行插入、更新和快速分析扫描融合到一个存储层中。正如之前讨论过的，HDFS、HBase和Cassandra等存储引擎拥有其中的某一项或几项能力，但它们之中没有一个拥有全部的能力。现有Hadoop存储引擎之间负载特性的差异被称为分析能力的空白（analytical gap），图1-8对此做了形象的解释

 

HDFS是一个仅支持追加写的文件系统，对于需要顺序扫描大规模数据的处理引擎而言，它的表现最好。在图1-8的另一端是HBase或者其他类big table的系统，比如Cassandra。HBase和Cassandra支持实时随机读/写，以及OLTP应用需要的其他特性。HBase非常适用于那种在线、实时、高并发，而且其中大多数操作都是随机读/写或短扫描的环境。

你会注意到，在图1-8中Kudu并没有声称其对于某一类特定负载要比HBase或者HDFS快。Kudu的目标是，在扫描性能上达到HDFS上的Parquet或者ORCFile格式的两倍；同时，像HBase一样，拥有快速随机读/写的能力，在SSD存储上的读/写延迟只有1 ms。

重新审视前面的实时分析应用场景例子，如果这一次改用Kudu的话，你会注意到我们的架构变得简单多了（见图1-9）。首先，只有一个存储层，不再存在用户发起的compaction或者存储优化过程。对运维人员来说，他们只需要监控和维护一个系统，并且不需要设置定时任务在实时层和批处理层之间或者在Hive的分区之间移动数据。开发人员不需要编写代码来维护数据，或者处理数据延迟到达的特殊情况，并且他们能很轻松地更新数据。而用户则可以即时访问实时和历史数据，因为它们都放在一个地方。

图1-9 使用了Kudu的架构

Kudu是一个新的存储系统。在过去的10年里，已经有数百个数据库系统被创造出来，人们对此感到疲惫不堪。为什么要重新做一个存储系统呢？在本节，我们会继续通过比较Kudu和传统生态系统的组件来回答这个问题。

最简单的是与SQL引擎的对比，比如Hive、Impala和Spark SQL。Kudu并不会完全执行SQL查询。SQL查询的一部分操作可以下推到存储层，比如投影操作和谓词操作，这些确实是在Kudu中执行的。然而，SQL引擎需要有解析器（parser）、优化器（planer）和执行查询的方法。Kudu仅在执行查询的过程中起作用并向优化器提供一些信息。此外，S Q L引擎必须把投影操作和谓词操作下推到Kudu，或者在此过程中与Kudu通信，所以Kudu参与了查询的执行过程，它不仅仅是一个简单的存储引擎。

 

 

Kudu现在拥有一些OLAP和OLTP的特性，但是缺少对跨行的原子性、一致性、隔离性、持久性事务的支持，可以把它归为混合事务/分析处理（Hybrid Transaction/Analytic Processing，HTAP）类型的数据库。例如，Kudu支持快速主键检索，并且能够在数据持续输入的同时进行分析。OLAP数据库在这种应用场景下性能通常不是很好。另外，与OLAP数据库相比，Kudu的持久性保证和OLTP数据库更接近。从长远来看，有了类似GoogleSpanner（一种OLTP系统）的跨数据中心的同步复制后，Kudu的持久性会更好。Kudu的quorum能力可以实现一种名为Fractured Mirrors的机制：一个或两个节点使用行存储，另外的节点使用列存储。这样就可以在行存储的节点上执行OLTP类型的查询，在列存储的节点上执行OLAP查询，混合两种负载。

 

 

 

 

 

 

 

 

’