页面树结构

版本比较

标识

  • 该行被添加。
  • 该行被删除。
  • 格式已经改变。
评论: 修改 - 格式

目录

Kudu 是一个针对 Apache Hadoop 平台而开发的列式存储管理器。Kudu 共享 Hadoop 生态系统应用的常见技术特性: 它在 commodity hardware商品硬件)上运行,horizontally scalable水平可扩展),并支持 highly available高可用)性操作。

Kudu 有许多不错的设计,它的一些优点包括 : 

  • OLAP 工作的快速处理。
  • MapReduceSpark 和其他 Hadoop 生态系统组件集成。
  • Apache Impala(incubating)紧密集成,使其与 Apache Parquet 一起使用 HDFS 成为一个很好的可变的替代方案。
  • 强大而灵活的一致性模型,允许您根据每个 per-request请求选择)一致性要求,包括 strict-serializable严格可序列化)一致性的选项。

  • 针对同时运行顺序和随机工作负载的情况性能很好。
  • 易于管理以及可以使用 Cloudera Manager 来进行管理。
  • High availability(高可用性)。Tablet ServersMasters 使用了 Raft Consensus Algorithm,确保只要有一半以上的副本可用,该 tablet 便可用于读写。例如,如果 3 个副本中有 个或 个副本中的 个可用,则该 tablet 可用。即使在 leader tablet 出现故障的情况下,读取功能也可以通过 read-only只读的)follower tablets进行服务。
  • 结构化数据模型。

通过结合这些所有的特性,Kudu 目标是支持在当代 Hadoop 存储技术上难以实现的应用的家族。Kudu 是一个很好的解决方案的几个例子是 : 

  • 报告那些需要立即向终端用户提供  newly-arrived(新来的)数据的应用程序。
  • 必须同时支持的 Time-series时间序列)应用程序 : 
    • 查询大量历史数据。
    • 必须非常快地返回关于单个实体的细粒度查询。
  • 使用预测模型进行实时决策的应用程序,可根据所有历史数据定期刷新预测模型。
  • 有关这些和其他方案的更多信息,请参阅 Example Use Cases

Kudu-Impala 集成特性

CREATE/ALTER/DROP TABLE

Impala 支持使用 Kudu 作为持久层来 creating创建),altering(修改)和 dropping删除)表。这些表遵循与 Impala 中其他表格相同的  nternal / external内部 / 外部)方法,允许灵活的数据采集和查询。

INSERT

数据可以使用与那些使用 HDFSHBase 持久性的任何其他 Impala 表相同的语法插入 Impala 中的 Kudu 表。

UPDATE / DELETE

Impala 支持 UPDATE 和 DELETE SQL 命令逐行或批处理修改 Kudu 表中的已有的数据。选择 SQL 命令的语法与现有标准尽可能兼容。除了简单 DELETE 或 UPDATE 命令之外,还可以 FROM 在子查询中指定带有子句的复杂连接。

Flexible Partitioning(灵活分区)

Hive 中的表分区类似,Kudu 允许您通过 hash 或范围动态预分割成预定义数量的 tablets,以便在集群中均匀分布写入和查询。您可以通过任意数量的 primary key主键)列,任意数量的 hashes 和可选的 list of split rows进行分区。参见模式设计

Parallel Scan(并行扫描)

为了在现代硬件上实现最高的性能,Impala 使用的 Kudu 客户端可以跨多个 tablets 扫描。

High-efficiency queries(高效查询)

在可能的情况下,Impala 将谓词评估推送到 Kudu,以便尽可能地将谓词评估为尽可能接近数据。在许多工作负载中,查询性能与 Parquet 相当。

有关使用 Impala 查询存储在 Kudu 中的数据的更多详细信息,请参阅 Impala 文档。

概念和术语

Columnar Data Store(列式数据存储)

Kudu 是一个 columnar data store(列式数据存储)。列式数据存储在强类型列中存储数据。通过适当的设计,由于几个原因,它针对 analytical分析)或 warehousing数据仓库)工作负载非常出色。

Read Efficiency(读取效率)

对于分析查询,您可以在忽略其他列时读取单个列或该列的一部分。这意味着您可以在磁盘上读取最少数量的块时完成查询。与基于行的存储相比,您需要读取整行,即使您只返回几列的值。

Data Compression(数据压缩)

由于给定的列只包含一种类型的数据,基于模式的压缩比压缩混合数据类型(在基于行的解决方案中使用)在同样的数量级上效率更高。结合从列读取数据的效率,压缩允许您在从磁盘读取更少的块时完成查询。请参阅 数据压缩

Table(表)

一张 talbe 是数据存储在 Kudu 的位置。表具有 schema 和完全有序的 primary key主键)。table 被分成称为 tabletssegments

Tablet

一个 tablet 是一张 table 连续的 segment,与其它数据存储引擎或关系型数据库中的 partition(分区)相似。给定的 tablet 在多个 tablet 服务器上进行复制,并且在任何给定的时间点,其中一个副本被认为是 leader tablet。任何副本都可以对读取进行服务,并且写入时需要在 tablet 服务的一组 tablet 服务器之间达成共识。

Tablet Server

一个 tablet server 存储数据并且为 clients 提供 tablets。对于给定的 tablet,一个 tablet server 充当 leader,其他 tablet server 充当该 tablet follower 副本。只有 leader 服务写请求,然而 leaderfollowers 为每个服务提供读请求。leader 使用 Raft Consensus Algorithm 来进行选举 。一个 tablet server 可以为多个 tablets 进行服务,并且一个 tablet 可以被多个 tablet servers 提供服务。

Master

master 保持跟踪所有的 tabletstablet serversCatalog Table 和其它与集群相关的 metadata在给定的时间点,只能有一个代理的 master(也就是 leader)。如果当前的 leader 消失,则选举出一个新的 master,使用  Raft Consensus Algorithm 来进行选举。

master 还针对客户端的操作协调 metadata(元数据)。例如,当创建新表时,客户端内部将请求发送给 master master 将新表的元数据写入 catalog table,并协调在 tablet server 上创建 tablet 的过程。

所有 master 的数据都存储在 tablet 中,可以复制到所有其他候选的 master

tablet server 以设定的间隔向 master 发出心跳(默认值为每秒一次)。

Raft Consensus Algorithm

Kudu 使用 Raft consensus algorithm 作为确保常规 tabletmaster 数据的容错性和一致性的手段。通过 Rafttablet 的多个副本选举出 leader,它负责接受以及复制到 follower 副本的写入。一旦写入的数据在大多数副本中持久化后,就会向客户确认。给定的一组 副本(通常为 35 个)能够接受最多(N - 1)/2 错误的副本的写入。

Catalog Table(目录表)

 catalog talbe 是针对 Kudumetadata(元数据中)的中心位置。它存储有关 tablestablets 的信息。该 catalog table(目录表)可能不会被直接读取或写入。相反,它只能通过客户端 API 中公开的元数据操作访问。

Tables

table schemas, locations, and states(表模式,位置 和状态)

Tablets

现有 tablet 的列表,哪些 tablet servers 具有每个 tablet 的副本,tablet 的当前状态以及开始和结束的 keys(键)。

Logical Replication(逻辑复制)

 Kudu 复制操作,而不是磁盘上的数据。这被称为 logical replication逻辑复制),而不是 physical replication物理复制)。这有几个优点 : 

 

  • 虽然 insert(插入)和 update(更新)确实通过网络传输数据,deletes(删除)不需要移动任何数据。delete(删除)操作被发送到每个 tablet server,它在本地执行删除。
  • 物理操作,如 compaction,不需要通过 Kudu 的网络传输数据。这与使用 HDFS 的存储系统不同,其中 blocks块)需要通过网络传输以满足所需数量的副本。
  • tablet 不需要在同一时间或相同的时间表上执行压缩,或者在物理存储层上保持同步。这会导致由于压缩或大量写入负载而导致所有 tablet server 同时遇到高延迟的机会。

架构概述

下图显示了一个具有三个 master 和多个 tablet serverKudu 集群,每个服务器都支持多个 tablet。它说明了如何使用 Raft 共识来允许 mastertablet serverleader 和 f ollow。此外,tablet server 可以成为某些 tabletleader,也可以是其他 tabletfollowerleader 以金色显示,而 follower 则显示为蓝色。

案例示例

Streaming Input with Near Real Time Availability具有近实时可用性的流输入)

数据分析中的一个共同挑战就是新数据快速而不断地到达,同样的数据需要靠近实时的读取,扫描和更新。Kudu 通过高效的列式扫描提供了快速插入和更新的强大组合,从而在单个存储层上实现了实时分析用例。

Time-series application with widely varying access patterns具有广泛变化的访问模式的时间序列应用)

time-series时间序列)模式是根据其发生时间组织和键入数据点的模式。这可以用于随着时间的推移调查指标的性能,或者根据过去的数据尝试预测未来的行为。例如,时间序列的客户数据可以用于存储购买点击流历史并预测未来的购买,或由客户支持代表使用。虽然这些不同类型的分析正在发生,插入和更换也可能单独和批量地发生,并且立即可用于读取工作负载。Kudu 可以用 scalable可扩展)和 efficient高效的)方式同时处理所有这些访问模式。由于一些原因,Kudu 非常适合时间序列的工作负载。随着 Kudu 对基于 hash 的分区的支持,结合其对复合 row keys行键)的本地支持,将许多服务器上的表设置成很简单,而不会在使用范围分区时通常观察到“hotspotting热点)”的风险。Kudu 的列式存储引擎在这种情况下也是有益的,因为许多时间序列工作负载只读取了几列,而不是整行。 过去,您可能需要使用多个数据存储来处理不同的数据访问模式。这种做法增加了应用程序和操作的复杂性,并重复了数据,使所需存储量增加了一倍(或更糟)。Kudu 可以本地和高效地处理所有这些访问模式,而无需将工作卸载到其他数据存储。

Predictive Modeling预测建模) 数据科学家经常从大量数据中开发预测学习模型。模型和数据可能需要在学习发生时或随着建模情况的变化而经常更新或修改。此外,科学家可能想改变模型中的一个或多个因素,看看随着时间的推移会发生什么。在 HDFS 中更新存储在文件中的大量数据是资源密集型的,因为每个文件需要被完全重写。在 Kudu,更新发生在近乎实时。科学家可以调整值,重新运行查询,并以秒或分钟而不是几小时或几天刷新图形。此外,批处理或增量算法可以随时在数据上运行,具有接近实时的结果。

Combining Data In Kudu With Legacy Systems结合 Kudu 与遗留系统的数据) 

公司从多个来源生成数据并将其存储在各种系统和格式中。例如,您的一些数据可能存储在 Kudu,一些在传统的 RDBMS 中,一些在 HDFS 中的文件中。您可以使用 Impala 访问和查询所有这些源和格式,而无需更改旧版系统。