Blink 有何特别之处？菜鸟供应链场景最佳实践(3)

除了上述几点优化，Blink SQL 模式还在尝试引入 SideInput、Partitioned ALL Cache 等优化方案，相信在随后开源的 Blink 版本中，，维表关联的性能会越来越好。 [好文分享：www.11jj.com]

下面是一张来自 Flink Committer 云邪 异步查询的流程图，供理解与同步请求的差异。 [原创文章：www.11jj.com]

数据倾斜

无数据不倾斜，我们在实时数仓建设过程中，也当然会遇到数据倾斜问题。在统计卖家的单量时，有些卖家单量大，有些卖家单量小，单量超大的卖家，就会产生数据倾斜；在统计行业的单量时，有些行业单量大，有些行业单量小，单量超大的行业，就会产生数据倾斜；在统计货品的库存流水情况时，有些货品库存流水频繁，一些货品库存流水较少，库存流水超频繁的货品就会产生数据倾斜……

我们应该如何处理数据倾斜问题呢？以统计卖家的单量为例，以前我们会先把订单这个 Key 作 Hash，先针对 Hash 之后的值做一次去重的聚合操作，再在此基础上，再做一次针对原 Key 去重的聚合操作。两次类似的聚合操作，导致代码写起来比较复杂，体力劳动比较多。

2017年，我们的实时数据开始全面切换到 Blink 上，Blink 在数据倾斜这块，又给我们提供了什么的方案呢？Blink 给出的答案是：MiniBatch/MicroBatch+LocalGlobal+PartialFinal。

MiniBatch/MicroBatch，可以实现微批处理，进而减少对 State 的访问，提升吞吐。因为微批处理会导致一定的延迟，最好结合 Blink 提供的允许延迟的相关参数来使用。

LocalGlobal，分为 Local 和 Global 两个阶段，有点类似 MapReduce 中的Combine 和 Reduce 两个阶段。LocalGlobal 可以很好地处理非去重类的聚合操作，但对 Count Distinct 的优化效果一般，因为在 Local 阶段，可能 Distinct Key的去重率并不会很高，进而导致后续的 Global 阶段，仍然会有热点。

PartialFinal，可以很好地解决 Count Distinct 带来的数据倾斜问题。PartialFinal 可以将 Distinct Key 自动打散，先聚合一次，在此基础上，再聚合一次，从而实现打散热点的作用。PartialFinal 跟手动 Hash 再聚合两次的效果一致，通过 Blink 提供的 PartialFinal 参数，可以自动实现，不再需要人为手工编写 Hash 再聚合两次的代码。

由上可以看出，Blink 在数据倾斜的处理上，已经实现了自动化，以前人为编写的打散热点方案，现在几个参数就能全部搞定，大大提升了代码的编写效率。