为什么80%的码农都做不了架构师？>>> 
上图是 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目前还是短板，有些功能还没支持
- 文档、教程和日志等方面
