在大規模量級的分布式儲存系統中，很多時候管理員以及使用者都有特定條件的查詢需求：比如使用者哪個目錄檔案資料量是最多的？還有對於管理員的需求：哪個節點上儲存的檔案數量最多，又或者是否存在損壞資料塊檔案類似種種的問題。因此在大型分布式儲存系統中，我們需要有乙個能夠快速透視，探查裡面資料的工具。當然它的功能要遠遠大於目前檔案系統提供的fsck這樣的工具命令。對於這種工具，我們可以怎樣對其進行設計呢？本文，筆者結合hadoop ozone recon服務，來聊聊裡面的一些相關設計思想。
這裡需要大家明白乙個關鍵的點，資料探查服務並不是要針對所有的物理資料進行乙個個的掃瞄統計，而只是需要對中心控制節點的核心元資料進行探查分析即可。比如hdfs，那我們專門分析的物件就是fsimage檔案。
為了避免對實際生產系統造成影響，我們一般的做法是會從乙個standby的元資料檔案進行定期同步，然後對這個同步而來的檔案再進行二次分析。當然，有時我們可以做的更高階一些，只有首次同步時進行元資料檔案的同步，後面只同步wal的更新操作，相當於這是standby的follower。因為資料探查服務不會對元資料檔案進行寫操作，所以我們可以讓這個檔案變為read-only模式的。
對於資料探查的定位，在這裡它是乙個服務，所以上述的行為應該被納入到這個服務當中。
有時候，針對不同的查詢分析需求，如果按照原來元資料檔案內的索引構建方式，會導致非常低的效率（比如遍歷完全統計），此時我們可以在服務中進行一定結構的轉換。比如一種常見的方式：倒排索引的構建，或者帶上字首匹配的支援。或者構建出不同key對應的不同value的含義，只要value是我們所需要的就行。
這裡的索引結構的重構建可以和上面元資料的定期同步行為的速率保持一致，以達到準實時更新的效果。
上述各個索引結構都構建完成後，我們可以做一些常規的匯**計的操作，然後將這些結果儲存到一張匯聚表中。然後使用者可以通過這張匯聚表的資料來進行他們希望的查詢請求。
比如舉個例子，我們儲存了一張container–>blocks數的表資料，定義如下：
create table `num_blocks_per_container` (
`container_id` bigint,
`num_blocks` int,
primary key (`container_id`)
);
資料探查服務不僅支援細粒度層面的元資料分析，當然它也應該包含節點層面的統計，諸如以下類似指標：
這些節點層面的統計需要由資料探查服務定期對這些節點做一次查詢操作，然後也將結果儲存到上面的匯聚表中。這類結果資料對於系統管理員來說將會相當有用，比如說利用這些資料我們可以知道節點使用空間的趨勢變化情況等等。
資料探查服務作為一項完整的資料分析服務，它不應該直接暴露給使用者。對於使用者來說，我們需要給他們提供乙個console的東西，使用者看到的可以是直接提供好的使用者命令，不同身份的使用者能夠使用的執行命令也是有所區分的。而console裡面的console server是資料探查服務的乙個**。
在這個console server的服務裡，我們可以進一步完善security的功能，加入一些authentication，或者更方便使用者進行查詢使用的一些feature，比如瀏覽器直接瀏覽查詢功能。
分布式儲存系統設計 資料分片
在分布式儲存系統中，資料需要分散儲存在多台裝置上，資料分片 sharding 就是用來確定資料在多台儲存裝置上分布的技術。資料分片要達到三個目的 分布均勻，即每台裝置上的資料量要盡可能相近 負載均衡，即每台裝置上的請求量要盡可能相近 擴縮容時產生的資料遷移盡可能少。資料分片一般都是使用key或key...
OJ系統 設計資料庫
e r圖 我們一共建立了 同學 老師 題目 課程 考試 和 測試用例 6個表。同學 同學 表一共有6個屬性，分別為 使用者名稱 註冊郵箱 密碼ac率 所選課程 提交的題目 其中，提交的題目 中包含著8個復合屬性，分別為 提交題目的id 提交的時間 語言結果 得分 長度 記憶體執行時長 老師 老師 表...
評價系統海量資料儲存設計
整體資料儲存包括基礎資料儲存 文字儲存 資料索引 資料快取幾個部分。基礎資料儲存 及標籤處於同一資料庫下，根據商品編號分別進行拆表 其它的擴充套件資訊資料，因資料量不大 訪問量不高，處理於同一庫下且不做分表即可。因人而異 因系統而異，根據不同的資料場景選擇不同儲存方案，有效利用資源的同時還能解決資料...