自动分裂是分布式系统中的一项重要技术，通常与自动迁移和负载均衡一起考虑，提供了系统的可扩展性和良好的性能。例如 Google 的 BigTable 和 Yahoo 的 PNUTS 都实现了类似的功能，我之前也认为这应该是一个好的分布式系统标配。
但读了 Facebook 关于实时 Hadoop 的文章后，结合我自己在工程上的实践，我开始反思这一想法，认识到了这个功能的一些局限性。
Facebook 在打造实时 HBase 系统时，放弃了 HBase 提供的自动分裂，而专门开发了手工分裂功能。对此， Facebook 的解释是：
由于业务数据的均匀增长性，所有子表可能在相近的时间触发自动分裂，导致分裂风暴；合理安排的手工分裂可以避免这一情况，减少对生产环境的影响。
手工分裂时在某个时间，子表的数目是稳定的，有利于进行调试和调优；自动分裂时很难把握住系统中子表的变化。
在对日志文件问题进行后期处理时，子表没有分裂比有分裂要容易处理很多。因为应用日志到子表上时不用考虑是否已经分裂。
Facebook 给出的三个原因是非常合理的，我也很赞同，但我想补充一下我对自动分裂局限性的两个考虑：
较难进行事故影响评估。对于一个严肃服务来说，发生系统事故时不仅要求尽快恢复，更为紧迫的要求是迅速给出影响评估。手工分裂时运维人员对系统中子表的分布情况有着更好的了解，能够更快地做出评估(而且一般影响面也可控一些)。
较难进行数据恢复。当子表数据出现问题，或者数据源本身就有问题，要进行数据恢复时，手工分裂一方面能够准确地定位错误数据的位置，另一方面便于进行错误数据的处理(后台直接替换错误文件等，不单指 HBase)。而自动分裂时寻找错误数据位置本身就比较麻烦，由于子表可能一直在变动中，对错误数据进行处理也不容易。
从上面列出的几点来看，使用、改造或者实现一个分布式系统时，不能仅仅考虑方案是否漂亮，还要考虑到该系统的具体应用场景。脱离了应用场景的系统实现，如同漂亮的水果，吃起来不一定甜啊！
