-.z網(wǎng)易視頻云：Kudu，支持快速分析的新型Hadoop存儲(chǔ)系統(tǒng)網(wǎng)易視頻云是網(wǎng)易傾力打造的一款基于云計(jì)算的分布式多媒體處理集群和專業(yè)音視頻技術(shù)，為客戶提供穩(wěn)定流暢、低時(shí)延、高并發(fā)的視頻直播、錄制、存儲(chǔ)、轉(zhuǎn)碼及點(diǎn)播等音視頻的PaaS效勞。在線教育、遠(yuǎn)程醫(yī)療、娛樂(lè)秀場(chǎng)、在線金融等各行業(yè)及企業(yè)用戶只需經(jīng)過(guò)簡(jiǎn)單的開(kāi)發(fā)即可打造在在線音視頻平臺(tái)。Kudu是Cloudera開(kāi)源的新型列式存儲(chǔ)系統(tǒng)，是ApacheHadoop生態(tài)圈的新成員之一〔incubating〕，專門為了對(duì)快速變化的數(shù)據(jù)進(jìn)展快速的分析，填補(bǔ)了以往Hadoop存儲(chǔ)層的空缺。本文主要對(duì)Kudu的動(dòng)機(jī)、背景，以及架構(gòu)進(jìn)展簡(jiǎn)單介紹。背景——功能上的空白Hadoop生態(tài)系統(tǒng)有很多組件，每一個(gè)組件有不同的功能。在現(xiàn)實(shí)場(chǎng)景中，用戶往往需要同時(shí)部署很多Hadoop工具來(lái)解決同一個(gè)問(wèn)題，這種架構(gòu)稱為混合架構(gòu)(hybridarchitecture)。比方，用戶需要利用Hbase的快速插入、快讀randomaccess的特性來(lái)導(dǎo)入數(shù)據(jù)，HBase也允許用戶對(duì)數(shù)據(jù)進(jìn)展修改，HBase對(duì)于大量小規(guī)模查詢也非常迅速。同時(shí)，用戶使用HDFS/Parquet+Impala/Hive來(lái)對(duì)超大的數(shù)據(jù)集進(jìn)展查詢分析，對(duì)于這類場(chǎng)景，Parquet這種列式存儲(chǔ)文件格式具有極大的優(yōu)勢(shì)。很多公司都成功地部署了HDFS/Parquet+HBase混合架構(gòu)，然而這種架構(gòu)較為復(fù)雜，而且在維護(hù)上也十分困難。首先，用戶用Flume或Kafka等數(shù)據(jù)Ingest工具將數(shù)據(jù)導(dǎo)入HBase，用戶可能在HBase上對(duì)數(shù)據(jù)做一些修改。然后每隔一段時(shí)間(每天或每周)將數(shù)據(jù)從Hbase中導(dǎo)入到Parquet文件，作為一個(gè)新的partition放在HDFS上，最后使用Impala等計(jì)算引擎進(jìn)展查詢，生成最終報(bào)表。這樣一條工具鏈繁瑣而復(fù)雜，而且還存在很多問(wèn)題，比方：?如何處理*一過(guò)程出現(xiàn)失敗.?從HBase將數(shù)據(jù)導(dǎo)出到文件，多久的頻率比較適宜.?當(dāng)生成最終報(bào)表時(shí)，最近的數(shù)據(jù)并無(wú)法表達(dá)在最終查詢結(jié)果上。?維護(hù)集群時(shí)，如何保證關(guān)鍵任務(wù)不失敗.?Parquet是immutable，因此當(dāng)HBase中刪改*些歷史數(shù)據(jù)時(shí)，往往需要人工干預(yù)進(jìn)展同步。這時(shí)候，用戶就希望能夠有一種優(yōu)雅的存儲(chǔ)解決方案，來(lái)應(yīng)付不同類型的工作流，并保持高性能的計(jì)算能力。Cloudera很早就意識(shí)到這個(gè)問(wèn)題，在2021年就開(kāi)場(chǎng)方案開(kāi)發(fā)Kudu這個(gè)存儲(chǔ)系統(tǒng)，終于在2021年發(fā)布并開(kāi)源出來(lái)。Kudu是對(duì)HDFS和HBase功能上的補(bǔ)充，能提供快速的分析和實(shí)時(shí)計(jì)算能力，并且充分利用CPU和I/O資源，支持?jǐn)?shù)據(jù)原地修改，支持簡(jiǎn)單的、可擴(kuò)展的數(shù)據(jù)模型。背景——新的硬件設(shè)備RAM的技術(shù)開(kāi)展非常快，它變得越來(lái)越廉價(jià)，容量也越來(lái)越大。Cloudera的客戶數(shù)據(jù)顯示，他們的客戶所部署的效勞器，2021年每個(gè)節(jié)點(diǎn)僅有32GBRAM，現(xiàn)如今增長(zhǎng)到每個(gè)節(jié)點(diǎn)有128GB或256GBRAM。存儲(chǔ)設(shè)備上更新也非?？?，在很多普通效勞器中部署SSD也是屢見(jiàn)不鮮。HBase、HDFS、以及其他的Hadoop工具都在不斷自我完善，從而適應(yīng)硬件上的升級(jí)換代。然而，從根本上，HDFS基于03年GFS，HBase基于05年BigTable，在當(dāng)時(shí)系統(tǒng)瓶頸主要取決于底層磁盤速度。當(dāng)磁盤速度較慢時(shí)，CPU利用率缺乏的根本原因是磁盤速度導(dǎo)致的瓶頸，當(dāng)磁盤速度提高了之后，CPU利用率提高，這時(shí)候CPU往往成為系統(tǒng)的瓶頸。HBase、HDFS由于年代長(zhǎng)遠(yuǎn)，已經(jīng)很難從根本架構(gòu)上進(jìn)展修改，而Kudu是基于全新的設(shè)計(jì)，因此可以更充分地利用RAM、I/O資源，并優(yōu)化CPU利用率。我們可以理解為，Kudu相比與以往的系統(tǒng)，CPU使用降低了，I/O的使用提高了，RAM的利用更充分了。簡(jiǎn)介Kudu設(shè)計(jì)之初，是為了解決一下問(wèn)題：?對(duì)數(shù)據(jù)掃描(scan)和隨機(jī)訪問(wèn)(randomaccess)同時(shí)具有高性能，簡(jiǎn)化用戶復(fù)雜的混合架構(gòu)?高CPU效率，使用戶購(gòu)置的先進(jìn)處理器的的花費(fèi)得到最大回報(bào)?高IO性能，充分利用先進(jìn)存儲(chǔ)介質(zhì)?支持?jǐn)?shù)據(jù)的原地更新，防止額外的數(shù)據(jù)處理、數(shù)據(jù)移動(dòng)?支持跨數(shù)據(jù)中心replicationKudu的很多特性跟HBase很像，它支持索引鍵的查詢和修改。Cloudera曾經(jīng)想過(guò)基于Hbase進(jìn)展修改，然而結(jié)論是對(duì)HBase的改動(dòng)非常大，Kudu的數(shù)據(jù)模型和磁盤存儲(chǔ)都與Hbase不同。HBase本身成功的適用于大量的其它場(chǎng)景，因此修改HBase很可能吃力不討好。最后Cloudera決定開(kāi)發(fā)一個(gè)全新的存儲(chǔ)系統(tǒng)。Kudu的定位是提供〞fastanalyticsonfastdata〞，也就是在快速更新的數(shù)據(jù)上進(jìn)展快速的查詢。它定位OLAP和少量的OLTP工作流，如果有大量的randomaccesses，官方建議還是使用HBase最為適宜。架構(gòu)與設(shè)計(jì)1.根本框架Kudu是用于存儲(chǔ)構(gòu)造化〔structured〕的表〔Table〕。表有預(yù)定義的帶類型的列〔Columns〕，每*表有一個(gè)主鍵〔primarykey〕。主鍵帶有唯一性〔uniqueness〕限制，可作為索引用來(lái)支持快速的randomaccess。類似于BigTable，Kudu的表是由很多數(shù)據(jù)子集構(gòu)成的，表被水平拆分成多個(gè)Tablets.Kudu用以每個(gè)tablet為一個(gè)單元來(lái)實(shí)現(xiàn)數(shù)據(jù)的durability。Tablet有多個(gè)副本，同時(shí)在多個(gè)節(jié)點(diǎn)上進(jìn)展持久化。Kudu有兩種類型的組件，MasterServer和TabletServer。Master負(fù)責(zé)管理元數(shù)據(jù)。這些元數(shù)據(jù)包括talbet的根本信息，位置信息。Master還作為負(fù)載均衡效勞器，監(jiān)聽(tīng)TabletServer的安康狀態(tài)。對(duì)于副本數(shù)過(guò)低的Tablet，Master會(huì)在起replication任務(wù)來(lái)提高其副本數(shù)。Master的所有信息都在內(nèi)存中cache，因此速度非?？?。每次查詢都在百毫秒級(jí)別。Kudu支持多個(gè)Master，不過(guò)只有一個(gè)activeMaster，其余只是作為災(zāi)備，不提供效勞。TabletServer上存了10~100個(gè)Tablets，每個(gè)Tablet有3〔或5〕個(gè)副本存放在不同的TabletServer上，每個(gè)Tablet同時(shí)只有一個(gè)leader副本，這個(gè)副本對(duì)用戶提供修改操作，然后將修改結(jié)果同步給follower。Follower只提供讀效勞，不提供修改效勞。副本之間使用raft協(xié)議來(lái)實(shí)現(xiàn)HighAvailability，當(dāng)leader所在的節(jié)點(diǎn)發(fā)生故障時(shí)，followers會(huì)重新選舉leader。根據(jù)官方的數(shù)據(jù)，其MTTR約為5秒，對(duì)client端幾乎沒(méi)有影響。Raft協(xié)議的另一個(gè)作用是實(shí)現(xiàn)Consistency。Client對(duì)leader的修改操作，需要同步到N/2+1個(gè)節(jié)點(diǎn)上，該操作才算成功。Kudu采用了類似log-structured存儲(chǔ)系統(tǒng)的方式，增刪改操作都放在內(nèi)存中的buffer，然后才merge到持久化的列式存儲(chǔ)中。Kudu還是用了WALs來(lái)對(duì)內(nèi)存中的buffer進(jìn)展災(zāi)備。2.列式存儲(chǔ)持久化的列式存儲(chǔ)存儲(chǔ)，與HBase完全不同，而是使用了類似Parquet的方式，同一個(gè)列在磁盤上是作為一個(gè)連續(xù)的塊進(jìn)展存放的。例如，圖中左邊是twitter保存推文的一*表，而圖中的右邊表示了表在磁盤中的的存儲(chǔ)方式，也就是將同一個(gè)列放在一起存放。這樣做的第一個(gè)好處是，對(duì)于一些聚合和join語(yǔ)句，我們可以盡可能地減少磁盤的訪問(wèn)。例如，我們要用戶名為newsycbot的推文數(shù)量，使用查詢語(yǔ)句：SELECTCOUNT(*)FROMtweetsWHEREuser_name=‘newsycbot’;我們只需要查詢User_name這個(gè)block即可。同一個(gè)列的數(shù)據(jù)是集中的，而且是一樣格式的，Kudu可以對(duì)數(shù)據(jù)進(jìn)展編碼，例如字典編碼，行長(zhǎng)編碼，bitshuffle等。通過(guò)這種方式可以很大的減少數(shù)據(jù)在磁盤上的大小，提高吞吐率。除此之外，用戶可以選擇使用通用的壓縮格式對(duì)數(shù)據(jù)進(jìn)展壓縮，如LZ4,gzip,或bzip2。這是可選的，用戶可以根據(jù)業(yè)務(wù)場(chǎng)景，在數(shù)據(jù)大小和CPU效率上進(jìn)展權(quán)衡。這一局部的實(shí)現(xiàn)上，Kudu很大局部借鑒了Parquet的代碼。HBase支持snappy存儲(chǔ)，然而因?yàn)樗腖SM的數(shù)據(jù)存儲(chǔ)方式，使得它很難對(duì)數(shù)據(jù)進(jìn)展特殊編碼，這也是Kudu聲稱具有很快的scan速度的一個(gè)很重要的原因。不過(guò)，因?yàn)榱惺骄幋a后的數(shù)據(jù)很難再進(jìn)展修改，因此當(dāng)這寫數(shù)據(jù)寫入磁盤后，是不可變的，這局部數(shù)據(jù)稱之為base數(shù)據(jù)。Kudu用MVCC〔多版本并發(fā)控制〕來(lái)實(shí)現(xiàn)數(shù)據(jù)的刪改功能。更新、刪除操作需要記錄到特殊的數(shù)據(jù)構(gòu)造里，保存在內(nèi)存中的DeltaMemStore或磁盤上的DeltaFIle里面。DeltaMemStore是B-Tree實(shí)現(xiàn)的，因此速度快，而且可修改。磁盤上的DeltaFIle是二進(jìn)制的列式的塊，和base數(shù)據(jù)一樣都是不可修改的。因此當(dāng)數(shù)據(jù)頻繁刪改的時(shí)候，磁盤上會(huì)有大量的DeltaFiles文件，Kudu借鑒了Hbase的方式，會(huì)定期對(duì)這些文件進(jìn)展合并。3.對(duì)外接口Kudu提供C++和JAVAAPI，可以進(jìn)展單條或批量的數(shù)據(jù)讀寫，schema的創(chuàng)立修改。除此之外，Kudu還將與hadoop生態(tài)圈的其它工具進(jìn)展整合。目前，kudubeta版本對(duì)Impala支持較為完善，支持用Impala進(jìn)展創(chuàng)立表、刪改數(shù)據(jù)等大局部操作。Kudu還實(shí)現(xiàn)了KuduTableInputFormat和KuduTableOutputFormat，從而支持Mapreduce的讀寫操作。同時(shí)支持?jǐn)?shù)據(jù)的locality。目前對(duì)spark的支持還不夠完善，spark只能進(jìn)展數(shù)據(jù)的讀操作。使用案例——小米小米是Hbase的重度用戶，他們每天有約50億條用戶記錄。小米目前使用的也是HDFS+HBase這樣的混合架構(gòu)?？梢?jiàn)該流水線相比照擬復(fù)雜，其數(shù)據(jù)存儲(chǔ)分為SequenceFile，Hbase和Parquet。在使用Kudu以后，Kudu作為統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)，可以同時(shí)支持離線分析和實(shí)時(shí)交互分析。性能測(cè)試1.和parquet的比較圖是官方給出的用Impala跑TPC-H的測(cè)試，比照Parquet和Kudu的計(jì)算速度。從圖中我們可以發(fā)現(xiàn)，Kudu的速度和parquet的速度差距不大，甚至有些Query比parquet還快。然而，由于這些數(shù)據(jù)都是在內(nèi)存緩存過(guò)的，因此該測(cè)試結(jié)果不具備參考價(jià)值。2.和Hbase的比較圖是官方給出的另一組測(cè)試結(jié)果，從圖中我們可以看出，在scan和range查詢上，kudu和parquet比HBase快很多，而randomaccess則比HBase稍慢。然而數(shù)據(jù)集只有60億行數(shù)據(jù)，所以很可能這些數(shù)據(jù)也是可以全部緩存在內(nèi)存的。對(duì)于從內(nèi)存查詢，除了randomaccess比HBase慢之外，kudu的速度根本要優(yōu)于HBase。3.超大數(shù)據(jù)集的查詢性能Kudu的定位不是in-memorydatab