Apache Kudu在网易的实践

文章目录

1 Kudu定位与架构
2 生产实践
3 我们遇到的问题
4 Kudu功能展望

本次的分享内容分成四个部分：

系统概述：认识kudu，理解Kudu的系统设计与定位
生产实践：分享网易内部的典型使用场景
遇到的问题：实际使用过程中遇到的问题和问题的排障过程
功能展望：对Kudu功能特性的展望

Kudu定位与架构

Kudu是一个存储引擎，可以接入Impala、Presto、Spark等Olap计算引擎进行数据分析,容易融入Hadoop社区。Kudu整合了随机读写和大数据分析能力，具有低延迟的随机读写能力和高吞吐量的批量查询能力。

与HBase、Casandra不同，Kudu要求声明Schema。Schema可以为上层计算引擎提供更多元数据,进行计算优化。Kudu的每个字段有主键、列名和列类型。拿到列类型信息后能够对不同列进行编码和压缩，优化存储空间，减少磁盘开销。Kudu支持bitshuffle、运行长度编码、字典编码等列编码方式，这些编码会根据列的类型不同做不同设计。比如对于重复值多、重复值变化不大的数据的压缩率很好。

Kudu使用列式存储给Kudu带来了如下特性：

存储上可以节约空间
可以对查询做更多优化，如将过滤条件下推到kudu执行，节约计算资源
支持向量化操作

Kudu 的 Schema 和列存

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Kudu数据存储在Table中，Tablet是Kudu的读写单元，Table内的数据会划分到各个Tablet进行管理。

创建Table时，需要指定Table的分区方式。Kudu 提供了两种类型的分区方式range partitioning ( 范围分区 ) 、 hash partitioning ( 哈希分区 )，这两种分区方式可以组合使用。分区的目的是把Table内的数据预先定义好分散到指定的片数量内，方便Kudu集群均匀写入数据和查询数据。范围分区支持查询时快速定位数据，哈希分区可以在写入时避免数据热点，可以适应各个场景下的数据。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Kudu有管理节点（Master）和数据节点（Tablet Server）。管理节点管理元数据，管理表到分片映射关系、分片在数据节点内的位置的映射关系，Kudu客户端最终会直接链接数据节点。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Kudu作为分布式系统，为了保障数据可用性和高可用，支持多副本。Kudu 使用 Raft 协议来实现分布式环境下副本之间的数据一致性。Raft算法数据不依赖其他存储和文件系统，优势在于可以保证服务高可用、服务可用性、一致性的均衡。

Kudu的update设计

Olap中对update的设计会影响到Olap性能。update操作可能引发数据多版本问题和update引发的数据merge问题。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Tablet是Kudu数据读写单元，Tablet下更细分的数据存储单元是 RowSet。RowSet有两种，分别是MemRowSet 和 DiskRowSet，不同RowSet维护了不同组件范围内的数据。内存中的 MemRowSet 在到达一定大小后会刷盘成为DiskRowSet。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Kudu把更新操作当作一条新操作，而不是写一条新日志。更新操作是Undo/Redo记录，这些内存中的更新操作会被整合为DeltaMemstore持久化。Base数据、Undo数据、Redu数据写在同一个RowSet中。这样的存储设计优点是可以在更新时候快速找到数据，缺点是查询时需要确认查询的主键在哪个RowSet位置中。

Kudu也使用了LSM的结构。Kudu的comopaction有多种：MinorDeltaCompaction、MajorDeltaCompaction、MergingCompaction。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Kudu的update是一个多版本操作，目的是写入和读取时互相不干扰、不需要读时额外加锁。

小结

Kudu Update设计特点：
• ** 更新已经flush的数据和写入新数据走不通的处理逻辑，原始数据和更新位于同一个Rowset，不用跨Rowset进行merge**
• **通过base数据的RowID和更新时间戳作为REDO/UNDO数据的key**，读取更新高效
• Key大小固定，存储和比较效率高
• 不需要查询出主键数据也能获取更新数据
• 在大多数使用场景下能够实现更高效的读取
• 如果返回的结果不要求顺序，直接从RowSet中读出数据，不用merge
• 如果更新较少，REDO会快速merge到base数据，这时在读取最新数据时，可以不进行apply REDO的操作

生产实践

实时数据采集场景

实时数据分析中，一些用户行为数据有更新的需求。没有引入Kudu前，用户行为数据会首先通过流式计算引擎写入HBase，但HBase不能支撑聚合分析。为了支撑分析和查询需求，还需要把HBase上的数据通过Spark读取后写入其他OLAP引擎。使用Kudu后，用户行为数据会通过流式计算引擎写入Kudu，由Kudu完成数据更新操作。Kudu可以支持单点查询，也可以配合计算引擎做数据分析。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

维表数据关联应用

有些场景中，日志的事件表还需要和MySQL内维度表做关联后进行查询。使用Kudu，可以利用NDC同步工具，将MySQL中数据实时同步导入Kudu，使Kudu内数据表和MySQL中的表保持数据一致。这时Kudu配合计算引擎就可以直接对外提供结果数据，如产生报表和做在线分析等。省去了MySQL中维度表和数据合并的一步，大大提升了效率。