Kiji - 基于Apache HBase構建實時的可擴展的數據應用

jopen 12年前發布 | 24K 次閱讀 HBase

什么是 kiji :

 

個人總體感覺就是構建在hadoop/hbase上的一層Wrapper，使用Avro存儲系列化的對象在HBase表中，基本上目的是讓應用程序的編寫者能更容易的用Hbase管理結構化的數據，而不是作為一個扁平的表使用。拋開Hadoop和HBase，其最核心的部分就是所謂的Kiji-Schema，基本上就是用Avro處理Schema，以及讀寫系列化數據。

 

kiji基本概念和與HBase的映射關系

kiji對HBase沒有做什么改動，也沒有使用Coprocessor之類對HBase的功能進行拓展增強，所以基本上就是架構在HBase的公共API上，借用HBase既有的能力實現所需的功能，這一點和Hive On Hbase 有些類似。與Hive不同的是，kiji表的Metadata信息也是以HBase表的形式存在的。所以kiji的概念基本上都可以最終落實映射到HBase上

 

Entity：個人理解因為kiji的出發點是企圖強化對象概念，所以HBase表中Row的概念被弱化，每個對象都用一個Entity來表示，對象的所有信息都存儲在一個Entity內部。實際上，Entityid對應于HBase的實現就是Row key。不過在存儲的時候，Entity ID可以以Hash或裸數據或混合的形式存儲。

 

Cell：kiji中的數據單位劃分是Cell，是由 locality:family:key加上Timestamp來定位的，和HBase的Cell是同一個層次，但是為什么在定位中比HBase多了一層呢，實際上locality對應的是HBase的Family的概念，就是用來做同類數據的物理分組用途（改個名字難道是怕別人不理解HBase劃分Family的用意？）。而kiji中的family只是一個邏輯數據劃分的概念，并不對應HBase中的具體某個概念，可以理解為僅僅是把HBase的qualifier在命名的邏輯上分為兩部分而已。

 

Layout：此外Kiji中還有Table Layout的概念，基本就是用來描述表的結構，Layout并沒有存儲在HTable的TableDescriptor中，而是在自己管理的meta表中存儲，在HBase上表現為一個普通的HBaseTable（e.g. kiji.default.meta)

 

Schema：Kiji CellSchema對應的就是Avro的Schema，用來將扁平的HBase表格數據對象化。因為kiji的核心之一就是Schema，所以在Cell Schema方面還是做了一些功夫的，Cell的內容可以是裸的AvroRecord，Schema完全由MetaTable決定，也可以把Cell Schema和Avro Record合并存儲。而存儲的Schema為了節省空間，可以是Schema的Hash，也可以是Schema的ID。對應的Full Schema的映射關系存儲在單獨的表中（e.g. kiji.default.schema_hash kiji.default.schema_id)

 

Mapping of Kiji conception to Hbase summary:

 

Items

</td>

Kiji

</td>

HBase

</td> </tr>

Entity related

</td>

Entity

</td>

All KeyValues belong to the same row

</td> </tr>

 

</td>

EntityID

</td>

Row key

</td> </tr>

Column related

</td>

 locality:family:key

</td>

Family:qualifier

</td> </tr>

 

</td>

locality

</td>

Family

</td> </tr>

 

</td>

Family:key

</td>

Qualifier

</td> </tr>

Schema related

</td>

Table Layout

</td>

KijiMetaTable on Hbase. e.g. kiji.default.meta

</td> </tr>

 

</td>

Cell Schema

</td>

Avro Schema saved together with Avro serialized data in KV

</td> </tr>

 

</td>

Cell Schema mapping

</td>

Schema Table on Hbase e.g. kiji.default.schema_hash, keji.default.schema_id

</td> </tr> </tbody> </table> </div>

 

Table讀寫操作相關

 

kiji的基本操作包括KijiTable的創建修改，以及Entity數據的讀寫。其操作的流程步驟和HBase的比較相似，也有許多對應的概念對象如Configuration/Admin/Table等，個人理解是因為kiji對數據模型并沒有本質的變革，只是封裝了一層wrapper操作，所以不可能也不需要在操作流程上有太大的差異。

 

Entity讀寫

 

數據的讀寫以Entity為導向，實際上可以理解為就是以Row為導向。同樣需要添加所操作的Family/column等。個人理解概念上的差異就是在對Entity的操作上時，Entity的所有完整內容都在一個對象內部，更接近面向對象的編程概念，也就是幫應用程序的作者做了一些封裝的工作，簡化開發者的工作量

 

Filter操作

 

Kiji提供了Row/column/value相關的幾個Filter，這個可以說是Feature，也可以說是為了方便應用開發者的無奈之舉，因為row/column都可能以Hash的形式存在，而cellvalue則是Avro編碼過的，此外還可能附加有Schema，所以HBase相關的Filter無法簡單的應用在Kiji table中工作。因此這些kiji Filter基本都是對HBase相關Filter的封裝，對應的都會有一個toHBaseFilter方法，用來在服務器端創建對應的HBaseFilter。

 

其它

 

Layout evolving

 

Kiji的重點既然是在Schema和Layout，在Layout的動態調整中也花了不少功夫，比如Layout，就分為Concrete layout descriptors和Layout update descriptors。前者是作為基礎，后者作為修改量用來修正基礎Layout。這樣做的目的號稱是為了減少Layout更新過程的Racecondition。沒有深入研究其Evolving的細節，有需要時再研究。

 

對官方Feature的理解

 

Kiji官方描述了Kiji的一些Feature和精妙之處，結合文檔和API閱讀，個人理解如下：

 

    • sesese色