kudu大量数据更新_数据高效处理的秘诀——Kudu实战

背景

使用Kudu之前，我们的Online Report采用都HDFS/Parquet on Impala的架构，数据每隔一小时通过MapReduce从生产db增量同步到HDFS，再通过HIVE/MAPREDUCE增量MERGE到数仓中，最终通过IMPALA查询在报表展示。这种架构可以支持超大数据集的查询和分析，但是数据更新执行过程很久，效率较差。而Apache Kudu结合了Hbase和HDFS的优势，可以同时提供高效的随机访问以及数据扫描能力，支持数据的实时插入和分析，为Online Report提供了另外一种选择。

Kudu简介

Kudu设计优势

OLAP工作流的快速处理

能够快速更新/获取新数据，并进行在线查询分析

列式存储结构

集成Hadoop生态组件

Spark/Flume/MapReduce/Impala等

服务的高可用性

TabletServer以及Master都使用*Raft*一致性算法。该算法确保只要可用副本数为总数的一半以上，Tablet就可以进行读写操作。即使在leader发生故障的情况下，follower也可以为程序提供只读服务。

结构化数据模型

类关系型数据库，强字段类型，主键索引，表分区设计

NOSQL APIs

支持 C++, Java and Python (INSERT/UPDATE/SCAN/DELETE等)

Kudu整体架构

下图展示了一个三个Master和N个TabletServer的Kudu集群

角色概念：

Tablet

一个table会由多个连续的tablet组成，这里的tablet类似于其他数据存储引擎或者传统数据库中的一个分区。为了容灾和高可用性，每一个tablet会备份至 N(备份数为奇数，最多为7个)个tablet server上，并且其中一个被选举为leader。任何副本都可以进行读操作，写操作时需要在为tablet服务的一组tablet server之间达成一致性

Master

1. 为了保证高可用性，master建议由3个节点部署，其中一个会是leader，如果当前的leader消失，则通过*Raft Consensus Algorithm*选举出一个新的master。

2. master会跟踪tablets、tablet servers、catalog table以及其他原数据的状态和信息，并协调client对metadata的操作

3. 所有master的数据都存在一个tablet里，可以被复制到其他候选的master节点上

Catalog Table

1. tables

2. 存储表结构，位置以及状态

3. tablet servers

4. 存储管理的tablet列表，每个tablet所在的tablet server，tablet的当前状态，开始以及结束的key

Logical Replication

Kudu副本复制操作与HDFS不同，HDFS需要完全通过网络传输来满足他所需要的副本数，而Kudu除了INSERT/UPDATE操作，其他操作都在节点本地执行，如DELETE操作，会将DELETE操作发送至每个tablet server，在他们等本地执行删除操作，极大的降低了集群的网络负载，另外，物理操作COMPACTION，也是本地单独执行，并且不需要在同一时间执行所有副本的压缩，这样能够减少由于COMPACTION以及大量写入操作，导致的高负载。

Kudu实战

表结构设计

创建一个Kudu表

表结构主要有三块内容：

字段设计

1. 字段数量不允许超过300个

2. 除主键外，其他字段可以为空

3. 每一个字段均可以设置自己的编码以及压缩方式

4. Kudu1.7.0版本开始，支持Decimal字段类型，适用于金融和特定的算数运算

主键设计

1. 建表必须包含主键，主键字段必须列在Schema的最前端

2. 建表后，主键无法更改，只能重建表

3. 不支持自增列

4. 主键不能为空，并且不能为boolean、float或者double类型

5. 主键的值无法被更新，但是可以被DELETE后，re-INSERT

6. 主键即索引，tablet中的所有行都按照主键排序。查询时，对主键指定相等或范围的谓词，Kudu扫描表的时候会过滤掉不满足条件的行。

分区设计

1. 不允许您更改创建后如何分区表，但可以添加或删除范围分区

2. 分区方式：哈希分区、范围分区以及多级分区。

表结构可以修改的内容：

1. 表名可以重命名

2. 主键名可以重命名

3. 非主键字段可以被重命名、删除或新增

4. 可以新增或删除范围分区

表结构最佳实践

1. 根据自身业务场景，选择合适的分区方式，让读与写操作在所有tablet server上均匀分布。

2. 根据应用查询的语句，设计合理的主键以及分区，保证读取数据时扫描最小的数据集

3. 分区数量的设置，根据官方文档，每个分区的大小尽量控制在4G左右(单个tablet server最大存储8T/管理的tablets数量最大2000个≈4G)，如果你的表数据量未来估算会在40G左右，那么你的分区数量可以设置10个。

JAVA API 的使用

Kudu实战总结

使用情况

目前通过canal消费生产Mysql-Binlog到Kafka，再通过Spring-Kafka-Consumer实时写入Kudu底层表

有一部分SqlServer的生产数据，通过KuduMapReduce的方式，每半个小时，批量更新到Kudu底层表

Online Report通过Kudu on Impala的方式，查询结果并展示

坑点

时钟服务NTP配置不合理，会导致Kudu服务直接崩溃，建议根据官方的推荐来配置NTP，另外可以通过修改参数max_clock_sync_error_usec值，来提高Kudu对时间偏差的容忍程度

在Impala中对Kudu表进行alter table A rename to B，只会更改impala的元数据，而不会更改任何Kudu的元数据，可以通过，先修改Impala元数据alter table A rename to B 后，再修改Kudu元数据alter table A set TBLPROPERTIES(’kudu.table_name’=’B’)

没有Rebalance功能，需要手工来做balance

在Kudu1.6.0之前，如果tablet server的某个磁盘坏了，那么整个tablet server就要重新format了，如果你的集群版本大于等于1.6.0并且损坏的盘并非WAL/Meta盘，那么你可以通过kusu fs update_dirs的方式来更新数据盘信息后，正常启动tablet server