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

今天解读的内容是来自 Hadoop Summit San 2016 关于 Apache Kudu 的一个介绍:Apache Kudu & Apache Spark SQL for Fast Analystics on Fast Data(视频见文章末尾)。欢迎关注微信公众号:大数据技术峰会解读(bigdata_summit),获取更多的内容和大数据技术峰会视频。

Apache Kudu 加速对频繁更新数据的分析_腾讯视频 https://v.qq.com/x/page/h03728qz2xm.html

Kudu Overview

上图是 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 这一存储层,能提高数据读取/扫描的性能
  • 相对 Parque,基于主键索引的查询,性能更高

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目前还是短板,有些功能还没支持
  • 文档、教程和日志等方面