本文为您介绍利用实时计算设计准实时（延迟在100ms以内）异常检测系统。 背景介绍 比如一家银行要做一个实时的交易检测，判断每笔交易是否是正常交易：如果用户的用户名和密码被盗取，系统能够在盗取者发起交易的瞬间检测到风险来决定是否冻结这笔交易。

基于实时计算打造舆情分析平台——新华智云 1.客户&产品简介： 新华智云是一家致力于通过大数据技术驱动媒体变革的公司，数芯是新华智云推出的实时舆情分析平台，旨在满足用户一系列舆情分析需求。

聊什么 为了满足本系列读者的需求，在完成《Apache Flink 漫谈系列(14) - DataStream Connectors》之前，我先介绍一下Kafka在Apache Flink中的使用。所以本篇以一个简单的示例，向大家介绍在Apache Flink中如何使用Kafka。

Flink入坑指南系列文章，从实际例子入手，一步步引导用户零基础入门实时计算/Flink，并成长为使用Flink的高阶用户。 简介 Group By + Agg这个最经典的SQL使用方式。Group By是SQL中最基础的分组操作，agg的全称是aggregation(聚合操作)，是一类SQL算子的统称，Flink中最常用的Agg操作有COUNT/SUM/AVG等，详情参见Flink支持的聚合操作列表。

什么是Table API 在《Apache Flink 漫谈系列(08) - SQL概览》中我们概要的向大家介绍了什么是好SQL，SQL和Table API是Apache Flink中的同一层次的API抽象，如下图所示： Apache Flink 针对不同的用户场景提供了三层用户API,最下层ProcessFunction API可以对State，Timer等复杂机制进行有效的控制，但用户使用的便捷性很弱，也就是说即使很简单统计逻辑，也要较多的代码开发。

聊什么 上一篇《Apache Flink 漫谈系列 - JOIN算子》我们对最常见的JOIN做了详尽的分析，本篇介绍一个特殊的JOIN，那就是JOIN LATERAL。JOIN LATERAL为什么特殊呢，直观说因为JOIN的右边不是一个实际的物理表，而是一个VIEW或者Table-valued Funciton。

聊什么 在《Apache Flink 漫谈系列 - SQL概览》中我们介绍了JOIN算子的语义和基本的使用方式，介绍过程中大家发现Apache Flink在语法语义上是遵循ANSI-SQL标准的，那么再深思一下传统数据库为啥需要有JOIN算子呢？在实现原理上面Apache Flink内部实现和传统.

12月20日，北京国家会议中心。Flink Forward China 2018 强势来袭～

实际问题 很多大数据计算产品，都对用户提供了SQL API，比如Hive, Spark, Flink等，那么SQL作为传统关系数据库的查询语言，是应用在批查询场景的。Hive和Spark本质上都是Batch的计算模式(在《Apache Flink 漫谈系列 - 概述》我们介绍过Spark是Micr.

实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。那么在计算过程中如果网络、机器等原因导致Task运行失败了，Apache Flink会如何处理呢？在 《Apache Flink 漫谈系列 - State》一篇中我们介绍了 Apache Flink 会利用State记录计算的状态，在Failover时候Task会根据State进行恢复。

实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。

Apache Flink China Meetup北京站来啦～

为进一步提升Apache Flink在国内的技术影响力，实时计算组运营团队在过去两个月的时间里，对Flink China社区持续进行品牌包装与推广，现将运营效果通过生态建设 / 活动运营 / 问卷调研 / 社区共建 / 内容输出 / 运营计划 六个方面展示。

2017年双11，虽然仓配系统做了非常多业务端的优化，使得峰值不会达到如交易系统那般恐怖的程度，但仓配业务链路长、节点多、分析维度复杂的业务特点，也使我们在开发仓配实时数据的过程中，面临了不少挑战。而正好基于双11的业务背景，我们也开始着手建立起带有"仓配特色"的实时数据版图。

阿里影业实时报表开始做法也是按照传统型报表做法一样，直接从阿里云rds写sql查询，随着数据量越来越大，这种做法已经没有办法满足业务扩张，带来的问题响应时间变慢，吞吐量低，我们急需要一种技术方案能满足未来2-3年随着影院增加，数据增长，而报表功能还能很好的满足客户需求技术方案。

9月19日，云栖大会的Flink分论坛，在杭州正式开幕。今天是云栖大会的第一天，据悉，这也是云栖大会首次加入Flink的论坛，足见阿里对于Flink前景的看好与重视。本次Flink分论坛，除了阿里巴巴的嘉宾外，论坛也邀请了Data Artisans的联合创始人，Flink的开创者和发扬者同台，共话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模型，并详细地阐述了它的语义，设计的核心原则，以及在实践开发过程中对模型的检验。