实时计算 Flink

blink测试团队成立一年多的时间，从无到有，逐步建立起完整的blink测试体系，从代码质量到集成测试再到预发测试，全方位保障blink质量，取得了显著的成果。

1.大数据处理的常用方法 大数据处理目前比较流行的是两种方法，一种是离线处理，一种是在线处理，基本处理架构如下： 在互联网应用中，不管是哪一种处理方式，其基本的数据来源都是日志数据，例如对于web应用来说，则可能是用户的访问日志、用户的点击日志等。

引言 在很多领域，如股市走向分析, 气象数据测控，网站用户行为分析等，由于数据产生快，实时性强，数据量大，所以很难统一采集并入库存储后再做处理，这便导致传统的数据处理架构不能满足需要。流计算的出现，就是为了更好地解决这类数据在处理过程中遇到的问题。

TopN 是统计报表和大屏非常常见的功能，主要用来实时计算排行榜。流式的 TopN 不同于批处理的 TopN，它的特点是持续的在内存中按照某个统计指标（如出现次数）计算 TopN 排行榜，然后当排行榜发生变化时，发出更新后的排行榜。

Flink SQL 是于2017年7月开始面向集团开放流计算服务的。虽然是一个非常年轻的产品，但是到双11期间已经支撑了数千个作业，在双11期间，Blink 作业的处理峰值达到了5+亿每秒，而其中仅 Flink SQL 作业的处理总峰值就达到了3亿/秒。

Connector 是连接外部数据和blink计算框架的桥梁，也是流计算的入口和出口。目前，blink支持了集团内部绝大多数的上下游（如下图)，详细的接入方法可以见官方文档，本文主要阐述connector设计和使用上需要注意的问题。

通俗讲retract就是传统数据里面的更新操作，也就是说retract是流式计算场景下对数据更新的处理方式。

流计算中一个常见的需求就是为数据流补齐字段。因为数据采集端采集到的数据往往比较有限，在做数据分析之前，就要先将所需的维度信息补全。比如采集到的交易日志中只记录了商品 id，但是在做业务时需要根据店铺维度或者行业纬度进行聚合，这就需要先将交易日志与商品维表进行关联，补全所需的维度信息。

去重逻辑在业务处理中使用广泛，大致可以分两类：DISTINCT去重和FIRST_VALUE主键去重，两者的区别是DISTINCT去重是对整行数据进行去重，比如tt里面数据可能会有重复，我们要去掉重复的数据；FIRST_VALUE是根据主键进行去重，可以看成是一种业务层面的去重，但是真实的业务场景使用也很普遍，比如一个用户有多次点击，业务上只需要取第一条。

最近在学习Flink的Fault Tolerance，了解到Flink在Chandy Lamport Algorithm的基础上扩展实现了一套分布式Checkpointing机制，这个机制在论文"Lightweight Asynchronous Snapshots for Distributed Dataflows"中进行了详尽的描述。

2017年6月22号，由“京城学堂”和阿里巴巴集团技术发展部主办的“对话科技”系列讲座邀请到了Apache Flink项目的PMC成员，来自德国DataArtisans公司的Till Rohrmann，在北京阿里中心为关注实时计算技术的阿里同学做了一场关于Apache Flink技术发展的精彩分享。

在Blink的流式任务中，State相关的操作通常都会成为整个任务的性能瓶颈。实时计算部-查询和优化团队开发了MiniBatch功能，大幅降低了State操作的开销，在今年的双11中，几乎所有适用的任务都启用了MiniBatch功能。

阿里巴巴需要研发世界级一流的流式计算引擎，实时处理海量数据，提供在线统计、学习和预测能力，不仅支持阿里巴巴自己的核心电商场景，同时也能通过阿里云向外部中小企业提供流式计算服务，输出实时计算能力，这就是我今天要分享的最新一代阿里巴巴实时计算引擎Blink。

背景 每年的双十一除了“折扣”，全世界（特别是阿里人）都关注的另一个焦点是面向媒体直播的“实时大屏”（如下图所示）。包括总成交量在内的各项指标，通过数字维度展现了双十一狂欢节这一是买家，卖家及物流小二一起创造的奇迹！ 双十一媒体直播大屏 这一大屏背后需要实时处理海量的庞大电商系统各个模块产生的

我们提出了Dataflow模型，并详细地阐述了它的语义，设计的核心原则，以及在实践开发过程中对模型的检验。