大数据存储技术之KUDU学习总结/快速入门

KUDU学习总结

1 基础概念

官方：https://kudu.apache.org/
在 KUDU 之前，大数据主要以两种方式存储：

• 静态数据：以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。

• 动态数据：以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。

从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？这个场景中，单种存储引擎无法满足业务需求，我们需要通过多种大数据工具组合来满足这一需求，一个常见的方案是：

如上图所示，数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，我们定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但他有如下缺点：

• 架构复杂。从架构上看，数据在 HBase、消息队列、HDFS 间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。

• 时效性低。数据从 HBase 导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。

• 难以应对后续的更新。真实场景中，总会有数据是「延迟」到达的。如果这些数据之前已经从 HBase 导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。为了解决上述架构的这些问题，KUDU 应运而生。KUDU 的定位是 「Fast Analytics on Fast Data」，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。

2 KUDU基础

2.1 使用场景

适用于那些既有随机访问，也有批量数据扫描的复合场景、高计算量的场景、使用了高性能的存储设备，包括使用更多的内存、支持数据更新，避免数据反复迁移、支持跨地域的实时数据备份和查询。

与HDFS和HBase相似，Kudu使用单个的Master节点，用来管理集群的元数据，并且使用任意数量的Tablet Server（可对比理解HBase中的RegionServer角色）节点用来存储实际数据。可以部署多个Master节点来提高容错性。一个table表的数据，被分割成1个或多个Tablet，Tablet被部署在Tablet Server来提供数据读写服务。
一些基本概念：
1 Master：集群中的老大，负责集群管理、元数据管理等功能

2 Tablet Server: 集群中的小弟，负责数据存储，并提供数据读写服务。一个 tablet server 存储了table表的tablet 和为 tablet 向 client 提供服务。对于给定的 tablet，一个tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。只有 leader服务写请求，然而 leader 或 followers 为每个服务提供读请求 。一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着。
3 Table(表)：一张table是数据存储在Kudu的tablet server中。表具有 schema 和全局有序的primary key（主键）。table 被分成称为 tablets 的 segments。

4 Tablet：一个 tablet 是一张 table连续的segment，tablet是kudu表的水平分区，类似于google Bigtable的tablet，或者HBase的region。每个tablet存储着一定连续range的数据（key），且tablet两两间的range不会重叠。一张表的所有tablet包含了这张表的所有key空间。与其它数据存储引擎或关系型数据库中的 partition（分区）相似。给定的tablet 冗余到多个 tablet 服务器上，并且在任何给定的时间点，其中一个副本被认为是leader tablet。任何副本都可以对读取进行服务，并且写入时需要在为 tablet 服务的一组 tablet server之间达成一致性。

2.2数据存储结构

一张表会分成若干个tablet，每个tablet包括MetaData元信息及若干个RowSet，RowSet包含一个MemRowSet及若干个DiskRowSet，DiskRowSet中包含一个BloomFile、Ad_hoc Index、BaseData、DeltaMem及若干个RedoFile和UndoFile（UndoFile一般情况下只有一个）。

• MemRowSet：用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。每次到达32M生成一个DiskRowSet。

• DiskRowSet：用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。

• BloomFile：根据一个DiskRowSet中的key生成一个bloom filter，用于快速模糊定位某个key是否在DiskRowSet中存在。

• Ad_hocIndex：是主键的索引，用于定位key在DiskRowSet中的具体哪个偏移位置。

• BaseData是MemRowSet flush下来的数据，按列存储，按主键有序。

• UndoFile是基于BaseData之前时间的历史数据，通过在BaseData上apply UndoFile中的记录，可以获得历史数据。

• RedoFile是基于BaseData之后时间的变更（mutation）记录，通过在BaseData上apply RedoFile中的记录，可获得较新的数据。

• DeltaMem用于DiskRowSet中数据的变更mutation，先写到内存中，写满后flush到磁盘形成RedoFile。

安装部署完之后的kudu页面

2.3 kudu语法示例

建表语句：

CREATE TABLE pk_inline
(
col1 BIGINT PRIMARY KEY,
col2 STRING,
col3 BOOLEAN
) PARTITION BY HASH(col1) PARTITIONS 2 STORED AS KUDU
TBLPROPERTIES (
    'kudu.num_tablet_replicas' = '1'
);

3 表设计

kudu的表具有类似于传统RDBMS中的表的数据结构。schema设计对于实现Kudu的最佳性能和操作稳定性至关重要。业务场景的多变，对于table来说并不存在一种最好的schema设计。大部分情况下，创建kudu的表需要考虑三个问题：
• 列的设计(column design)
• 主键设计(primary key design)
• 分区设计(partitioning design)
比较好的Schema设计应该满足一下要求：

1. 数据的分布和存储的方式满足：读取和写入操作都可以均匀的分散到tablet servers上(受分区影响)
2. tablet将以均匀，可预测的速度增长，并且tablet server的负载将随着时间的推移保持稳定(受分区影响最大)
3. 扫描将读取完成查询所需的最少数据量。(这主要受主键设计的影响，但分区也通过分区修剪发挥作用)

4 kudu安装

基于centos

4.1 安装各种依赖

sudo yum install autoconf automake cyrus-sasl-devel cyrus-sasl-gssapi \
  cyrus-sasl-plain flex gcc gcc-c++ gdb git java-1.8.0-openjdk-devel \
  krb5-server krb5-workstation libtool make openssl-devel patch \
  pkgconfig redhat-lsb-core rsync unzip vim-common which

2 centos版本7以上，执行以下操作

$ DTLS_RPM=rhscl-devtoolset-3-epel-6-x86_64-1-2.noarch.rpm
$ DTLS_RPM_URL=https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-6-x86_64/noarch/${DTLS_RPM}
$ wget ${DTLS_RPM_URL} -O ${DTLS_RPM}
$ sudo yum install -y scl-utils ${DTLS_RPM}
$ sudo yum install -y devtoolset-3-toolchain

3 执行如下命令

sudo yum install memkind
$ sudo yum install numactl-libs numactl-devel
$ git clone https://github.com/memkind/memkind.git
$ cd memkind
$ ./build.sh --prefix=/usr
$ sudo yum remove memkind
$ sudo make install
$ sudo ldconfig

4

$ sudo yum install doxygen gem graphviz ruby-devel zlib-devel

5 从git仓库克隆

$ git clone https://github.com/apache/kudu $ cd kudu

6

$ build-support/enable_devtoolset.sh thirdparty/build-if-necessary.sh

7

mkdir -p build/release cd build/release ../../build-support/enable_devtoolset.sh \ ../../thirdparty/installed/common/bin/cmake \ -DCMAKE_BUILD_TYPE=release ../.. make -j4

8 make之后选择一个启动方式启动kudu

sudo make install installs the following:
•	kudu-tserver and kudu-master executables in /usr/local/sbin
•	Kudu command line tool in /usr/local/bin
•	Kudu client library in /usr/local/lib64/
•	Kudu client headers in /usr/local/include/kudu