Blinker

本文为 Apache Flink 新版本重大功能特性解读之 Flink SQL 系列文章的开篇，Flink SQL 系列文章由其核心贡献者们分享，涵盖基础知识、实践、调优、内部实现等各个方面，带你由浅入深地全面了解 Flink SQL。 1. 发展历程今年的8月22日 Apache Flink 发布了1.9.0 版本(下文简称1.9)，在 Flink 1.9 中，Table 模块迎来了核心架构的升级，引入了阿里巴巴Blink团队贡献的诸多功能，本文对Table 模块的架构进行梳理并介绍如何使用 Blink Planner。 Flink 的 Table 模块 包括 Table API 和 SQL，Table API 是一种类SQL的API，通过Table API，用户可以像操作表一样操作数据，非常直观和方便；SQL作为一种声明式语言，有着标准的语法和规范，用户可以不用关心底层实现即可进行数据的处理，非常易于上手，Flink Table API 和 SQL 的实现上有80%左右的代码是公用的。作为一个流批统一的计算引擎，Flink 的 Runtime 层是统一的，但在 Flink 1.9 之前，Flink API 层 一直分为DataStream API 和 DataSet API， Table API & SQL 位于 DataStream API 和 DataSet API 之上。 ...

阿里妹导读：菜鸟供应链业务链路长、节点多、实体多，使得技术团队在建设供应链实时数仓的过程中，面临着诸多挑战，如：如何实现实时变Key统计？如何实现实时超时统计？如何进行有效地资源优化？如何提升多实时流关联效率？如何提升实时作业的开发效率？ 而 Blink 能否解决这些问题？下面一起来深入了解。背景菜鸟从2017年4月开始探索 Blink（即 Apache Flink 的阿里内部版本），2017年7月开始在线上环境使用 Blink，作为我们的主流实时计算引擎。 为什么短短几个月的探索之后，我们就选择Blink作为我们主要的实时计算引擎呢？ 在效率上，Blink 提供 DataStream、TableAPI、SQL 三种开发模式，强大的 SQL 模式已经满足大部分业务场景，配合半智能资源优化、智能倾斜优化、智能作业压测等功能，可以极大地提升实时作业的开发效率；在性能上，诸如MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案，可以极大地提升实时作业的性能；在保障上，Blink 自带的 Failover 恢复机制，能够实现线程级的恢复，可以做到分钟级恢复，配合 Kmonitor 监控平台、烽火台预警平台，可以有效地实现实时作业的数据保障。 接下来，我将结合供应链业务的一些业务场景，简要说明，Blink 如何解决我们遇到的一些实际问题。 回撤机制订单履行是供应链业务中最常见的物流场景。什么是订单履行呢？当商家 ERP 推单给菜鸟之后，菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间，配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约，我们经常需要统计每家配送公司每天各个节点的预计单量，便于配送公司提前准备产能。 看似很简单的实时统计加工，我们在开发过程中遇到了什么问题呢？履行重算！当物流订单的上游某个节点延迟时，履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后，其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说，并不能很友好的支持这种变 Key 统计的问题。以前，数据量没那么大的时候，还可以通过 OLAP 数据库来解决这类场景，当量上来后， OLAP 方案的成本、性能都是很大的问题。 除了 OLAP 方案，我们提倡采用 Blink 已经内置的 Retraction 机制，来解决这类变 Key 统计的问题，这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的Retraction 机制，使用 State 在内存或者外部存储设备中对数据进行统计处理，当上游数据源对某些汇总 Key 的数据做更新时，Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息，并用最新下发的消息对表做更新操作。 下面是一个简化后的案例，供了解Blink Retraction的内部计算过程： 对于上述案例，可以通过 Blink 提供的强大的、灵活的、简易的 SQL 开发模式来实现，只需要几行 SQL 即可完成。 select plan_tms_sign_time ,sum(1) as plan_tms_sign_lgtord_cntfrom (select lg_order_code ,last_value(plan_tms_sign_time) as plan_tms_sign_time from dwd_csn_whc_lgt_fl_ord_ri group by lg_order_code ) ssgroup by plan_tms_sign_time;维表关联供应链业务的实体角色非常多（仓、配、分拨、站点、小件员、货主、行业、地区等），实体繁多，这意味着我们在建设实时明细中间层的时候，会使用大量的维表关联，这对 Blink 在维表关联的性能上提出了更高的要求——如何提升大量的大小维表的关联性能？Blink 从来没让用户失望，Blink SQL 模式在维表关联的性能上，也做了大量的优化： ...

表格存储: 数据存储和数据消费All in one表格存储（Table Store）是阿里云自研的NoSQL多模型数据库，提供PB级结构化数据存储、千万TPS以及毫秒级延迟的服务能力。在实时计算场景里，表格存储强大的写入能力和多模型的存储形态，使其不仅可以作为计算结果表，同时也完全具备作为实时计算源表的能力。通道服务是表格存储提供的全增量一体化数据消费功能，为用户提供了增量、全量和增量加全它量三种类型的分布式数据实时消费通道。实时计算场景下，通过为数据表建立数据通道，用户可以以流式计算的方式对表中历史存量和新增数据做数据消费。利用表格存储存储引擎强大的写入能力和通道服务完备的流式消费能力，用户可以轻松做到数据存储和实时处理all in one！Blink: 流批一体的数据处理引擎Blink是阿里云在Apache Flink基础上深度改进的实时计算平台，同Flink一致Blink旨在将流处理和批处理统一，但Blink相对于社区版Flink，在稳定性上有很多优化，在某些场景特别是在大规模场景会比Flink更加稳定。Blink的另一个重大改进是实现了全新的 Flink SQL 技术栈，在功能上，Blink支持现在标准 SQL 几乎所有的语法和语义，在性能上，Blink也比社区Flink更加强大，特别是在批 SQL 的性能方面，当前 Blink 版本是社区版本性能的 10 倍以上，跟 Spark 相比，在 TPCDS 这样的场景 Blink 的性能也能达到 3 倍以上[1]。从用户技术架构角度分析，结合表格存储和Blink可以做到：1. 存储侧，使用表格存储，则可以做到写一份数据，业务立即可见，同时原生支持后续流式计算消费，无需业务双写；2. 计算侧，使用Blink流批一体处理引擎，可以统一流批计算架构，开发一套代码支持流批两个需求场景。本文就将为大家介绍实时计算的最佳架构实践：基于表格存储和Blink的实时计算架构，并带快速体验基于表格存储和Blink的数据分析job。更优的实时计算架构：基于表格存储和Blink的实时计算架构我们以一个做态势感知的大数据分析系统为例，为大家阐述表格存储和Blink实时计算的架构优势。假如客户是大型餐饮企业CEO，连锁店遍布全国各地，CEO非常关心自己有没有服务好全国各地的吃货，比如台湾顾客和四川顾客在口味评价上会不会有不同？自己的菜品是否已经热度下降了？为了解决这些问题，CEO需要一个大数据分析系统，一方面可以实时监控各地菜品销售额信息，另一方面也希望能有定期的历史数据分析，能给出自己关心的客户变化趋势。用技术角度来解读，就是客户需要：1. 客户数据的实时处理能力，持续聚合新增的订单信息，能大屏展示和以日报形式展示；2.对历史数据的离线分析能力，分析离线数据做态势感知、决策推荐。经典的解决方案基本上基于Lambda大数据架构[2]，如下图1，用户数据既需要进入消息队列系统（New Data Stream如Kafka）作为实时计算任务的输入源，又需要进入数据库系统(All Data如HBASE)来支持批处理系统，最终两者的结果写入数据库系统(MERGED VIEW)，展示给用户。这个系统的缺点就是太庞大，需要维护多个分布式子系统，数据既要写入消息队列又要进入数据库，要处理两者的双写一致性或者维护两者的同步方案，计算方面要维护两套计算引擎、开发两套数据分析代码，技术难度和人力成本很高。利用表格存储同时具备强大的写入能力、实时数据消费能力，Blink + SQL的高性能和流批融合，经典Lambda架构可以精简为下图2，基于表格存储和Blink的实时计算架构：该架构引入的依赖系统大大减少，人力和资源成本都明显下降，它的基本流程只包括：用户将在线订单数据或者系统抓取数据写入表格存储源表，源表创建通道服务数据通道；实时计算任务(黄线)，使用Blink表格存储数据源DDL定义SQL源表和结果表，开发和调试实时订单日聚合SQL job；批处理计算任务(绿线)，定义批处理源表结果表[1]，开发历史订单分析SQL job;前端服务通过读取表格存储结果表展示日报和历史分析结果；快速开始介绍完架构，我们就来迅速开发一个基于TableStore和Blink的日报实时计算SQL，以流计算的方式统计每日各个城市的实时用餐单数和餐费销售额。在表格存储控制台创建消费订单表consume_source_table(primary key: id[string])，并在订单表->通道管理下建立增量通道blink-demo-stream, 创建日统计结果表result_summary_day(primary key: summary_date[string])；在Blink开发界面，创建消费订单源表、日统计结果表、每分钟聚合视图和写入SQL：—消费订单源表CREATE TABLE source_order ( id VARCHAR,– 订单ID restaurant_id VARCHAR, –餐厅ID customer_id VARCHAR,–买家ID city VARCHAR,–用餐城市 price VARCHAR,–餐费金额 pay_day VARCHAR, –订单时间 yyyy-MM-dd primary(id)) WITH ( type=‘ots’, endPoint =‘http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com’, instanceName = “blink-demo”, tableName =‘consume_source_table’, tunnelName = ‘blink-demo-stream’,);—日统计结果表CREATE TABLE result_summary_day ( summary_date VARCHAR,–统计日期 total_price BIGINT,–订单总额 total_order BIGINT,–订单数 primary key (summary_date)) WITH ( type= ‘ots’, endPoint =‘http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com’, instanceName = “blink-demo”, tableName =‘result_summary_day’, column=‘summary_date,total_price,total_order’);INSERT into result_summary_dayselect cast(pay_day as bigint) as summary_date, –时间分区count(id) as total_order, –客户端的IPsum(price) as total_order, –客户端去重from source_ods_fact_log_track_actiongroup by pay_day;上线聚合SQL, 在表格存储源表写入订单数据，可以看到result_summary_day持续更新的日订单数，大屏展示系统可以根result_summary_day直接对接；总结使用表格存储和Blink的大数据分析架构，相对于传统开源解决方案，有很多优势：1、强大的存储和计算引擎，表格存储除了海量存储、极高的读写性能外，还提供了多元索引、二级索引、通道服务等多种数据分析功能，相对HBASE等开源方案优势明显，Blink关键性能指标为开源Flink的3到4倍，数据计算延迟优化到秒级甚至亚秒级；2、全托管服务，表格存储和Blink都全托管的serverless服务，即开即用；3、低廉的人力和资源成本，依赖服务全serverless免运维，按量付费，避免波峰波谷影响；篇幅原因，本文主要介绍了表格存储和Blink结合的大数据架构优势，以及简单SQL演示，后续更复杂、贴近场景业务的文章也会陆续推出，敬请期待！参考文献1. Blink解密，https://yq.aliyun.com/articles/6891172. Lambda大数据架构，https://mapr.com/developercentral/lambda-architecture/本文作者：竹千代_阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

案例与解决方案汇总页：阿里云实时计算产品案例&解决方案汇总一. 背景介绍如<利用blink+MQ实现流计算中的延时统计问题>一文中所描述的场景，我们将其简化为以下案例：实时流的数据源结构如下：物流订单号支付时间仓接单时间仓出库时间LP12018-08-01 08:00 LP12018-08-01 08:002018-08-01 09:00 LP22018-08-01 09:10 LP22018-08-01 09:102018-08-01 09:50 LP22018-08-01 09:102018-08-01 09:502018-08-01 12:00我们期望通过以上数据源，按照支付日期统计，每个仓库的仓接单量、仓出库量、仓接单超2H未出库单量、仓接单超6H未出库单量。可以看出，其中LP1仓接单时间是2018-08-01 09:00，但一直到2018-08-01 12:00点之前，一直都没有出库，LP1满足仓接单超2H未出库的行为。该场景的难点就在于：订单未出库。而对于TT中的源消息流，订单未出库，TT就不会下发新的消息，不下发新的消息，blink就无法被触发计算。而针对上述的场景，对于LP1，我们需要在仓接单时间是2018-08-01 09:00+2H，也就是2018-08-01 11:00的之后，就要知道LP1已经仓接单但超2H未出库了。二. 解决方案本文主要是利用blink CEP来实现上述场景，具体实现步骤如下所述。第一步：在source DDL中定义event_timestamp，并定义sink，如下：—-定义sourcecreate table sourcett_dwd_ri( lg_order_code varchar comment ‘物流订单号’ ,ded_pay_time varchar comment ‘支付时间’ ,store_code varchar comment ‘仓库编码’ ,store_name varchar comment ‘仓库名称’ ,wms_create_time varchar comment ‘仓接单时间’ ,wms_consign_create_time varchar comment ‘仓出库时间’ ,evtstamp as case when coalesce(wms_create_time, ‘’) <> ’’ then to_timestamp(wms_create_time, ‘yyyy-MM-dd HH:mm:ss’) else to_timestamp(‘1970-01-01 00:00:00’, ‘yyyy-MM-dd HH:mm:ss’) end –构造event_timestamp，如果源表本身带有消息的occur_time,可直接选择occur_time作为event_timestamp ,WATERMARK FOR evtstamp AS withOffset(evtstamp, 10000) –设置延迟10秒处理)with( type=‘tt’ ,topic=‘dwd_ri’ ,accessKey=‘xxxxxx’ ,accessId=‘xxxxxx’ ,lengthCheck=‘PAD’ ,nullValues=’\N|’);—-定义sinkcreate table sink_hybrid_blink_cep( ded_pay_date varchar comment ‘支付日期’ ,store_code varchar comment ‘仓库编码’ ,store_name varchar comment ‘仓库名称’ ,wms_create_ord_cnt bigint comment ‘仓接单量’ ,wms_confirm_ord_cnt bigint comment ‘仓出库量’ ,wmsin_nowmsout_2h_ord_cnt bigint comment ‘仓接单超2小时未出库单量’ ,wmsin_nowmsout_6h_ord_cnt bigint comment ‘仓接单超6小时未出库单量’ ,sub_partition bigint comment ‘二级分区（支付日期)’ ,PRIMARY KEY (ded_pay_date, store_code, sub_partition))with( type=‘PetaData’ ,url = ‘xxxxxx’ ,tableName=‘blink_cep’ ,userName=‘xxxxxx’ ,password=‘xxxxxx’ ,bufferSize=‘30000’ ,batchSize=‘3000’ ,batchWriteTimeoutMs=‘15000’);第二步：根据blink CEP的标准语义进行改写，如下：create view blink_cep_v1asselect ‘仓接单-仓出库超时’ as timeout_type ,lg_order_code ,wms_create_time as start_time ,wms_consign_create_time as end_timefrom source_dwd_csn_whc_lgt_fl_ord_riMATCH_RECOGNIZE( PARTITION BY lg_order_code ORDER BY evtstamp MEASURES e1.wms_create_time as wms_create_time ,e2.wms_consign_create_time as wms_consign_create_time ONE ROW PER MATCH WITH TIMEOUT ROWS –重要，必须设置延迟也下发 AFTER MATCH SKIP TO NEXT ROW PATTERN (e1 -> e2) WITHIN INTERVAL ‘6’ HOUR EMIT TIMEOUT (INTERVAL ‘2’ HOUR, INTERVAL ‘6’ HOUR) DEFINE e1 as e1.wms_create_time is not null and e1.wms_consign_create_time is null ,e2 as e2.wms_create_time is not null and e2.wms_consign_create_time is not null)where wms_create_time is not null –重要，可以大大减少进入CEP的消息量and wms_consign_create_time is null –重要，可以大大减少进入CEP的消息量;第三步：根据blink的执行机制，我们通过源实时流sourcett_dwd_ri与超时消息流blink_cep_v1关联，来触发blink对超时消息进行聚合操作，如下：create view blink_cep_v2asselect a.lg_order_code as lg_order_code ,last_value(a.store_code ) as store_code ,last_value(a.store_name ) as store_name ,last_value(a.ded_pay_time ) as ded_pay_time ,last_value(a.wms_create_time ) as wms_create_time ,last_value(a.real_wms_confirm_time ) as real_wms_confirm_time ,last_value(case when coalesce(a.wms_create_time, ‘’) <> ’’ and coalesce(a.real_wms_confirm_time, ‘’) = ’’ and now() - unix_timestamp(a.wms_create_time,‘yyyy-MM-dd HH:mm:ss’) >= 7200 then ‘Y’ else ‘N’ end) as flag_01 ,last_value(case when coalesce(a.wms_create_time, ‘’) <> ’’ and coalesce(a.real_wms_confirm_time, ‘’) = ’’ and now() - unix_timestamp(a.wms_create_time,‘yyyy-MM-dd HH:mm:ss’) >= 21600 then ‘Y’ else ‘N’ end) as flag_02from (select lg_order_code as lg_order_code ,last_value(store_code ) as store_code ,last_value(store_name ) as store_name ,last_value(ded_pay_time ) as ded_pay_time ,last_value(wms_create_time ) as wms_create_time ,last_value(wms_consign_create_time) as real_wms_confirm_time from sourcett_dwd_ri group by lg_order_code ) aleft outer join (select lg_order_code ,count(*) as cnt from blink_cep_v1 group by lg_order_code ) bon a.lg_order_code = b.lg_order_codegroup by a.lg_order_code;insert into sink_hybrid_blink_cepselect regexp_replace(substring(a.ded_pay_time, 1, 10), ‘-’, ‘’) as ded_pay_date ,a.store_code ,max(a.store_name) as store_name ,count(case when coalesce(a.wms_create_time, ‘’) <> ’’ then a.lg_order_code end) as wmsin_ord_cnt ,count(case when coalesce(a.real_wms_confirm_time, ‘’) <> ’’ then a.lg_order_code end) as wmsout_ord_cnt ,count(case when a.flag_01 = ‘Y’ then a.lg_order_code end) as wmsin_nowmsout_2h_ord_cnt ,count(case when a.flag_02 = ‘Y’ then a.lg_order_code end) as wmsin_nowmsout_6h_ord_cnt ,cast(regexp_replace(SUBSTRING(ded_pay_time, 1, 10), ‘-’, ‘’) as bigint) as sub_partitionfrom blink_cep_v2 as t1where coalesce(lg_cancel_time, ‘’) = ‘‘and coalesce(ded_pay_time, ‘’) <> ‘‘group by regexp_replace(substring(ded_pay_time, 1, 10), ‘-’, ‘’) ,a.store_code;三. 问题拓展blink CEP的参数比较多，要完全看懂，着实需要一些时间，但CEP的强大是毋庸置疑的。CEP不仅可以解决物流场景中的超时统计问题，风控中的很多场景也是信手拈来。这里有一个风控中的场景，通过上述物流案例的用法，我们是否能推敲出这个场景的用法呢？风控案例测试数据如下：刷卡时间银行卡ID刷卡地点2018-04-13 12:00:001WW2018-04-13 12:05:001WW12018-04-13 12:10:001WW22018-04-13 12:20:001WW我们认为，当一张银行卡在10min之内，在不同的地点被刷卡大于等于两次，我们就期望对消费者出发预警机制。blink CEP是万能的么？答案是否定的，当消息乱序程度比较高的时候，实时性和准确性就成了一对矛盾的存在。要想实时性比较高，必然要求设置的offset越小越好，但offset设置比较小，就直接可能导致很多eventtime<watermark-offset的消息，直接被丢弃，准确性很难保证。比如，在CP回传物流详情的时候，经常回传的时间跟实操的时间差异很大（实操时间是10点，但回传时间是15点），如果以实操时间作为eventtime，可能就会导致这种差异很大的消息被直接丢掉，无法进入CEP，进而无法触发CEP后续的计算，在使用CEP的过程中，应该注意这一点。四. 作者简介花名：缘桥，来自菜鸟-CTO-数据部-仓配数据研发，主要负责菜鸟仓配业务的离线和实时数据仓库建设以及创新数据技术和工具的探索和应用。本文作者：付空阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

案例与解决方案汇总页：阿里云实时计算产品案例&解决方案汇总一. 背景介绍菜鸟的物流数据本身就有链路复杂、实操节点多、汇总维度多、考核逻辑复杂的特点，对于实时数据的计算存在很大挑战。经过仓配ETL团队的努力，目前仓配实时数据已覆盖了绝大多数场景，但是有这样一类特殊指标：“晚点超时指标”（例如：出库超6小时未揽收的订单量），仍存在实时汇总计算困难。原因在于：流计算是基于消息触发计算的，若没有消息到达到则无法计算，这类指标恰好是要求在指定的超时时间计算出有多少未达到的消息。然而，这类指标对于指导实操有着重要意义，可以告知运营小二当前多少订单积压在哪些作业节点，应该督促哪些实操人员加快作业，这对于物流的时效KPI达成至关重要。之前的方案是：由产品前端根据用户的请求查询OLAP数据库，由OLAP从明细表出结果。大促期间，用户请求量大，加之数据量大，故对OLAP的明细查询造成了比较大的压力。二. 解决方案2.1 问题定义“超时晚点指标” 是指，一笔订单的两个相邻的实操节点node_n-1 、node_n 的完成时间 time_n-1、time_n，当满足 : time_n is null && current_time - time_n-1 > kpi_length 时，time_flag_n 为 true , 该笔订单计入 超时晚点指标的计数。如下图，有一笔订单其 node_1 为出库节点，时间为time_1 = ‘2018-06-18 00:00:00’ ，运营对出库与揽收之间考核的时长 kpi_length = 6h, 那么当前自然时间 current_time > ‘2018-06-18 06:00:00’ 时，且node_2揽收节点的time_2 为null，则该笔订单的 timeout_flag_2 = true , “出库超6小时未揽收订单量” 加1。由于要求time_2 为null，即要求没有揽收消息下发的情况下让流计算做汇总值更新，这违背了流计算基于消息触发的基本原理，故流计算无法直接算出这种“超时晚点指标”。决问题的基本思路是：在考核时刻（即 kpi_time = time_n-1+kpi_length ）“制造”出一条消息下发给流计算，触发汇总计算。继续上面的例子：在考核时刻“2018-06-18 06:00:00”利用MetaQ定时消息功能“制造”出一条消息下发给流计算汇总任务，触发对该笔订单的 time_out_flag_2 的判断，增加汇总计数。同时，还利用 Blink 的Retraction 机制，当time_2 由null变成有值的时候，Blink 可以对 time_out_flag_2 更新，重新计数。2.2 方案架构如上图所示：Step1: Blink job1 接收来自上游系统的订单数据，做清洗加工，生成订单明细表：dwd_ord_ri，利用TT下发给Blink job2 和 Blink job3。Step2：Blink job2 收到 dwd_ord_ri后，对每笔订单算出考核时刻 kpi_time = time_n-1+kpi_length，作为MetaQ消息的“TIMER_DELIVER_MS” 属性，写入MetaQ。MetaQ的定时消息功能，可以根据用户写入的TIMER_DELIVER_MS 在指定时刻下发给消费者，即上图中的Blink job3。Step3：Blink job3 接收 TT、MetaQ 两个消息源，先做Join，再对time_flag判断，最后做Aggregate计算。同一笔订单，dwd_ord_ri、timing_msg任意一个消息到来，都会触发join，time_flag判断，aggregate重新计算一遍，Blink的Retraction可对结果进行实时更新。2.3 实现细节本方案根据物流场景中多种实操节点、多种考核时长的特点，从Blink SQL代码 和 自定义Sink两方面做了特殊设计，从而实现了灵活配置、高效开发。（1） Blink job2 — 生成定时消息关键Blink SQL 代码如下。约定每条record的第一个字段为投递时间列表，即MetaQ向消费者下发消息的时刻List，也就是上面所说的多个考核时刻。第二个字段为保序字段，比如在物流场景中经常以订单code、运单号作为保序主键。该代码实现了对每个出库的物流订单，根据其出库时间，向后延迟6小时（21600000毫秒）、12小时（43200000毫秒）、24小时（86400000毫秒）由MetaQ向消费者下发三个定时消息。create table metaq_timing_msg(deliver_time_list varchar comment ‘投递时间列表’, – 约定第一个字段为投递时间listlg_code varchar comment ‘物流订单code’, – 约定第二字段为保序主键node_name varchar comment ‘节点名称’,node_time varchar comment ‘节点时间’,)WITH(type = ‘custom’,class = ‘com.alibaba.xxx.xxx.udf.MetaQTimingMsgSink’,tag = ‘store’,topic = ‘blink_metaq_delay_msg_test’,producergroup = ‘blinktest’,retrytimes = ‘5’,sleeptime = ‘1000’);insert into metaq_timing_msgselectconcat_ws(’,’,cast( (UNIX_TIMESTAMP(store_out_time)*1000 + 21600000) as varchar), –6小时cast( (UNIX_TIMESTAMP(store_out_time)*1000 + 43200000) as varchar), –12小时cast( (UNIX_TIMESTAMP(store_out_time)*1000 + 86400000) as varchar) –24小时) as deliver_time_list,lg_code,‘wms’ as node_name,store_out_time as node_timefrom(selectlg_code,FIRST_VALUE(store_out_time) as store_out_timefrom srctablegroup by lg_code)bwhere store_out_time is not null ;（2） Blink 自定义Sink — MetaQTimingMsg SinkBlink的当前版本还不支持 MetaQ的定时消息功能的Sink，故利用 Blink的自定义Sink功能，并结合菜鸟物流数据的特点开发了MetaQTimingMsg Sink。关键代码如下（实现 writeAddRecord 方法）。@Overridepublic void writeAddRecord(Row row) throws IOException {Object deliverTime = row.getField(0);String[] deliverTimeList = deliverTime.toString().split(",");for(String dTime:deliverTimeList){ String orderCode = row.getField(1).toString(); String key = orderCode + “_” + dTime; Message message = newMessage(row, dTime, key); boolean result = sendMessage(message,orderCode); if(!result){ LOG.error(orderCode + " : " + dTime + " send failed"); } }}private Message newMessage(Row row,String deliverMillisec,String key){ //Support Varbinary Type Insert Into MetaQ Message message = new Message(); message.setKeys(key); message.putUserProperty(“TIMER_DELIVER_MS”,deliverMillisec); int arity = row.getArity(); Object[] values = new Object[arity]; for(int i=0;i<arity;i++){ values[i]=row.getField(i); } String lineStr=org.apache.commons.lang3.StringUtils.join(values, FIELD_DELIMITER); try { byte[] bytes = lineStr.getBytes(ENCODING); message.setBody(bytes); message.setWaitStoreMsgOK(true); } catch (UnsupportedEncodingException e) { LOG.error(“create new message error”,e); } return message;}private boolean sendMessage(Message message,String orderCode){ long retryTime = 0; boolean isSendSuccess = true; if(message != null){ message.setTopic(topicName); message.setTags(tagName); } SendResult result = producer.send(message, new MessageQueueSelector() { @Override public MessageQueue select(List<MessageQueue> list, Message message, Object o) { …. // 针对物流订单code的hash算法 return list.get(index.intValue()); } },orderCode); if(!result.getSendStatus().equals(SendStatus.SEND_OK)){ LOG.error("" + orderCode +" write to metaq result is " + result.getSendStatus().toString()); isSendSuccess = false; } return isSendSuccess;}}（3）Blink job3 — 汇总计算关键Blink SQL 代码如下，统计了每个仓库的“出库超6小时未揽收物理订单”、“出库超12小时未揽收物理订单”、“出库超24小时未揽收物理订单”的汇总值。代码中使用了“stringLast()”函数处理来自dwd_ord_ri的每条消息，以取得每个物流订单的最新出库揽收情况，利用Blink Retraction机制，更新汇总值。create view dws_store_view as select t1.store_code, max(t1.store_name) as store_name, count(case when length(trim(t1.store_out_time)) = 19 and t1.tms_collect_time is null and NOW()-UNIX_TIMESTAMP(t1.store_out_time,‘yyyy-MM-dd HH:mm:ss’) >= 21600 then t2.lg_code end ) as tms_not_collect_6h_ord_cnt, —出库超6小时未揽收物流订单量 count(case when length(trim(t1.store_out_time)) = 19 and t1.tms_collect_time is null and NOW()-UNIX_TIMESTAMP(t1.store_out_time,‘yyyy-MM-dd HH:mm:ss’) >= 43200 then t2.lg_code end ) as tms_not_collect_12h_ord_cnt,—出库超6小时未揽收物流订单量 count(case when length(trim(t1.store_out_time)) = 19 and t1.tms_collect_time is null and NOW()-UNIX_TIMESTAMP(t1.store_out_time,‘yyyy-MM-dd HH:mm:ss’) >= 86400 then t2.lg_code end ) as tms_not_collect_24h_ord_cnt —出库超6小时未揽收物流订单量from ( select lg_code, coalesce(store_code,’-1’) as store_code, store_name, store_out_time, tms_collect_time from ( select lg_code, max(store_code) as store_code, max(store_name) as store_name, stringLast(store_out_time) as store_out_time, stringLast(tms_collect_time)as tms_collect_time, from dwd_ord_ri group by lg_code ) a ) t1left outer join ( select lg_code, from timing_msg where node_name = ‘wms’ group by lg_code) t2on t1.lg_code = t2.lg_codegroup by t1.store_code ;三. 方案优势3.1 配置灵活我们从“Blink SQL 代码” 和“自定义MetaQ” 两个方面设计，用户可以根据具体的业务场景，在Blink SQL的一个view里就能实现多种节点多种考核时间的定时消息生成，而不是针对每一个实操节点的每一种定时指标都要写一个view，这样大大节省了代码量，提升了开发效率。例如对于仓库节点的出库超6小时未揽收、超12小时未揽收、超24小时未揽收，这三个指标利用上述方案，仅需在Blink job2的中metaq_timing_msg的第一个字段deliver_time_list中拼接三个kpi_length，即6小时、12小时、24小时为一个字符串即可，由MetaQTimingMsg Sink自动拆分成三条消息下发给MetaQ。对于不同的节点的考核，仅需在node_name，node_time填写不同的节点名称和节点实操时间即可。3.2 主键保序如2.3节所述，自定义的Sink中 实现了MetaQ的 MessageQueueSelector 接口的 select() 方法，同时在Blink SQL 生成的MetaQ消息默认第二个字段为保序主键字段。从而，可以根据用户自定义的主键，保证同一主键的所有消息放在同一个通道内处理，从而保证按主键保序，这对于流计算非常关键，能够实现数据的实时准确性。3.3 性能优良让专业的团队做专业的事。个人认为，这种大规模的消息存储、消息下发的任务本就应该交给“消息中间件”来处理，这样既可以做到计算与消息存储分离，也可以方便消息的管理，比如针对不同的实操节点，我们还可以定义不同的MetaQ的tag。另外，正如2.2节所述，我们对定时消息量做了优化。考虑到一笔订单的属性字段或其他节点更新会下发多条消息，我们利用了Blink的FIRST_VALUE函数，在Blink job2中同一笔订单的的一种考核指标只下发一条定时消息，大大减少了消息量，减轻了Blink的写压力，和MetaQ的存储。四. 自我介绍马汶园 阿里巴巴 -菜鸟网络—数据部 数据工程师菜鸟仓配实时研发核心成员，主导多次仓配大促实时数据研发，对利用Blink的原理与特性解决物流场景问题有深入思考与理解。本文作者：付空阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

Blink 开源了有一段时间了，竟然没发现有人写相关的博客，其实我已经在我的知识星球里开始写了，今天来看看 Blink 为什么香？我们先看看 Blink 黑色版本：对比下 Flink 版本你就知道黑色版本多好看了。你上传 jar 包的时候是这样的：我们来看看 Blink 运行的 job 长啥样？再来对比一下 Flink 的样子：查看 Job Task 的详情，可以看到开始时间、接收记录、并行度、duration、Queue in/out、TPS查看 subTask，这里可以直接点击这个日志就可以查看 task 日志：查看背压：查看 task metric，可以手动添加，支持的有很多，这点很重要，可以根据每个算子的监控以及时对每个算子进行调优：查看 job 运行时间段的情况：查看 running 的 job：查看已经完成的 job：查看 Task Manager：Task Manager 分配的资源详情：Task Manager metric 监控信息详情：Task Manager log 文件详情，包含运行产生的日志和 GC 日志：Task Manager 日志详情，支持高亮和分页，特别友好，妈妈再也不担心我看不见 “刷刷刷” 的日志了。总结介绍了 Flink 的 Blink 分支编译后运行的界面情况，总体来说很棒，期待后面 Blink 合并到 Flink！本文原创地址是: http://www.54tianzhisheng.cn/2019/02/28/blink/ , 未经允许禁止转载。关注我微信公众号：zhisheng另外我自己整理了些 Flink 的学习资料，目前已经全部放到微信公众号了。你可以加我的微信：zhisheng_tian，然后回复关键字：Flink 即可无条件获取到。更多私密资料请加入知识星球！Github 代码仓库https://github.com/zhisheng17/flink-learning/以后这个项目的所有代码都将放在这个仓库里，包含了自己学习 flink 的一些 demo 和博客。相关文章1、《从0到1学习Flink》—— Apache Flink 介绍2、《从0到1学习Flink》—— Mac 上搭建 Flink 1.6.0 环境并构建运行简单程序入门3、《从0到1学习Flink》—— Flink 配置文件详解4、《从0到1学习Flink》—— Data Source 介绍5、《从0到1学习Flink》—— 如何自定义 Data Source ？6、《从0到1学习Flink》—— Data Sink 介绍7、《从0到1学习Flink》—— 如何自定义 Data Sink ？8、《从0到1学习Flink》—— Flink Data transformation(转换)9、《从0到1学习Flink》—— 介绍Flink中的Stream Windows10、《从0到1学习Flink》—— Flink 中的几种 Time 详解11、《从0到1学习Flink》—— Flink 写入数据到 ElasticSearch12、《从0到1学习Flink》—— Flink 项目如何运行？13、《从0到1学习Flink》—— Flink 写入数据到 Kafka14、《从0到1学习Flink》—— Flink JobManager 高可用性配置15、《从0到1学习Flink》—— Flink parallelism 和 Slot 介绍16、《从0到1学习Flink》—— Flink 读取 Kafka 数据批量写入到 MySQL ...

apache已公开合并计划，点击可阅读原文《Batch as a Special Case of Streaming and Alibaba’s contribution of Blink》，由AI前线进行了翻译。**春节前一周，经过社区内部讨论，阿里巴巴大数据引擎 Blink 作为 Flink 的分支 正式开源。今天，Apache Flink 官方网站发文对 Blink 贡献回 Flink 项目的意义作进一步说明，并公布了 Blink 和 Flink 的合并计划。社区的合并计划最初会将重点放在有界 / 批处理功能上，社区将对 SQL/Table API 模块进行重组，将 Blink 查询规划器（优化器）和运行时（操作符）合并为当前 SQL 运行时的附加查询处理器。经过一段过渡期之后，将开发新的查询处理器，而当前的处理器很可能会被弃用。为了合并 Blink 的调度增强功能和有界数据的作业恢复功能，Flink 社区也在努力重构当前的调度功能。前不久，经社区讨论，阿里巴巴决定将 Blink 贡献回 Flink 项目。为什么说这对 Flink 来说是一件大事？这对 Flink 的用户和社区来说意味着什么？这与 Flink 的整体愿景有着怎样的关系？让我们退后一步，一探究竟。针对 Blink 的贡献形式，Flink 社区讨论邮件如下：https://lists.apache.org/thre…统一的批处理和流式处理方法从早期开始，Flink 就有意采用统一的批处理和流式处理方法。其核心构建块是“持续处理无界的数据流”：如果可以做到这一点，还可以离线处理有界数据集（批处理），因为有界数据集就是在某个时刻结束的数据流。很多项目（例如 Flink、Beam 等）都支持“流式处理优先，将批处理视为流式处理的特殊情况”的理念，这个理念也经常被认为是构建跨实时和离线数据应用程序的强大方式，可以大大降低数据基础设施的复杂性。为什么批处理器仍然存在？“批处理只是流式处理的一个特例”并不意味着所有的流式处理器都能用于批处理——流式处理器的出现并没有让批处理器变得过时：纯流式处理系统在批处理工作负载时其实是很慢的。没有人会认为使用流式处理器来分析海量数据是个好主意。像 Apache Beam 这样的统一 API 通常会根据数据是持续的（无界）还是固定的（有界）将工作负载委托给不同的运行时。Flink 提供了一个流式 API，可以处理有界和无界的场景，同时仍然提供了单独的 DataSet API 和运行时用于批处理，因为速度会更快。那么“批处理只是流式处理的一个特例”这种想法出了什么问题？其实这种范式并没有错。统一批处理和流式处理 API 只是一个方面，我们还需要利用“有界数据”这个特殊情况的某些特征来应对批处理用例。毕竟，批处理器就是专门为这种特殊情况而准备的。建立在流式运行时之上的批处理我们始终认为，同时拥有一个可用于流式处理和批处理的运行时是可能的。一个流式处理优先的运行时也可以利用有界数据流的特殊属性进行快速的批处理，就像批处理器那样。而这就是 Flink 所采用的方法。Flink 包含了一个网络栈，支持低延迟 / 高吞吐的流式数据交换和高吞吐的批次 shuffle。它还提供了很多流式运行时操作符，也为有界输入提供了专门的操作符，如果你选择了 DataSet API 或 Table API，就可以使用这些操作符。因此，Flink 实际上在早期就已经展示出了一些令人印象深刻的批处理性能。下面的基准测试有点旧了，但在早期很好地验证了我们的架构方法。排序 3.2TB（80GB/ 节点）数据所使用的时间（以秒为单位）还差些什么？为了总结这个方法，并让 Flink 在有界数据（批处理）方面达到最新的水平，我们需要做出更多的增强。我们认为下面这些特性是实现我们愿景的关键：真正统一的运行时操作符栈：目前，有界和无界操作符具有不同的网络和线程模型，不会混在一起，也不匹配。最初是因为批处理操作符遵循的是“拉取模型”（为了方便批处理算法），而流式操作符遵循的是“推模型”（可以获得更好的延迟 / 吞吐量）。在统一的操作符栈中，持续流式操作符是基础。在操作有界数据时，如果没有延迟方面的约束，API 或查询优化器可以从更大的操作符集中选择合适的操作符。例如，优化器可以选择一个特殊的连接操作符，先完全读取第一个输入流，然后再读取第二个输入流。利用有界数据流来减小容错范围：如果输入数据是有界的，可以在 shuffle（内存或磁盘）期间缓冲数据，并在发生故障后重放数据。这样可以实现更细粒度的故障恢复，也更有效。利用有界数据流操作符的属性进行调度：持续无界的流式应用程序需要同时运行所有操作符。基于有界数据的应用程序可以根据其中一个操作符如何消费数据（例如，先构建哈希表，再探测哈希表）来调度另一个操作符。这样做可以提高资源效率。为 DataStream API 启用这些特殊优化：目前只有 Table API 在处理有界数据时激活了这些优化。SQL 的性能和覆盖范围：SQL 是事实上的标准数据语言，虽然它被用在持续流式处理种，但并不适用于有界 / 批处理的情况。为了与最佳批处理引擎展开竞争，Flink 需要提升 SQL 查询执行覆盖率和性能。虽然 Flink 的核心数据平面具有很高的性能，但 SQL 执行的速度在很大程度上取决于优化器规则、丰富的操作符和代码生成，等等。现在来说说 BlinkBlink 是 Flink 的一个分支，最初在阿里巴巴内部创建的，针对内部用例对 Flink 进行改进。Blink 添加了一系列改进和集成（https://github.com/apache/fli… ），其中有很多与有界数据 / 批处理和 SQL 有关。实际上，在上面的功能列表中，除了第 4 项外，Blink 在其他方面都迈出了重要的一步：统一的流式操作符：Blink 扩展了 Flink 的流式运行时操作符模型，支持选择性读取不同的输入源，同时保持推送模型的低延迟特性。这种对输入源的选择性读取可以更好地支持一些算法（例如相同操作符的混合散列连接）和线程模型（通过 RocksDB 的连续对称连接）。这些操作符为“侧边输入”（https://cwiki.apache.org/conf… ）等新功能打下了基础。Table API 和 SQL 查询处理器：与最新的 Flink 主分支相比，SQL 查询处理器是演变得最多的一个组件：Flink 目前将查询转换为 DataSet 或 DataStream 程序（取决于输入的特性），而 Blink 会将查询转换为上述流式操作符的数据流。Blink 为常见的 SQL 操作添加了更多的运行时操作符，如半连接（semi-join）、反连接（anti-join）等。查询规划器（优化器）仍然是基于 Apache Calcite，但提供了更多的优化规则（包括连接重排序），并且使用了适当的成本模型。更加积极的流式操作符链接。扩展通用数据结构（分类器、哈希表）和序列化器，在操作二进制数据上更进一步，并减小了序列化开销。代码生成被用于行序列化器。改进的调度和故障恢复：最后，Blink 实现了对任务调度和容错的若干改进。调度策略通过利用操作符处理输入数据的方式来更好地使用资源。故障转移策略沿着持久 shuffle 的边界进行更细粒度的恢复。不需重新启动正在运行的应用程序就可以替换发生故障的 JobManager。Blink 的变化带来了大幅度的性能提升。以下数据由 Blink 开发者提供，给出了性能提升的粗略情况。在 TPC-H 基准测试中，Blink 与 Flink 1.6.0 的相对性能。Blink 性能平均提升 10 倍在 TPC-DS 基准测试中，Blink 与 Spark 的性能，将所有查询的总时间汇总在一起。Blink 和 Flink 的合并计划Blink 的代码目前已经作为 Flink 代码库的一个分支（https://github.com/apache/fli… ）对外开放。合并这么多变更是一项艰巨的挑战，同时还要尽可能保持合并过程不要造成任何中断，并使公共 API 尽可能保持稳定。社区的合并计划最初将重点放在上述的有界 / 批处理功能上，并遵循以下方法以确保能够顺利集成：为了合并 Blink 的 SQL/Table API 查询处理器增强功能，我们利用了 Flink 和 Blink 都具有相同 API 的事实：SQL 和 Table API。在对 Table/SQL 模块（https://cwiki.apache.org/conf…）进行一些重组之后，我们计划将 Blink 查询规划器（优化器）和运行时（操作符）合并为当前 SQL 运行时的附加查询处理器。可以将其视为同一 API 的两个不同的运行器。最开始，可以让用户选择要使用哪个查询处理器。经过一个过渡期之后，将开发新的查询处理器，而当前的处理器很可能会被弃用，并最终被丢弃。因为 SQL 是一个定义良好的接口，我们预计这种转换对用户来说几乎没有影响。为了合并 Blink 的调度增强功能和有界数据的作业恢复功能，Flink 社区已经在努力重构当前的调度功能，并添加对可插拔调度和故障转移策略的支持。在完成这项工作后，我们就可以将 Blink 的调度和恢复策略作为新查询处理器的调度策略。最后，我们计划将新的调度策略应用于有界 DataStream 程序。扩展的目录支持、DDL 支持以及对 Hive 目录和集成的支持目前正在进行单独的设计讨论。总 结我们相信未来的数据处理技术栈会以流式处理为基础：流式处理的优雅，能够以相同的方式对离线处理（批处理）、实时数据处理和事件驱动的应用程序进行建模，同时还能提供高性能和一致性，这些实在是太吸引人了。要让流式处理器实现与专用批处理器相同的性能，利用有界数据的某些属性是关键。Flink 支持批处理，但它的下一步是要构建统一的运行时，并成为一个可以与批处理系统相竞争的流式处理器。阿里巴巴贡献的 Blink 有助于 Flink 社区加快实现这一目标。本文作者：云学习小组阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要： 阿里巴巴计算平台事业部研究员蒋晓伟深入分享Flink和Blink的关系以及未来发展。推荐阅读。12月20日，由阿里巴巴承办的 Flink Forward China 峰会在北京国家会议中心召开，来自阿里、华为、腾讯、美团点评、滴滴、字节跳动等公司的技术专家与参会者分享了各公司基于 Flink 的应用和实践经验。感兴趣的开发者可以看云栖社区的对于大会的主会+5场分论坛的直播与视频点播。会议进行中，看到AI前线对蒋晓伟的采访。正如许多开发者所关心的Flink和Blink的关系（云栖社区2016年文章：阿里蒋晓伟谈流计算和批处理引擎Blink，以及Flink和Spark的异同与优势），如今有了更新的方向。本篇AI前线的专访讲述的极为清晰。特别转载，共享。*今年，实时流计算技术开始步入主流，各大厂都在不遗余力地试用新的流计算框架，实时流计算引擎和 API 诸如 Spark Streaming、Kafka Streaming、Beam 和 Flink 持续火爆。阿里巴巴自 2015 年开始改进 Flink，并创建了内部分支 Blink，目前服务于阿里集团内部搜索、推荐、广告和蚂蚁等大量核心实时业务。在大会的主题演讲上，阿里巴巴集团副总裁周靖人宣布，阿里巴巴内部 Flink 版本 Blink 将于 2019 年 1 月正式开源！ 阿里希望通过 Blink 开源进一步加深与 Flink 社区的联动，并推动国内更多中小型企业使Flink。Flink Forward China会上，AI 前线对阿里巴巴计算平台事业部研究员蒋晓伟（花名量仔）进行了独家专访，他与我们分享了关于下一代实时流计算引擎的看法，并针对 Blink 的重要新特性、开源后 Blink 与 Flink 之间的关系、Blink 后续规划等问题进行了解答。阿里巴巴与 Flink随着人工智能时代的降临和数据量的爆发，在典型的大数据业务场景下，数据业务最通用的做法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在很多的业务场景之下，用户的业务逻辑在批处理和流处理之中往往是相同的。但是，用户用于批处理和流处理的两套计算引擎是不同的。因此，用户通常需要写两套代码。毫无疑问，这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题，所以阿里巴巴就在想：能不能有一套统一的大数据引擎技术，用户只需要根据自己的业务逻辑开发一套代码。这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持，这就是阿里巴巴选择 Flink 的背景和初衷。彼时的 Flink 不管是规模还是稳定性尚未经历实践，成熟度有待商榷。阿里巴巴实时计算团队决定在阿里内部建立一个 Flink 分支 Blink，并对 Flink 进行大量的修改和完善，让其适应阿里巴巴这种超大规模的业务场景。简单地说，Blink 就是阿里巴巴开发的基于开源 Flink 的阿里巴巴内部版本。阿里巴巴基于 Flink 搭建的平台于 2016 年正式上线，并从阿里巴巴的搜索和推荐这两大场景开始实现。目前阿里巴巴所有的业务，包括阿里巴巴所有子公司都采用了基于 Flink 搭建的实时计算平台。目前，这套基于 Flink 搭建的实时计算平台不仅服务于阿里巴巴集团内部，而且通过阿里云的云产品 API 向整个开发者生态提供基于 Flink 的云产品支持。以下内容整理自 AI 前线对蒋晓伟的采访。开源的时机AI 前线：为什么选择现在将 Blink 开源？这其中有哪些考量？什么样的时机才是开源最合适的时机？蒋晓伟： 在我看来，有几个因素：第一个因素是，这几年我们一直试图把阿里对 Flink 的改进推回社区，但社区有自己的步伐，很多时候可能无法把我们的变更及时推回去。对于社区来说，需要达成共识，才能更好地保证开源项目的质量，但同时就会导致推入的速度慢一些。经过这几年积累，我们这边和社区之间的差距已经变得比较大了。Blink 有一些很好的新功能，比如批处理功能，在社区版本是没有的。在过去这段时间里，我们不断听到有人问，Blink 什么时候能开源、是不是能开源这样的呼声。我们有两种方法，一种就是慢慢地推回去再给用户用。但我们认为这样等下去对社区不是最好的。我们还是希望尽快把我们的代码拿出来，尽量让大家都能用起来。所以最近这半年，我们一直都在准备把代码整理好去进行开源。选择在这个时间点开源有几个好处：第一个好处是我们所开源的这些代码在阿里内部经过像双一十、双十二这样巨大流量的检验，让我们对它的质量有更大的信心，这是非常大的好处；第二个好处，Flink Forward 大会是第一次在中国举办，在这样一个场合开源表明了阿里对 Flink 社区坚定的支持，这是一个比较好的场合。主要是基于这些考虑。选 Blink 还是 Flink？这不会是一个问题AI 前线：开源的 Blink 版本会和阿里巴巴内部使用的 Blink 保持一致吗？蒋晓伟： 即将开源的是阿里巴巴双十二的上线版本，还会有一些小的改进。AI 前线：Blink 开源后，两个开源项目之间的关系会是怎样的？未来 Flink 和 Blink 也会由不同的团队各自维护吗？蒋晓伟： 开源的意思是，我们愿意把 Blink 的代码贡献出来，但这两个项目是一个项目。有一件事情需要澄清一下，我们将公开 Blink 的所有代码，让大家都可以看到，但与此同时，我们会跟社区一起努力，通过讨论决定 Blink 以什么样的方式进入 Flink 是最合适的。因为 Flink 是一个社区的项目，我们需要经过社区的同意才能以分支的形式进入 Flink，或者作为变更 Merge 到项目中。我想强调一下，我们作为社区的一员需要跟社区讨论才能决定这件事情。Blink 永远不会成为另外一个项目，如果后续进入 Apache 一定是成为 Flink 的一部分，我们没有任何兴趣另立旗帜，我们永远是 Flink 的一部分，也会坚定地支持 Flink。我们非常愿意把 Blink 的代码贡献给所有人，所以明年 1 月份我们会先将 Blink 的代码公开，但这期间我们也会和社区讨论，以什么样的形式进入 Flink 是最合适的、怎么贡献是社区最希望的方式。我们希望，在 Blink 开源之后，和社区一起努力，把 Blink 好的地方逐步推回 Flink，成为 Flink 的一部分，希望最终 Flink 和 Blink 变成一个东西，阿里巴巴和整个社区一起来维护。而不是把它分成两个东西，给用户选择的困难，这不是我们想要的。因此未来用户也不会面临已经部署了 Flink、是否要把 Flink 迁移到 Blink 的问题，企业选型时也不需要在 Flink 和 Blink 之间抉择，Blink 和 Flink 会是同一个项目。Blink 开源只有一个目的，就是希望 Flink 做得更好。Blink 改进了什么？AI 前线：能不能重点介绍一下即将开源的 Blink 版本有哪些比较重要的新技术特性？与 Flink 最新发布版本相比，阿里的 Blink 做了哪些方面的优化和改进？蒋晓伟： 阿里巴巴实时计算团队不仅对 Flink 在性能和稳定性上做出了很多改进和优化，同时在核心架构和功能上也进行了大量创新和改进。过去两年多，有很多更新已经推回给社区了，包括 Flink 新的分布式架构等。目前我们的 Blink 版本跟社区版本还有几点差异，第一个是稳定性方面，我们做了一些优化，在某些场景会比社区版本更加稳定，特别是在大规模场景。另外还有一个比较大的不一样是我们全新的 Flink SQL 技术栈，它在功能上，特别是在批处理的功能上比社区版本强大很多。它支持现在标准 SQL 几乎所有的语法和语义。另外，在性能上，无论是在流式 SQL 还是批 SQL，我们的版本在性能上都有很大的优势。特别是在批 SQL 的性能方面，当前 Blink 版本是社区版本性能的 10 倍以上，跟 Spark 相比，在 TPCDS 这样的场景 Blink 的性能也能达到 3 倍以上。如果用户对批处理或者对 SQL 有着比较强的需求，我们这个版本会用户可以得到很多好处。Blink 在阿里内部的应用AI 前线：请介绍一下 Blink 在阿里内部的使用情况。目前 Blink 在阿里的大数据架构中扮演什么样的角色？在阿里内部主要用于哪些业务和应用场景？蒋晓伟： 现在阿里的大数据平台上，所有的实时计算都已经在使用 Blink；同时，除了实时计算以外，在一些流批一体化的场景也会用 Blink 来做批处理；我们在机器学习场景也有一个探索，叫做 Alink，这个项目是对 Flink Machine Learning Library 的改进，其中实现了大量的算法，都是基于 Flink 做实时机器学习的算法，Alink 在很多场景已经被证明在规模上有很大的优势。同时，我们在图计算场景也有一些探索。AI 前线：目前阿里内部有多少部门在使用 Blink？蒋晓伟： 前段时间我们刚刚做过统计，阿里的技术部门大约有 70% 都在使用 Blink。Blink 一直是在用户的反馈之中成长起来的，对于内部用户反馈的数据倾斜、资源使用率、易用性方面的问题，Blink 都做了针对性的改进。现在 Blink 用的最多的场景主要还是实时计算方面，阿里还有一些业务现在相对比较新，还没有进入实时计算的领域，等这些业务进入实时计算领域时也会使用 Blink。在批处理方面，阿里内部也有一个自研的批处理引擎叫做 MaxCompute，MaxCompute 也会拥抱 Flink 生态，在语法和语义上做和 Flink 兼容的工作。未来，整个阿里的计算体系和平台都会融入同一个生态。后续规划AI 前线：接下来阿里对于 Blink 还有哪些规划？包括技术改进、落地应用、更新维护、社区等几个方面。蒋晓伟： 从技术上说，今天我们公布了 Flink 在批处理上的成果，接下来，我们会对技术持续投入，我们希望每几个月就能看到技术上有一个比较大的亮点。下一波亮点应该是机器学习场景。要把机器学习支持好，有一系列的工作要做，包括引擎的功能、性能和易用性。这些工作我们已经在内部的讨论和进行之中，接下来几个月，大家应该会看到一些成果。我们也在和社区讨论一些事情。除了机器学习之外，我们在图计算方面也有一些探索，包括对增量迭代更好的支持。做完这些之后，可以认为 Flink 作为大数据的计算引擎已经比较完备了。同时，我们也重点去做 Flink 的生态，包括 Flink 与其他系统之间的关系、易用性等。Flink 要真正做好，不仅需要它本身功能强大，还需要把整个生态做得非常强大。这部分我们甚至会跟一些 ISV 合作，看看是不是能够在 Flink 之上提供更好的解决方案，进一步降低用户的使用门槛。在社区方面，我们希望能够把把 Blink 完全融入 Flink 社区，一起做 Flink 社区的运营，让 Flink 真正在中国、乃至全世界大规模地使用起来。在应用方面，实时流计算其实有很多很有潜力的应用场景，但有一些可能大家不是非常熟悉，我们会对这些场景做一些推广。以实时机器学习为例，它往往能够给我们带来比一般的机器学习更大的效果提升。去年，实时强化学习给我们在搜索上带来了 20% 以上的提升。除此之外，在安全领域（比如实时的 Fraud Detection）、监控报警方面，还有 IoT 领域，实时流计算都有非常广泛的应用场景。这些 Flink 现在可能已经做了，但是大家还没有意识到，Flink 能够给大家带来这样的商业上的好处。AI 前线：Blink 开源之后，后续阿里在这基础上做的变更和更新会以什么样的方式推回社区版本？蒋晓伟： 我们理想的方式是，阿里内部的版本是社区的 Flink 版本加上一些定制化的插件，不需要对 Flink 本身做修改，而是对 Flink 做增加。比如跟阿里内部系统交互的部分跟社区是不适用的，就会保持在内部，我们希望这些修改不动 Flink 代码，而是用插件的方式加在 Flink 上面。最终的方式就是，对于所有公司都有用的修改会在 Flink 代码本身做修改，使所有使用 Flink 的公司都能从中获利，而对接阿里内部系统的部分就只在阿里内部使用。下一代实时流计算引擎之争AI 前线：先在很多人提到实时流计算引擎，都会拿 Spark 和 Flink 来做对比，您怎么看待下一代实时流计算引擎之争？未来实时流计算引擎最重要的发展方向是什么？蒋晓伟：Spark 和 Flink 一开始 share 了同一个梦想，他们都希望能够用同一个技术把流处理和批处理统一起来，但他们走了完全不一样的两条路，前者是用以批处理的技术为根本，并尝试在批处理之上支持流计算；后者则认为流计算技术是最基本的，在流计算的基础之上支持批处理。正因为这种架构上的不同，今后二者在能做的事情上会有一些细微的区别。比如在低延迟场景，Spark 基于微批处理的方式需要同步会有额外开销，因此无法在延迟上做到极致。在大数据处理的低延迟场景，Flink 已经有非常大的优势。经过我们的探索，Flink 在批处理上也有了比较大的突破，这些突破都会反馈回社区。当然，对于用户来说，多一个选择永远是好的，不同的技术可能带来不同的优势，用户可以根据自己业务场景的需求进行选择。未来，在大数据方向，机器学习正在逐渐从批处理、离线学习向实时处理、在线学习发展，而图计算领域同样的事情也在发生，比如实时反欺诈通常用图计算来做，而这些欺诈事件都是实时地、持续不断地发生，图计算也在变得实时化。但是 Flink 除了大数据领域以外，在应用和微服务的场景也有其独特的优势。应用和微服务场景对延迟的要求非常苛刻，会达到百毫秒甚至十毫秒级别，这样的延迟只有 Flink 的架构才能做到。我认为应用和微服务其实是非常大的领域，甚至可能比大数据更大，这是非常激动人心的机会。上面这些都是我们希望能够拓宽的应用领域。AI 前线：在技术方面，Spark 和 Flink 其实是各有千秋，但在生态和背后支持的公司上面，Flink 是偏弱的，那么后续在生态和企业支持这块，阿里会如何帮助 Flink？蒋晓伟： 这次阿里举办 Flink Forward China 就是想推广 Flink 生态的重要举动之一。除了 Flink Forward China 大会，我们还会不定期举办各种线下 Meetup，投入大量精力打造中文社区，包括将 Flink 的英文文档翻译成中文、打造 Flink 中文论坛等。在垂直领域，我们会去寻找一些合作伙伴，将 Flink 包装在一些解决方案中提供给用户使用。AI 前线：关于开源项目的中立性问题。阿里现在在大力地推动 Flink 开源项目的应用和社区的发展，但业界其他公司（尤其是与阿里在其他业务上可能有竞争的公司）在考虑是否采用 Flink 的时候可能还是会对社区的中立性存在一些疑虑，对于这一点，阿里是怎么考虑的？蒋晓伟： 阿里本身会投入非常大的力量推动 Flink 社区的发展和壮大，但我们也非常希望有更多企业、更多人加入社区，和阿里一起推动社区发展，这次阿里承办 Flink Forward China 峰会就是想借此机会让更多公司参与进来。光阿里一家是无法把 Flink 生态做起来的。我希望大家能够看到我们在做的事情，然后消除这样的疑虑。我们会用自己的行动表明，我们是真的希望把 Flink 的社区做大，在这件事情上，我们并不会有私心。本文作者：阿里云头条阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...