Apache Kudu 加速对频繁更新数据的分析

• 摘要：上图是Hadoop生态体系中,存储引擎和应用场景的对应关系。横轴代表数据查询分析的频度(PaceofAnalysis),依次为:归档基于静态数据的扫描/分析(一次写入多次读取)基于频繁更新数据的快速分析实时访问/更新(OLTP)纵轴代表的是数据的更新频度(PaceofData),依次为只读追加(Append-Only)频繁更新实时更新我们知道,HDFS特别适合归档和基于静态数据的扫描/分析的场景(一次写入多次读取),也就是上图中左下角的黄色区域,而HBase擅长实时高并发的读

• 

   

  上图是 Hadoop 生态体系中,存储引擎和应用场景的对应关系。

   

  横轴代表数据查询分析的频度(Pace of Analysis),依次为:

  归档
  基于静态数据的扫描/分析(一次写入多次读取)
  基于频繁更新数据的快速分析
  实时访问/更新(OLTP)

  纵轴代表的是数据的更新频度(Pace of Data),依次为

  只读
  追加(Append-Only)
  频繁更新
  实时更新

  我们知道,HDFS 特别适合归档和基于静态数据的扫描/分析的场景(一次写入多次读取),也就是上图中左下角的黄色区域,而HBase擅长实时高并发的读写应用,也就是右上角的蓝色区域。但是对于需要在频繁更新的数据之上做快速分析,也就是上图中间的虚线区域,Hadoop社区却一直没有比较好的存储层产品来满足。Kudu正是出于填补这个空白而诞生的。

   

  视频中提到,Kudu的设计借鉴了Parque和HBase一些理念 / 思想。

   

  Kudu产品的几个要点:

  数据模型和关系数据库类似,为结构化的表;列的数量有限(和HBase/Cassandra相比较而言)
  内部数据组织方式为列式存储
  很好的横向扩展能力,目前测试的是275个节点(3PB),计划支持到上千个节点(几十PB)
  不错的性能,集群能达到百万级别的TPS,单节点吞吐为几个GB/s
  本身不提供SQL接口,只支持类似NoSQL的接口,如 Insert(), Update(), Delete() and Scan() 等
  通过与 Spark 和 Impala 等(Drill,Hive的支持还在进行中)的集成,对外提供基于 SQL 的查询分析服务

  Kudu 和 Spark 集成后,能带来的好处:

  带来和 Parquet 相似的扫描性能,但却不存在数据更新/插入的延迟,也就是说,对数据的实时更新/插入,对分析应用来说是即时可见的,无延迟。
  Spark对数据的过滤条件(基于判定的过滤条件,即 predicate)可以下推到 Kudu 这一存储层,能提高数据读取/扫描的性能
  相对 Parquet,基于主键索引的查询,性能更高 Spark Datasource

  这部分比较简单,介绍Kudu与Spark集成的代码片段。基本上就创建一个kuduDataFrame后,后续的操作就和普通的Spark DataFrame API没什么差别了

  
  Quick Demo

  Demo也比较简单,有兴趣大家可以自己看一下视频(位置在视频的 18分26秒),就是在 Spark Shell 中操作一个 kuduDataFrame

  
  Use Cases

  Kudu 最适合的场景包含这两个特点:

  同时有顺序和随机读写的场景
  对数据更新的时效性要求比较高

  这样的场景有:

  和时间序列相关的数据分析:对市场/销售数据的实时分析;反欺诈;网络监控等
  在线报表和数据仓库应用:如ODS(Operational Data Store)

  片中还介绍了小米使用Kudu的一个具体场景,需求是要收集手机App和后台服务发送的 RPC 跟踪事件数据,然后构建一个服务监控和问题诊断的工具,要求:

  高写入吞吐:每天大于200亿条记录
  为了能够尽快定位和解决问题,要求系统能够查询最新的数据并能快速返回结果
  为了方便问题诊断,要求系统能够查询/搜索明细数据(而不只是统计信息)

  在没有使用kudu之前,方案的架构如下图所示。

   

  

   

  这是典型的Lambda架构(存在两套相对独立的数据流水线:批处理和流处理),一部分源系统数据是通过Scribe(日志聚合系统)把数据写到HDFS,另一部分源系统数据(实时性要求较高的?)是直接写入HBase,然后:

  为了能支持交互式/实时的查询,需要通过Hive/MR/Spark作业把这两部分数据合并成 Parquet 格式存放在HDFS,通过 Impala 对外提供交互式查询服务
  线下分析的就直接通过运行 Hive/MR/Spark 作业来完成

  我们可以看到,这样的数据线比较长,带来两个问题:

  其一是数据时效性较差(一个小时到一天);
  其二是需要多次数据转换(如:HFile + seqfile ==> Parquet)

  还有一个问题,存储层中数据不是按照时间戳来排序,如果有部分数据没有及时到达,那么为了统计某一天的数据,可能就要读取好几天的数据才能得到。

   

  使用了Kudu以后,方案的架构如下图所示。

   

  

   

  数据都存储在Kudu中,分两条线进入Kudu:

  对于需要做加工(ETL)的数据或来自压力较大的系统的数据(产生的数据较多,源系统无法长时间缓存)可以先进入Kafka缓存,然后通过Storm做实时的ETL后进入Kudu,这种情况的延时在 0~10秒的区间
  反之,源系统的数据可以直接写入 Kudu,这种情况数据没有任何延迟

  然后,一方面可以通过 Impala 对外提供交互式查询服务(基于SQL),另一方面也可以直接通过 Kudu API 直接访问数据

  这样的架构带来的好处比较明显,一方面是大大提高数据的时效性,另一方面大大简化系统架构

   

  PPT中还有一张 Kudu + Impala 的方案与 MPP 数据库产品(如 Greenplum,Vertica 和 Teradata)进行对比,但是由于时间关系视频中没有讲,这里简单提一下:

   

  他们有存在相似之处:

  提供基于SQL的交互式快速查询/分析
  能够提供插入、更新和删除操作

  相对于 MPP 数据库,Kudu + Impala 方案的优势:

  更快的流式数据插入(streaming insert)
  和 Hadoop 生态体系有较好的集成:
  
  把 Kudu 和 HDFS 部署在同一个集群,可以关联分别存储在 Kudu 和 HDFS 上的表
  和 Spark,Flume等的集成度较好

  相对于 MPP 数据库,Kudu + Impala 方案的劣势:

  批量插入的性能相对较慢
  不支持数据装载的原子操作,不支持跨行的原子操作,不支持二级索引 Kudu Roadmap

  相对 HDFS 和 HBase,Kudu还是一个比较新的项目,视频介绍了产品路线图的一些想法:

   

  安全方面:

  和 Kerberos 的集成
  力度更细的权限控制
  基于组和角色的权限管理
  ...

  运维方面:

  稳定性的增强
  一些恢复工具
  故障诊断辅助工具

  性能和扩展性:

  具体一些读写性能提升的想法
  扩展性的提升(短期到400节点,长期上千节点)

  客户端方面:

  目前支持Java、C++ 和 python,Python目前还是短板,有些功能还没支持