网易视频云：Kudu,支持快速分析的新型Hadoop存储系统
- 格式：docx
- 大小：513.27 KB
- 文档页数：12
文档推荐
-
最新网易视频云：流媒体服务器原理和架构解析页数:20
-
APP如何接入网易视频云直播功能页数:3
-
网易视频云技术分享HBase优化实战页数:8
-
网易视频云：漫谈中文分词页数:6
-
网易视频云直播常见问题解析页数:3
下载文档原格式
合集下载
kudu架构原理
kudu架构原理
Kudu的架构原理主要包括以下几个方面：
1. 副本机制：Kudu使用分布式副本机制来提高数据可靠性和可用性。
在Kudu中，每个表的数据被分成多个tablet，每个tablet在多个tablet服务器上具有冗余副本。
这些副本可以在不同的服务器上，以提高容错性和数据可靠性。
同时，Kudu还支持在多个副本之间进行数据同步，以确保数据的实时一致性。
2. 分布式存储：Kudu采用分布式存储方式，将数据分散到多个节点上，以提高数据存储和读取的效率。
Kudu支持将数据存储在本地磁盘上，同时支持使用缓存和压缩等技术来优化存储和读取性能。
3. 内存存储：Kudu使用内存存储技术，将部分数据存储在内存中，以提高数据的读取速度。
Kudu支持将数据缓存到内存中，并支持自动扩展内存容量，以满足不断增长的数据需求。
4. 数据分区：Kudu支持对数据进行分区，以提高数据的管理和查询效率。
Kudu按照列进行分区，每个分区对应一个tablet。
通过合理地分区，可以实现对大数据集的高效查询和管理。
5. 分布式协调：Kudu使用分布式协调服务，如ZooKeeper或ETCD，来管理集群中的元数据和配置信息。
这些服务可以帮助Kudu实现节点之间的协调和通信，确保集群的正常运行。
综上所述，Kudu的架构原理包括副本机制、分布式存储、内存存储、数据
分区和分布式协调等方面。
这些原理的实现使得Kudu能够提供高效、可靠、可扩展的数据存储和查询服务。
使用Hadoop进行音频和视频数据处理的方法
使用Hadoop进行音频和视频数据处理的方法随着互联网的迅速发展和智能设备的普及，音频和视频数据的产生和存储量呈现出爆炸式增长。
为了更好地管理和利用这些海量的音频和视频数据，使用Hadoop进行音频和视频数据处理成为一种有效的方法。
一、Hadoop简介Hadoop是一个开源的分布式计算框架，能够处理大规模数据集并提供高可靠性、高性能的数据存储和处理能力。
它的核心组件包括Hadoop Distributed File System（HDFS）和MapReduce。
二、音频数据处理1. 数据采集：音频数据可以通过麦克风、录音设备等进行采集。
采集到的音频数据可以是原始的PCM数据或者经过压缩编码的数据。
2. 数据存储：将音频数据存储到HDFS中，可以使用Hadoop提供的HDFS命令行工具或者编写自定义的程序进行数据上传。
3. 数据预处理：对音频数据进行预处理，包括去噪、降噪、降采样等操作。
可以使用Hadoop的MapReduce模型编写程序进行并行处理。
4. 特征提取：从音频数据中提取有用的特征，例如音频的频谱特征、能量特征等。
可以使用Hadoop的MapReduce模型编写程序进行并行处理。
5. 数据分析：对提取到的音频特征进行分析和挖掘，例如音频识别、语音合成等。
可以使用Hadoop的MapReduce模型编写程序进行并行处理。
三、视频数据处理1. 数据采集：视频数据可以通过摄像头、摄像机等进行采集。
采集到的视频数据可以是原始的YUV数据或者经过压缩编码的数据（如H.264）。
2. 数据存储：将视频数据存储到HDFS中，可以使用Hadoop提供的HDFS命令行工具或者编写自定义的程序进行数据上传。
3. 数据预处理：对视频数据进行预处理，包括去噪、降噪、降采样等操作。
可以使用Hadoop的MapReduce模型编写程序进行并行处理。
4. 特征提取：从视频数据中提取有用的特征，例如视频的帧率、分辨率、运动信息等。
网易视频云：探求BlockCache实现机制
网易视频云：探求BlockCache实现机制网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。
在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。
LRUBlockCacheLRUBlockCache是HBase目前默认的BlockCache机制，实现机制比较简单。
它使用一个ConcurrentHashMap管理BlockKey到Block的映射关系，缓存Block只需要将BlockKey 和对应的Block放入该HashMap中，查询缓存就根据BlockKey从HashMap中获取即可。
同时该方案采用严格的LRU淘汰算法，当Block Cache总量达到一定阈值之后就会启动淘汰机制，最近最少使用的Block会被置换出来。
在具体的实现细节方面，需要关注三点：1. 缓存分层策略HBase在LRU缓存基础上，采用了缓存分层设计，将整个BlockCache分为三个部分：single-access、mutil-access和inMemory。
需要特别注意的是，HBase系统元数据存放在InMemory区，因此设置数据属性InMemory = true需要非常谨慎，确保此列族数据量很小且访问频繁，否则有可能会将hbase.meta元数据挤出内存，严重影响所有业务性能。
2. LRU淘汰算法实现系统在每次cache block时将BlockKey和Block放入HashMap后都会检查BlockCache 总量是否达到阈值，如果达到阈值，就会唤醒淘汰线程对Map中的Block进行淘汰。
系统设置三个MinMaxPriorityQueue队列，分别对应上述三个分层，每个队列中的元素按照最近最少被使用排列，系统会优先poll出最近最少使用的元素，将其对应的内存释放。
网易视频云技术干货：分布式搜索elasticsearch集群监控工具bigdesk
网易视频云技术干货：分布式搜索elasticsearch集群监控工具bigdesk网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PASS服务。
在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。
现在，网易视频云与大家分享一下分布式搜索elasticsearch集群监控工具bigdesk。
bigdesk是elasticsearch的一个集群监控工具，可以通过它来查看es集群的各种状态，如：cpu、内存使用情况，索引数据、搜索情况，http连接数等。
今天，网易视频云就给大家分享关于分布式搜索elasticsearch集群监控工具bigdesk的技术干货！插件安装运行：1.bin/plugin -install lukas-vlcek/bigdesk2.运行es3.打开（localhost:9200/_plugin/bigdesk/）当然，也可以直接下载源码运行index.html同样是输入ip地址和端口后连接，界面如下。
加星的表示主节点。
下面介绍下各个图表。
系统监控：这里包含系统方面的一些状态，左起分别为：cpu，内存，交换区和平均负载的情况jvm：显示jvm的一些状态，左起分别为：jvm heap内存使用情况，蓝色的为已使用内存；非heap使用内存；线程数；gc情况（次数和时间）；进程：下面四张图主要显示es的进程对系统资源的使用情况，左起分别为：进程打开文件数，内存使用情况，cpu时间和进程的cpu使用率ps：内存使用情况中的Total virtual指linux下虚拟内存，它包括virtual memory map中的所有数据量之和。
包括：程序类+程序数据+jar包空间+jre占用空间等。
resident memory指程序实际占用的物理内存。
kudu原理
Kudu原理一、Kudu简介Kudu是一个分布式的高性能列存储系统，由Apache软件基金会开发和维护。
它主要用于解决大数据分析的难题，如实时分析、机器学习等。
二、Kudu的特点1.低延迟查询：Kudu的设计目标之一是提供低延迟的读写操作。
它使用了类似于LSM树、B+树等数据结构来加速数据的读写操作，从而实现了高性能的查询。
2.高可扩展性：Kudu支持水平扩展，可以根据需求增加更多的节点来存储和处理大规模数据。
它通过分区和副本机制来实现数据的负载均衡和容错性。
3.一致性和持久性：Kudu使用了WAL（Write-Ahead-Log）来确保数据的一致性和持久性。
每次写入操作都会先写入WAL，然后再进行内存和磁盘的数据更新。
三、Kudu的架构Kudu的架构包括Master节点、Tablet Server节点和Client节点。
3.1 Master节点Master节点是Kudu集群的管理节点，它负责管理和协调整个集群的工作。
Master节点主要负责以下几个功能：•元数据管理：Master节点维护了Kudu集群的元数据信息，包括表的结构、分区信息等。
所有对表的DDL操作都需要通过Master节点来执行。
•负载均衡：Master节点会监控集群中各个Tablet Server节点的负载情况，并根据需要将数据迁移至负载较低的节点，以实现负载均衡。
•故障处理：Master节点会检测和处理集群中节点的故障。
当某个节点宕机时，Master节点会重新分配该节点上的数据和任务。
3.2 Tablet Server节点Tablet Server节点是实际存储数据的节点，它负责数据的读写和查询操作。
每个Tablet Server节点可以管理多个Tablet，每个Tablet负责存储表的一部分数据。
Tablet Server节点主要包括以下几个组件：•Tablet Manager：负责管理Tablet，包括创建、删除和拆分等操作。
简述hadoop的主要功能模块
简述hadoop的主要功能模块
hadoop 是一个分布式计算的框架，它是由Apache软件基金会开发的一个开源的分布式计算系统，它实现了一个分布式文件系统HDFS 和一个集群计算框架MapReduce。
hadoop的主要功能模块包括：
1. 硬件抽象层：Hadoop提供的硬件抽象层可用于抽象出各种物理计算资源，使之成为一个可用于分布式计算的逻辑资源。
2. HDFS文件系统：HDFS是Hadoop的核心，它是一个分布式文件系统，它提供了对大量数据集的高效存储，以及跨多个节点的高性能数据访问。
3. MapReduce框架：MapReduce框架是一个集群计算框架，它支持编写分布式处理程序，支持从多个数据源获取数据，支持在多台机器上进行大规模并行计算，实现高性能处理和分析大数据集的功能。
4. YARN框架：YARN是Hadoop的资源管理框架，它可以管理集群上的所有资源，并实现较为高效的资源分配。
5. 集群管理系统：Hadoop的集群管理系统可以监控、管理和维护集群的整个运行状态，提供对容错、拓扑变更等功能的支持，实现集群缩放和稳定运行。
- 1 -。
大数据资料之Kudu
第 2 章 Kudu 快速入门 2.1 安装 2.1.1 点击主机下面的 Parcel
2.1.2 点击 KUDU 对应的下载，下载完后点击分配、激活 2.1.3 回到首页点击添加服务
2.1.4 选择 KUDU 选择继续 2.1.5 分配角色
2.1.6 设置 master 和 Tablet 路径
/etc/init.d/ntpd restart
2.2 配置 impala 支持 kudu 2.2.1 点击 impala
2.2.2 点击配置
2.2.3 找到 Kudu 服务，选择 Kudu 后重启 impala
2.3 使用案例 2.3.1 创建表
从 Impala 在 Kudu 中创建一个新表类似于将现有的 Kudu 表映射到 Impala 表， 但需要自己指定模式和分区信息。
2.3.2 查询 Impala 中现有的 Kudu 表
通过 Kudu API 或其他集成（如 Apache Spark ）创建的表不会在 Impala 中自动显 示。要查询它们，必须先在 Impala 中创建外部表以将 Kudu 表映射到 Impala 数据库中：
CREATE EXTERNAL TABLE my_mapping_table STORED AS KUDU TBLPROPERTIES (
e.printStackTrace(); } finally {
client.close(); }
} }
3.3 删除表
import org.apache.kudu.client.KuduClient; import org.apache.kudu.client.KuduException;
public class DropTable {
网易视频云：网盘背后的存储系统atlas
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PASS服务。
在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。
现在，网易视频云与大家分享一下百度网盘背后的存储系统atlas.百度网盘免费提供2TB存储，它的存储量一定是惊人的，支持它的存储系统atlas也是相当不错的。
atlas是一个KV存储，支持GET/PUT/DELETE三个接口，看起来接口简单，但要做好这么一个大规模系统非常不易，我们来看看atlas到底长啥样。
atlas基于如图所示arm存储机, 2U放6个机器，每个机器4核、4GB内存、4个3T硬盘，2U 总共72TB存储，相比普通机架服务器，存储密度提升1倍。
arm存储机的内存量过小，而文件系统产生的元数据过大，考虑性能原因不能把文件存储成文件。
甚至也不能采用haystack存储方式，haystack 元数据虽然小，但也超过ARM存储机的内存量。
atlas架构如上图所示，altas采用分布式元数据管理机制, 根据哈希策略将对象元数据切片成N个slice，这些slice交由PIS（Patch and Index Server）集群管理，每个PIS节点负责管理多个slice。
slice 到PIS的映射表通过元数据服务器管理（图中未画出），映射表较小，能被客户端全量缓存。
PIS的结构如上图所示，replication模块以主从复制方式保证slice三副本一致性。
写请求发往主节点，主节点生成唯一请求ID之后将ID和请求转发给从节点，从节点接收到请求之后，追加到patch模块维护的log文件。
请求ID的作用是串行化写，即从节点按照ID排序串行化执行请求。
主节点至少收到一个从节点的响应后，将KV写入本地，并告诉客户端写成功。
（如何保证一致性？）。
网易视频云技术分享：HBase优化实战
网易视频云技术分享：HBase优化实战网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PAAS 服务，在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。
现在，网易视频云的技术专家给大家分享一则技术文：HBase 优化实战。
背景Datastream一直以来在使用HBase分流日志，每天的数据量很大，日均大概在80亿条，10TB的数据。
对于像Datastream这种数据量巨大、对写入要求非常高，并且没有复杂查询需求的日志系统来说，选用HBase作为其数据存储平台，无疑是一个非常不错的选择。
HBase是一个相对较复杂的分布式系统，并发写入的性能非常高。
然而，分布式系统从结构上来讲，也相对较复杂，模块繁多，各个模块之间也很容易出现一些问题，所以对像HBase这样的大型分布式系统来说，优化系统运行，及时解决系统运行过程中出现的问题也变得至关重要。
正所谓：“你”若安好，便是晴天；“你”若有恙，我便没有星期天。
历史现状HBase交接到我们团队手上时，已经在线上运行有一大段时间了，期间也偶尔听到过系统不稳定的、时常会出现一些问题的言论，但我们认为：一个能被大型互联网公司广泛采用的系统(包括Facebook，twitter，淘宝，小米等)，其在性能和可用性上是毋庸置疑的，何况像Facebook这种公司，是在经过严格选型后，放弃了自己开发的Cassandra系统，用HBase取而代之。
既然这样，那么，HBase的不稳定、经常出问题一定有些其他的原因，应用反应经常会过段时间出现数据写入缓慢，导致应用端数据堆积现象，是否可以通过增加机器数量来解决？其实，那个时候，我们本身对HBase也不是很熟悉，对HBase的了解，也仅仅在做过一些测试，了解一些性能，对内部结构，实现原理之类的基本上都不怎么清楚。
大数据存储与处理技术考试 选择题 64题
1. 在大数据处理中，Hadoop的核心组件是：A. HDFSB. MapReduceC. YARND. 以上都是2. HDFS的默认块大小是多少？A. 64MBB. 128MBC. 256MBD. 1GB3. 以下哪个不是NoSQL数据库的类型？A. 键值存储B. 列存储C. 文档存储D. 关系型数据库4. 在MapReduce框架中，哪个阶段负责数据的洗牌和排序？A. Map阶段B. Reduce阶段C. Shuffle阶段D. Sort阶段5. Spark的核心抽象是什么？A. RDDB. DataFrameC. DatasetD. Graph6. 以下哪个是Spark的内存计算引擎？A. HadoopB. FlinkC. TezD. Mesos7. 在HBase中，数据模型是基于什么？A. 表B. 行C. 列族D. 单元格8. 以下哪个是HBase的存储引擎？A. HDFSB. MapReduceC. CassandraD. RocksDB9. 在Kafka中，消息的持久化是通过什么实现的？A. 日志B. 队列C. 缓存D. 数据库10. 以下哪个是Kafka的主要组件？A. ProducerB. ConsumerC. BrokerD. 以上都是11. 在Spark中，以下哪个操作会触发实际的计算？A. mapB. filterC. collectD. cache12. 以下哪个是Spark的分布式计算框架？A. HadoopB. FlinkC. TezD. Mesos13. 在Hive中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. MySQL14. 以下哪个是Hive的查询语言？A. SQLB. HQLC. HiveQLD. PL/SQL15. 在Pig中，数据流是通过什么表示的？A. 脚本B. 图C. 表D. 文件16. 以下哪个是Pig的执行引擎？A. HadoopB. TezC. Spark17. 在Cassandra中，数据模型是基于什么？A. 表B. 行C. 列族D. 单元格18. 以下哪个是Cassandra的存储引擎？A. HDFSB. RocksDBC. LevelDBD. Bigtable19. 在Elasticsearch中，数据存储在什么地方？A. 索引B. 文档C. 类型D. 字段20. 以下哪个是Elasticsearch的查询语言？A. SQLB. DSLC. LuceneD. JSON21. 在Neo4j中，数据模型是基于什么？A. 节点B. 关系C. 属性D. 以上都是22. 以下哪个是Neo4j的查询语言？A. CypherB. GremlinC. SQLD. HQL23. 在Redis中，数据模型是基于什么？A. 键值对B. 列表C. 集合D. 有序集合24. 以下哪个是Redis的存储引擎？A. RocksDBC. InnoDBD. 内存25. 在MongoDB中，数据模型是基于什么？A. 文档B. 集合C. 数据库D. 字段26. 以下哪个是MongoDB的查询语言？A. SQLB. MongoDB Query LanguageC. JSOND. BSON27. 在Flink中，数据流是通过什么表示的？A. 数据集B. 数据流C. 数据管道D. 数据图28. 以下哪个是Flink的执行引擎？A. HadoopB. TezC. SparkD. Flink29. 在Tez中，数据流是通过什么表示的？A. 图B. 表C. 文件D. 脚本30. 以下哪个是Tez的执行引擎？A. HadoopB. TezC. SparkD. Flink31. 在Presto中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. MySQL32. 以下哪个是Presto的查询语言？B. HQLC. HiveQLD. PrestoQL33. 在Impala中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. MySQL34. 以下哪个是Impala的查询语言？A. SQLB. HQLC. HiveQLD. ImpalaQL35. 在Kudu中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Kudu36. 以下哪个是Kudu的查询语言？A. SQLB. HQLC. HiveQLD. KuduQL37. 在Druid中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Druid38. 以下哪个是Druid的查询语言？A. SQLB. HQLC. HiveQLD. DruidQL39. 在ClickHouse中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. ClickHouse40. 以下哪个是ClickHouse的查询语言？B. HQLC. HiveQLD. ClickHouseQL41. 在Bigtable中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Bigtable42. 以下哪个是Bigtable的查询语言？A. SQLB. HQLC. HiveQLD. BigtableQL43. 在Spanner中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Spanner44. 以下哪个是Spanner的查询语言？A. SQLB. HQLC. HiveQLD. SpannerQL45. 在TiDB中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. TiDB46. 以下哪个是TiDB的查询语言？A. SQLB. HQLC. HiveQLD. TiDBQL47. 在CockroachDB中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. CockroachDB48. 以下哪个是CockroachDB的查询语言？B. HQLC. HiveQLD. CockroachDBQL49. 在VoltDB中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. VoltDB50. 以下哪个是VoltDB的查询语言？A. SQLB. HQLC. HiveQLD. VoltDBQL51. 在MemSQL中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. MemSQL52. 以下哪个是MemSQL的查询语言？A. SQLB. HQLC. HiveQLD. MemSQLQL53. 在Greenplum中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Greenplum54. 以下哪个是Greenplum的查询语言？A. SQLB. HQLC. HiveQLD. GreenplumQL55. 在Snowflake中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Snowflake56. 以下哪个是Snowflake的查询语言？B. HQLC. HiveQLD. SnowflakeQL57. 在Redshift中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Redshift58. 以下哪个是Redshift的查询语言？A. SQLB. HQLC. HiveQLD. RedshiftQL59. 在BigQuery中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. BigQuery60. 以下哪个是BigQuery的查询语言？A. SQLB. HQLC. HiveQLD. BigQueryQL61. 在Athena中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Athena62. 以下哪个是Athena的查询语言？A. SQLB. HQLC. HiveQLD. AthenaQL63. 在Azure Data Lake Storage中，数据存储在什么地方？A. HDFSB. HBaseC. CassandraD. Azure Data Lake Storage64. 以下哪个是Azure Data Lake Storage的查询语言？B. HQLC. HiveQLD. Azure Data Lake StorageQL 答案：1. D2. B3. D4. C5. A6. D7. C8. A9. A10. D11. C12. D13. A14. C15. A16. B17. D18. B19. A20. B21. D22. A23. A24. D25. B26. B27. B28. D29. A30. B31. A32. A33. A34. A35. D36. A37. D38. A39. D40. A41. D42. A43. D44. A45. D46. A47. D48. A49. D50. A51. D52. A53. D54. A55. D56. A57. D58. A59. D60. A61. D62. A63. D64. A。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
网易视频云：Kudu，支持快速分析的新型Hadoop存储系统网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。
在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。
Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的新成员之一（incubating），专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。
本文主要对Kudu的动机、背景，以及架构进行简单介绍。
背景——功能上的空白Hadoop生态系统有很多组件，每一个组件有不同的功能。
在现实场景中，用户往往需要同时部署很多Hadoop工具来解决同一个问题，这种架构称为混合架构(hybrid architecture)。
比如，用户需要利用Hbase的快速插入、快读random access的特性来导入数据，HBase也允许用户对数据进行修改，HBase对于大量小规模查询也非常迅速。
同时，用户使用HDFS/Parquet + Impala/Hive来对超大的数据集进行查询分析，对于这类场景，Parquet这种列式存储文件格式具有极大的优势。
很多公司都成功地部署了HDFS/Parquet + HBase混合架构，然而这种架构较为复杂，而且在维护上也十分困难。
首先，用户用Flume或Kafka等数据Ingest工具将数据导入HBase，用户可能在HBase上对数据做一些修改。
然后每隔一段时间(每天或每周)将数据从Hbase中导入到Parquet文件，作为一个新的partition放在HDFS上，最后使用Impala等计算引擎进行查询，生成最终报表。
这样一条工具链繁琐而复杂，而且还存在很多问题，比如：∙ 如何处理某一过程出现失败？∙ 从HBase将数据导出到文件，多久的频率比较合适？∙ 当生成最终报表时，最近的数据并无法体现在最终查询结果上。
∙ 维护集群时，如何保证关键任务不失败？∙ Parquet是immutable，因此当HBase中删改某些历史数据时，往往需要人工干预进行同步。
这时候，用户就希望能够有一种优雅的存储解决方案，来应付不同类型的工作流，并保持高性能的计算能力。
Cloudera很早就意识到这个问题，在2012年就开始计划开发Kudu这个存储系统，终于在2015年发布并开源出来。
Kudu是对HDFS和HBase功能上的补充，能提供快速的分析和实时计算能力，并且充分利用CPU和I/O资源，支持数据原地修改，支持简单的、可扩展的数据模型。
背景——新的硬件设备RAM的技术发展非常快，它变得越来越便宜，容量也越来越大。
Cloudera的客户数据显示，他们的客户所部署的服务器，2012年每个节点仅有32GB RAM，现如今增长到每个节点有128GB或256GB RAM。
存储设备上更新也非常快，在很多普通服务器中部署SSD 也是屡见不鲜。
HBase、HDFS、以及其他的Hadoop工具都在不断自我完善，从而适应硬件上的升级换代。
然而，从根本上，HDFS基于03年GFS，HBase基于05年BigTable，在当时系统瓶颈主要取决于底层磁盘速度。
当磁盘速度较慢时，CPU利用率不足的根本原因是磁盘速度导致的瓶颈，当磁盘速度提高了之后，CPU利用率提高，这时候CPU往往成为系统的瓶颈。
HBase、HDFS由于年代久远，已经很难从基本架构上进行修改，而Kudu 是基于全新的设计，因此可以更充分地利用RAM、I/O资源，并优化CPU利用率。
我们可以理解为，Kudu相比与以往的系统，CPU使用降低了，I/O的使用提高了，RAM的利用更充分了。
简介Kudu设计之初，是为了解决一下问题：∙ 对数据扫描(scan)和随机访问(random access)同时具有高性能，简化用户复杂的混合架构∙ 高CPU效率，使用户购买的先进处理器的的花费得到最大回报∙ 高IO性能，充分利用先进存储介质∙ 支持数据的原地更新，避免额外的数据处理、数据移动∙ 支持跨数据中心replicationKudu的很多特性跟HBase很像，它支持索引键的查询和修改。
Cloudera曾经想过基于Hbase进行修改，然而结论是对HBase的改动非常大，Kudu的数据模型和磁盘存储都与Hbase不同。
HBase本身成功的适用于大量的其它场景，因此修改HBase很可能吃力不讨好。
最后Cloudera决定开发一个全新的存储系统。
Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的数据上进行快速的查询。
它定位OLAP和少量的OLTP工作流，如果有大量的random accesses，官方建议还是使用HBase最为合适。
架构与设计1.基本框架Kudu是用于存储结构化（structured）的表（Table）。
表有预定义的带类型的列（Columns），每张表有一个主键（primary key）。
主键带有唯一性（uniqueness）限制，可作为索引用来支持快速的random access。
类似于BigTable，Kudu的表是由很多数据子集构成的，表被水平拆分成多个Tablets. Kudu 用以每个tablet为一个单元来实现数据的durability。
Tablet有多个副本，同时在多个节点上进行持久化。
Kudu有两种类型的组件，Master Server和Tablet Server。
Master负责管理元数据。
这些元数据包括talbet的基本信息，位置信息。
Master还作为负载均衡服务器，监听Tablet Server的健康状态。
对于副本数过低的Tablet，Master会在起replication任务来提高其副本数。
Master的所有信息都在内存中cache，因此速度非常快。
每次查询都在百毫秒级别。
Kudu支持多个Master，不过只有一个active Master，其余只是作为灾备，不提供服务。
Tablet Server上存了10~100个Tablets，每个Tablet有3（或5）个副本存放在不同的Tablet Server上，每个Tablet同时只有一个leader副本，这个副本对用户提供修改操作，然后将修改结果同步给follower。
Follower只提供读服务，不提供修改服务。
副本之间使用raft协议来实现High Availability，当leader所在的节点发生故障时，followers 会重新选举leader。
根据官方的数据，其MTTR约为5秒，对client端几乎没有影响。
Raft 协议的另一个作用是实现Consistency。
Client对leader的修改操作，需要同步到N/2+1个节点上，该操作才算成功。
Kudu采用了类似log-structured存储系统的方式，增删改操作都放在内存中的buffer，然后才merge到持久化的列式存储中。
Kudu还是用了WALs来对内存中的buffer 进行灾备。
2.列式存储持久化的列式存储存储，与HBase完全不同，而是使用了类似Parquet的方式，同一个列在磁盘上是作为一个连续的块进行存放的。
例如，图中左边是twitter保存推文的一张表，而图中的右边表示了表在磁盘中的的存储方式，也就是将同一个列放在一起存放。
这样做的第一个好处是，对于一些聚合和join语句，我们可以尽可能地减少磁盘的访问。
例如，我们要用户名为newsycbot的推文数量，使用查询语句：SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’;我们只需要查询User_name这个block即可。
同一个列的数据是集中的，而且是相同格式的，Kudu可以对数据进行编码，例如字典编码，行长编码，bitshuffle等。
通过这种方式可以很大的减少数据在磁盘上的大小，提高吞吐率。
除此之外，用户可以选择使用通用的压缩格式对数据进行压缩，如LZ4, gzip, 或bzip2。
这是可选的，用户可以根据业务场景，在数据大小和CPU效率上进行权衡。
这一部分的实现上，Kudu很大部分借鉴了Parquet的代码。
HBase支持snappy存储，然而因为它的LSM的数据存储方式，使得它很难对数据进行特殊编码，这也是Kudu声称具有很快的scan速度的一个很重要的原因。
不过，因为列式编码后的数据很难再进行修改，因此当这写数据写入磁盘后，是不可变的，这部分数据称之为base数据。
Kudu用MVCC（多版本并发控制）来实现数据的删改功能。
更新、删除操作需要记录到特殊的数据结构里，保存在内存中的DeltaMemStore或磁盘上的DeltaFIle里面。
DeltaMemStore是B-Tree实现的，因此速度快，而且可修改。
磁盘上的DeltaFIle是二进制的列式的块，和base数据一样都是不可修改的。
因此当数据频繁删改的时候，磁盘上会有大量的DeltaFiles文件，Kudu借鉴了Hbase的方式，会定期对这些文件进行合并。
3.对外接口Kudu提供C++和JAVA API，可以进行单条或批量的数据读写，schema的创建修改。
除此之外，Kudu还将与hadoop生态圈的其它工具进行整合。
目前，kudu beta版本对Impala支持较为完善，支持用Impala进行创建表、删改数据等大部分操作。
Kudu 还实现了KuduTableInputFormat和KuduTableOutputFormat，从而支持Mapreduce 的读写操作。
同时支持数据的locality。
目前对spark的支持还不够完善，spark只能进行数据的读操作。
使用案例——小米小米是Hbase的重度用户，他们每天有约50亿条用户记录。
小米目前使用的也是HDFS + HBase这样的混合架构。
可见该流水线相对比较复杂，其数据存储分为SequenceFile，Hbase和Parquet。
在使用Kudu以后，Kudu作为统一的数据仓库，可以同时支持离线分析和实时交互分析。
性能测试1. 和parquet的比较图是官方给出的用Impala跑TPC-H的测试，对比Parquet和Kudu的计算速度。
从图中我们可以发现，Kudu的速度和parquet的速度差距不大，甚至有些Query比parquet还快。
然而，由于这些数据都是在内存缓存过的，因此该测试结果不具备参考价值。
2.和Hbase的比较图是官方给出的另一组测试结果，从图中我们可以看出，在scan和range查询上，kudu和parquet比HBase快很多，而random access则比HBase稍慢。