【数据蒋堂】第46期：大数据集群该不该透明化？

这好像是个多余的问题，大部分大数据平台都把集群透明化作为一个基本目标在努力实现。

所谓集群透明化，是指把一个多台机器的集群模拟得像一个巨大的单机，只是系统管理层面知道体系是由很多单机集群而成，应用程序则应当尽量少地感受到集群的存在，在概念上可以把整个集群理解成一台机器，甚至在代码级都可能和单机运算兼容。

透明化主要有两个方面。一方面是数据存储，提供统一的集群文件系统或者数据库系统，应用程序不需要关心数据具体存放在哪里了，系统将自动寻找合适的节点，并提供一定的冗余容错机制；内存的透明化相对要困难一些，有时需要应用程序知道集群的存在。另一方面是任务分配，系统负责将大任务拆分成小任务并分配给各个节点机去执行，在有节点故障时能再将任务分配给其它节点；有时任务拆分比较困难，也需要程序员事先设计好拆分方案。

透明化显然有好处，可以降低理解难度，开发程序时和单机情况差不多，也能提高代码的兼容性。从这个意义上讲，只要能透明化就都应当去做，除非是实现难度太大（比如上面提到内存和任务拆分）的情况。

那么，为什么还要提出该不该透明化的问题呢？

因为，透明化难以获得最优的性能，而高性能对于大数据计算又是一个关键的目标。

高性能计算方案因运算目标和数据特征而异，并没有普适的优化方法。好算法需要特定的数据分布及任务分配方案，而使用系统自动的机制就很可能无法实现了。有些优化手段还是互相矛盾的，如果不做透明化则可以根据场景选用哪种。而实现透明化时，为了保证在任何情况都能正常工作，经常只能选择较保险的方案，常常这并不是性能最好的方案。

比如在做JOIN运算时，我们可以从业务上区分维表和事实表，也事先知道维表的容量，如果维表数据量较小，则可以将维表主动存储到所有节点中甚至读入内存，而只把事实表分段存储到节点中，并按此分布设计更优的算法能。而透明化方案不能做这些假定，要处理一般情况，就不能区分维表和事实表，也不能假定维表足够小。有些计算平台能够临时测定数据特征以采用更优的计算 方案，针对JOIN这种被研究得很透的运算有可能做到，但更复杂的情况就不一定了。

另外，透明化体系一般都会有一个较复杂的框架来控制数据分布及实现任务调度，这个事并不简单，本身也会消耗很多资源，而如果不搞透明化或透明化程度较弱时，则可以把这些资源本用到计算上。比如容错机制，节点机可能有故障，集群体系要能在故障机数量不多时保证计算仍然可以进行下去，这需要重新设计数据的冗余方案，要求高时还要及时保存中间结果。

一定程度地牺牲透明化，可以换来更高的性能。数据存储可以直接使用节点机的文件系统，程序员可以根据运算的特征以及节点的能力来决定数据的分布以及冗余方案，对应用层并不提供一个统一的网络文件系统。任务分配也由程序员自行处理，也是根据运算特殊及数据分布以及节点能力来安排任务，养活框架消耗，将尽量多的资源都用到计算任务本身上。

当然，牺牲透明化会带来程序的开发复杂度提高，与单机情况的兼容性变差，这也是需要权衡的问题。透明化与否，并不是非黑即白的选择。完全透明化，可能得不到最优的性能；彻底不透明，又会导致开发成本又过高。具体要透明到什么程度，根据实际场来选择。

一般来讲，规模较大的集群要做好透明化，小规模集群则可以实施个性化管理。

大集群的节点多，如果不采用透明化方案，每个节点都个性化管理，那复杂度会提升太多，虽然可能获得一些性能提升，但带来的麻烦度很可能更高。而小集群则实施每个节点的个性化管理是管得过来的，节点存储的数据各有不同。对于容错，大集群在很短的时间段内就可能发生故障节点，一定要有较强的自动容错能力，这时花在框架上的开销是必须的；而小集群则没有这个问题，几个节点的集群保证连续正常工作许多天并不是个小概率事件，就没必要在框架上消耗太多资源。