从图中可以看出，他们早在 2016 年 Flink 崭露头角的时候就已经将 Flink 加入到了他们的 EMR 当中。相比 Cloudera 的后知后觉，AWS 在这方面果然就老江湖了许多。令人印象深刻的是，AWS 这几年围绕流计算产品的发展，一直有一个清晰的主线，那就是针对不同体量的客户推出更加适合他们的产品和解决方案。他们很好的总结了不同体量的客户对产品的需求的不同（相信这不仅仅只是针对流计算，针对其他的产品也是异曲同工）：
比如他们发现了大量的客户有时候使用流计算框架只是简单的解决一个数据转存的问题，比如简单的把数据从 Kinesis Data Stream（这个其实是他们的一个消息队列服务，光看名字容易有点误导）转存到 S3 上，或者把数据发到 Redshift 或者 Elasticsearch。针对这种场景，他们就开发了专门的 Kinesis Data Firehose 产品，让用户不需要写代码就能够完成这样的工作。另外，一些具备一些开发能力的客户，会写一些代码或者 SQL 来对数据进行处理和分析。针对这种场景，他们提供了 Kinesis Data Analytics 服务。
另外让人印象深刻的一点是，AWS 的各个产品之间的协同做的非常好（我在后来还参加了一个 AWS Kinesis 产品的演示分享，其中涉及到不少产品之间的协调和打通，让人印象深刻）。每个产品专注解决一部分的问题，产品和产品之间在功能上不能说完全没有重叠的地方，但基本上还是非常克制。演讲中分享的每个真实的用户场景，基本都涉及了 3-5 个以上的产品互相的协同。对客户需求的精准把握，以及产品的协同站位精确解决用户问题，这两点非常值得我们去学习。
扯的有点远了，回到 Flink 上来。Rahul 最后总结了一下 Flink 是他们目前看到的会去消息队列里消费数据的产品中增长最快的系统，但从绝对体量上来看还是偏小。这也基本符合 Flink 目前的一个状态，热度高，增长也很快，但是绝对体量还偏小，不过这也预示着想象的空间还比较大。
Google 在 AWS 之后出场，由 Reven 和 Sergei 带来（前者也是《Streaming Systems》一书的作者之一，终于见到真人了）。这个 Talk 整体上来讲和 Flink 没有太大的关系，分享的是 Google 这些年在流计算相关系统的研发过程中得到的经验。和 AWS 相比，两家公司的特色也是相当鲜明。AWS 分享的都是对客户需求和产品的总结，而 Google 说的基本上都是纯技术上的经验收获。听了之后也确实收获良多，不过由于篇幅问题就不在这具体展开了。人家也已经准备好一段总结让我们可以打包带走：
主议程
由于分身乏术，在主议程中我只挑选了一些个人比较感兴趣或者是不怎么了解的领域进行观摩和学习。但为了整篇报告的完整性，我还是尽量的简单介绍一下其他我没有参与但是还算熟悉的议题。后续主办方也会将所有的视频和 PPT 上传到网上供大家进行查看。接下来我就把议题按照个人理解分成几个不同的类别，分别抛砖引玉一下。大家如果对其中的某些议题的细节特别感兴趣的，可以再去仔细查看视频和 PPT。
平台化实践
基于 Flink 构建数据平台可以算得上最热门的一个议题方向了。这几年阿里巴巴实时计算团队一直不遗余力的向社区推广基于 SQL 构建数据处理平台的经验，目前看起来大家也基本上认同了这个方向，也纷纷的开始上了生产。不过根据具体的场景，作业量的规模等特点，也有一些公司会选择使用更加底层和更加灵活的 DataStream API 来构建数据平台，或者两者都提供。这也符合我们一开始的判断，SQL 能解决大多数问题，但不是全部。在一些灵活的场景下，DataStream 能更方便和高效的解决用户的问题。
-
议题1：《Writing a interactive SQL engine and interface for executing SQL against running streams using Flink》
这个分享来自美国的一家名叫 eventador 的创业公司，也是本次大会的赞助商之一。整个分享大部分还是他们产品架构和功能的介绍，基本上和我们以及其他公司的平台架构类似。比较有意思的是，他们也发现了在平台化的实践过程中，用户是同时需要 SQL 这种高阶 API 以及更加灵活和偏底层点的 DataStream API，并且这两者的比例是 8：2 开。
还有一个比较有意思的功能是，他们在 SQL 上提供了 JavaScript 的 UDF 支持，并且在他们的用户之间非常受欢迎。在 SQL 上，持续的降低使用门槛确实是一个比较靠谱的路子，和我们想提供 Python UDF 支持也是基于同样的出发点。
- 议题2：《Building a Self-Service Streaming Platform at Pinterest》
Pinterest 算是 Flink 社区的新面孔，这次是他们第一次在 Flink 的大会上分享他们的经验。他们主要的应用场景主要是围绕广告来展开，使用 Flink 来给广告主们实时反馈广告的效果。这也算的上是 Flink 相当经典的一个使用场景了。至于为什么这么晚才用 Flink，他们上来就进行了说明。他们花了比较大的功夫去对比 Spark Streaming，Flink 以及 Kafka Stream 这 3 个引擎，权衡再三之后才选择了 Flink，也算是比较谨慎和心细了。同时他们的老的业务基本上都是使用 Spark 跑批处理作业，在切换成流之后，也是需要拿出点实实在在的成绩才有可能在公司内大规模推广。
接着，他们也分享了两个在平台化实践过程中填的坑。
-
第一个是日志的查看，尤其是当所有的作业跑在 YARN 上的时候，当作业结束后怎么查看作业运行时的日志是一个比较头疼的问题。
-
第二个是 Backfilling，在新的作业上线或者作业逻辑需要变更的时候，他们希望先追一部分存在 S3 上的历史数据，然后在基本追完的时候切换到 Kafka 这样的消息队列上继续进行处理。
这个 Backfilling 是 Flink 流批一体最经典的场景，而且看起来确实是个很普遍的刚需。如果没记错的话，这次大会就有 3 个议题提到了这方面的问题，以及他们的解法。解法各有千秋，不过如果 Flink 在引擎上能够直接内置支持了这样的场景的话，相信体验会好不少（这也恰恰是 Flink 接下去一个比较重要的方向之一）。
- 其他议题推荐
1.《Stream SQL with Flink @ Yelp》：Yelp 已经算是 Flink 的老牌玩家了，在这个分享里他们总结了他们目前的流计算场景，以及他们的平台的做法。我因为时间冲突的原因没有听到这个分享，不过从其他渠道得到的反馈看起来他们应该是属于玩的比较溜的。推荐大家在视频和 PPT 上线后观摩学习一下。
2.《Flink for Everyone: Self-Service Data Analytics with StreamPipes》：一般来说，平台化建设都是公司内部项目，很少进行开源。这个叫做 FZI 的非盈利机构跳出来当了一把雷锋，提供了一套完全开源的平台化工程实现：streampipes。自带一整套托拉拽的作业构建流程，而且看起来界面也相当的不错，有需要的同学可以参考一下。
3.《Dynamically Generated Flink Jobs at Scale》：这是高盛分享的基于 Flink 的平台实践，支持一天运行 12 万的作业。在银行和金融业的 IT 同学们可以参考下。
篇幅有限，还有其他相关的议题就不一一列出了。总体来说，基于 Flink 构建数据平台已经是一个相当成熟的实践，各行各业都有成功的案例进行参考。还没有上车的同学们，你们还在等什么？
应用场景类
除了上面的平台化实践，使用 Flink 解决某些应用场景的具体问题也是这次分享中一个比较热门的方向。这些用户往往自己编写少量作业，来解决他们的实际问题。或者就干脆是平台的使用方，来分享如何使用平台来解决更贴近终端用户的问题。这也是 Flink 能够真正创造实际业务价值的地方，本想多听几个，可无奈老是时间冲突。
这是 Uber 分享的一个脑洞比较大的应用场景，他们使用 Flink 来实时判断乘客是不是发生了车祸。和 Pinterest 一样，在这个业务场景下，Uber 也是为了时效性而从 Spark 迁移到了 Flink。他们介绍了他们如何依赖两项最重要的数据（GPS 信息和手机加速信息），再套用机器学习模型，来实时的判断乘客是否发生了车祸。
后续也提到了他们希望共享这个业务上收集的数据，以及在这个数据的基础上生成的一些特征，在其他的团队进行推广（怎么感觉方向又要转到平台化了-_-!）
- 其他议题推荐
1.《Airbus makes more of the sky with Flink》：空客公司介绍了他们如何使用 Azure、Flink 来进行飞行数据的分析，旨在提供更好的飞行体验。
2.《Intelligent Log Analysis and Real-time Anomaly Detection @ Salesforce》：Salesforce 介绍了他们使用 Flink 结合机器学习模型来解决实时日志分析，并且实时探测一些异常情况比如关键服务性能下降等。
3.《Large Scale Real Time Ad Invalid Traffic Detection with Flink》：Criteo 这家法国的广告公司介绍了广告场景下进行实时的异常流量探测。
4.《Enabling Machine Learning with Apache Flink》：Lyft 分享了他们如何基于 Flink 构建了机器学习的平台来解决多种多样的业务问题。
简单总结一下，在偏应用场景的方向上，已经越来越多的看到了 Flink 和机器学习结合使用的案例。基本上，一些稍微复杂点的问题很难通过规则逻辑，或者 SQL 来进行简单的判定。这种情况下，机器学习就能够派上比较大的用场。目前看来，大家还是更多的先使用其他引擎训练好模型，然后让 Flink 加载模型之后进行预测操作。但是过程中也会碰到类似两个引擎对样本的处理逻辑不同等问题而影响最终的效果。
这也算是 Flink 今后的一个机会，如果 Flink 在更加偏向批处理的模型训练上能提供比较好的支持，那么用户完全可以使用同一个引擎来进行诸如用本拼接，模型训练以及实时预测这一整套流程。整个的开发体验包括实际上线效果相信都会有较大的提升，让我们拭目以待 Flink 在这方面的动作。
生产实践
这部分主要是生产实践的经验分享，很不好意思的是，相关的议题我一个都没有参与。我根据议题的简介简单做个介绍，感兴趣的同学可以自行查看相关资料。
-
《Apache Flink Worst Practices》：大家可能都听过不少 Best Practices，这个分享反其道而行之，专门介绍各种使用 Flink 的最差姿势，基本上算是分享各种踩坑或者踩雷的地方，让听众能够避开。
-
《How to configure your streaming jobs like a pro》：Cloudera 基于这些年他们在数百个流计算作业上总结下来的调参经验。针对不同类型的作业，哪些参数比较关键。
-
《Running Flink in production: The good, the bad and the in-between》：Lyft 分享的他们运维 Flink 的经验，有哪些 Flink 做的比较好的地方，也包括哪些 Flink 现在做的不够好的地方。让大家对运维 Flink 生产作业有更全面的认知。
-
《Introspection of the Flink in production》：Criteo 分享的教大家如何观测 Flink 作业是否正常的经验，以及当作业出问题时，如何最快的定位 root cause。
-
《Kubernetes + Operator + PaaSTA = Flink @ Yelp》：当大部分人还是基于 Yarn 来运行 Flink的时候，Yelp 这个深度玩家已然走到了大家前面。这也是我在这次大会中看到的唯一使用 Flink + K8S 上线的组合。
虽然一个议题也没听，但是也从别的议题中零零星星的听到一些大家关于 Flink 生产的话题，其中比较突出的是 Flink 和 Kubernetes 的结合问题。K8S 的火热，让大家都有种不蹭一下热度就落伍了的想法。不少公司都有朝着这个方向进行尝试和探索的意愿。其中就属 Yelp 走的最快，已经拿这套架构上线了。
个人觉得 Flink 和 K8S 的结合还是相当靠谱的，可以解锁更多 Application 和在线服务相关的姿势。当然，阿里巴巴实时计算团队在这方面也没有落伍，我们也已经和阿里云 K8S 合作了相当长一段时间，最近也推出了基于 K8S 容器化的全新一代实时计算产品 Ververica Platform。
研究型项目
前面的议题基本都是一些工程化的实践，这次大会还有不少研究型的项目吸引了我的兴趣。生态的繁荣发展，除了有各大公司的实践之外，偏理论化的研究型项目也不可缺少。听说这次大会收到了不少研究型的议题，但由于议题数量有限，只从里面挑选了一部分。
这是苏黎世联邦理工学院的一名博士后带来的自动配置流计算作业的一个研究型项目。他们的研究方向主要集中在如何让流计算作业能够自治，不需要人为干预而能够自动的调整到最佳的状态。这和 Google 在 keynote 里的分享不谋而合，都是希望系统本身具备足够强的动态调整能力。
这个分享主要有两部分内容，第一部分是提出了一种新的性能瓶颈分析理论。一般来说，当我们想要优化一个流计算作业的吞吐和延迟时，我们往往采用比较传统的观测 CPU 热点的方式，找到作业中最耗 CPU 的部分然后进行优化。但往往我们忽略了一个事实是，影响系统 latency 或者吞吐往往还有各种等待的操作，比如算子在等待数据进行处理等。如果我们单独优化 cpu 热点，优化完之后可能只会让系统其它地方等待的时间变长，并不能真正带来延迟的下降和吞吐的上升。所以他们先提出了一种”关键路径“的理论，在判断性能瓶颈时是以链路为单元进行判断和测量。只有真正的降低整条关键路径的耗时，才能有有效的降低作业的延迟。
第二个部分是介绍了一种新的作业自动扩缩容机制，并且和微软的 Dhalion 进行了对比。这个做法的特色在于，其他类似的系统总是对一个算子单独做决策，而他们会更多的把多个算子进行同时考虑。在扩缩容的时候让多个算子同时操作，减少收敛所需要的动作次数。
流计算任务的自治化也是我个人非常感兴趣的一个方向，也看到不少研究型的项目和论文在阐述这方面的工作，但暂时还未见到工业界对比有比较深入的分享（AWS 的 kinesis 服务具备动态扩缩容能力，但由于缺乏细节介绍不确定是否足够通用以及是否能够应对比较复杂的场景）。
阿里巴巴实时计算团队早在一年前就启动了类似的项目，在这方向上进行了尝试和探索。面对内部大量的业务场景和需求，加上目前各种前沿的研究，相信不远的将来可以有所突破。
1.《Moving on from RocksDB to something FASTER》：这也是苏黎世联邦理工带来的关于状态存储相关的研究，寻找比 RocksDB 更快的解决方案。在 Statebackend 上，阿里巴巴实时计算团队也有所布局，我们正在探索一种完全基于 Java 的存储引擎。
2.《Scotty: Efficient Window Aggregation with General Stream Slicing》：介绍了一种使用切片来提升窗口聚合性能的方法。
深度技术剖析
这个部分主要介绍的都是 Flink 在过去 1-2 个版本内做的一些大的 feature 和重构。由于本人就是 Flink 的开发者，对这些工作都比较熟悉，因此就没有选择去听这些分享。借用 Stephan 在 Keynote 中的两张图，基本做了比较好的概括。
有同学对其中个别的技术点感兴趣的话，基本都能够找到对应的议题，在这里我就不展开一一介绍了。
总结和感想
这几年随着阿里巴巴持续对 Flink 的大力投资，Flink 的成熟度和活跃度均有了质的飞跃。社区生态也越发的繁荣，包括 cloudera 和 AWS 都已经开始积极的拥抱 Flink，也得到了不错的成果。各大公司的议题也从早年的抱着尝鲜的态度尝试 Flink，转变成了来分享使用 Flink 大规模上线后的一些成果和经验教训。在此基础之上，逐渐了形成了基于 Flink 的平台化实践、结合机器学习进行具体业务的问题解决和一些比较新颖的探索研究型项目等方向，让整个生态的发展更加的完整和壮实。不仅如此，Flink 也在积极的探索一些新的热门方向，比如和 K8S 的结合，和在线服务场景的结合等等，体现了这个生态的强大生命力。
不过归根结底，Flink 到底还是一个大数据计算引擎，其宗旨还是希望去解决大数据计算这个问题。在文章的一开头，我也提到了在看到 Flink 进军 Application 和 FaaS 的方向时，一个疑问一直在我的心头萦绕：Flink 到底是怎么样的一个计算引擎，它究竟是要解决什么样的问题？如果没有一个很清晰的主线和长远认识，在引擎的发展过程中很容易就会走偏，最终导致失败。
大部分人可能还停留在 Flink 是一个成熟的实时计算引擎的认知，但 Flink 从诞生的第一天起就想着要解决批处理的问题。即便现在 Flink 已经逐渐填补了批处理这个坑，但又朝着 Application 这样的在线服务场景发起了探索。乍一看，Flink 好像什么问题都想解，什么方向都想插一脚，真的是这样吗？
带着这样的疑问参加完了整个大会，又额外思考了几天，我开始有了一些新的认识和见解。想要回答 Flink 到底是怎么样的一个计算引擎，它究竟想解决什么样的问题这个疑问，我们得从数据本身开始看起。毕竟，一个计算引擎所要处理的对象，就是数据本身。
第一个问题是，我们需要处理的数据都是从哪里来的？对大部分公司和企业来说，数据可能来自各种手机 APP，IoT 设备，在线服务的日志，用户的查询等等。虽然数据的来源和种类各不相同，但有一个特点可能是大部分情况下都具备的：数据总是实时的不断产生。
我们可以使用流（Stream）或者日志（Log）这样的概念来模拟抽象所需要处理的数据，这也是现在一种比较流行的抽象方式，Jay Kreps 大神早年就在不遗余力的推广这样的方式，感兴趣的同学可以读一下这篇博文： 《The Log: What every software engineer should know about real-time data’s unifying abstraction》。
https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
在这里先解答一下常见的几个疑惑，因为这个看起来和大家平时接触到的数据比较不一样。常见的问题会有：
-
我平时的接触的数据都存在 Database 里，看起来这个不一样啊？Database 可以理解成为将这些 Stream 物化后的产物，一般是为了后续的频繁访问可以更快。而且大部分 Database 系统的实现里，其实也是用的 Log 来存储所有的增删改行为。
-
我平时接触的数据都放在数仓里，按照天做了分区。这种情况可以再往数据的源头想一下，数据刚产生的时候不会直接到你的数仓，一般也是需要经过一个 ETL 过程。一般的数仓可以理解成将过去的一段段有限流，转存成了更高效的格式。
当我们使用这样的方式来抽象数据之后，我们就可以考虑我们会在这样的数据上做什么样类型的计算了。先从有限流开始：
-
对过去的一部分数据做一下简单的清洗和处理，这基本上就是大部分经典的批处理 ETL 作业。
-
对过去的一部分数据做一些稍微复杂点的关联和分析，这算是比 ETL 稍微复杂点的批处理作业。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
最后
看完美团、字节、腾讯这三家的面试问题，是不是感觉问的特别多，可能咱们又得开启面试造火箭、工作拧螺丝的模式去准备下一次的面试了。
开篇有提及我可是足足背下了1000道题目，多少还是有点用的呢，我看了下，上面这些问题大部分都能从我背的题里找到的，所以今天给大家分享一下互联网工程师必备的面试1000题。
注意不论是我说的互联网面试1000题，还是后面提及的算法与数据结构、设计模式以及更多的Java学习笔记等，皆可分享给各位朋友
互联网工程师必备的面试1000题
而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
试1000题**。
注意不论是我说的互联网面试1000题，还是后面提及的算法与数据结构、设计模式以及更多的Java学习笔记等，皆可分享给各位朋友
[外链图片转存中…(img-pt5J4KhI-1711867407173)]
互联网工程师必备的面试1000题
而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。
[外链图片转存中…(img-oCrvCej6-1711867407174)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
1618
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
