Cloudera 公司研发工程师，Kudu 发明人Todd Lipcon：Kudu，Storage for Fast Analytics on fast Data

Cloudera 公司研发工程师，Kudu 发明人Todd Lipcon带来的演讲主题是《Kudu:Storage for Fast Analytics on fast Data》。

Todd Lipcon同时也是Hadoop、HBASE等项目的成员。他表示Kudu是一个新的存储引擎，这个项目研发的动机是希望解决HBASE等等这些不能兼顾高性能分析和更新的问题，Todd Lipcon详细介绍了Kudu如何简化构建分析型应用架构，如何提高分析的性能，另外，他邀请了小米公司的一个工程师给他助阵，演示Kudu上面的实际应用效果。

Cloudera 公司研发工程师，Kudu 发明人 Todd Lipcon

Todd Lipcon：大家好！今天给大家介绍下Kudu，昨天我们谈到了Kudu，昨天我们在一个孵化器讨论组中间谈到Kudu，今天我们具体介绍下Kudu。

首先开始讨论一下为什么我们建立Kudu，它是个新的存储系统，基于Hadoop生态系统之上的系统，Hadoop有很多组件，组件多的让人迷惑 ，我们为什么还要增加一个组件？

如果看Hadoop的生态系统，有两种存储的选择这个表格没有什么数据，在这个表格上大家可以看到两个存储选择，首先可以看到HDFS，HDFS是个非常成熟的系统，HDFS对于分析来讲是非常棒的系统。在Y轴上面是性能表现，HDFS分析性能非常好，可以进行很多数据的处理，而且进行高性能高速的大数据处理。但是X轴上上我们随机的访问，可以看到HDFS这个解决方案的不好，它对于随机的支持和随机的访问是表现不太好的。

我们有另外一个系统叫“HBASE”，可以花几毫秒时间进行数据缓冲、数据整合和调取数据，大家如果进行分析，比如SQL在HBASE上进行分析的话，它的性能并不是很好，所以HBASE对于数据分析来讲比HDFS慢很多。有的时候你是分析师，有的时候你要进行数据迁移和整合，所以没有人能够填补这中间的空缺，就是同时兼具数据分析、数据整合、数据迁移和数据访问，Kudu填补了这个空白 。Kudu的分析比这个好很多，另外，它的延迟很少，几毫秒时间可以进行随机随意调取和数据的更新，所以我们的语言和语境都是非常连续和连贯的，我们也有不同的表格、不同的数据线和行，就相当于是一个线性的数据组。

我为什么要做Kudu的另外一个原因，因为它的硬件变了，HDFS是2003年Google基础上的，HBASE是基于06年开发的硬件，可是现在的硬件完全不一样了，2006年我们没有Flash，对于随机调取来讲Flash更加便宜，读写能力很好，价格是3美元每个比特，同时它在不停的下降。下一个阶段的硬件也在研发过程中，英特尔他们在做新的硬件，硬件的处理速度快很多。HDFS和HBASE的硬件不适应这样的高性能。另外一个大变化是RAM完全增大了，以前是64兆RAM，现在256G的RMA非常常见，甚至更大。所以我们需要用一个东西用起我们的缓存，这样我们就可以进行更好更快的数据处理。但是在HBASE和HDFS并不能高效利用CPU，它们的存储很慢，现在的特点是我们的存储都很快了，所以现在我们需要更好的系统，把冗余去掉，更好的应用CPU和存储的性能。

所以为什么要用Kudu，Kudu是一个大规模的数据处理器，现在已经用275节测试Kudu，500节都不会有任何问题，我们只是没有测而已。它的设计是基于1000nodes以上的，同时，它也可以是可以扩展的，所以用新的硬件和新的技术可以很好的在Kudu上进行扩展。另外，随意的调取和读写，每秒钟都可以有几百万次，如果你是分析师，每秒钟多个GB的nodes速度也是非常容易取得的，所以如果我们读数据的话每秒钟可以读好多字节。我们的存储能力非常棒，我们并不存储文件，我们也不存储比特，我们存储表格，所以我们是SQL支持的数据和语言，大概200或500个列，不像HBASE有1000多万个列，所有这些列都有它自己的标题，比如时间、地点等等。所以我们也支持其他的表格，因为我们知道大数据是要很长时间，有的时候加一个列需要几秒钟。但是NoSQL的API我们也可以连接，我们有JAVA，也可以用C++语言等等。

讲讲Kudu的案例，什么时候大家要用Kudu而不用HABASE和HDFS，Kudu是把线性处理和随意处理连接起来，我们可以看具体的情形，比如两个情形，时间序列 ，我们经常把市场的数据深入进来，比如我们不同时间段的股价，所以我们需要做数据的分析。但是我们不需要大批量进行分析，比如我们想做最后5分钟或10分钟的分析，或者最后10分钟或5秒钟的分析，用Kudu就可以立刻进行。有的时候我们需要数据的纠正，昨天来的数据是不正确的，比如它把美元发过来，但实际上应该是以人民币，所以这个时候我们需要进行数据的修正。在其他的系统中数据修正很难，但是在Kudu系统中很容易进行。

另外一个是数据的迁移和导入导出，比如我有一个客户的列表，客户列表需要不停的更新，如果客户登陆的时候我们就要进行更新 ，如果有个新的客户我们就需要进行更新，有的时候我们也需要进行客户名单的分析，有的时候也需要查找具体客户的信息，这时候访问 数据库有数据分析、数据调取和数据导入，这需要用Kudu。今天用Hadoop可以建立这样的构架 ，但是非常的复杂。

我们看左上角，大家可以看到数据源，数据源是用HBASE，是唯一一种技术可以进行一行行的插入，有的时候我们可以把HBASE变成不同的格式，因为HBASE对于分析来讲非常慢，所以可以转换HBASE其他模式。其他数据可以用Parquet模式输入到其他的数据模拟中间。大家并不知道我们的指令是在进行执行，是改变了还是我们的指令没有执行，Parquet的文件是不是不够，所以我们需要有大文件、小文件包。Hadoop的系统对于我们进行程序来讲非常复杂，给操作有很多不便捷性。有些老的数据可能需要花10分钟、1小时或者一天进行修正和处理，有的时候需要调取老数据，更新数据时很难去更新，需要从头到尾找数据，也许要打电话找工程师，然后告诉数据错误的情况，所以过程是非常头疼的。用Kudu很简单，可以让大家插入数据，通过缓冲，同时大家也可以容易进行快速分析，同时可以让大家进行更新数据。所以用API来讲，Kudu是非常简单的应用情况。

下面请常新明（音）给大家介绍小米用Kudu的具体案例。

常新明：我介绍小米使用Kudu的案例，这是一个移动服务的监控和故障定位工具，这个工具收集移动端和后端服务，收集各种模块之间的调用信息，我们利用这些信息来监控服务质量，另外，如果故障发生之后，我们可以用这些信息非常快的定位到问题。这个系统要求比较高的写入吞吐，目前我们每天有大概50亿以上的消息，并且每天都在增长。另外，我们需要查询到最近的数据，并且能够快速自由的对这些数据进行查询，以便用来定位问题。最后，我们希望查询到最原始的每一条单独记录，我们不希望这些数据被异聚合。

这是使用Kudu之前我们的数据流，数据源通常会产生两种数据，第一种数据是时间序列或者日志，我们把这种数据打到里面。第二种是支持随机更新的状态数据，一般存储在HBASE或者MySQL，对于离线咨询我们使用这个，对两种数据进行直接操作。对交互式查询或者在线分析查询，我们把这些数据批量导成存储格式。目前的问题是数据流比较长，导致了我们的数据延迟比较高，一般是几分钟或者天级别的数据延迟，另外的问题是我们绝大多数数据不是严格有序的，一般数据有一定的随机延迟。这个现象在移动应用来说非常普遍，因为移动端为了节约流量和电量，都是打包或者定时发过来，有比较高的延迟。

在使用Kudu之后简化了我们的数据流，现在用户可以通过两种方式灌入数据，如果我们应用需要ETL数据，可以使用ETL，数据打入卡夫卡，延迟一般小于10秒钟。如果我们应用有严格的实时要求，可以直接把数据写入Kudu，没有任何延迟。使用Kudu之后，优化简化了数据流，降低数据延迟，以有序高效列存储保持，我们的查询效率也极大的提高。

Todd Lipcon：现在给大家简单说说Cloudera内部怎么运作 ，我们可以进行进一步探讨。大家进行这个处理机，非常相似于数据日志，我们Kudu系统可以用手持电脑或者平板电脑进行操作，所有都是自动的，图表的生成也是自动的，hash也是自动生成的，简单操作，每个tablet都是分区，每个都是用这样的算法 进行复制，它是在斯坦福几年前开发出来的一个算法，这样的复制意味着，如果一个服务器出现故障，在5秒钟之内我们就可以恢复，这个恢复非常迅速，而且完全自动恢复，不需要有任何的操作人员。Tablets服务器可以存储数据，是在局部的磁盘当中去存储。

我们还有另外一个流程称为Master，它只处理元数据，存储数据做三个事情，一个是不断追踪tablets分支，接下来不断追踪表，还有它们的示意图，还有元数据，第三个是会应对决策，比如负载均衡，还有在哪里放在一个新的tablet，当我们创建一个tablet的时候把它放在哪，一切都非常简单，它只存储非常少量的元数据，非常的小，运营非常快速，没有扩展性问题。

在内部Kudu存储数据，这里有一个例子，我们有twitterFirehose table，还有四个栏，ID、时间、用户名、实际文本，还有每行的，那是列的，每行会按照同样的顺序存储数据，首先是存储第一排，第一行，然后第二行。基于排的这个数据库，会把数据库按照每一列来变成几个分开的文件，我们有用户名的文件，还有twitterID的文件。

为什么这比较好呢？第一点，它的规模大小不一样，尺寸不一样，有创建的时间表，它们非常小，一个文件可能是一个G，用户名是个文本，可能是2个G，实际内容可能是200个G。大家可以去想象一下，他要进行搜索，有个查询的要求，要输入特定的用户名，这个用户名有价值，我们只需要阅读用户名这一列，而不是阅读204个G，这样我们阅读的数据少100倍，速度也更快。

另外一个很大的优势是压缩，大家可以看看这个，这里是44，都是比较大的，但是它们都比较类似，这样我们可以去了解到和以前相比有哪些区别，它们可以变成小的数据，接下来可以把它们打包成小的字节，64个字节可以变成17个字节，压缩非常迅速、非常快，因为它是载体的运营，是在现在CPU上的运行，可以每行压缩几个字结，就像时间序列一样，不会出现太大的改变。

可以进行编码 ，比如我们有名字或算法，或者没有独特的价值，我们可以自动进行对它进行压缩。可以帮助我们节省非常多的空间，使得你的查询变得更加迅速，因为它所使用的数据更少。把数据在后台变成列，内存当中是按行存储的，随后在硬盘当中把它变成列，当我们对行进行升级的时候，有Docker，然后把Docker压缩到列的文件当中，这里不给大家介绍细节，大家可以阅读我们的论文。

接下来介绍一下整合，大家可以利用快速的命令，使两行的代码运行，它非常的迅速、更快。我们还有Impala整合，新的进行升级，还有删除。我们一直在推出更多的集合整合，这些都是开放的。最后，我们和Map Reduce进行整合，如果大家进行Map Reduce的话可以找到同样的节点、同样的硬盘，它们可以共同运作，然后我们可以快速的进行运行。

最后介绍一下性能，TPC-H是非常常见的数据库标杆 ，只有几百个G，75个节点，可以用它对标CPU的效率，我们可以在RAM当中快速进行查询。如果大家不知道TPC-H的标杆，它是22个不同的query，复杂度处在中间水平。

我们觉得Kudu应该比Parquet低一点，但是我们发现Kudu比它快30%，Parquet比较简单，它应该能够更快，我们只是进行了简单的优化。Kudu对分析来说真的非常快速，这是重要的一点。

我们看看这张图片，有几个不同的查询，发现Kudu比Phoenix快10倍到100倍，Phoenix的设计是针对LTPG设计的，而不是针对分析、查询和数据的扫描。我们也进行了一些查询，用小米的Benchmark进行对标，Kudu比这个快得多，而且我们做了其他方面的优化，针对选择性查询，而Parquet没有。这个我要给大家介绍一下Kudu在哪些方面做得不是很好，对于只有LTP的应用，比如NoSQL风格的，还有随即的访问 Kudu做得不是很好，和HBASE相比Kudu是它的一半，有的时候慢4倍，将来我们可以做一些优化，把它的速度提高一下，可以慢2倍或者慢30%，如果有这样应用的话Kudu不是个最佳的选择。

如果大家利用Kudu的话，现在有个项目被接受了，小米运行71个节点，现在还没有进行具体的运营，但是很快就会运营。我们现在没有安全性，也没有后备，这些特征都是让我们感觉非常惊讶的，也许明年我会告诉大家，这些工作我们都已经完成了。在这方面可能需要一些专家来帮助大家，大家如果想尝试Kudu的话，大家可以找到我们，小米也可以帮助你。

我们这个社区比较小，但是我们希望能够有更多的人加入到Kudu的社区当中，也许明年可以把你们的标识放到这张幻灯片当中。大家作为用户，可以看一下我们的网站 Kudu.io，大家也可以进入Kudu-user @Googlelegroups.com，我们有个在线应用在旧金山非常受欢迎，可能在中国还不是非常的受欢迎，大家可以从浏览器中登陆，和我们进行聊天 ，大家也可以下载VM，这样可以快速的去尝试，也可以去下载CSD，这样可以在多个节点上进行安装。

如果大家要关注我们，进行开发的话，我们希望找到更多人参与到我们的开发队伍当中，大家可以加入到当中找到BUG，帮助我们修复BUG，一切都是开源的，我们的社区也开放的社区，非常感谢各位，希望大家回家的时候可以尝试一下Kudu。

更多精彩内容，请关注直播专题2015中国大数据技术大会(BDTC) ，新浪微博ImapBox@邮箱云存储，订阅ImapBox大数据微信号。