Pinterest is a visual platform at its core, so the need to understand and act on images is paramount. A couple of years ago, the Content Quality team designed and implemented our own batch pipeline to detect similar images. The similarity signal is widely used at Pinterest for use cases varying from improving recommendations based on similar images to taking down spam and abusive content. However, it was taking several hours for the signal to be computed for newly created images, which was a long window for spammers and abusers to harm the platform. So recently, the team implemented a streaming pipeline to detect similar images in near-real-time.

Apache Flink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。它提供的功能包括精确的唯一性保证、低延迟、高吞吐量和强大的计算模型。在Pinterest，我们采用Flink作为统一的流处理引擎。

随着 Flink k8s 化以及实时集群迁移完成，有赞越来越多的 Flink 实时任务运行在 K8s 集群上，Flink k8s 化提升了实时集群在大促时弹性扩缩容能力，更好的降低大促期间机器扩缩容的成本。同时，由于 K8s 在公司内部有专门的团队进行维护，Flink k8s 化也能够更好的减低公司的运维成本。

不过当前 Flink k8s 任务资源是用户在实时平台端进行配置，用户本身对于实时任务具体配置多少资源经验较少，所以存在用户资源配置较多，但实际使用不到的情形。比如一个 Flink 任务实际上 4 个并发能够满足业务处理需求，结果用户配置了 16 个并发。这种情况会导致实时计算资源的浪费，从而对于实时集群资源水位以及底层机器成本，都有一定影响。基于这样的背景，本文从 Flink 任务内存以及消息能力处理方面，对 Flink 任务资源优化进行探索与实践。

随着公司用户增长业务快速发展，陆续孵化出 部落、同镇、C 端会员、游戏等非常多的业务板块。与此同时产品及运营对实时数据需求逐渐增多，帮助他们更快的做出决策，更好的进行产品迭代，实时数仓的建设变得越发重要起来。本文主要介绍用户增长业务基于 Flink 构建实时数仓的实践之路。

用户点击商品 A，但购买了同类商品 B，则商品 A 记为一次订单流失。

微保用户运营中台经过前期的投入研发，在离线场景下已经得到了较为系统化的支持。通过对离线数据选取、干预，可实现对目标用户进行T+1触达。但T+1本身的延迟性会导致用户在产生特定行为时不能被实时触达，无法充分发挥数据的价值，取得更优的运营效果

​本文主要围绕 MQ-Hive 场景，针对目前字节跳动内已有解决方案的痛点，提出基于 Flink 的实时解决方案，并介绍新方案在字节跳动内部的使用现状。

一线实战经验总结分享～

本文主要介绍了达达集团使用基于开源的Flink Stream SQL开发的Dada Flink SQL进行实时计算任务SQL化过程中的实践经验。

日志实时处理

基于Kafka+Flink+Redis的电商大屏实时计算案例

无论在 OLAP 还是 OLTP 领域，Join 都是业务常会涉及到且优化规则比较复杂的 SQL 语句。对于离线计算而言，经过数据库领域多年的积累 Join 的语义以及实现已经十分成熟，然而对于近年来刚兴起的 Streaming SQL 来说 Join 却处于刚起步的状态。其中最为关键的问题在于 Join 的实现依赖于缓存整个数据集，而 Streaming SQL Join 的对象却是无限的数据流

同样是用Flink，微博广告的做法有什么不同？

带你进阶打怪了。

Flink--大数据技术栈15

快手有诸多业务场景应用了Flink，包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播CDN调度等。