kuda 了解片

原本上个月想去了解一下kuda的，结果一直没有抽出时间去搞，如今大体先开个头，方便后面深刻！

 

Apache Kudu是开源Apache Hadoop生态系统的新成员，它完善了Hadoop的存储层，能够 快速分析快速数据。

Kudu提供快速插入/更新和高效柱状扫描的组合，以在单个存储层上实现多个实时分析工做负载。做为HDFS和Apache HBase的新补充，Kudu使架构师可以灵活地处理各类用例，而无需异乎寻常的解决方法。

Kudu专为须要快速（快速变化）数据快速分析的用例而设计。Kudu专为利用下一代硬件和内存处理而设计，可显着下降Apache Impala（孵化）和Apache Spark（最初与其余执行引擎）的查询延迟。

 

Kudu和Impala均是Cloudera贡献给Apache基金会的顶级项目。

 

以前一直是 hdfs+Parquet+hive+impala

如今不少厂有用kuda+impala(或其余), 

去百度一番，快速了解一下。

 

kuda大体了解 

Kudu做为底层存储，在支持高并发低延迟kv查询的同时，还保持良好的Scan性能，该特性使得其理论上可以同时兼顾OLTP类和OLAP类查询。

Impala做为老牌的SQL解析引擎，其面对即时快速查询(Ad-Hoc Query)类请求的稳定性和速度在工业界获得过普遍的验证，Impala并无本身的存储引擎，其负责解析SQL，并链接其底层的存储引擎。在发布之初Impala主要支持HDFS，Kudu发布以后，Impala和Kudu更是作了深度集成。

在众多大数据框架中，Impala定位相似Hive，不过Impala更关注即席查询SQL的快速解析，对于执行时间过长的SQL，仍旧是Hive更合适。

对于GroupBy等SQL查询，Impala进行的是内存计算，于是Impala对机器配置要求较高，官方建议内存128G以上，此类问题Hive底层对应的是传统的MapReduce计算框架，虽然执行效率低，可是稳定性好，对机器配置要求也低。

执行效率是Impala的最大优点，对于存储在HDFS中的数据，Impala的解析速度原本就远快于Hive，有了Kudu加成以后，会是如虎添翼，部分查询执行速度差异可达百倍。

值得注意的是，Kudu和Impala的英文原意是来自非洲的两个不一样品种的羚羊，Cloudera这个公司很是喜欢用跑的快的动物来做为其产品的命名。

 

Kudu的典型使用场景

流式实时计算场景

流式计算场景一般有持续不断地大量写入，与此同时这些数据还要支持近乎实时的读、写以及更新操做。Kudu的设计可以很好的处理此场景。

时间序列存储引擎(TSDB)

Kudu的hash分片设计可以很好地避免TSDB类请求的局部热点问题。同时高效的Scan性能让Kudu可以比Hbase更好的支持查询操做。

机器学习&数据挖掘

机器学习和数据挖掘的中间结果每每须要高吞吐量的批量写入和读取，同时会有少许的随机读写操做。Kudu的设计能够很好地知足这些中间结果的存储需求。

与历史遗产数据共存

在工业界实际生产环境中，每每有大量的历史遗产数据。Impala能够同时支持HDFS、Kudu等多个底层存储引擎，这个特性使得在使用的Kudu的同时，没必要把全部的数据都迁移到Kudu。

 

Kudu中的重要概念

列式存储

毫无疑问，Kudu是一个纯粹的列式存储引擎，相比Hbase只是按列存放数据，Kudu的列式存储更接近于Parquet，在支持更高效Scan操做的同时，还占用更小的存储空间。列式存储有如此优点，主要由于两点：1. 一般意义下的OLAP查询只访问部分列数据，列存储引擎在这种状况下支持按需访问，而行存储引擎则必须检索一行中的全部数据。2. 数据按列放一块儿通常意义来说会拥有更高的压缩比，这是由于列相同的数据每每拥有更高的类似性。

Table

Kudu中全部的数据均存储在Table之中，每张表有其对应的表结构和主键，数据按主键有序存储。由于Kudu设计为支持超大规模数据量，Table之中的数据会被分割成为片断，称之为Tablet。

Tablet

一个Tablet把相邻的数据放在一块儿，跟其余分布式存储服务相似，一个Tablet会有多个副本放置在不一样的服务器上面，在同一时刻，仅有一个Tablet做为leader存在，每一个副本都可单独提供读操做，写操做则须要一致性同步写入。

Tablet Server

Tablet服务顾名思义，对Tablet的读写操做会经过该服务完成。对于一个给定的tablet，有一个做为leader，其余的做为follower，leader选举和灾备原则遵循Raft一致性算法，该算法在后文中有介绍。须要注意的是一个Tablet服务所能承载的Tablet数量有限，这也要求的Kudu表结构的设计须要合理的设置Partition数量，太少会致使性能下降，太多会形成过多的Tablet,给Tablet服务形成压力。

Master

master存储了其余服务的全部元信息，在同一时刻，最多有一个master做为leader提供服务，leader宕机以后会按照Raft一致性算法进行从新选举。

master会协调client传来的元信息读写操做。好比当建立一个新表的时候，client发送请求给master，master会转发请求给catelog、 tablet等服务。

master自己并不存储数据，数据存储在一个tablet之中，而且会按照正常的tablet进行副本备份。

Tablet服务会每秒钟跟master进行心跳链接。

Raft Consensus Algorithm

Kudu 使用Raft一致性算法，该算法将节点分为follower、candidate、leader三种角色，当leader节点宕机时，follower会成为candidate而且经过多数选举原则成为一个新的leader，由于有多数选举原则，因此在任意时刻，最多有一个leader角色。leader接收client上传的数据修改指令而且分发给follower，当多数follower写入时，leader会认为写入成功并告知client。

Catalog Table

Catelog表存储了Kudu的一些元数据，包括Tables和Tablets。（catalog table）目录表可能没法直接读取或写入。相反，它只能经过客户端API中公开的元数据操做访问。

Tables:table schemas, locations, and states

Tablets:the list of existing tablets, which tablet servers have replicas of each tablet, the tablet’s current state, and start and end keys.

Logical replication

Logical Replication(逻辑复制)

Kudu复制操做，而不是磁盘数据。这称为逻辑复制，而不是物理复制。这有几个好处：

• 尽管插入和更新确实经过网络传输数据，但删除操做不须要移动任何数据。删除操做将发送到每一个tablet server(服务器)，该服务器在本地执行删除。

• 物理操做（例如压缩）不须要在Kudu中经过网络传输数据。这与使用HDFS的存储系统不一样，后者须要经过网络传输块以知足所需数量的副本。

• tables不须要同时或在相同的时间表上执行压缩，或者在物理存储层上保持同步。因为压缩或大量写入负载，这下降了全部tables(平板电脑)服务器同时遇到高延迟的可能性。

Kudu架构概览

从下图能够看出有三台Master，其中一个是leader，另外两个是follower。

有四台Tablet server，n个tablets及其副本均匀分布在这四台机器上。每一个tablet有一个leader，两个follower。每一个表会按照分片的数量分红多个tablet。

leader以黄金显示，而follower以蓝色显示。

 

 

Kudu+Impala对咱们意味着什么

Kudu+Impala为实时数据仓库存储提供了良好的解决方案。这套架构在支持随机读写的同时还能保持良好的Scan性能，同时其对Spark等流式计算框架有官方的客户端支持。这些特性意味着数据能够从Spark实时计算中实时的写入Kudu，上层的Impala提供BI分析SQL查询，对于数据挖掘和算法等需求能够在Spark迭代计算框架上直接操做Kudu底层数据。

Kudu-Impala集成功能

CREATE/ALTER/DROP TABLE

Impala支持使用Kudu做为持久层建立，更改和删除表。这些表遵循与Impala中其余表相同的内部/外部方法，容许灵活的数据提取和查询。

INSERT

可使用与任何其余Impala表相同的语法将数据插入Impala中的Kudu表，例如使用HDFS或HBase进行持久化的表。

UPDATE / DELETE

Impala支持UPDATE和DELETESQL命令逐行或批量修改Kudu表中的现有数据。选择SQL命令的语法与现有标准尽量兼容。除了simple DELETE 或UPDATE命令以外，还可使用FROM子查询中的子句指定复杂链接。

灵活的分区

与Hive中的表分区相似，Kudu容许您经过散列或范围动态地将表预分割为预约义数量的平板电脑，以便在集群中均匀分配写入和查询。您能够按任意数量的主键列，任意数量的哈希值和可选的拆分行列表进行分区。请参阅架构设计。

并行扫描

为了在现代硬件上实现最高性能，Impala使用的Kudu客户端在多个平板电脑上并行扫描。

高效查询

在可能的状况下，Impala将谓词评估推送到Kudu，以便尽量接近数据评估谓词。在许多工做负载中，查询性能与Parquet至关。

有关使用Impala查询存储在Kudu中的数据的更多详细信息，请参阅Impala文档。

 

 

Spark集成最佳实践

每个群集避免多个Kudu客户端。

一个常见的Kudu-Spark编码错误是实例化额外的KuduClient对象。在kudu-spark中，a KuduClient属于KuduContext。Spark应用程序代码不该建立另外一个KuduClient链接到同一群集。相反，应用程序代码应使用KuduContext访问KuduClient使用KuduContext#syncClient。

要诊断KuduClientSpark做业中的多个实例，请查看主服务器的日志中的符号，这些符号会被来自不一样客户端的许多GetTableLocations或 GetTabletLocations请求过载，一般大约在同一时间。这种症状特别适用于Spark Streaming代码，其中建立KuduClient每一个任务将致使来自新客户端的主请求的周期性波。

 

Spark集成已知问题和限制

• Spark 2.2+在运行时须要Java 8，即便Kudu Spark 2.x集成与Java 7兼容。Spark 2.2是Kudu 1.5.0的默认依赖版本。

• 当注册为临时表时，必须为名称包含大写或非ascii字符的Kudu表分配备用名称。

• 包含大写或非ascii字符的列名的Kudu表不能与SparkSQL一块儿使用。能够在Kudu中重命名列以解决此问题。

• <>而且OR谓词不会被推送到Kudu，而是由Spark任务进行评估。只有LIKE带有后缀通配符的谓词才会被推送到Kudu，这意味着它LIKE "FOO%"被推下但LIKE "FOO%BAR"不是。

• Kudu不支持Spark SQL支持的每种类型。例如， Date不支持复杂类型。

• Kudu表只能在SparkSQL中注册为临时表。使用HiveContext可能没法查询Kudu表。

 

 

Kudu以及Impala的不足

Kudu主键的限制

• 表建立后主键不可更改；
• 一行对应的主键内容不能够被Update操做修改。要修改一行的主键值，须要删除并新增一行新数据，而且该操做没法保持原子性；
• 主键的类型不支持DOUBLE、FLOAT、BOOL，而且主键必须是非空的(NOT NULL)；
• 自动生成的主键是不支持的；
• 每行对应的主键存储单元(CELL)最大为16KB。

Kudu列的限制

• MySQL中的部分数据类型，如DECIMAL, CHAR, VARCHAR, DATE, ARRAY等不支持；
• 数据类型以及是否可为空等列属性不支持修改；
• 一张表最多有300列。

Kudu表的限制

• 表的备份数必须为奇数，最大为7；
• 备份数在设置后不可修改。

Kudu单元（Cells）的限制

• 单元对应的数据最大为64KB，而且是在压缩前。

Kudu分片的限制

• 分片只支持手动指定，自动分片不支持；
• 分片设定不支持修改，修改分片设定须要”建新表-导数据-删老表”操做；
• 丢掉多数备份的Tablets须要手动修复。

Kudu容量限制

• 建议tablet servers的最大数量为100；
• 建议masters的最大数量为3；
• 建议每一个tablet server存储的数据最大为4T（此处存疑，为什么会有4T这么小的限制？）；
• 每一个tablet server存储的tablets数量建议在1000之内；
• 每一个表分片后的tablets存储在单个tablet server的最大数量为60。

Kudu其余使用限制

• Kudu被设计为分析的用途，每行对应的数据太大可能会碰到一些问题；
• 主键有索引，不支持二级索引(Secondary indexes)；
• 多行的事务操做不支持；
• 关系型数据的一些功能，如外键，不支持；
• 列和表的名字强制为UTF-8编码，而且最大256字节；
• 删除一列并不会立刻释放空间，须要执行Compaction操做，可是Compaction操做不支持手动执行；
• 删除表的操做会马上释放空间。

Impala的稳定性

• Impala不适合超长时间的SQL请求；
• Impala不支持高并发读写操做，即便Kudu是支持的；
• Impala和Hive有部分语法不兼容。

FAQ

Impala支持高并发读写吗？

不支持。虽然Impala设计为BI-即席查询平台，可是其单个SQL执行代价较高，不支持低延时、高并发场景。

Impala能代替Hive吗？

不能，Impala设计为内存计算模型，其执行效率高，可是稳定性不如Hive，对于长时间执行的SQL请求，Hive仍然是第一选择。

Impala须要多少内存？

相似于Spark，Impala会把数据尽量的放入内存之中进行计算，虽然内存不够时，Impala会借助磁盘进行计算，可是毫无疑问，内存的大小决定了Impala的执行效率和稳定性。Impala官方建议内存要至少128G以上，而且把80%内存分配给Impala

Impala有Cache吗？

Impala不会对表数据Cache，Impala仅仅会Cache一些表结构等元数据。虽然在实际状况下，一样的query第二次跑可能会更快，但这不是Impala的Cache，这是Linux系统或者底层存储的Cache。

Impala能够添加自定义函数吗？

能够。Impala1.2版本支持的UDFs，不过Impala的UDF添加要比Hive复杂一些。

Impala为何会这么快？

Impala为速度而生，其在执行效率细节上作了不少优化。在大的方面，相比Hive，Impala并无采用MapReduce做为计算模型，MapReduce是个伟大的发明，解决了不少分布式计算问题，可是很遗憾，MapReduce并非为SQL而设计的。SQL在转换成MapReduce计算原语时，每每须要多层迭代，数据须要较多的落地次数，形成了极大地浪费。

• Impala会尽量的把数据缓存在内存中，这样数据不落地便可完成SQL查询，相比MapReduce每一轮迭代都落地的设计，效率获得极大提高。
• Impala的常驻进程避免了MapReduce启动开销，MapReduce任务的启动开销对于即席查询是个灾难。
• Impala专为SQL而设计，能够避免每次都把任务分解成Mapper和Reducer，减小了迭代的次数，避免了没必要要的Shuffle和Sort。

同时Impala现代化的计算框架，可以更好的利用现代的高性能服务器。

• Impala利用LLVM生成动态执行的代码
• Impala会尽量的利用硬件配置，包括SSE4.1指令集去预取数据等等。
• Impala会本身控制协调磁盘IO，会精细的控制每一个磁盘的吞吐，使得整体吞吐最大化。
• 在代码效率层面上，Impala采用C++语言完成，而且追求语言细节，包括内联函数、内循环展开等提速技术
• 在程序内存使用上，Impala利用C++的自然优点，内存占用比JVM系语言小太多，在代码细节层面上也遵循着极少内存使用原则，这使得能够空余出更多的内存给数据缓存。

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能够保证单行操做的原子性。

 

Example Use Cases

具备近实时可用性的流输入

数据分析中的一个常见挑战是新数据快速且持续地到达，而且须要几乎实时地提供相同的数据以进行读取，扫描和更新。Kudu提供快速插入和更新的强大组合，以及高效的柱状扫描，以在单个存储层上实现实时分析用例。

具备普遍变化的访问模式的时序应用程序

时间序列模式是根据数据点发生的时间组织和键入数据点的模式。这对于随时间调查指标的性能或尝试根据过去的数据预测将来行为很是有用。例如，时间序列客户数据可用于存储购买点击流历史记录和预测将来购买，或供客户支持表明使用。虽然这些不一样类型的分析正在发生，但插入和突变也可能单独和大量发生，而且可当即用于读取工做负载。Kudu能够以可扩展且高效的方式同时处理全部这些访问模式。

因为多种缘由，Kudu很是适合时间序列工做负载。因为Kudu支持基于散列的分区，结合其对复合行密钥的本机支持，能够很容易地设置跨多个服务器的表，而不会出现使用范围分区时常见的“热点”风险。Kudu的柱状存储引擎在这种状况下也颇有用，由于许多时间序列工做负载只读取几列，而不是整行。

过去，您可能须要使用多个数据存储来处理不一样的数据访问模式。这种作法增长了应用程序和操做的复杂性，并使数据重复，使所需的存储量翻倍（或更差）。Kudu能够本地高效地处理全部这些访问模式，而无需将工做卸载到其余数据存储。

预测建模

数据科学家常常从大量数据集开发预测性学习模型。当学习发生或建模的状况发生变化时，可能须要常常更新或修改模型和数据。此外，科学家可能想要改变模型中的一个或多个因素，看看随着时间的推移会发生什么。更新存储在HDFS中的文件中的大量数据是资源密集型的，由于每一个文件都须要彻底重写。在Kudu，更新几乎是实时发生的。科学家能够调整值，从新运行查询，并在几秒或几分钟内刷新图表，而不是几小时或几天。此外，批处理或增量算法能够随时在数据上运行，并具备接近实时的结果。

将Kudu中的数据与遗留系统(RDBMS,HDFS)相结合,用impala访问查询，无需该旧系统

 

 

 

其余补充：

1.参考 kuda的官网： https://kudu.apache.org/overview.html#architecture

2.OLTP(On-line Transaction Processing) 面向的是高并发低延时的增删改查(INSERT, DELETE, UPDATE, SELECT, etc..)。

OLAP(On-line Analytical Processing) 面向的是BI分析型数据请求，其对延时有较高的容忍度，处理数据量相较OLTP要大不少。

传统意义上与OLTP对应的是MySQL等关系型数据库，与OLAP相对应的则是数据仓库。OLTP与OLAP所面向的数据存储查询引擎是不一样的，其处理的请求不同，所须要的架构也大不相同。这个特色意味着数据须要储存在至少两个地方，须要按期或者实时的同步，同时还须要保持一致性，该特色对数据开发工程师形成了极大的困扰，浪费了同窗们大量的时间在数据的同步和校验上。Kudu+Impala的出现，虽然不能完美的解决这个问题，但不能否认，其缓解了这个矛盾。

在此须要注意的是OLTP并无严格要求其事务处理知足ACID四个条件。事实上，OLTP是比ACID更早出现的概念。在本文中，OLTP和OLAP的概念关注在数据量、并发量、延时要求等方面，不关注事务。