脚本宝典收集整理的这篇文章主要介绍了4个优化方法,让你能了解join计算过程更透彻,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
摘要:现如今, 跨源计算的场景越来越多, 数据计算不再单纯局限于单方,而可能来自不同的数据合作方进行联合计算。
本文分享自华为云社区《如何高可靠、高性能地优化join计算过程?4个优化让你掌握其中的精髓》,作者: breakDraw 。
现如今, 跨源计算的场景越来越多, 数据计算不再单纯局限于单方,而可能来自不同的数据合作方进行联合计算。
联合计算时,最关键的就是标识对齐,即需要将两方的角色将同一个标识(例如身份证、注册号等)用join操作关联起来, 提取出两边的交集部分, 后面再进行计算,得到需要的结果。
而这种join过程看似简单,其实有非常多的门道,这里让我从最简单的join方法开始, 一步步演示join的优化过程。
首先假设以下场景:
拿到2张表的全量数据, 直接2个for循环进行遍历
如果id匹配,则合并2个行记录作为join结果
for (row r1 : tb1) { for(row r2 : tb2) { if(idMatch(r1, r2) { // 获取r1和r2拼接后的r3 r3 = join(r1,r2) result.add(r3) } } }@H_304_51@
图示如下:
上面这种join有2个问题:
首先解决刚才提到的第一个问题
实际上join过程就很像一种命中过程, 因此可以联想到哈希表。
for (row r1 : tb1) { if(idMap.containKey(r1.getId())) { row r2 = idMap.get(r1.getId()); r3 = join(r1,r2) result.add(r3) } }
这样复杂度就优化到了O(m)了
还有一个问题没解决: ”为了收集全量数据, 可能导致内存溢出“。
那我们可以将大表按照特定数量进行拆分,分成多批数据
例如每次以1000条的数量,和小表进行上面的哈希表碰撞过程。这样空间复杂度就是O (K + n)。
当每碰撞完一次,才接着接收下一批数据。如下面所示
注意, ”告知计算完成这种响应机制“也可以优化成阻塞的缓冲队列。
但是还有个问题, 如果小表本身也很大, 例如1亿条, 计算节点连小表的哈希表都存不下,怎么办?
另外单节点计算的CPU有限,如何能在短时间内快速提升性能?
例如我们可以对id列进行shuffle分片
如果id是均匀的, 则小表的数据就被拆成了3份,也许就能正好存下了。
大表数据按同样的方式分片, 分到相同的节点, 对计算结果是没有影响的, 只要你的分片算法确保id匹配的行一定在同一个节点即可。
另外性能上, 分布式计算理论上按照节点数量也能够提升N倍的join速度。
这种分布式计算的方式已经能解决大部分join作业了,但是还有个问题:
本地计算,指的就是在通过网络输出数据前,先提前做一些预处理。这种操作在各种计算引擎中都有体现
对于join过程, 我们可以:
以上仅仅只是最基础的join优化过程, 而在海量数据、高性能、高安全、跨网络的复杂场景中, 关于join计算还会有更多的挑战。
因此可以关注华为可信智能计算TICS服务,专注高性能高安全的联邦计算和联邦学习,推动跨机构数据的可信融合和协同,安全释放数据价值。
以上是脚本宝典为你收集整理的4个优化方法,让你能了解join计算过程更透彻全部内容,希望文章能够帮你解决4个优化方法,让你能了解join计算过程更透彻所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。