Question

对于任意一个大型复杂系统来说，如果它能被拆分的话，我们拆分的模式无非上述三种。而且这种从逻辑的视角进行的拆分活动，最终也会表现为数据的拆分，例如子系统与子系统各自的数据库。更进一步地，当我们不再需要考虑这些子系统之间的数据关系时，整个系统将是可持续分布、并行计算的。

虽然从我们目前的分析来看，这一切是成立的，但是现实中的系统往往并不这样简单。其中的问题之一，在于“数据并不总是可以拆分”。例如一个简单的统计日志功能，其原始的需求如下：分析某个日志文件，统计日志的总行数。

缘于这个日志文件过大，我们对日志文件进行了数据拆分：每 100M 数据分成一个文件。这样，我们在整个逻辑上就可以理解为：对于文件 log1.txt 使用逻辑 A₁，对于文件 log2.txt 使用逻辑 A₂，如此等等；对于整个逻辑，我们将对 A₁，…，A_n返回值求和 9 。

但是 log1.txt，log2.txt，…，logN.txt 这些文件之间却存在着关系。由于数据按 100M 分段，而换行并不总是发生在分段的边界之上，所以 log1.txt 末尾可能有“半行”属于 log2.txt 的第一行……类似这样的关系，使得我们在拆分 log.txt 这个数据总量时存在一些实际限制。

这些数据方面的限制，通常是通过逻辑来弥补的。我们总是试图让“数据拆分”这一活动更简单，或更规则。其简单，意味着分布它的成本很低，例如“数据按 100M 分段”的分布成本仅仅是物理存储上的限制；其规则，意味着处理它的成本很低，例如“数据总是在换行边界上分段”，那么处理它的程序将非常容易写，并且判断逻辑会少很多，执行效率也就高很多。

但如同算法时间与空间复杂度难于平衡一样，分布成本低通常处理成本就高，反之亦然。也就是说，对于既已存在的数据集来说 10 ，简单而又规则地拆分是两难之事。

1. 可见“象太大”才是最原始、顶层的根本问题，所谓“大象不能分割”事实上是“化整为零”这个求解方案所带来的第二层问题；而“将大象重量映射为石头重量”，是进一步的求解方案。“映射/如何映射”作为第三层的问题，是远离原始问题的以及其本质的。 ↩
2. 这其实并不那么明显。其一， 处理 （process）是函数的基本抽象含义，如同它在数学中的含义是求解；其二， 数据 （data）是处理的具体对象，这是函数入口参数的基本抽象含义，如同数学中的公式是函数，而代入公式的那些数才是求解的问题（即数据）。 ↩
3. 引导光盘、引导软盘，以及硬盘活动分区的引导扇区等。 ↩
4. 这里仅基于 Windows 系统的“进程－线程”模型进行讨论。事实上这些逻辑单元在不同系统中有着多种类型、多种层次与关系的抽象，例如作业（Job）、任务（Task）、进程（Process）、线程（Thread）、协和（Coroutine）、流（Flow）、事务（Work）、会话（Session）等。 ↩
5. 注意这样的实现其实是基于“进程-线程”模型的并发（Concurrency），这些执行体只是在宏观上看来是并行的而已，并非真正意义上的、与串行（Sequential）相对的并行计算（Parallel, Parallel computing）。 ↩
6. 这句话的意思是说：我们只好让那些不能拆分的逻辑运行在同一个处理单元中。 ↩
7. 如果使用一个自动分布程序来处理函数 foo() ，我们显然只需要进行完整的语法扫描，以确定 foo_1 与 foo_2 各自使用的那一部分数据即可。 ↩
8. 对于在分布环境下的“函数的参数界面”，在 Erlang 中可以理解为消息，而在另外一些基于数据库、数据中心或数据结点的解决方案中，可以理解为持锁的数据项或结点。 ↩
9. 在这个问题中，A₁，…，A_n是否是相同的逻辑呢？这并非一个关键问题，因为我们现在仅在讨论数据的分布。 ↩
10. 这也提出了数据规划的必要性问题：若我们现在有机会规划这些数据，那么必然能降低将来处理它们的成本。 ↩