Apache Kudu 读后感

Kudu[1]是Apache下一个新开源产品,其介绍

        A new addition to the open source Apache Hadoop ecosystem, Apache Kudu (incubating) completes Hadoop's storage layer to enable fast analytics on fast data.

        其目标是很快的分析数据,在多处的介绍里面也看到其希望弥补HDFS和HBase之间的gap,前者是重离线批量,后者中在线随机,今天看了下Kudu的论文[2],记录感想。

        其在文章开始说如果用户想完成数据在线写入,然后又要分析,没有一个独立的软件能够完成(关系数据库就没提了,其实有些写入能力还是可以的,比如TokuDB),常见的架构是写入HBase然后导入到HDFS分析,或者写入Kafka,然后分别分入HBase和HDFS进行分析,作者认为这种架构有如下不足:

        1. 复杂:这不用讲了,几个大家伙一起肯定不是那么好搞懂的;

        2. 安全:猜测作者主要意思是数据在各个组件间流动,那么如果有一款组件安全性做的不好,就有导致数据泄露的风险;

        3. 一致性:上面方案中的数据同步机制一般都是通过异步队列进行的,存在一定的延时性,所以数据源和数据目标之间会有一部分数据不一致;

        4. 时效性:跟一致性是类似问题,因为是异步队列或者定期拉数据,那么就不能实时的分析此类的数据。


        所以他们就要做一款完整解决上面问题的产品了,Kudu大羚羊诞生。

        Kudu从整体看是列存储,就是列数据之间是分开存储的,这样扫描的时候如果只需要扫描部分列就会比较快(大块扫描场景);

        Kudu是强schema的,这样系统就有了更多的信息,可以进行更好的编码压缩,比如bitvector之类的,都是传统数据库早就发明的;

        Kudu支持range和hash两种方式对数据进行分片,这是个用户友好的选择,技术方案上差别不大;

        Kudu没有使用类似HDFS的共享存储,而是自己管理磁盘,这当然利于做将事情做到极致且利于快速推进,不过自己管理磁盘,数据复制也不是那么容易的。

        Kudu支持基于Raft协议提高可用性,支持动态增加、减少replica个数。这个好理解,反正存储都自己做了,一个完全的垂直产品,搞Raft是天经地义,MySQL兄弟们啥时候推出来这个?

        Kudu支持MVCC做事务控制,不过事务这一段写的太模糊,写了靠token机制,也写了靠类似Spanner的commit-wait(根本上来说,同步只有两种,一种是消息,就是给你打个电话告诉你点事情;一种基于一个共同的时间,比如约定7点开战,commit wait是后一种),不知道到底要干嘛。

        文中看到了一个东西叫做Fractured Mirrors(很早别人提的), 这个想法实在妙,三份replica的底层存储引擎可以不同,比如replica A更好的支持随机读,replica B更好的支持批量读,这样就可以在不同的场景中充分的利用各个replica的能力,在产品架构上,分层和垂直的设计半斤八两不分上下。

        Kudu对PK做了唯一性约束,也就是每次写会检查是否存在,是在引擎层做的,这似乎不是个很好的设计,做的太硬了。

        Kudu也要做compaction来移除无效数据,或者整理数据以便优化读,这里其将数据文件切小,再加上很好的优先级控制和一些启发式算法,对各个replica的时机也做控制,那么还是能做到尽量少的影响业务。


        整体而言,Kudu似乎想做一个集合OLTP/OLAP的东西,在线写入,高可用,可选的一致性,即时快速的扫描分析,好嘛。大一统的产品能不能做成要打个问号,不过我个人倒觉得如果沿着这条路,MySQL类似的产品们希望更大。


[1] Kudu: http://getkudu.io/

[2] Kudu 论文:http://getkudu.io/kudu.pdf

上一篇:技术问题两则


下一篇:JZ-015-反转链表