您的位置: 首页  >  文章  >  Apache Kudu 加速对频繁更新数据的分析

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

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

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

     

    上图是 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之前,方案的架构如下图所示。

     

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

     

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

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

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

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

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

     

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

     

    Apache 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目前还是短板,有些功能还没支持

相关推荐