查看原文
其他

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

蒋步星 数据蒋堂 2023-02-25

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

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

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

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

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

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

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

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

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

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

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

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

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


  正文结束  


 近期文章

【数据蒋堂】第45期:大数据计算语法的SQL化

【数据蒋堂】第44期:谈谈临时性计算

【数据蒋堂】第43期:报表开发的现状

【数据蒋堂】第42期:RDB与NoSQL的访问性能

【数据蒋堂】第41期:文件的性能分析

【数据蒋堂】第40期:倍增分段技术

【数据蒋堂】第39期:数据分段讨论

【数据蒋堂】第38期:JOIN延伸 - 维度其它应用

【数据蒋堂】第37期:JOIN延伸 - 维度查询语法

【数据蒋堂】第36期:JOIN延伸 - 维度概念

【数据蒋堂】第35期:JOIN提速 - 有序归并

【数据蒋堂】第34期:JOIN提速 - 外键指针的衍生

【数据蒋堂】第33期:JOIN提速 - 外键指针化

【数据蒋堂】第32期:JOIN简化 - 意义总结

【数据蒋堂】第31期:JOIN简化 - 维度对齐

【数据蒋堂】第30期:JOIN简化 - 消除关联

【数据蒋堂】第29期:JOIN运算剖析


    关于数据蒋堂    

《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。


蒋步星,清华大学计算机硕士,著有《非线性报表模型原理》等

1989年中国国际奥林匹克数学竞赛团体冠军成员,个人金牌

2000年创立润乾公司,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准。

2008年开始研发不依赖关系型数据的计算引擎,历经多个版本后,于2014年集算器正式发布。有效地提高了复杂结构化大数据计算的开发速度和运算效率。

2016年荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业 • 十大领军人物”。

2017年创办数据领域技术讲堂《数据蒋堂》,专注数据、每周一期。

2017年获得中国大数据产业生态大会评选的“2017年度中国数据大工匠”

2017年荣获中国电子信息产业发展研究院评选的“2017年中国软件和信息服务业 • 十大领军人物”。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存