經過和社區討論，並參照網上的一些帖子，自己還看了一些源碼，終於將region split的大致流程搞清楚了。
1. RegionServer開始split，首先會在ZK中創建一個名稱爲“/hbase/region-in-transition/region-name”的znode，狀態爲SPLITTING；
2. 由於Master在不停的觀察znode（/hbase/region-in-transition），所以它很快能感知到新的變化；
3. RegionServer在HDFS上父region目錄下創建一個子目錄“.splits”；
4. RegionServer關閉父region，這會迫使一個memstore的flush，然後本地標記父region爲offline狀態。此時，訪問父region的客戶端將拋出NotServingRegionException。所以客戶端對此場景應當採用嘗試機制；
5. 在“.splits”目錄下，RegionServer爲兩個子region分別創建目錄和必需的數據結構。然後，針對父region的每個storefile，爲每個子region各創建一個reference文件，即這些reference文件將引用父region的storefile。在0.96.2的實現中，reference文件的路徑爲：父region目錄/.splits/子region_EncodedName/cf_name/storefile_name.父region_EncodedName；
6. RegionServer在真實的region目錄下（在0.96.2的實現中爲/hbase/data/namespace_name/table_name/），爲子region創建目錄，並將reference文件移動到新建的目錄中；
7. RegionServer修改.META.表中父region的記錄，不但將其狀態置爲offline，並且爲其添加子region的信息。並在.META.表中爲每個子rigion添加一條記錄，並置記錄的server字段值爲當前RegionServer的地址和端口。對.META.表的這些修改是原子性的；
8. RegionServer並行的打開子region，即子region將變爲open狀態，併爲客戶端提供讀寫服務；
9. RegionServer將ZK上的znode（/hbase/region-in-transition/region-name）狀態置爲SPLIT，並等待master感知後刪除此zonode；
至此，split操作應該算是結束了。社區宣傳split操作很快，應該就是因爲並沒有實際的拆分storefile，而是採用了非常小的reference文件的原因。
split之後，子region通過reference文件引用父region的數據。當子region發生compaction而生成自己的storefile後，reference文件將會刪除。master的GC任務將週期性的檢查父region是否仍被子region引用，如果沒有的話，將刪除父region的所有數據，包括.META.表中的記錄和HDFS上的目錄結構（split過程中遺留的“.splits”也就順便被清理了。。。）
本文參考的源碼是0.96.2版本，不同版本的實現可能略有不同。
在此順便提及一下Hypertable的split過程，其實和Hbase類似。只不過Hypertable在split後通常會馬上將一個新的子region/range移動到一個新的RegionServer/RangeServer上，並會伴隨觸發major compaction。
本文還參考了以下兩篇文章：
http://zh.hortonworks.com/blog/apache-hbase-region-splitting-and-merging/#comment-501262
