Kudu 是什么 

Kudu是Todd Lipcon@Cloudera带头开发的存储系统,其整体应用模式和HBase比较接近,即支持行级别的随机读写,并支持批量顺序检索功能。

那既然有了HBase,为什么还需要Kudu呢,简单的说,就是嫌弃HBase在OLAP场合,SQL/MR类的批量检索场景中,性能不够好。通常这种海量数据OLAP场景,要不走预处理的路,比如像EBAY麒麟这样走Cube管理的,或者像谷歌Mesa这样按业务需求走预定义聚合操作。再有就是自己构建数据通道,串接实时和批量处理两种系统,发挥各自的特长。

但是OLAP是个复杂的问题,场景众多,必然不可能有完美的通用解决方案,Kudu定位于应对快速变化数据的快速分析型数据仓库,希望靠系统自身能力,支撑起同时需要高吞吐率的顺序和随机读写的应用场景(可能的场景,比如时间序列数据分析,日志数据实时监控分析),提供一个介于HDFS和HBase的性能特点之间的一个系统,在随机读写和批量扫描之间找到一个平衡点,并保障稳定可预测的响应延迟

那为什么不能想办法改进HBase呢?Todd自己做为HBase的重要贡献者之一,没有选择这条路,自然是因为任何系统设计时都有Tradeoff,基于HBase的设计思想很难实现Kudu所定位的目标

相关链接

  • http://getkudu.io/

## == 核心思想 ==

### 数据模型:

数据模型定义上,Kudu管理的是类似关系型数据库的结构化的表,表结构由类Sql的Schema进行定义,相比于HBase这样的NoSql类型的数据库,Kudu的行数据是由固定个数有明确类型定义的列组成,并且需要定义一个由一个或多个列组成的主键来对每行数据进行唯一索引,相比于传统的关系型数据库,kudu在索引上有更多的限制,比如暂时不支持二级索引,不支持主键的更新等等。

尽管表结构类似于关系型数据库,但是Kudu自身并不提供SQL类型的语法接口,而是由上层其他系统实现,比如目前通过Impala提供SQL语法支持。

Kudu底层API,主要面对简单的更新检索操作,Insert/Update/Delete等必须指定一个主键进行,而Scan检索类型的操作则支持条件过滤和投影等能力。

### 集群架构:

Kudu的集群架构基本和HBase类似,采用主从结构,Master节点管理元数据,Tablet节点负责分片管理数据,

和HBase不同的是,Kudu没有借助于HDFS存储实际数据,而是自己直接在本地磁盘上管理分片数据,包括数据的Replication机制,kudu的Tablet server直接管理Master分片和Slave分片,自己通过raft协议解决一致性问题等,多个Slave可以同时提供数据读取服务,相对于HBase依托HDFS进行Region数据的管理方式,自主性会强一些,不过比如Tablet节点崩溃,数据的迁移拷贝工作等,也需要Kudu自己完成。

### 存储结构:

因为数据是有严格Schema类型定义,所以Kudu底层可以使用列式存储的方案来提高存储和投影检索效率(不过,设计kudu时,因果关系我估计是倒过来的,先决定要使用列式存储,再决定需要schema)

和HBase一样,Kudu也是通过Tablet的分区来支持水平扩展,与HBase不同的是,Kudu的分区策略除了支持按照Key Range来分区以外,还支持Hash based的策略,实际上,在主键上,Kudu可以混合使用这两种不同的策略

Hash分区的策略在一些场合下可以更好的做到负载均衡,避免数据倾斜,但是它最大的问题就是分区数一旦确定就很难再调整,所以目前Kudu的分区数必须预先指定(对Range的分区策略也有这个要求,估计是先简单化统一处理),不支持动态分区分裂,合并等,因此表的分区一开始就需要根据负载和容量预先进行合理规划。

在处理随机写的效率问题方面,Kudu的基本流程和HBase的方案差不多,在内存中对每个Tablet分区维护一个MemRowSet来管理最新更新的数据,当尺寸超过一定大小后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是牺牲了写性能来换取读取性能的提升。

既然存在Delta数据,也就意味着数据查询时需要同时检索Base文件和Delta文件,这看起来和HBase的方案似乎又走到一起去了,不同的地方在于,Kudu的Delta文件与Base文件不同,不是按Key排序的,而是按被更新的行在Base文件中的位移来检索的,号称这样做,在定位Delta内容的时候,不需要进行字符串比较工作,因此能大大加快定位速度。但是无论如何,Delta文件的存在对检索速度的影响巨大。因此Delta文件的数量会需要控制,需要及时的和Base数据进行合并。由于Base文件是列式存储的,所以Delta文件合并时,可以有选择性的进行,比如只把变化频繁的列进行合并,变化很少的列保留在Delta文件中暂不合并,这样做也能减少不必要的IO开销。

除了Delta文件合并,DRS自身也会需要合并,为了保障检索延迟的可预测性(这一点是HBase的痛点之一,比如分区发生Major Compaction时,读写性能会受到很大影响),Kudu的compaction策略和HBase相比,有很大不同,kudu的DRS数据文件的compaction,本质上不是为了减少文件数量,实际上Kudu DRS默认是以32MB为单位进行拆分的,DRS的compaction并不减少文件数量,而是对内容进行排序重组,减少不同DRS之间key的overlap,进而在检索的时候减少需要参与检索的DRS的数量。

以32MB这样小的单位进行拆分,也是为了能够以有限的资源快速的完成compaction的任务,及时根据系统负载调整Compaction行为,而不至于像HBase一样,Major Compaction动作成为导致性能不稳定的一个重要因素。所以对于Kudu来说,IO操作可以是一个持续平缓的过程,这点对响应的可预测性至关重要。

### 其它

Kudu底层核心代码使用C++开发,对外提供Java API接口,没有使用Java开发核心代码,也许有部分原因是希望通过自己管理内存,更好的适应和利用当前服务器上普遍越来越大的内存空间(256G+),另外也便于在关键逻辑中更好的优化代码。

## == 小结 ==

总体来说,个人感觉,Kudu本质上是将性能的优化,寄托在以列式存储为核心的基础上,希望通过提高存储效率,加快字段投影过滤效率,降低查询时CPU开销等来提升性能。而其他绝大多数设计,都是为了解决在列式存储的基础上支持随机读写这样一个目的而存在的。比如类Sql的元数据结构,是提高列式存储效率的一个辅助手段,唯一主键的设定也是配合列式存储引入的定制策略,至于其他如Delta存储,compaction策略等都是在这个设定下为了支持随机读写,降低latency不确定性等引入的一些Tradeoff方案

官方测试结果上,如果是存粹的随机读写,或者单行的检索请求这类场景,由于这些Tradeoff的存在,HBASE的性能吞吐率是要优于Kudu不少的(2倍到4倍),kudu的优势还是在支持类SQL检索这样经常需要进行投影操作的批量顺序检索分析场合。

目前kudu还处在Incubator阶段,并且还没有成熟的线上应用(小米走在了前面,做了一些业务应用的尝试),在数据安全,备份,系统健壮性等方面也还要打个问号,所以是否使用kudu,什么场合,什么时间点使用,是个需要好好考量的问题 ;)

转载自:http://blog.csdn.net/colorant/article/details/50803226

KUDU--秒级查询的数据仓库相关推荐

  1. clickhouse 在货拉拉的应用实践,千亿级别数据实现秒级查询

    作者:扬大平仔 前携程.网易高级工程师,现为货拉拉高级工程师.热爱技术,敢于将新技术用于项目实践. 前言 为了解决线上问题定位慢,相应不及时等问题.所以我们决定开发一套智能问题定位系统.对于我们的一些 ...

  2. ClickHouse留存分析工具十亿数据秒级查询方案

    作者:陈璐,腾讯 CSIG 高级数据分析师 本文实践了对于千万级别的用户,操作总数达万级别,每日几十亿操作流水的留存分析工具秒级别查询的数据构建方案.同时,除了留存分析,对于用户群分析,事件分析等也可 ...

  3. java按秒查询数据_ClickHouse留存分析工具十亿数据秒级查询方案

    作者:陈璐,腾讯 CSIG 高级数据分析师本文实践了对于千万级别的用户,操作总数达万级别,每日几十亿操作流水的留存分析工具秒级别查询的数据构建方案.同时,除了留存分析,对于用户群分析,事件分析等也可以 ...

  4. Hadoop企业级应用之秒级查询Kudu+Impala

    Apache Kudu是开源Apache Hadoop生态系统的新成员,它完善了Hadoop的存储层,可以快速分析快速数据. Apache Impala是CDH的集成部分,通过Cloudera Ent ...

  5. 耗时3天,上亿数据如何做到秒级查询?

    点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章 来源:sohu.gg/jIp59N 最近在忙着优化集团公司的一个报 ...

  6. 6亿数据秒级查询,ClickHouse太快了!

    " ClickHouse 在数据分析技术领域早已声名远扬,最近由于项目需求使用到了 ClickHouse 做分析数据库,于是用测试环境做了一个单表 6 亿数据量的性能测试. 图片来自 Pex ...

  7. 耗时 3 天,上亿数据如何做到秒级查询?

    最近在忙着优化集团公司的一个报表.优化完成后,报表查询速度由从半小时以上(甚至查不出)到秒查的质变.从修改 SQL 查询语句逻辑到决定创建存储过程实现,花了我 3 天多的时间,在此总结一下,希望对朋友 ...

  8. python +ip2region 离线IP库地址文件实现秒级查询ip归属地址

    ip2region ip2region - 离线的ip地址查询库,ip到地区的映射库,提供二进制,B树,内存搜索三种查询算法,查询速度非常快. 支持Java,PHP,C,Python,Nodejs,G ...

  9. 亿级数据多条件组合查询——秒级响应解决方案

    1 概述 组合查询为多条件组合查询,在很多场景下都有使用.购物网站中通过勾选类别.价格.销售量范围等属性来对所有的商品进行筛选,筛选出满足客户需要的商品,这是一种典型的组合查询.在小数据量的情况下,后 ...

最新文章

  1. 2021年大数据Flink(三十八):​​​​​​​Table与SQL ​​​​​​案例五 FlinkSQL整合Hive
  2. Go简单的Goroutine示例
  3. 光猫直连电脑不能上网_电脑插上网线不能上网怎么办
  4. xxx系统可用性和易用性分析
  5. import org.apache.http.xxxxxx 爆红,包不存在之解决办法
  6. 使用jquery获取url及url参数的方法及定义JQuery扩展方法
  7. 原来访问网页弹出cookie是这样的
  8. 类的概念、成员函数的定义方式、类的访问控制和封装、类的大小、this指针
  9. 怎么修改腾讯视频账户和密码
  10. php intdiv(),PHP intdiv()函数使用方法
  11. C语言int的字节数跟什么有关,C语言中int型字长和什么有关
  12. 如何找到自身产品优势?
  13. OSChina 周二乱弹 —— 从此鲜肉成屌丝
  14. C#重写WebBrowser组件,禁止跳转到IE新窗口、脚本错误
  15. python爬虫外贸客户_python实战成功爬取海外批发商价格信息并写入记事本
  16. java foreach跳出本次循环_java控制流程最全示例
  17. php dom怎么创建节点,前端必须掌握的DOM节点操作方法!
  18. schema自动生成前端代码
  19. android平板 双清,什么是小米平板2刷机前的双清
  20. unity 接入移动MM (3.1.10)

热门文章

  1. Linux查看版本当前操作系统内核信息
  2. 使用Spring Security3的四种方法概述
  3. [记录]java.math.biginteger cannot be cast to java.lang.long
  4. [网摘]关于产品运营
  5. Mysql字段数据类型:char与varchar的区别
  6. 点击链接,执行.py脚本,cgi脚本,浏览器中没有显示解析后的web页面,而是.py文件本身的代码内容...
  7. 对datatable进行linq过滤
  8. 42.Android之ListView中ArrayAdapter简单学习
  9. iOS之数组的排序(升序、降序及乱序)
  10. ecmall类关系图(转)