• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 200, comments - 8, trackbacks - 0, articles - 0

            HBase簡(jiǎn)介(很好的梳理資料)

            Posted on 2013-06-07 22:14 鑫龍 閱讀(337) 評(píng)論(0)  編輯 收藏 引用 所屬分類: HBASE

            一、 簡(jiǎn)介

            history

            started by chad walters and jim

            2006.11 G release paper on BigTable

            2007.2 inital HBase prototype created as Hadoop contrib

            2007.10 First useable Hbase

            2008.1 Hadoop become Apache top-level project and Hbase becomes subproject

            2008.10 Hbase 0.18,0.19 released

             

            hbase是bigtable的開源山寨版本。是建立的hdfs之上,提供高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)。

            它介于nosql和RDBMS之間,僅能通過主鍵(row key)和主鍵的range來檢索數(shù)據(jù),僅支持單行事務(wù)(可通過hive支持來實(shí)現(xiàn)多表join等復(fù)雜操作)。主要用來存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。

            與hadoop一樣,Hbase目標(biāo)主要依靠橫向擴(kuò)展,通過不斷增加廉價(jià)的商用服務(wù)器,來增加計(jì)算和存儲(chǔ)能力。

             

            HBase中的表一般有這樣的特點(diǎn):

            1 大:一個(gè)表可以有上億行,上百萬列

            2 面向列:面向列(族)的存儲(chǔ)和權(quán)限控制,列(族)獨(dú)立檢索。

            3 稀疏:對(duì)于為空(null)的列,并不占用存儲(chǔ)空間,因此,表可以設(shè)計(jì)的非常稀疏。

             

            下面一幅圖是Hbase在Hadoop Ecosystem中的位置。




            二、 邏輯視圖


            HBase以表的形式存儲(chǔ)數(shù)據(jù)。表有行和列組成。列劃分為若干個(gè)列族(row family)

            Row Keycolumn-family1column-family2column-family3
            column1column1column1column2column3column1
            key1t1:abc
            t2:gdxdf
            t4:dfads
            t3:hello
            t2:world
            key2t3:abc
            t1:gdxdf
            t4:dfads
            t3:hello
            t2:dfdsfa
            t3:dfdf
            key3t2:dfadfasd
            t1:dfdasddsf
            t2:dfxxdfasd

            t1:taobao.com

             

            Row Key

            與nosql數(shù)據(jù)庫們一樣,row key是用來檢索記錄的主鍵。訪問hbase table中的行,只有三種方式:

            1 通過單個(gè)row key訪問

            2 通過row key的range

            3 全表掃描

            Row key行鍵 (Row key)可以是任意字符串(最大長(zhǎng)度是 64KB,實(shí)際應(yīng)用中長(zhǎng)度一般為 10-100bytes),在hbase內(nèi)部,row key保存為字節(jié)數(shù)組。

            存儲(chǔ)時(shí),數(shù)據(jù)按照Row key的字典序(byte order)排序存儲(chǔ)。設(shè)計(jì)key時(shí),要充分排序存儲(chǔ)這個(gè)特性,將經(jīng)常一起讀取的行存儲(chǔ)放到一起。(位置相關(guān)性)

            注意:

            字典序?qū)nt排序的結(jié)果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序,行鍵必須用0作左填充。

            行的一次讀寫是原子操作 (不論一次讀寫多少列)。這個(gè)設(shè)計(jì)決策能夠使用戶很容易的理解程序在對(duì)同一個(gè)行進(jìn)行并發(fā)更新操作時(shí)的行為。

             

            列族

            hbase表中的每個(gè)列,都?xì)w屬與某個(gè)列族。列族是表的chema的一部分(而列不是),必須在使用表之前定義。列名都以列族作為前綴。例如courses:history  courses:math 都屬于 courses 這個(gè)列族。

            訪問控制、磁盤和內(nèi)存的使用統(tǒng)計(jì)都是在列族層面進(jìn)行的。實(shí)際應(yīng)用中,列族上的控制權(quán)限能 幫助我們管理不同類型的應(yīng)用:我們?cè)试S一些應(yīng)用可以添加新的基本數(shù)據(jù)、一些應(yīng)用可以讀取基本數(shù)據(jù)并創(chuàng)建繼承的列族、一些應(yīng)用則只允許瀏覽數(shù)據(jù)(甚至可能因 為隱私的原因不能瀏覽所有數(shù)據(jù))。

             

            時(shí)間戳

            HBase中通過row和columns確定的為一個(gè)存貯單元稱為cell。每個(gè) cell都保存著同一份數(shù)據(jù)的多個(gè)版本。版本通過時(shí)間戳來索引。時(shí)間戳的類型是 64位整型。時(shí)間戳可以由hbase(在數(shù)據(jù)寫入時(shí)自動(dòng) )賦值,此時(shí)時(shí)間戳是精確到毫秒的當(dāng)前系統(tǒng)時(shí)間。時(shí)間戳也可以由客戶顯式賦值。如果應(yīng)用程序要避免數(shù)據(jù)版本沖突,就必須自己生成具有唯一性的時(shí)間戳。每個(gè) cell中,不同版本的數(shù)據(jù)按照時(shí)間倒序排序,即最新的數(shù)據(jù)排在最前面。

            為了避免數(shù)據(jù)存在過多版本造成的的管理 (包括存貯和索引)負(fù)擔(dān),hbase提供了兩種數(shù)據(jù)版本回收方式。一是保存數(shù)據(jù)的最后n個(gè)版本,二是保存最近一段時(shí)間內(nèi)的版本(比如最近七天)。用戶可以針對(duì)每個(gè)列族進(jìn)行設(shè)置。

             

            Cell

            {row key, column( =<family> + <label>), version} 唯一確定的單元。cell中的數(shù)據(jù)是沒有類型的,全部是字節(jié)碼形式存貯。

             

            三、 物理存儲(chǔ)

            1 已經(jīng)提到過,Table中的所有行都按照row key的字典序排列。

            2 Table 在行的方向上分割為多個(gè)Hregion。


            3 region按大小分割的,每個(gè)表一開始只有一個(gè)region,隨著數(shù)據(jù)不斷插入表,region不斷增大,當(dāng)增大到一個(gè)閥值的時(shí)候,Hregion就會(huì)等分會(huì)兩個(gè)新的Hregion。當(dāng)table中的行不斷增多,就會(huì)有越來越多的Hregion。

            4 Hregion是Hbase中分布式存儲(chǔ)和負(fù)載均衡的最小單元。最小單元就表示不同的Hregion可以分布在不同的HRegion server上。但一個(gè)Hregion是不會(huì)拆分到多個(gè)server上的。

            5 HRegion雖然是分布式存儲(chǔ)的最小單元,但并不是存儲(chǔ)的最小單元。

            事實(shí)上,HRegion由一個(gè)或者多個(gè)Store組成,每個(gè)store保存一個(gè)columns family。

            每個(gè)Strore又由一個(gè)memStore和0至多個(gè)StoreFile組成。如圖:

            StoreFile以HFile格式保存在HDFS上。




            HFile分為六個(gè)部分:

            Data Block 段–保存表中的數(shù)據(jù),這部分可以被壓縮

            Meta Block 段 (可選的)–保存用戶自定義的kv對(duì),可以被壓縮。

            File Info 段–Hfile的元信息,不被壓縮,用戶也可以在這一部分添加自己的元信息。

            Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。

            Meta Block Index段 (可選的)–Meta Block的索引。

            Trailer–這一段是定長(zhǎng)的。保存了每一段的偏移量,讀取一個(gè)HFile時(shí),會(huì)首先 讀取Trailer,Trailer保存了每個(gè)段的起始位置(段的Magic Number用來做安全check),然后,DataBlock Index會(huì)被讀取到內(nèi)存中,這樣,當(dāng)檢索某個(gè)key時(shí),不需要掃描整個(gè)HFile,而只需從內(nèi)存中找到key所在的block,通過一次磁盤io將整個(gè) block讀取到內(nèi)存中,再找到需要的key。DataBlock Index采用LRU機(jī)制淘汰。

            HFile的Data Block,Meta Block通常采用壓縮方式存儲(chǔ),壓縮之后可以大大減少網(wǎng)絡(luò)IO和磁盤IO,隨之而來的開銷當(dāng)然是需要花費(fèi)cpu進(jìn)行壓縮和解壓縮。

            目標(biāo)Hfile的壓縮支持兩種方式:Gzip,Lzo。

             

            HLog(WAL log)

            WAL 意為Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging),類似mysql中的binlog,用來 做災(zāi)難恢復(fù)只用,Hlog記錄數(shù)據(jù)的所有變更,一旦數(shù)據(jù)修改,就可以從log中進(jìn)行恢復(fù)。

            每個(gè)Region Server維護(hù)一個(gè)Hlog,而不是每個(gè)Region一個(gè)。這樣不同region(來自不同table)的日志會(huì)混在一起,這樣做的目的是不斷追加單個(gè) 文件相對(duì)于同時(shí)寫多個(gè)文件而言,可以減少磁盤尋址次數(shù),因此可以提高對(duì)table的寫性能。帶來的麻煩是,如果一臺(tái)region server下線,為了恢復(fù)其上的region,需要將region server上的log進(jìn)行拆分,然后分發(fā)到其它region server上進(jìn)行恢復(fù)。

            HLog文件就是一個(gè)普通的Hadoop Sequence File,Sequence File 的Key是HLogKey對(duì)象,HLogKey中記錄了寫入數(shù)據(jù)的歸屬信息,除了table和region名字外,同時(shí)還包括 sequence number和timestamp,timestamp是”寫入時(shí)間”,sequence number的起始值為0,或者是最近一次存入文件系統(tǒng)中sequence number。HLog Sequece File的Value是HBase的KeyValue對(duì)象,即對(duì)應(yīng)HFile中的KeyValue,可參見上文描述。

             

            四、 系統(tǒng)架構(gòu)


            Client

            1 包含訪問hbase的接口,client維護(hù)著一些cache來加快對(duì)hbase的訪問,比如regione的位置信息。

             

            Zookeeper

            1 保證任何時(shí)候,集群中只有一個(gè)master

            2 存貯所有Region的尋址入口。

            3 實(shí)時(shí)監(jiān)控Region Server的狀態(tài),將Region server的上線和下線信息實(shí)時(shí)通知給Master

            4 存儲(chǔ)Hbase的schema,包括有哪些table,每個(gè)table有哪些column family

             

            Master

            1 為Region server分配region

            2 負(fù)責(zé)region server的負(fù)載均衡

            3 發(fā)現(xiàn)失效的region server并重新分配其上的region

            4 GFS上的垃圾文件回收

            5 處理schema更新請(qǐng)求

             

            Region Server

            1 Region server維護(hù)Master分配給它的region,處理對(duì)這些region的IO請(qǐng)求

            2 Region server負(fù)責(zé)切分在運(yùn)行過程中變得過大的region

            可以看到,client訪問hbase上數(shù)據(jù)的過程并不需要master參與(尋址訪問zookeeper和region server,數(shù)據(jù)讀寫訪問regione server),master僅僅維護(hù)者table和region的元數(shù)據(jù)信息,負(fù)載很低。

             

            五、關(guān)鍵算法 / 流程

            region定位

            系統(tǒng)如何找到某個(gè)row key (或者某個(gè) row key range)所在的region

            bigtable 使用三層類似B+樹的結(jié)構(gòu)來保存region位置。

            第一層是保存zookeeper里面的文件,它持有root region的位置。

            第二層root region是.META.表的第一個(gè)region其中保存了.META.z表其它region的位置。通過root region,我們就可以訪問.META.表的數(shù)據(jù)。

            .META.是第三層,它是一個(gè)特殊的表,保存了hbase中所有數(shù)據(jù)表的region 位置信息。



            說明:

            1 root region永遠(yuǎn)不會(huì)被split,保證了最需要三次跳轉(zhuǎn),就能定位到任意region 。

            2.META.表每行保存一個(gè)region的位置信息,row key 采用表名+表的最后一樣編碼而成。

            3 為了加快訪問,.META.表的全部region都保存在內(nèi)存中。

            假設(shè),.META.表的一行在內(nèi)存中大約占用1KB。并且每個(gè)region限制為128MB。

            那么上面的三層結(jié)構(gòu)可以保存的region數(shù)目為:

            (128MB/1KB) * (128MB/1KB) = = 2(34)個(gè)region

            4 client會(huì)將查詢過的位置信息保存緩存起來,緩存不會(huì)主動(dòng)失效,因此如果client上的緩存全部失效,則需要進(jìn)行6次網(wǎng)絡(luò)來回,才能定位到正確的region(其中三次用來發(fā)現(xiàn)緩存失效,另外三次用來獲取位置信息)。

             

            讀寫過程

            上文提到,hbase使用MemStore和StoreFile存儲(chǔ)對(duì)表的更新。

            數(shù)據(jù)在更新時(shí)首先寫入Log(WAL log)和內(nèi)存(MemStore)中,MemStore中的數(shù)據(jù)是排序的,當(dāng)MemStore累計(jì)到一定閾值時(shí),就會(huì)創(chuàng)建一個(gè)新的MemStore,并 且將老的MemStore添加到flush隊(duì)列,由單獨(dú)的線程flush到磁盤上,成為一個(gè)StoreFile。于此同時(shí),系統(tǒng)會(huì)在zookeeper中 記錄一個(gè)redo point,表示這個(gè)時(shí)刻之前的變更已經(jīng)持久化了。(minor compact)

            當(dāng)系統(tǒng)出現(xiàn)意外時(shí),可能導(dǎo)致內(nèi)存(MemStore)中的數(shù)據(jù)丟失,此時(shí)使用Log(WAL log)來恢復(fù)checkpoint之后的數(shù)據(jù)。

            前面提到過StoreFile是只讀的,一旦創(chuàng)建后就不可以再修改。因此Hbase的更 新其實(shí)是不斷追加的操作。當(dāng)一個(gè)Store中的StoreFile達(dá)到一定的閾值后,就會(huì)進(jìn)行一次合并(major compact),將對(duì)同一個(gè)key的修改合并到一起,形成一個(gè)大的StoreFile,當(dāng)StoreFile的大小達(dá)到一定閾值后,又會(huì)對(duì) StoreFile進(jìn)行split,等分為兩個(gè)StoreFile。

            由于對(duì)表的更新是不斷追加的,處理讀請(qǐng)求時(shí),需要訪問Store中全部的 StoreFile和MemStore,將他們的按照row key進(jìn)行合并,由于StoreFile和MemStore都是經(jīng)過排序的,并且StoreFile帶有內(nèi)存中索引,合并的過程還是比較快。

            寫請(qǐng)求處理過程



            1 client向region server提交寫請(qǐng)求

            2 region server找到目標(biāo)region

            3 region檢查數(shù)據(jù)是否與schema一致

            4 如果客戶端沒有指定版本,則獲取當(dāng)前系統(tǒng)時(shí)間作為數(shù)據(jù)版本

            5 將更新寫入WAL log

            6 將更新寫入Memstore

            7 判斷Memstore的是否需要flush為Store文件。

             

            region分配

            任何時(shí)刻,一個(gè)region只能分配給一個(gè)region server。master記錄了當(dāng)前有哪些可用的region server。以及當(dāng)前哪些region分配給了哪些region server,哪些region還沒有分配。當(dāng)存在未分配的region,并且有一個(gè)region server上有可用空間時(shí),master就給這個(gè)region server發(fā)送一個(gè)裝載請(qǐng)求,把region分配給這個(gè)region server。region server得到請(qǐng)求后,就開始對(duì)此region提供服務(wù)。

             

            region server上線

            master使用zookeeper來跟蹤region server狀態(tài)。當(dāng)某個(gè)region server啟動(dòng)時(shí),會(huì)首先在zookeeper上的server目錄下建立代表自己的文件,并獲得該文件的獨(dú)占鎖。由于master訂閱了server 目錄上的變更消息,當(dāng)server目錄下的文件出現(xiàn)新增或刪除操作時(shí),master可以得到來自zookeeper的實(shí)時(shí)通知。因此一旦region server上線,master能馬上得到消息。

             

            region server下線

            當(dāng)region server下線時(shí),它和zookeeper的會(huì)話斷開,zookeeper而自動(dòng)釋放代表這臺(tái)server的文件上的獨(dú)占鎖。而master不斷輪詢 server目錄下文件的鎖狀態(tài)。如果master發(fā)現(xiàn)某個(gè)region server丟失了它自己的獨(dú)占鎖,(或者master連續(xù)幾次和region server通信都無法成功),master就是嘗試去獲取代表這個(gè)region server的讀寫鎖,一旦獲取成功,就可以確定:

            1 region server和zookeeper之間的網(wǎng)絡(luò)斷開了。

            2 region server掛了。

            的其中一種情況發(fā)生了,無論哪種情況,region server都無法繼續(xù)為它的region提供服務(wù)了,此時(shí)master會(huì)刪除server目錄下代表這臺(tái)region server的文件,并將這臺(tái)region server的region分配給其它還活著的同志。

            如果網(wǎng)絡(luò)短暫出現(xiàn)問題導(dǎo)致region server丟失了它的鎖,那么region server重新連接到zookeeper之后,只要代表它的文件還在,它就會(huì)不斷嘗試獲取這個(gè)文件上的鎖,一旦獲取到了,就可以繼續(xù)提供服務(wù)。

             

            master上線

            master啟動(dòng)進(jìn)行以下步驟:

            1 從zookeeper上獲取唯一一個(gè)代碼master的鎖,用來阻止其它master成為master。

            2 掃描zookeeper上的server目錄,獲得當(dāng)前可用的region server列表。

            3 和2中的每個(gè)region server通信,獲得當(dāng)前已分配的region和region server的對(duì)應(yīng)關(guān)系。

            4 掃描.META.region的集合,計(jì)算得到當(dāng)前還未分配的region,將他們放入待分配region列表。

             

            master下線

            由于master只維護(hù)表和region的元數(shù)據(jù),而不參與表數(shù)據(jù)IO的過 程,master下線僅導(dǎo)致所有元數(shù)據(jù)的修改被凍結(jié)(無法創(chuàng)建刪除表,無法修改表的schema,無法進(jìn)行region的負(fù)載均衡,無法處理region 上下線,無法進(jìn)行region的合并,唯一例外的是region的split可以正常進(jìn)行,因?yàn)橹挥衦egion server參與),表的數(shù)據(jù)讀寫還可以正常進(jìn)行。因此master下線短時(shí)間內(nèi)對(duì)整個(gè)hbase集群沒有影響。從上線過程可以看到,master保存的 信息全是可以冗余信息(都可以從系統(tǒng)其它地方收集到或者計(jì)算出來),因此,一般hbase集群中總是有一個(gè)master在提供服務(wù),還有一個(gè)以上 的’master’在等待時(shí)機(jī)搶占它的位置。


            六、訪問接口

            • HBase Shell
            • Java clietn API
            • HBase non-java access
              • languages talking to the JVM
                • Jython interface to HBase
                • Groovy DSL for HBase
                • Scala interface to HBase
              • languages with a custom protocol
                • REST gateway specification for HBase
                • 充分利用HTTP協(xié)議:GET POST PUT DELETE

            §

                • text/plain
                • text/xml
                • application/json
                • application/x-protobuf
              • Thrift gateway specification for HBase
                • java
                • cpp
                • rb
                • py
                • perl
                • php
            • HBase Map Reduce
            • Hive/Pig

            七、結(jié)語:

            全文對(duì) Hbase做了 簡(jiǎn)單的介紹,有錯(cuò)誤之處,敬請(qǐng)指正。未來將結(jié)合 Hbase 在淘寶數(shù)據(jù)平臺(tái)的應(yīng)用場(chǎng)景,在更多細(xì)節(jié)上進(jìn)行深入。


            參考文檔

            Bigtable: A Distributed Storage System for Structured Data

            HFile: A Block-Indexed File Format to Store Sorted Key-Value Pairs for a thorough introduction Hbase Architecture 101

            Hbase source code

             

            很久沒寫博客了,因?yàn)楹苊Γ贿^今天發(fā)現(xiàn)一篇不錯(cuò)的文章,幫我梳理了下HBase,原文地址:http://www.tbdata.org/archives/1509

            日本精品一区二区久久久| 久久se精品一区二区| 狠狠久久亚洲欧美专区| 久久久噜噜噜久久熟女AA片| 国产精品欧美久久久久天天影视| 97精品国产91久久久久久| 老色鬼久久亚洲AV综合| 色狠狠久久AV五月综合| 99久久99久久精品国产片果冻 | 久久99亚洲综合精品首页| 青青草国产成人久久91网| 国产精品久久久久…| 久久精品国产秦先生| 91久久精品国产成人久久| 激情久久久久久久久久| 人妻系列无码专区久久五月天| 久久午夜无码鲁丝片午夜精品| 四虎国产精品成人免费久久| 久久无码AV中文出轨人妻| 2021国内久久精品| 国产精品美女久久久久久2018| 久久精品成人免费网站| 久久综合精品国产一区二区三区 | 久久久噜噜噜久久中文字幕色伊伊 | 亚洲欧美一级久久精品| 亚洲日本va中文字幕久久| 精品久久久久久国产潘金莲| 国产成人AV综合久久| 一级a性色生活片久久无| av午夜福利一片免费看久久| 99热精品久久只有精品| 97精品伊人久久大香线蕉| 成人久久综合网| 久久99热这里只有精品66| 精品久久人妻av中文字幕| 久久久久久久综合综合狠狠| 亚洲精品国产字幕久久不卡 | 国产综合免费精品久久久| 一本色道久久HEZYO无码| 国产精品热久久无码av| 久久久久亚洲精品天堂|