公司网站要多大空间,陆良县住房和城乡建设局网站,ip域名解析查询,莘县网站建设简介#xff1a;本文将对FFA Keynote议题作一些简单的归纳总结#xff0c;感兴趣的小伙伴们可以在FFA官网[2]找到相关主题视频观看直播回放。 作者 | 梅源#xff08;Yuan Mei#xff09; 来源 | 阿里技术公众号
律回春晖渐#xff0c;万象始更新#xff0c;这句诗用来形…简介本文将对FFA Keynote议题作一些简单的归纳总结感兴趣的小伙伴们可以在FFA官网[2]找到相关主题视频观看直播回放。 作者 | 梅源Yuan Mei 来源 | 阿里技术公众号
律回春晖渐万象始更新这句诗用来形容2021年的大数据领域再合适不过而Flink在2021年也开启了新的篇章。
2022年1月8-9号Flink Forward AsiaFFA线上峰会成功举行。Flink Forward Asia 是由 Apache 官方授权Apache Flink中文社区主持举办的会议。目前Flink Forward Asia 已成为国内最大的 Apache 顶级项目会议之一是 Flink 开发者和使用者的年度盛会。在线上峰会的同时FFA还举办了首届以实时计算为主题的Flink Hackathon共有267支参赛队伍最终27支队伍入围参与线下决赛。未来Flink Hackathon也会常态化举办集思广益。 FFA大会从社区发展业界影响力以及生态技术演进这三方面总结了Flink在过去一年的发展。社区方面根据Apache软件基金会2021财年报告公布的各项核心指标Flink已连续三年位列Apache社区最活跃的项目之一。而作为社区的最小原子Flink的社区代码开发者Contributor已超过1400名年增长率超过20%。其中尤其值得一提的是Flink中文社区的蓬勃发展Flink的官方公众号订阅数超过5万人全年推送超过140篇和Flink技术生态以及行业实践相关的最新资讯。最近Flink社区开通了Flink官方视频号希望通过更加丰富新颖的形式从更多纬度让大家对Flink有更全面的了解。此外Flink社区重构和改版了去年开通的Flink官方学习网站Flink Learning[1]希望通过这个学习网站汇总沉淀和Flink相关的学习资料场景案例以及活动信息使Flink Learning真正成为大家学习研究探索Flink的好帮手。 业界影响力方面Flink已成为业界实时计算的事实标准。越来越多的公司不仅使用Flink也积极参与Flink的发展与建设共同完善Flink。目前Flink的代码开发者来自全球超过100公司。去年举办的4场的线下meet up阿里巴巴、字节跳动携程和360都提供了大力支持。而今年FFA大会有来自互联网金融能源制造业电信等各个行业的40知名公司共83个主题演讲。从生态技术演进来看Flink在云原生高可用性流批一体和AI四个主打方向上都取得了不错的成绩。特别值得一提的是Flink新推出了流批一体的进阶版流式数仓Streaming Warehouse这个概念实现流批实时分析一体化真正意义上完成流批一体计算和流批一体存储的融合让整个数仓的数据流动起来。流式数仓将是Flink未来最重要的方向之一在Flink社区也会同步推广。
本文将对FFA Keynote议题作一些简单的归纳总结感兴趣的小伙伴们可以在FFA官网[2]找到相关主题视频观看直播回放。
一 主会场议题 在主议题之前阿里巴巴集团副总裁阿里巴巴开源技术委员会负责人阿里云智能计算平台负责人贾扬清老师作为开场嘉宾分享了他对开源在云计算的大背景下的思考开源无论是从技术贡献还是生态发展来看已从最初的替代和补充逐步发展成为创新和引领的角色。阿里巴巴到目前为止已经开源了2700多个项目是国内互联网技术企业中的先锋。而Flink作为阿里巴巴最具影响力的开源项目之一无论是在技术先进性还是生态丰富性上都无可争议。不仅如此阿里巴巴在过去几年中积极拓展Flink的适用场景通过自身大规模业务打磨迭代开源技术进而将这些技术回馈Flink社区并携手其他开源项目形成更全面的联合解决方案真正做到了开源开放持续回馈加速普及。
下面来重点聊一聊几个主议题。
1 Flink Next –– Beyond Stream Processing
主议题照例由Apache Flink中文社区发起人阿里巴巴开源大数据平台负责人王峰花名莫问老师开启主要介绍 Flink 社区在 2021 年取得的成果以及未来的发展方向包括云原生Flink容错流批一体和机器学习四个部分。
云原生 –– 部署架构演进 Flink部署的三种模式
说起开源大数据的发展绕不开云原生两者相依相生相辅相成。作为开源大数据的引擎课代表Flink的部署模式是如何在云原生大背景下演进的是个很有趣的话题。Flink最早的部署模式是经典的静态StaticStandalone模式这里的静态是指用户必须根据业务估算预留资源资源少了作业就跑不起来所以大部分情况下需要按最大资源量来预留。显而易见这种模式对于用户来说既复杂资源利用率也不高。第二种模式我们称为主动Active模式这里的主动是指Flink会根据业务资源的使用情况主动的去向底层Kubernetes或者Yarn申请和释放资源。这种模式需要Flink和底层Kubernetes或者Yarn深度集成适用于需要对资源深度把控的用户对中小用户来讲太过复杂。这就引出了第三种模式我们称为适应性Adaptive/Reactive模式。在这种模式下Flink可以像云上其他应用一样根据所给的资源增加或减少资源pod通过改变自身拓扑结构来动态调整运行。从用户的角度来看他并不需要了解资源是如何分配的所以第三种模式对于用户的门槛相对较低。
还有一个值得思考的问题是云原生到底给Flink带来了什么除了弹性资源管理数据多备份自适应运维管理标准化的工具和操作笔者觉得更重要的是降低用户的使用门槛用更小的成本给用户提供更简单稳定和丰富的使用体验。
Flink容错 –– 稳定快速的Checkpoint 和Checkpointing相关的讨论几乎贯穿了Flink的整个发展历程它是整个Flink容错架构的核心。Flink会定期给所有的算子状态做快照检查点Checkpoint如果Flink作业失败作业会从上一个完整的Checkpoint恢复。在实际工作中我们发现引擎这一层很大部分的Oncall的问题都跟做Checkpoint相关所以如何能够高频稳定的完成Checkpoint是提升Flink高可用性容错的重点。造成做Checkpoint失败超时的主要原因来自两方面一是中间数据流动缓慢造成Checkpoint Barrier流动缓慢二是算子状态过大造成状态数据上传超时。Flink针对这两个方面都有重点项目在跟进Buffer Debloating和Generalized Log-Based Checkpoint。
Buffer Debloating是在不影响吞吐和延迟的前提下缩减上下游需要缓存的数据到刚好算子不空转目前Buffer Debloating默认上游会动态缓存下游1秒钟能处理的数据这个时间是可以配置的。Buffer Debloating在Flink-1.14版本已经发布。Generalized Log-Based Checkpoint是一种基于log打点的方式来做Checkpoint的方法类似传统DB的write ahead log好处是能快速高频且稳定的做Checkpoint代价是需要额外多写/存一份log。我们知道Flink做Checkpoint由同步和异步两个过程组成同步的过程通常很快主要的耗时在异步上传状态文件这个过程中。Generalized Log-Based Checkpoint的原理就是将Checkpointing这个过程和耗时的异步上传文件这个过程剥离开也同时和底层状态存储的物化过程解耦。Generalized Log-Based Checkpoint预计会在Flink-1.15版本发布。
分论坛核心技术专场talk“Flink新一代流计算和容错Flink Fault Tolerance 2.0”对这个部分有更为详细的阐述感兴趣的同学可以找来看看。
流批一体 –– 架构演进和落地
流批一体是近些年Flink一直在力推的创新性理念从最早提出这个理念到当前被广泛接受莫问老师分享了流批一体在Flink的系统架构各个层面演进的过程及其落地场景如下图所示。 1架构演进
API层面去年流批统一的SQL/Table APIDeclarative API首次在阿里巴巴双十一最核心的天猫营销活动分析大屏场景中落地[3]今年更近一步完成了Imperative API的整合形成流批统一的DataStream API而陈旧的DataSet API将逐步被淘汰。架构层面同一个作业可以同时处理有限数据集和无限数据集并且connector框架可以同时对接流式存储和批式存储做到一套代码可以处理两套数据源。运行层面一套调度框架可以同时适用于流和批的作业流批shuffle是pluggable的复用一套shuffle接口。阿里巴巴实时计算团队在今年开源了存算分离的Remote Shuffle Service[4]放在Flink开源项目的Flink-extended这个子项目组里面。Flink-extended[5]里面包含很多其他Flink生态项目有兴趣的同学可以去看一看。
继去年在天猫双十一核心大屏业务上线后流批一体今年逐步在阿里巴巴更多核心业务上推广。除了阿里巴巴有越来越多的公司认可流批一体这个理念。今年FFA有个专门的流批一体分论坛由字节跳动美团京东以及小米等公司分享流批一体在其业务中的实践。此外在核心技术专场中有专门针对流批一体架构演进的专场talk“面向流批一体的 Flink Runtime 新进展”对这个话题感兴趣的同学可以了解一下。对新版connector框架原理感兴趣的同学可以参考核心技术专场中的“Flink Connector社区新动向与Hybrid Source原理实践”。
2场景落地
莫问老师指出流批一体这一技术理念落地需要具体的场景支撑来体现其真正价值基于此他分享了流批一体最为典型的两个应用场景。
场景1 Flink CDC全增量一体化数据集成 在传统的数据集成中离线和实时数据集成是两套不同的技术栈需要全量和增量定时合并时效性也比较差。Flink的流批一体能力结合Flink CDC的能力可以实现一体化数据集成先全量的同步完历史数据后自动接到断点实时的续传增量数据实现一站式数据同步读取数据库全量数据后自动切换通过binlog增量同步。这里的自动切换的实现基于新版流批一体Source框架。
Flink CDC目前已可以支持大部分主流数据库包括MySQL、Postgres、Oracle、MongoDB、MariaDB其他的如TiDBDB2SQL Server也在积极开发中。对Flink CDC如何能够实现一站式数据集成感兴趣的同学可以参考分论坛实时数据湖专场中的talk“Flink CDC 如何简化实时数据入湖入仓”。
场景2 Streaming Warehouse流式数仓
前面提到今年的一大亮点是莫问老师提出的流式数仓Streaming Warehouse这个概念这个概念提出的大背景是为了解决实时离线数仓一体化的问题。
实时离线数仓一体化这个问题目前比较常用的解决方案是用实时和离线两条链路来实现1实时流处理链路Flink Kafka对数据进行分层ODSDWDDWS并实时写入在线服务层提供在线服务实时OLAP2同时会有一条离线链路定期对实时数据进行补充和历史修正。这里除了常见的流批不统一带来的开发效率维护成本流批口径不统一等问题以外其实还有一个更隐蔽同时也更难解决的问题为了保证实时性实时链路中的ODSDWDDWS这些分层数据是存在消息队列比如Kafka中的但是消息队列中的数据是没办法有效进行实时分析的如果引入其他的OLAP系统会增加系统复杂度同时也不能保证数据一致性。 为了解决消息队列无法有效率的进行实时分析的问题Flink引入了Dynamic Table动态表来存放实时链路产生的分层数据如上图所示。这样一来Flink可以通过Flink SQL的流批一体能力实时的串联起整个分层数仓通过Flink SQL对Dynamic Table的OLAP查询提供实时分析的能力。我们可以把这个理解成流批一体的进阶版本流批实时分析一体化也就是莫问老师这里提出的流式数仓StreamHouse Streaming Warehouse这个概念真正做到在一套方法论的大框架下实现一套API一套计算一套中间存储的全链路一体化。
Dynamic Table动态表不同于一般意义上的Source和Sink是Flink的内置表。之所以称为动态表是因为此表具有流表二象性。流表二象性通过列存LSM Tree和Log两种不同的存储形式来支持分别对应于Flink SQL的批全量分析和流增量处理两种模式。Dynamic Table通过Flink自身的Checkpointing一致性语义机制保证流表二象性在两种存储形式下的一致性语义。这里需要特别注意的是流表二象存储的数据一致性问题是混拼系统引入其他OLAP和消息队列无法轻易规避和解决的问题因为中间涉及多系统间的一致性读写同步这也是Flink Dynamic Table区别于其他类似系统的核心竞争力之一。如果大家对动态表的实现感兴趣的话可以看一看流批一体分论坛中“基于Flink Dynamic Table构建流批一体数仓”这个talk里面有对Dynamic Table更详细的介绍。
这个部分的最后有一个流式数仓的demo用上述一体化的方法论展示了流作业在实时OLAP分析发现业务逻辑有错后如何批式做订正并实时支持OLAP查询更正的一个流批实时分析一体化的典型场景还是很受启发的大家可以看一看。想对流式数仓有更详细了解的同学可以参考莫问老师关于流式数仓的专访[6]。
机器学习 –– Apache Flink ML 2.0 全新架构 机器学习作为Apache Flink的另一大重要场景在今年Flink流批一体API和架构进一步完善的基础上基于流批一体DataStream API完成重构全面升级到Flink ML 2.0。Flink ML最大的特点是实时离线一体化以及与之相配套的实时离线一体化管理调度Flink AI Flow和执行。在Flink ML 2.0中有几个新的亮点是值得看一看的1Flink基于DataStream在引擎部分原生的支持全新的迭代计算框架支持更灵活的分布式同步和异步迭代2发布了一套新版Flink ML pipeline API遵循机器学习用户更熟悉Scikit-Learn风格TransformerEstimatorModel3支持一体化的深度学习集成Flink ML Estimator可以将Pytorch和Tensorflow拉起4流批一体能力使得Flink ML 2.0可以同时对接流和批的数据集。
Flink ML 2.0目前已经由阿里巴巴实时计算团队和机器学习团队共同完成贡献给Flink社区成为Flink的一个子项目Flink-ML[7]。值得一提的是除了阿里巴巴现在还有很多其他公司也在共同建设Flink ML的生态比如360贡献了Clink[8]。核心技术专场中“为实时机器学习设计的算法接口与迭代引擎”这个talk详细介绍了Flink ML 2.0的架构演进此外今年FFA还有一个机器学习专场感兴趣的同学可以看一看。
PyFlink方面Flink对AI的主流开发语言Python的支持更加完备PyFlink在功能上完全追平了Table API 和Data Stream API的能力在性能上创新性的通过JNI调用C再在C里面调用Python解析器的方法消除了Python UDF和Java跨进程通信使得Python UDF性能接近Java UDF兼顾开发和运行的效率。分论坛核心技术专场“基于 FFI 的 PyFlink 下一代 Python 运行时介绍”有对这部分更详细的解释。
二 实时计算在字节跳动的发展与展望
主议题第二场由字节跳动计算基础架构负责人师锐老师带来。字节跳动的产品业务场景主要都是以实时信息流推荐为主因此以Flink为支撑的实时计算广泛应用在字节跳动的各个产品中。字节跳动旗下全线产品总MAU目前已超过19亿由于其业务特性其数据量EB级别1EB 2^60 Bytes和实时推荐的请求量百万QPS都是巨大的。我们可以看到在师锐老师分享的字节跳动引擎资源使用的对比图中Flink和Spark基本持平这在一般的公司是不太常见的从这个方面也可以看出字节跳动整个业务线对以Flink为基础的流计算的依赖。 字节跳动主要计算引擎资源对比图
字节跳动从2017年开始调研并逐步使用Flink流式计算到2019年初所有流式作业已完成从JStorm到Flink的迁移。2019年开始随着Flink SQL和Flink批式计算的成熟Flink Batch也在字节跳动数据同步等场景相继落地现在每天大约有10w Flink Batch作业运行。师锐老师特别提到从去年开始流批一体也逐步在字节跳动公司内部推广应用感兴趣的小伙伴可以参考流批一体分论坛专场中的talk“流批一体在字节跳动特征平台的实践”。目前字节跳动全球Flink流式作业达到4w个其中SQL作业占30%使用的CPU核数超过400万核晚高峰Flink作业处理消息的QPS达到90亿Checkpoint高峰流量吞吐达到600GB/s还是很惊人的 Flink在字节跳动发展图
在字节跳动的分享中基于存算分离架构的流批一体消息队列BMQ值得提一提BMQ目前承接了字节90%的消息队列流量。在BMQ之前字节使用Kafka作为消息队列集群升级扩缩容需要大量拷贝数据所以完成一个集群的升级差不多需要一周的时间。为了解决这个问题字节团队基于存算分离的架构重新设计实现了消息队列BMQ。在BMQ的架构之下数据存放在分布式文件系统HDFS中Meta存放在K-V存储中。由于BMQ的计算层Proxy无状态所以非常容易做扩缩容迁移时间可在分钟级完成。另一方面BMQ可以同时提供Stream API和Batch API所以可以同时支持流和批的消费实现存储层的流批一体。有些小伙伴可能有疑问这和上面提到的动态表Dynamic Table一样吗笔者觉得还是很不一样的因为要解决的问题不一样动态表要解决流批实时分析一体化的问题所以它的流批存储格式是完全不一样的为了分别加速流处理和批查询而BMQ所有数据只写一份在HDFS上主要还是为支持高效的大规模消息传输和读写服务的。
师锐老师提到他们下一步计划是推进Flink OLAP的落地。他指出Flink拥有丰富的connector生态可以实现跨数据源查询Flink OLAP能力在字节内部测试过可以媲美Presto甚至在有些情况下更优现在有关Flink OLAP的改进和优化也在积极推进Flink社区中。本次FFA字节跳动有7个分会场talk从核心技术提升到行业实践涵盖了方方面面对Flink在字节跳动内部如何演进使用感兴趣的同学可以去看看。
三 工商银行实时大数据平台建设历程及展望
主议题第三场由中国工商银行大数据平台负责人袁一老师带来他从金融行业的视角分享了有关工行实时大数据平台建设的历程和思路。 首先我们来看一张描述工行数据流向的示意图如上图所示。应用产生的数据会写入到MySQL或Oracle等关系型数据库之后将数据库产生的日志复制到Kafka消息队列中作为实时处理平台的数据源。实时处理平台有三个数据出口一是通过Flink实时ETL可以实现实时数据入湖二是将Flink的结果输出到HBase或者ES等联机数据库中提供面向应用的数据中台服务三是通过Presto或CK等分析型引擎提供面向分析师的BI分析能力。工行内部的高时效业务场景基本上都可以包含在这条链路体系之中。
聪明的小伙伴们可能已经发现了上面这条复杂数据链路和Flink流式数仓Streaming Warehouse场景几乎一摸一样。但是通过Flink的流式数仓我们可以把工行的这条中间贯穿很多系统和组件的链路简化成Flink单链路通过Flink的动态表Dynamic Table提供的流批实时分析一体化的能力来完成实时入湖实时数据服务和实时分析
另一个比较有趣的点是金融行业的数据中台在设计的时候会特别考虑数据私密和安全的问题。他们采用的方法有以下几种1采用全生命周期的数据监控审计用于数据访问的审计和追溯2在数据发生移动的时候给数据本身加水印可以方便溯源3通过SQL实现自然人级别的动态数据访问权限控制4通过专家规则和Machine Learning来自动识别海量数据中的敏感数据。这些思想和方法在数据安全数据私密越来越受重视的今天很有借鉴意义。袁一老师还详细分享了很多和金融行业相关的业务场景相信会对业务场景感兴趣的同学有所启发。
四 Deconstructing Stream Storage
主议题的最后一场由Pravega中国社区创始人戴尔科技集团OSA软件开发总监滕昱老师压轴解构流存储。
Pravega是提供流批统一能力的开源分布式流存储有如下特点1相同键值下可以保证数据有序2可以根据数据流量动态扩缩存储单元3支持事务性写入4支持Checkpointing和一致性读写5分层存储设计。所有的这些特性都封装在Stream抽象的设计理念之下也给流式计算屏蔽了很多流存储端的复杂性。在这次分享中滕昱老师着重介绍了Pravega的分层存储架构Tiered Storage其底层是一个基于分布式文件/对象存储的持久性主存储中间是基于内存的全局Cache层最上层是分布式Log抽象层。滕昱老师还同时分享了Pravega的分层存储架构与Kafka和Pulsar这两个消息系统在架构上的区别以及对性能的影响感兴趣的同学可以去详细了解一下。 在Pravega的分享中有几个比较有趣的点
一是Pravega针对现在比较火热的物联网边缘计算的定制优化。比如Pravega针对多客户端的两阶段数据聚合在Writer进行第一阶段聚合在Segment Store进行第二阶段聚合极大的提高了吞吐量。这种数据聚合优化非常适用于有大量客户端但每个客户端产生的数据量比较小的情况而这就是物联网的典型特点。
二是Pravega和Flink联动的端到端的auto-scaling。弹性扩缩容是云原生大背景下非常重要的问题前面提到Pravega的一大特点就是可以自动扩缩容调整Segment数目而这个数目可以很好的作为Flink Reactive Scaling的指标两者相结合后可以做到从计算到存储端到端的auto-scaling目前这项工作已在两边社区合作规划中。滕昱老师的分享中还有一个Demo展示了Pravega和Flink联动scaling的效果。
滕昱老师表示未来存储和计算流和表的界限逐渐模糊Pravega流批一体的存储设计也暗合了Flink未来很重要的一个发展方向。Pravega社区会积极与包括Flink在内的数据湖仓相关的开源社区通力合作构建解决方案。今年Pravega和Flink社区共同发布了白皮书未来也期望和Flink社区有更多合作将Flink计算推向数据的产生端通过Pravega能实现数据从端到云的流动。
五 圆桌会议
今年FFA主会场新增加了一个环节圆桌会议分北京和上海两场邀请了业界来自阿里巴巴字节跳动美团快手小米工商银行戴尔科技集团和小红书在内的多位大数据专家负责人共同探讨Flink以及实时计算的未来。各位大佬友好真诚并且很接地气讨论了很多大家都比较关心的问题由于篇幅关系这里仅列出了讨论的部分相关话题大家可以找视频感受一下
如何看待Flink在实时计算方面已趋于成熟这个话题目前大家都用实时计算做什么实时计算的未来是怎样的技术和业务层面基于此Flink需要探索哪些新的领域解决哪些关键问题有人认为实时计算的门槛和代价比较高相对偏小众也有很多人认为实时计算是未来的方向大数据和 AI 都会向实时化方向演进大家怎么看这个问题Flink在整个开源大数据生态中应该如何定位如何保持差异化如何看待公司内部技术实践技术创新与开源社区之间的关系大家使用和回馈社区的策略又是什么使用和贡献开源项目有哪些优势公司内部在做Flink哪方面的探索过程中又遇到过哪些挑战Flink在内部使用的未来规划以及接下来有哪些打算贡献社区的创新技术如何看待 Flink 与生态项目之间的合作、竞争关系什么样的开源社区是对大家有帮助的开源社区同时又是一个可持续发展的社区
六 总结和感想
过去的2021年是大数据领域的风口年对于Apache Flink实时计算的领跑者能否抓住这个风口也是很关键的一年。在Flink SQL趋于成熟流批一体在业内逐步被接受落地的当口我们需要思考未来Flink何去何从这也是我们正在做的事情。在此基础上Flink推出了流批一体的进阶版流式数仓Streaming Warehouse这个概念希望能实现流批实时分析一体化真正意义上完成流批一体计算和流批一体存储的融合做到在一套方法论的大框架下实现一套API一套计算一套中间存储的全链路一体化。流式数仓将是Flink未来最重要的方向道阻且长行则将至行而不辍未来可期
[1] Flink官方学习网站Flink LearningFlink 中文社区 | 中文学习教程
[2] Flink Forward 峰会 - Flink Forward Asia 2021
[3]40亿条/秒Flink流批一体在阿里双11首次落地的背后
[4]Remote Shuffle Servicehttps://github.com/flink-extended/flink-remote-shuffle
[5]Flink-extendedflink-extended · GitHub
[6] Apache Flink不止于计算数仓架构或兴起新一轮变革https://c.tb.cn/F3.0OfNLU
[7]Flink-MLhttps://github.com/apache/flink-ml
[8]Clinkhttps://github.com/flink-extended/clink
原文链接
本文为阿里云原创内容未经允许不得转载。
