作者回复: nlj是一种join实现方式哈,和hash join、sort merge join一样,是一种join实现机制。cartesian join是一种join形式,和inner、left、right对等。每一种join形式,都可以用多种实现机制来做、来实现~
作者回复: 没错,Broadcast joins可以进一步提升性能。
作者回复: 赞👍,满分💯,无可挑剔~
作者回复: 这块能展开说说吗?具体怎么转化为等值join?可以举个例子哈~
作者回复: 空task~ 其实这个好理解,比如你对原始数据集做过滤,原来的数据有1万条,过滤之后1条,但是filter会继承之前的partitioner,也就是分区和之前是一样的,但其实很多分区中都没有数据,也就是空task。你这个例子也一样,并行度是200,实际上就是reducer的partitioner会划分出200的分区,partitioner是固定的,分区是一定要划出来的,但是实际上数据只有一条,其他的都是空task,白白浪费调度资源。 这也是为什么Coalesce之后,要做filter,以及为什么AQE要做自动分区合并,道理其实都一样,都是为了避免空task白白浪费宝贵的CPU资源。
作者回复: 是的,你说的没错。函数的副作用指的是对外部变量、外部环境的影响,内部状态的改变和转换不算。文中这块表述的不严谨哈,这里主要是想强调可变变量fields带来的计算开销。
作者回复: 好问题,其实改动非常小,开销相比正例也不大,但这里的关键在于,这个函数会被反反复复调用上百次,累积下来,开销就上去了。所以,关键不在于点小不小,而是这个点,是不是瓶颈。
作者回复: 可以,没问题,接触过Spark就行。放心吧,原理部分会有大量的生活化类比和故事,尽可能地让你“边玩边学”。另外,咱们有微信群,有问题可以随时探讨~
作者回复: 精辟!满分💯,一针见血
作者回复: 广播的思路很赞。不过二分查找这里值得商榷哈,咱们目的是过滤出满足条件的event date,然后和其他维度一起、分组聚合。这里关键不在于过滤和查找效率,关键在于大表的重复扫描,只要解决这个核心痛点,性能问题就迎刃而解。