HBase入門-安全與權限

安全&權限 我的廢話： 大年三十夜，看春晚實在是太無聊了，整個《新聞聯播》的電視劇版本，還不如上上網，看看資料，喝喝老酒，寫點東西來的快活。 近2年來雲計算的話題到目前為止風風火火從來沒有平靜過，一直是大家嘴邊讨論的熱門話題，人們期望運用雲計算提供可靠、穩定、高速的計算，在雲計算中Google是目前最大的雲計算供應商，例如：Google GAE(Google App Engine)和Google的Docs線上文章服務，這些SaaS上線産品的資料存儲(datastore)是由BigTable提供存儲服務的，在次之前我提到過Yahoo貢獻給Apache的那些山寨版本(Google與Yahoo的那些利器)，其中Apache的HBase就是山寨了Google的BigTable。 我們知道在雲計算的技術話題中Apache的Hadoop項目是一塊基石，利用Hadoop項目中的産品可以建立雲計算平台和超大型的計算。不知道你是否有想過如果将HBase作為Google GAE上的資料存儲(datastore)，那麼每個使用者之間的資料通路權限怎麼辦？如果使用HBase提供對大客戶提供“私有雲”(private cloud)或者另一種可能一個公司内部的叢集上運作HBase，公司的内部可能有幾個部門，某幾個部門之間的資料都是獨立分離但又運作在一個平台上，那麼你就會發現HBase不具備這樣的功能，貌似目前HBase的最高版本0.90.0還沒有這樣的功能對使用者的表、Row、Cell的通路權限。但是我們知道Google的GAE上每個使用者通路的資料肯定是有權限劃分的，不然我隻要有權限登入GEA就能看見所有使用者存放的資料了。這樣的問題你有可能沒有想過，但趨勢公司的工程師們卻為此想到了這點，并且把他們的設想和設計送出了HBase項目組，并且提出了以下主要的設計思想： Client access to HBase is authenticated User data is private unless access has been granted Access to data can be granted at a table or per column family basis. 對HBase中的表和資料劃分權限等級和身份驗證後，操作權限被分為3大類，每類中包含的操作權限如下所示： 對于方案中涉及到存儲的權限的是指整個表或表中的列族，也就是說隻考慮在表這個級别的權限，表與表之間的所屬關系是存放在 .META. 系統表中，以regioninfo:owner 的格式進行存放，例如:系統中table1這個表是有權限的，這個表權限的存根儲存在3個地方 ： The row in .META. for the first region of table1 The node /hbase/acl/table1 of Zookeeper The in-memory Permissions Mirror of every regionserver that serves table1 如圖所示，圖中的箭頭表示了資料流向的順序： 方案中HBase在分布式、叢集環境下，而權限一緻性的問題交給了Zookeeper來處理，在多個regionservers中，每個伺服器的HRegion中存放着多個表，并且實作了(implement)ZKPermissionWatcher接口的nodeCreated() 和 nodeChanged() 方法，這2個方法對Zookeeper 的節點進行監控， 節點的狀态發生相應的變化時會ZooKeeper重新整理鏡像中的權限。 如圖所示： HBase的這一關于權限的功能正在設計和研讨當中，讓我們繼續對他保持關注，看看今後将會發生的變化能給我們帶來什麼樣的效果，非常期待這個功能早日正式釋出。 原文連結：http://www.uml.org.cn/sjjm/201212141.asp#2