自動分裂是分佈式系統中的一項重要技術，通常與自動遷移和負載均衡一起考慮，提供了系統的可擴展性和良好的性能。例如 Google 的 BigTable 和 Yahoo 的 PNUTS 都實現了類似的功能，我之前也認爲這應該是一個好的分佈式系統標配。
但讀了 Facebook 關於實時 Hadoop 的文章後，結合我自己在工程上的實踐，我開始反思這一想法，認識到了這個功能的一些侷限性。
Facebook 在打造實時 HBase 系統時，放棄了 HBase 提供的自動分裂，而專門開發了手工分裂功能。對此， Facebook 的解釋是：
由於業務數據的均勻增長性，所有子表可能在相近的時間觸發自動分裂，導致分裂風暴；合理安排的手工分裂可以避免這一情況，減少對生產環境的影響。
手工分裂時在某個時間，子表的數目是穩定的，有利於進行調試和調優；自動分裂時很難把握住系統中子表的變化。
在對日誌文件問題進行後期處理時，子表沒有分裂比有分裂要容易處理很多。因爲應用日誌到子表上時不用考慮是否已經分裂。
Facebook 給出的三個原因是非常合理的，我也很贊同，但我想補充一下我對自動分裂侷限性的兩個考慮：
較難進行事故影響評估。對於一個嚴肅服務來說，發生系統事故時不僅要求儘快恢復，更爲緊迫的要求是迅速給出影響評估。手工分裂時運維人員對系統中子表的分佈情況有着更好的瞭解，能夠更快地做出評估（而且一般影響面也可控一些）。
較難進行數據恢復。當子表數據出現問題，或者數據源本身就有問題，要進行數據恢復時，手工分裂一方面能夠準確地定位錯誤數據的位置，另一方面便於進行錯誤數據的處理（後臺直接替換錯誤文件等，不單指 HBase）。而自動分裂時尋找錯誤數據位置本身就比較麻煩，由於子表可能一直在變動中，對錯誤數據進行處理也不容易。
從上面列出的幾點來看，使用、改造或者實現一個分佈式系統時，不能僅僅考慮方案是否漂亮，還要考慮到該系統的具體應用場景。脫離了應用場景的系統實現，如同漂亮的水果，吃起來不一定甜。但令人感到諷刺的是，漂亮的水果一般比較貴。
轉載自：http://blog.solrex.org/articles/on-automatic-splitting.html