4月25-26日，全球首个 Apache 顶级项目在线盛会 Flink Forward 中文精华版重磅开播，聚焦 Alibaba、 Google、AWS、Uber、Netflix、DellEMC、微博、滴滴等各大互联网公司实时计算的经典场景和业务故事，由 Flink 核心贡献者们对 19 个优质 talk 进行中文翻译及解说，您可免费在线观看。
为期一天半的 Flink Forward 中文精华版在北京、上海、杭州三地进行联动直播，吸引了全球近 20000 人次开发者在线观看。除优质内容外，Flink Forward 精华版还首次开创问题征集，在线观看直播的同学可及时对嘉宾分享提出疑问并邀请讲师在线解答。
大会全部提问及解答：
https://shimo.im/sheets/twgyxGh9hqy6DHYk/MODOC/
直播回顾及 Flink 社区学习资料大礼包下载请点击:
Flink Forward 全球在线会议中文精华版0425
Flink Forward 全球在线会议中文精华版0426
以下选取了大会部分具有代表性的问题及讲师回答，共享给大家。
Keynote: Introducing Stateful Functions 2.0: Stream Processing meets Serverless Applications
解说嘉宾：李钰（绝顶），Apache Flink Committer，Apache Flink 1.10 Release Manager，阿里巴巴高级技术专家。
「Q」：PyFlink 支持 Stateful Function 吗？另外 Stateful Function 的 State 管理是怎么样的？
「A」：目前暂不支持。
Stateful Function 的 State 管理和通常 streaming 作业的 State 管理是一样的，并没有作特殊处理。actor system 或者说应用这块，它和 stream processing 有一个很大的区别在于流处理是一个 DAG (有向无环图)的结构。但是 actor system 是可能有环的。Stateful Function 实际上是增加了一个 feedback loop 支持，但它并没有去改动 runtime 内核，可以理解为是利用 streaming 自带的 state 管理来做的。
圆桌 | Lyft: 基于 Flink 的准实时海量数据分析平台
解说嘉宾：王阳（亦祺），阿里巴巴技术专家。
「Q」：Flink 实时写 parquet 文件会不会产生大量小文件呀？怎么处理小文件问题呢？
「A」：用 StreamingFileSink 去写 Parquet 格式的数据是会产生小文件的，这样会导致 presto/hive client 去分析时性能比较差，Lyft 的做法是通过 SuccessFile Sensor 让 airflow 自动调度一些 ETL 的任务来进行 compaction 和 deduplication，已经处理完成的会将 rawevent 的分区 swap 出去。这样处理以后得到更好的数据质量，同时提升交互式查询的性能。
演讲 | 微博基于 Flink 的机器学习实践
分享嘉宾：
- 于茜，微博机器学习研发中心高级算法工程师。多年来致力于使用 Flink 构建实时数据处理和在线机器学习框架，有丰富的社交媒体应用推荐系统的开发经验。
- 曹富强，微博机器学习研发中心系统工程师。现负责微博机器学习平台数据计算模块。主要涉及实时计算 Flink，Storm，Spark Streaming，离线计算 Hive，Spark 等。目前专注于 Flink 在微博机器学习场景的应用。
- 于翔，微博机器学习研发中心算法架构工程师。
「Q」：Gemini 是怎么使用的？
「A」：这个问题比较复杂，后期我们会在公众号发布详细的使用说明及对比实验。
Tips：后期微博机器学习研发中心团队将就“如何使用 Gemini”主题分享一篇技术文章，除详细的使用说明外还有对比实验分析，敬请期待！
「Q」：样本的多流 join 是基于哪种窗口实现的？
「A」：Flink 现有的窗口计算不能满足我们的业务需求，我们用 union + timer 实现了滑动窗口，数据存储到 map state 里，底层采用 rocksdb + ssd 硬盘来存储，并且自定义了样本的 trigger 触发机制。我们对比过 rocksdb，java heap 这两种 state backend 的策略，在均衡业务场景，处理速度和硬件代价之后，最终选择rocksdb + ssd 来作为 state 的 backend。
「Q」：多媒体特征计算是怎么通过 Flink 支持的，能详细解释下吗？这块的稳定性如何？如何保证的?
「A」：首先我们在 gpu上部署算法模型，并且把模型封装成 rpc 服务。然后通过 Flink 来调用 rpc 服务，实时的生成图片，视频的各种特征。
稳定性 ：我们通过 Flink metrics，对整个作业的全流程做监控，包括但不限于rpc服务的耗时，成功率等指标。通过 At Least Once 机制来保证每条数据都处理一次。通过对 source （kafka) 端上的监控来监控整体作业的延迟。
另外根据业务场景引入了高可用的保障机制(对账系统)，来保证数据处理的稳定性，目前重点业务可以达到99.999%的成功率。
「Q」：模型上线后如何使应用自动将原始输入数据转变成模型需要的输入变量？
「A」：模型上线预测时，在在线系统中，我们从特征服务中获取特征字段，拼接出原始特征数据，然后经过一个特征处理的模块，将原始样本转化为模型需要的输入数据（可以是libsvm格式或者是适合 DNN 的其他数据格式），然后传到模型服务模块，特征处理的输出的数据格式以及特征处理的代码，训练与预测时保持一致的，唯一的区别在于训练的数据相对在线预测的数据会多出 label 相关的字段。
演讲 | Alink：提升基于 Flink 的机器学习平台易用性
分享嘉宾：杨旭（品数），阿里巴巴资深技术专家。
「Q」：支持实时机器学习的算法多吗？如何防止个别奇异值对模型的影响？
「A」：Alink 所有的分类、回归模型都支持流式数据的预测，在线学习算法方面目前支持 FTRL。在各个模型训练时，有对特殊数据的处理，另外，使用 Alink 的数据处理组件，也可以在训练前进行数据清洗。
「Q」：1.10 已经没有 FlinkML 了吧？FlinkML 和 ALink 之间的关系是？
「A」：FlinkML 为 Flink 自带的机器学习算法库，分为旧的版本和新的版本。在做 Alink 前，我们首先认真调研了当时的 FlinkML（即旧版本 FlinkML）的情况，其仅支持 10 余种算法，支持的数据结构也不够通用，在算法性能方面做的优化也比较少，而且其代码也很久没有更新。所以，我们放弃了基于旧版 FlinkML 进行改进、升级的想法，决定基于 Flink 重新设计研发机器学习算法库，随后发展为现在的 Alink。
在 Alink 发展的过程中，我们一直与 Flink 社区紧密关联，在每年的 Flink Forward 大会上汇报我们的进展，共同探讨技术问题，获取反馈和建议。随着 Alink 功能的不断增强和完善，社区中欢迎 Alink 进行开源的呼声日益高涨，我们可开始和 Flink 社区更紧密联系，推动开源 Alink 的代码进入 FlinkML。
与此同时，社区中更多的人意识到旧版 FlinkML 的问题，决定整个废弃掉旧版 FlinkML，建设新版 FlinkML。我们积极参加新版 FlinkML API 的设计，分享 Alink API 设计的经验；Alink 的 Params 等概念被社区采纳；之后开始为新版 FlinkML 贡献算法实现代码，已提交了 40 余个 PR，包括算法基础框架、基础工具类及若干算法实现。
Alink 包含了非常多的机器学习算法，在向 FlinkML 贡献的过程中，需要社区 commiter 的讨论设计与审查代码，这个过程有助于代码的精益求精，但由于社区 commiter 的资源有限，代码完全贡献到 FlinkML 的过程会持续很长时间。这时，我们不得不考虑是否有其他方式，可以让用户先用起来，Alink 单独开源是个很好的解决方式，它与向 FlinkML 继续贡献算法实现，可以同时进行。用户的使用反馈也有助于我们更好的改进算法实现。此想法获得了社区的支持，获得了公司内领导和同事的支持，在 Flink Forword Asia 2019 大会上，宣布了 Alink 开源。
圆桌 | Flink SQL 之 2020：舍我其谁
解说嘉宾：伍翀（云邪），Apache Flink PMC，阿里巴巴技术专家。
「Q」：demo 里的 catalog 里表的元数据是基于内存的还是持久化到外部存储的？
「A」：demo 里有注册了两个 catalog，一个 default catalog（内存），一个 hive catalog（持久化），两种 catalog 都能存批的表和流的表（其实 Flink SQL 不区分流和批的表）
「Q」：本案例跟您上一次(2020年2月份)讲的 flink SQL 案例 中用到的特性有什么不一样吗？
「A」：本次 demo 覆盖的 feature 更全，包括 4 种 join，流批一致性，CEP 等等。
圆桌 | Apache Flink 误用之痛
解说嘉宾：孙金城（金竹），Apache Member，Apache Flink PMC，阿里巴巴高级技术专家。
「Q」：Flink 窗口计算，heap 状态存取消耗很多 cpu，对比 spark 相同逻辑窗口计算多耗很多 cpu，请问有没有优化方案？
「A」：这个要看具体的场景，需要更细致的场景说明一下？一般的优化方法如下：
- 尽量用增量聚合替代全量聚合[1]。不仅减小 state 的大小，而且能在数据抵达窗口时就开始计算。
- 注意下 Type 是否都能被 Flink 识别，否则序列化反序列化会用默认的 Kryo，导致序列化反序列化加大 cpu 开销[2]。可以配上
env.getConfig().disableGenericTypes();来禁用 Kryo，验证下是否类型都被Flink识别了。
[1] https://ci.apache.org/projects/flink/flink-docs-master/dev/stream/operators/windows.html#processwindowfunction-with-incremental-aggregation
[2] https://ci.apache.org/projects/flink/flink-docs-stable/dev/types_serialization.html#data-types-serialization
「Q」：请问多个窗口级联相同的 keyby 可以使用 datastreamutil 吗？多个 key 特别长有没有方法优化
「A」：
1.可以用 DataStreamUtil 来级联，避免多次 shuffle。
2.业务上如果有办法优化 key 的长度是最好的，比如减少字段数；或者抽取指定长度或位置的数据作为 key。其次，技术上可以将 key hash 下，比如取 md5，但是这个会带来多余的 cpu 损耗，需要和 key 偏长而带来的网络或 io 损耗来权衡，看哪个代价更高。
圆桌 | Uber ：使用 Flink CEP 进行地理情形检测的实践
解说嘉宾：付典，Apache Flink Committer，阿里巴巴技术专家。
「Q」：CEP 一般怎么调优性能？
「A」：Flink CEP 里，规则的复杂程度对于性能影响很大，所以如果遇到性能问题，可以从是否可以从业务的角度简化规则的角度来优化
「Q」：那个不同的 key 的窗口错开是使用自定义窗口 trigger 吗？
「A」：可以理解为实现了一个自定义的 WindowAssigner，WindowAssigner 针对每个 key 在调用的时候，加入了随机的因素，从而使得不同的 key 得到的窗口范围不一样。
演讲 | A deep dive into Flink SQL
分享嘉宾：伍翀（云邪），Apache Flink PMC，阿里巴巴技术专家。
「Q」：minibatch 减少与 state 交互的方式可以在 datastream 中用吗？
「A」：minibatch 优化目前只在 SQL 层的聚合算子中实现了，DataStream 中用不了。
「Q」：Flink SQL 为了支持流批统一，底层用了大量 CodeGen 技术，同样的 SQL 在底层 codegen 出不同的代码，这个 codegen 过程消耗时间吗？对应批，尤其是 OLAP 这种场景，需要快速出结果的场景，codegen 会占整个过程时间的比例？
「A」：目前 codegen 发生在编译期，因此只执行一次，所以对于流作业和批作业都还好。不过对于 OLAP 场景确实对于 codegen 以及 代码编译都会非常敏感，也是以后的一个优化方向，目前还没有评测过 codegen 的耗时。
「Q」：stream 模式可能拿不到 statistics 的情况下 join 的优化是怎么做的？
「A」：目前流计算模式的所有优化都是确定性的优化，没有考虑 statistics。不过批的优化已经考虑了。在拿不到 stats 的时候，我们会有默认的统计值，比如 rowcount=10^8。
演讲 | Flink's application at Didi
分享嘉宾：薛康，现任滴滴技术专家，实时计算负责人。毕业于浙江大学，曾任百度高级研发工程师，对大数据生态建设有丰富经验。
「Q」：能讲一下 streamsql 在线 debug 功能实现原理吗？
「A」：解析 SQL，替换 source 和 sink 为文件和标准输出，然后正常执行 DML，把结果打印到标准输出，展示在平台上。
「Q」：sql IDE 中写的 sql ，血缘关系是怎么实现的？
「A」：每个 connector 会上报连接的数据源信息，比如 kafka 集群、topic等，作为指标上报到 kafka，然后存入 druid，由平台串联各个环节，组成完整链路。
「Q」：想问下怎么监控各个 flink 集群中作业的运行状态，类似于 flink-web 上的每个作业状态（运行或失败）。
「A」：定期通过 yarn api 拿到每个 app 的 JM 地址，通过 JM 的 restful API 拿到正在运行的 job 信息，判断每个 job 的启动时间，如果在两次判断之间，说明期间有过重启，累积一定次数就可以报警。注意判断刚提交的情况。
「Q」：kafka table 的元数据管理，group.id,start-mode 这种运行时参数怎么持久化？还是只保存静态的 kafka connection 信息 / schema 信息，group.id/start-mode 等作为表参数传入？
「A」：确实，只保存静态信息，比较个性化的运行时信息作为参数，通过 set key=value 的形式作为 job 的一部分一起提交。
演讲 | Data Warehouse, Data Lakes, What's Next?
分享嘉宾：金晓军（仙隐），阿里巴巴高级技术专家。
「Q」：hologres 能支持高性能的更新操作来实现 Flink RetractSink 吗?
「A」：可以支持。其实如果用了 hologres,直接存明细就好了，大部分场景不需要做预聚合，需要的时候直接查询。
「Q」：hologres 大数据量的查询效率如何？能支持更新删除操作不？
「A」：可以支持，目前线上有万亿级别的表做多维分析，能够在200ms以内算出结果。hologres 支持更新和删除。
「Q」：hologres 相较于现在社区的数据湖框架 hudi,delta 和 iceberg 的差异点是什么？
「A」：
- hologres 是数据 ingestion 实时生效，而目前开源方案是 mini-batch，类似于flink和 spark streaming 的区别。
- Hologres 本身是提供服务能力，可以直接给线上应用提供服务，更高的SLA。
- hologres 能提供高 qps 的查询能了，可以直接作为 flink 的维表。
演讲 | 终于等到你：PyFlink + Zeppelin
分享嘉宾：
- 孙金城（金竹），Apache Member，Apache Flink PMC，阿里巴巴高级技术专家。
- 章剑锋（简锋），Apache Member，Apache Zeppelin PMC，阿里巴巴高级技术专家。
「Q」：既然定位在全面整合 Python，那么加强 Jupyter notebook 就好了吧，Zeppelin vs Jupyter怎么考虑？
「A」：首先 PyFlink 会在 Zeppelin 和 Jupyter 中都会进行支持，目前是 Zeppelin走在前面。Zeppelin vs Jupyter 来讲 Zeppelin更加侧重大数据的计算场景， Jupyter 更贴合机器学习的场景，Zeppelin 可以多租户企业级使用，Jupyter 更适合单用户场景。
「Q」：flink on zeppelin 的最佳应用场景有哪些？
「A」：批流计算的 ETL 和数据分析，适合用 flink sql，pyflink 和 table api。
「Q」：Zeppelin 对 K8s 的支持目前如何，社区有这块的规划吗？另外 Zeppelin on K8s 为啥选择使用 Pod 来部署 Zeppelin Server 而不是 statefulset 或者 deployment 呢？
「A」：这块正在做，依赖于 flink 对 k8s 的支持，预计 zeppelin 0.9 + flink 1.11 可以完美支持 k8s。
Production-Ready Flink and Hive Integration - what story you can tell now?
解说嘉宾：李锐（天离），Apache Hive PMC，阿里巴巴技术专家。
**「Q」：既然有 hive 了，也有好用的 Hive 客户端工具，比如 dbvis。如果公司业务是使用 hive 做离线批查询，值得再通过其他框架这样整合吗？我直接使用 dbvis 来做 hive 分析不就好了？
疑问：Hive 是批分析工具，有必要强行和流整合吗？专工具专用是不是更好些？**
「A」：还是有不少用户需要对 hive 做实时化改进的，比如实时写入，或者通过 presto、impala 等做交互式查询。Flink 与 Hive 整合可以完全是批的模式，获取比 Hive 原有批处理更好的性能。另一方面我们也观察到有用户希望能够实时的消费写入 Hive 的数据，这种情况就需要跟流整合了。
「Q」：1.10 中可以在 hivecatalog 上建 kafka 表，是不是已经可以接 kafka 数据写人 hive 表中了（及批流已经统一了）？
「A」：不是的，1.10 只是通过 hive catalog 来保存 kafka 表的元数据，但写入实际数据的时候还是只支持批式的写入。流式写入 hive 表要 1.11 才支持。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
