Apache Kudu是一种针对结构化数据的存储系统，旨在填补HDFS和HBase之间的空白，提供低延迟的随机读写和高效的数据分析。Kudu结合了HDFS的批量分析和HBase的随机访问能力，支持实时插入和更新，适合需要同时进行随机读写和批量分析的场景。Kudu通过列式存储、与Hadoop生态组件的集成以及高可用性设计，优化了OLAP工作流。然而，Kudu在主键限制、更新操作和工具方面存在一些限制，如仅支持单个主键进行范围分区。Kudu的使用场景包括流处理、时间序列分析和预测建模等，与Impala和Spark等工具集成良好。
Kudu是什么？有什么特性？它和Hadoop生态的关系是什么？有了HDFS和HBase，为什么还要用kudu？
目录
Kudu产生的背景
在KUDU之前，大数据主要以两种方式存储；
（1）静态数据：
以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。
（2）动态数据：
以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。
这两种数据在存储方式上完全不同，导致使用场景完全不同。在真实的场景中，面对既需要随机读写，又需要批量分析的大数据场景，该如何选择呢？显然单种存储引擎无法满足业务需求，我们需要通过多种大数据工具组合来满足这一需求。
例如，Online Report采用HDFS/Parquet on Impala的架构，数据每隔一小时通过MapReduce从生产db增量同步到HDFS，再通过HIVE/MAPREDUCE增量MERGE到数仓中，最终通过IMPALA查询在报表展示。类似这样：
如图所示，数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，我们定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但他有如下缺点：
(1)架构复杂。从架构上看，数据在HBase、消息队列、HDFS 间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。
(2)时效性低。数据从HBase导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。
(3)难以应对后续的更新。真实场景中，总会有数据是延迟到达的。如果这些数据之前已经从HBase导出到HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。
这种架构可以支持超大数据集的查询和分析，但是数据更新执行过程很久，效率较差。而Apache Kudu结合了Hbase和HDFS的优势，可以同时提供高效的随机访问以及数据扫描能力，支持数据的实时插入和分析，为Online Report提供了另外一种选择。
Kudu是什么
KUDU的定位是Fast Analytics on Fast Data，把analytics 和 online两个应用场景进行了整合，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。
Kudu---This new open source complement to HDFS and Apache HBase is designed to fill gaps in Hadoop’s storage layer that have given rise to stitched-together, hybrid architectures.
(一个弥补HDFS和HBase之间的缺口的新型的存储，它能够更有效的利用现代硬件的CPU和IO资源，既能够支持分析，又能够支持更新、删除和实时查询。)
可以看出，KUDU 是一个折中的产品，在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。
Kudu集HDFS的顺序读和HBASE的随机读于一身，同时具备高性能的随机写，以及很强大的可用性（单行事务，一致性协议），支持Impala spark计算引擎。是一个融合HDFS和HBase的功能的新组件，具备介于两者之间的新存储组件。可以同时提供低延迟的随机读写和高效的数据分析能力，支持水平扩展,高可用，与Cloudera Impala和Apache Spark等当前流行的大数据查询和分析工具结合紧密。
kudu的使用场景
官方表述：
- Strong performance for both scan and random access to help customers simplify complex hybrid architectures（适用于那些既有随机访问，也有批量数据扫描的复合场景）
- High CPU efficiency in order to maximize the return on investment that our customers are making in modern processors（高计算量的场景）
- High IO efficiency in order to leverage modern persistent storage（使用了高性能的存储设备，包括使用更多的内存）
- The ability to update data in place, to avoid extraneous processing and data movement（支持数据更新，避免数据反复迁移）
- The ability to support active-active replicated clusters that span multiple data centers in geographically distant locations（支持跨地域的实时数据备份和查询）
更贴近业务的适用场景解读：
- Streaming Input with Near Real Time Availability（具有近实时可用性的流输入）
刚刚到达的数据就马上要被终端用户使用访问到。
数据分析中的一个共同挑战就是新数据快速而不断地到达，同样的数据需要靠近实时的读取，扫描和更新。Kudu 通过高效的列式扫描提供了快速插入和更新的强大组合，从而在单个存储层上实现了实时分析用例。
- Time-series application with widely varying access patterns（具有广泛变化的访问模式的时间序列应用）
需要同时支持：
根据海量历史数据查询。
必须非常快地返回关于单个实体的细粒度查询。
time-series（时间序列）模式是根据其发生时间组织和键入数据点的模式。这可以用于随着时间的推移调查指标的性能，或者根据过去的数据尝试预测未来的行为。例如，时间序列的客户数据可以用于存储购买点击流历史并预测未来的购买，或由客户支持代表使用。虽然这些不同类型的分析正在发生，插入和更换也可能单独和批量地发生，并且立即可用于读取工作负载。Kudu 可以用 scalable （可扩展）和 efficient （高效的）方式同时处理所有这些访问模式。由于一些原因，Kudu 非常适合时间序列的工作负载。随着 Kudu 对基于 hash 的分区的支持，结合其对复合 row keys（行键）的本地支持，将许多服务器上的表设置成很简单，而不会在使用范围分区时通常观察到“hotspotting（热点）”的风险。Kudu 的列式存储引擎在这种情况下也是有益的，因为许多时间序列工作负载只读取了几列，而不是整行。 过去，您可能需要使用多个数据存储来处理不同的数据访问模式。这种做法增加了应用程序和操作的复杂性，并重复了数据，使所需存储量增加了一倍（或更糟）。Kudu 可以本地和高效地处理所有这些访问模式，而无需将工作卸载到其他数据存储。
- Predictive Modeling（预测建模）
支持根据所有历史数据周期地更新模型。
数据科学家经常从大量数据中开发预测学习模型。模型和数据可能需要在学习发生时或随着建模情况的变化而经常更新或修改。此外，科学家可能想改变模型中的一个或多个因素，看看随着时间的推移会发生什么。在 HDFS 中更新存储在文件中的大量数据是资源密集型的，因为每个文件需要被完全重写。在 Kudu，更新发生在近乎实时。科学家可以调整值，重新运行查询，并以秒或分钟而不是几小时或几天刷新图形。此外，批处理或增量算法可以随时在数据上运行，具有接近实时的结果。
- Combining Data In Kudu With Legacy Systems（结合 Kudu 与遗留系统的数据）
公司从多个来源生成数据并将其存储在各种系统和格式中。例如，您的一些数据可能存储在 Kudu，一些在传统的 RDBMS 中，一些在 HDFS 中的文件中。您可以使用 Impala 访问和查询所有这些源和格式，而无需更改旧版系统。
有关这些和其他方案的更多信息，请参阅 Example Use Cases。
国内使用的kudu一些案例可以查看《构建近实时分析系统.pdf》文档。
Kudu设计优势
- OLAP工作流的快速处理
能够快速更新/获取新数据，并进行在线查询分析
- 列式存储结构
- 集成Hadoop生态组件
Spark/Flume/MapReduce/Impala等
- 服务的高可用性
TabletServer以及Master都使用*Raft*一致性算法。该算法确保只要可用副本数为总数的一半以上，Tablet就可以进行读写操作。即使在leader发生故障的情况下，follower也可以为程序提供只读服务。
- 结构化数据模型
类关系型数据库，强字段类型，主键索引，表分区设计
- NOSQL APIs
支持 C++, Java and Python (INSERT/UPDATE/SCAN/DELETE等)
kudu使用时的优势
1）一个table由多个tablet组成，对分区查看、扩容和数据高可用支持非常好
2）支持update和upsert操作。
3）与imapla集成或spark集成后（dataframe）可通过标准的sql操作，使用起来很方便
4）可与spark系统集成
kudu使用时的劣势
1）只有主键可以设置range分区，且只能由一个主键，也就是一个表只能有一个字段range分区，且该字段必须是主键。
2）如果是pyspark连接kudu，则不能对kudu进行额外的操作；而scala的spark可以调用kudu本身的库，支持kudu的各种语法。
3）kudu的shell客户端不提供表schema查看。如果你不通过imapla连接kudu，且想要查看表的元数据信息，需要用spark加载数据为dataframe，通过查看dataframe的schema查看表的元数据信息。
3）kudu的shell客户端不提供表内容查看。如果你想要表的据信息，要么自己写脚本，要么通过spark、imapla查看。
4）如果使用range 分区需要手动添加分区。假设id为分区字段，需要手动设置第一个分区为1-30.第二个分区为30-60等等
5）时间格式是utc类型，需要将时间戳转化为utc类型，注意8个小时时差。
kudu基本原理
表与schema
Kudu设计是面向结构化存储的，因此，Kudu的表需要用户在建表时定义它的Schema信息，这些Schema信息包含：列
最低0.47元/天 解锁文章
扫一扫
438
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
