资料蒋堂 | 资料分布背后的逻辑

作者：蒋步星

来源：资料蒋堂

本文共1100字，建议阅读7分钟。

在分散式数据库及大资料平台中，资料如何分布到多台机器中是个很关键的问题。

在分散式数据库及大资料平台中，资料如何分布到多台机器中是个很关键的问题。因为很多运算是资料密集型的，如果资料分布做得不好，就会导致网络传输量变大，从而影响效能。

一般来讲，分散式数据库会提供两种分布策略：对于大表按某个字段（的HASH值）去分布，大多数情况会使用主键，这样可以把资料分拆到多台机器上；对于小表则采用复制性分布，也就是每个机器上都会复制一份。

但是，表的大小并没有绝对的判定标准，很大很小的表都容易识别并采取相应的策略，而那些资料不多不少的中型资料表又该采取哪种策略呢？

要搞清这个问题，我们就要知道资料分布背后的逻辑，什么样的资料分布才算是好的？

合理的资料分布能够有效地减少JOIN运算过程中的网络传输量！这也是资料分布的关键目标。

大部分常规运算都容易分拆到多个机器上分别执行后再汇总，这样，原则上资料只要尽量平均分布就可以由各节点来分摊计算负担。但是JOIN不一样，它涉及关联计算，如果JOIN的两条记录不在同一个节点上，那就需要把它们先传输到一起才能进行运算，这种事当然越少越好了。

那么怎样才能尽量避免JOIN过程中的资料传输呢？

这又要回到我们已经讨论过多次的JOIN型别。回顾一下去年的文章《JOIN运算剖析》，我们把JOIN分成三类：外来键、同维、主子。同维表和主子表的JOIN是在主键（或部分）之间进行的，主键不同的两条记录是不可能发生JOIN的，这样，如果资料已经按主键分布的，就不会发生跨节点JOIN的现象了。而外来键表的JOIN，维表记录可能被事实表随意引用，无论怎样将维表分布，都有可能发生跨节点JOIN的现象，只有将维表复制到每个节点上去，才能避免JOIN过程中的网络传输。

这样，我们就知道了：同维表和主子表要按主键字段去分布，而维表则要采用复制性策略，每节点都放一份，这样能有效减少跨节点JOIN运算。

但这和大表小表有什么关系？

一般来讲，记录事件的事实表会随着时间推移而不断增大，常常是大表，而这种表之间的JOIN大多数是同维表或主子表（比如订单及明细）关系。而用于外来键指向的维表主要是用于储存一些不常变化的属性资讯，相对要小一点。于是，本来是事实表要分拆分布、维表要复制分布的策略，就会表现成“大表”分拆、“小表”复制的特征了。

明白了这一点，我们就不会再纠结大表小表的界限在哪里了，其实没有大小之分，而是在资料结构中的地位决定的。

不过，关系数据库中并没有明确的事实表和维表概念，需要我们主动地去识别，有意识地设定分布方案。而且，一定要用主键去分布，随便找一个无关字段去分布，就起不到减少跨节点JOIN的作用了。

有些大资料平台只提供自动（按大小）分布的方案，不能强制复制维表，也不能让同维表和主子表按主键同步分布，这时候分散式计算的效果就不会好了，在选择这些计算体系时需要特别注意。

专栏作者简介

润干软件创始人、首席科学家

清华大学计算机硕士，中国大资料产业生态联盟专家委员，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润干公司；2004年，首次在润干报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润干软件释出不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大资料计算的开发和运算效率；2015年，润干软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016、2017年，荣获中国电子资讯产业发展研究院评选的“中国软件和资讯服务业十大领军人物”；2017年度中国资料大工匠、资料领域专业技术讲堂《资料蒋堂》创办者。

— 完 —

关注清华-青岛资料科学研究院官方微信公众平台“THU资料派”及姊妹号“资料派THU”获取更多讲座福利及优质内容。