kudu应用经验分享mysql
本文是小米工程师常冰琳于10月25日晚10点在“大数据产业联合会”微信群中分享的内容，由hadoop123小编整理而成，供你们学习。sql
小米使用kudu的背景后端
小米大概在14年中开始和cloudera合做，做为kudu小白鼠用户，帮cloudera在生产环境验证kudu。kudu+Impala能够帮助咱们解决实时数据的ad-hoc查询需求。数组
在kudu以前，咱们的大数据分析pipeline大概是有这几种：微信
1. 数据源-> scribe打日志到HDFS -> MR/Hive/Spark -> HDFS Parquet -> Impala -> 结果serviceapp
这个数据流通常用来分析各类日志。异步
2. 数据源 -> 实时更新HBase/Mysql -> 天天批量导出Parquet-> Impala -> 结果serve工具
这个数据流通常用来分析状态数据，也就是通常须要随机更新的数据，好比用户profile之类。oop
这两条数据流主要由几个问题：性能
1. 数据从生成到可以被高效查询的列存储，整个数据流延迟比较大，通常是小时级别到一天；
2. 不少数据的日志到达时间和逻辑时间是不一致的，通常存在一些随机延迟。
好比不少mobile app统计应用，这些tracing event发生后，极可能过一段时间才被后端tracing server收集到。
咱们常常看到一些hive查询，分析一天或者一小时的数据，可是要读2-3天或者多个小时的日志，而后过滤出实际想要的记录。
对于一些实时分析需求，有一些能够经过流处理来解决，不过他确定没用SQL方便，另外流式处理只能作固定的数据分析，对ad-hoc查询无能为力
kudu的特色正好能够来配合impala搭建实时ad-hoc分析应用。
改进后的数据流大概是这个样子：
1. 数据源 -> kafka -> ETL(Storm) -> kudu -> Impala
2. 数据源 -> kudu -> Impala
数据流1 主要是为须要进一步作ETL的应用使用的，另外kafka能够当作一个buffer，当写吞吐有毛刺时，kafka能够作一个缓冲。
若是应用有严格的实时需求，就是只要数据源写入就必须可以查到，就须要使用数据流2。
引入kudu的目的
引入kudu主要是用来替换 HDFS+parquet的。
kudu的列存和parquet列存有啥区别？
从功能上说，kudu的列存除了提供跟parquet接近的scan速度，还支持随机读写。支持随机写，数据就能够实时灌入存储中，达到实时查询的效果；可是parquet文件只能批量写，因此通常只能按期生成，因此增大了延迟。kudu的存储相似hbase的lsm存储。
为何说kudu的scan会比kylin快呢
kylin是存储在hbase上的，kudu的scan为何比hbase快，简单的说kudu是真正的列存储，hbase只是列簇存储。kudu是有schema的，每一列的数据是在文件中已数组的形式保存的，而hbase存储在hfile里面的仍是sort好的(rowkey, column, timestamp, value)对，scan是开销要多不少，具体须要看kudu的paper了，在这里文字很差解释。
storm 写kudu的吞吐量能到多少，和storm写hbase比呢
咱们在71个节点的集群作了测试，随机写性能：随机写26亿条记录：每一个节点大概4W 随机写性能。
大概的状况以下：
71 Node cluster
Hardware
CPU: E5-2620 2.1GHz * 24 core Memory: 64GB
Network: 1Gb Disk: 12 HDD
Software
Hadoop2.6/Impala 2.1/Kudu
3个大表，其中一个大表天天：
~2.6 Billion rows
~270 bytes/row
17 columns, 5 key columns
storm到kudu，按照天天26亿数据来算，每秒大概30000条记录吧。
这个是咱们的应用挑出的6个查询，作的查询性能对比。一样6个查询，查询parquet和查询kudu作的对比。当时kudu的设计目标是接近parquet的scan性能，惊喜的是，目前kudu的scan性能在生产环境下有时还比parquet快一些。
像hbase有coprocessor，kudu有相似的计算功能吗？
kudud。kudu有predicatepushdown，目前有impala使用时，scan时是把一些过滤提交给kudu去作的。
大家是想用kudu替换hbase仍是一块儿搭配用？
感受这两个工具目前用来解决不一样的问题，hbase仍是用来作OLTP类存储跟Mysql相似，kudu则用来升级咱们现有的数据分析数据流，主要仍是OLAP的workload。
Kudu支持随机增长列吗？
只要不是primarykey的列，是能够随时增长的，并且不像mysql增长列时影响其余操做，kudu altertable是异步的，并且对性能影响不大。hbase是无schema的，因此能够成千上万个列，kudu不行的，列的数量也不能过多。咱们目前也就试过30多列的，一些300+列的表尚未测试过。
Kudu目前有稳定版吗
目前beta版本，不推荐如今在生产环境使用。
可否介绍一下小米使用kudu过程当中踩过的坑？
目前踩的坑都还在开发阶段，其实都不算什么，并且从大方向上看，咱们仍是相信kudu这种方式对比以前的数据流优点很明显，对吞吐不是很是高的应用，这种方案是发展方向。其实咱们在老的数据流上碰到不少问题，以前提到的数据延迟，数据无序，多个组件之间的兼容性，数据无schema致使灌入数据时缺乏验证，其实都但愿引入kudu后可以解决。
