首先解释一下数据过热、延迟数据丢弃和数据反压的产生原因：
1.数据过热原因：
实时处理中的关键问题是检测数据流中的事件模式。复杂事件处理（CEP）恰好解决了对连续传入事件进行模式匹配的问题。 匹配的结果通常是从输入事件派生的复杂事件。 与对存储数据执行查询的传统DBMS相比，CEP在存储的查询上执行数据。 可以立即丢弃与查询无关的所有数据。 考虑到CEP查询应用于潜在的无限数据流，这种方法的优势是显而易见的。 此外，输入立即处理。 一旦系统看到匹配序列的所有事件，结果就会立即发出。 这方面有效地带来了CEP的实时分析能力。CEP现在用于诸如股票市场趋势和信用卡欺诈检测等金融应用，对于每个机架，都会监控功耗和温度。 无论何时发生这种测量，分别产生新的功耗或温度事件。 基于此监控事件流，我们希望检测即将过热的机架，并动态调整其工作负载和对其降温
解决方法：首先，我们监测温度事件，每当我们看到连续两次警告温度升高时，我们就会发出此机架的警报。 然后，该警报可以触发对冷却机架的对策
2.延迟数据丢弃：Flink的窗口处理流式数据虽然提供了基础EventTime的WaterMark机制（下一节讲），但是只能在一定程度上解决数据乱序问题。而某些极端情况下数据延迟会非常严重，即便通过WaterMark机制也无法等到数据全部进入窗口再进行处理。默认情况下，Flink会将这些严重迟到的数据丢弃掉
解决方法：可以借助Allowed Lateness机制来对迟到的数据进行额外的处理，
DataStream API提供了allowedLateness方法来指定是否对迟到数据进行处理，指定后，Flink窗口计算过程中会将window的Endtime加上该时间作为窗口最后被释放的时间，当接入的数据中EventTime未超过窗口最后被释放的时间，但WaterMark已经超过Window的EndTime时，直接触发窗口计算。相反，如果事件时间超过了窗口最后被释放的时间（最大延时时间），则只能对数据进行丢弃处理。
默认情况下，GlobleWindow的最大Lateness时间为Long.MAX_VALUE，即不超时，因此数据会源源不断累积到窗口中，等待被触发。
3.数据反压：做全网的count，那么用以上左图的红色和紫色，分别发送到一个地方去统计，不做预处理的话，红色节点负载过高，很快就导致反压。
解决办法：最好的办法就是红色和紫色的节点现在上游chain起来做预处理，相当于把一个聚合分成两部分，先做count，再做sum。但是上面的方案不总是有效，比如count distinct，它也需要按颜色group by还要按某一列去distinct，导致不同的数据无法被预聚合。所以在local-global上除了chain的方式还有shuffle的方式，相当于shuffle两次，也就是大家在流计算中所说的打散。第一次按distinct key去shuffle，第二次用group by的key去做shuffle。当然这些都是SQL Engine都会自动帮你做。