4月25-26日,全球首个 Apache 顶级项目在线盛会 Flink Forward 中文精华版重磅开播,聚焦 Alibaba、 Google、AWS、Uber、Netflix、DellEMC、微博、滴滴等各大互联网公司实时计算的经典场景和业务故事,由 Flink 核心贡献者们对 19 个优质 talk 进行中文翻译及解说,您可免费在线观看。html
为期一天半的 Flink Forward 中文精华版在北京、上海、杭州三地进行联动直播,吸引了全球近 20000 人次开发者在线观看。除优质内容外,Flink Forward 精华版还首次开创问题征集,在线观看直播的同窗可及时对嘉宾分享提出疑问并邀请讲师在线解答。java
大会所有提问及解答:
https://shimo.im/sheets/twgyxGh9hqy6DHYk/MODOC/web
直播回顾及 Flink 社区学习资料大礼包下载请点击:算法
Flink Forward 全球在线会议中文精华版0425
Flink Forward 全球在线会议中文精华版0426sql
如下选取了大会部分具备表明性的问题及讲师回答,共享给你们。apache
解说嘉宾:李钰(绝顶),Apache Flink Committer,Apache Flink 1.10 Release Manager,阿里巴巴高级技术专家。windows
「Q」:PyFlink 支持 Stateful Function 吗?另外 Stateful Function 的 State 管理是怎么样的?
「A」:目前暂不支持。api
Stateful Function 的 State 管理和一般 streaming 做业的 State 管理是同样的,并无做特殊处理。actor system 或者说应用这块,它和 stream processing 有一个很大的区别在于流处理是一个 DAG (有向无环图)的结构。可是 actor system 是可能有环的。Stateful Function 其实是增长了一个 feedback loop 支持,但它并无去改动 runtime 内核,能够理解为是利用 streaming 自带的 state 管理来作的。restful
解说嘉宾:王阳(亦祺),阿里巴巴技术专家。网络
「Q」:Flink 实时写 parquet 文件会不会产生大量小文件呀?怎么处理小文件问题呢?
「A」:用 StreamingFileSink 去写 Parquet 格式的数据是会产生小文件的,这样会致使 presto/hive client 去分析时性能比较差,Lyft 的作法是经过 SuccessFile Sensor 让 airflow 自动调度一些 ETL 的任务来进行 compaction 和 deduplication,已经处理完成的会将 rawevent 的分区 swap 出去。这样处理之后获得更好的数据质量,同时提高交互式查询的性能。
分享嘉宾:
「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 相关的字段。
分享嘉宾:杨旭(品数),阿里巴巴资深技术专家。
「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 开源。
解说嘉宾:伍翀(云邪),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 Member,Apache Flink PMC,阿里巴巴高级技术专家。
「Q」:Flink 窗口计算,heap 状态存取消耗不少 cpu,对比 spark 相同逻辑窗口计算多耗不少 cpu,请问有没有优化方案?
「A」:这个要看具体的场景,须要更细致的场景说明一下?通常的优化方法以下:
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 损耗来权衡,看哪一个代价更高。
解说嘉宾:付典,Apache Flink Committer,阿里巴巴技术专家。
「Q」:CEP 通常怎么调优性能?
「A」:Flink CEP 里,规则的复杂程度对于性能影响很大,因此若是遇到性能问题,能够从是否能够从业务的角度简化规则的角度来优化
「Q」:那个不一样的 key 的窗口错开是使用自定义窗口 trigger 吗?
「A」:能够理解为实现了一个自定义的 WindowAssigner,WindowAssigner 针对每一个 key 在调用的时候,加入了随机的因素,从而使得不一样的 key 获得的窗口范围不同。
分享嘉宾:伍翀(云邪),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。
分享嘉宾:薛康,现任滴滴技术专家,实时计算负责人。毕业于浙江大学,曾任百度高级研发工程师,对大数据生态建设有丰富经验。
「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 的一部分一块儿提交。
分享嘉宾:金晓军(仙隐),阿里巴巴高级技术专家。
「Q」:hologres 能支持高性能的更新操做来实现 Flink RetractSink 吗?
「A」:能够支持。其实若是用了 hologres,直接存明细就行了,大部分场景不须要作预聚合,须要的时候直接查询。
「Q」:hologres 大数据量的查询效率如何?能支持更新删除操做不?
「A」:能够支持,目前线上有万亿级别的表作多维分析,可以在200ms之内算出结果。hologres 支持更新和删除。
「Q」:hologres 相较于如今社区的数据湖框架 hudi,delta 和 iceberg 的差别点是什么?
「A」:
分享嘉宾:
「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。
解说嘉宾:李锐(天离),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 才支持。