主键
- 表创建后，主键不能修改。必须删除重建表指定新的主键
- 主键列必须在非主键列之前
- 主键列的值不能使用UPDATE函数修改。如果要修改主键的值只能删除该行重新插入，并且该操作无法保持原子性；
- 主键的类型不支持DOUBLE、FLOAT、BOOL，并且主键必须是非空的(NOT NULL)；
- 不支持自动生成的主键（如自增列）
- 每行对应的主键存储单元(CELL)最大为16KB
列
- MySQL中的部分数据类型，如DECIMAL, CHAR, VARCHAR, DATE, ARRAY等不支持；
- 数据类型以及是否可为空等列属性不支持修改；
- 不能通过ALTER TABLE更改现有列的类型和是否可为空属性
- DECIMAL类型列的精度和规模不能通过ALTER TABLE进行修改（Kudu 1.7+才支持decimal类型）
- 表最多可以有300列。
表
- 表的副本数必须为奇数，最多为7。
- 备份数在设置后不可修改。
单元格
- 单个单元格的值在编码或压缩前不能大于64KB。
分区限制(分片限制)
- 只支持手动指定分区(分片)，自动分区(分片)不支持；
- 分片设定不支持修改，修改分片设定需要”建新表-导数据-删老表”操作；
- 表必须使用简单或复合主键手动分区。
- Range 分区可以在建表后添加或删除。
- 表中已有的数据无法重新自动分区。有一种解决方案，创建一个新表并制定新的分区，然后将旧表的数据插入新表。
- 失去大部分副本的tablet（比如三个副本中的一个）需要人工干预才能恢复。
集群管理
- 不支持机架感知。
- 不支持多数据中心。
- 不支持滚动重启。
服务器管理
- 生产部署时应该为tablet server分配至少4G内存，在接近数据和tablet的限制时，最好配置大于16G的内存。
- 预写日志（WAL）只能存储在磁盘上。
- 磁盘故障是无法容忍的，一旦检测到磁盘故障，tablet server就会崩溃。
- 无法恢复数据的磁盘需要格式化该tablet server的所有Kudu数据，然后才能重新启动。
- 无法添加或删除数据目录，必须对所有目录进行重新格式化以更改目录集。
- Tablet servers不能优雅地退役。
- 不能更改tablet servers的地址和端口。
- Kudu对时钟同步有严格的要求，一旦时钟不同步，Kudu的master和tablet server就会崩溃。
- Kudu发行版只在NTP中进行过测试，其他时钟同步程序不保证能正常工作。
规模
- 建议tablet server最多为100台。
- 建议master最多为3个。
- 建议每个tablet server存储的数据最大为4T（此处存疑，为何会有4T这么小的限制？）；
- 每个tablet server存储的tablets数量建议在1000以内；
- 每个表分片后的tablets存储在单个tablet server的最大数量为60。
- 建议的最大数据存储量为，复制和压缩后，每个tablet server 8TB。
- 建议每个tablet server管理的tablet为2000，包含tablet的副本。
- 在创建表时，每个Tablet server的每个表的最大tablet数为60。
基于以上限制，可以推测出一下内容：
Kudu中存储的总数据量建议为：tablet server总数单个tablet server的数据量=100*8TB=800TB，即Kudu不适用于存储PB级数据。
单个tablet的数据量建议为：单个tablet server的数据量/每个tablet server中tablet的总数=8TB/2000=4G。Kudu支持的压缩方式有LZ4, Snappy，或zlib。鉴于各种压缩算法的压缩比一般不超过50%，则每个tablet中的数据量在压缩前的大小建议应小于2G。
复制和备份
- kudu目前没有任何内置备份和恢复功能。建议用户在必要的时候使用spark或impala等工具导入或导出表。
其他使用限制
- Kudu被设计为分析的用途，如果单行中包含多个千字节的单元格，则可能会遇到问题。
- 主键有索引，不支持二级索引(Secondary indexes)。
- 不支持多行事务操作。
- 不支持外键等关系特性。
- 表名和列名必须为有效的UTF-8字符串，最大长度为256个字符。
- 删除一列并不会马上释放空间，需要执行Compaction操作，但是Compaction操作不支持手动执行；
- 删除表的操作会立刻释放空间。
其他已知的问题
- 如果Kudu master配置了-log_force_fsync_all选项、 tablet servers和客户端将经常超时，集群可能变得不可用。
- 如果一个tablet server 有大量的tablet，启动可能需要几分钟。建议将每台服务器的tablet数量限制在100或更少。在预拆分表时，请考虑这个限制。如果您注意到启动时间较慢，您可以在web UI中监视每个服务器的tablet数量。
- Kerberos身份验证在主机名中包含大写字母的主机上不能正常运行。
- 如果在krb5.conf中配置rdns = false，Kerberos身份验证将不能正常工作。
Kudu+Impala对我们意味着什么
Kudu+Impala为实时数据仓库存储提供了良好的解决方案。这套架构在支持随机读写的同时还能保持良好的Scan性能，同时其对Spark等流式计算框架有官方的客户端支持。这些特性意味着数据可以从Spark实时计算中实时的写入Kudu，上层的Impala提供BI分析SQL查询，对于数据挖掘和算法等需求可以在Spark迭代计算框架上直接操作Kudu底层数据。
Kudu相比Hbase有何优势，为什么？
Kudu在某些特性上和Hbase很相似，难免会放在一起比较。然而Kudu和Hbase有如下两点本质不同。
- Kudu的数据模型更像是传统的关系型数据库，Hbase是完全的no-sql设计，一切皆是字节。
- Kudu的磁盘存储模型是真正的列式存储，Kudu的存储结构设计和Hbase区别很大。
综合而言，纯粹的OLTP请求比较适合Hbase，OLTP与OLAP结合的请求适合Kudu。
Kudu是纯内存数据库吗？
Kudu不是纯内存数据库，Kudu的数据块分MemRowSet和DiskRowSet，大部分数据存储在磁盘上。
Kudu拥有自己的存储格式还是沿用Parquet的？
Kudu的内存存储采用的是行存储，磁盘存储是列存储，其格式和Parquet很相似，部分不相同的部分是为了支持随机读写请求。
compactions需要手动操作吗？
compactions被设计为Kudu自动后台执行，并且是缓慢分块执行，当前不支持手动操作。
Kudu支持过期自动删除吗？
不支持。Hbase支持该特性。
Kudu有和Hbase一样的局部热点问题吗？
现代的分布式存储设计往往会把数据按主键进行有序存储。这样会造成一些局部的热点访问，比如把时间作为主键的日志实时存储模型中，日志的写入总是在时间排序的最后，这在Hbase中会造成严重的局部热点。Kudu也有同样的问题，但是比Hbase好很多，Kudu支持hash分片，数据的写入会先按照hash找到对应的tablet，再按主键有序的写入。
Kudu在CAP理论中的位置？
和Hbase一样，Kudu是CAP中的CP。只要一个客户端写入数据成功，其他客户端读到的数据都是一致的，如果发生宕机，数据的写入会有一定的延时。
Kudu支持多个索引吗？
不支持，Kudu只支持Primary Key一个索引，但是可以把Primary Key设置为包含多列。自动增加的索引、多索引支持、外键等传统数据库支持的特性Kudu正在设计和开发中。
Kudu对事务的支持如何？
Kudu不支持多行的事务操作，不支持回滚事务，不过Kudu可以保证单行操作的原子性。
Kudu笔记
- KUDU分区数必须预先预定
- 在内存中对每个Tablet分区维护一个MemRowSet来管理最新更新的数据，默认是1G刷新一次或者是2分钟。后Flush到磁盘上形成DiskRowSet，多个DiskRowSet在适当的时候进行归并处理
- 和HBase采用的LSM（LogStructured Merge，很难对数据进行特殊编码，所以处理效率不高）方案不同的是，Kudu对同一行的数据更新记录的合并工作， 不是在查询的时候发生的（HBase会将多条更新记录先后Flush到不同的Storefile中，所以读取时需要扫描多个文件，比较rowkey，比较版本等，然后进行更新操作），而是在更新的时候进行，在Kudu中一行数据只会存在于一个DiskRowSet中，避免读操作时的比较合并工作。那Kudu是怎么做到的呢？ 对于列式存储的数据文件，要原地变更一行数据是很困难的，所以在Kudu中，对于Flush到磁盘上的DiskRowSet（DRS）数据，实际上是分两种形式存在的，一种是Base的数据，按列式存储格式存在，一旦生成，就不再修改，另一种是Delta文件，存储Base数据中有变更的数据，一个Base文件可以对应多个Delta文件，这种方式意味着，插入数据时相比HBase，需要额外走一次检索流程来判定对应主键的数据是否已经存在。因此，Kudu是牺牲了写性能来换取读取性能的提升。更新、删除操作需要记录到特殊的数据结构里，保存在内存中的DeltaMemStore或磁盘上的DeltaFIle里面。DeltaMemStore是B-Tree实现的，因此速度快，而且可修改。磁盘上的DeltaFIle是二进制的列式的块，和base数据一样都是不可修改的。因此当数据频繁删改的时候，磁盘上会有大量的DeltaFiles文件，Kudu借鉴了Hbase的方式，会定期对这些文件进行合并。
Kudu设计笔记
Kudu 1.9.0文档：https://kudu.apache.org/releases/1.9.0/docs/
Kudu 1.9.0 Java API文档：https://kudu.apache.org/releases/1.9.0/apidocs/
1.Kudu介绍：Kudu集HDFS的顺序读和HBASE的随机读于一身，同时具备高性能的随机写，以及很强大的可用性（单行事务，一致性协议），支持Impala spark计算引擎。
2.什么时候使用kudu
大规模数据复杂的实时分析，例如大数据量的join。
数据有更新
查询准实时
3.存储
Kudu的存储是不基于HDFS的，构建集群时，kudu很有可能和HDFS共同占用物理磁盘或者云磁盘，理想情况是独立空间。4.表设计
10+G a tablet
10-100 tablets individual node
在配置32C，64G机器上，跑过1000个tablet情况，能正常写入，但在大量查询情况下，出现tablet time out，rpc满了的情况，
5.分区设计
hash
range
6.参数
1、Kudu Tablet Server Maintenance Threads
参数：maintenance_manager_num_threads
解释：Kudu后台对数据进行维护操作，如写入数据时的并发线程数，一般设置为4，官网建议的是数据目录的3倍
Kudu Tablet Server Maintenance Threads 这个参数决定了Kudu后台对数据进行维护操作，如写入数据时的并发线程数。并发数越大，吞吐量越高，
但对集群计算能力的要求也越高。默认值为1，表示Kudu会采用单线程操作；对于需要大量数据进行快速写入/删除的集群，可以设置更大的值。
该值可以设置跟计算节点的数据磁盘数量和CPU核数有关，一般来说，建议设置为4以获取比较均衡的性能，最大不超过8。
2、Kudu Tablet Server Block Cache Capacity Tablet
参数：block_cache_capacity_mb
解释：分配给Kudu Tablet Server块缓存的最大内存量，建议是2-4G
Kudu Tablet Server Block Cache Capacity Tablet的Block buffer cache，根据集群内存配置和数据量规模设置。一般建议至少2GB～4GB。
3、Kudu Tablet Server Hard Memory Limit Kudu
参数：memory_limit_hard_bytes
解释：Tablet Server能使用的最大内存量，有多大，设置多大，tablet Server在批量写入数据时并非实时写入磁盘，而是先Cache在内存中，
在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。对于写入性能要求比较高的集群，建议设置更大的值（一般是机器内存的百分之80）
Kudu Tablet Server Hard Memory Limit Kudu的Tablet Server能使用的最大内存。Tablet Server在批量写入数据时并非实时写入磁盘，
而是先Cache在内存中，在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。对于写入性能要求比较高的集群，建议设置更大的值，比如32GB。
4.Maximum Process File Descriptors
这个参数决定了Kudu能够同时打开的操作系统文件数。不设置则使用系统的ulimits值，设置后会覆盖系统的设置。
需要根据集群的规模及并发处理能力，非常谨慎的设置这个值。
5.Default Number of Replicas
这个参数设置了每个Tablet的默认复制因子，默认值为3，表示每个表的数据会在Kudu中存储3份副本。
我们可以根据需要修改这个全局默认值，也可以在建表语句中通过’kudu.num_tablet_replicas’属性来设置每个表的副本数，
比如：’kudu.num_tablet_replicas’ = ‘1’。
7.建议每个表50columns左右，不能超过300个
8.hash分区数量 * range分区数量不能超过60个（1.7.0版本之后没限制了）
9.设置block的管理器为文件管理器（默认是日志服务器）
解释：并非所有文件系统格式都需要设置该选项。ext4、xfs格式支持hole punching（打孔），所以不需要设置block_manager=file，但是ext3 格式需要。
可以通过df -Th命令来查看文件系统的格式。
参数：--block_manager=file
10.设置ntp服务器的时间误差不超过20s（默认是10s）
参数：max_clock_sync_error_usec=20000000
11.设置rpc的连接时长（默认是3s，建议不要设置）
参数：--rpc_negotiation_timeout_ms=300000
12.设置rpc一致性选择的连接时长（默认为1s，建议不要设置）
参数：--consensus_rpc_timeout_ms=1000
13.记录kudu的crash的信息
解释：
Kudu在遇到崩溃时，使用Google Breakpad库来生成minidump。这些minidumps的大小通常只有几MB，即使禁用了核心转储生成，也会生成，
生成minidumps只能在Linux上建立。
minidump文件包含有关崩溃的进程的重要调试信息，包括加载的共享库及其版本，崩溃时运行的线程列表，处理器寄存器的状态和每个线程的堆栈内存副本，
以及CPU和操作系统版本信息。
Minitump可以通过电子邮件发送给Kudu开发人员或附加到JIRA，以帮助Kudu开发人员调试崩溃。为了使其有用，
开发人员将需要知道Kudu的确切版本和发生崩溃的操作系统。请注意，虽然minidump不包含堆内存转储，但它确实包含堆栈内存，
因此可以将应用程序数据显示在minidump中。如果机密或个人信息存储在群集上，请不要共享minidump文件。
参数：
--minidump_path=minidumps
--max_minidumps=9
（默认是在设置的log目录下生成minidumps目录，里边包含最多9个以dmp结尾的文件，无法设置为空值，需要注意的是如果自定义minidump文件，
在master不能启动的情况下，需要将该目录中的文件删除）
14.Stack WatchLog
解释：每个Kudu服务器进程都有一个称为Stack Watchdog的后台线程，它监视服务器中的其他线程，以防它们被阻塞超过预期的时间段。
这些跟踪可以指示操作系统问题或瓶颈存储。通过WARN日志信息的跟踪（Trace）可以用于诊断由于Kudu以下的系统（如磁盘控制器或文件系统）引起的根本原因延迟问题。
15.cdh设置多master
参数：--master_addresses=cdh01:7051,cdh02:7051cdh03:7051
16.kudu出现启动速度特别慢
解决办法：
1、取消所有配置参数（除了资源、时间同步）
2、升级版本到kudu1.6.0
3、client必须停止（client不占用io的情况，3台机器，每台机器60G，127分区数量，启动速度3分钟）
4、查看io使用情况 iostat -d -x -k 1 200
17.单hash分区最大是60
18.安装kudu过程中，会要求CPU支持ssc4.2指令集，但是我们的虚拟机cpu没有这个执行集，所以无法安装
19.设置client长连接过期时间
参数：--authn_token_validity_seconds=12960000（150天）
注意：设置到tserver的配置文件中
20.tserver和master的wal和data目录要分隔（或者是目录设置为lvm卷轴）
原因：wal目录只能设置为1个
参数：--fs_wal_dir_reserved_bytes
解释：
Number of bytes to reserve on the log directory filesystem for non-Kudu usage. The default,
which is represented by -1, is that 1% of the disk space on each disk will be reserved.
Any other value specified represents the number of bytes reserved and must be greater than or equal to 0.
Explicit percentages to reserve are not currently supported
用于非kudu都使用的日志目录文件系统的字节数，默认情况下是-1，每个磁盘上的磁盘空间的1%将被保留，指定的任何其他值表示保留的字节数，必须大于或等于0。
21.设置用户权限，能移动tablet
参数：--superuser_acl=*
22.tserver宕掉后，5分钟后没有恢复的情况下，该机器上的tablet会移动到其他机器
参数：--follower_unavailable_considered_failed_sec=300
23.超过参数时间的历史数据会被清理，如果是base数据不会被清理。而真实运行时数据大小持续累加，没有被清理。
参数：--tablet_history_max_age_sec=900
impala + kudu一些优化笔记
1.一开始需要全量导入kudu，这时候我们先用sqoop把关系数据库数据导入临时表，再用impala从临时表导入kudu目标表
由于sqoop从关系型数据直接以parquet格式导入hive会有问题，这里默认hive的表都是text格式；每次导完到临时表，
需要做invalidate metadata 表操作，不然后面直接导入kudu的时候会查不到数据
2.除了查询，建议所有impala操作都在impala-shell而不在hue上面执行
3.impala并发写入kudu的时候，数据量比较大的时候
这时候kudu配置参数 --memory_limit_hard_bytes能大点就大点，因为kudu写入首先保存再内存里面，到一定阀值才溢写到磁盘，这个是直接最能提高写的方法；
当然不是所有机器都有那么多资源，可以把--maintenance_manager_num_threads 这个参数稍微调大，需要调试，提高数据从内存写入磁盘的效率
4.impala查询kudu
首先所有表做完全量的etl操作，必须得执行compute stats 表名，不然impala执行sql生成的计划执行数评估的内存不准确，容易评估错误导致实际执行不了
kudu表最好不要做任何压缩，保证原始扫描性能发挥最好；假如对查询性能要求比存储要求高的话；大部分企业对实时查询效率要求高，而且存储成本毕竟低；
kudu针对大表要做好分区，最好range和hash一起使用，前提是主键列包含能hash的id，但range分区一定要做好，经验告诉我一般是基于时间；
查询慢的sql，一般要拿出来；方便的话做下explain，看下kudu有没有过滤部分数据关键字kudu predicates；假如sql没问题，那在impala-shell执行这个sql，
最后执行summray命令，重点查看单点峰值内存和时间比较大的点，对相关的表做优化，解决数据倾斜问题
5.kudu数据删除
大表不要delete，不要犹豫直接drop，在create吧；磁盘空间会释放的
6.关于impala + kudu 和 impala + parquet
网上很多分析impala + kudu 要比 impala + parquet 优越很多；谁信谁XB；
首先两个解决的场景不一样，kudu一般解决实时，hive解决的是离线（通常是T + 1或者 T -1）
hive基于hdfs，hdfs已经提供一套较为完善的存储机制，底层数据和文件操作便利；安全性，可扩展性都比kudu强很多，
最重要parquet + impala效率要比kudu高，数仓首选是它
kudu最大优势是能做类似关系型数据库一样的操作，insert, update, delete，这样热点的数据可以存储在kudu里面并随时做更新
7.最后谈到的实时同步工具
同步工具我们这里使用streamsets，一个拖拉拽的工具，非常好用；但内存使用率高，通过jconsole我们发现，所有任务同时启动；
JVM新生代的内容几乎都跑到老年代了，GC没来的及，就内存溢出了；后面单独拿几台服务器出来做这个ETL工具，jvm配置G1垃圾回收器
kudu的产生背景
1.在 kudu 之前，大数据主要以两种方式存储：
第一种是静态数据：以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。
这类存储的局限性是数据无法进行随机的读写和批量的更新操作。
第二种是动态数据：以 HBase作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS、不适用于批量数据分析的场景。
2.从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，
又需要批量分析的大数据场景，该如何选择呢？
3.这个场景中，单种存储引擎无法满足业务需求，我们需要通过多种大数据组件组合来满足这一需求，一个常见的方案是：
数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，我们定时（通常是 T+1 或者 T+H）将 HBase的 数据写成静态的文件（Parquet）
导入到 OLAP 引擎（HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景。
但他有如下缺点：
第一：架构复杂。从架构上看，数据在 HBase、消息队列Kafka、HDFS 间流转，涉及环节太多，运维成本很高。
并且每个环节需要保证高可用、维护多个副本、存储空间浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。
第二：时效性低。数据从 HBase 导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。
第三：难以应对后续的更新。真实场景中，总会有数据是延迟到达的。如果这些数据之前已经从 HBase 导出到 HDFS，
新到的变更数据就难以处理了，一个方案是把新变更的数据和原有数据进行对比，把不同的数据重新进行更新操作，这时候代价就很大了。
假如说，我们想要sql实时对大量数据进行分析该怎么办？或者是我想让数据存储能够支持Upsert（更新插入操作），又该怎么办？所以这就是kudu的优势。
kudu 的定位是 Fast Analytics on Fast Data，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。
4.KUDU在 HDFS 和 HBase 这两个中平衡了随机读写和批量分析的性能，既支持了SQL实时查询，也支持了数据更新插入操作。
完美的和impala集成，统一了hdfs数据源和kudu数据源，从而使得开发人员能够高效的进行数据分析。5.hdfs不支持批量更新操作，kudu支持
hdfs适用于离线sql分析，kudu适用于实时sql分析 hbase不支持sql操作，kudu支持（hbase-hive表可支持sql操作，但是效率极低）
hbase不支持结构化数据存储，kudu支持
hbase开发语言使用的java，内存的释放通过gc来完成，在内存比较紧张时可能引发full gc进而导致服务不稳定；kudu核心模块用的c++来实现，没有full gc的风险
hbase的timestamp是暴露的，kudu没有暴露
hbase的插入和更新操作都是当作一条数据进行处理的，而kudu是分隔开的
6.适合于在线实时分析的应用
适合大数据量更新操作的应用
适合将mysql的数据同步到kudu，减轻备库mysql查询的压力
适合存储ADS数据，包含用户标签、各类指标数据等
适合于存储结构化数据
适合于和Impala继承，SQL分析数据
适合于和HDFS一起使用，聚合数据源
实时预测模型的应用，支持根据所有历史数据周期地更新模型
7.kudu完美的和impala集成，统一了hdfs数据源和kudu数据源，从而使得开发人员能够高效的进行数据分析。
impala-kudu 主要用于实时的分析海量数据，即海量的结构化数据不断更新到kudu中，底层是以列式结构分布式存储，查询是获取结构化数据，
然后进行 OLAP 分析、数据挖掘、机器学习等分析型操作，这些分析型操作所涉及的数据延迟性很小。
但是kudu对硬件资源要求很高，特别是IO这块，之前公司遇到的集群瓶颈是多台机器（写30m/s）IO使用率达到100%，从而使用rpc连接超时，导致数据丢失。
impala-kudu 的应用适用于多个行业，凡是结构化数据分析的情景都可使用，从实时性方面来讲，使用sql实时的查询结构化数据，使得分析操作快速和高效。
从离线方面来讲，可以查询hdfs的数据，从而保证了数据的统一化和多元化，并且有利于构建数据仓库模型。
kudu的基础架构
1.Kudu特点
特点一：主从架构 主为master，从为tserver，通常为三主多从
特点二：高可用性（High availability）
Tablet server 和 Master 使用 Raft Consensus Algorithm 来保证节点的高可用，确保只要有一半以上的副本可用，
该 tablet 便可用于读写。例如，如果3个副本中有2个可用 或 5个副本中的有3个可用，则该tablet可用。即使在 leader tablet 出现故障的情况下，
读取功能也可以通过 read-only（只读的）follower tablets来进行服务，或者是leader宕掉的情况下，会根据raft机制重新选举leader
特点三：水平可扩展
特点四：OLAP 工作的快速处理。
特点五：与 MapReduce，Spark ，Impala和其他 Hadoop 生态系统组件集成
特点六：使用 Cloudera Manager 轻松维护和管理
特点七：底层存储完全是列式结构，每一列都可以自定义压缩
特点八：查询出来的数据是结构化模型，支持sql操作
2.Kudu概念和术语
1.开发语言 C++
2.Columnar Data Store（列式数据存储）
3.Read Efficiency（高效读取）
对于分析查询，允许读取单个列或该列的一部分同时忽略其他列
4.Data Compression（数据压缩）
由于给定的列只包含一种类型的数据，所以基于此模式的压缩会比压缩混合数据类型（在基于行的解决案中使用）时更有效几个数量级。
结合从列读取数据的效率，压缩允许从磁盘读取更少的块时完成查询5.Table（表）
一张table是数据存储在 Kudu 的位置。表具有schema（结构）和全局有序的primary key（主键）。table被分成很多段，也就是称为tablets（Tablet的复数）
6.Tablet（段）
一个tablet 是 一张表table 连续的segment（段），与其它数据存储引擎或关系型数据库partition（分区）相似。
在一定的时间范围内，tablet的副本冗余到多个tserver服务器上，其中一个副本被认为是leader tablet。
任何副本都可以对读取进行服务，并且写入时需要为tablet服务的一组tablet server之间达成一致性。
一张表分成多个tablet，分布在不同的tablet server中，最大并行化操作，Tablet在Kudu中被切分为更小的单元，叫做RowSets，
RowSets分为两种MemRowSets和DiskRowSet，MemRowSets每生成32M，就溢写到磁盘中，也就是DiskRowSet
7.Tablet Server
tablet server是 存储tablet 和 为tablet向client提供服务。对于给定的tablet，一个tablet server充当 leader，
其他tablet server充当该tablet的follower副本。只有leader为每一个服务提供写请求，leader和followers为每个服务提供读请求。
leader使用Raft协议来进行选举 。一个tablet server可以服务多个tablets，并且一个 tablet 可以被多个tablet servers服务着。
8.Master
保持跟踪所有的tablets、tablet servers、catalog tables（目录表）和其它与集群相关的metadata。在给定的时间点，只能有一个起作用的master（也就是 leader）。
如果当前的leader消失，则选举出一个新的master，使用Raft协议来进行选举。master还协调客户端的metadata operations（元数据操作）。
例如，当创建新表时，客户端内部将请求发送给master。 master将新表的元数据写入catalog table（目录表），并协调在tablet server上创建tablet的过程。
所有master的元数据都存储在一个tablet中，可以复制到所有其他候选的master。tablet server以设定的间隔向master发出心跳（默认值为每秒一次）。
master是以文件的形式存储在磁盘中。
9.Raft Consensus Algorithm
Kudu 使用 Raft consensus algorithm 作为确保常规 tablet 和 master 数据的容错性和一致性的手段。
通过 Raft协议，tablet 的多个副本选举出 leader，它负责接受请求和复制数据写入到其他follower副本。
一旦写入的数据在大多数副本中持久化后，就会向客户确认。给定的一组N副本（通常为 3 或 5 个）能够接受最多(N - 1)/2 错误的副本的写入。
10.Catalog Table（目录表）
catalog table是Kudu 的 metadata（元数据中）的中心位置。它存储有关tables和tablets的信息。
该catalog table（目录表）可能不会被直接读取或写入。相反，它只能通过客户端 API中公开的元数据操作访问。
catalog tables存储以下两类元数据。
Tables：table schemas 表结构，locations 位置，states 状态
Tablets：现有tablet 的列表，每个 tablet 的副本所在哪些tablet server，tablet的当前状态以及开始和结束的keys（键）。
Kudu-Impala 集成特性
1. CREATE/ALTER/DROP TABLE
Impala 支持使用 Kudu 作为持久层来 creating（创建），altering（修改）和 dropping（删除）表。
这些表遵循与 Impala 中其他表格相同的 Internal / external（内部 / 外部）方法，允许灵活的数据采集和查询。
2.INSERT
数据可以使用“与那些使用 HDFS 或 HBase 持久性的任何其他 Impala 表相同的”语法插入 Impala 中的 Kudu 表。
3.UPDATE / DELETE
Impala 支持 UPDATE 和 DELETE SQL 命令逐行或批处理修改 Kudu 表中的已有的数据。
选择 SQL 命令的语法与现有标准尽可能兼容。除了简单 DELETE 或 UPDATE 命令之外，还可以 FROM 在子查询中指定带有子句的复杂连接。
Flexible Partitioning（灵活分区）
与 Hive 中的表分区类似，Kudu 允许您通过 hash 或 range 动态预分割成预定义数量的 tablets，以便在集群中均匀分布写入和查询。
您可以通过任意数量的 primary key（主键）列，任意数量的 hashes 和可选的 list of split rows 来进行分区。
4. Parallel Scan（并行扫描）
为了在现代硬件上实现最高的性能，Impala 使用的 Kudu 客户端可以跨多个 tablets扫描。
5. High-efficiency queries（高效查询）
在可能的情况下，Impala 将谓词评估下推到 Kudu，以便使谓词（in，between and，>，<）评估为尽可能接近数据。在许多任务中，查询性能与 Parquet 相当。
扫一扫
2360
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
