State(t) = OperatorState(t) + SourceState(t)
则定义流计算引擎的计算过程为，存在计算计算逻辑 F 使得：
F(E(t), Sink(t), State(t)) = Sink(t+1) + State(t)
后者对流计算流域的影响堪比20世纪初 GFS，BigTable 以及MapReduce 三篇论文对大数据的影响，后面 Google 又在 MillWheel 之上继续发展，开源了 Apache Bean 这个系统级的流批一体数据解决方案，因为 MillWheel 是更纯粹的「流计算」，所以我们重点来分析 MillWheel。
Kafka Streams 中的「结果」也以事务的方式批量持久化，但和 Flink 不同的是，这些结果是被写入不同的消息队列中：
源状态 SourceState(t)：即 Kafka 源中的 Offset 信息，会被写入一个单独的 Kafaka 队列中，该队列对用户透明；
从流计算输出的角度来看，这些消息已被成功处理同时输出至下游，但从端到端的一致性来看，它们依然属于不一致的数据。又如，使用 Flink 处理 CDC（Change Data Capture） 的场景，如果下游是 MySQL，在 Flink 2PC 完成之前
本文从流计算的本质出发，推导出了在流处理中实现端到端一致性的通用解法，同时结合通用解法，分析了目前几种主流流计算引擎在一致性上的实现思路。有「财大气粗」型的 Google MillWheel，背靠强大的基础架构用于状态管理；
告警风暴与告警误报：为了不错过细微的问题，我们可能会配置大量的监控，从而导致在完整的软件生命周期中可能产生大量的告警，难以从其中识别出有效信息。另外大量的告警也带了很大程度上的误报问题，从而导致“狼来了”效应，于是真正的问题反而很容易又被忽略掉。这就陷入了恶性循环。
自动去重：每个告警会根据告警自身的关键特征计算出一个告警指纹，然后根据告警指纹自动去重。例如：某主机每一分钟触发CPU使用率过高告警，1小时触发60次，但对于告警管理系统来说，这只是一个告警的60个快照，而不是60个独立的告警；同时假如通知设置为30分钟重复，则一共只会发送两次通知，而不是每一分钟就发送一次通知。
今年是阿里巴巴双11的第13年，站在新轮回的时间点上，程立回顾了过去12年整个行业、数字技术的演进历程，并对未来12年的技术前进方向做出了判断和预测，同时还分享了今年双11阿里在未来技术前进方向上的初步实践，以及十大技术亮点。以下为程立的分享整理：
可应用于新闻阅读，同款商品识别等场景中，多模态知识图谱补全技术可以通过远程监督补全多模态知识图谱，完善现有的多模态知识图谱，多模态对话系统可用于电商推荐，商品问答领域。
。如图2所示，PKG包含<h, r, t>形式的三元组。例如，<Item-1， Material，Cotton>表示产品Item-1的材质是棉花。我们这样处理的原因在于，（1）PKG描述了产品的客观特性，它结构化且易于管理，通常为PKG做了很多维护和标准化工作，所以PKG相对干净可信。
