Kudu 学习 - 第一篇 Kudu 简介
一、为什么会有 Kudu
要在 Hadoop 生态系统中实现数据的快速输入和快速分析，一直以来只有少数可用但是不够完美的解决方案。它们要么以缓慢的数据输入为代价实现快速分析，要么以缓慢的分析为代价实现快速的数据输入。
Apache Kudu 就是为对快速输入的数据进行快速的分析而生。
Kudu 的重要性在于：
- 大数据分析的复杂性往往是存储系统的局限性带来的，Kudu 的局限性小很多，一定程度使大数据分析变得简单
- 新的应用场景需要 Kudu，例如越来越多的应用集中在机器生成的数据和实时分析领域
- 适配新的硬件环境，从而带来更高的性能和应用灵活性
二、源码学习地址
源码学习地址：https://github.com/kudu-book/getting-started-kudu
三、Kudu 的概念与特性
3.1 Kudu 是一个存储层
Kudu 仅仅是一个存储层，本身不处理数据，而是依赖外部的 Hadoop 处理引擎来处理，如 MapReduce、Spark 或 Impala。
Kudu 可以作为一个独立的存储引擎运行，不依赖于 HDFS 或者 Zookeeper 等其他框架。
Kudu 把数据按照自己的列存储格式存储在底层 Linux 文件系统中。
Kudu 的易用性体现在：
- 提供了更接近于 RDBMS 的功能和数据模型
- 提供类似 RDBMS 的库表存储结构
- 允许用户以和 RDBMS 相同的方式插入、更新和删除数据
Kudu 最大的优势：
Kudu 同时具备了逐行插入、低延迟随机访问、更新和快速分析扫描的能力，使得它在 OLAP 和 OLTP 中都能提供较好的支持，这些原本需要多个存储系统同时支持的复杂架构被替换成只有一个存储系统，所有的数据被存放在这个存储系统里，极大地简化了大数据的架构。
3.2 Kudu 的表结构
Kudu 的表是由固定数量的拥有类型的列组成的，这些列的子集将构成主键，主键保证了行的唯一性。
Kudu 表被水平分割成很多块，成为 tablet。
写操作使用 Raft 一致性算法在 tablet 之间复制数据。
3.3 Kudu 的元数据管理
Kudu 存储自己的元数据信息，元数据存储在由 master 服务器管理的 tablet 中，表中的用户数据则存储在有 tablet 服务器管理的 tablet 中。但如果要在 Kudu 上使用 Impala，则还需要 Hive 的 Metastore 服务作为支撑。
3.4 Kudu 与传统生态系统的 SQL 引擎比较
Kudu 与传统生态系统的 SQL 引擎比较，如 Hive、Impala 和 SparkSQL。
Kudu 不会完全执行 SQL 查询。只有一部分操作会被下推到 Kudu，如投影操作和谓词操作，其他由 SQL 引擎执行，要求 SQL 需具备解析器（parser）、优化器（planer）和执行查询的方法。
3.5 Kudu 与传统关系型数据库比较
- 跟关系型数据库一样，Kudu 表有一个唯一的主键。
- 关系型数据库中常见的特性，比如事务、外键和非主键索引，目前在 Kudu 中是不支持的。
- Kudu 拥有一些 OLAP 和 OLTP 特性，但是缺少对跨行的原子性、一致性、隔离性、持久性事务的支持。
- Kudu 可被归为混合食物/分析处理（Hybrid Transaction/Analytic Processing，HTAP）类型数据库。
- Kudu 支持快速主键检索，并能在数据持续输入的同时进行分析，而 OLAP 数据库在这种场景下性能通常不是很好。
- Kudu 的持久性保证和 OLTP 数据库更为接近。
- Kudu 的 quorum 能力可以实现一种名为 Fractured Mirrors 的机制，即一个或两个节点使用行存储，另外的节点使用列存储。这样就可以在行存储的节点上执行 OLTP 类型的查询，在列存储的节点上执行 OLAP 查询，混合两种负载。
3.6 Kudu 与大数据组件比较
Kudu 与大数据组件比较，如 HDFS、HBase 和 Cassandra。
- HDFS 擅长大规模扫描，但不擅长随机读，严格来说，并不支持随机写，可以通过合并的方式模拟随机写，但成本很高。
- HBase 和 Cassandra 擅长随机访问，随机读取和修改数据，但大规模扫描性能较差。
- Kudu 的目标是把扫描性能做到 HDFS 的两倍，而随机读性能接近 HBase 和 Cassandra，实际目标是在 SSD 上随机读/写的延迟在 1ms 以内。
3.7 Kudu 的优势总结
- 简化了存储引擎的复杂度
- 更适合实时分析场景
- 类似 RDBMS 的功能结构与使用方式
四、Kudu - 服务器
所有的 Kudu 服务器都可被分为两种类型：master 服务器和 tablet 服务器。服务器上的数据都以 tablet 形式存储。每个角色通常至少有三台服务器，tablet 中的数据可以爱这些服务器之间复制，通过 Raft 一致性算法，其中一台服务器会被选举为 Leader。
master 服务器
master 服务器的职责是管理 Kudu 集群的各种操作。客户端与单台 master 服务器交互来实现表的定义、获取表属性或元数据。master 服务器是一个单 tablet 表，存储诸如表名、列名、列类型和数据位置之类的元数据，以及状态类信息，如表是否正在被创建、运行、删除等。本质上，master 服务器管理着系统的“目录”，而这个“目录”也是所有 RDBMS 都会使用的。
每个表的目录数据的量很小。为了提高性能，系统始终在内存中保存了完整的目录数据的 write-through 缓存。即使 master 服务器对于访问数据非常重要，它也无须执行很多操作。因此，它们可以被部署在小服务器（硬件）上。因为 master 服务器会使用配置中的复制因子（replicationfactor）来复制元数据存储，所以拥有与复制因子相同数量的 master 服务器非常重要。默认情况下，应该安装三台服务器。这也将确保 Kudu 集群的高可用性。
tablet 服务器
tablet 服务器是工作节点，类似于 HDFS DataNode 和 HBase region server 的混合体。tablet 服务器的作用是执行所有与数据相关的操作：存储、访问、编码、压缩、compaction 和复制。与 master 服务器相比，tablet 承担着繁重的工作。tablet 服务器还负责将数据复制到其他 tablet 服务器上。
- Kudu 最多可以支持 300 台服务器。但为了获得最高的稳定性，建议 tablet 服务器不超过 100 个。
- 建议每台 tablet 服务器最多包含 2000 个 tablet（包含副本）。
- 建议每个表在每台 tablet 服务器上最多包含 60 个 tablet（包含副本）。
- 建议每台 tablet 服务器最多在磁盘上存储 8TB 的数据。服务器上所有磁盘的容量之和可以超过 8TB，并且可以和 HDFS 共享。
- 为了获取对大事实表的最优扫描性能，建议保持一个 tablet 对应 一个 CPU 核的比例。不要将复制的表计算在内，只考虑 Leader tablet 的数量。对于小维度的表，可以只分配几个 tablet。
五、Kudu - 分区机制
热点问题（hotspotting）
热点问题是分布式系统的数据访问中最常见的问题。当大多数的读或写查询（或者两者）都落到同一个服务器上时，就会出现热点。而我们真正想达到的效果是数据完美地分布，使所有的读/写操作分散到集群的大部分节点上。
Kudu 是基于主键来重组和索引数据的，目前 Kudu 还没有任务和二级键或二级索引的概念。糟糕的主键或分区设计通常会导致热点。
Kudu 的分区策略
Kudu 可以使用两种分区（可以组合使用）：范围分区和哈希分区。
通过不同的分区策略对主键进行分区可以有效避免热点问题。