-
发表了文章 2023-01-30
网易游戏实时 HTAP 计费风控平台建设
摘要：本文整理自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳，在 FFA 实时风控专场的分享。本篇内容主要分为五个部分：实时风控业务会话会话关联的 Flink 实现HTAP 风控平台建设提升风控结果数据能效发展历程与展望未来点击查看直播回放 & 演讲PPT众所周知，网易互娱的核心业务之一是线上互动娱乐应用服务，比如大家耳熟能详的梦幻西游、阴阳师等都是网易互娱的产品。不管是游戏产品还是其他应用，都需要做出好的内容来吸引用户进行应用内购买，进而产生盈利。当用户在商城里点击商品进行购买的时候，会弹出支付界面，进行验证、支付后，就可以收到道具了。这个过程对于用户来说往往都是一些非常简单的操作，但为了保证这个过程可以正确结算、发货，整个支付流程其实跨越了很多服务提供商和终端，走了一条相当复杂的调用链路。这些不同的业务节点之间会产生很多相互的调用关系，进而产生一些异构的日志、数据、记录。由于经过了网络，其中的数据可能会有一定时间水位线的不一致、延迟，甚至数据丢失的情况，且本身这些数据又很可能是异构的，就更增大了我们对这些数据进行分析和使用的难度。如果我们需要用这些数据进行高时效性的故障排查或者风险控制，就势必需要研制一套方案，来适配这样技术需求。为了解决以上的问题，我们以 Flink 为计算引擎构建了一套实时风控平台，并为他起名为 Luna，下面我将为大家进行详细的介绍。一、实时风控业务会话常见的线上支付逻辑是，当用户在应用上点击商城的道具进行应用内购买的时候，用户的客户端终端就会到计费系统进行下单，获得本次下单的订单信息。然后我们的客户端会弹出支付界面，用户进行渠道付款。当支付完成后，我们会把渠道返回给客户端的支付凭证回传给计费系统，计费系统会去渠道验证凭证是否有效。如果是有效的，就会通知游戏服务器发货，这个时候我们的客户端才会收到道具。这就是从用户点击到最终收到道具的整个流程。从这个已经极度简化了的支付模型可以看到，不同的公司、服务提供商、部门、服务系统会产生了一系列会话下的数据。如果我们能把这些数据收集起来，进行一定的处理后，还原当时用户操作的现场。这将对运营运维人员在定位故障、排查故障，甚至整个业务环境的宏观分析都有着非常重要的价值。而分析的关键点是，我们如何还原这个行为的现场，我们把这个行为的现场叫风控业务会话，即由一次用户行为所引发的，需要多个系统协作完成、同时触发多个请求、产生跨越多个服务提供方调用的全过程。这里需要注意的是，业务会话跨越了多个相互独立的请求链路，且没有统一全局的 trace-id 可以被提前置入所有的数据中。由于我们的业务会话需要跨越多个请求链路，所以在数据关联分析的时候就存在很多难题。比如：多服务、多请求产生的异构结果难以直接关联。调用顺序复杂，存在并发、异步的情况。时间跨度大、业务水位不同步。以前在解决支付丢单、支付一次重复发货等问题的时候，往往只能通过运营人员去处理，这就非常依赖于运维人员的经验了。并且在这些大量的数据里，会有非常多冗余和无用字段，还有可能会有一些非常复杂的嵌套关系。这些都有可能让运维人员在判断时产生错判和误判。此外，还会给运维人员带来非常多的重复性工作，从而使得人力能效低下，把时间浪费在重复的事情上。前文也提到了开源 Tracing 方案，往往需要依赖全局的 trace-id。对于新的系统，我们可以提前设计 trace-id 打点。但是对于有历史包袱的系统来说，他们往往不愿意修改跟踪来跟踪打点，那么这个时候传统的方案就走不通了。在这种情况下，如果我们要进行业务会话还原，就需要设计一套新的方案。这套方案我们希望可以具备以下功能：实时微观业务会话检索与查错。实时宏观业务环境统计与风控。业务会话级数据能效挖掘与提升。从还原业务会话到使用数据做 HTAP 实时风控平台的全过程，我们使用 Flink 消费原始数据，根据平台上提前配置好的分析模板，实时还原出业务会话。然后把业务会话的结果存储存起来，并为它打上我们提前设置好的一些结论模型，产生的风控结论。对于存储起来的这些微观会话进一步被聚合，进而产生整个业务环境上的宏观统计量，以支持我们在整个平台上的风控分析需求。二、会话关联的 Flink 实现Flink 是实时计算的实施标准，基于此我们毫无疑问地选择了它。那么实时业务会话关联在 Flink 系统上，我们希望可以做出怎样的效果呢？第一，零侵入。即无需对现有业务进行改动，也无需有全局的跟踪 ID，就可以做到业务会话的还原。第二，跨数据源。因为我们的业务往往需要跨越 n 种数据源，所以我们希望这 n 种数据源都可以被这个系统所支持，比如日志、维表、事实表、REST 接口等。第三，实时。实时产生结果，无需等待 T+1。第四，低代码。我们希望基于分析需求，可以通过向导式的配置，来产生实时的分析模板，并对宏观统计报表，可以配置式的进行多维度聚合。上图展示的是 JFlink-SDK，它是网易自研的一套流管理平台以及它的开发手脚架 SDK。大家可以把它理解成是一套可以模块化配置式开发的流作业手脚架，实时关联分析的引擎就是基于这套手脚架开发出来的。回到在使用业务会话还原的问题上。来自各个数据源的数据业务点，通过各种方式被同步收集到数据仓库的存储层中，我们有多种数据存储收集这些数据。针对各种各样的数据存储，Flink 有非常丰富的 connect 可以进行消费。然后 JFlink-SDK 又对它进行了二次封装，定义异构数据。使其在读取到 Flink 的时候，可以被转化成统一的视图。这些数据视图是我们提前建设好的一些数据治理系统和平台，数据治理系统会为 JFlink-SDK 提供数据读取的规范。当通过 SDK Source 读取后，他们就会被统一转化成业务视图，这样就非常方便我们后续对这些原始异构的数据进行关联了。它的数据结构是以基准和非基准共同构成的一种设计。在进行业务数据点关联的时候，它的基本思想是基准+补充。所以我们在选择业务时，会选择最为核心的风控阶段作为基准，也就意味着，基准是整个业务中最关键的步骤，可以用唯一的 ID 关联起来。对于通过业务 ID 关联起来的基准，我们会形成一个类似图的数据结构，这个东西我们称之为基准簇，它由同一种数据来源的基准和补充所关联得到的一个雪花状数据结构。基准是业务会话中最关键的步骤，它通常是公共携带的某种标志步骤。比如以计费下单为场景，客户端的下单，打开支付界面、上传凭证、支付完成是四个最为关键的步骤。他们都打上了执行这些步骤的订单号，这四个步骤就可以作为整个业务规划的核心步骤，也就是基准。因为数据是不按顺序到达的，所以出现这是个步骤中的任意一个我们都可以开启业务会话。而下单记录、商品详情、渠道回调记录等等一些辅助性的数据，他们对问题定位起不了关键作用，而且它们可能没有基准中订单号的字段，所以就没有资格被选为基准。但它们中也有一些字段可以和基准中的字段进行关联。比如渠道回调日志，渠道商在一些辅助性的数据上打了 trans_id 字段。它虽然没有 order_id，但它可以通过 trans_id 与基准中的 trans_id 建立一一映射的关系，也就是我们可以通过 trans_id 关联起这份数据与基准簇的关系。所以通过基准+补充，我们就可以解决目前线上系统，无法为所有数据打上统一 ID 埋点的痛点。在 Stream API 中基准关联的实现，我们使用的是 Session Window。它是 Flink 提供给我们的标准时间窗口之一，可以在有数据流入的时候进行窗口时间超时的重置。除此之外，如果整条流的业务水位线，越过了整个超时时间的边界，它就会触发窗口计算。这种结果就非常适合由用户触发的会话窗口，也适合我们基准数据构造的逻辑。但用户引起的这种行为，往往时间是不固定的，所以带有属性的会话窗口就非常适配这种特性。比如风控业务会话的还原，和浏览商品到最终下单支付的整个支付应用轨迹的追踪，都非常适合用这种模式来进行窗口计算。这里的 Flink Session Window 其实就是前文提到的构造完毕的基准簇，它包含了所有被关联进来的原始数据，以及按照一定规则处理好的二级字段。至于它怎么在关联的时候进行字段抽取呢，后续再来讨论这个规则，此处就先认为，在窗口完成的时候就把簇计算出来了，并完成了所需字段计算和抽取。一般用户的支付意愿窗口往往在 10~20 分钟，如果我们直接使用 Event Time Session Window 来进行计算，就会发现如果用户很快完成了下单，但系统仍然需要等待 10~20 分钟，才能使会话窗口进行计算，这就大大降低了数据的时效性。对此 Flink 也为我们提供了一口入口，我们可以自定义窗口的 Trigger 来设置窗口触发的时机和业务会话提前结束的判定。举个例子，一些数据量极少的场景，它的水位线可能一直没有向前推动，这种情况我们就可以加上 Process Timeout 和 FIRE & UPDATE 语义。这就可以让业务会话在水位线没有推进的情况下，先进行计算，往后发送。然后在下游进行保证，即当上游重复 fire 的时候，可以进行 update 的语义。再举个例子，我们可以在风控的分析模板中配置一下。当业务会话满足某些条件的时候，就不用再等待超时了。比如当所有的节点都被关联上时，如果继续等待也不会等到任何节点，这个时候就无需等待超时时间，可以立即 fire 出结果。当业务会话存在一些特殊且极端的情况，比如客户端支付到一半崩溃了，等了非常久才起来，这个时候很可能就会被拆分为两个业务会话，因为前一个业务会话已经超时了。这种时候我们会选择把两个被分裂的会话 fire 出来，然后由运维人员进行合并或者保持原样。接下来我们来讨论一下，对于补充的数据我们又是如何构造的。基准数据拥有公共 ID，所以它们可以被 Key By 到数据窗口里进行计算。但是补充数据点往往是各自用各自不同的 ID 进行关联，所以这个时候我们就可以类比数据库里的多表 join 了。不同的补充数据就类似于一张不同的表，通过不同的字段与基准数据簇进行 join 操作。这就是我们遇到的挑战，它不仅关联字段不同，水位线的推进速度也很可能不一样，这都是无法把它们两者放到同时间窗口中计算的关键因素。那么如何去解决这个问题呢？如何基于扩展的基准先进知识，关联回没有公共 ID 的补充数据呢？这正是整个解决没有公共 trans_id 还能形成会话的关键所在。类比 join 操作，Flink 已经为我们提供了非常好用的算子，叫做 Interval Join。即两种输入数据分别取自己的特定字段作为 key，然后通过这个 key 把他们分到同一分组上，进行时间区间内的 join。Flink Event Time Interval Join 是把当前流和对手输入流里，指定上下边界的区间内数据进行 join，这种特性就非常适用于我们这种场景，因为当我们从基准数据簇中取一个字段，和从非基准的补充中取一个字段，如果它们等值，那就意味着它们属于同业务会话，它们应该进行关联。这个时候就可以用 Interval Join 算子进行关联，而且 Interval Join 不会打开时间窗口，因为每条流的 GC Watermark 是根据对手流加上我们提前配置的边界时间区间来进行的，这种结构就非常适合两种数据流时间水位线推动不一致的情况。 但是还有另外一种情况，就是当某一条数据来源有延迟的情况下，这笔数据会被丢失，这是 Flink 1.16 正式版之前的情况。在 Flink 1.17 版本中，社区的小伙伴已经把这个代码合并进去了，后续很期待在新版本中使用这个功能。当数据延迟进行补回的时候，我们的处理方式是，把延迟数据和当时关联的上下文，放到消息队列里，通过流重新消费出来，并根据当时关联的上下文，重新从数据存储里把写进去的会话查回来，然后用同样的逻辑重新把这笔数据补回更新，写回数据库。这样整个过程中无论是实时关联，还是延迟数据的补回，用的逻辑都是完全一样的，保证了我们处理逻辑的简洁和一致性。最终我们用 Flink 实时关联出来的业务会话会被存储起来以供检索，并通过 Luna 平台以行为树的形式进行展示。三、HTAP 风控平台建设当我们完成了算法可行性测试，并使用 Flink 实现了技术原型后。接下来就是如何把这一整套框架平台化，使其成为便捷、准确、丰富的风控平台。风控平台需要做到以下这些功能。支持微观排障，可以具体查询某一笔订单、业务会话当时的业务场景，把它还原出来；支持从宏观上统计整个环境的各种数据量。且配置和查询都需要是自助、向导式的。基于以上的考虑，我们设计了 HTAP 实时风控平台 Luna。基于这个平台，用户就可以自己从各种异构数据源中选择，配置业务行为树和分析模板。然后平台会根据配置好的模板，起 Flink 流算出业务会话的结果，形成会话结果存到存储层。且支持用户从平台上进行条件检索，进行多维度的聚合。分析模板的配置我们是做了自动更新，也就是所有平台上的更新都无需人工运维。从上图中可以看到，核心组件是计算层的 Flink，加上存储层的 TiDB，加上我们自己基于 JavaScript 的平台服务系统。目前可以达到微观查询是毫秒级，多维度的风控聚合结果在年级别都可以做到秒级查询。我们的平台支持，用户从不同的数据源中选出，需要参与这一次关联分析的数据和关注抽取的字段进行配置。配置好后，Flink 会根据这些配置，自动生成出 Flink 的 Source 和 Sink。然后进行行为树的定义。定义整个业务行为会发生的动作，本质就是用人力运维排障方法论进行沉淀和泛化，将配置的形式固化下来。之后这些配置模板就会用于生成 Flink 流的 UDF 配置，并被实时同步到运行中的 Flink 流中。除此之外，配置界面还提供了预览功能，即可以一边配置一边预览整个行为树。风控场景上的分析模板修改后，如果不涉及数据源的增减，我们的流可以通过 broadcast stream 的特性进行自动同步和变更。从架构图中可以看出，我们选择了 TiDB 作为关联结果的存储层。那么我们是如何考虑的呢？数据结果需要灵活可拓展，且适配索引。这样用户就能快速的自由配置抽取字段。频繁的更新操作。因为我们的计算逻辑决定了我们会构造基准数据，再构造补充数据，以一种异步的形式写到数据库，所以需要频繁更新。完备的聚合函数。因为宏观统计需要做各种各样的聚合，以满足我们数据分析统计的需求。满足业务需求的写入/读取速度。这样就可以使用列转行的结构，存储到我们的关系数据库里了。列转行是把会频繁发生增减字段的 DDL 转化为 DML，就可以支持我们灵活的数据结构。每个字段都需要索引这样的特性，这在数据量持续增大的表上，就有着非常优秀的特性。在这样一种存储结构上，我们的微观业务会话查询就可以做到毫秒级，灵活结合多种条件进行检索，以帮助运维人员快速查看线上风险和可能发生的故障原因。当我们点击查看任何具体的业务会话时，公共平台就会展示出当前这个业务会话的业务行为树，并抽取出有助于排障的一些关键字段和二级指标，极大方便了我们的运维人员排查具体问题的场景。对于常见的问题，我们甚至还会用结论模型直接给出风控结论，让我们的运维人员进去就能马上看出问题所在。对于宏观统计，大家肯定也想到可以使用 SQL 作用在上面来进行统计了，毕竟我们把数据存在了关系型数据库 TiDB 里，但这里还存在着一些坑点。当我们的数据量超过 10 亿的时候，我们的数据聚合时间会出现一些变化。比如当粒度是一小时，聚合时间是一天的时候，我们数秒可以完成。但当我们把时间拉到 60 天，几乎就出不来了。在查看数据存储层的时候会发现，TiKV 已经 IO 满了，而且 CPU 飙升，因为我们做的数据量实在是太大了。通过分析整个执行计划可以看到，TiKV 使用常规的模式进行 SQL 把所有数据捞到 TiDB 层进行聚合计算。这样做获取的数据函数会非常多，随着我们时间区间的增大会越来越缓慢，这样我们肯定是不能接受的。那么我们来回看一下风控的 AP 需求，我们需要读取大量实时的关联的数据点；支持有复杂的聚合函数，且我们的查询不应该影响到 Flink 流进行 TP 写入。这个时候就会想到，TiDB 有一个叫 TiFlash 的组件，它可以完成 TiDB 的 HTAP 特性。也就是 AP 和 TP 同样用 SQL 来完成，且它是物理隔离的，这就非常的适用于这样的场景。TiFlash 伪装成一个 Raft Learner TiKV 节点，加入 Raft Group，参与数据实时、事务性同步。这样就可以做到 AP 和 TP 的物理隔离，并且它还支持事物，这样就可以在执行 SQL 的时候无感进行 HTAP 了。在进行这样的优化后我们可以看到，当我们的查询包含多层 join，甚至有分位数计算的时候，90 天聚合时间，粒度查询可以在十秒内返回和完成，这可以说是一次质的飞跃。最后，我们把宏观统计提供给用户。在 TiFlash 的助力下，我们的平台可以做到秒级的 AP 多维度聚合查询。这种聚合查询出来的结果可以让我们的数据分析人员，从更高层次对整个业务环境的风险进行识别。四、提升风控结果数据能效当我们可以实时产生业务会话的结果，并在平台上展示的时候，接下来我们将通过以下几点提高数据效能。风控结论生成：节约重复人力成本标签和统计：将详情数据归类统计为宏观数据数据打宽：增加分析维度可视化展示：挖掘数据规律那么我们为什么把数据存储在 TiDB 这样的一种关系型数据库里呢？因为 TiDB 作为一个分布式数据库，被我们广泛存储各项业务的事实和维度数据了。如果我们把风控数据簇也放在这里面，通过简单的专业操作我们就可以完成数据的拓宽，丰富我们的数据报表。不仅是产生离线报表的时候可以这么方便的转，我们在实时计算的时候，也进行了 Async Join，通过 Async Join 转 UDF 进行实时数据打宽，同时我们支持多种存储介质。对于这种 Async Join，我们利用了 Flink 的 Async IO 的特性，并在 join 的时候进行了一些优化。比如进行批的 join，不同时间水位线的缓存 join 以及 timeup 数据的侧输出等等，这些都为数据的准确性提供了保障。通过数据打宽后，我们的风控统计分析维度就可以更上一层楼了。之前通过 ID 无法做到的特殊聚合，现在把数据打宽，都可以进行可视化的一些分析和展示了。除此之外，对于常见问题，我们支持预先配置结论模型。当运维人员实时查询微观会话时，直接为他们给出结论。得到结论后，我们就可以从更高的角度，观察和统计整个业务环境的宏观情况了，甚至可以进行实时的业务环境监控。从而提高故障的发现率、预警率、预警的准确率以及整个运维人力的能效。并且通过可视化的展示可以使我们的风控平台更准确的提供服务。五、发展历程与展望未来早在 2017 年我们就对实时计算开始调研了，并在 2018 年形成了双向发展的规划，分别是平台化和 SDK 手脚架的改造，经过多层的迭代，最终形成我们的一站式运维平台。随着平台和 SDK 的发展，我们的实时业务线也越来越广泛。比如从最早的日志分析监控，到通用的解析 ETL，到用户画像，到复杂的关联分析，再到如今的实时风控平台，我们也是在实时领域越走越远，这都是 Flink 给我们带来的变革。未来我们希望，可以实时风控平台可以支持更多的功能。比如我们希望支持用 Flink-SQL 即席查询风控结果；用户反馈驱动的风控模型修正；结合 Flink-ML 挖掘更深层次数据价值。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-18
中原银行对金融行业实时数仓的现状与发展趋势思考
近期举办的 2022 第四届实时计算 Flink 挑战赛中，在各位大佬的指导下，完成了本课题的设计和实践，现在把本方案的设计思路分享给大家，希望通过本次经验分享可以为其它企业带来一点实时数据使用的新思路。众所周知，实时数仓落地是一个难点，尤其是金融行业，还没有出现真正所谓的实时报表。金融行业个别案例的实时数仓是在较窄场景、较多限制下的尝试，还不能够称之为实时数仓，如银行普遍的实时报表业务都无法满足。当前亟需设计实现一套能够落地的金融行业的实时报表方案，来满足业务场景对数据时效性越来越高的需求。本文内容首先介绍了银行业常见的实时场景和解决方案，然后针对银行业报表依赖维度表计算的特点，提出了基于 Flink Table Store 作为数据存储，进而构建流式数仓的解决方案。在正式开始之前呢，简单介绍一下中原银行的基本情况。中原银行是河南全省唯一的省属法人银行，总资产突破 1.2 万亿，在国内城市商业银行排名第 8 位。本团队是负责中原银行的实时计算业务，包括实时的采集、加工和分析全链路。一、金融行业实时数仓现状分析1.1 动账场景介绍 数仓建模有范式建模和维度建模，银行业采用的是维度建模，其中分为事实表和维度表。事实表：刻画行为的，一般用来统计交易笔数，交易金额，业务量等。维度表：描述结果和状态的，常见的用户手机号、身份证号、所属的机构等不经常更新的数据，但其中银行业比较重要的有“账户余额”，客户余额会随着动账交易而频繁更新。本文以银行典型的动账场景为例，一次动账操作其实是一个事务，至少操作两张表，第一张比较好理解，就是交易流水表，记录转账的一次行为；第二张则是用户的属性表，其中有一个字段是用户的余额，需要随着动账的交易流水表同步更新，上面的两个表是两次转账的示例。在这个转账场景下进行分析流水表的特点：主要是 Insert 操作，记录行为信息，适合增量计算，如统开户、取款、贷款、购买理财等事件行为。应用的场景有实时营销，如大额动账提醒，工资代发，理财产品购买等；实时反欺诈的申请反欺诈、交易反欺诈；在贷后管理也有应用，如监控用户入账行为，提供给零贷贷后临期催收、扣款等。客户属性表的特点：主要是 Update 操作，记属性信息，客户的存款、贷款、理财、基金、保险等产品的余额是在维度表中，所以常使用维度表全量计算资产信息，如资产余额类的计算，计算某分支行的总存款余额等。应用的场景主要是实时报表、实时大屏：如对公 CRM、零售 CRM；经营管理；资产负债管理等。针对于银行业这两种典型的动账场景，有三种解决方案。下面逐个介绍不同方案适用的场景和有哪些局限。1.2 基于 Kafka 的 ETL该架构能够解决的问题，大多是基于事实表的增量计算，已经在行内有大量的落地案例，但无法解决银行业的基于维度表的全量计算。另外该方案很难形成规模化的数据分层复用，Kafka 存在数据无法查询和长期持久化等问题。这种烟囱式的 case by case 开发阶段，本行已经经历过了，生产上也有大量的落地场景，实时任务达到了 300+个。1.3 基于微批的 ELT为了解决银行业大量基于维度表的统计分析场景，来看一下进行了哪些方式的探索。总结来说，是一种先载入后分析，也就是 ELT 的方式。过程是这样的，先实时采集-> 然后直接实时载入->最后在实时 OLAP 查询阶段进行逻辑的加工。在ELT探索的的初期，我们采用过微批全量计算的方式，在数据实时地写入到数据库后，定时执行全量加工逻辑，类似于离线数仓有跑批的概念，只不过每天跑批缩短到了小时级别或分钟级别跑一次批，来达到准实时加工的效果。显而易见，这种方式是不可取的，存在时效性差、跑批不稳定等问题。1.4 基于视图的 ELT随着 MPP 数据库的发展，查询性能得到了极大的提升，本行使用 StarRocks 引擎，通过 View 视图嵌套加工逻辑的方式也进行了探索，也就是把业务数据库的数据以 CDC 方式，载入 MPP 数据库的明细层，查询分析逻辑使用 View 封装，在查询触发时直接计算，这种方式也可以解决基于维度表的全量计算，但每次查询资源消耗太大，支撑大数据高频率的查询操作比较困难，无法大范围应用推广。1.5 动账场景总结基于事实表的增量计算已经在生产进行了大量的落地和实践，本文主要是讨论银行业基于维度表的全量计算场景，上述两种解决方案虽然能够解决一部分实时场景，但局限很大，当前阶段来到了优化升级和未来方向选择的节点。为了解决银行业基于维度表的实时 OLAP，必须把部分计算向前移动，在 Flink侧计算。湖存储 Flink Table Store 的出现，使基于维度表的全量计算成为了可能。也就是底层一部分转化工作在Flink中计算，另一部分聚合计算等工作在 OLAP 数据库中计算，两者分摊一下计算时间和资源消耗。在未来，还是希望把全部加工逻辑，全部在Flink端分层完成，向着存算分离、流批一体的流式数仓方向发展。二、基于 Flink Table Store 的金融行业流式数仓2.1 Flink Table Store 介绍2022 年发布的 Flink Table Store，能够很好地解决之前遇到的大量数据更新、全量存储等问题，Table Store 是一个统一的存储，用于在 Flink 中构建流式处理和批处理的动态表，支持高速数据摄取和快速的数据查询。是一种湖存储格式，存储和计算分离，导入数据时双写到数据文件和日志系统。支持流批写入、流批读取，支持快速 Update 操作。还支持丰富的 OLAP 引擎，Hive、Trino 等，当前 StarRocks 也在支持湖存储查询分析，相信在不久的将来，StarRocks 也是能够支持查询 Flink Table Store。了解详情，请移步到官网：https://nightlies.apache.org/flink/flink-table-store-docs-release-0.2/2.2 导入数据在银行业，业务数据库仍然是以 Oracle 为主，全量数据初始化到 Flink Table Store 中，使用的 Oracle Connector 需要开发才能使用，同时需要支持 Filter、Project 等操作。采用 JDBC 连接以流式读取数据库的方式进行全量写入到 Flink Table Store 中，同时在建表配置项中配置 changelog-producer = input，保存完整的 changelog，为后续流写和流读作准备。在完成了全量数据的初始化，后续增量的更新数据需要持续地写入到 Flink Table Store 中，首先从 Oracle 中把数据实时地抽取出来，以 JSON 格式写入到 Kafka，供后续多个场景复用 Topic。在银行业，数据库管理较为严格，能够实时获取业务数据比其它行业要解决更多方面的困难。下面模拟一下动账过程：客户表初始状态为客户 1、2、3 的余额分别为 100、200、300。客户 1 转入 100 元，则客户表执行 Update 操作，使客户 1 的余额从 100 -> 200。客户 2 转出 100 元，则客户表执行 Update 操作，使客户 2 的余额从 200 -> 100。数据库的 Update 操作，使用 CDC 工具把 changelog 信息以 json 格式写入到 Kafka 队列。后续启动 Flink SQL 任务消费 Kafka，将 changelog 流写入到 Flink Table Store 中。 在拿到增量的 CDC 数据后，需要把增量更新数据和历史全量数据进行融合，才能够得到完整最新的全量数据。这里有两个问题需要探讨：第一：全量数据和增量数据为什么分开写入呢？避免实时数据抽取多份，统一写入 Kafka，后续多个实时场景可以复用；离线数据全量初始化可能是一个经常性的操作，比如每周进行一次全量的初始化。第二：全量数据和增量数据如何保证衔接正确呢？维度表常规情况下是有主键的表，这样就能够保证有幂等的特性，只需要保证增量数据早于全量数据就行了。比如增量数据5点开始启动写入到 Kafka，全量数据 6 点开始全量同步，增量写入任务在全量同步结束后开始指定早于 6 点的数据开始消费就可以保证数据的完整性了。 另外在写入 Flink Table Store 时需要配置 table.exec.sink.upsert-materialize= none，避免产生 Upsert 流，以保证 Flink Table Store 中能够保存完整的changelog，为后续的流读操作做准备。2.3 查询数据第一种方式，Batch模式。历史存量和实时写入的数据，均能够在线 OLAP 分析。支持流写批读，Batch 模式读取数据是从 Snapshot 文件中读取，checkpoint interval 周期内可见。支持多种查询引擎 Hive、Trino、Flink SQL 等，全局有序 Sorted File 的 Data Skipping，Sort Aggregation and Sort Merge Join 特性等。这里可以任意时间查看各个分支行的存款余额，或者分析客户的明细信息等。第二种方式，Streaming 模式。以 Streaming 模式启动查询时，任务会持续在线运行，当客户 1 进行转账操作时，如转入 100 元，变成了 200 元。此时在实时数仓发生的过程如下：这个过程有如下特点：流批统一。存储统一，Snapshot+Log，存量数据读取 Snapshot，增量数据读取 changelog，hybird 读取全量实时数据。查询统一，离线和实时使用相同的 SQL 语句。Streaming 模式开启 mini-batch 减少聚合语句的冗余changelog 输出。减少物化。FTS 中有完整的 changelog，避免 Flink State 中生成物化节点。时延较低。changelog 使用 File 存储，代价低，时延高；使用 Kafka 存储，代价高，时延低。数据驱动，而不是时间调度驱动或者查询时才开始触发计算。2.4 导出数据最终的结果数据，如果查询频率不高，可以直接使用 Flink 1.16 提供的 SQL Gateway 功能；如果查询频率较高，可以再以流式写出到外部的数据库中，提供稳定的在线服务能力。2.5 未来发展实现真正端到端的流式数仓，既能够支持实时数据和完整的 changelog，也支持批量导入离线数据，当数据在源头发生变化时就能捕捉到这一变化，并支持对它做逐层分析，让所有数据实时流动起来，并且对所有流动中的数据都可以实时查询，是以纯流的方式而不是微批的方式流动。在这个过程中，数据是主动的，而查询是被动的，分析由数据的变化来驱动。数仓的分层可以解决实时数据的复用，多指标随着数据的实时流动而实时变化，从另一种角度说也是在用空间换取时间。离线数据和实时数据共同存储在 Flink Table Store 中，使用廉价的存储和存算分离更加灵活的进行弹性计算。离线分析 sql 和实时分析 sql 式完全一样的，最终达到流批一体的效果。总结如下：存算分离的湖存储，FTS 提供完善的湖存储 Table Format，提供准实时 OLAP 分析。能够存储全量数据，每层数据能够可查，支持 Batch 和 Streaming 两种模式。支持大量数据更新，有序的 LSM 结构，支持快速的 Update 操作。支持流批写流批读，尤其是能够流式读取，流式数据从 Log System 中读取。完整的 changelog，支持全部流程传递完整的+I、-U、+U、-D 操作，减少 Flink State 中的物化节点。真正实现流批一体，流批统一 Flink SQL，流批统一存储。那为什么不直接采用这种架构进行构建呢？当前阶段这个架构还无法完全落地，比如其中聚合计算有大量的撤销动作、多个层之间的实时数据流动需要大量的资源和调试技能等，不过随着技术的发展，相信流式数仓一定会到来。2.6 流式数仓落地进展当前阶段，既然多层的流式数仓落地还有一定的距离，那么在加入 Flink Table Store 后，在原有 ELT 架构的基础上，进行优化升级，看看带来了哪些变化。在整个计算过程中，直接把原始数据写入 Flink Table Store，使之存储历史全量和实时更新的表数据，然后计算逻辑使用 Flink SQL 实现，最后把初步汇总的数据写入到 StarRocks 中。原始明细数据在 Flink 中计算，极大的减少了 StarRocks 的计算逻辑，Flink 和 OLAP 引擎两者协调配合，共同提供端到端的实时报表业务。这种架构在我们在生产上也已经行进了初步的尝试，效果非常显著。以对公 CRM 实时存贷款场景为例，该功能显示全行、分支行的实时存贷款情况。旨在为业务人员及客户经理提供一个可以随时查看行内总/分/支行及客户的存贷款等重要业务指标变化情况的功能，从而时刻掌握行内资产最新状况。扫码进入赛事官网了解更多信息：更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-16
Disney 流媒体广告 Flink 的应用实践
摘要：本文整理自 Disney 广告智能执行总监郝又超、Disney 广告智能实时计算负责人李丁哲，在 FFA 的分享。本篇内容主要分为四个部分：Disney 流媒体广告与实时应用业务场景实现实时平台构建未来展望点击查看直播回放 & 演讲PPT一、Disney 流媒体广告与实时应用说到 Disney 流媒体业务包括 Hulu，大家可能并不熟悉，因为我们在国内的业务并没有落地。Hulu 是在 15 年前由 Disney、福克斯和 NBC 共同发起成立的，现在已经在美国本土是一家头部的流媒体平台了。2019 年，Disney 收购了福克斯从而得到的 Hulu 的运营控制权，因此也得到了 Hulu 上的广告平台这样一个优质资源。因为作为传统的流媒体公司，Disney 原来并没有自己的技术广告平台，而在 2019 年之后，Disney 也陆续的发力线上流媒体，推出了 Disney+，ESPN+，Star+等多个流媒体品牌。下面来具体看一下 Disney 和 Hulu 的流媒体以及广告业务的数据。2.35 亿，是截止到今年十月份，Disney 流媒体包括 Disney+，Hulu，ESPN+，Star+在全球的订阅用户。这是一个什么概念呢？Netflix 已经在全球运营了超过十年，我们在今年 7 月份就已经超过了它全球的订阅用户数，且我们的订阅用户数是以家庭为单位的，所以实际触达的个人用户可能有 7 -10 亿。Hulu 是当前 Disney 流媒体广告业务的主要来源，每天投放数亿 15 秒、30 秒长的视频广告，而每选择一个广告都会产生几十甚至上百个事件，对数据平台有着极高的挑战，随着 Disney+上 12 月份即将上线广告，这种挑战预期将数倍增长。接下来给大家稍微介绍一下 Disney 的流媒体广告数据平台。大概分为两层，一层是底层的数据和算法，另一层是应用和服务。数据和算法主要包括三部分：用户数据。主要通过以用户和用户身份为主要维度来汇聚用户的行为数据，从而对数据交换以及广告所需要的定向进行人群圈选的核心能力。运营数据。主要包括两部分：一部分是通过以广告的曝光为核心，汇聚所有的广告曝光、投放、转化以及用户交互的数据，形成 Event Store。另一方面是通过对 Event Store 在广告的订单维度上进行进一步聚合，提供各种的 KPI。这些聚合通常是实时的，这就是 Flink 在我们广告平台上主要的应用场景。机器学习平台。主要通过我们丰富的数据，从用户、广告商以及 Disney 的核心的业务指标进行优化。可以说数据和算法提供的应用和服务，驱动着我们整个广告生命周期的各个环节。比如:售卖和规划阶段，我们提供库存预测，用户洞察；投放和交易阶段，我们提供实时的定向、实时的决策、实时的监控和故障定位；报告分析阶段，我们有商务智能、广告的归因和面向广告商的各种报表。从具体实时应用的角度，我们目前使用 Flink 主要尝试了三个场景，分别是广告决策漏斗、广告曝光监控、广告系统大屏，这三个环节将在后面做具体阐述。二、业务场景实现大概在两年前，我们对流计算框架做了一个统一的选型，之前有用到多种的流计算框架，为了实现上面提到的业务需求，最终选择了 Flink。原因有以下几点：使用 Flink，可以比较灵活的使用它的 vp 的处理或者流式的处理，从而达到我们对于时效性的多种需求。Flink 它有流批统一的 API，我们可以用 Datastream 对有限流做 Batch 处理，或者对无限流做流式的处理。而且它可以让我们使用同一套代码，大大减少了我们维护代码的压力。Flink 支持 Exactly Once 语义，结合我们的上下游，可以达到一个从端到端的 Exactly Once 的保证。Flink 有很多非常好用的编程的接口，比如 Window Functions。从整个大数据平台上来看，Flink 的定位主要如下图所示。首先从系统及用户侧去把数据收集到多个消息队列中，然后在上面这条 Flink 统一做一个流式计算，计算出业务所需的一些指标，通过数据接口暴露给实时的业务平台、实时的运维平台，以及其他一些系统如广告服务器。在批处理的这一条链路上，除了会用 Spark 生成一些离线的业务报表、离线的对外数据输出，还会用 Flink Batch 做一些指标回填的操作。下面分享下第一部分最后提到的三个场景。第一个场景是广告决策漏斗，主要面向的是维护人员和开发者。对于广告的决策系统来讲，广告决策是一个相对比较复杂的过程。当用户登录到流媒体平台的时候，我们需要从一个庞大的广告池子里，通过粗排、精排等多个过滤条件，最终给用户选择出一个最适合他的广告。因此在这么复杂的业务场景中，就萌生出了运维同学、开发同学对错误排查能力的需求。我们把广告决策的整个流程，抽象成了一个广告决策漏斗。我们希望通过前端给运维人员、开发人员展示一些具体的信息，比如在漏斗里是否有投放的机会、广告是否定向成功、是否被过滤掉、最终有没有投放给用户，如果没有投放给用户，失败原因是什么等等。对于这个业务场景我们主要有三个非常需要关注的点。数据质量。作为一个需要供大家去做 debug 的平台，我们希望我们的数据质量能够得以保证，要不然这个平台将毫无意义，甚至会误导运维人员、 开发人员，使他们做出一些错误的判断。系统时效。我们不仅希望广告系统在出现问题时，可以及时发现，希望在运维人员更改配置后，或者开发人员修复一些代码 bug 后，可以及时在广告平台上看到变化，来判断是否成功修复了问题。开销代价。决策漏斗是一个监控平台，我们不希望它消耗太多的计算资源。那么在整体的架构中，首先需要我们的广告服务器将一些决策信息进行一些动态的编码压缩，然后发送到消息队列当中。Flink 从消息队列中统一做拉取，在窗口框架中将它们 Join 起来，还原出决策漏斗。在这之前也做了一些解码的工作，最终将决策漏斗放在前端进行展示。这一条实时链路在实现的时候，我们使用了 Exactly Once 语义。上下游都是使用的 Kafka，利用 Kafka 的能力获得 Exactly Once 的保证。OLAP 这一套插入数据的系统也是保证了 Exactly Once 从 Kafka 读取到数据库中，最终成功的实现了从端到端的 Exactly Once。下面这一条离线的批处理链路，只把它当作一个纠错的链路，当我们实时链路有一些 bug ，造成部分数据质量问题时候的一个数据重填以及纠错。在这个离线链路上，我们也是尝试使用了流批一体，使用同一套代码去做这个数据的回填。总结一下，刚才提到的三点我们最关心的核心问题；在数据质量方面，我们从业务角度上看，实现了脏数据收集旁路。一旦发现上游传输的数据不对，运维人员就可以及时得到通知，去进行问题排查。然后这一条链路从底层是用 Exactly Once 做的数据质量的保证，保证都是可以信赖的数据。在开销代价方面，Exactly Once+流批一体也实现了一个 Kappa 的架构。传统 lambda 架构需要做一个常驻的回填纠错。在 Kappa 的架构下，这一部分的计算资源可以被节省下来。在系统时效方面，我们也做了一些优化，比如优化了 Flink 本身任务的一些性能。像决策信息是由压缩、动态的编码来发送到我们后端的，这里就涉及了一些比较复杂的数据模型，因为它的原生正反序列化比较缓慢，所以我们进行了一个针对性的优化，提高了整体链路的吞吐率。可能比较熟悉的同学知道，如果使用 Exactly Once，消息的 Transaction Commit 和 Checkpoint 的生成是息息相关的。只有当 Checkpoint 生成的时候，才会把消息 Transaction Commit 到 Kafka 上，所以时效性也跟 Checkpoint 的速度或者 Checkpoint 间隔的大小紧密相关，我们也对此进行了一些针对性的优化。不同于一般情况下的 Hadoop 生态系统，Hadoop 在 HDFS 做 Checkpoint。在我们这个应用场景下，我们使用的是 AWS 的 S3 存储。Flink on S3 的 Checkpoint，我们是对于这个场景进行一些深度的优化。除了时效性以外，我们在稳定性方面也解决了一些问题。比如在比较大的被压场景下，可能会有 Checkpoint 过于缓慢，甚至 Kafka Transaction 失效的问题；在 Flink 1.14 版本，Kafka 的 Producer 可能有 Transaction ID 重用的问题；在同时使用 Transaction，也就是 Exactly Once 和流批一体的时候，面临了这两者不是百分百兼容的问题；比如 Checkpoint 和 Transaction Commit 紧密的关系，在 Batch 的情况下我们没有 Transaction 的概念，需要对算子的内部情况和整体的 Flush 做一些特殊的处理。在这套系统上线后，我们成功的支持了 20 亿/秒的指标生成，2 分钟左右的端到端延迟，数据取用方面毫秒级响应。第二个场景是广告曝光监控，主要面向的是用户方和广告主。广告主在签订广告合同的时候，通常会有一些定向投放的限制，比如我是一个母婴用品的广告，那就希望投放的人群是妈妈或者女性，还会有一些动态的规则，比如在投放次数上，不希望在同一时间内投放给同一个用户超过多少次；或在同一个用户的会话窗口下，不希望跟竞品广告出现在一起等等需求。因此我们研发了广告曝光的监控平台，广告主可以在我们的广告曝光监控平台上看到自己广告投放的一些信息。比如广告的投放区域、面向人群、或者当更改了一些定向规则后，广告服务器有没有反映出这些变化等等需求。那么广告监控具体是如何实现的呢？首先从我们的系统和客户端收集到一些广告选择的上下文信息、用户和广告的一些交互信息到消息队列中。然后使用 Flink 进行流和流的 join，再加上维度表做维度的增强，从而生成了一系列的事实指标。这些事实指标可以包括广告的曝光、独立访客的数量、用户观看频率等等。基于这些基础的事实指标和一些特定的广告业务规则，我们计算出一些衍生指标，比如广告投递的状况。在离线我们也生成了一些，可能实时比较不容易生成的指标，比如特别多维度的 UV 指标等等。我们把这一系列的指标，统一通过我们的数据接口向外暴露。这个数据呢，一方面给前端使用，另一个方面也会被广告系统使用。我们现在的广告系统，更多的是由基础和简单的广告曝光计数器和算法，来控制广告投放的速率。如果我们使用有更加丰富维度的曝光信息，可以支持 AB 测试、更加细腻的广告曝光速率控制等场景。所以在整个数据链路中，我们最关心的就是数据的可用性。对于数据可用性我们主要做了两点。尝试让 Flink 和我们正在使用的一个元信息系统进行打通，然后我们的其他应用，比如 Spark，Hive 等应用就可以直接使用 Flink 生成的数据了。我们提供了一个统一的指标接口。那么不同的下游、前端、后端就可以灵活取用我们的指标了。第三个场景是广告系统大屏。前两个场景更多的是关注某一个广告投放的一个局部，而广告系统大屏更多的是面向管理层，需要对广告系统和广告投放有一个全局的洞察力。我们使用 Flink 对一些数据源进行处理，然后通过指标接口暴露出来，再基于不同的业务规则，每 5 分钟、每小时、每天的批式处理，最终投放给前端做广告实时大屏展示。三、实时平台构建我们的 Flink 实时平台是基于云上开发的，使用 K8s 作为容器的管理系统，Flink Operator 管理 Flink 集群。我们自己研发了 Job submitter 的角色去帮助用户，让他们以自己熟悉的姿势去提交 Flink 任务。对于在计算平台出现的一些经典问题，我们也都一一解决了。比如当集群资源有限的情况下，有很多大任务，且每个任务都需要大量的资源，我们同时提交每个任务都能拿到一定的资源，但都没能拿到应该拿到资源的时候，会造成任务和任务之间的互锁，这个时候我们使用了 Gang scheduler 就可以将其解决。除此之外我们还进行了流批作业混部，这样可以最优化资源的利用率。为了利用云上弹性缩扩容的能力，我们主要创建了三种类型的队列。常驻任务队列，它主要面向 Flink Streaming 这样的任务，这样的任务通常它的资源使用更加趋于稳定。所以我们为它主要选择了 Reserved 节点，以一个更长的租期去租用这些设备，然后达到更低的使用费率。批处理任务队列，它主要面向 Flink Batch，Spark Batch 这样的任务。我们主要使用 On demand 节点，以保证我们对 SLA 的要求。临时任务队列，它主要面向一些低优先级的任务。我们主要使用 Spot 计算节点，这个节点有比较低 SLA 保证。比如在任务运行的过程中，Spot 节点可能会随时撤出，在每次取用 Spot 节点时，也不能完全满足即取即用的需求，因此我们用 SLA 换取了一个更低的费率。总体来说，这个计算平台也是根据我们不同队列的一个负载去进行一个弹性的一个扩/缩容。对于用户侧，我们也有相应的平台，比如任务管理、任务详情，可以让用户看到提交到实时平台上的任务状况。除此之外还提供了日志的管理系统，包括日志搜集、日志查询，满足用户 debug 的需求。当然我们也有给运维同学的一些平台，比如集群总体指标查看平台以及对每一个任务运行情况、任务指标查询的窗口。四、未来展望我们非常关注 Flink 社区的一些技术发展。Flink 未来在我们产品上的一些实用场景，可以归纳为以下几个方面。全流批一体。目前 Flink 在我们产品上的使用只在局部环节，主要是一些实时 KPI 的生成，这造成了在存储和计算上的资源浪费。因为我们不得不借助 Lambda 的结构来保证流批之间数据的一致性。如果能借助流批一体，希望可以降低我们在存储和计算上的双重成本。OLAP。目前我们的实时 KPI 返回还是有单独的 OLAP 引擎，未来希望可以通过统一引擎来提高我们开发的效率。实时归因。对于广告来说，归因是非常重要的一个环节。目前我们所有的归因都还是离线来实现的，但从业务需求上，我们希望能够更快的知道用户转化的原因，所以利用 Flink 在实时归因上对我们也非常重要。流式机器学习。在数据平台和计算引擎全部迁到实时计算上后，我们也很想尝试流式机器学习。包括在线特征提取、在线模型训练等等。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-13
Apache Flink 社区 2022 年度报告：Evolution, Diversity, Connection
2022 年悄然落幕，Apache Flink 社区又迎来了蓬勃发展的一年。社区共发布了 2 个 Flink 主版本，孵化出了新的流批一体表格存储项目，举办了 13 场线上线下活动，包括分别面向亚洲（北京）和欧美（旧金山）的 2 次 Flink Forward 大会，并向开发者推送了 100+技术文章，围绕实时湖仓、实时风控、数据集成、流批一体等核心场景进行了深度技术解读和最佳实践的传递，呈现出了一个不断繁荣的开源、开放的开发者社区。期待在 2023 年能与全球开发者共同努力，一起推动 Flink 社区在全球化生态市场中获得更大的成功。接下来，我们将通过 Evolution、Diversity、Connection 三个关键词，从年度最佳实践、核心技术演进、开源技术生态等多维度盘点过去一年的成果，与各位开发者一同见证社区成长。业界年度奖项我们一同见证了 Flink 开源项目的技术创新与高速发展。Flink 连续两年蝉联 Apache 软件基金会财年报告最活跃项目，用户交流程度、开发活跃度、影响力等多项指标，在整个 Apache 软件基金会的社区中名列前茅。在工信部电子标准院开源项目成熟度评估中获得“优秀一级”评级，并收获了 Segmentfault 思否、CSDN、IT168 等行业媒体赞誉。 感谢各位开发者、用户、行业媒体、权威机构的支持和认可，相信 2023 年 Flink 社区将会取得更大的成绩！社区精华内容2022 年发版回顾官宣｜Apache Flink 1.16 发布公告 Apache Flink Table Store 0.2.0 发布 Flink CDC 2.3 发布，持续优化性能，更多连接器支持增量快照，新增 Db2 支持 Apache Flink ML 2.1.0 发布公告 年度最佳实践美团基于 Flink 的实时数仓平台建设新进展 钱大妈基于 Flink 的实时风控实践流批一体在京东的探索与实践 Flink 在米哈游的落地实践 基于 Flink 构建大规模实时风控系统在阿里巴巴的落地 核心技术演进FFA 2022 主会场 Keynote：Flink Towards Streaming Data WarehouseFlink 1.15 新功能架构解析：高效稳定的通用增量 CheckpointFlink 1.16：Hive SQL 如何平迁到 Flink SQLFlink 大规模作业调度性能优化基于 Flink CDC 实现海量数据的实时同步和转换基于 Apache Flink Table Store 的全增量一体实时入湖Flink ML API，为实时机器学习设计的算法接口与迭代引擎开源技术生态Apache Flink 不止于计算，数仓架构或兴起新一轮变革 “后 Hadoop 时代”，大数据从业者如何应对新技术趋势带来的挑战? 投入上百人、经历多次双 11，Flink 已经足够强大了吗？ 5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布 关于 Apache Flink 和实时计算的最新动态、未来方向，你想知道的都在这里更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-12
PyFlink 最新进展解读及典型应用场景介绍
摘要：本文整理自阿里巴巴高级技术专家付典，在 FFA 核心技术专场的分享。本篇内容主要分为四个部分：PyFlink 发展现状介绍PyFlink 最新功能解读PyFlink 典型应用场景介绍PyFlink 下一步的发展规划点击查看直播回放 & 演讲PPT一、PyFlink 发展现状介绍很多 PyFlink 的新用户都会问这样一些问题，PyFlink 是否成熟？功能是否齐全？性能怎么样？在这里，我们针对用户的这样一些问题，进行一个详细的解读。首先，在功能层面，PyFlink 已经对齐了 Flink Java API 中的绝大多数功能。用户使用 Java API 可以实现的功能，基本上都可以用 Python API 实现得出来。同时，PyFlink 还面向 Python 用户提供了很多特有的能力，比如说 Python UDF、Pandas UDF 等，允许用户在 PyFlink 作业中使用各种 Python 三方库。在部署模式上，PyFlink 支持各种常见的部署模式，比如说 YARN、kubernetes、Standalone 等，这意味着用户可以根据需要，灵活地选择作业的部署模式。除了功能层面之外，性能也是很多用户非常关心的。在性能上，PyFlink 也做了很多优化，首先，在执行计划层面，PyFlink 做了一系列的优化，尽可能优化作业的物理执行计划，比如算子融合。当作业的物理执行计划确定之后，在 Python 运行时，PyFlink 通过 Cython 实现了 Python 运行时中核心链路的代码，尽量降低 Python 运行时中框架部分的开销。对于 Cython 有所了解的同学应该知道，Cython 在执行时会被编译成 native 代码来执行，性能非常高。同时，PyFlink 还在现有的进程模式的基础之上，引入了线程执行模式，以进一步提升 Python 运行时的性能。线程执行模式在 JVM 中执行用户的 Python 代码，通过这种方式，在一些典型应用场景中，性能甚至可以追平 Java，这一块后面我们还会详细介绍。经过这一系列的优化之后，目前 PyFlink 无论在功能上还是在性能上，都已经基本完备，达到了生产可用的状态。PyFlink 达到目前这样一个状态，并不是一蹴而就的，从 Flink 1.9 开始引入 PyFlink，到目前为止，PyFlink 已经累计发布了 8 个大版本，20 多个小版本。从 Flink 1.9 到 Flink 1.11 这几个版本中，我们重点在完善 Python Table API，基本上对齐了 Java Table API 中的绝大多数功能，同时也支持了 Python UDF、Pandas UDF 等功能。在 Flink 1.12 至 Flink 1.14 版本中，社区主要是在完善 Python DataStream API，目前已经基本上对齐了 Python DataStream API 上的绝大部分常用功能。在 Flink 1.15 至 Flink 1.16 版本中，PyFlink 的重点是在性能优化上，在原有的进程执行模式的基础之上，为 Python 运行时引入了线程执行模式，以进一步地提升 Python 运行时的性能。随着 PyFlink 功能的逐渐完善，我们也看到 PyFlink 的用户数也在逐渐增长，PyPI 的日均下载量在过去一年也有了显著的增长，从最开始的日均 400 多次，已经增长到日均 2000 多次。二、PyFlink 最新功能解读接下来，我们看一下 PyFlink 在 Flink 1.16 中的功能。PyFlink 在 Flink 1.16 中支持的功能主要是围绕使 PyFlink 在功能及性能上全面生产可用这样一个目的。为此，我们重点补齐了 PyFlink 在功能以及性能上的最后几处短板。如上图所示，PyFlink 在 Flink 1.16 中支持了 side output 功能。用户可以把一条数据流，切分成多条数据流。以机器学习为例，用户可以通过该功能，把一份数据集给切分成多份，分别用于模型训练和模型验证。除此之外，用户也可以通过 side output 处理迟到数据或者脏数据。将迟到数据或者脏数据通过 side output 拆分出来，单独进行处理。用户也可以通过 side output 把迟到数据或脏数据，写入外部存储，进行离线分析。PyFlink 在 Flink 1.16 中，还支持了 broadcast state。通过该功能，用户可以将一条数据流中的数据，广播发送到另一条数据流算子中的多个并发实例上，并通过 broadcast state 保存广播流的状态，以确保作业在 failover 时，所有算子恢复的状态是一致的。比如我们用 PyFlink 做近线预测，当模型更新后，可以将最新的模型文件地址，广播发送到所有的预测算子，来实现模型的热更新，并通过 broadcast state 确保在作业 failover 时，所有算子加载的模型文件是一致的。PyFlink 在 Flink 1.16 中，对于 DataStream API 上 Window 的支持也做了很多完善，原生支持了各种窗口，比如滚动窗口、滑动窗口、会话窗口等等。Window 可以将无限流中的数据，划分成不同的时间窗口进行计算，在流计算中是非常重要的功能，有着非常丰富的应用场景。比如机器学习用户可以使用 Window 来计算实时特征。在短视频应用中，可以通过 Window，计算用户最近五分钟的有效视频观看列表，也可以通过 Window，来计算最近 30 分钟，某个视频在各个人群中的点击分布等。除此之外，在 Flink 1.16 中，PyFlink 还新增了对于很多 DataStream API 上 connector 的支持，包括 Elasticsearch、Kinesis、Pulsar、Hybrid source 等。与此同时，也支持 Orc、Parquet 等 format。有了这些 connector 以及 format 的支持，PyFlink 基本上已经对齐了所有 Table API 以及 DataStream API 上 Flink 官方所支持的 connector。需要说明的是，对于 PyFlink 中没有原生提供支持的 connector，如果有对应的 Java 实现，也是可以在 PyFlink 作业中使用的，其中 Table API 以及 SQL 上的 connector，可以直接在 PyFlink 作业中使用，不需要任何开发。对于 DataStream API connector，用户只需要非常少量的开发即可在 PyFlink 作业中使用。如果用户有需求的话，可以参考一下 PyFlink 中现有的 DataStream API connector 是如何支持的，基本上只需要一两个小时即可完成一个 connector 的支持。除了前面介绍的这些功能层面的增强之外，在性能层面，Flink 1.16 也做了很多工作，基本完成了 Python 运行时线程执行模式的支持。相比于进程执行模式，线程执行模式的性能更好。线程执行模式通过 JNI 调用的方式，执行 Python 代码，节省序列化/反序列化开销及通信开销。特别是当单条数据比较大时，效果更加明显。由于不涉及跨进程通信，线程执行模式目前采用同步执行的方式，不需要在算子中进行攒批操作，没有攒批延迟，适用于对延迟敏感的场景，比如量化交易。与此同时，与其他 Java/Python 互调用方案相比，PyFlink 所采用的方案兼容性更好。很多 Java/Python 互调用方案对于所能支持的 Python 库，都有一定程度的限制。PyFlink 所采用的方案，对于用户在作业中所使用的 Python 库没有任何限制。如上图左侧所示，展示了进程模式和线程模式架构的区别。进程模式需要启动一个独立的 Python 进程，用于执行用户的 Python 代码。线程执行模式在 JVM 中，通过 JNI 调用的方式执行 Python 代码。PEMJA 是 PyFlink 中 Java 代码和 Python 代码之间互调用的库。如上图右侧所示，在处理时延上，相比于进程模式，线程模式有显著的降低。因为进程模式不需要攒数据，来一条处理一条。与此同时，在处理性能上，线程模式相比进程模式也有较大的提升，在某些情况下，性能甚至可以追平 Java。这里需要说明的是，Python UDF 的执行性能既取决于 PyFlink 执行框架的性能，也跟 Python UDF 的实现是否高效息息相关。通过各种优化手段，目前 PyFlink 执行框架的性能已经非常高效，开销非常小。用户的 PyFlink 作业的执行性能很大程度取决于，用户作业中的 Python UDF 实现得是否高效。如果用户的 Python UDF 实现得足够高效，比如说实现的过程中针对一些耗时操作，有针对性地进行来一些优化或者利用一些高性能的 Python 三方库，那么 PyFlink 作业的性能其实是可以实现的非常好的。三、PyFlink 典型应用场景介绍接下来，讲一讲 PyFlink 的应用场景。目前，实时机器学习是 PyFlink 用户的重点应用场景。以推荐系统为例，上图是实时推荐系统的一个典型架构。用户的行为日志，通过 APP 埋点等手段，实时采集到消息队列中，经过实时数据清洗，归一化处理之后，在特征生成、样本拼接等模块使用。实时的用户行为日志，可以用来计算实时特征。首先，实时用户行为日志可以被用来计算实时特征。实时特征是 Flink 非常重要的应用场景。实时特征对于推荐效果的提升非常明显，建设难度相对来说比较小，是当前很多公司投入的重点。比如在短视频应用中，用户最近 N 分钟的有效视频观看列表就是短视频应用中，非常重要的用户实时特征。这个特征可以通过一个 Flink 作业，实时分析用户的行为日志得到。一般来说，用户的行为日志还会同步一份到离线存储中，用于生成离线特征。这块主要是用于计算一些复杂特征或者是说长周期特征。不管是离线特征还是实时特征，最终都会存储到特征库中供在线推荐系统使用。实时的用户行为日志不但可以用来构造实时特征，而且可以用来构造实时样本，用于模型训练。通过分析用户的行为日志，可以自动完成对样本打标签。比如在推荐系统中，给用户推荐了 10 个 item，如果用户点击了某个 item，那么在行为日志中就会出现这个 item 的点击事件。有了这个点击事件，我们就可以得到一条正样本。同理，如果对于某个 item，只有曝光事件，没有点击事件，我们就可以将其看成是一条负样本。除了区分正负样本之外，还需要拼接上用户的特征以及 item 的特征之后，才能得到一条完整的样本。这里需要注意的是，做样本拼接时所用的特征不是来自于实时特征库，而是来自于历史特征库。由于实时特征库中的特征是不断更新的，比如在短视频应用中，用户最近 N 分钟的视频点击列表特征，随着时间的推移，在不断发生变化。因此在样本拼接时，我们希望拼接推荐发生时所用到的特征，而不是当前时刻的特征。样本拼接可能发生在推荐事件过去一段时间之后，此时在实时特征库中存储的特征可能已经发生了变化，因此这里拼接的是历史特征库。因为历史特征库中的数据来自于推荐发生时所用到的特征。样本经过训练之后，最终生成模型。经过验证，如果没有问题，就可以把模型部署到线上，供在线推理服务使用。在推荐系统中，在线推理服务包括召回、排序等多个环节。其中，在召回环节使用比较广泛的一种手段是多路召回技术，每一路召回使用不同的策略。比如说可以根据用户画像、当前的热点内容、运营策略等，分别生成不同的召回结果。对于这些召回结果，合并之后，再经过排序等环节之后展示给用户。由此可见，多路召回的好处是显而易见的。通过多路召回，可以增强推荐结果的多样性。这里需要指出的是，由于推荐系统对于延时比较敏感，对于召回策略或者模型的性能要求非常高。因此，召回中使用的模型或者策略一般都比较简单。目前一些公司也在探索，在多路召回系统中引入近线召回。近线召回可以预先计算召回结果，并将召回结果缓存，作为多路召回中的一路，供在线推理服务直接使用。因此近线召回没有时延约束，用户可以在近线召回中使用一些比较复杂的模型或者策略。接下来，介绍一下在上述步骤中，如何使用 PyFlink 完成各项功能的开发。在实时数据清洗部分，机器学习应用中，输入数据中往往包含很多列。Flink 的其他功能也可以用于数据清洗，比如 SQL。SQL 本身也是非常方便的，那么和 SQL 相比，PyFlink 可以提供哪些附加价值呢？首先，在机器学习场景中，普遍有一个共性的特点，数据中的列非常多，可能有几十列甚至上百列。在这种情况下 SQL 语句可能写起来非常长，比如在这个例子中，用户可能希望对第 9 列和第 10 列进行一个合并操作，其他列保留。但是在 SELECT 语句中，需要把所有的其他的无关列都写出来，如果数据中的列非常多，写起来非常繁琐，同时可读性、可维护性也会变得比较差，PyFlink 对于这块提供了完善的支持。另外，机器学习用户通常对于 Pandas 比较熟悉，习惯于使用 Pandas 进行数据处理，很多机器学习相关的库的数据结构都是采用 Pandas 或者 Numpy 的数据结构，PyFlink 在这块也提供了很好的支持，支持用户在 Python UDF 的实现中使用 Pandas 库。接下来，我们通过几个具体的例子看一下如何在 PyFlink 中使用上述功能。首先，PyFlink 提供了行操作和列操作的 API，从而简化用户的代码逻辑。通过列操作，用户可以非常方便的增加列、删除列或替换列。列操作适用于输入数据的列很多，且只有个别列发生变化的场景。比如在上述例子中，我们通过 add_or_replace_columns 操作，对数据中的 item_id 一列进行归一化后，替换原有的 item_id 列，数据中的其他列不需要再显式列出来。除了列操作之外，PyFlink 还支持行操作，可以以行为单位对数据进行变换。在行操作的 UDF 中，可以直接通过列名引用对应列，使用起来非常方便，适用于输入数据中的列很多，且需要对多个列进行处理的场景。在行操作中，不需要在 UDF 的输入参数中，把所有用到的列都显式列出来，而是把一行数据都作为输入传进来，供 UDF 使用。在上述例子中，我们通过 map 操作对数据进行变换，map 的输入是一个 Python 函数，Python 函数的输入输出类型都是 Row 类型，Row 是 PyFlink 中定义的一个数据结构，在 Python 函数的实现中可以通过列名引用输入数据中对应列的值，使用起来非常方便。除了 map 之外，PyFlink 中还提供了多个行操作相关的 API，如果有需要的话，大家可以从 PyFlink 的官方文档中了解详细信息。如果用户熟悉 Pandas 库，也可以在 Python 函数中使用 Pandas 库。用户只需要将 Python 函数的类型，标记成 Pandas 即可。在这种情况下，Python 函数的输入类型是 Pandas 的 DataFrame。PyFlink 运行时框架会在调用用户的 Python 函数之前，将输入数据转换成 Pandas 的 DataFrame 结构，方便用户使用。除此之外，Python 函数的输出类型也需要是 Pandas DataFrame。接下来，我们看一下实时特征计算部分。当前有很多公司，开发一个实时特征任务的流程通常是这样的：首先，算法团队的同学通过数据挖掘等手段，发现某个特征会比较有用。然后，找到数据开发团队的同学，进行需求沟通。将特征的详细描述信息，甚至 Python 代码参考实现，提给数据开发团队的同学。然后，数据开发团队的同学进行需求排期并实现。在实现的过程中，算法团队的同学和数据开发团队的同学可能还需要进行多轮沟通，确保数据开发团队的同学的理解和实现没有问题。另外，算法团队同学提供的 Python 参考实现，有可能不太容易翻译成 Java 代码。比如里面用到了一些 Python 三方库，找不到合适的 Java 实现等等。最后，当特征任务开发好之后，算法同学经过一系列的验证，很有可能发现这个特征可能并没有预期中的效果那么好，这样的一个特征任务很可能就废弃了。数据开发团队的同学也白忙活了。从这个过程中，我们看到特征的开发成本是非常高的，涉及到跨团队的沟通、开发语言的转换，特征上线的周期也非常长，通常以周甚至月为单位。而 PyFlink 可以显著降低实时特征任务的开发门槛、缩短实时特征的上线周期。有了 PyFlink，算法团队的同学完全可以自己来开发实时特征任务。同时，在特征任务开发的过程中，可以使用各种 Python 库，没有任何限制。在推荐场景中，可能会用到这样一个特征，计算用户最近 5 分钟的访问物品列表。为此，PyFlink 提供了多种实现手段。首先，用户可以通过 SQL+Pandas UDAF 的方式来实现上述功能。上述 SQL 语句定义了一个长度为 5 分钟、步长为 30 秒的滑动窗口，针对窗口中的数据，定义了一个 Pandas UDAF 来计算用户在这个窗口中的访问序列。Pandas UDAF 的主要逻辑是对窗口中用户访问的 item 进行排序，并使用｜作为分隔符，生成访问序列字符串。除此之外，用户可以通过 DataStream API 计算序列特征，实现上述功能。通过使用 DataStream API，定义了一个窗口大小为 5 分钟、步长为 30 秒的滑动窗口，并定义了一个聚合函数来处理每一个窗口中的数据。聚合函数需要实现 create_accumulator、add、get_result、merge，定义如何针对窗口中的数据进行聚合运算。针对窗口中的每一条数据，框架会依次调用聚合函数的 add 方法，当窗口中所有的数据都处理完后，框架会调用聚合函数的 get_result 方法来获得聚合值，因此用户只需要根据业务逻辑的需要实现这几个方法即可。在 add 方法中，我们将数据缓存起来，在 get_result 中对于所有数据进行排序，并以｜作为分隔符，生成访问序列字符串。接下来，我们来看一下实时样本生成部分。在实时样本生成部分，主要有正负样本判断和特征拼接。首先，我们看一下正负样本的构造。在推荐场景中，当给用户推荐了一批 item 之后，如果用户点击了某个 item，就会成为一个正样本，而如果用户没有点击，则成为一个负样本。在离线场景中，判别正负样本是非常容易的，而在实时场景中，就不那么容易了。给用户展现了某个 item 之后，用户有可能不点击，也有可能隔了很久之后才点击。在 Flink 中，用户可以通过定时器解决正负样本问题。针对每条曝光事件，用户可以注册一个定时器。定时器的时间间隔，可以根据业务的需要确定。在这个例子中，我们定义了一个 10 分钟的定时器。在 10 分钟内，如果收到了这条曝光事件对应的点击事件，则可以将其看成是一个正样本，否则，如果在 10 分钟内还没有收到对应的点击事件，则可以将其看成一个负样本。正负样本的问题解决了之后，样本的标签也就确定了，接下来，还需要拼接上推荐发生时所用到的特征，才能成为一条完整的样本。这里，我们可以使用 Flink 中的维表 Join 功能，来进行特征的拼接。为了解决特征穿越问题，也就是说在拼接用户的实时特征时，用户的实时特征相比推荐发生时可能已经发生了变化，前面我们提到，在线推理服务在推荐时，可以将所用到的实时特征保存到历史特征库中。为了便于区分特征的版本，可以给特征加一个唯一的标识，比如 trace_id，然后在做特征拼接时，通过 trace_id 来定位推荐发生时所使用的特征，解决特征穿越的问题。接下来，我们来看一下近线推理。近线推理是非常典型的应用场景。目前，很多用户在用 PyFlink 做近线推理。首先，用户可以通过 Table API 做近线推理。在 Table API 里，用户可以通过 Select 语句做近线推理。推理逻辑可以封装在用户的自定义函数中。在自定义函数里，用户可以通过 open 方法，加载机器学习模型。open 方法只会在作业启动阶段调用一次，因此可以确保机器学习模型只 load 一次。实际的预测逻辑可以定义在 eval 方法中。除了 Table API 之外，用户也可以通过 DataStream API 做近线推理。跟 Table API 类似，DataStream API 中的自定义函数中也提供了一个 open 方法。用户可以在 open 方法里，加载机器学习模型。使用方式跟 Table API 比较像，用户可以根据自己的需求，选择使用 Table API，还是 DataStream API。除此之外，用户可以通过 timer 提升推理的时效性。在某些场景中，为了提高时效性，可以通过定时器来做周期性推理。该方法适用于活跃用户的范围比较确定，且用户访问比较频繁的场景。在这些场景中，可以针对活跃用户，或者圈选一批重点用户，周期性地进行近线推理，以进一步提升推荐效果。在这里，我们每 5 分钟对于活跃用户进行一次近线推理。某些公司可能是 Java 技术栈。算法团队训练出模型之后，由开发团队再去负责部署使用。在这种情况下，用户可能会倾向于使用 Flink 的 Java API 进行预测。在 PyFlink 支持线程模式的过程中，抽象出了一个 library PEMJA，支持 Java 和 Python 之间的互调用，跟其他的 Java/Python 互调用库相比，PEMJA 的性能更好，并且对于各种 Python 库的支持也比较好，兼容所有的 Python 库。这个例子展示了如何利用 PEMJA 提供的 API，在 Flink Java 作业中加载机器学习模型、并进行预测。从这个例子可以看出，通过 PEMJA，用户可以在 JAVA 代码中调用并执行 Python 代码。四、PyFlink 下一步发展规划接下来，PyFlink 的建设重点，会逐步从功能以及性能，转向易用性、稳定性以及文档，帮助用户更好的使用 PyFlink。我们接下来会重点完善以下几个方面。首先，由于当前 PyFlink 的端到端示例相对来说还比较少，不利于新用户快速上手。接下来，我们会建设一个独立的 PyFlink 网站，结合具体场景，展示更多的端到端使用示例。其次，在易用性方面，接下来会重点优化作业执行过程中的报错提示，让报错信息更友好，使用户在开发作业的过程中更容易定位问题。与此同时，我们也在重构当前 Python API 的文档。这块主要是参考一些其他成熟的 Python 项目的经验，比如 Pandas。使得用户在 Python API 文档中，更容易找到 PyFlink 中各个 API 的使用方式。最后，作业运行的稳定性也非常重要。我们也会持续改进并加强 PyFlink 作业运行的稳定性，比如降低 PyFlink 作业在进程模式下 checkpoint 的耗时等。最后，也欢迎大家加入 【PyFlink 交流群】交流和反馈 PyFlink 相关的问题和想法。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-10
Flink 批作业的运行时自适应执行管控
摘要：本文整理自阿里云高级技术专家朱翥，在 FFA 核心技术专场的分享。本篇内容是关于在过去的一年中，Apache Flink 对运行时的作业执行管控进行的一些改进。这些改进，让 Flink 可以更好的利用运行时的信息，来灵活的控制作业的执行，从而使得 Flink 批处理作业的执行可以更加的稳定、更有效率，并且更容易运维。详细内容主要分为两个部分：自适应执行计划同源实例的并行执行点击查看直播回放 & 演讲PPT一、自适应执行计划我们先看一下，Flink 是如何描述作业的执行计划的。以这个 DataStream 作业为例，Flink 会基于它先生成一个 StreamGraph。这是一个有向无环图，图中的节点对应着计算逻辑，图中的边则对应着数据的分发方式。Flink 会根据节点的并行度以及他们之间的连边方式，把一些计算节点进行链接合并，最终形成 JobGraph，从而降低计算节点间的数据传输开销。这个操作的目的是，是为了降低计算节点之间的数据传输开销。StreamGraph 和 JobGraph 都是在编译阶段生成的。JobGraph 会提交给 Flink Job Manager，从而启动和执行作业。在执行作业前，Flink 会生成 ExecutionGraph。这个 ExecutionGraph 是根据 JobGraph 中的节点并行度，展开生成的。 我们知道，Flink 是一个分布式计算框架。而 ExecutionGraph 的每一个节点，都对应着一个需要部署到 TaskManager 上进行执行的任务，每一条边都对应着任务的输入和输出。所以说，它是作业的物理执行计划。这个物理执行计划，描述了任务的计算逻辑、所需资源和并行度，同时也描述任务产出数据的划分方式，此外还描述了任务对数据的依赖关系以及数据传输方式。通过它，Flink 就能知道如何创建和调度作业的所有任务，从而完成作业的执行。但是，如前面所说，它是在作业运行前就已经确定的，是静态的。而 Flink 难以在作业执行前，预判什么样的计划参数更合理。所以，这些执行计划参数，只能依赖用户提前指定，也就是需要手动调优。然而，对于批作业，由于其分阶段执行的特性，在执行一个阶段前，理论上 Flink 是可以获得很多有用的信息的，比如其消费的数据量大小、这些数据的分布模式、当前的可用资源等等。基于这些信息，我们可以让 Flink 对执行计划动态的进行调优，从而获得更好的执行效率。并且，由于 Flink 可以自动的进行这些调优，也可以让用户从手动调优中解放出来。这就是 Flink 批处理作业的自适应执行计划。为了支持自适应执行计划，最核心的一点，是需要一个可以动态调整的执行拓扑。所以，我们改造了 ExecutionGraph，使其支持渐进式构建。具体的来说，就是让 ExecutionGraph 一开始只包含 Source 节点，随着执行的推进，再逐渐的加入后续的节点和连边。这样，Flink 就有机会对尚未加入的执行节点和连边进行调整。但在这个地方，我们遭遇了一个阻碍。因为在原来的作业执行中，上游节点执行是依赖于下游节点的并行度的。具体来说，是因为上游在产出数据时，会根据下游并行度，对数据进行划分（sub-partition）；这样，每个下游任务就可以直接消费其对应的那一个数据分区。然而，在动态执行计划的场景下，下游节点的并行度是不确定的。为了解决这个问题，我们改造了节点数据的划分逻辑，使其不再根据下游节点的并行度，而是根据其最大并行度进行划分。同时，我们也改造了节点消费数据的逻辑，使其不再只消费单一分区，而是可以消费一组连续的数据分区（sub-partition range）。通过这样的方式，上游节点执行得以和下游节点的并行度解耦，动态执行拓扑也得以实现。在支持了动态执行拓扑后，我们引入了 Adaptive Batch Scheduler 来支持自适应执行计划。与原有调度器不同的地方在于，Adaptive Batch Scheduler 会基于动态执行拓扑进行作业管控，持续收集运行时的信息，定制后续的执行计划。Flink 会基于执行计划，动态生成执行节点和连边，以此来更新执行拓扑。在上述框架下，我们为 Flink 增加了自动决定并行度的能力。用户只需要配置希望单个执行节点处理的数据量， Flink 就可以根据该阶段需要处理的数据量，自动推导该阶段的节点并行度。相比起传统的为每个作业单独配置并行度，自动决定并行度有这些优点：一是配置简单，无需为每个作业单独配置，一项配置可以适用于很多作业；二是可以自动的适配每天变化的数据量，当数据量较大时，作业并行度可以大一些，从而保障作业的产出时间；三是可以细粒度的调整作业的并行度，提高资源利用率。但是自动决定并行度，数据可能分布不均。为了解决这个问题，我们在自动决定并行度的基础上，进行了自动均衡下发数据的改进。这个改进会采集 sub-partition 粒度的数据量，并以此来决定执行节点的并行度，以及每个执行节点应该消费哪些分区数据。从而尽可能让下游各执行节点消费的数据，接近用户配置的预期值。相比起自动决定并行度，这样的方式不但让下游数据量更均衡，而且能够缓解数据倾斜的影响。这个功能正在开发中，会随着 Flink 1.17 发布。以上就是我们当前已经或是即将在 Flink 中完成的自适应执行计划的改进。不过，自适应执行计划还有更大的改进空间，比如根据 join 算子实际消费的数据量，动态决定应该用 hash join 还是 broadcast join；支持选择性执行任务，在满足特定条件下，为作业加入额外的执行分支；在 Sink 输出结果达标时提前结束作业。此外，我们也在考虑 SQL 的动态优化能力。当前，SQL 的查询优化是在作业编译时进行的；其只能通过 Source 的 Meta 信息，对数据量进行估算，容易导致优化结果不准确。如果可以向 SQL planner 反馈运行时信息，来动态的优化执行计划，就可以得到更好的执行效果。二、同源实例的并行执行接下来，讲一讲同源实例的并行执行。同源实例是指，属于同一个执行节点的执行实例。执行拓扑是由执行节点组成，各节点会创建执行实例，将其部署到 TaskManager 上进行执行。当前，每个执行节点在某一时刻只能有一个执行实例，只有当该实例失败(或被取消)后，节点才会创建一个新的执行实例。这也意味着，同源执行实例只能串行执行。驱动我们更改这一现状的，是来自预测执行的需求。在生产中，热点机器是无法避免的，混部集群、密集回刷，都可能导致一台机器的负载高、IO 繁忙。其上执行的数据处理任务可能异常缓慢，导致批作业产出时间难以得到保障。预测执行，是一种已经得到普遍的认可、用来解决这类问题的方法。其基本思路是，为热点机器上的慢任务创建新的执行实例，并部署在正常的机器节点上。这些预测执行实例和对应的原始实例，具有相同的输入和产出。其中，最先完成的实例会被承认，其他相应实例会被取消。因此，为了支持预测执行，Flink 必须支持多个同源实例并行执行。为了支持同源实例并行执行，我们进行了下列改进。首先，我们重新梳理了执行节点的状态。当前，执行节点的状态和其当前唯一执行实例是一一对应的。然而，如果一个节点可以同时存在多个执行实例，这样的映射方式就会出现问题。为此，我们重新定义了执行节点与执行实例的状态映射，取执行实例中最接近 FINISH 状态的状态作为执行节点的状态。这样既可以兼容单执行实例场景，也能支持多个同源实例并行执行的场景。其次，我们保证了 Source 的同源执行实例，总是会读取到相同的数据。大体上来说，就是我们在框架层为每个 Source 执行节点增加一个列表，来维护分配给它的数据分片。该节点的所有执行实例都会共享这一个列表，只是会各自维护一个不同的下标，来记录其处理到的数据分片进度。这样的改动的好处是，大部分现有 Source 不需要额外的修改，就可以进行预测执行。只有当 Source 使用了自定义事件的情况下，它们才需要实现一个额外的接口，用以保证各个事件可以被分发给正确的执行实例。在接下来的 Flink 1.17 中，我们也会支持 Sink 的同源执行实例并行执行。其关键点在于避免不同 Sink 之间的执行冲突，特别是要避免因此产生的数据不一致，因为 Sink 是需要向外部系统进行写入的。由于 Sink 的写入逻辑隐藏在各个 Sink 的实现中，我们无法像 Source 一样在框架层统一避免写入冲突。所以我们向 Sink 层暴露了执行实例标识（attemptNumber），使 Sink 可以自行避免冲突。同时为了安全起见，我们默认不会允许 Sink 的同源执行实例并行执行，除非 Sink 显式声明支持同源执行实例并行执行。在此基础上，我们为 Flink引入了预测执行机制。主要包括三个核心组件。首先是慢任务检测器。它会定期进行检测，综合任务处理的数据量，以及其执行时长，评判任务是否是慢任务。当发现慢任务时，它会通知给批处理调度器。其次是批处理调度器。在收到慢任务通知时，它会通知黑名单处理器，对慢任务所在的机器进行加黑。并且，只要慢任务同源执行的实例数量，没有超过用户配置上限，它会为其拉起并部署新的执行实例。当任意执行实例成功完成时，调度器会取消掉其他的同源执行实例。最后是黑名单处理器。Flink 可以利用其加黑机器。当机器节点被加黑后，后续的任务不会被部署到该机器。为了支持预测执行，我们支持了软加黑的方式，即加黑机器上已经存在的任务，可以继续执行而不会因为加黑被取消掉。除此之外，工作人员对外部 UI 进行改进，方便展示当前运行中的所有同源执行实例，用户可以更好的判断预测执行的执行结果。此外，我们对 WebUI 也进行了改进，使其能够展示当前运行中，或是作业结束时的所有同源执行实例，用户可以更好的判断预测执行的执行结果。此外，UI 也能展示被加黑的 Slot 和 TaskManager。需要说明的是，虽然出发点是支持批作业的预测执行。同源执行实例的并行执行，也为流作业的任务平滑迁移提供了可能。当流作业有任务落在慢机器上时，我们也可能先为其预先拉起一个同源执行实例，待该实例的部署和初始化完成后，通过直接切换数据连边，可以达成低断流的任务迁移。配合慢任务检测、黑名单等能力，我们甚至能让 Flink 自动的进行慢任务迁移。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2023-01-03
Flink 容错恢复 2.0 2022 最新进展
摘要：本文整理自阿里云 Flink 存储引擎团队负责人，Apache Flink 引擎架构师 & PMC 梅源在 FFA 核心技术专场的分享。主要介绍在 2022 年度，Flink 容错 2.0 这个项目在社区和阿里云产品的进展。内容包括：Flink 容错恢复 2.0 项目简介及思考2022 年度 Flink 容错 2.0 项目进展点击查看直播回放 & 演讲PPT一、Flink 容错恢复 2.0 项目简介及思考首先来概括的看一下 Flink 容错的链路，主要包括四个过程：做快照（Checkpointing），发现失败节点（Failure Detection），重新调度（Re-Scheduling）和状态恢复（State Recovery）。在一个 Flink 作业中，数据从数据源经过各个算子的处理最终写入 Sink。其中有些算子需要记录数据处理的中间结果，会暂时把中间结果缓存在算子内部，即算子的状态中。如果这个 Flink 作业因为各种原因出现失败或者错误，就需要重新恢复这些状态，因此我们需要对状态进行周期性快照，即 Checkpointing 过程。由于快照很频繁，所以需要 Checkpointing 过程稳定、轻量并保证成功。如果一个节点挂了，需要快速发现失败节点，并完成相应的清理工作。然后生成新的作业，并重新调度，完成部署。当作业重新调度之后，需要从最新的快照中恢复算子的中间状态，也就是 State Recovery 状态恢复。从上面的描述不难看出，容错恢复是一个全链路的过程，包括给状态做快照，发现节点失败，重新调度部署以及恢复状态。另一方面容错恢复也是个需要从多个维度来考虑的问题，包括容错成本、对正常处理的影响、数据一致性保证的程度、以及在整个容错恢复过程中的行为表现（比如是否需要满速 TPS 的保证和不断流的保证）等等。另外需要指出的是在云原生背景下，容器化部署带来了一些新的限制和便利，这些都是我们在设计新一代容错时不能忽视的地方。有关这个部分更详细的内容可以参考去年的 talk “Flink 新一代流计算和容错——阶段总结和展望”2022 年我们的工作主要集中在 Checkpointing，Scheduling 和 State Recovery 这三个部分。在 Checkpointing 这个部分，我们实现了分布式快照架构的升级：Flink 1.16 修复了和 Unaligned Checkpoint 相关的几个关键 bug，特别是 Unaligned 和 Aligned Checkpoint 之间转换这个部分，使得 Unaligned Checkpoint 可以真正做到生产可用；Flink 1.16 发布的一个重要 feature 是通用增量 Checkpoints，通过增量快照和 State Store 快照过程的分离，可以保证稳定快速的 Checkpointing 过程。这个后续我们会有相关 Blog Post 详细的分析通用增量 Checkpoints 在各种 Benchmark 下的各项指标以及适用场景。在 Scheduling 这个部分，Approximate 和 At-least-once 单点重启功能已经在阿里云实时计算企业级服务里实现，主要由阿里云实时计算 Flink Runtime 团队完成，他们还通过引入作业热更新功能，极大缩短了扩缩容的断流时间。这两个功能在阿里云实时计算 VVR 6.0.4 版本上线，欢迎大家试用。在 State Recovery 这个部分，社区在 1.15 引入了工作目录的概念，结合 K8S 的 PV 挂载，可以实现状态的本地恢复。为了适应云原生部署，我们在状态存储部分进行了分层存储架构升级，对恢复和扩缩容都有很大的改进。特别是 Lazy-Load 的引入，使得快速恢复不再受状态大小的影响，结合上面提到的作业热更新功能，基本可以做到扩缩容无断流。Lazy-Load 这个功能也已在阿里云 VVR 6.x 版本中上线。下面我主要从快照生成，作业恢复/扩缩容，快照管理这三个方面详细介绍 2022 年度 Flink 在容错部分的进展。二、2022 年度 Flink 容错 2.0 项目进展2.1 优化快照生成在快照生成部分，我们对 Flink 分布式快照架构进行了整体升级。先来看看升级前的架构有什么问题：问题 1：对齐时间长，反压时被完全阻塞Flink 的 Checkpoint 机制是通过从 Source 插入 Barrier，然后在 Barrier 流过每个算子的时候给每个算子做快照来完成的。为了保证全局一致性，如果算子有多个输入管道的时候，需要对齐多个输入的 Barrier。 这就产生了问题 1，因为每条链路的处理速度不一样，因此 Barrier 对齐是需要时间的。如果某一条链路有反压，会因为等待对齐而使得整条链路完全被阻塞，Checkpoint 也会因为阻塞而无法完成。问题 2：Buffer 数目固定，管道中有多余的处理数据由于算子间的上下游 Buffer 数目是固定的，它们会缓存比实际所需更多的数据。这些多余的数据不仅会在反压时进一步阻塞链路，而且会使得 Unaligned Checkpoint 存储更多的上下游管道数据。问题 3：快照异步上传时间较长且不可控快照的过程包括两部分：同步状态刷盘和异步上传状态文件，其中异步文件上传的过程和状态文件大小相关，时间较长且不可控。我们从 Flink 1.11 开始着手逐一的解决这些问题，如下图所示。Flink 1.11、 Flink 1.12 引入了 Unaligned Checkpoint， 使得 Checkpoint Barrier 不被缓慢的中间数据阻塞。Flink 1.13、Flink 1.14 引入了 Buffer Debloating，让算子与算子间的管道数据变得更少。Flink 1.15、Flink 1.16 引入了通用增量 Checkpoints，让异步上传的过程更快、更稳定。升级后的分布式快照架构如下图所示：对于问题 1，在 Flink 1.16 版本中，Unaligned Checkpoint 允许透支 Buffer，解决了在 Buffer 不足时，不能及时响应 Unaligned Checkpoint 的问题。 此外，全局计时超时机制的引入能够有效改进 Unaligned 和 Aligned Checkpoint 之间自动转换的触发条件。对于问题 2，Buffer debloating 的引入可以动态调整缓存的数据量，动态缓存 1 秒内需要处理的数据。下面我们来重点看一看第 3 个问题是如何用通用增量 Checkpoint 来解决的Flink 的算子状态更新会反映在状态表中。在之前的设计当中，Flink 算子做快照的过程分为两步：第一步是同步的对状态表进行快照，内存中的数据刷盘，准备好上传到持久存储的文件；第二步是异步的上传这些文件。异步上传文件这个部分有两个问题：问题 1：异步上传的文件大小依赖 State Backend 的实现问题 2：异步过程需要等到同步过程结束才能开始，因为同步快照结束前是没法准备好需要上传的文件的我们来分别看一下这两个问题。对于第一个问题，以 RocksDB 为例，虽然 Flink 对 RocksDB 也支持增量 Checpoint，但是 RocksDB 出于自身实现考虑，它需要对文件做 Compaction。每次 Compaction 会产生新的比较大的文件，那这个时候即使是增量 Checkpoint，需要上传的文件也会因此时不时变大。在 Flink 作业并发比较大的情况下，上传文件时不时变大的问题就会变得很频繁，因为只有等所有并发的文件上传完毕，一个完整的算子状态才算快照完成。对于第二个问题，在同步快照结束前，Flink 无法准备好需要上传的文件，所以必须要等快照结束时才能开始上传。也就是说，上图中的红色斜条纹这个时间段完全被浪费了。如果需要上传的状态比较大，会在很短时间内对 CPU 和网络产生较大的压力。为了解决上述两个问题，我们在 Flink 社区实现了通用增量快照。在新架构下，状态更新不仅会更新状态表，而且会记录状态的更新日志。上图中状态表会和架构升级前一样周期性的刷到持久存储，但是这个周期可以比较大（比如 10 分钟）在后台慢慢上传，该过程称为物化过程。同时状态更新日志也会持续上传到远端持久存储，并且在做 Checkpoint 时 Flush 剩余全部日志。这样的设计就比较好的解决了前面提到的两个问题：通过将快照过程和物化过程完全独立开来，可以让异步上传的文件大小变得很稳定；同时因为状态更新是持续的，所以我们可以在快照之前就一直持续的上传更新日志，所以在 Flush 以后我们实际需要上传的数据量就变得很小。架构升级后的一个 Checkpoint 由物化的状态表以及增量更新的日志组成。物化过程结束后，相对应的更新日志就可以被删除了。上图中的蓝色方框部分，是通用增量快照和之前架构的区别，这个部分被称为 Changelog Storage（DSTL）。DSTL 是 Durable Short-term Log 的缩写。我们从这个英文名就能看出来 DSTL 是有针对性需求的需要短期持久化增量日志，物化后即可删除需要支持高频写，是一个纯 append 写操作，仅在恢复时需要读取需要 99.9% 的写请求在1秒内完成需要和现有的 Checkpoint 机制提供同一级别的一致性保证社区现在的版本是用 DFS 来实现的，综合考量下来基本可以满足需求。同时 DSTL 提供了标准的接口也可以对接其他的存储。在本次 Flink Forward 美团的分享中，可以看到美团在使用 Bookkeeper 实现 DSTL 以及通用增量快照方面取得的性能的提升。这个部分的最后我们来看一下使用通用增量快照的 Trade-off通用增量快照带来的好处显而易见：可以让 Checkpoint 做的更稳定，平滑 CPU 曲线，平稳网络流量使用（因为快照上传的时间被拉长了，并且单次上传量更小更可控）可以更快速的完成 Checkpoint（因为减少了做快照 Flush 的那个部分需要上传的数据）也因此，我们也可以获得更小的端到端的数据延迟，减小 Transactional Sink 的延迟因为可以把 Checkpoint 做快，所以每次 Checkpoint 恢复时需要回滚的数据量也会变少。这对于对数据回滚量有要求的应用是非常关键的通用增量快照也会带来一些额外的 Cost，主要来自两个方面：Checkpoint 放大和状态双写：Checkpoint 放大的影响主要有两点。第一，远端的存储空间变大。但远端存储空间很便宜，10G 一个月大约 1 块钱。第二，会有额外的网络流量。但一般做 Checkpoint 使用的流量也是内网流量，费用几乎可以忽略不计。对于状态双写，双写会对极限性能有一些影响，但在我们的实验中发现在网络不是瓶颈的情况下，极限性能的损失在 2-3% 左右（Flink 1.17 中优化了双写部分 FLINK-30345，也会 backport 到 Flink 1.16），因此性能损失几乎可以忽略不计。对于通用增量 Checkpoint 这个部分我们近期会有更详尽的测试分析报告，敬请期待。2.2 优化作业恢复和扩缩容接下来讲一讲 Flink 社区在作业恢复和扩缩容部分的优化，主要包括优化本地状态重建，云原生背景下的分层状态存储架构升级，以及简化调度过程。作业扩缩容和作业容错恢复有很多共性，比如都需要依据上一次快照来做恢复，都需要重新调度，但他们在细微之处又是有些区别的。本地状态重建以状态恢复本地重建来讲，对于容错恢复，将状态文件原样加载进本地数据库就可以了，但是如果是扩缩容恢复就会更复杂一些。举例来说上图中的作业并发从 3 扩容到 4，新作业 task 2 的状态有一部分来自原先作业的 task 1，还有一部分来自原先作业的 task 2，分别是橙色和黄色部分。Flink 作业算子的状态在 Rescaling 做状态重新分配时，新分配的状态来自原先作业相邻的并发，不可能出现跳跃的有间隔的状态分配。在缩容时，有可能有多个状态合成一个新状态；在扩容的时候，因为状态一定是变小的，所以新的变小的状态一定最多来自相邻的两个原先的并发。接下来具体讲一讲状态是如何做本地重建的，以 RocksDB 为例。第一步，需要下载相关的状态文件。第二步，重建初始的 RocksDB 实例，并删除对实例无用的 Key，即删除上图中灰色的部分，留下橙色部分。第三步，将临时 RocksDB 实例中的 Key 插入到第二步重建的 RocksDB 中，也就是黄色的部分插入到橙色的 DB 中。我们在 Flink 1.16 中，对本地重建的第二步进行了优化。通过引入 DeleteRange，使得整个删除无用 Key 的操作变成 O（1），并且因为最多只可能有 2 个 Range 需要删除，因此额外的数据结构（TombStone 表）对正常读写的影响微乎其微。从上图右边的实验结果可以看出，对于状态大小 122GB 的 Word Count 作业，从并发 3 扩容到并发 4，Flink 1.16 比之前的版本扩容速度提升 2 – 10 倍。同时我们在 Flink 1.16 引入了标准的 Rescaling Micro Benchmark，在此之前社区没有一个标准来测试 Rescaling 的性能。在阿里云实时计算企业版中，我们对本地状态重建的第一步和第三步也进行了优化。我们只需要下载需要的状态文件，并且可以进行文件粒度的直接合并，避免创建临时 DB 实例。阿里云实时计算版本和 Flink 1.16 社区版本对比，缩容速度也有 7 倍的提升。分层状态存储架构为了更好的适应云原生的大背景，我们对分层状态存储架构也进行了初步探索，也就是说我们把远端盘也作为 State Backend 的一部分。这种分层架构可以解决 Flink 状态存储在云原生背景下面临的大部分问题：解决容器化部署本地磁盘大小受限的问题解决外置状态成本高，数据一致性难以保障的问题解决小状态需要额外落盘的问题解决大状态访问速度慢的问题这些问题和容错没有太大关系，以后有机会专门讲一讲这个部分。远端盘作为 State Backend 的一部分，状态加载策略可以变得更灵活。这样状态在没有完全加载恢复完成之前，就可以开始数据处理。在优化前，用户状态恢复时，读写被完全阻塞。在优化后，用户状态恢复的过程中，可以进行半速读写，然后逐渐恢复到全速，如上图所示。可配置的状态加载策略的引入，极大的缩短了状态恢复的初始延迟和业务断流时间。我们从下面两个实验可以看到，单并发状态大小 7GB 左右的作业启动后延迟时间在优化后从 4.5 分钟降到了 1.25 分钟，状态恢复部分提速 75%。同样的作业，在优化后可以发现从状态恢复开始时，就会有 TPS，极大的降低了业务断流的时间。在作业调度这个部分，阿里云 Flink Runtime 团队在阿里云实时计算 VVR 6.0.4 版本中引入了作业热更新这个功能，其核心思想是在扩缩容的时候简化作业重新调度的步骤，并且在新的作业生成后再停掉老的作业，这样可以进一步缩短作业断流的时间。在没有资源预申请的情况下，作业热更新可以使无状态作业扩容和缩容时间降低三倍左右。综上所述，通过延迟状态加载策略，配合作业热更新，基本可以保证在状态恢复和调度层面，做到扩缩容无断流或极短时间断流。2.3 优化快照管理前两个部分都是讲性能上的优化，最后一个部分我想聊一聊快照管理部分的一些梳理。Flink 发展到现今已经是一个很成熟的系统了，清晰化的概念以及简单易用性是衡量一个系统成熟度的很重要的部分，所以这里聊一聊快照概念和管理。Flink 的快照 Snapshot 分为两种：Savepoint 和 Checkpoint。Savepoint 一般由用户触发，所以它归属用户所有，因此由用户负责创建和删除。正因此，Flink 系统引擎层是不能够去删除 Savepoint 相关文件的。所以 Savepoint 不和 Flink 作业强绑定，不同的 Flink 作业可以从同一个 Savepoint 启动。Savepoint 是自包含的：自己包含所需要的一切。Checkpoint 正好相反，它的主要作用是系统容错自愈，所以它由 Flink 引擎周期性触发，并且所属权归属 Flink 引擎。Checkpoint 文件的组织结构都由 Flink 引擎决定和管理，所以引擎负责按需清理 Checkpoint 文件。正因此，Checkpoint 和生成该 Checkpoint 的作业强绑定，并且是非自包含的，比如说 Incremental Checkpoint 之间会有依赖关系。那有什么问题呢？因为 Savepoint 主要目标服务对象是用户，为了对用户友好，Savepoint 使用用户可读的标准格式，也正因此 Savepoints 做得非常慢，经常情况下状态稍微大一点就会超时，同样恢复也很慢。另一方面，Checkpoint 使用的是增量系统原生格式，所以做得很快。这种情况下，用户会把 Retained Checkpoint 当成 Savepoint 来使用。Retained Checkpoint 是在作业停掉后保留的 Checkpoint，这样Retained Checkpoint 就变成了 Savepoint 和 Checkpoint 的混合体。造成的问题是用户负责删除 Retained Checkpoint，但是用户并不知道如何安全的删除 Retained Checkpoint。为了解决上述问题，Flink 1.15 引入了两种状态恢复模式，即 Claim 模式和 No-Claim 模式。在 Claim 恢复模式下，引擎声明 Retained Checkpoint 的所属权，Retained Checkpoint 归引擎所有，引擎负责删除。在 No-Claim 恢复模式下，引擎放弃 Retained Checkpoint 的所属权。Retained Checkpoint 中所有的文件都不会被 Flink 引擎使用，用户可以很安全的删除 Retained Checkpoint。在 No-Claim 的基础上，我们引入了 Native Savepoint，来加速 Savepoint 的创建和恢复。Native Savepoints 使用和 Checkpoint 一样的存储格式，其实现原理和 No-Claim 类似。Savepoint 不会使用之前的 Checkpoint 文件，相当于做一个全量的 Checkpoint。我们的企业版本通过进一步优化，让 Native Savepoint 也真正能做到增量 Savepoint。上图是 Flink 社区引入 Native Savepoint 之前，之后以及企业版进一步优化后的 Savepoint 性能对比图。我们可以看到在引入 Native Savepoint 之前，Savepoint 做的很慢。在 Savepoint 总大小 5GB 的情况下（状态中等大小），做一次 Savepoint 超过 10 分钟（超时）。这意味着一旦用户使用 stop-with-savepoint 来停止作业（也就是在停止作业前做个 Savepoint），就得等超过 10 分钟，完全没法用。在引入 Native Savepoint 之后，需要等 2 分半钟，也比较长，勉强能用。企业版进一步优化后，等待时间变成 5s 钟，这个基本上在可等待的范围之内了。最后我们小结回顾一下 Flink 容错恢复在 2022 年的主要进展在分布式快照架构方面，Unaligned Checkpoint 引入全局计时器，可以通过超时机制自动从 Aligned Checkpoint 切换成 Unaligned Checkpoint，这个对于 Unaligned Checkpoint 生产可用是非常重要的一步通用增量 Checkpoint 生产可用，这对于 Checkpoint 稳定性和完成速度有很大的提升，同时可以平滑 CPU 和网络带宽的使用这里值得一提的是，不仅仅是阿里巴巴在 Checkpoint 这个部分贡献了大量的代码，很多其他的公司也积极的投入到社区当中，比如 Shopee 和美团。他们在社区中贡献代码同时，也积极推动这些功能在公司内部的落地和延展，取得了不错的效果在状态存储方面，我们进行了分层状态存储的初步探索，扩缩容速度有 2 – 10 倍的提升阿里云实时计算平台推出了扩缩容无断流的组合功能：延迟状态加载和作业热更新，分别从状态加载和作业调度这两个方面来实现扩缩容无断流引入增量 Native Savepoint，全面提升 Savepoint 的可用性和性能。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-29
Flink Shuffle 3.0: Vision, Roadmap and Progress
摘要：本文整理自阿里云高级技术专家宋辛童 (五藏)，在 FFA 2022 核心技术专场的分享。本篇内容主要分为五个部分：Flink Shuffle 的演进流批融合云原生自适应Shuffle 3.0点击查看直播回放 & 演讲PPT一、Flink Shuffle 的演进在整个 Shuffle 的演进过程中，其实并没有明确提出过所谓 Shuffle 1.0 和 2.0 的概念。但从它的技术发展经历中，我们能把它分成如上图所示的两个阶段。在 Shuffle 1.0 阶段，Shuffle 只具备基础的数据传输能力，Flink 项目也处于相对年轻的阶段。在 Shuffle 2.0 阶段，我们对 Shuffle 做了一系列优化。在性能方面，我们对数据的序列化，底层网络的内存拷贝进行了优化，并针对 Batch 场景设计了 Sort-Based Blocking Shuffle，这种 Shuffle 方式可能对磁盘 IO 会更加友好。在稳定性方面，我们引入了 Credit-Based 流控机制，这种机制会比原本依赖于 TCP 的反压机制更具稳定性。此外，社区还引入了 Buffer-Debloating 机制，使其能够在反压的状态下减少数据积压对 checkpoint 的影响。在流批一体方面，我们将 Shuffle 模块进行 Service 插件化重构，让第三方开发的 Shuffle 实现成为可能。除此之外，我们还为批场景中的 Remote Shuffle Service 技术铺垫了道路。综上我们可以发现，不管是性能还是稳定性，都是 Flink 上大规模生产必备的能力，而流批一体是 Flink 社区过去发展的主要方向之一。从整个 Shuffle 2.0 阶段，我们发现 Flink Shuffle 已经趋于成熟，在生产中表现优异。说到 Shuffle 3.0 的时候，我们重点要关注哪些问题呢？或者说随着时代的发展、技术的进步，对于 Shuffle 又提出了哪些新的挑战呢？这里我们也列出了三个关键词：分别是流批融合、云原生和自适应。接下来，也会逐一的去跟大家做一个展开的探讨。二、流批融合“流批融合”与“流批一体”有什么样的联系和区别？如上图所示，左边是 Flink 经典的流批一体架构。在这套架构中，Flink 提供了流批统一的 API 表达，然后使用统一的引擎也就是 Flink，进行流和批的数据处理。此外，我们通常会把实时任务与离线任务调度到同一个集群进行混部，从而提升研发运维效率和资源利用率。目前，Flink 流批一体架构主要体现在面向用户的流批一体。如果看引擎的内部，我们会发现，一个 Flink 任务的流模式和批模式的区别非常明显，而整套架构中也仍然存在离线和实时两条数据链路。由此可见，流批一体主要是一个面向用户的概念。流批融合，所谓 Flink 流和批融合的能力，不仅仅是将流和批的技术放在一个引擎当中，我们希望能在引擎侧打破流和批的技术边界，既有流技术，又有批技术，同时服务不同的场景。在流批融合方面，主要有如下两个要点：第一，在批处理场景下，Flink 作为以流式为内核的引擎，不但借鉴和学习了成熟的批技术经验，还具备很多独一无二的优势。比如我们在流处理时，上下游任务同时运行，流式内核引擎能够保证数据不落盘进行直接传输，从而降低 IO 开销，提升性能。除此之外，在流处理上有基于 checkpoint 的容错机制，它拥有更灵活、更精细的容错能力。第二，流式引擎具备批处理的能力之后，反过来也能够更好地服务流处理场景。比如批作业数据通常需要排序，它在状态访问时具有更好的性能与效果。除此之外，批数据的中间数据会落盘，具有可重复消费的特点，这对容错也有比较好的提升。流批融合主要强调，打破流和批的边界。从引擎侧把所有技术放在一起使用，服务于不同的场景。不难看出流批融合的概念是端到端的事情，贯穿执行计划优化、编译、调度、运行、Shuffle、容错等场景，都需要按照流批融合的概念进行改变和提升。Hybrid Shuffle 是一种将流技术应用于批场景的技术。目前，Flink Shuffle 主要有 Pipelined Shuffle 和 Blocking Shuffle。其中，流式 Pipelined Shuffle 的上下游任务是同时运行的，大幅缩短任务的运行时间。同时，其数据可以在任务间直接传递，不需要落盘。但是目前 Pipelined Shuffle 在批场景下，仍处于生产不可用的状态。因为它在上下游同时运行时，资源需求较高。如果同时存在多个任务，每个任务只能拿到一部分资源，很容易形成资源调度的死锁。批式 Blocking Shuffle 有更好的资源自适应能力。在极限情况下，我们可以用一个 slot 执行完所有任务。但是它的性能较慢，因为批任务按 stage 调度的方式运行，每个 stage 都需要等待长尾任务完成。其次，它的数据需要全部落盘，导致 IO 开销较大。由此可见，不管是流式 Shuffle 还是批式 Shuffle，它们在某种特定的情况下，都会出现资源碎片的现象，即虽然持有资源却不能够调度任务并执行，从而会造成资源浪费。Hybrid Shuffle 是想将流式 Shuffle 跟批式 Shuffle 的特点结合在一起，让用户在写数据时，既可以写入内存通过内存直接进行消费，也可以在内存中存放不下这么多数据、下游消费不够及时的时候，将数据写入到磁盘当中进行后期消费。通过自适应切换，在上游产出数据的过程中和完成后，下游可以随时消费，从而彻底消除资源碎片的情况。Hybrid Shuffle 在资源充足的情况下，上下游的所有任务可以同时运行，它的性能跟流式 Pipeline Shuffle 相同。在资源受限的条件下，Hybrid Shuffle 可以先让上游执行，将数据落到磁盘之后，下游再进行消费。其资源的自适应性比 Blocking Shuffle 更好。除此之外，Hybrid Shuffle 在内存跟磁盘之间进行切换，是一种动态的自适应切换，并不是静态的一次性切换。我们在数据消费的过程中，可以随时在内存写满的状态下，切换到磁盘模式。当内存中的数据被消费，留出更多的空间后，它又可以切换回内存进行消费。目前，Hybrid Shuffle 已经在 Flink 1.16 发布。经过测试，Hybrid Shuffle 相比 Blocking，在资源受限的条件下，性能提升了 7.2%。如果在资源充足的情况下，Hybrid Shuffle 会比 Blocking 有更大幅度的性能提升。接下来，在 Flink 1.17 时，我们会继续对 Hybrid Shuffle 进行完善与优化。主要包括针对广播数据的性能优化，以及对大规模生产中批处理的其他重要特性的兼容。Single Task Failover 单点重启是将批技术应用于流场景的技术。Flink 在流式任务中，如果一个任务出现失败，关联的上下游任务都要进行全局重启，才能保证数据一致性，但是这种全局重启的成本较高，特别是一些大规模、复杂的作业。单点 Failover 能够做到当出现 Failover 时，只对当前失败任务进行重启。目前，我们支持三种一致性语义，分别是 Best-effort、At-least-once、Exactly-once。一致性的保障越强，相应的开销就越高。其中，Best-effort 需要恢复任务状态。为了解决这个问题，我们采用分布式局部快照的方式，给每个任务做定时的局部快照，避免全局的同步开销。在 At-least-once 语义下，我们需要对上游数据进行重放，避免数据丢失。在 Exactly-once 语义下，我们不仅需要对数据进行重放，下游还要对数据进行去重。不管是重放输入，还是去重输出，都是在 Shuffle 层面完成。它们跟 Blocking Shuffle 的数据落盘半持久化、支持重复消费具有很高的相似性。所以在实践中，我们是基于现有的批 Shuffle 能力，进行了扩展和二次开发。目前，Single Task Failover 的工作，仍处于内部实践阶段，At-least-once 语义即将在阿里云内部上线，Exactly-once 则还处于研发当中。三、云原生Shuffle 3.0 在云原生场景下的实践。从 Flink 1.9 版本开始，我们就一直在建设 Flink 云原生部署体系，包括 Native K8s 的部署模式、轻量化客户端的 Application Mode、Native K8s HA 模式，以及 Reactive Scaling 的资源管理方式等等。Flink 云原生部署体系越来越完善。用于 Flink 流式任务的生产也相对比较成熟，并经过了大量的生产检验。但我们在运行批任务时，仍会遇到问题。其中，最主要的问题是批的 Shuffle 数据存储。在 Batch 任务中，我们需要对大量的中间数据进行落盘，这个时候就产生了数据存放在哪的问题。目前 Flink 有两种主流的 Shuffle 模式，即 Internal Shuffle 和 Remote Shuffle。Internal Shuffle 的数据直接写在 TM，这里有两个问题。第一，资源效率问题。在云生或云计算场境下，资源的弹性伸缩能力是非常重要的。在 Flink 的 Internal Shuffle 中，当我们把数据写在 TM 本地时，TM 无法及时释放资源，限制了计算资源的弹性。第二，磁盘成本问题。一个物理机的磁盘在容器化的场境下，我们无法精确的界定每个 TM 需要配置多少磁盘空间。如果配置空间较多，成本就较高，会造成资源浪费。如果配置空间不足，会影响数据处理的稳定性。虽然云盘拥有动态挂载，共享存储空间等能力，但其成本相比磁盘较高，访问速度也比本地访问慢一些，同时动态挂载也比较费时。综上所述，Internal Shuffle 的问题主要是资源效率以及磁盘成本。Remote Shuffle 的问题是数据传输开销。原本 Shuffle 数据只需要在两个 TM 之间进行传输，现在我们需要先从上游的 TM 传输给一个远程系统，然后下游的 TM 再从远程系统进行消费，这会让传输的成本至少增加一倍。此外，我们不但需要运维部署 Flink 集群，还需要额外部署一套 Remote Shuffle Service 集群，从部署运维上也会产生一部分成本开销。最后，Remote Shuffle Service 虽然能够在一定程度上缓解磁盘空间和磁盘成本问题，因为它可以建立一个 Remote Shuffle Service，同时服务大量不同的 Flink 实例，可以起到削峰填谷的作用，但它并不能从根本上消除磁盘空间的问题。所以目前 Internal Shuffle 和 Remote Shuffle 都没有非常完善的解决方案，来解决 Flink 在云原生场景下 Batch 数据的存储问题。大家在使用云产品时，经常使用对象存储。基于对象存储的 Shuffle，拥有灵活的资源弹性，成本相对较低。但对象存储往往是不可修改的，上游在写数据的过程中，数据对下游不可见，一旦下游数据可见，上游则无法对数据进行修改或追加。除此之外，其性能相比本地磁盘或云盘，仍有一定的差距。因此在流处理场景下，基于对象存储的 Shuffle 仍面临一些挑战。一方面，需要基于不可修改的对象存储，实现边读边写的能力。另一方面，对象存储很难满足低延需求。虽然对象存储很难独立支撑 Shuffle 数据管理，但当本地磁盘不够时，可以将对象存储作为其他数据存储方式的补充，从而实现性能和成本的均衡。目前，基于对象存储的 Shuffle，仍处在内部实践阶段，预计在 Flink 1.18 版本发布。四、自适应自适应，在最新的 Flink 1.16 中，有四种不同的 Shuffle，分别是 Pipelined Shuffle、Hash Blocking Shuffle、Sort-Based Blocking、以及最新推出的 Hybrid Shuffle。未来，Flink 可能会引入 Single Task Failover、对象存储 Shuffle、Merge-Based Shuffle 等等。除此之外，在第三方项目中，Flink Remote Shuffle 也是基于 Flink Shuffle 的接口实现。大量不同的 Shuffle 实现同时存在，也带来了一些问题。用户不知道如何选择 Shuffle 类型，使用起来比较困难。根据场景选择适合的 Shuffle 类型，这需要用户对 Shuffle 内部原理有深入的了解。选择 Shuffle 类型之后，在实际生产中，用户对 Shuffle 进行参数调优时，也面临不同的 Shuffle 类型调优参数及原理均有所差异的问题。除此之外，由于有些用户的场景比较丰富，可能需要同时使用多种 Shuffle 类型。这些 Shuffle 类型如何进行搭配？其复杂性给用户使用带来了困难。在开发者维护方面，随着出现了越来越多的 Shuffle，工作人员需去维护更多的代码，甚至重复开发。除此之外，Shuffle 内部的复杂度，开始向 Flink 全链路扩散，比如 SQL 编译、调度运行等等。为项目的长期的维护，带来了一定的影响。为了解决上述问题，我们提出了三种提高自适应性的方法。第一，复杂性反转。让 Shuffle 适配外部条件，并决定当前需要选择哪一种 Shuffle 实现，降低操作的复杂性。第二，减少外部信息依赖。我们希望根据实际掌握的信息，做出最好的决策。我们可以把非必要信息，转化为补充信息，同时对能自动获取的信息尽量自动获取，减少 Shuffle 与其他模块的信息依赖。第三，我们希望在运行过程中，根据使用环境的变化，Shuffle 能够自动调整自己的行为，消除不同 Shuffle 类型之间的边界，以适应运行时的动态变化。五、Shuffle 3.0最后介绍一下，基于上述关键词，我们提出的 Flink Shuffle 3.0 架构设计。这套架构被称为自适应的分层存储架构。在这套架构中，我们将 Shuffle 上下游间的数据交换过程，抽象为上游将数据写入某种存储当中、下游再从该存储中抽取需要查询的数据的过程。在分层自适应存储架构中，包含一个写端 Selector 和一个读端 Selector，主要负责向不同的存储介质写数据和读数据。在中间的存储层，隐藏了内部实现细节，具有统一的抽象。在动态自适应方面，写端按照优先级，进行存储层的数据写入。如果遇到空间不足等问题，存储层会反馈当前无法接收数据，然后继续写下一个优先级的存储层。在读端，我们按照优先级的顺序，依次去查询想要的数据。通过分层存储加动态自适应的方式，我们将多种存储层的介质，进行融合和互补，满足我们在不同情况下的需求。在存储层规划方面，Local TM 层主要有内存跟磁盘。在 Remote TM 层，用户把数据写到第三方 TM 的内存跟磁盘中，进行管理。此外还有远程存储介质层。目前，我们在 Shuffle 3.0 自适应存储架构的探索中，遇到了如下关键技术问题。在数据分组方面，不同位置存放的数据分组方式不同，决定了数据索引结构和文件存储格式的差异。在数据管理粒度方面，采用较大粒度在存储层之间切换，降低切换频率和查找代价，不同存储层内适合不同粒度。在存储层内部，内存存储比较适用较小的粒度，它对实时可见性的要求较高，管理数据的成本较低。而对于像对象存储这样的远程存储服务，我们会更关注如何减少文件数量，倾向于相对较大的数据管理粒度。在数据索引方面，数据存放的位置决定了适用不同的索引方式。比如本地 TM 和远程 TM 上，内存索引的方式查询性能更好。由于对象存储缺乏外部的服务进程，对数据进行管理。所以我们基于文件命名的方式，对文件进行简单的 list 操作，根据文件名判断当前想要的数据，是否在文件当中。目前，Shuffle 3.0 仍处在探索阶段。未来，在 Flink 1.18 时，社区会推出第一个版本的分层自适应架构存储，包含本地 TM 内存、磁盘的存储层，支持远端对象存储能力。后续我们会逐步增加流处理、Single Task Failover、远程 TM 的内存+磁盘等能力。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-28
上云节省 35%计算资源，420 个运维人天：运满满实时计算实践和思考
摘要：本文整理自满帮实时数据团队 TL 欧锐，在 FFA 2022 行业案例专场的分享。本篇内容主要分为四个部分：满帮业务及平台架构介绍实时数据实时产品未来计划点击查看直播回放 & 演讲PPT一、满帮业务及平台架构介绍满帮集团全心全意帮助司机和货主，助力物流降本增效，利用移动互联网、大数据、人工智能等新技术，打造智慧物流生态平台，提升“车找货、货找车”的智能化和标准化，改变传统物流行业“小、乱、散、弱”的状况。旗下运满满货运平台一站式解决货运全链路问题，百万司机一秒响应。满帮实时数据矩阵图满帮的实时数据矩阵图主要采用了云原生和 OLAP 平台的架构，主要采用了阿里云 Flink+Hologres 的应用架构。在实时数仓层面，建设了用户、货源、流量、支付、交易、营销以及 CRM 基础层，同时还建设了我们特有的数仓分层，叫实时供需层，相当于传统公司的 ADM 层。在这一层我们建设了线路司机分布情况、沿途货源分布情况、二级货类分布情况、实时离线供需融合情况以及每个出发城市或者线路沿途的疫情和天气情况。在数仓上我们还往前更近了一层，做了实时特征。基于分钟级或者秒级的实时数仓去做数据，快速高效的赋能给算法和运营业务。包括司机和货主的行为特征、司机行为概率分布、货源行为状态分布、路线货源价格分布。同时，我们团队在实时策略上也做了相应开发，比如说司机有拼单的意愿，或者说司机有漫游行为、人群流量实时预测、Push 流量实时预测和分配。关于为了满足实时业务的实时数据产品，它和离线数仓有一个本质区别，就是实时数据需要更多直接触达业务。那么我们怎么去定义实时数据产品呢？我们想把它变成一个实时的决策平台，包含如下几个环节：第一步是数据洞察;第二步是智能归因;第三步是实时预警，指标归因出来后把数据告警给相关的业务方;第四步是人群画像，指在告警时，需要把相关人群的画像主动勾勒出来;第五步通过高效的 OLAP 和 Flink 计算开发一条简单的策略;然后导入到规则引擎，让算法和运营来调取;最后通过 A/B 效果完成整个决策平台的产品构建。线上实时决策平台和底层数仓，主要的服务对象包含页面排序、搜索排序、智能召回、Push 收归、司机会员、委托定价等权益或价格的策略，实时决策基本上都用到了实时特征和实时数据。在做实时数据的时候，我们思考了三个维度。第一是价值。我们需要去理解和洞察业务，然后通过实时决策平台赋能业务。第二是闭环，我们不仅只是把数据做到位，还需要考虑整个业务的闭环效果。第三是成本，主要是基于价值去衡量 ROI，如果投入与产出不成正比，我们就需要在成本上相对收敛一些。满帮实时计算平台架构接下来分享一下满帮实时计算平台的架构。满帮的数据分布在不同的机房，当然也分布在不同的云厂商。从下图可以看到 A 机房主要是生产系统和实时计算，B 机房主要是离线机房，即离线集群。在这种数据架构下做实时数据的全链路能力，我们做了如下几件事：我们做了全链路稳定性建设。数据源到最上游的数据消费做到分钟级，即一分钟、十几秒甚至几秒钟，业务系统就要消费到底层传来的数据。我们在实时计算数据源上进行了稳定性治理。在前端埋点采用了业内比较领先的架构，后端埋点在一些关键的业务点上进行了一些打点，让数据可以做到秒级到达实时数据仓库。我们统一了数据标准。在数据源治理完后，把所有的实时数据放到一个数据总线里，保证实时数据的消费是统一数据标准。我们曾经采用过传统的 Doris 和自建的一些架构，但发现运维成本都相对比较高，所以最终采用了阿里的 Hologres 集群。我们要做一个完整的数据服务生态圈。在把数据赋能到业务方和调用方的时候，我们需要提供一些 API 和消息队列。这里我们吸收了阿里云 OneService 的建设思路，构建了一个统一数据服务。我们和算法平台一起做了实时样本归因平台，同时配合他们做了一个实时训练的框架，保证算法和运营的实时决策。从自建 Flink 到迁移云原生的阿里云实时计算 Flink 版平台降本增效以上是实时计算平台架构的分享，接下来分享一下，我们从自建的 Flink 迁移到云原生的阿里云实时计算 Flink 版平台的原因。原有自建集群上运行实时作业稳定性差，严重影响业务，自建整体运维成本较高，需要将重心从平台建设向业务优化倾斜，技术发展路线从开源自建向托管云服务迁移。具体如下：第一点，阿里云实时计算 Flink 版平台采用了云原生全托管架构，部署、资源隔离在上面都具有天然的架构先进性，CU 级别智能弹性扩缩容有效提升性价比。第二点，我们在自己搭建 Flink on Yarn 的时候，发现底层的资源隔离和资源之间的影响有很大的波动性，阿里云实时计算 Flink 版平台的云原生资源隔离能力可以实现作业级和代码级的隔离，减少互相影响，技术领先性创造平台稳定性。第三点，阿里云实时计算 Flink 版开发平台，它的 metrics 采集系统、SQL 开发、资源调优明显改善开发效率，运维工作量和成本显著降低。下面我们来看一下，下半年把运满满的整个实时计算 Flink 任务全部迁移到阿里云，收益是怎么样的？我们迁移的 Flink 任务有 560 个，迁移时间仅需 1.5 个月。迁移过后，经过一段时间的观察，我们发现 SLA 的指标从 95%提升到了 99%。另外在运维人效方面，从原来的三个人到现在的一个人，全年节约了 420 人天。在开发的效率方面，每个任务的开发、调优、上线可以提前两天。如果按照每年 300 个任务，就是节省了 600 人天。最后基于阿里云对 Flink SQL 和底层 state 状态的深度优化，我们发现平均一个 Flink SQL 任务消耗 6.67CU 的资源，而上了阿里云过后，可以节省 40%的资源。这样算下来，整体可以达到 35%的资源节省。二、实时数据目前我们使用阿里云 Flink+Hologres 这套架构来基于分钟级或者秒级的实时数仓去做数据，快速高效的赋能给算法和运营业务。包括司机和货主的行为特征、司机行为概率分布、货源行为状态分布、路线货源价格分布等。应用场景主要分成两个部分。第一部分是特征计算，第二部分是样本归因。样本归因即把用户的行为数据、特征数据、回流数据关联起来。我们采用这套架构的原因是，Hologres 支持读写分离和实时数仓，其中读写分离的性能给我们带来很大的收益。另外我们在做特征的二次计算时，也采用了阿里云 Flink+Hologres 的最佳实践，实时计算 Flink 版在实时作业的稳定性上给了我们很大的惊喜，同时定时调优的策略使得资源效率显著提高，很好的为实时决策提供了数据支撑。从实时数据到实时决策实时决策包含两部分，分别是在算法场景的实时决策、在运营场景的实时决策。下面先分享一些我们怎么用实时数据决策算法场景。在一个传统的推荐算法链路上，它的链条是相对比较长的。司机从 APP 进行搜索，然后经过 AB 流、子场景、召回、粗排、截断、精排，最后到实时策略。其中召回的环节，可能会带来千条的数据，所以要通过后边的环节逐步减少数据量。从下图可以看到，AB 分流到实时策略的过程需要实时指标把它们串联起来，实时指标的数据在 AB 分流、召回、粗排、截断、精排等环节都会被用到。另外在精排的时候，用分钟级模型也要用到实时指标的数据。所以要理解实时数据的决策，首先要理解实时数据对每一个算法子模块的作用。接下来我们思考一个问题，要怎么去推导实时数据问题定义、目标、策略和价值呢？首先，如果我们在算法场景用实时数据赋能业务，需要考虑以下三个方面：系统实时性，需要实时获取最新的模型和数据。特征实时性，需要实时获取数据的分布。模型实时性，需要保证实时拟合数据的分布。然后我们需要确定子目标，确保特征的更实时、模型的更实时、样本的更实时。我们给自己定义的目标是，第一计算延迟全链路小于 3 分钟，关键点链路要做到 10 秒甚至 20 秒；第二整体数据延迟小于 5 分钟；第三样本准确率大于 97%。接下来制定策略。在计算延迟方面，我们采用 阿里云 Flink+OLAP。在数据低延方面，需要考虑样本延迟、特征延迟、全链路延迟监控、数据治理、链路优化。在样本准确率方面，除了使用传统的一些样本技术，我们还需要注意样本数据质量监控和模型效果在线监控。我们采用了阿里云 Flink+Hologres 这套架构。最后明确价值。在业务价值方面，基于搜索天模型基础，有 3%业务的提升。技术价值方面，积累沉淀实时特征模型，提升算法模型更新时效性，赋能算法业务，服务不同特色算法场景；打通增量学习全链路，为增量学习平台打下技术基础。具备实时特征计算的实时数仓建设下面分享基于阿里云 Flink+Hologres 实现的实时数仓的建设。我们的数仓是以位置关系、运力、供需三个维度为核心，进行双向推导和抽象。和一般的物流公司差不多，我们的实时基础数据也都包含用户、货源、车辆、流量、交易、车油、金融、风控。但我们更关注的其实是司机和货主的位置状态，因为这决定了我们的匹配效率，所以我们的实时数仓和传统的离线数仓有很大不一样。我们基于位置构建了一套实时数仓，由于业务决策的实时必要性，产生了对数据的实时性要求，因此我们在构建数仓时，数据一部分通过 Flink CDC 同步到 Hologres，实时入仓，一部分经过实时计算后落到数仓中，形成一体化分析服务。通过位置把货源、车辆、用户、交易、流量、营销等数据关联起来。另外我们还需要深入业务，在车货匹配、定价决策、调度决策、供需监控、客服决策等方面，实时做决策。但在这一过程中，业务使用还是会和数仓之间有一层 Gap。实时数仓对业务的抽象度不够，要怎么办？实时数仓到底能给业务带来什么价值？怎么度量？实时数据怎么挖掘特有业务的指标和特征？所以我们抽象了一个实时供需引擎。换句话来说就是在业务和实时数仓上，抽象了一个虚拟的产品层供业务使用。我们在数仓建设的时候进行了两次抽象。第一次抽象是自下而上，抽象出一个实时数仓。第二次抽象是也是自下而上，抽象出一个供需引擎。建设实时数仓过后，我们还在进行了实时特征和实时指标的开发。在这一过程中我们发现，对接业务的时候，我们往往很被动。客户提出一个需求，我们就逐步去开发，这样往往会花费大量的时间。比如业务提出了一个需求，数据的同学就需要大概 8 天的时间去做架构设计和数据开发。等把特征开发完后，算法同学还要进行数据的回流和模型训练及验证，这个过程又需要大概 10 天左右。整个过程需要 20 天甚至一个月才能全链路上线。那么怎样才能提高整个链路的开发和迭代效率呢？我们做了一个批量实时特征计算框架。举个例子，在我们的环境中，有一个点击数据需要根据算法不同的时间时间维度去看。有的算法要求 5 分钟，有的算法要求 1 个小时，有的算法要求 10 秒，这个时间是无法预估的，在算法上线之前我们无法知道哪一个时间纬度对它最有效。除此之外，还需要看每次点击次数的分位数、近 5 分钟的分布、排名、近 5 分钟排名 log、group by 的状态、daytime 分桶特征等等。在前面基础上我们还会做一些交叉特征，比如减去常有的平均次数，当天天气情况和当前疫情情况等。所以用户提出一个数据的背后其实隐含了很多特征。我们采用了一套阿里云实时计算Flink 版架构，来确保用户提出数据后，能尽最大可能满足业务需求。用 Window 的滑动窗口、滚动窗口保证可以做到时间上的切片和滑动。sum 代表计算，我们可以做 5 分钟、10 分钟、30 分钟的开发计算。然后通过 function 调用计算函数，自动计算出实时特征。function 定义的函数包括 log、ration、cnt、dayCategory 等。在做了这套计算框架后，我们在研发效率上有明显提升，支撑特征批量开发，开发周期从 3 天降低到 2 天，目前还在大规模的推广，我们目标是从 3 天降低到 0.5 天。资源利用方面，我们把 120 个任务合并成 16 个，资源消耗减少 200 Core 资源。在性能和稳定性方面，我们每分钟计算出 1000+特征，且任务保持稳定运行。值得一提的是，如此庞大的计算得益于阿里云实时计算Flink版云上能力的不断更新，比如将类似 Window table-valued 函数增强、CAST 和类型系统增强、双流 Join 算子支持自动推导开启 KV 分离优化等，能力完善的同时作业运行性能显著提高，对业务决策进行了有力的支撑。三、实时产品解决了实时数据的问题，我们在实时数仓的基础之上，构建了以实时线上决策系统为核心定位的产品，以实时预警作为出发点开始，目前我们做了以下这些事。第一个是实时指标告警平台烽火台，它的作用是解决实时指标的展示和告警。从下图中右边的窗口可以看到，我们可以通过实时指标烽火台把用户关心的指标展示出来；从右边的窗口可以看到，还可以对指标进行配置告警，主动触达业务告警。第二个是实时数据服务平台，它的作用是解决实时数据服务能力。当业务方需要调用数据时，我们不能直接吐到它的消息队列里，所以希望有一套 API 接口或者一套服务来解决它调用我们数据的问题。因此我们和离线数仓共用一套 OneService，然后把我们提供的数据服务展示在一个数据超市里。业务方只需要通过一些简单的配置，就能生成 API，供用户直接调用，最后进行计费。四、未来计划2006 年我们上了 Hadoop；2018-2019 主要以 Spark Streaming 为主；2020 年上了 Flink DataStream；2021 年上了实时数仓和 Flink SQL；2022 年，我们搭建了实时特征、实时服务、烽火台；2022 年 Q4 我们将 Flink 迁移到了阿里云上，升级了特征平台，还对实时决策平台进行了初步构造。2023 年，我们将把实时数据和业务进行更深度的融合，做实时决策平台 2.0；探索 Flink on AI 并大规模使用。除此之外，我们还会基于阿里云 Hologres 和别的云厂商产品，去构建我们自己的跨云 OLAP 引擎平台。点击查看直播回放 & 演讲PPT更多内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-22
FFA 2022 主会场 Keynote：Flink Towards Streaming Data Warehouse
摘要：本文整理自 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问），在 Flink Forward Asia 2022 主会场的分享。本篇内容主要分为四个部分：实时流计算全球范围事实标准2022 数据实时化技术创新不止Streaming Data Warehouse流式数仓 Demo点击查看直播回放 & 演讲PPT一、实时流计算全球范围事实标准Apache Flink 社区从 2014 年诞生到 2022 年已经经过了连续八年的快速发展。从早期的互联网行业逐步扩展到更多的传统行业，比如金融、电信、交通、物流、以及能源制造等等。Apache Flink 诞生于欧洲，爆发于中国。最近几年席卷全球，在北美、东南亚等全球各地开始被大量使用。可以说在全球的各个行业，只要大家想到实时流计算，基本上都会选择 Apache Flink。因此我们就可以认定 Apache Flink 社区已经成为了全球范围内实时流计算的事实标准。从 2022 年社区的各项指标中，也进一步得到印证。Flink 社区经过八年的快速发展，在 Github Star 上也一直持续稳定的快速增长。目前为止，Flink 的 Github Star 已经超过了 20000，这在 Apache 主流的大数据项目中依然是名列前茅的。在开发者生态方面，我们也已经积累了超过 1600 名的开发者，为 Flink 社区做贡献，2022 年又新增加了 200 多名开发者。从下载量上也可以看到，Flink 在 2022 年再创新高，月度峰值的下载量最高已经突破 1400 万次。在整个 Flink 国际化生态不断繁荣发展的过程中，我们可以非常自豪的看到，中国开发者在里面承担了非常大的核心推动力。通过 OSS Insight 网站的数据统计可以看到，Flink 社区在 Github 上产生的 Pull Request 有 45% 是来自于中国的开发者。由此可见，整个社区的技术演进和技术开发的推动力主要都是由中国开发者带来的。Apache Flink 中文社区这几年也在持续稳定的发展中。去年非常多国内的开发者在 Apache Flink 社区公众号上发布了文章，数量达 100 多篇。Apache Flink 社区公众号的订阅人数也已经超过了 60000 名。今年我们还推出了 Apache Flink 官方的视频号，目前订阅人数也已经将近 4000 名。Flink 经过多年持续的健康发展，形成了一个繁荣的生态， 它的核心竞争力是什么呢？其实非常明确的可以看到，就是 Flink 的技术领先性，实时化的大数据计算能力。Flink 社区最近几年其实也和其他的主流的开源社区和生态进行了合作，形成了一系列丰富多彩的实时化大数据场景解决方案，例如：和 HBase 社区联合起来形成实时大屏分析的解决方案。和一些生态数仓项目，比如 Hudi、Iceberg、ClickHouse、StarRocks、Doris、TiDB 等开源湖仓产品，形成全链路实时湖仓分析解决方案。和主流的深度学习框架，比如 TensorFlow，PyTorch 项目进行联合使用，提供实时化、个性化推荐的解决方案。和 Prometheus 形成实时监控报警的解决方案。从以上内容我们可以看到，Flink 社区的心态是非常开放的，可以和很多主流的开源社区形成联合解决方案。让丰富多彩的实时化场景解决方案，推动各个行业大数据实时化技术的升级。二、2022 数据实时化技术创新不止接下来我将为大家介绍一下，2022 年中 Flink 社区在实时化技术路线上的一些重要技术成果和创新成果。Apache Flink 社区在 2022 年发布了两个大的版本，Flink 1.15 和 Flink 1.16。在 1.15 中，Flink 解决了很多以前历史存在的一些难题，比如初步支持了跨版本流 SQL 作业升级，在 1.15 中可以检测到新老版本不兼容的情况并对用户进行提示，也可以去兼容老版本的 plan 进行升级。此外 1.15 也解决了 Flink 在多 Source 对齐情况下的挑战。因为 Flink 的一个流任务可以有时候会有多个数据源或者日志流。不同的日志流的数据进展是不一样的，所以就有可能导致他们的数据进度差异较大。在 1.15 中提出了新的方案，更加方便的实现了多 Source 的 Watermark 对齐。在 Flink 核心理念中，比如 Checkpoint 和 Savepoint 这两个概念用户就一直不是很清楚，经常会使用不当。因此在 1.15 中也对这两个概念重新进行了梳理和定义。同时也将 Checkpoint 和 Savepoint 进行存储格式的统一，让 Savepoint 也可以像 Checkpoint 一样高效的被使用。此外对批处理技术也进行了更多的完善，包括批算子的自动并发设置，让批处理更加易用，流批一体更加实用。在 1.16 中，我们做了更多的技术创新和新的技术的尝试。比如我们对整个 Flink 分布式一致性快照技术架构，进行了很大程度的升级，落地了 Unaligned CP + Log-Based CP 新组合。在 Flink Streaming 方面引进了异步化的技术和缓存能力，使得 Streaming 维表 Join 有更强的能力。在流批一体领域提出了流批自适应 Hybrid Shuffle，通过更加合理的利用集群资源，来提升网络 Shuffle 的性能。在生态方面，对 Hive 生态进行了更好的兼容和拥抱。不仅能够无缝对接 Hive 的 HMS，也完全兼容了 HiveServer2 协议。在 Hive SQL 的兼容性上，Flink SQL 也达到了 94%以上的兼容度，也就是原来用户在 Hive 生态上写的 Hive SQL 绝大部分都可以不经过修改直接运行在 Flink 引擎之上，利用 Flink 实时化计算高性能的能力，去加速 Hive 离线数仓的性能。在 Python API 方面，PyFlink 也得到了彻底的完善。在 1.16 中已经基本覆盖了所有 Flink 的关键算子。这样对 Python 程序员来说，也可以通过 Python 语言使用 Flink 所有特性了。刚才介绍的 Flink 1.15 和 Flink 1.16 的诸多特性，也只是冰山一角。其实整个 1.15 和 1.16，还推出了非常多的特性和改进。接下来我会选择一些比较有代表性和创新性的技术点进行深度解读。首先来看一下新一代分布式一致性快照的架构。我们知道分布式一致性快照技术在整个 Flink 社区里是非常核心的理念。Flink 作为一款有状态的流计算引擎，分布式快照是它的非常核心的特点。比如 Flink 在不停做流计算的过程中，会定期 Take Snapshot 或者 Checkpoint 将流计算的状态进行持久化。就算流任务出现异常，它也可以从上一个临近的状态进行恢复，保证业务的连续性。因此 Flink 的用户都有一个天然的诉求，就是希望 Flink 的分布式一致性快照可以更加低成本、高频的做出来，从而让业务更加流畅。但是在真实的生产环境中，尤其是大规模、复杂的生产环境中， 分布式一致性快照是面临非常多挑战的。尤其是在反压的情况下，挑战尤为突出。因为在反压的过程中，整个流计算的网络 buffer 会被打满，也就是网络拥塞。用来做 Checkpoint 的 Barrier 没有办法成功的在流里面传输，所以各个流计算的算子也没有办法收集到这些 Barrier，并且让 Barrier 对齐，也就没有办法触发 Checkpoint。即使能够触发 Checkpoint，在执行 Checkpoint 动作的时候，也需要把本地的状态数据上传到远程的云存储之上，数据量的大小也是不可控的。如果在状态数据的变化比较大的情况下，Checkpoint 依然会持续很久，并变得不可控。所以 Flink 在最近几个版本中对整个分布式一致性快照架构做的很多的技术点的升级 。比如我们连续做了多个版本的 Unaligned Checkpoint，推出了 Buffer Debloating 技术。在 Flink 1.16 中落地了 Log-based Checkpoint 来做架构升级和改造。通过 Buffer Debloating 可以让整个网络 buffer 使用更加高效；通过 Unaligned Checkpoint 去除对 Barrier 对齐的依赖；通过 Log-based Checkpoint 大幅降低执行 Checkpoint 的成本。接下来分享一下 State 状态存储体系。在云原生时代，我们需要对 Flink 的状态存储体系进行了更大范围的升级。相信各个开源软件或者基础软件都需要去考虑如何去适应 Cloud Native 时代，如何去进行相应的升级和转型。云原生时代给我们带来了的最明显的特点就是资源的弹性更强了，越来越 Serverless 了，这对 Flink 架构提出了更高的弹性扩缩容需求。Flink 作业的并发会随着资源弹性和业务负载不断改变，因此 Flink 的状态存储也需要进行相应的适配，即状态数据的分裂和合并。如果状态存储根据并发的变化而进行分裂合并的性能变差，整个 Flink 的弹性扩缩容就会受到严重的影响。因此在 Flink 1.16 中，对 RocksDB State Backend 的状态重建算法进行了大量优化，使之有 2-10 倍的提升。但这还不是我们的终极方案，后续 Flink 将会对整个状态存储管理体系进行更大的升级，变成一个彻底的存算分离架构来适应云原生环境。我们希望所有的状态数据全部都原生在 HDFS 或者云存储之上，本地磁盘和内存只是状态数据的缓存加速层，构建一套体系化的 Tiered State Backend 系统。接下来分享一下流批一体上的技术创新。流批一体是 Flink 中一个非常有特色的技术理念，Shuffle 是整个分布式计算里非常核心的一个性能相关的技术。在 Flink 的 Shuffle 中，有两种经典的 Shuffle，分别是流式的 Pipeline Shuffle 和批式的 Blocking Shuffle。流式的 Pipeline Shuffle 是任务的上下游，通过网络的方式直接连接进行数据传输。批式的 Blocking Shuffle 是上游将中间数据写到磁盘或者存储服务上，下游通过磁盘或者存储服务下载中间数据。因此在常规的理念中，流执行模式都会用流式 Shuffle，批任务都会用批式 Shuffle。但我们也可以明显的看出，流式 Shuffle 的性能比较高，因为它不经过磁盘 Io，而批式 Shuffle 经过一次磁盘 Io 性能会更差一点。所以我们能不能将流式 Shuffle 也应用在批执行模式或者批任务场景下，加速批式 Shuffle 呢？从技术本身来说是可以的，但在真正生产环境下执行的时候，会发现有一个很大的约束或者不确定性。因为流式 Shuffle 有个前提条件是，上下游或者说一个联通的连通图需要同时拉起。但这就需要更多的资源，而真正在生产环境下是否能有这么多资源是不可保证的，所以就可能有死锁的情况发生。因此是否可以在资源相对充足的情况下，把连通图一起拉起进行流式 Shuffle 加速。而资源不够的情况下，退回到经典的批式 Blocking Shuffle，这样就可以合理的利用资源来进行 Shuffle 加速了。答案肯定是可以的。这也是在 1.16 中推出 Hybrid Shuffle 的背景和思路起因。接下来分享一下最近一两年新提出的概念 Flink CDC，即基于 Flink 的全增量一体数据同步技术。首先介绍一下做 Flink CDC 的原因。Flink 本质上是一款流式的分布式执行引擎或者计算引擎，它在大家心目中已经是连接各种不同存储的数据管道或者数据通道了。Flink 本身具有非常多的技术特色，比如有丰富的 Connector 生态，能够连接各种各样的主流存储系统；有优秀的分布式架构，包括支持 Checkpoint 机制，流批融合机制。这些都是一款全增量一体数据集成引擎所需要的特性。所以我们认为，在 Flink 的肩膀上去构建一款全增量数据同步引擎是特别容易成功的，因此就启动了 Flink CDC 项目。其实在去年 Flink-CDC 1.0 的试水中，整个开发者生态对它都是一个非常正向的反馈。所以今年加大了对 Flink CDC 的投入，推出了更加完善和成熟的 Flink CDC 2.0 大版本和框架。在 2.0 中，我们抽象出了通用的增量快照一致性读取算法。有了它之后，就可以降低接入数据源的成本，加速接入更多的数据源。同时结合整个分布式框架的诸多优势，Flink CDC 已经具备了非常强的能力。比如支持高性能的并行读取，借助 Flink Checkpoint 优势，实现数据断点续传。并通过增量一致性快照读取算法，可以全程对数据库无锁，这样我们在整个全增量一体数据同步的过程中不会对在线业务有任何的影响。从下图中可以看到，Flink-CDC 2.0 已经接入了很多主流的数据源，比如 MySQL 家族，PolarDB，Oracle，MariaDB 等，接入中有 PG，TiDB 和 Ocean Base 等，相信日后会有更多的数据源接入到 Flink CDC 数据同步框架中。在最后一项技术创新中，我分享一下 Flink 在机器学习场景中的子项目 - Flink ML 2.0。大家都知道在老版的 Flink 中有一个模块叫 Flink ML，即 Flink 机器学习算法库。老的 Flink ML 模块是基于 Flink DataSet API 来构建的，但 DataSet API 已经被废弃了。在最近几个版本中，Flink 已经将基础的 API 层全部统一到流批一体的 DataStream API 之上，不再使用 DataSet，所以老版 Flink ML 也相当于被废弃了。去年其实已经预告了要重新建设 Flink ML 成为一个新的 Flink 子项目。今年我们通过努力已经将这件事进行了从 0-1 的孵化和落地，并发布了两个版本，第三个版本也在进行之中。我们都知道机器学习的算法库，它的运算核心是迭代计算框架，因此我们在 Flink ML 2.0 项目中，基于 Flink Data Stream 流批一体的 API，重建了一套流批一体的迭代计算框架。它不仅支持传统的同步迭代训练，也支持异步的迭代训练模型。Flink 不只支持有限数据集的训练，也支持无限流数据集上的在线迭代训练。同时借助 Flink Checkpoint 分布式框架的优势，也支持整个分布式训练断点的异常恢复。这对一些需要长时间运行的训练任务还是有很好的生产意义的。经过一年的努力，在社区版已经对 Flink ML 的算法进行了第一步的完善。阿里云实时计算和机器学习团队共同贡献了 30 多个经典的机器学习算法，覆盖了常见的特征工程场景，明年将会完成所有主流经典 ML 算法库的完善。三、Streaming Data WarehouseFlink 下一步核心演进的方向是 Streaming Data Warehouse。在这之前，为了更好理解，先来回顾一下历史上核心理念的演进的过程。Flink 在诞生的时候，它为什么能击败了上一代流式计算引擎 Storm，受到开发者的青睐，成为新的一代流计算的计算引擎的呢？我觉得关键的核心点是 Flink 是一款有状态的流计算，而 Storm 是一个无状态的流计算引擎。Flink 将 Streaming 计算和状态存储进行有机融合，这样就可以在框架层支持整个流计算状态的精准数据一致性。不仅保持低延迟、高吞吐的流计算能力，还保证了数据一致性，而且是在框架层面保持的，这是 Storm 做不到的。所以 Flink 凭借技术架构上的创新成为了新一代流计算的霸主。但在 Flink 诞生之后的几年，就遇到了一个瓶颈，推广门槛过高。因为大家在早期开发 Flink 的时候，都要写 Java 程序，通过 DataStream 的 API 写 Java 代码，这对很多数据分析师来说门槛还是很高的。因为在整个数据分析师的世界里，标准的语言是 SQL，这也是 Flink 很难推广的一个原因。2019 年，阿里巴巴将自己内部积累的 Blink SQL 贡献给了 Flink 社区，从此 Flink 社区也有了一套非常易用的 Stream SQL。有了 SQL 后大幅降低了开发门槛，所以之后 Flink 的应用得到了爆炸式的增长，这也是为什么大家看到最近这两三年 Flink 出现了一个加速普及的过程。但是 SQL 只能够解决计算层的一些体验问题。即使 Flink 具备流批一体 SQL 的能力，能够实现全量增量开发一体化的体验，但它依然没有办法解决存储层割裂的问题。下一阶段 Flink 社区新的机会点就是继续提升一体化的体验，来实现一套实时数据链路。因此我们可以通过 Flink 的流批一体的 SQL 和流批一体的存储，构建一套真正一体化体验的流式数仓- Streaming Data Warehouse。在 Streaming Data Warehouse 新的理念和形态中，可以保证所有的数据端到端都可以实时流动；整个全链路的开发过程中，用户都可以有全增量一体化的开发体验，并且有统一的数据存储和管理体系。因此如果要去做下一代的 Streaming Data Warehouse 架构。第一步要完善的就是流批一体存储。目前在开源生态中还没有一款真正能够实现，高性能流读流写、批读批写的流批一体存储。因此 Flink 社区去年推出了全新子项目 Table Store，它的定位就是实现流批一体的存储能力。它的特点是能实现高性能的流读流写、批读批写，所以我们把 Table Store 的数据表称为动态表。Table Store 的设计完全遵循现在新一代存算分离的理念，可以把数据存储在 HDFS 或者主流云存储上。它的核心存储格式是由 Lake Store 和 Log Store 两部分组成。在 Lake Store 中，应用了很多经典的数据结构，比如 LSM 和 ORC，以及一系列索引技术。LSM 技术比较适合大规模数据更新，ORC 的列存技术配合一些索引，适合高性能的数据读取。在 Log Store 中，提供了完整 CDC 语义的 Changelog，这样配合 Flink 的 SQL 就可以增量订阅 Table Store，进行流式的数据分析了。整个 Table Store 的数据体系是完全开放的，它除了可以默认对接 Flink 之外，它也能对接 Spark、Hive、Trino 等这些主流的开源计算引擎。Table Store 在 Flink 社区已经发布了两个版本，0.1 和 0.2。目前除了阿里巴巴以外，字节跳动等一些公司也参与了项目的共建。接下来看一下经过两个版本发布，Table Store 在真正场景下的流读、流写、批读、批写的性能怎么样。我们做了一个性能测试，将 Table Store 和目前最主流的数据湖存储 Hudi 进行了对比。整个性能测试的业务场景来自经典的 TPC-H，利用 TPC-H 的工具产生 6000 万条订单数据，写入到 MySQL 的订单表中，模拟一个真实的业务行为。然后利用 Flink CDC 做数据同步，将 MySQL 的数据同步到数据湖仓表中。一条链路将它写入到 Apache Hudi 里，一条链路写入到 Table Store。然后去测试、对比一下，两个不同技术数据更新的性能差异，同时我们再用 Flink SQL 对这两张数据表进行查询。在测试结果中，我们可以看到 Table Store 的更新性能非常优秀，明显领先了 Hudi 的更新能力。在数据查询的性能上明显领先了 Hudi 的 MOR 模式，比较接近 COW 模式，综合性能上可以看出 Table Store 流批一体的读写性能还是非常优秀的。四、流式数仓 Demo为了让大家更好的理解 Streaming Data Warehouse 这个新理念，制作了一个 demo 供大家观看。首先通过 Flink SQL 实时同步到 Table Store，然后构建 ODS, DWD，ADS 层。数据及元数据存储在云上 OSS。demo 使用 TPC-H 数据集，包含两张事实表，主订单 orders，子订单 lineitem，和两张维度表，分别是用户维表 customer、国家维表 nation。主订单表关联用户维表可以得到用户所在国家标识，关联子订单表可以得到订单价格，关联国家维表可得到国家字段。被打宽后的明细表，按年和国家进行聚合即可得到年度国家 GMV 分布。首先创建 MySQL 数据库到 Table Store 的同步任务。第一张是订单明细表 line item。在 Table Store 中，为了更好的区分不同数据层，我们给它加上 ods 前缀。在 with 参数中，我们指定了表的 OSS 存储地址，并设置 auto-create 属性为 true，即自动创建当前表的所在目录。类似的方式声明其余三张表的 DDL，将主订单表、用户维表、国家维表进行同步。在提交任务时，我们使用 statement set 语法，将四张表放在一个任务里进行同步。下面我们开始操作；从模板中心创建同步任务，点击提交准备上线作业。切换到运维界面，准备启动。在同步任务启动后，我们可以开始生成订单明细数据，接下来的动画会演示生成明细数据的过程。首先使用主订单中的 o_orderkey 关联子订单中的 l_orderkey，可以看到主订单中只有 o_orderkey 等于 1 的记录，满足等值条件。这里使用 interval join 让主订单表的下单日期 o_order_date 与子订单表的发货日期 l_shipdate 在 14 天内，可以看到子订单表中只有一条记录满足 interval 条件。同时我们用子订单中的金额字段和折扣字段计算出 GMV 字段 l_revenue。紧接着，我们使用 customer key 与用户维表进行 look up join，得到了用户所在国家的标识 c_nation_key。最后我们与国家维表进行关联，得到了用户所在国家字段。通过一次 interval join 和两次 look up join 订单明细表就构建完成了。接下来我们就可以对明细表按年和国家进行汇总，计算出 GMV 金额。我们同样使用 statement set 语法将明细层和汇总层的计算放在同一个任务里。下面开始生成作业：点击提交，准备上线作业。切换到运维界面准备启动。现在所有任务都在运行中，我们创建临时查询来预览汇总表的数据。随机选取 1993 年，各个国家的 GMV 数据已经展示出来了。在上一步中，我们已经计算并查询了汇总之后的国家 GMV 数据。假设我们接到一个新的需求，要将国家维表中的国家字段从英文转换为中文，进行数据订正。此时我们可以创建 batch 作业，对维表和它所产生的下游表进行 overwrite。从模板中心创建为表订正任务。点击提交准备上线作业，切换到运维界面准备启动。等待作业启动并执行完毕后，按照同样方式对 DWD 和 ADS 表进行 overwrite。在上游数据订正任务都执行完成后，我们重新查询汇总表的数据，可以看出在订正后汇总表的国家已经转化为中文。以上就是本次 demo 的全部内容。点击查看直播回放 & 演讲PPT更多内容Flink Forward Asia 2022 本届 Flink Forward Asia 更多精彩内容，可点击阅读原文或扫描图片二维码观看全部议题的视频回放及获取 FFA 2022 峰会资料！PC 端观看：https://flink-forward.org.cn/ 「建议前往 FFA 2022 大会官网观看全部议题的视频回放」活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-19
Flink 在米哈游的应用实践
摘要：本文整理自米哈游大数据实时计算团队负责人张剑，在 FFA 的分享，本篇内容主要分为三个部分：发展历程和平台建设场景应用实践未来展望点击查看直播回放 & 演讲PPT一、发展历程和平台建设米哈游成立于 2011 年，致力于为用户提供高品质、超出预期的产品和服务。公司陆续推出多款人气产品，如崩坏学园 2、崩坏 3、未定事件簿、原神以及社区产品米游社等。随着公司的快速发展，实时计算需求应运而生。我们基于 Flink 计算引擎构建了实时计算平台。依据需求及主要工作的不同划分为三个阶段。第一阶段，以 Datastream API 开发为主的 Flink 平台。第二阶段，以 Flink SQL 为主的一站式开发平台。第三阶段，一站式开发平台的功能深化和场景覆盖。为什么选择 Flink？首先是基于 Flink 框架优异的特性，如毫秒延迟、窗口计算、状态管理、容错恢复。同时蓬勃发展的社区，对 Flink 的引入充满信心。1.0 阶段主要是以 Datastream API 开发为主，初步具备了任务管理以及运维能力。但随着开发人员增多，基于 Datastream API 开发弊端稍加显现，如开发难度大，版本易冲突、运维难度大等。2.0 阶段为了解决大家的问题，构建了以 Flink SQL 为主的一站式开发平台，主要基于 Flink 1.10 和 1.12。平台的主要工作主要分为如下四个方面：加强多云跨区域任务管理能力的建设。增强 Flink SQL 能力以及丰富上下游连接器。构建指标和日志体系。完善元数据以及任务血缘的管理。基于一站式开发平台较大的提高了大家的开发效率。截止目前，Flink SQL 占比总任务数达 90%以上。随着业务的发展，大家提出了新的期望。总结起来有如下几点：越来越多的同学加入，对任务的调优和调参方面希望能够降低成本。部分业务的流量波动性较大，希望能有任务的自动扩缩容管理机制。部分常见的 ETL 任务，用 Flink SQL 开发也有较大的成本，希望能够基于配置生成 Flink 任务。对数据的时效性有了新的期望，希望数据入仓能够分钟可查，或者基于近实时数仓开发。基于此，3.0 阶段主要是一站式平台开发功能深化和场景覆盖。我们思考的方向主要有如下四个方面：静态和动态资源调优。自动扩缩容。资源弹性能力。加强近实时数仓的建设。静态资源调优指用户开发完一个任务，依据其基本的业务逻辑及探测当前时刻的任务流量，结合本身任务的设置来给定初始资源，同时优化一些不合理的选项，避免用户反复调试。动态调优指一个任务已经上线运行。根据作业收集的指标信息，不断调整任务的资源，来满足任务的正常运行，避免反压及流量波动所带来的影响。从中可以看出，动态调优需要平台具备自动扩缩容的管理机制。而自动扩缩容的管理机制又对底层资源的弹性具有一定的要求。平台的整体架构，主要分三个部分：用户权限及鉴权。功能和服务。主要包含：概览大盘、作业开发、版本管理、作业运维、作业日志、元数据及血缘、监控告警、资源调优、自动扩缩容、弹性资源管理、安全管控。资源和环境。主要包含：多元环境执行端、资源管理器、跨云跨区域的环境管理。二、场景应用实践第一个重要的应用场景是全球游戏日志标准化采集加工。众所周知，日志处理是大数据处理的重要方面，有些日志的重要性不亚于数据库里的数据。Flink 承担着公司全球游戏业务每天近百亿的日志处理，峰值流量过千万。依据采集方式的不同将数据来源分为两大类。通过 Filebeat 的采集。通过日志上报服务接收之后传输到 Kafka 实时数据总线。经过 Flink SQL 处理、加工、写入下游的存储，比如 Clickhouse、Doris、Iceberg。同时，我们会对采集、加工、处理等环节的数据延迟和数据质量加以监控和校正。提供给下游的业务，比如客服查询系统、运营实时分析、离线数仓等。第二个应用场景是实时报表和实时大屏。放到一起是因为它们通常会涉及到聚合指标的计算。我们针对重要的指标，根据业务需求提供实时大屏服务，同时针对运营基于 BI 报表提供实时指标的应用查看，让运营能够及时了解当前游戏的运行状况，方便给业务侧做分析判断。基于实时指标的应用的案例：社区帖子排序。主要用到的是实时指标。社区帖子排序通常会涉及到数据关联，这也是 Flink 比较强项的能力。社区帖子排序的数据主要源于两个方面。第一个是通过客户端埋点上报，通过 Kafka 接收，Flink 通过流式消费 Kafka 来实现数据的接入。第二个是在业务库，比如 MySQL 的分库分表，我们通过 Flink CDC 能够很方便的获取 Binlog 的实时数据，然后将分库分表的数据写入下游 KV 存储，通过另外一个任务进行流表关联，实现数据打宽的目的。但为什么和上图内容不一样呢？这是因为这一常见链路有两个弊端。第一个是引入了 KV 存储，如 Hbase，任务链路的复杂度就会提高。第二个是这里假定流的速度慢于维表更新的速度，否则就会导致数据关联不上。为了解决这些问题，我们在 Flink SQL 中将流表关联任务和 Flink CDC 任务在同一个任务里进行接入，采用的是 Regular Join 的方式。这里可能就会有同学会有疑问，用 Flink SQL 需要设置一个统一的状态过期时间，那么维表状态数据会被清理掉，这样不就没办法进行关联了吗？这里我们拓展了 Flink SQL 的能力，能够在 SQL 层面控制底层状态细化的生存周期。比如可以将维表的状态设置为不过期，从而实现数据关联，之后再经过指标计算，提供给后端帖子排序服务做前端展示。第三个应用场景是近实时数仓。主要有两个方面：第一个方面是离线入仓近实时化改造。以前数据离线入仓往往是通过小时级 ETL 任务进行的，每个小时数据入仓后，下游的调度任务才能够依次启动。对于较大的日志数据，更是可能会耗费 10-20 分钟不等，占据每个小时的 20%~30% 的时间。经过日志入仓近实时化的改造，通过实时任务来写入 Iceberg 表，同时对采集、加工、写入的延迟加以监控，通过日志文件的元信息和实时计算的元信息进行比对来保证数据质量。最后，针对 Iceberg 表建立 Iceberg Manager 管理中心，主要是小文件合并优化、快照清理等。从离线日志近实时数仓改造能得到两个明显的收益。一是离线存储的 IO 从之前的每个小时波动性较大到现在较为平稳，二是数据入仓的时效从以前的每小时到分钟级。第二个方面是数据库数据一键入湖。相较日志，数据库的数据 Schema 相对具有结构化，我们可以自动探测 Schema 一键生成入湖的任务。依托平台的自动调优以及扩缩容的能力，自动提交任务运行。针对数据库的数据同步，主要会分为两条链路。第一个是通过 Flink CDC 进行全量同步写入 Iceberg V2 表，同步时关闭 upsert 功能，保证写入不会产生太多 delete file。第二个是采用 Flink CDC 做增量同步，通过 Flink SQL 再写入同一个 Iceberg V2 表。过程中我们发现，有时候很多任务可能会对同一个数据源进行消费，这一过程会对上游业务库有一定的压力。所以我们做了一定的优化，将 Flink CDC 采集的数据先写入 Kafka。后面如果再有新的任务对同一个数据源消费，会被自动感知，切换到已经同步过数据的 Kafka 上，避免对业务库产生压力。数据库数据一键入湖的收益：一方面是从原来需要经过 Flink SQL 到现在基于配置式任务开发，在开发效率上有较大的提高，另一方面从以前离线的批量拉取，过渡到现在对 Binlog 的实时消费，避免了数据库的压力。下面分享一个近实时数仓的应用案例。如下图所示，这是我们提供的玩家战绩查询，主要是通过 Flink SQL 任务将实时数据写入 Iceberg 表，然后通过实时任务进行排序、计算等操作，写入中间 Iceberg 表，最后通过同步任务将数据同步给战绩服务，给玩家提供查询。第四个应用场景是实时风控。在米哈游，风控团队和实时计算团队联系密切，我们一起拓展了在风控领域的作用。良好的风控服务无疑也是彰显 Flink 在风控领域较为强大的作用，我们基于风控引擎构建了一套相对自动化的任务管理方式，让实时计算平台服务化。首先根据指标规则，自动拆解任务，自动化做任务创建以及任务调优运行。依靠底层的弹性能力能够比较方便的保证任务的正常运行。同时，我们会对计算完成的指标数据以及原始数据实时入湖。经过每个小时做全量指标校验以及线上规则全面监控来保证实时数据的准确性。拓展的应用场景比如登陆校验、游戏反作弊、人机校验等。三、未来展望第一、Flink 奠定了实时计算领域的基础，我们将着重加强平台能力的建设，主要有如下四个方面：加强 Flink SQL 及本身能力的建设，包括流处理、批处理的能力。增强资源调优，包括静态资源调优，动态资源调优。目的是让业务开发人员更多的关注业务本身，而无需关心其他技术性问题。做好自动化运维的工作，降低用户的运维成本。拓展弹性能力。我们现在是基于 Yarn On K8s 的模式，未来我们将推进 Flink Native K8s，借助 K8s 本身优秀的资源管理能力，来实现弹性和更好的应用体验。第二、探索更多的使用场景，有如下三个方面：基于 Flink SQL 实现延迟消息的服务结合 Kafka，就能相对简单的提供给消息队列团队，帮助其更好的发展。基于 Flink CDC 的 Binlog 服务提供给运维团队，助力业务发展。加强应用级别指标能力建设，帮助业务开发团队更好的发展业务。最后，数据湖和 Table Store 的不断实践，主要有如下方面：首先，数据湖正处于高速发展，Table Store 也崭露头角。随着新版本的发布，让我们基于流批一体的生产实践有了基础，我们也在不断探索流批一体的生产实践。其次，在进一步探索近实时数仓的建设。过去离线数仓、实时数仓相对割裂，在建设近实时数仓时，如何基于数据的确定性和数据的无界性，在近实时数仓中得以平衡。比如，我们是否可以基于近数据源产生类似 WaterMark 的一种机制来在流数据上保证一定的确定性，或者是文件的 FileMark 来实现等同于离线批处理的确定性含义呢？另外，离线数仓往往有完善的任务调度和依赖，方便用户进行补数、重跑等操作。那么在建设近实时数仓管理中心的时候，我们是否也需要相应的功能呢？这些都是值得我们探索和思考的地方。点击查看直播回放 & 演讲PPT更多内容Flink Forward Asia 2022 本届 Flink Forward Asia 更多精彩内容，可点击阅读原文或扫描图片二维码观看全部议题的视频回放及获取 FFA 2022 峰会资料！PC 端观看：https://flink-forward.org.cn/ 「建议前往 FFA 2022 大会官网观看全部议题的视频回放」活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-15
Flink Unaligned Checkpoint 在 Shopee 的优化和实践
目录 1. Checkpoint 存在的问题 2. Unaligned Checkpoint 原理介绍 3. 大幅提升 UC 收益 4. 大幅降低 UC 风险 5. UC 在 Shopee 的生产实践和未来规划Flink 做为大数据流计算的标杆，通过 Checkpoint 和 State 保证了 Exactly Once 语义。在生产实践中，Shopee 遇到了很多 Checkpoint 的问题，并尝试引入 Flink 的 Unaligned Checkpoint 去解决。但调研后发现效果与预期有一定差距，所以在内部版本对其进行了深度改进，并将大部分改进已经反馈给了 Flink 社区。本文会介绍 Checkpoint 存在的问题、Unaligned Checkpoint 原理、Shopee 对 Unaligned Checkpoint 的改进、对 Flink 社区的贡献以及内部的实践和落地。点击查看更多技术内容1. Checkpoint 存在的问题1.1 Checkpoint 存在的技术问题Flink 作业反压严重导致 Checkpoint 超时失败是 Flink 生产中普遍存在的问题，而持续的反压会造成长时间没有成功的 Checkpoint。例如：外部查询或写入性能瓶颈、CPU 瓶颈、数据倾斜等在大促或高峰期常见的场景都会间接导致 Checkpoint 持续失败。1.2 Checkpoint 持续失败对业务的影响消费了半小时的 lag 数据，dev 发现这半小时任务的消费速率慢，达不到预期，想调大任务并行度并重启来提升消费能力。如果 Checkpoint 一直失败，则需要从半小时前的 Checkpoint 恢复，这半小时内消费过的数据会被重复消费，导致资源浪费和业务数据可能重复的风险。当消费 lag 时，如果 tolerable-failed-checkpoints（容忍 CP 失败的次数默认是 0）太低，Flink job 可能进入死循环（消费 lag 导致 job 反压严重，反压严重导致 Checkpoint 超时失败，Checkpoint 失败导致 job 失败，job 失败导致消费更多的 lag），lag 永远不能消费完成。无限容忍 Checkpoint 失败不是优雅的解决方案，如果容忍次数太高：生产上的问题不能及时地被发现；一些 Connector 在 Checkpoint 时会提交数据或文件。如果 Checkpoint 持续失败，这些数据或文件长时间不能被提交，它会导致数据延迟和事务超时。例如：Kafka Producer 事务超时会导致事务失败；一旦作业重启，将有大量数据被重复消费。业务高峰和大促与消费 lag 类似，会遇到相同的问题。1.3 引入 Unaligned Checkpoint基于上述背景，很多用户都希望在 Flink 任务有瓶颈（反压严重）时，Checkpoint 可以成功，所以 Flink 社区在 FLIP-76 中引入了 Unaligned Checkpoint 机制（下文简称 UC）。2. Unaligned Checkpoint 原理介绍2.1 UC 核心思路反压严重时，Aligned Checkpoint（下文简称 AC）超时主要在于 Barrier 在数据流中排队。反压严重时，数据流动很慢导致 Barrier 流动很慢，最终导致 AC 超时。UC 的核心思路是：当数据流动很慢时，Barrier 通过某些机制超越数据，从而使得 Barrier 可以快速地从 Source 一路超车到 Sink。2.2 Task 的 UC 流程详解假设当前 Task 上游 Task 并行度为 3，下游并行度为 2。UC 开始后 Task 的 3 个 InputChannel 会陆续收到上游发送的 Barrier。如图所示，灰色框表示 buffer 中的一条条数据，InputChannel-0 先收到 Barrier，其他 InputChannel 还没收到 Barrier。当某一个 InputChannel 接收到 Barrier 时，会直接开启 UC 的第一阶段，即：UC 同步阶段。注意：只要有任意一个 Barrier 进入 Task 网络层的输入缓冲区，Task 直接开始 UC；不用等其他 InputChannel 接收到 Barrier，也不需要处理完 InputChannel 内 Barrier 之前的数据。如下图所示，为了保证数据一致性，UC 同步阶段 Task 不能处理数据，同步阶段会做以下几个事情：Barrier 超车：发送 Barrier 到所有的 ResultSubPartition 的头部，超越所有的 input&output buffer，Barrier 可以被快速发到下游 Task；Buffer 进行快照：对所有超越的 input&output buffer 做快照；调用算子的 snapshotState 方法；Flink 引擎对算子内部的 State 进行快照。有几个注意事项：做 UC 时，Barrier 超越的 buffer 数据直接被跳过了。为了保证数据不丢失，这些 buffer 需要跟 State 一起写到 HDFS，从 Checkpoint 恢复时，这些数据会被消费；同步阶段 Task 不能处理数据，为了尽量减少阻塞的时间，同步阶段只是对 buffer 和状态数据进行一份引用，真正写数据到 HDFS 会通过异步完成；UC 同步阶段的最后两步与 AC 完全一致，对算子内部的 State 进行快照。UC 同步阶段完成后，Task 继续处理数据，同时开启 UC 的第二个阶段：Barrier 对齐和 UC 异步阶段。异步阶段将同步阶段浅拷贝的 State 以及 buffer 写到 HDFS 中。为什么 UC 还有 Barrier 对齐呢？当 Task 开始 UC 时，有很多 InputChannel 没接收到 Barrier，这些 InputChannel 的 Barrier 之前可能还会有 network buffer 需要进行快照，所以 UC 第二阶段需要等所有 InputChannel 的 Barrier 都到达，且 Barrier 之前的 buffer 都需要快照。可以认为 UC 需要写三类数据到 HDFS 上：同步阶段引用的所有 input&output buffer；同步阶段引用的算子内部的 State；同步阶段后其他 InputChannel Barrier 之前的 buffer。异步阶段把这三部分数据全部写完后，将文件地址汇报给 JobManager，当前 Task 的 UC 结束。注：理论上 UC 异步阶段的 Barrier 对齐会很快。如上述 Task 所示，Barrier 可以快速超越所有的 input&output buffer，优先发送 Barrier 给下游 Task，所以上游 Task 也类似：Barrier 超越上游所有的 buffer，快速发送给当前 Task。2.3 UC 实践中的问题当任意一个 Barrier 进入 Task 网络层的输入缓冲区时，Task 直接开始 UC。Barrier 快速超越所有的 buffer 被发送到下游，所以 UC 不受反压影响。理论上：无论反压有多严重，UC Barrier 都可以一路超车，快速从 Source 流到 Sink，每个 Task 都可以快速完成快照。理论很美好，但我们在实际调研和任务使用过程中，发现 UC 效果达不到预期：在很多场景，任务反压严重时，UC 仍然不能成功，导致 UC 预期收益大打折扣；UC 会显著增加写 HDFS 的文件数，对线上服务的稳定性有影响，增加了大范围应用的难度；UC 存在一些 bug。后续部分会介绍上述问题，以及 Shopee 的解决方案和对社区的贡献。3. 大幅提升 UC 收益Task 在处理数据的过程中不能处理 Checkpoint，必须将当前处理的这条数据处理完并将结果写入到 OutputBufferPool 中，才会检查是否 InputChannel 有接收到 UC Barrier，如果有则开始 UC。如果 Task 处理一条数据并写结果到 OutputBufferPool 超过 10 分钟，那么 UC 还是会超时。通常处理一条数据不会很慢，但写结果到 OutputBufferPool 可能会比较耗时。从 OutputBufferPool 的视角来看，上游 Task 是生产者，下游 Task 是消费者。所以下游 Task 有瓶颈时，上游 Task 输出结果到 OutputBufferPool 会卡在等待 buffer，不能开始 UC。为了解决这个问题，Flink 社区在 FLINK-14396 中引入了预留 buffer 的机制。解决思路是：Task 处理数据前检查 OutputBufferPool 是否有空闲的 buffer，如果没有空闲 buffer 则继续等待。详细流程如下图所示。等 OutputBufferPool 中有空闲 buffer 了才去处理数据，来保证 Task 处理完数据后可以顺利地将结果写入到 OutputBufferPool 中，不会卡在第 5 步数据输出的环节。优化后如果没有空闲 buffer，Task 会卡在第 3 步等待空闲 buffer 和 UC Barrier 的环节，在这个环节当接收到 UC Barrier 时可以快速开始 UC。3.1 处理一条数据需要多个 buffer 场景的提升如下图所示，由于只预留了一个 buffer，当处理一条数据需要多个 buffer 的场景，Task 处理完数据输出结果到 OutputBufferPool 时可能仍然会卡在第 5 步，导致 Task 不能处理 UC。例如：单条数据较大、flatmap、window 触发以及广播 watermark 都是处理一条数据需要多个 buffer 场景，这些场景下 Task 卡在第 5 步数据输出环节，导致 UC 表现不佳。解决这个问题的核心思路还是如何让 Task 不要卡在第 5 步而是卡在第 3 步的等待环节。基于上述问题，Shopee 在 FLIP-227 提出了 overdraft（透支） buffer 的提议，思路是：处理数据过程中，如果 buffer 不足且 TaskManager 有空余的 network 内存，则当前 Task 的 OutputBufferPool 会向 TM 透支一些 buffer，从而完成第 5 步数据处理环节。注：OutputBufferPool 一定是在没有空闲 buffer 时才会使用透支 buffer。所以一旦透支 buffer 被使用，Task 在进行下一轮第 3 步进入等待 Barrier 和空闲 buffer 的环节时，Task 会认为 OutputBufferPool 没有空闲 buffer，直到所有透支 buffer 都被下游 Task 消费完且 OutputBufferPool 至少有一个空闲 buffer 时，Task 才会继续处理数据。默认 taskmanager.network.memory.max-overdraft-buffers-per-gate=5，即：Task 的每个 OutputBufferPool 可以向 TM 透支 5 个 buffer。引入透支 buffer 机制后，当 TM network 内存足够时，如果处理一条数据需要 5 个 buffer，则 UC 完全不会卡住。如果 TM 的 network 内存比较多，可以调大参数兼容更多的场景。Flink-1.16 开始支持透支 buffer 的功能，涉及到的 JIRA 有：FLINK-27522、FLINK-26762、FLINK-27789。3.2 Legacy Source 的提升从数据的来源划分有两种 Task，SourceTask 和非 SourceTask：SourceTask 从外部组件读数据到 Flink Job 中，非 SourceTask 从 InputChannel 中读数据，数据来源于上游 Task。非 SourceTask 从 InputChannel 读数据之前会对 OutputBufferPool 进行检查，有空闲 buffer 才会读取。SourceTask 从外部组件读取数据前如果不检查 OutputBufferPool 是否有空闲 buffer，则 UC 会表现不佳。Flink 有两种 Source，分别是 Legacy Source 和新 Source：新 Source 与 Task 的工作模式是拉的模式，即：Task 向 Source 拉数据，工作模式跟 InputChannel 类似，Task 会检查 OutputBufferPool 有空闲 buffer 后，再从 Source 中拉数据。Legacy Source 是推的模式，即：Legacy Source 从外部组件读到数据后直接往下游发送，当 OutputBufferPool 没有空闲 buffer 时，Legacy Source 就会卡住，不能正常处理 UC。然而，我们生产环境几乎所有 Flink job 仍在使用 Legacy Source，由于 Legacy Source 已经被 Flink 社区废弃不再维护，所以 Shopee 内部对常用的 Legacy Source 做了改进。改进思路与上述思路类似：Legacy Source 检查 OutputBufferPool 有空闲 buffer 后，再往下游发数据。Flink 中最常用的 FlinkKafkaConsumer 其实就是 Legacy Source，所以业界很多 Flink 用户都仍在使用 Legacy Source。我们将内部改进版的 Legacy Source 分享到了 FLINK-26759。4. 大幅降低 UC 风险经过上述优化，反压严重时 UC 在 Legacy Source 和消费一条数据需要多个 buffer 的场景也可以快速成功，已经达到了一些 Flink 用户的预期效果，但 UC 仍然达不到大规模生产的标准。主要在于 UC 相比 AC 会写 network buffer 到 Checkpoint 中，所以引入了一些额外风险：会写更多的文件到 HDFS，给 NameNode 造成额外压力；数据的 schema 升级以后，如果序列化不兼容，则数据无法恢复；当算子之间的连接发生变化时，算子之间的 buffer 数据无法恢复（例如：从 rebalance 改为 forward）。4.1 无法顺利地从 AC 切换成 UC用户希望既可以规避这些风险，又可以享受 UC 带来的收益，所以 Flink 社区引入了 Aligned checkpoint timeout 机制，即：默认 Checkpoint 是 AC，如果 AC 在指定时间内不能完成，则切换成 UC。引入 AC timeout 机制后，UC 的风险并没有完全规避，只是在任务没有反压的情况下，仍然是 AC，不存在额外的风险。当反压严重 AC 会失败时，切换成 UC 来保证 Checkpoint 可以成功。我们假设 AC timeout = 1min 且 Checkpoint timeout = 5min，即：Checkpoint 仍然以 AC 开始，AC 一分钟不能成功则切换成 UC，Checkpoint 总时长超过 5 分钟就会超时失败。AC timeout 的发展总共有三个阶段，前两个阶段并达不到预期目标，即：1 分钟时间到了，Job 仍然不能从 AC 切换为 UC，甚至 5 分钟都不能切换成 UC 最终导致 Checkpoint 超时失败。我们可以带着目标去了解这三个阶段。4.2 InputChannel 支持从 AC 切换为 UCFLINK-19680 首次支持了 AC timeout 机制，第一阶段的原理是：每个 Task 从接收到第一个 Barrier 开始计时，如果 Task 内 AC Barrier 对齐时间超过 AC timeout，则当前 Task 从 AC 切换为 UC。该机制存在的问题是：当 Job 的 Task 数较多，从 Source 到 Sink 要经过 10 个 Task。假设 10 个 Task 内部 Barrier 对齐时间都是 59 秒，则所有 Task 都不会切换成 UC，但 10 个 Task 都需要对齐，Checkpoint 总时长至少需要 590 秒（大于 5 分钟），所以最终 Checkpoint 仍然超时失败。基于阶段一的问题，FLINK-23041 进行了改进，第二阶段的原理是：Barrier 中携带 Checkpoint 开始的时间戳，当 InputChannel 收到 Barrier 后，用当前系统时间减 Checkpoint 开始的时间表示 Checkpoint 已经过去多久了：如果已经超过 1 分钟，直接切换成 UC；如果少于 1 分钟，则用 1 分钟减 AC 已经消耗的时间，表示希望多久以后切换成 UC。设定一个定时器，时间到了，就会切换成 UC。阶段二相比阶段一，解决了多个 Task 时间累加的问题，只要 InputChannel 接收到 Barrier，在指定时间内 AC 没有完成，就可以定时将 AC 切换成 UC。4.3 Output buffer 支持从 AC 切换为 UC阶段二完成后，可以认为 InputChannel 已经较好地支持了 AC 切换为 UC。但存在的问题也很明显，即：output buffer 不支持从 AC 切换为 UC。如果任务反压严重，Barrier 在 output buffer 中排队，如果在 5 分钟内 Barrier 不能发送到下游 Task 的 InputChannel，则 Checkpoint 仍然会超时。基于这个问题，Shopee 在 FLINK-27251 和 FLINK-28077 提出了支持 output buffer 从 AC 切换成 UC 的改进。设计思路是：如果开启了 UC 且当前是 AC，则发送 Barrier 到 output buffer 的尾部。但过一会 AC 可能需要转换为 UC，所以需要设定一个定时器。如果定时器时间到了 Barrier 还在 output buffer 中排队，则将 AC 转换为 UC：Barrier 超车到 output buffer 头部，且图中超越的浅蓝色 buffer 需要被快照写到 Checkpoint 中。社区早期为 Checkpoint 设计了 Benchmark 用来评估 Checkpoint 的性能，如下图所示，该优化 merge 到 Flink master 分支后 UC 的性能提升了 11 倍。4.4 UC 小文件合并开启 AC timeout 机制后，Flink 可以做到反压不严重时使用 AC，反压严重时顺利切换成 UC。大大降低了 UC 的额外风险，也可以在反压严重时享受 UC 带来的收益。但在大规模生产中，仍然有风险。默认 Flink 每个 Subtask 为 buffer 写一个文件，假设任务有 10 个 Task，每个 Task 并发为 1000，则 UC 可能会额外写 1 万个小文件。假设 Kafka 集群出现故障或瓶颈，大量 Flink Job 写 Kafka 慢，会导致大量 Flink 任务从 AC 切换成 UC。这种情况大量任务瞬间写数十万的小文件到 HDFS，可能导致 NameNode 雪崩。为了解决小文件问题，Shopee 在 FLINK-26803 和 FLINK-28474 中提出了合并 UC 小文件的改进。优化思路：多个 Task 共享同一个文件。每个 Task 不再单独创建文件，而是向 CheckpointStreamManager 获取文件流。CheckpointStreamManager 会为 n 个 Task 分配一个文件，默认 channel-state.number-of-tasks-share-file=5，即：5 个 Task 共享一个 UC 文件，UC 文件个数就会减少 5 倍。多个 Task 同时写同一个文件会有线程安全问题，所以写文件时要对文件流进行加锁来保证多个 Task 串行写文件。从生产经验上来看，大量的 UC 小文件在 1MB 以内，所以 20 个 Task 共享一个文件也是可以接受的。当然，如果 NN 压力非常小且 Flink Job 更追求写效率，可以设置该参数为 1，表示 Task 不共享 UC 文件。当前 UC 小文件合并的功能我们还在给社区贡献中。4.5 修复 network buffer 死锁Shopee 对 UC 相关的贡献还包括：在 FLINK-22946 中解决了回收 network buffer 时的死锁问题。5. UC 在 Shopee 的生产实践和未来规划5.1 UC 生产实践为了规避 UC 带来的额外风险，Shopee 内部将 aligned-checkpoint-timeout 设置为 1 分钟，表示任务反压不严重，如果 AC 可以在 1 分钟以内完成，则使用 AC。当反压严重 AC 在 1 分钟以内不能完成时，才切换为 UC。Shopee Flink 平台的开发页面也增加了 UC 的开关，用户可以选择是否为作业开启 Unaligned Checkpoint，目前已有上百个 Flink 任务开启 UC，且目前使用 UC 的作业表现良好，反压时 UC 也可以成功。5.2 UC 未来规划我们会持续关注用户在 UC 上遇到的问题，待稳定运行数月后，可以考虑开启 AC timeout 的前提下为全量任务开启 UC。Shopee 内部版本对 Flink 调度和 network 内存模块有较大改动，可以精确计算 TM 需要的 network 内存，未来会为 UC overdraft buffer 预留单独的内存。点击查看更多技术内容活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-14
Flink 1.16：Hive SQL 如何平迁到 Flink SQL
摘要：本文整理自 Apache Flink PMC&Committer 伍翀（云邪）在 9 月 24 日 Apache Flink Meetup 的演讲。主要内容包括：Hive SQL 迁移的动机Hive SQL 迁移的挑战Hive SQL 迁移的实践Hive SQL 迁移的演示未来规划点击查看直播回放 & 演讲PDF一、Hive SQL 迁移的动机Flink 已经是流计算的事实标准，当前国内外做实时计算或流计算一般都会选择 Flink 和 Flink SQL。另外，Flink 也是是家喻户晓的流批一体大数据计算引擎。然而，目前 Flink 也面临着挑战。比如虽然现在大规模应用都以流计算为主，但 Flink 批计算的应用并不广泛，想要进一步推动真正意义上的流批一体落地，需要推动业界更多地落地 Flink 批计算，需要更积极地拥抱现有的离线生态。当前业界离线生态主要以 Hive 为主，因此我们在过去版本中做了很多与 Hive 相关的集成，包括 Hive Catalog、Hive 语法兼容、Hive UDF 兼容、流式写入 Hive 等。在 Flink 1.16 版本中，我们进一步提升了 HiveSQL 的兼容度，还支持了 HiveServer2 的协议兼容。所以，为什么 Flink 要去支持 Hive SQL 的迁移？一方面，我们希望吸引更多的 Hive 离线数仓用户，通过用户来不断打磨批计算引擎，对齐主流批计算引擎。另一方面，通过兼容 Hive SQL，来降低现有离线用户使用 Flink 开发离线业务的门槛。除此之外，另外，生态是开源产品的最大门槛。Flink 已经拥有非常丰富的实时生态工具，但离线生态依然较为欠缺。通过兼容 Hive 生态可以快速融入 Hive 离线生态工具和平台，降低用户接入的成本。最后，这也是实现流批一体的重要一环，我们希望推动业界尝试统一的流计算和批计算引擎，再统一流计算和批计算 SQL。从用户角度来看，Hive SQL 为什么要迁移到 Flink SQL 上？对于平台方而言，统一流批计算引擎，只需维护一套 Flink 引擎，可以降低维护成本，提升团队研发效率。另外，可以利用 Flink + Gateway+ HiveSQL 兼容，快速建设一套 OLAP 系统。Flink 的另一优势是拥有丰富的 connector 生态，可以借助 Flink 丰富的数据源实现强大的联邦查询。比如不仅可以在 Hive 数仓里做 ad-hoc 查询，也可以将 Hive 表数据与 MySQL、HBase、Iceberg、Hudi 等数据源做联邦查询等。对于离线数仓用户而言，可以用 Hive SQL 写流计算作业，极大降低实时化改造成本。使用的依然是以前的 HiveSQL 语法，但是可以运行在 streaming 模式下。在此基础之上也可以进一步探索流批一体 SQL 层以及流批一体数仓层的建设。二、Hive SQL 迁移的挑战但是 Flink 支持 HiveSQL 的迁移面临着很多挑战，主要有以下三个方面：兼容：包括离线数仓作业和Hive平台工具的兼容。主要对应用户层的兼容和平台方的兼容。稳定性：迁移后的作业首先要保证生产的稳定性。我们在1.16中也做了很多这方面的工作，包括FLIP-168 预测执行和Adaptive Hash Join。后续我们会发表更多的文章来介绍这方面的工作。性能：最后性能也是很重要的，在1.16中我们也做了很多这方面的工作，包括Dynamic Partition Pruning（DPP）、元数据访问加速等，后续也会发表更多文章来介绍这方面的工作。接下来我们重点讲解下 Hive 兼容相关的工作。Hive 语法的兼容并没有完全造出一套新的 SQL 引擎，而是复用了 Flink SQL 的很多核心流程和代码。我们抽象出了可插拔的 parser 层来支持和扩展不同的语法。Flink SQL 会经过 Flink Parser 转换成 Flink RelNode，再经过 Logical Plan 优化为 Physical Plan，最后转换为 Job Graph 提交执行。为了支持 Hive 语法兼容，我们引入了 Hive Parser 组件，来将 Hive SQL 转化成 Flink RelNode。这个过程中，复用了大部分 Hive 现有的 SQL 解析逻辑，保证语法层的兼容（均基于 Calcite）。之后 RelNode 复用同样的流程和代码转化成 LogicalPlan、Physical Plan、JobGraph，最后提交执行。从架构上看，Hive 语法兼容并不复杂，但这是一个“魔鬼在细节”的工作。上图为部分 Flink1.16 版本里 Flink Hive 兼容相关的 issue，涉及 query 兼容、类型系统、语义、行为、DDL、DML、辅助查询命令等非常多语法功能。累计完成的 issue 数达近百个。Flink1.16 版本将 Hive 兼容度从 85% 提升至 94.1%。兼容度测试主要依靠 Hive qtest 测试集，其中包含 12,000 多个测试 case，覆盖了 Hive 目前所有主流语法功能。没有兼容的一部分包括 ACID 功能（业界使用较少），如果除去 ACID 功能，兼容度已达 97%以上。SQLGateway 是 Flink SQL 的 server 层组件，是单独的进程，对标 HiveServer2 组件。从 Flink 整体架构上看，SQLGateway 处于中间位置。向下，封装了用户 API 的 Flink SQL 和 Hive SQL。不管是 Flink SQL 还是 Hive SQL，都使用 Flink 流批一体的 Runtime 来执行，可以运行在批模式，也可以运行在流模式。Flink 的资源也可以部署运行在 YARN、K8S、Flink standalone 集群上。向上，SQLGateway 提供了可插拔协议层 Endpoint，目前提供了 HiveServer2 和 REST 两种协议实现。通过 HiveServer2 Endpoint，用户可以将 Hive 生态的很多工具和组件（Zeppelin、Superset、Beeline、DBeaver 等）连接到 SQL Gateway，提供流批统一的 SQL 服务并兼容 Hive SQL。通过 REST 协议可以使用 Postman、curl 命令或自己通过 Python、Java 编程来访问，提供完善和灵活的流计算服务。将来，Endpoint 能力也会继续扩展，比如可以提供更高性能的 gRPC 协议或兼容 PG 协议。三、Hive SQL 迁移的实践目前快手正在与 Flink 社区紧密合作，推进流批一体的落地。目前快手迁移 Hive SQL 作业到 Flink SQL 作业已经取得了初步的进展，已有上千个作业完成了迁移。快手的迁移主要策略为双跑平台，已有业务继续运行，双跑平台有智能路由组件，可以通过指定规则或 pattern 识别出作业，投递到 MapReduce、Spark 或 Flink 上运行。初期的运行较为谨慎，会通过白名单机制指定某些作业先运行在 Flink，观察其稳定性与性能，对比其结果一致性，后续逐步通过规则来放量。更多的实践经验与细节可以关注 Flink Forward Asia 2022 上分享的《Hive SQL 迁移到 Flink SQL 在快手的实践》。四、Hive SQL 迁移的演示Demo1：Hive SQL 如何迁移到 Flink SQL接下来演示一下 Hive SQL 如何迁移到 Flink SQL。我们已经搭建好一个 YARN 集群，以及 Hive 相关组件，包括 HiveServer2 的服务。我们使用 Zeppelin 做数据可视化和 SQL 查询。我们将演示 Hive SQL 迁移到 Flink SQL 只需改一行地址，Zeppelin 体验并无二致，SQL 也无需修改。完整的 Demo 视频请观看完整的演讲视频： https://www.bilibili.com/video/BV1BV4y1T7d4首先在 Zeppelin 中配置 Hive Interpreter，填入 HiveServer2 的 JDBC 地址和端口、用户名密码、Driver 等信息。使用当前的 Hive Interpreter，我们可以通过 Hive DDL 命令创建一张打宽的 store_sale_detail 表。使用 Hive SQL 语法关联 store_sales、date_dim、store 三张表，打成一张宽表写到 store_sale_detail。执行该 INSERT INTO 语句后，便能在 Hadoop 平台上看到运行起来的 MapReduce 任务。store_sale_detail 明细宽表生产完后，我们就可以进行查询分析，比如查看星期天每个店铺的销量。运行完后可通过饼图等多种形式展示结果。上面简单演示了使用 Hive 进行数据生产和数据分析，其中计算引擎使用的是 Hive 原生的 Hadoop MapReduce 作业，作业运行在 YARN 集群上。接下来我们开始迁移到 Flink SQL，作业仍然运行在 YARN 集群上。首先搭建 Flink SQL 集群以及启动 SQLGateway。我们已经下载并解压了 Flink 1.16 版本。其中 lib 文件夹下也已经提前准备 Hive connector、JDBC connector 和 MySQL Driver。另外，还需要将 flink-table-planner-loader 与 opt/ 目录下的 flink-table-planner JAR 包做个替换，然后启动 YARN session 集群。Session 集群启动后，可在 yarn 上看到 Flink 的 session application。在启动 SQLGateway 之前，需要先修改配置，主要配置 HiveServer2 Endpoint 相关的信息。此处 SQLGateway 的 endpoint type 是 HiveServer2，以及需要额外设置三个配置：HiveServer2 的 hive-conf-dir、thrift.host 以及 thrift.port。这里注意我们启动的端口号是 20002。然后通过 sql-gateway.sh start 命令启动 SQL Gateway 服务。启动后便可以进行迁移。因为 HiveServer2 运行在同一台机器上，因此只需修改端口号即可。将此处 10000 端口号改为刚刚启动的 20002 端口号，即 Flink SQLGateway 的端口，无需进行任何其他改动。重启 interpreter，迁移完成！接着我们可以在 Zeppelin 中重新执行一遍刚刚的 Hive SQL 语句，可以发现结果都是一致的。如上图所示，是查询每个商店在周日的销售总额的结果，其饼图结果与使用 Hive 引擎查询的结果完全一致，不同的是这次的查询是运行在 Flink 引擎之上。Hive SQL 迁移到 Flink SQL 后不仅能获得更好的性能，还能获得 Flink SQL 提供的额外能力，包括更丰富的联邦查询和流批一体能力。我们可以用 Flink DDL 创建新的 catalog，比如 MySQL 表里还有新的额外的维度信息，不在 Hive 中，希望关联它做新数据的探查。只需使用 Flink 的 CREATE CATALOG 语句创建 MySQL catalog，即可实现联邦查询。同时，Flink 会将能下推的 projection、filter 等都下推到 MySQL 进行裁剪。除此之外，也可以使用 Hive SQL 体验流计算的能力。使用 Flink 语法创建一张 datagen 表，该表会源源不断产生随机数据。再切回 Hive 语法创建一张 Hive 结果表 sink。将运行模式改为 streaming，执行 insert into 语句，便提交了一个流作业，该作业会源源不断地将 datagen 中生成的数据流式地写入 Hive。为了验证 Hive 结果表一直在被流作业写入数据，我们也可以用 Hive 语法查询写入的表。如上图所示，通过不断执行 count(*) 语句，可以看到该表一直在写入数据，因此查询结果会不断变化。五、未来规划未来，Flink 将在以下三个方面持续演进：第一，持续在 batch 上做更多尝试和投入，提升 batch 的稳定性和性能，目标是短期内能够追齐主流的批计算引擎。第二，完善数据湖的分析，比如更高效的批式数据湖读写、查询优化下推、列存上的读写优化，Iceberg、Hudi 以及 Flink Table Store 的支持等。另外，也会提供丰富的湖上数据查询和管理功能，比如查询快照版本的能力、查询元数据、更丰富的 DML 语法（UPDATE、DELETE、MERGE INTO）以及管理湖上数据 CALL 命令等。第三，Flink Batch 生态建设，包括进一步完善 Remote Shuffle Service、血缘管理等。Q&AQ：Hive 写通过 Flink 执行，如果 Hive 数据量特别大，是否会出现内存不足、OOM 等报错？A：目前 Flink 执行 batch 模式下，基本所有算子里都有内存管理机制。数据不是以 Java 对象的方式存在 Flink，而是在 Java 内存里面开辟了单独的内存空间供其使用。如果内存满，则会做落盘、spill，速度可能会略微下降，但一般不会发生内存 OOM。Q：Flink 是否支持 Hive 自定义 UDF 函数？迁移成本如何？A：支持，可直接迁移。Q：现有的离线数仓从 Hive 迁到 Flink 是否存在风险？平滑迁移的注意点有哪些？A：平滑迁移目前大多使用双跑平台，通过机制挑选出部分作业先进行迁移，迁移的作业在两个平台同时运行，因此需要验证行为、结果是否一致，然后逐渐将老平台的作业下线，变为单跑。整个过程需要循序渐进，通常需要半年至一年的时间。Q：Demo 中有一个 SQL 查询使用了 Hive on MR 引擎，迁移之后是走 Flink SQLGateway 还是 Hive on MR 模式?A：迁移后，因为配置的端口是 Flink SQL Gateway 的端口，所以 SQL 请求走的是 Flink SQL Gateway，Gateway 会将 Hive SQL 编译成 Flink 作业提交到 YARN 集群上运行。Q：Flink 运行批量任务时，TaskManager 个数是我们指定还是自动生成？A：对于 standalone 模式，包括运行在 k8s 上的 standalone 模式，TM 数量由用户指定。其他模式下，TM 数量都由 Flink 自己决定和拉起，包括 yarn/k8s application 模式，yarn session 模式, yarn per-job 模式，native k8s session 模式。拉起的 TM 数量和作业请求的 slot 数相关，taskmanager.numberOfTaskSlots 参数决定了 slot 与 TM 个数的映射关系，slot 数量则和被调度的作业节点的并发度相关。Q：Flink 运行在 K8S 上时，如果启用了动态资源分配，shuffle 数据会一直保存在 POD 磁盘上吗？A：可以选择，可以 on TM 也可以 on RemoteShuffleService。Q：离线作业迁移后，是否还支持 with as 语法以及 partition by 语法？A：WITH AS 语法依然支持，CREATE TABLE 中的 PARTITIONED BY 语法也仍然支持。点击查看直播回放 & 演讲PDF Flink 1.16.0 已如期发布，欢迎大家体验和使用 Hive SQL 迁移的能力，也欢迎加入【Flink Batch 交流群】交流和反馈相关的问题和想法。活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-12-05
FFA 2022 收官总结｜活动报告出炉，实时即未来！
作为开源大数据领域的顶级峰会，Flink Forward 集结了无数优秀的行业实践和领先的技术动态，始终拥抱未来。2022 年 11 月 27 日，第五届 Flink Forward Asia 大会 —— Flink Forward Asia 2022 完美收官。此次 FFA 2022 由阿里云计算平台事业部主办，美的、米哈游、Disney 、字节跳动、运满满、美团、快手、蔚来汽车等全球 40+ 一线厂商共同参与，为开发者们带来了一场干货满满的技术盛宴。更多内容Flink Forward Asia 2022 本届 Flink Forward Asia 更多精彩内容，可点击阅读原文或扫描图片二维码观看全部议题的视频回放及获取 FFA 2022 峰会资料！PC 端观看：https://flink-forward.org.cn/ 「建议前往 FFA 2022 大会官网观看全部议题的视频回放」活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-28
Flink Forward Asia 2022 主论坛概览
2022 年 11 月 26-27 日，Flink Forward Asia（FFA）峰会成功举行。Flink Forward Asia 是由 Apache 软件基金会官方授权、由阿里云承办的技术峰会，是目前国内最大的 Apache 顶级项目会议之一，也是 Flink 开发者和使用者的年度盛会。由于疫情原因，本届峰会仍采用线上形式。此外，本次峰会上还举行了第四届天池实时计算 Flink 挑战赛的颁奖仪式，4346 支参赛队伍中共有 11 支队伍经过层层角逐脱颖而出，最终收获了奖项。FFA 大会照例总结了 Apache Flink 过去一年的发展情况。2022 年，Apache Flink 社区继续保持快速发展：Github Star 数突破 2 万；代码贡献者总人数超过 1,600 人；单月下载量突破 1,400 万次。其中，Apache Flink 中文社区的发展尤为蓬勃：据 ossinsight.io 统计截至目前 Apache Flink 项目所有 PR 中有 45% 来自中国开发者；由 Apache 软件基金会授权、Apache Flink PMC 管理的官方微信公众号，2022年 共发布了 130+ 篇技术分享文章，累计订阅用户数突破 6 万；新开通的微信视频号发布了36 篇视频，目前已有近 4,000 订阅用户。我们欣喜地看到，Apache Flink 已成为实时流计算全球范围事实标准。Flink 凭借强大的实时化大数据计算能力，与众多开源社区生态项目的强强联合，形成了实时大屏展示、实时数据集成、实时湖仓分析、实时个性化推荐、实时风控监控等一系列实时化大数据场景的解决方案，成为了推动各行各业数据分析实时化升级的核心推动力。本文接下来将对本次 FFA 峰会主论坛几个 Keynotes 议题进行简单的归纳总结，感兴趣的小伙伴可以到官网观看大会全部议题的视频回放。云与开源，共植数字世界的根在 Keynotes 议题开始之前，阿里巴巴集团副总裁、阿里巴巴开源技术委员会负责人、阿里云智能计算平台负责人贾扬清老师作为开场嘉宾，分享了他对云与开源关系的理解。在产业数字化、数字产业化的今天，云和开源已经共生、共长、共筑了一个数字世界的根。开源与商业化如何更好地结合，我们认为云是其中最重要的一环。云为开源软件的部署和获取提供了更好的环境，在云提供的弹性环境中，用户可以一键获得开源软件与平台的能力。云和开源软件的共生，也使得用户能有更加广阔和灵活的选择，每个人都能够寻找到最适合的开源软件组合来解决自身业务问题。在这个发展的过程中，逐渐形成了云原生的概念。在过去的十几年中，阿里巴巴一直是开源软件和社区的坚定拥护者和实践者，形成了“三位一体”的策略：开源社区的技术、阿里巴巴内部应用的技术以及在阿里云上通过商业化形式提供给客户的技术是统一的。开源提供了非常好的用户体验，在阿里巴巴这样的大规模场景中能够产生很多个性化或系统化的需求，二者的关注点形成互补。阿里巴巴将自己的最佳实践贡献回开源社区，使得社区的易用性与大规模企业所使用的稳定性、弹性能够很好地结合。以 Apache Flink 为例，阿里巴巴在 2016 年开始采用 Flink 作为内部实时计算的一条技术路线，并基于 Flink 建设了 Blink 这样一个内部体系。从 16 年开始，我们逐渐将 Blink 贡献回社区，至 18 年已成为 Flink 社区最大的贡献者。今天我们欣喜地看到，Apache Flink 项目管理委员会中有 1/4 的成员来自阿里巴巴，通过阿里巴巴的推动以及整个社区的合作，Flink 已经被中国绝大多数的互联网企业作为流计算的事实标准来采用，Flink 也连续两年蝉联 Apache 社区最活跃项目。今天云与开源的迭代，也使得人们在开源软件的方向上有了新的探索。以 Flink 为例，最初是一个以 Java API 实现流计算的平台，在阿里巴巴内部及阿里云上的应用中逐渐生长出了像 SQL 这样的能力。近几年，阿里巴巴也在根据自身使用 Flink 的需求不断探索新的方向，例如在数据集成方向发展非常快的 Flink CDC 项目、和机器学习结合的 Flink ML 项目、与传统数仓相结合的流式数仓概念以及在此概念下推出的 Flink Table Store 项目等。此外，在整个大数据领域也有很多共性的技术，例如大规模分布式计算在存算分离环境中的 Remote Shuffle Service，在 Flink、Spark、Hive 等引擎中都有类似的需求。我们也很高兴地向大家宣布，阿里云已经将自身云场景中孕育的 Remote Shuffle Service 项目捐献给了 Apache 软件基金会，命名为 Apache Celeborn。阿里巴巴不仅是开源软件的受益者，同时也是贡献者。开源已经成为阿里巴巴工程师文化中不可或缺的一部分，越来越多的工程师在开源社区汲取知识，在积极地参与开源软件和社区建设，同时也在适当的时候将我们自己建设的项目贡献给开源社区。我相信在未来我们会继续和开源社区一起，基于云这样一个底座，给用户提供更加容易触达和使用软件的平台和方式，同时以我们和社区的技术实力共同建设更加繁荣的开源社区。Flink Towards Streaming Data Warehouse主论坛 Keynotes 议题照例由 Apache Flink 中文社区发起人、阿里云开源大数据平台负责人王峰老师开启，介绍了 Apache Flink 社区在 2022 年取得的主要技术创新与成果，以及未来的发展方向。Apache Flink 2022 - 数据实时化技术创新不止2022 年，Apache Flink 发布了两个大版本。在 Flink 1.15 版本中，社区集中解决了许多长期存在的历史难题，包括 SQL 作业的跨版本升级、状态快照的所属权语义与生命周期管理、跨数据源的 Watermark 进度同步、批作业自适应算子并发设置等。在 Flink 1.16 版本中，社区进行了更多新的创新与尝试，包括分布式一致性快照架构升级、创新流批自适应融合 Shuffle、基于异步与缓存技术的流式 SQL 维表 Join 改进、完整兼容 Hive 生态、PyFlink 功能及性能全面生产可用等。分布式一致性快照架构全新升级Apache Flink 作为一款有状态的流式计算引擎，分布式一致性快照是其非常核心的一项技术。Flink 在流计算过程中，定期对状态做快照并持久化，当作业出现异常时可以从最近一次快照进行恢复，以保证业务连续性。因此，能够以更高的频次、更低的成本进行快照，让业务更加流畅，是 Flink 用户的共同诉求。然而在真实生产环境中，特别大规模复杂生产环境中，分布式一致性快照面临着诸多挑战：一方面在反压状态下，网络缓冲拥塞，用于做分布式快照的 Barrier 无法沿数据流向下传输，无法及时触发快照；另一方面，即使能触发快照，需要持久化到远程存储系统的本地状态数据的数据量和上传时间均不可控。上述原因导致用户时常遇到无法在规定时间内生成分布式快照的情况，严重影响业务的稳定性。针对上述问题，Flink 在最近几个版本中对整个分布式一致性快照架构进行了全方面的升级，主要内容包括：Unaligned Checkpoint：当 Barrier 对齐时间达到一定阈值后，自动转化为 Unaligned Checkpoint，兼顾 Checkpoint 的数据量与 Barrier 对齐时间。Buffer Debloating：只缓存下游算子 1s 内可以处理的数据量，在避免网络传输影响算子性能的前提下，最大限度降低算子间缓存的数据量。Log-based Checkpoint：状态表与增量日志解耦，异步上传，大幅降低生成快照的成本。随着上述技术在 Flink 1.16 落地，Flink 形成了新一代的分布式一致性快照架构。面向云原生的新一代状态存储管理体系云原生时代已经到来，各个基础软件项目都需要考虑如何去适应这样一个时代，Apache Flink 也不例外。对于 Flink 而言，云原生时代带来的最显著的变化是对于资源弹性扩缩容的诉求，这要求 Flink 作业的并发度能够随着业务量和资源不断改变。在并发度改变时，Flink 的状态存储也需要快速地重新分配，即状态存储的分裂与合并。因此，Flink 状态存储的分裂、合并性能，直接关系到 Flink 弹性扩缩容的体验。在 Flink 1.16 版本中，社区对 RocksDB State Backend 的状态重建算法进行了大量优化，取得了 2-10 倍的性能提升，使得 Flink 的弹性扩缩容更加平滑、更加适应云原生时代。此外，社区还计划将 Flink 状态存储管理体系进一步升级为彻底的存算分离架构，以适应云原生环境。目前 Flink 的状态存储管理体系并非真正的存算分离架构，所有状态数据依然存储在本地 RocksDB 实例中，只有在分布式快照时将增量数据拷贝到远程存储，保证远程存储中存有全量的状态数据。未来，Flink 的状态数据将全部原生于远程存储之上，本地磁盘与内存只用作缓存加速，形成分层存储体系，我们称之为分层状态存储（Tired State Backend）架构。流批融合的 Hybrid Shuffle 创新技术流批一体、流批融合是 Apache Flink 非常有特色的一个技术理念，而 Shuffle 则是分布式计算系统中一项非常核心的、与性能高度相关的技术。Flink 1.16 创新推出了流批融合的 Hybrid Shuffle 技术。在此之前，Apache Flink 在流模式和批模式下分别采取了两种不同的 Shuffle 技术：流式 Pipelined Shuffle：上下游任务通过网络直接连接，数据通过内存和网络进行传输，无需磁盘 IO，性能更好。批式 Blocking Shuffle：上游任务先将中间数据写到磁盘或其他存储服务，下游再从磁盘或存储服务读取中间数据，需要磁盘 IO，性能稍差。那么能否将流式 Shuffle 也应用在批执行模式下，加速批的 Shuffle 呢？从技术本身来说是可以的，但在生产环境下会面临比较大的约束。流式 Shuffle 要求所有彼此联通的任务同时拉起，这就需要更多的资源，而在生产环境下是否能有这么多资源是无法保证的，甚至可能会有死锁的情况发生。如果能只在资源充足的情况下将彼此联通的任务同时拉起进行流式 Shuffle 加速，同时在资源不足的情况下退化为批式 Shuffle，就可以更加合理地利用资源来进行 Shuffle 的加速。这也就是 Hybrid Shuffle 的背景和思路。Flink 1.16 中完成了第一版 Hybrid Shuffle，初步评测相比传统的 Blocking Shuffle 取得了不错的性能提升。在后续版本中，社区也会对这项技术做进一步的完善与优化。Flink CDC 全增量一体化数据同步Flink CDC，即基于 Apache Flink 的全增量一体化数据同步技术，是近两年提出的一个新概念。为什么要基于 Flink 打造一款全增量一体化数据同步引擎？Flink 本质上是一款流式分布式计算引擎，事实上已经成为连接不同存储的数据管道。Flink 拥有丰富的 Connector 生态能够连接各种主流存储系统，具有优秀的分布式架构支持分布式快照、流批融合等机制，这些都是一款全增量一体数据集成引擎所需要的特性。因此，基于 Flink 打造全增量一体化数据同步引擎是非常适合的，这也就是 Flink CDC 项目的由来。去年我们推出了 Flink CDC 1.0，得到了来自开发者生态非常好的反馈。因此今年我们加大投入，推出了更加成熟完善的 Flink CDC 2.0。Flink CDC 2.0 的主要特性包括：通用的增量快照框架抽象，降低了新数据源的接入成本，使 Flink CDC 能够快速接入更多的数据源。支持高性能的并行读取。基于 Flink 的分布式快照机制，实现数据同步的断点续传，提高可靠性。对数据源全程无锁，数据同步对在线业务无任何影响。Flink CDC 创新项目成长非常迅速，正在成为新一代数据集成引擎。目前 Flink CDC 已支持了包括 MySQL 家族、PolarDB、Oracle、MongoDB 等主流数据库且接入了增量快照框架，另外还支持了像 DB2、SQLServer、PostgreSQL、TiDB、OceanBase 等耳熟能详的数据库，相信今后也会有更多的数据源接入 Flink CDC 框架。该项目也获得了开源生态中开发者们的一致好评，Github Star 数已经超过 3,000。新一代迭代计算框架助力 Flink ML-2.0在老版本的 Flink 中有一个 Flink ML 模块，是一套基于 DataSet API 实现的机器学习算法库。随着 Flink 基础 API 层全部统一到流批一体的 DataStream API，原本的 Flink ML 模块也和 DataSet API 一同被废弃了。今年，Flink 社区基于 DataStream API 重新建设 Flink ML 成为一个新的子项目，目前已经发布了两个版本。众所周知，机器学习算法库运算的核心是迭代计算框架。Flink ML 2.0 基于 Flink DataStream API 重建了一套流批一体的迭代计算框架，能够支持无限流上的在线训练、训练中断恢复以及高性能的异步训练。Flink ML 2.0 仍处于起步阶段，第一批数十种算法已经由阿里云实时计算和机器学习团队完成了贡献，能够覆盖常见的特征工程场景，支持低延迟的近线推理计算。期待未来有更多公司和开发者能够参与进来，为 Flink ML 贡献更多经典的机器学习算法，让 Flink 优秀的计算能力在机器学习场景中发挥更大的作用。Apache Flink Next - Streaming Data Warehouse在去年的 FFA 峰会上，我们提出了 Apache Flink 社区下一步技术演进的方向——Streaming Data Warehouse。我们首先来回顾一下 Flink 历史上核心技术理念演进的过程，这有助于理解为什么我们认为 Streaming Data Warehouse 是 Flink 下一步的演进方向。Stateful Streaming：Flink 在诞生之初，能够受到开发者的青睐，取代上一代流式计算引擎 Storm，成为新一代流式计算引擎，关键在于其有状态的流计算这一定位。通过将流计算与状态存储有机融合，Flink 可以在保持高吞吐低延迟的同时，在框架层支持有状态流计算的精准数据一致性。Streaming SQL：早期 Flink 开发必须写 Java 程序，使得 Flink 项目在快速发展几年之后遇到了推广门槛过高的瓶颈。在数据分析师的世界里，事实标准的语言是 SQL。于是在 2019 年，阿里云将内部积累的 Blink SQL 贡献给了 Flink 社区，大幅降低了 Flink 的开发门槛，使得 Flink 在各行各业的应用得到了爆炸式的增长。Streaming Data Warehouse：Flink 的流批一体 SQL 能够实现计算层全量增量开发一体化的体验，但无法解决存储层割裂的问题。流式存储中的数据很难对其进行查询分析，而批式存储中数据的时效性又比较差。因此，我们认为下一阶段 Flink 社区新的机会点就在于继续提升一体化体验，通过流批一体 SQL + 流批一体存储构建一体化体验的流式数仓。Flink 社区推出的全新子项目 Flink Table Store，其定位就是实现流批一体的存储能力，能够实现高性能的流读、流写、批读、批写。Flink Table Store 的设计遵循存算分离理念，数据存放在主流的云存储之上，其核心存储格式由 LakeStore 和 LogStore 两部分组成。LakeStore 应用了经典的 LSM、ORC 及其他索引技术，适合大规模、高性能的数据更新与读取。LogStore 提供了完整 CDC 语义的 ChangeLog，配合 Flink Streaming SQL 可以增量订阅 Table Store 进行流式数据分析。此外，Flink Table Store 采用开放的数据格式体系，除了默认对接 Flink 之外，也可以对接 Spark、 Hive、Trino 等主流开源计算引擎。Flink Table Store 诞生一年来，共推出了两个版本，完成了从 0 到 1 的孵化落地。目前除了阿里云之外，也有来自字节跳动等公司的开发者在参与共建和试用。我们对 Flink Table Store 和目前主流的数据湖存储 Hudi 进行了性能对比，结果显示 Flink Table Store 的更新性能明显领先 Hudi，查询性能明显领先 Hudi MOR 模式、接近 Hudi COW 模式，综合表现更佳。Apache Flink 实时计算在美的多业务场景下的应用与实践第二场 Keynotes 议题是由美的集团实时数据负责人、资深数据架构师董奇老师带来的，她从家电行业的视角分享了 Apache Flink 实时计算在美的传统及新兴业务场景的应用与实践。董奇老师首先介绍了实时生态体系在美的的发展和建设现状。美的的实时数仓体系建设主要围绕时效性、稳定性、灵活性三个要素。时效性方面，设计了以 Flink 为核心的时效性保障架构；稳定性方面，包括开发阶段针对数据源连通性、元数据参数格式等的一系列校验和运行阶段的集群资源、任务状态等监控告警；灵活性方面，包括统一的元数据、UDF、Connector 等资源管理和对任务模板、公用逻辑等任务管理功能的支持。Flink 在美的核心传统业务场景的数字化转型中发挥了重要的作用，董奇老师分享了其中三个场景。B 端长周期场景：具体业务场景包括美云销 App 看板和全链路订单可视。传统行业的采购、营销、库存分析以及长周期订单的跟踪，都需要对过去很长一段时间的数据进行回溯，这对实时计算的挑战是比较大的。在我们的架构中，历史全量数据是通过 Flink 自动加载 Hive 分区表来引入的，与 Kafka 增量数据相结合，做进一步计算加工。工厂生产进度：工厂的管理人员和员工可以通过实时大屏看到每个小时的生产进度，对于更好地完成每天的生产任务具有很大的实用价值。抢单活动大屏：面向代理商、运营商、零售商的抢单活动，涉及到价格、供货、新品首发等方面的权益，是非常关键的。活动现场的实时大屏对于指导运营人员调整运营策略、代理商和零售商开展零售和抢单活动具有重要意义。在美的新兴业务场景中，同样有许多基于 Flink 的实时数字化应用实践，在这方面董奇老师也分享了三个场景。家居设备实时智能调控：冰箱云管家、洗地机云管家、电热云管家等产品都具有分析用户行为、调整控制智能家电行为以达到节能节水目的的功能。Flink 消费 Kafka 中的设备数据，与 Redis / HBase 用户、产品、第三方数据以及算法模型、规则相关联，将结果再写出到 Kafka 中，最终通过 IoT 云完成设备指令的下发。此外，在这套链路中 Flink 还承担了实时监控的职能。HI 服务实时消息推送：智能家居产品除了自动调控功能之外，还有许多需要通过人机交互、人为操控完成的功能，例如故障提醒、完成提醒、耗材提醒等。这套链路与家居设备实时智能调控很像，只是最终的数据会写出到第三方的推送平台。电商活动监控大屏：业务数据化，将运营人员手工收集录入的业务数据落入数据库，通过 CDC 技术捕捉增量变化数据，再由 Flink 进行加工，通过 StarRocks + QuibkBI 搭建实时大屏，以供快速直观的运营决策。董奇老师指出，美的集团接下来的实时生态体系建设将重点围绕降本提效与工具赋能，包括云原生部署、热点均衡、任务报错根因与修复提示等基础运维能力，以及平台与业务侧的可视化配置集成工具、细粒度资源配置、流批一体实践等。Apache Flink 在米哈游的应用实践接下来是来自米哈游大数据实时计算团队负责人张剑老师的分享。张剑老师首先介绍了 Flink 在米哈游的发展历程和平台建设情况。米哈游实时计算平台建立之初就选择了 Apache Flink，这是基于 Flink 毫秒延迟、窗口计算、状态存储、容错恢复等优异特性以及背后蓬勃发展的社区。最初的实时计算平台是完全基于 Flink DataStream API 的，初步具备任务的管理与运维能力。随着业务的增长，米哈游实时计算平台在 2020 年开始迈入高速发展阶段，着手打造以 SQL 为主的一站式开发平台，推进了多云跨区域的任务管理、SQL 及连接器、指标和日志体系、元数据和血缘等能力的建设，极大提高了研发效率。今年，米哈游实时计算平台开始朝着新的目标迈进，着手推进一站式开发平台的功能深化与场景覆盖，包括静态和动态调优、自动扩缩容、资源弹性、近实时数仓等能力的建设。在应用方面，张剑老师分享了米哈游内部四个重要的应用场景。全球游戏日志标准化采集加工：Flink 承担着米哈游全游戏业务每天近百亿的日志处理，峰值流量过千万。通过 Filebeat 采集和日志上报服务接收到的日志传输到 Kafka 实时数据总线，经过 Flink SQL 处理加工，写入下游 Clickhouse、Doris、Iceberg 等存储，提供给客服查询系统、运营实时分析、离线数仓等应用场景。实时报表及实时大屏：我们会根据业务需求，对重要的指标提供实时大屏服务，同时针对运营基于 BI 报表提供实时指标的应用查看。在社区帖子排序的场景中，数据来源一是客户端埋点上报到 Kafka，二是通过 Flink CDC 抓取业务库的增量数据。为了不引入额外的 KV 存储，同时解决维表更新不及时导致关联失败的问题，我们将 Flink 流式消费 Kafka 的任务和 Flink CDC 抓取业务库的任务合并成了同一个任务，采用 RegularJoin 进行关联。这里我们对 Flink SQL 进行了拓展，能够控制底层状态细化的生存周期，避免维表状态过期。关联后的数据再经过指标计算，提供给帖子排序服务。近实时数仓：我们通过 Flink SQL 实时写入 Iceberg 的方式，实现了日志离线入仓近实时化，数据入仓时效从小时级缩短到了分钟级，离线存储 IO 的波动性也平稳了很多。通过 Flink CDC 对 MySQL 数据库进行全量、增量的同步，结合平台的一键任务生成、自动调优扩缩容、自动提交运行等能力，实现了数据库一键入湖，大幅提高了开发效率、降低了对数据库的压力。近实时数仓的一个典型应用场景是玩家战绩查询。实时风控：在米哈游，风控团队和实时计算团队联系密切。风控团队提供了良好的风控引擎，实时计算团队基于风控引擎构建了一套相对自动化的 API 及任务管理方式，让实时计算平台服务化。具体的应用场景包括登录校验、游戏反作弊、人机校验等。张剑老师介绍，米哈游在实时计算领域未来的工作主要包括三个方面：一是平台能力建设，包括 Flink SQL、资源调优、自动化运维、资源弹性等；二是使用场景的探索，比如延迟消息服务、基于 Flink CDC 的 Binlog 服务、应用级别指标服务等；三是数据湖和 TableStore 的不断实践，包括流批一体与近实时数仓的实践与探索。Disney 流媒体广告 Flink 的应用实践最后一场 Keynotes 议题是由 Disney 广告智能执行总监郝又超老师和 Disney 广告智能实时计算负责人李丁哲老师联合带来的。郝又超老师首先介绍了 Disney 流媒体广告业务。Hulu 作为美国本土头部的流媒体平台，最早是由 Disney、Fox、NBC 共同发起成立的。随着 2019 年对 Fox 的收购，Disney 得到了 Hulu 的运营控制权与广告平台的优质资源，开始发力线上流媒体，陆续推出 Disney+、ESPN+、Star+ 等品牌。目前，Disney 流媒体在全球有 2.35 亿订阅用户（以家庭为单位），已超过 Netflix。Hulu是当前 Disney 流媒体广告业务的主要来源，每天投放数亿15秒、30秒长的视频广告，而每选择一个广告都会产生几十甚至上百个事件，对数据平台有着极高的挑战，随着Disney+上12月份即将上线广告，这种挑战预期将数倍增长。Disney 流媒体广告数据平台分为数据算法和应用服务两层，其中 Apache Flink 主要应用于数据算法层，对运营数据中的关键指标做实时聚合。接下来，李丁哲老师分享了 Disney 流媒体广告数据平台中实时数据部分的具体情况。在实时链路中，从系统及用户侧收集到的数据，由 Flink 进行统一的流式计算，计算出的指标通过数据接口暴露给业务平台、运维平台、广告服务器等。在离线链路中，使用 Spark 生成离线报表和对外数据输出，使用 Flink 进行指标回填等处理。李丁哲老师还分享了 Disney 流媒体广告使用 Flink 的三个实时应用场景。广告决策漏斗：广告决策是一个复杂的过程，需要从庞大的广告池中，通过粗排、精排以及一系列过滤条件，选择出最适合用户的广告。为了对这个复杂的过程进行错误排查，我们将其抽象成漏斗模型，对广告的投放机会、定向成功与否、是否被过滤、最终是否投放成功、投放失败原因等信息进行展示。我们使用 Flink 将从广告服务器获取到的决策信息进行解码、关联，还原出决策漏斗并交由前端展示。在离线链路中我们实践了 Flink 的流批一体，使用同一套代码在实时数据出现问题时进行纠错与数据回填。广告曝光监控：广告主通常会提出一些广告投放的要求，比如针对特定人群投放、限制同用户同时间段内的投放次数、避免和竞品广告同时出现等。针对这些需求，我们研发了广告曝光监控平台，让广告主可以查看其广告投放的相关信息。在这个场景中，我们使用 Flink 对来自广告系统和客户端的上下文信息和用户行为进行关联和维度增强，生成一系列的事实指标，并基于特定规则计算出更多衍生指标。广告系统大屏：面相管理层与业务方，提供关于广告系统与广告投放情况的全局洞察能力。来自事实数据源的数据，经过 Flink 的处理，通过指标接口暴露出来，再根据不同的业务规则进行聚合，最终投放给前端做大屏展示。李丁哲老师介绍，Disney 流媒体广告的实时数据平台搭建在云上，部署在 Kubernetes 容器编排系统上，使用 Flink Operator 管理 Flink 集群，实践了 Gang Scheduler、流批作业混部、基于队列的弹性扩缩容等技术。在议题的最后，郝又超老师分享了 Flink 未来在 Disney 流媒体广告平台上的一些应用场景规划，包括全流批一体、OLAP、实时归因、流式机器学习等。总结本次大会上，我们欣喜地看到 Apache Flink 社区仍在持续繁荣地向前发展：社区建设方面，全球与中文社区规模与活跃度均屡创新高；技术成长方面，状态、容错、Shuffle、数据集成、机器学习等方向都在持续创新，面向未来流式数仓的流批一体存储 Flink Table Store 也取得了喜人的进展；行业应用方面，正有越来越多不同行业的公司加入到 Flink 生产实践的队伍中，将技术积累与新的需求源源不断地回馈到社区。让我们共同期待 Apache Flink 越来越好~！更多内容Flink Forward Asia 2022 本届 Flink Forward Asia 更多精彩内容，可点击阅读原文或扫描图片二维码观看全部议题的视频回放及获取 FFA 2022 峰会资料！PC 端观看：https://flink-forward.org.cn/ 「建议前往 FFA 2022 大会官网观看全部议题的视频回放」活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-26
投入上百人、经历多次双 11，Flink 已经足够强大了吗？
采访嘉宾 ｜ 王峰（莫问） 作者 ｜Tina作为最活跃的大数据项目之一，Flink 进入 Apache 软件基金会顶级项目已经有八年了。 Apache Flink 是一款实时大数据分析引擎，同时支持流批执行模式，并与 Hadoop 生态可以无缝对接。2014 年，它被接纳为 Apache 孵化器项目，仅仅几个月后，它就成为了 Apache 的顶级项目。对于 Flink 来说，阿里有非常适合的流式场景。作为 Flink 的主导力量，阿里从 2015 年开始调研 Flink，并于 2016 年第一次在搜索场景中上线 Flink。在落地的同时，阿里对 Flink 进行大量的修改和完善，让其适应超大规模业务场景。2017 年，阿里已成为 Flink 社区最大规模用户， Flink 团队也达上百人。这其中的一些早期改进，阿里在 2018 年的文章《 Flink 已经足够强大了吗？阿里巴巴说：还不够 》中已有详尽解读。2019 年，阿里宣布收购了 Flink 背后的企业，并正式开源内部 Flink 版本 Blink，贡献了超百万行代码，极大地推动了社区的良性发展。在 2021 年双 11 中，Flink 承载的实时计算峰值达到了每秒 40 亿条记录，数据体量也达到 7 TB 每秒，相当于一秒钟需要读完 500 万本《新华字典》。这几年，Flink 社区在国内外技术会议上不断宣传推广，让 Flink 得到大量采用，各种应用场景也变得更加广泛，生态快速发展。Flink 已经变得强大，其设计目标也不再仅仅是流计算引擎，而是让绝大部分数据分析师都可以利用 Flink 流批一体 API 搭建实时数据集成、分析、风控和在线机器学习场景解决方案。2022 年 11 月 26-27 日， Flink Forward Asia 2022 于线上召开，这是一次总结最近发布的重要功能的机会。这一次，Flink 流式数仓功能更加成熟，CDC 也能够接入多种数据库......InfoQ 趁此机会，采访了 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（花名莫问），解读 Flink 核心技术的进展，并了解 Flink 的未来规划。从流计算到流批一体计算打败 Storm 和 Spark Streaming 之后，Flink 成为了流计算的唯一标准，技术上已经没有了竞争对手。Flink 诞生之初能够快速打败上一代流计算引擎 Storm，凭借的是“有状态的流计算”这个核心理念和特色。 通过合流式计算和状态管理两项技术，Flink 不仅提供了高性能的纯流式计算，同时也在框架层通过分布式一致性快照技术，为用户提供了数据精准一致性保证。在莫问看来，这是 Flink 出道后迅速成为流计算领域新主流的关键原因。虽然 Spark Streaming 通过借助强大的 Spark 生态也能够成为一些流计算场景的选择，但其本质依然是基于 Spark Batch 引擎构建的，非纯流执行模式还是会限制其执行性能和流语义表达。而在批计算方面，Flink 已经完成绝大部分工作，并日益成熟。“目前 Flink 已经能够完整跑通批处理标准测试集 TPC-DS，而且性能也非常不错，已经达到主流批处理引擎水平，接下来 Flink 在批处理的成熟度上会持续完善和打磨，并结合自身流处理的天然优势，力求给用户带来业界最好的流批一体计算体验。”为什么我们需要流批一体？为什么基于 Flink 的流批一体更有技术优势？我们先从业务视角看待这个问题，早期企业基本都是离线业务，基于批处理一天运行一次报表，但数字世界在不断进化演进，对实时的需求会越来越多。实时风控、实时 BI 统计、实时推荐、实时监控，这些都不能等到晚上进行（到了晚上可能商品已经卖完了，用户也走了），实时化的数据分析才能给用户带来价值。逐渐离线和实时就会成为两条平行割裂的链路，并随着实时数据业务量占比持续提升，会有越来越多的任务要重复开发两遍，开发者会开始面临开发效率问题。此外，实时和离线链路割裂还会存在业务口径一致性的问题，在之前的技术方案下，实时和离线相当于用了两套工具干活，使用不同的语言、不同的引擎，数据口径也无法一致，这样的分析结果就会干扰业务决策，甚至会误导决策失误。这时候流批一体自然而然就成为了解决实时离线割裂的“新手段”。用一套计算引擎开发出的实时离线两个业务流程，天然是一致的，不会存在误差。尤其在一些高时效的业务场景中，如搜索、推荐、广告，数据平台中的营销分析，对流批一体的需求自然就会比较高。而且，在搜索推荐场景中，还能将 Flink 流批任务与在线任务混部到一起，共用一个资源池，进行统一调度，从而最大化利用服务器资源，这在业界也是比较先进的实践方式。流批一体新架构能够带来的收益是明显的，但也并不是说它就是“放之四海而皆准”的一种技术架构。莫问认为，“如果当前数据业务基本都在离线数仓，尚未有一定规模的实时化业务，那也没有必要过早去做流批一体改造，因为这样收益并不大。当实时业务量日益成为主流，相对离线占比日益增大，或者对数据一致性有越来越强一致的要求的话，那么流批一体架构就是面向未来的必然选择。”流式数仓：基于流批一体的新数仓架构流批一体是一个技术理念。Flink 在 SQL 层提供了流批一体语义表达能力，即用户可以写一套 SQL，从而同时用在实时和离线两个场景，从而得到全增量一体化的数据开发体验。这是流批一体理念的终点吗？显然还不够。因为在数据存储链路上，还是存在很大的复杂性，例如：在实时链路上，Flink 需要将数据写入 Kafka 等流式存储中，在离线链路上，Flink 往往要将数据写入到 Hive/Iceberg/Hudi 等批式存储中。两条存储链路是割裂的，用户依然要同时维护两条数据链路，造成较大的管理难度。然而目前我们要同时维护两套存储的原因主要是业界目前没有一个较为生产可用的流批一体存储，同时支持高效的流读、流写、批读、批写能力，用户为了满足不同业务需求（时效性，可分析性等）只能通过多条链路的组合来拼接，甚至还要在不同存储间同步数据，这必然会让整个链路变得日益复杂。那目前业界是否已经存在可用的流批一体存储来解决这个问题呢？大家可能会想到 Apache Hudi 的这个主流湖存储项目，Hudi 也确是目前业界流批一体存储能力上相对最完善的技术，但 Hudi 在存储结构的设计上，并不适合大规模更新。因此，Flink 社区下一个阶段的重点方向就是要去解决这个用户痛点，将流批一体理念进一步完善，提供真正可用的流批一体存储技术，从而基于流批一体计算和存储推出完整的流式数仓新架构，这也是 2021 年底 Flink 社区推出 Flink Table Store 独立子项目的背景。2022 年，Flink Table Store 已经完成了从 0 到 1 的孵化，并发布了 2 个 release 版本，除了阿里巴巴，包括字节跳动在内的多家公司都已经参与了这个项目的贡献，并有不少公司开始试用。Flink 社区接下来的重点演进方向就是流式数仓新架构，为用户提交更加简洁、实时化的数仓架构，并提供更加一体化的体验，这也是 Flink 多年来倡导的流批一体理念的完整落地场景，流批一体计算和存储的完美结合。在今天的 Flink Forward Asia 2022 上，莫问给大家展示了一个完整的产品化 Demo，基于阿里的实时计算平台，在 TPC-H 业务背景下跑通了完整的流批一体数据处理和分析流程，包括从数据库源头开始的 Flink CDC 数据入湖（写入 Table Store）、Flink SQL 实时流式分析（订阅 Table Store）以及批量数据订正和实时交互查询，给大家呈现了一个完整的流式数仓新架构成果。此外，Flink 流式数仓架构也是开放的体系，支持对接其他一切具备流批一体能力的存储系统，例如阿里云的 Hologres，阿里也在内部完成了 Flink SQL + Hologres 的企业级自研流式数仓产品，不久也将正式对外发布。基于 Flink 的全增量一体化数据集成数据集成是实时流处理平台中非常重要的一个应用场景，这在 Garnter 2022 年 1 月发布的流处理平台市场引导报告中也可以得到印证，从全球市场看大概 1/3 的流处理场景是和实时数据集成相关的，即通过流处理能力将各种不断变化数据源中的数据同步到分析数据库，数据仓库和数据湖中，从而确保用户可以实时分析到最新的数字世界。随着实时化数据分析技术的普及，用户的数据同步需求也在进一步升级，期望能够使用一套一体化的全量数据同步工具，一键实现数据同步。但在传统数据集成技术体系下，全量和实时数据同步往往需要两套工具（基于批和流的），并且用户需要在两套工具之间进行协同，因此要真正实现全增量同步流程的无缝对接并保证数据一致性，这个难度和挑战是非常大的。但如果能够利用上 Flink 流批一体融合特性，那实现全增量一体化的实时数据集成就变得可行了。此外，Flink 本身也具备了丰富的 Connector 生态，能够连接业界各种主流存储，以及优秀的分布式集成框架，包括容错和分布式一致性快照等能力。因此在 Flink 的基础上做全增量一体化数据集成，相当于“站在巨人肩膀上”，会更快更容易。这就是 Flink CDC 项目诞生的背景，其大量借助了 Flink 自身的优势，利用流批一体执行模式实现了全增量同步自动切换，基于 Flink Checkpointing 能力实现了数据同步断点续传特性，并基于增量快照一致性读取算法保证了数据同步全程对在线数据库无锁操作，这样对生产业务不会产生任何影响。作为流批一体的另一个创新应用场景，CDC 项目发展速度也非常快，网易、腾讯、Oceanbase、哔哩哔哩、Xtransfer 等公司都参与了社区贡献，GitHub Star 目前已经突破 3000，生态上支持了很多主流数据库，包括 MySQL、Oracle、PostgreSQL、MongoDB、TiDB、PolarDB 和 OceanBase 等。莫问表示，Flink CDC 会进一步利用 Flink 社区的创新成果，接入更多的数据源，成为新一代全增量一体化的数据集成引擎。云原生时代的 Flink随着云原生的普及，越来越多的企业应用进行了容器化迁移，并通过 K8s 进行编排管理。最近几年，大数据领域的 Spark、Kafka 等都开始支持 K8s，使得大数据应用从传统的 Yarn 时代转变为云原生时代。Flink 社区很早以前就开始基于云原生来设计了，包括 Flink 的资源调度、流式 Shuffle，都是天然适合云原生的。Flink 作为一个流式计算引擎，数据的 Shuffle 不需要落盘，都是流式的进行数据传输，分布式计算之间数据的流动都是通过网络加内存，不依赖本地盘，因此天然就是存算分离的架构。另外，Flink 自带了一个状态存储，计算的算子和状态访问是一体的，在算子内部就支持状态访问，这个其实也在朝着存算分离方向去演进，也就是说 Flink 随时可以关掉 RocksDB 服务，把状态数据 SnapShot 到持久化的 HDFS 或者是云存储上。Flink 作为云原生架构下的产物，本身也一直朝着云原生架构去设计，社区在五六年前就开始做 Flink on K8s。 支持K8s之后 ，对 Flink 有很大的帮助，比如部署不依赖 Hadoop 了：只要有 K8s，就可以部署 Flink，也没有任何依赖。运维方案也非常标准化，K8s 的运维体系也会运维 Flink。同时，Flink 也可以基于容器来进行部署，容器给 Flink 带来了更好的隔离性，包括任务之间的隔离、多租户的管理，甚至下一步做 Serverless，也会更加自然和容易。在云原生的发展趋势下，自适应性非常重要。更好的资源弹性让业务的波动也变得更加灵活，而云上的资源也是海量的，用户可以根据业务的需求不断弹性调资源规模。特别是 Serverless 的环境下，用户甚至不需要去考虑机器资源了。Flink 自身也会去增加更多的自适应的能力，实现自动化的任务并发管理和状态数据管理，从而让 Flink 能更好地使用云上的弹性机制。Apache Flink 正在蓬勃发展，并在广大的大数据分析生态中变得不可或缺，逐渐成为了企业数据战略的关键支柱。但对于一些传统企业来说，如果没有很强大的大数据技术团队，用开源软件自建一个数据分析平台还是比较困难的。所以提供产品化服务，降低技术门槛，也是阿里云 Flink 技术团队正在做的事情。阿里云已经推出了一款云原生的实时计算 Flink 产品，提供了以 Flink SQL 为核心的开发运维平台，将阿里内部积累的 Flink 生产运维经验和企业级能力都通过产品化的形式开放给广大中小企业，提供实时数仓、实时数据集成、实时风控和实时特征工程等解决方案，帮助数字化企业加速大数据技术实时化升级。另外，阿里云提供的 Flink 产品也采用了最先进的 Serverless 架构，用户只要按需购买计算资源就可以运行方便使用 Flink，让实时计算更加普惠。莫问表示，未来几个月之内，基于 Flink 的多云 PaaS Serverless 服务也将在全球范围公测，作为推动 Flink 社区不断技术创新的核心研发团队，阿里云希望把 Flink 技术生态进一步推向全球。采访嘉宾简介：王峰，花名“莫问”，阿里巴巴研究员，2006 年北航毕业加入阿里巴巴，目前负责阿里云开源大数据平台，并担任阿里巴巴开源委员会大数据与 AI 方向副主席。2015 年开始将萌芽状态的 Apache Flink 引入中国，基于 Flink 推动阿里大数据进入全链路实时化时代，并以此为标杆效应带动了 Flink 在全球各个行业的快速普及和发展，让 Flink 成为了大数据实时计算领域的事实标准。阿里积极拥抱开源，也主动贡献开源。迄今，阿里已累计对外开源了上百个优秀项目，在 GitHub 上 Star 总数超百万。更多内容Flink Forward Asia 2022 Flink Forward 是由 Apache 官方授权的 Apache Flink 社区官方技术大会，通过参会不仅可以了解到 Flink 社区的最新动态和发展计划，还可以了解到国内外一线厂商围绕 Flink 生态的生产实践经验，是 Flink 开发者和使用者不可错过的盛会。本届 Flink Forward Asia 正在直播，可点击阅读原文或扫描图片二维码观看！时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-25
Flink CDC 2.3 发布，持续优化性能，更多连接器支持增量快照，新增 Db2 支持
作者｜阮航 & 徐榜江一、Flink CDC 简介Flink CDC[1] 是基于数据库的日志 CDC 技术，实现了全增量一体化读取的数据集成框架。配合 Flink 优秀的管道能力和丰富的上下游生态，Flink CDC 可以高效实现海量数据的实时集成。作为新一代的实时数据集成框架，Flink CDC 具有全增量一体化、无锁读取、并行读取、表结构变更自动同步、分布式架构等技术优势，同时社区提供了完整的文档支持[2]。在 Flink CDC 开源的两年多时间里，社区成长迅速，目前 Flink CDC 社区已有 76 位贡献者，7 位 Maintainer，社区钉钉用户群超过 7800 人。二、 Flink CDC 2.3 概览在社区用户和贡献者们的共同努力下， Flink CDC 2.3 正式发布了：https://github.com/ververica/flink-cdc-connectors/releases/tag/release-2.3.02.3 版本共有 49 位社区贡献者参与贡献，累计解决 126 个 issue，合并了 133 个 PR，贡献者们累计贡献了 170+ 提交。 从代码分布上看，MySQL CDC，MongoDB CDC， Oracle CDC，增量快照框架（flink-cdc-base）模块以及文档模块均为用户带来了很多特性和改进。面对如此多的改进和特性，本文通过下图带你 3 分钟快速了解 Flink CDC 2.3 版本的重大改进和核心特性。新增 Db2 CDC 连接器， 解锁读取 Db2 数据库，支持全量和增量一体化同步。MongoDB CDC，Oracle CDC 两大连接器均接入了增量快照框架，从而提供了无锁读取，并发读取和断点续传的能力。MySQL CDC 连接器在 2.3 版本里进行了诸多性能优化和稳定性大改进，极大提升了生产稳定性和性能。Flink CDC 2.2 版本兼容了 Flink 1.13 和 Flink 1.14， Flink CDC 2.3 在此基础上继续兼容了 Flink 1.15 & 1.16 大版本，从而兼容了 Flink 的四个大版本。这意味着 CDC 的 SQL connector 可以跑在不同的 Flink 集群上而无需任何修改，如果是 DataStream 用户也可以参考 SQL Connector 的打包方式，实现跨版本兼容。OceanBase CDC 连接器支持将全部数据库类型对接到 Flink SQL，也就是说 OceanBase 所有类型的字段均支持同步。MySQL CDC 和 OceanBase CDC 连接器提供中文文档，这可以更好地帮助到中文用户。三、详解核心特性和重要改进Flink CDC 2.3 版本带来了诸多重要的改进和特性，本文挑选最重要的四个进行深入解读。3.1 新增Db2 CDC 连接器Db2 是 IBM 开发的关系型数据库管理系统[3]。Db2 CDC 连接器可以捕获 Db2 数据库中表的行级变更，其实现原理是基于 ASN Capture/Apply agents 提供的 SQL 复制能力 ，将数据库中开启 capture mode 的表的变更存到指定的 change table 中。Db2 CDC 连接器首先通过 JDBC 读取表中的历史数据，再从 change table 中获取增量变更数据，从而实现全增量同步。3.2 MongoDB CDC，Oracle CDC 连接器支持增量快照算法在 Flink CDC 2.3 版本中，MongoDB CDC 连接器和 Oracle CDC 连接器都对接到了 Flink CDC 增量快照框架上，实现了增量快照算法，从而提供无锁读取，并行读取和断点续传的功能。至此，Flink CDC 支持增量快照算法的数据源不断扩大，在接下来的版本中，社区也在规划让更多的连接器对接到增量快照框架上。3.3 MySQL CDC 连接器优化作为社区最受用户关注的 MySQL CDC 连接器，2.3 版本中社区引入了诸多高级特性，极大地提升了性能和稳定性，具体包括：3.3.1 支持指定位点启动MySQL CDC 连接器支持从指定的位点启动作业。可以通过 timestamp，binlog offset 或 binlog gtid 的方式指定作业启动时的 binlog 具体位置，还支持设置为 earliest-offset 从最早的 binlog 位点启动作业。3.3.2 分片算法优化2.3 版本对全量阶段分片算法进行优化。将目前的同步分片改为异步进行，支持用户指定主键中某一列作为分片的切分列，并且分片过程支持 checkpoint，提升了全量读取阶段时因为同步分片阻塞导致的性能问题。3.3.3 稳定性提升MySQL CDC 连接器支持全部字符集对接到 Flink SQL，解锁更多用户场景，支持宽容默认值提升作业对不规范 DDL 的容忍度，支持自动获取数据库的时区从而解决时区问题。3.3.4 性能提升2.3 版本 MySQL CDC 重点优化了内存和读取性能，通过 JM 里的 meta 复用和 TM 中流式读取等改进降低了 JM 和 TM 的内存使用；同时通过优化 binlog 解析逻辑提升了 binlog 读取性能。3.4 其他改进Flink CDC 2.3 版本兼容了 Flink 1.13，1.14，1.15 和 1.16 四个大版本，极大地降低用户 Connector 的升级和运维成本。OceanBase CDC 修复了时区问题，支持全类型对接到 Flink SQL，并提供了更多的配置项，支持更灵活的配置。如新增加 table-list 配置项，支持访问多张 OceanBase 数据表等。MongoDB CDC 支持了更多的数据类型，优化了捕获表的筛选过程。TiDB CDC 修复了全增量切换时数据丢失问题，支持读取时 region 切换。Postgres CDC 支持 geometry 类型，开放了更多配置项，支持配置 changelog mode 来过滤发送的数据。SqlServer CDC 支持了更多的版本，并对文档[4]进行完善。MySQL CDC 和 OceanBase CDC 连接器提供了中文文档[5][6]，此外还对 OceanBase CDC 连接器提供了视频教程[7]。四、未来规划Flink CDC 开源社区的发展，得益于贡献者们的无私贡献和 Maintainer 成员的开源布道，更离不开广大 Flink CDC 用户群体的积极反馈和宣传布道，Flink CDC 社区将会继续做好开源社区建设。当前 Flink CDC 社区正在做 2.4 版本的规划[8]，也欢迎所有用户和贡献者参与反馈，在接下来的 2.4 版本，社区主要方向计划从下述四个方面展开：数据源完善支持更多的数据源，推动更多的 CDC 连接器接入增量快照框架，支持无锁读取、并发读取、断点续传等特性。可观测性提升提供限流功能，以降低全量阶段对数据库产生的查询压力；提供更丰富的监控指标，可以获取到任务进度相关指标监控任务状态。性能提升全量阶段支持使用 Batch 模式同步全量阶段数据，提升全量阶段性能；全量读取阶段结束后自动释放空闲 reader 资源等。易用性提升提升连接器的易用性，比如简化开箱即用的配置参数，提供 Datastream API 程序示例等。致谢：感谢所有为 Flink CDC 2.3 版本做出贡献的覃立辉、莫贤彬、rookiegao、He Wang 等 49 位社区贡献者，特别感谢社区的四位 Maintainer 成员阮航、孙家宝、龚中强和任庆盛为 2.3 版本发布所做的杰出工作。阿里云实时计算 Flink 版提供更多企业级 Flink CDC 能力[9]，包括了分库分表合并、表结构变更同步、整库同步等重要功能，更好的支持了阿里云实时数仓 ODPS-Hologres 等产品，同时使用可无缝构建实时数据仓库。欢迎感兴趣的用户移步阿里云产品官网体验使用。贡献者列表：01410172，Amber Moe，Dezhi Cai，Enoch，Hang Ruan，He Wang，JiaJia，Jiabao Sun，Junwang Zhao，Kyle Dong，Leonard Xu，Matrix42，Paul Lin，Qingsheng Ren，Qishang Zhong，Rinka，Sergey Nuyanzin，Tigran Manasyan，camelus，dujie，ehui，empcl，fbad，gongzhongqiang，hehuiyuan，hele.kc，hsldymq，jiabao.sun，legendtkl，leixin，leozlliang，lidoudou1993，lincoln lee，lxxawfl，lzshlzsh，molsion，molsionmo，pacino，rookiegao，skylines，sunny，vanliu，wangminchao，wangxiaojing，xieyi888，yurunchuan，zhmin，阿洋，莫贤彬附录[1] https://github.com/ververica/flink-cdc-connectors[2] https://ververica.github.io/flink-cdc-connectors[3] https://www.ibm.com/products/db2[4] https://ververica.github.io/flink-cdc-connectors/release-2.3/content/connectors/sqlserver-cdc.html[5] https://ververica.github.io/flink-cdc-connectors/release-2.3/content/connectors/mysql-cdc%28ZH%29.html[6] https://ververica.github.io/flink-cdc-connectors/release-2.3/content/connectors/oceanbase-cdc%28ZH%29.html[7] https://ververica.github.io/flink-cdc-connectors/release-2.3/content/%E5%BF%AB%E9%80%9F%E4%B8%8A%E6%89%8B/oceanbase-tutorial-zh.html[8] https://github.com/ververica/flink-cdc-connectors/issues/1728[9] https://www.alibabacloud.com/help/zh/realtime-compute-for-apache-flink/latest/data-synchronization-quick-start更多内容Flink Forward Asia 2022 时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-23
“后 Hadoop 时代”，大数据从业者如何应对新技术趋势带来的挑战?
作者 | 蔡芳芳采访嘉宾 | 刘京娟、贾扬清、王峰作为开源大数据项目的发端，Hadoop 兴起至今已经超过十五年。在过去这十数年里，开源大数据领域飞速发展，我们见证了多元化技术的兴起和变迁。为了从代码托管平台汇聚的海量数据里，通过数据处理和可视化的方式，深刻洞察开源大数据技术的过去、现在和未来，并为企业和开发者在开源大数据技术领域的应用、学习、选型和技术研发等方面提供有益参考，开放原子开源基金会、X-Lab 开放实验室、阿里巴巴开源委员会共同发起了「2022 开源大数据热力报告」项目。报告从 Hadoop 发展的第 10 年，即 2015 年起，收集相关公开数据进行关联分析，研究开源大数据进入新阶段后的技术趋势，以及开源社区的运作模式对技术走向的助推作用。经过对最活跃的 102 个开源大数据项目进行研究，报告发现：每隔 40 个月，开源项目热力值就会翻一倍，技术完成一轮更新迭代。在过去 8 年里，共发生了 5 次较大规模的技术热力跃迁，多元化、一体化、云原生成为当前开源大数据发展趋势的最显著特征。开放原子开源基金会副秘书长刘京娟表示，报告希望重点对如下人群有所帮助：（1）从事大数据技术研发的企业和开发者。他们可以通过报告，了解大数据技术的发展趋势，从而指引学习方向并提升自身的技能，从技术活跃度的角度为应用开发的技术选型提供一定的参考。（2）有志于为开源项目贡献代码的开发者。开源大数据细分领域众多、百花齐放，但也存在一些相对薄弱的环节，比如数据安全和数据管理等，开发者可以从多个细分领域切入，帮助这些领域更好地发展。（3）开源大数据项目的运营者或者维护者。他们能够从优秀项目的热力发展趋势中，获取经验和规律，从而用更成熟的方式运营开源项目。对于大数据从业者们来说，开源大数据项目热力迁徙背后的技术发展逻辑是怎样的？大家应该如何应对新技术趋势带来的挑战？针对这些问题，近日 InfoQ 与阿里巴巴集团副总裁、阿里巴巴开源委员会主席、阿里云计算平台事业部负责人贾扬清，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（花名莫问）聊了聊。用户需求多样化推动技术多元化以 Hadoop 为核心的开源大数据体系，从 2015 年开始转变为多元化技术并行发展。一方面，原有 Hadoop 体系的产品迭代趋于稳定。部分 Hadoop 生态项目（如 HDFS）成为其他新兴技术的基础依赖，一些常见的开源大数据组件组合，比如 Flink+Kafka、Spark+HDFS 等，经过开源生态市场的检验，比较成熟也容易上手，已经成为相对固定的标准化选择。另一方面，开发者的热情分别涌向「搜索与分析」、「流处理」、「数据可视化」、「交互式分析」、「DataOps」、「数据湖」六大技术热点领域，每个热点领域集中解决某个特定场景问题。报告呈现出的热点领域热力跃迁（热力值大幅度跳变）情况与此相符：「数据可视化」在 2016 和 2021 年经历了两次热力跃迁，「搜索与分析」和「流处理」 在 2019 年热力跃迁， 「交互式分析」和 「DataOps」从 2018 年和 2021 年经历了两次热力跃迁、 「数据湖」在 2020 年热力跃迁。这也呼应了大数据应用场景和规模变化的趋势：从上层数据可视化应用普及，到数据处理技术升级，再到数据存储和管理的结构性演变，最终，数据基础设施能力的提升又反过来推动上层应用技术革新。贾扬清认为，热力跃迁背后体现了技术发展是一个螺旋上升的过程，用户侧需求推进技术往前一步之后，就需要系统侧再往前一步，以实现更好的可扩展性、更低的成本和更高的灵活性；当系统侧达到了一个能够承载更大规模数据计算处理分析的状态，大家又会开始寻求是不是可以把用户侧或业务侧的数据分析、可视化等做得更好。比如，流行的开源大数据可视化工具 Apache Superset，其背后的商业公司 Preset 最近就在 BI 方面做新的探索。相比已经趋于稳定的原 Hadoop 体系，新场景之下，如数据治理分析、流式计算 +OLAP、数据湖等，开源大数据组件仍然在不断推陈出新，未来存在比较多变数。随着这些后起的大数据开源组件越来越庞杂，开发者们驾驭开源数据平台的难度也与日俱增。这其实给想要利用开源组件构建企业级大数据平台的企业带来了相当大的挑战。首先，大部分业务场景都需要多个大数据组件互相配合使用，这就要求技术团队同时掌握很多不同的大数据组件，并且要能融会贯通、知道如何将这些组件更好地组合到一起。但大部分中小公司或传统企业并没有足够的大数据基础人才。因此企业可能需要一个比较专业的大数据团队，为他们提供设计、咨询以及指导，让他们能够把开源大数据的组件串联在一起形成一整套解决方案。其次，当业务规模增大，企业对大数据平台的稳定性、安全性和高可用能力的要求也会随之提高，必然会增加构建大数据平台的复杂性。比如系统出现问题时，到底问题在哪里，怎么去诊断、分析、报警，做到实时可观测，这些配套能力都是开源大数据组件本身不具备的。这需要在开源生态上做出配套的工具或产品，帮助企业更好的发现问题、定位问题和解决问题。以上挑战，在贾扬清和王峰看来，都可以通过云上标准化产品在一定程度上解决掉。但从另一个角度来看，云本身其实也给大数据技术栈带来了一些新的挑战。云原生带来的变化和挑战报告显示，2015 年后出现的新项目，无一例外均在云原生方向进行了积极的技术布局。Plusar、 DolphinScheduler、JuiceFS、Celeborn、Arctic 等诞生于云原生时代的开源项目如雨后春笋般破土成长。这些新项目在 2022 年的热力值占比已经达到 51%，其中，数据集成、数据存储、数据开发与管理等领域都发生了非常大的项目更迭，新项目热力值占比已经超过了 80%。从 2020 年开始， Spark、 Kafka、Flink 等主流项目也陆续正式支持 Kubernetes。云原生趋势下，开源大数据技术栈正处于重构之中。其中数据集成领域的重构相比其他细分领域走得更快一些。随着云端多样化数据收集需求的爆发，以及下游数据分析逻辑的变化，数据集成从“劳动密集型”ETL 工具演进到灵活高效易用的“数据加工流水线”。传统数据集成工具 Flume、 Camel 处于平稳维护状态， Sqoop 已于 2021 年从 Apache 基金会退役。与云原生结合更紧密的 Airbyte、Flink CDC、 SeaTunnel、 InLong 等项目飞速发展。在报告的热力趋势中可以看到，云原生数据集成在 2018 年超越了传统数据集成，从 2019 年开始，这一演进历程加速，热力值逐年翻倍。不少新孵化的项目热力值年均复合增长率超过 100%，增长势头强劲。过去几年，数据源和数据存储逐步迁移到云端，更多元化的计算负载也运行到了云端。云底座实际上改变了开源大数据的很多前提，作为这场变革的亲历者，王峰感触颇深。十多年前，王峰就参与了基于 Hadoop 做大数据开发的工作，当时他还是比较初级的工程师，大部分工作还基于本地机器，需要考虑的问题包括选择什么机型、多大磁盘、磁盘大还是内存大等。如今，大数据的底座变成了云上的虚拟机、容器、对象存储、云存储，所有开源项目从一开始就要考虑弹性架构、要考虑如何具备很好的可观测性、要考虑怎么跟 Kubernetes 等云原生生态天然对接，等等，这些问题已经存在于大家的潜意识里，改变了很多开源项目在初始阶段的预期。同时在云上运行之后，数据架构也会发生变化。比如计算与存储分离已经成为大数据平台的标准架构，是现在大家默认一定要考虑的问题，因此不管是什么大数据组件（Flink、Hive、Presto 等等），在做数据 Shuffle 的时候都要考虑到不能再依赖本机、不能假设会有本地磁盘，因为在云上机器是必定会迁移的。这就需要一个通用的 shuffle 服务来协助完成这项工作，把云上资源模型变化考虑进去做自适应地调度。前不久阿里捐献给 Apache 基金会的开源项目 Celeborn，做的就是帮助计算引擎提升数据 shuffle 性能的工作。技术层面，云给原有的开源大数据体系带来的挑战不止于此。比如调度基础，以前大家都默认在 Hadoop 上做资源管理和调度，上云之后大家则都拥抱 Kubernetes 生态，基于 Kubernetes 来做编排和调度。但 Kubernetes 作为在线调度服务，调度大规模数据计算任务存在瓶颈，阿里内部本身对 Kubernetes 做了非常多改进。另外，比如云存储虽然优势多多，但也存在传输带宽、数据 locality 方面的缺陷。一些后起的开源项目如 JuiceFS、Alluxio 等，就是为了解决云存储加速的问题而生，阿里云 EMR 上的大数据存储加速服务 JindoData 也在做这方面的工作。王峰表示，开源大数据体系还在不断进化，仍需要走一段路，才能真正与云原生彻底结合。大数据从业者如何面向未来发展？作为技术创新的实验场，云原生带来了更灵活的资源弹性和更低的存储、运维成本，让很多企业可以更大胆地在云上做一些尝试，提升了大家试错、试新的意愿，自然也更有利于创新技术或软件的成功。贾扬清观察到，海外有很多新软件或新引擎会走“先吸引用户、然后把用户转化为客户”的路。在他看来，这将来在国内可能也会成为一个趋势，因为云确实提供了一个很好的资源以及软件分发环境。不过云只是给了大家一把很好的锤子，如果一个人能力不强，用的时候也可能会砸到自己的脚。比如，由于用户在云上获得资源更加容易，可能就会比较随意地进行数据存储和计算，进而造成浪费。因此从业务角度，云服务商与用户其实是一体的，云服务商在大规模开源数据体系之上，需要根据企业的需求做更多数据治理方面的工作，帮助用户用好云这把锤子，避免资源浪费。贾扬清表示，如何更有效地使用云平台、云资源已经成为企业越来越关注的需求，现在主要是企业级软件在做这方面的工作，将来可能会有更多开源工具出现。畅享未来的数据工程趋势，贾扬清认为有三个方向是大数据从业者可以重点关注的。首先是云化，即用云来解决系统架构的问题，涵盖了离线实时一体化、大数据 AI 一体化、流批一体化、湖仓一体化四个层面。现在不管是开源项目还是闭源产品其实都在朝着更加一体化的方向发展，Flink 社区新的子项目 TableStore 也是在这个方向上做的一个探索，追根究底是为了在一定程度上降低大数据技术栈的复杂度，未来计算引擎可能也会更多地跟数据治理、数据编排工具结合成为一体化的数据解决方案。其次是上层数据应用会变得更加简单，从长远来看，对于最终用户，所有的数据都可以使用通用的 SQL 方式进行分析。最后，将来会有更多的生态发展起来，无论是阿里云的 Flink、EMR 还是海外的 Databricks、Snowflake、Bigquery 都还只是工具平台，在这些数据平台之上需要有更多类似于 Saleforce 的企业来做出更丰富的垂直解决方案，最终形成更加繁荣的数据生态，当然前提是数据平台先做好标准化。王峰同样很看好数据生态未来的发展，尤其对于开源大数据来说，生态更加关键。现在欧美很多数据领域的公司，虽然各有特色，但相互之间也能形成协同，这样大家就会处于一个良性的竞争状态。王峰认为，这有助于推进各厂商的产品走向标准化，能够给用户和客户带来很多好处。从整个应用市场的角度来说，形成标准化之后，各方能够比较低成本地去接入这个数据工程生态，反过来可以一起把整个市场蛋糕做大。身处快速发展的数据工程领域，大数据从业者如何面向未来发展？将来岗位角色、职责是否会发生变化？贾扬清认为，系统工程师、数据工程师、数据科学家这些角色未来会继续存在。但云已经解决了很多系统问题，所以越来越多工程师角色会开始往上层业务走。偏系统搭建的底层工作，即系统工程师角色，可能会更多聚集在提供标准化服务的云数据服务商、数据引擎服务商等，其他企业则会更加关注业务本身，把人力更多投入在偏数据科学以及上层业务里，不再需要那么多系统工程师。这是社会分工精细化的必然结果。对于数据科学家、数据工程师，他们的职责会更多地偏重于利用数据实现业务价值，包括根据业务需求做数据建模、数据治理等工作，不用再像以前一样去解底层系统和运维等问题，因为这些问题已经被系统工程师、被云解得很好了。Flink Forward Asia 2022 想了解更多大数据领域的最新前沿技术动态？好奇头部企业正在实时计算、数据湖、数据治理等热门方向做哪些探索和实践？欢迎关注 Flink Forward Asia 2022，一场专属于大数据从业者的技术盛宴！Flink Forward Asia（简称 FFA） 是由 Apache 官方授权、阿里云承办的 Apache Flink 社区官方技术大会，今年将采用线上直播方式，广大开发者足不出户就可以在线观看来自阿里巴巴、字节跳动、快手、美团、华为、Shopee、运满满、米哈游、蔚来汽车、集度汽车、菜鸟、网易等全球 40+ 行业一线厂商，围绕 Flink 核心技术、行业实践、平台建设、实时风控、实时湖仓、数据集成等多个时下热门方向的技术创新和实践分享。时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-18
FFA 2022 专场解读 - 流批一体 & 平台建设 & AI 特征工程
Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！FFA 2022 官网：https://flink-forward.org.cn/流批一体流批一体专场由来自快手、京东、数禾、Shopee、蚂蚁集团等企业的技术专家为你呈现流批一体的大规模应用实践案例，详细拆解落地难点和应对方案。另有来自阿里巴巴的技术专家手把手教你如何基于 Hive SQL on Flink 构建流批一体引擎。流批一体架构在快手的实践和思考张静｜快手技术专家，Apache Flink/Calcite Committer本次演讲分享将包括：流批一体的背景流批一体在快手落地思路 & 分阶段建设的目标第一阶段（加强 Flink 批能力建设）在快手的实践 & 挑战 & 进展第二阶段（业务视角的流批一体）的挑战和相关的开放性问题蚂蚁实时低代码研发和流批一体的应用实践马年圣｜蚂蚁集团数据技术专家，实时数仓架构师王 鑫｜蚂蚁集团高级技术专家，Apache Storm PMC，Apache RocketMQ Committer，Apache IoTDB Committer蚂蚁实时研发体系经过一年多的升级，已经形成了基于元表资产+Flink 引擎的实时研发模式，并在此基础上构建了实时的资产消费和保障体系。再往前一步，我们探索并落地了蚂蚁的低代码研发和流批一体研发能力，来降低实时研发门槛并提效实时开发。本次 FFA 期望能够向大家介绍这两种能力的构建背景（业务/技术）、构建思路、核心能力和应用场景案例，来详细分析这两个能力构建的细节。Flink 流批一体方案在数禾的实践杨涵冰｜上海数禾信息科技有限公司，大数据架构师在如今互联网金融服务场景中，特征、模型、决策的实时性变得越来越重要，各场景对于实时化的需求也越来越多。在对各场景的实时化实践中，我们遇到了一些共有的问题：离线、实时数据口径不一致；离线、实时逻辑不一致；批量、点查等查询场景多样；实时流特有概念较难理解，开发门槛较高；实时流回溯测试困难等问题。本次分享将介绍数禾利用 Flink 流批一体方案解决上述问题的实践经验。流批一体在 AI 核心电商领域的探索与实践祝海峰｜阿里巴巴高级技术专家搜索、推荐、广告等核心电商领域，涉及海量的电商、用户行为等数据，需要支持大规模深度模型参数更新，是一个典型的批次/实时计算结合的场景，阿里智能引擎事业部基于大数据存储和计算引擎技术(Flink)，针对复杂业务特点，简化用户 ETL 开发流程，探索出一套行之有效的批流一体技术，支撑了阿里巴巴集团数千个业务场景，具备 PB 级批处理，百万 TPS 吞吐，秒级延迟的处理能力。Hive SQL on Flink 构建流批一体引擎罗宇侠｜阿里云 开发工程师方盛凯｜阿里云 开发工程师在 Flink 1.16 中，社区通过加强对 Hive Dialect 的支持以及引进了 SQL Gateway 进一步提升了 Flink 对于 Hive 兼容性，帮助用户方便地将已有的 Hive 批作业迁移到 Flink 上以构建流批一体的计算引擎。 在大部份的场景下，用户只需要将提交作业的地址更改为 Flink SQL Gateway 就可以将原本的 Hive 作业改为通过 Flink 来执行，做到了无缝切换。同时用户既可以使用 Hive SQL 也可以使用 Flink SQL 的语法写流式任务。在本篇演讲过程之中，将介绍以下内容：构建流批一体引擎的挑战Hive SQL on Flink 构建流批一体引擎流批一体引擎的收益Demo未来展望Flink 流批一体在 Shopee 的大规模实践李明昆｜Shopee 高级研发工程师，Flink Remote Shuffle ContributorShopee 各个业务线对 Flink 流批一体有很多需求，目前 Flink 流批一体已经具有支持大规模生产的能力，可以给数据开发的带来极大价值。Shopee 的 Flink 团队大力发掘流批一体的价值，这次演讲将对这些落地实践做详细介绍。流批一体在 Shopee 的应用场景批处理能力的生产优化与离线生态的完全集成平台在流批一体上的建设和演进未来规划平台建设平台建设专场由来自爱奇艺、知乎、Dinky 社区、货拉拉、美团、联通、小米、Apache StreamPark 社区、阿里巴巴、蚂蚁集团的技术专家分享基于 Apache Flink 的实时计算平台演进与实践。阿里实时计算平台建设实践周凯波｜阿里云高级技术专家，Apache Flink Contributor随着业务的快速发展，集团各个 BU 对实时计算的需求越来越强烈，平台化能显著提高研发效率，降低运维成本。本次分享主要介绍阿里实时计算平台从 2.0 基于 Yarn 的架构到 3.0 云原生时代的演进，以及在 3.0 平台上一些核心功能的建设实践，如健康分，智能诊断，细粒度资源，作业探查以及企业级安全的建设等。Flink 在蚂蚁大规模金融场景的平台建设李志刚｜蚂蚁集团 高级技术专家，蚂蚁集团流计算平台负责人介绍 Flink 在蚂蚁的实践情况，主要包含 Flink on k8s，on k8s 集群模式，热启动，自动化调优，流控，流批一体等技术爱奇艺统一实时计算平台建设李恒｜爱奇艺资深研发工程师为了更好地满足实时业务的需求，实现公司降本增效的目标，爱奇艺大数据团队对实时服务体系进行了系统的整合和优化设计。本次分享将介绍团队基于 Flink 建设统一实时计算平台的经验，以及通过数据湖和 Flink CDC 技术进行架构升级的实践。将分为三部分：基于 Flink 的统一实时计算平台建设：旧服务整合和任务迁移，实现数据和任务统一维护，实现降本增效的目标。基于 Flink 和 iceberg 的流批一体实践：平台化建设和用户行为数据近实时数仓建设。Flink CDC 的实践：典型业务基于 Flink CDC 的数据架构升级。Flink 实时计算平台在知乎演进贾承昆｜知乎大数据架构负责人实时计算平台在知乎的发展Flink SQL + 一站式元数据管理平台化可运维性提升和保障Flink CDC 平台化Dinky 在 Flink 开发模式的开源探索实践亓文凯｜开源 Dinky MaintainerDinky 是一个开源 FlinkSQL 平台，由于它具备自身 Flink 环境，可以构建各种定制业务，所以它的能力不仅仅局限于作业提交运维，而是在 Flink 环境和生态应用带来了无限可能。本次分享将介绍 Dinky 在 Flink 新开发模式的开源探索实践。Dinky & Flink 介绍FlinkSQL 开发调试FlinkCatalog 管理FlinkCDC 整库实时入仓入湖未来规划货拉拉基于 Flink 计算引擎的应用与优化实践王世涛｜货拉拉大数据实时研发平台负责人Flink 在货拉拉的使用现状性能优化主题 1：udf/udtf 维表化 + 经纬度预处理缓存性能优化主题 2：利用 binlog 数据中 old 属性，减少聚合函数计算量数据确定性优化主题：通用版本 Flink Per-partition watermark 问题解决方案数据准确性优化主题：group by 状态过期，延迟数据导致聚合数据覆盖问题稳定性优化主题 1：多场景脏数据容忍稳定性优化主题 2：异步 sink平台化方案 1：指标监控方案平台化方案 2：hdfs/doris 分区数据完整性可见性方案未来展望Flink SQL 在美团实时数仓生产中的增强与实践董剑辉｜美团数据系统研发工程师张 彬｜美团数据系统研发工程师Flink SQL 算子属性可灵活配置的能力建设Flink SQL 实时作业变更后从状态恢复的能力建设Flink SQL 实时作业语义正确性问题排查的能力建设联通 Flink 实时计算平台化运维实践穆纯进｜联通数科实时计算团队负责人，Apache StreamPark Committer业务介绍: 实时计算平台提供了在海量实时数据下打造平台级多种实时计算任务管理能力，集成了 50 多种实时数据源，日均 2.3 万亿的数据处理，支撑了 10000+的数据服务订阅。Flink 作业运维背景：支撑需求多、实时作业多、研发人员多、使用用户多、上线频率高、稳定要求高、监控延迟低、作业上线流程长、作业用途不明确、作业异常责任人不明确。基于 StreamPark 打造一站式的面向 Flink 实时计算作业的 DevOps 平台和作业管理平台，集成了项目创建、代码编译、作业创建、环境设置、资源配置、作业启停、监控告警、日志管理、UDF、版本管理、支持 YARN/Kubernetes/Remote 等多集群的管理功能。小米基于 Flink 的实时数仓建设实践周超｜小米软件开发工程师在实时数仓场景下，小米选择 Flink 作为实时计算引擎，数据湖 Iceberg 作为存储底座，在流批一体方向不断探索，本次分享围绕小米在实时数仓方面的探索与实践展开，主要涉及：小米数仓架构演进基于 Flink+Iceberg 的实时数仓架构升级实践，提升链路稳定性与实时性针对 Flink 状态过期而导致计算不确定性问题，介绍流批一体的解决方案未来规划Apache Streampark 让 Flink 开发管理更简单王华杰｜Apache StreamPark PPMC, 社区发起人Apache StreamPark(Incubating) 于 2022 年 9 月 1 号正式通过投票成为 Apache 软件基金会的孵化项目, 初衷是让流处理更简单，StreamPark 规范了项目的配置, 定义了最佳的编程方式, 提供了一系列开箱即用的 Connectors 和一套快速开发的脚手架, 使用 StreamPark 开发,可以极大降低学习成本和开发门槛, 让开发者只用关心最核心的业务。另一方面，在实时作业开发部署管理方面, 没有针对 Flink 作业的专业管理平台，这是企业在实践中会遇到的一道坎。StreamPark 提供专业的作业开发管理平台，包括但不限于作业开发、调试、交互查询、部署、操作、运维、实时数仓&流式数仓等, 是一个完整的解决方案, 这次演讲将对这些落地实践做详细介绍。项目简介核心能力实现原理最佳实践新功能预览未来规划AI 特征工程AI 特征工程专场将由来自腾讯、字节跳动、阿里巴巴的技术专家带来基于 Flink 的实时特征工程平台建设思路与落地实践。FeatHub: 流批一体的实时特征工程平台林东｜Apache Kafka Committer 和 PMC 成员本次演讲中，我们将介绍 FeatHub，一个由阿里云自研并开源的实时特征平台。我们将介绍 FeatHub 的架构设计，已经完成的工作，以及近期的发展计划。我们为 FeatHub 设计了易于使用的 Python SDK，来方便用户开发，分享，以及部署特征工程作业到生产环境。FeatHub 目前支持使用 Flink 作为计算引擎来完成流批一体的特征计算，支持在 Kafka,文件系统等多种存储引擎中读取和存储特征。用户可以使用声明式的 API 来定义特征，无需担心特征穿越的问题，也无需使用相对复杂的底层计算引擎 API 来计算特征。我们希望通过提供这些功能，来提升特征工程作业的开发效率，并推动实时特征工程的应用发展。我们将介绍 FeatHub 在运满帮的实践经验，并展望 FeatHub 未来的发展方向。FeatHub 已经在 https://github.com/alibaba/feathub 开源。欢迎大家尝试使用并提供反馈。微信安全基于 Flink 实时特征开发平台实践李天旺｜腾讯专家级工程师介绍微信安全基于 Flink 建设一站式实时特征开发平台实践；通过提供常用组件，方便重用能力与快速开发，并实现业务人员无需熟悉 Flink、无需写代码会简单 SQL 就能快速开发；再通过画布的形式组装组件，使业务逻辑更清晰、方便不同业务之间借鉴，赋能其他相似业务场景。议题大纲如下：风控实时特征开发的诉求与挑战高效的一站式实时特征开发平台建设思路线上运营过程遇到挑战质量保障基于 Flink ML 搭建的智能运维算法服务及应用张颖莹｜阿里云计算平台算法专家大数据平台运维场景对算法的需求特点（实时、海量、多源异构数据）智能运维算法在大数据平台运维业务场景的应用案例和典型模型。传统算法架构的局限性使用 Flink ML 搭建智能运维算法服务具体流程和收益字节跳动十亿级特征计算平台的建设和应用廖嘉逸｜字节跳动推荐特征生产方向负责人刘首维｜字节跳动推荐架构工程师字节跳动推荐架构在去年开始着手构建了流批一体的特征生产系统，基于 Flink 和强大的 State 能力功能实现了有状态的窗口统计类特征，并在 ETL 特征场景实现了 Flink Streaming & Batch 的流批一体。随着业务的逐步上量和场景的不断丰富，系统又在易用性、性能、机器学习生态支持上，出现了新的问题和挑战。我们在特征系统推广的过程中遇到了算法工程师调优实时特征的成本过高、生产链路无法和特征回溯打通、长周期的实时特征无法初始化、特征类型支持不足等问题。通过对流批一体架构的多次迭代，我们在计算层面引入了跨作业的流批一体 Planner、状态 Bootstrap 等能力，帮助特征生产系统的生态更上了一个台阶。背景流批一体架构回顾流批一体 Planner问题与挑战未来规划以上为 Flink Forward Asia 2022 流批一体 & 平台建设 & AI 特征工程专场内容节选，了解更多大会详情可点击下方链接：https://flink-forward.org.cn/移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-17
FFA 2022 专场解读 - 实时风控 & 实时湖仓 & 数据集成
FFA 2022 专场解读 - 实时风控 & 实时湖仓 & 数据集成Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！FFA 2022 官网：https://flink-forward.org.cn/实时风控实时风控专场将由网易互娱、字节跳动、京东、AirWallex、阿里巴巴的技术专家分享实时风控平台建设的实践案例。网易游戏实时 HTAP 计费风控平台建设林佳｜网易互娱技术中心计费实时平台与 SDK 技术负责人，Apache Flink Contributor，Flink CDC Contributor用户在终端设备上的一次行为动作，往往需要多个系统协作完成，其间会同时触发多个请求，产生跨越多个服务提供方和各类异构数据的一次业务会话。计费行为（登录/支付等）正是这类复杂业务会话的典型，也是关系到营收的风险控制关键阶段。要实时关联并还原业务会话，满足具体问题定位、宏观质量监控、故障分类和归因等风控需求，是业界的一大难题。在网易互娱计费数据中心开发计费实时风控需求的实践中，基于 Flink 和 TiDB，在实时计算、非结构化存储、HTAP 实践等技术领域做了大量的探索，积淀了不少业界前沿的实践经验，本次演讲旨在与分享和讨论其中的关键技术和最佳实践，本次演讲内容将包括：基于 Flink 的配置式跨请求复杂风控业务会话关联分析实时异常识别与自适应修复提升数据能效Flink + TiDB，实时 HTAP 风控平台建设Flink CEP 在抖音电商的业务实践张健｜字节跳动数据工程师FlinkCEP 是基于 Flink 实现的实时数据规则引擎，支持跨多个事件的规则匹配。然而，当前 FlinkCEP 在多规则处理、规则表达方面还存在易用性问题。本次分享主要介绍 FlinkCEP 在抖音电商业务的应用实践以及易用性优化：FlinkCEP 简介抖音电商业务场景介绍抖音电商应用实践收益总结未来展望京东物流实时风控实践周文跃｜运营数据产品部-风控数据产品组架构师京东物流风控涉及到的业务介绍（包括招投标、商家、仓、分拣、运输、配送），风控场景概括，每个业务类型中关系到的风险场景介绍，招投标涉及的围标串标、商家中的虚假商家、分拣中偷重漏重等等，本次分享包含京东对实时风控的整体思考、技术方案以及目前的实践应用情况。京东物流业务介绍物流风控场景概括物流风控平台建设Flink 赋能，实时技术赋能前后对比技术挑战，平台建设所遇到的一些挑战以及如何解决未来规划Flink CEP 新特性进展与在实时风控场景的落地耿 飙｜阿里云开发工程师，Flink Contributor胡俊涛｜阿里云开发工程师，Flink ContributorFlink CEP 是基于 Flink 实现的复杂事件处理库，它可以识别出数据流中符合特定模式(Pattern)的事件序列，并允许用户作出针对性处理。依托于 Flink 的分布式特性、毫秒级处理延迟以及自身丰富的规则表达能力，Flink CEP 在实时风控、实时营销场景中扮演着越来越重要的角色。本次分享我们会介绍 Flink 社区在 1.16 中对 Flink CEP 所做的增强与优化。除此之外，我们还会介绍阿里云实时计算团队为了进一步提高 Flink CEP 的泛用性与易用性所做的工作，包括：支持规则热更新、支持多规则在同一数据流上进行匹配等新特性；拓展了 Flink SQL 的 MATCH_RECOGNIZE 语法，进一步增强 MATCH_RECOGNIZE 表达能力。展示中，我们会针对实时反作弊场景，通过一个 Demo 来展示如何使用 Flink CEP 来构建实时反作弊应用，并在作业运行的过程中，动态热更新反作弊规则。AirWallex 基于 Flink 打造实时风控系统董大凡｜AirWallex 风控团队研发经理作为一家金融科技公司，Airwallex提供跨境支付，跨境收账的诸多跨境金融服务。为了应对交易过程中面对的洗钱，诈骗等金融风险， Airwallex的风控团队决定全面拥抱Flink，借助Flink的流批一体能力，打造AirWallex的实时风控系统。 本次分享主要介绍我们如何基于Flink构建高可用低延时的风控服务公司业务背景介绍风险及应对方案技术挑战与亮点高可用性保证线上表现实时湖仓实时湖仓专场邀请快手、bilibili、SmartNews、美团、SelectDB、OceanBase、StarRocks 等企业技术专家分享基于 Flink 的实时湖仓建设实践与思考。Flink + Hologres：构建企业级 Streaming Warehouse 实时数仓姜伟华｜阿里云一站式实时数仓 Hologres 总负责人随着实时数仓的普及，在线化、一站式、敏捷化成为实时数仓新的发展趋势，阿里云 Hologres 支持高吞吐写入与更新、PB 级数据秒级查询以及高并发的在线服务查询，并与 Flink 深度融合，解决传统数仓加工链路长、数据更新难等问题，提供一站式实时数仓标准解决方案。通过 Flink Catalog、Hologres binlog 等的深度整合，Flink+Hologres 为用户提供了完整的企业级实时数仓 Streaming Warehouse 构建能力，让用户把实时数仓变的易用好用。本次演讲内容主要包含：实时数仓分层的技术需求阿里云一站式实时数仓Hologres介绍Flink x Hologres：天作之合基于Flink Catalog的Streaming Warehouse实践快手基于 Apache Flink 的实时数仓建设实践冯立｜快手实时数据开发工程师羊艺超｜快手实时数据开发工程师本次演讲围绕快手在实时数仓方面的探索与实践展开，主要涉及：实时数仓建设的方法论，降本增效背景下资源优化的方法论，以及实时数仓的场景化实战。快手实时数仓的发展实时数仓建设方法论实时数仓场景化实战未来规划B 站实时数据湖实践周晖栋｜bilibili 大数据实时团队 资深开发工程师本次演讲分享将包括：背景和痛点探索：DB 入仓，埋点入仓，BI 实时报表场景基建优化总结展望美团买菜基于 Flink 的实时数据建设实践严书｜美团买菜实时数仓技术负责人美团买菜属于美团全链条自营的生鲜零售业务，Flink 在实时数据分析、业务生产实时监控、实时特征等场景下有着广泛的应用，本次分享主要介绍美团买菜基于 Flink 的实时数据建设实践经验。SmartNews 基于 Flink 的 Iceberg 实时数据湖实践戢清雨｜SmatNews 数据平台架构师， Apache Iceberg Contributor本次演讲分享将包括：SmartNews 数据湖介绍基于 Iceberg v1 格式的数据湖实践基于 Flink 实时更新的数据湖（Iceberg v2 format）解决方案Flink 实时更新带来的小文件数量性能问题性能评估总结Flink Table Store 0.3 构建流式数仓最佳实践李劲松｜阿里巴巴高级技术专家，Apache Flink PMC本次演讲分享将包括：流式数仓核心需求Flink Table Store 最佳实践Flink Table Store 0.3 核心能力Apache Flink X Apache Doris：构建极速易用的实时数仓架构王磊｜SelectDB 资深大数据研发专家、Apache Doris Contributor作为一个现代化、高性能、支持实时的 OLAP 数据库，目前 Apache Doris 与 Apache Flink 结合构建的实时数仓架构已经得到众多用户的应用。与此同时，如何进一步简化数据同步链路、提升数据实时性以及高并发写入性能，也是 Apache Doris 在持续优化和迭代的重要方向。 在本次分享中，我们将为大家介绍如何基于 Apache Doris 和 Apache Flink 构建极速易用的实时数仓架构。美团增量数仓建设新进展汤楚熙｜美团数据系统研发工程师数据生产一直以来存在离线与实时两套流程，口径不统一，维护成本高，数据生产就绪时间将会越来越难保证，伴随着实时数仓的 SQL 化和实时数仓平台的推广，一些业务团队实时与离线开发开始集中到同一批人身上，开发方式也逐渐趋同，离线与实时流程统一具备了实现的要求，基于美团长期以来的能力储备，我们适时的提出增量生产，以解决离线数仓就绪时间难保证、离线+实时两套生产流程所带来的数据正确性、开发成本等问题。OceanBase+Flink：构建高效的实时计算解决方案周跃跃｜OceanBase 架构师本次演讲分享将包括：分布式数据库 OceanBase 关键技术解读OceanBase 与 Flink 生态对接以及典型应用场景OceanBase X Flink 生产实践展望Flink + StarRocks：实时数据分析新范式谢寅｜StarRocks 社区技术布道师本次分享围绕以下五个方面：StarRocks 极速分析核心能力基于 Primary Key 模型实现有更新的实时数据分析Flink + StarRocks Primary Key 带来了数据分析性能怎样的改变京东物流的实践案例StarRocks 未来实时数仓新范式数据集成云原生为数据集成领域注入了全新生命力，本专场邀请小红书、小米、科杰科技、易车、京东、顺丰、XTransfer、阿里等技术专家分享基于 Flink 的数据集成系统探索与实践。基于 Flink CDC 高效构建现代数据栈徐榜江｜阿里云技术专家, Apache Flink Commiter & Flink CDC Maintainer阮 航｜阿里云高级开发工程师，Apache Flink Contributor & Flink CDC Maintainer本次演讲分享将包括：深入解读 Flink CDC 2.3基于 Flink CDC 构建现代数据栈基于 Flink CDC 的现代数据栈实践DemoFlink 的数据集成类服务在小红书降本增效的实践与应用袁奎｜小红书高级开发工程师小红书作为在多云架构云原生场景中的头部公司，其存在数据分布在不同云上的问题，所以基于 Flink 数据集成和传输是大数据处理和分析业务侧的基石。在降本增效的业界大环境下，不断苛刻的成本要求，对目前基于 Flink 的数据集成传输提出了更高的要求，我们在这个背景下做了两个维度的优化措施和方案。本次演讲分享将包括：小红书基于 Flink 的数据集成传输类服务的特点和挑战；Flink 批模式和虚拟集群部署的实践；实践过程中遇到的问题以及解决方案；未来展望基于 Flink 的小米数据集成实践胡焕｜小米计算平台高级工程师本次演讲中，我们将介绍小米在数据集成领域的思考和实践，以及正在打造的基于 Flink 的数据集成引擎。生产实践环节中，我们将展示部分小米数据集成的实战案例。本次演讲分享将包括：MySQL 实时数据集成支持分库分表中间件TiDB 百亿级单表实时集成到 IcebergDoris 写入支持分区覆盖语义非结构化数据集成数据集成产品设计基于 Flink CDC 的实时同步系统张军｜科杰科技大数据架构师，Apache Flink、Iceberg、StreamPark ContributorFlink CDC 技术为数据的实时同步提供了稳定、可靠的保证，但是还是存在一些不足，比如无法支持整库同步，无法支持 ddl 同步等，所以我们基于 Flink cdc 开发了一套实时同步系统，使用户通过可视化页面就能进行数据的同步，并且还对数据同步的功能做了增强，添加了很多额外的功能。本次演讲分享将包括：功能概览：可视化操作、库同步、多表同步、DDL 支持、多数据源支持、丰富的数据类型支持、其他功能支持技术方案未来规划Flink CDC 在易车的应用实践王林红｜易车数据平台负责人Flink 在易车实时数仓、实时数据集成、湖仓一体等方面有很广泛的应用实践，尤其是满足实时大屏、实时流量分析及实时大促等应用场景。本次分享主要介绍 Flink CDC 在易车相关应用的落地实践及经验分享：Flink CDC 全增量一体化框架介绍及基于 Flink CDC 的 DTS 平台建设实践Flink CDC 实践问题与优化Flink CDC+hudi 集成及实时数据湖应用实践Flink CDC 在京东的探索与实践韩飞｜京东资深技术专家，Apache Flink Contributor演讲内容大纲：京东自研 CDC 介绍(业务规模、部署容灾、技术架构、技术特性)京东场景的 Flink CDC 优化(指定位点、自动切库、监控告警扩展、多实例)业务案例(业务背景、数据架构演进)未来规划顺丰基于 Flink CDC + Hudi 推进实时业务落地唐尚文｜顺丰科技 大数据平台研发高级工程师主要分享顺丰基于 Flink 实时计算应用的场景, 实时数据平台的建设实践、以及我们在这个过程中对 Flink CDC 实践经验与 Hudi Schema Evolution 等一些相关的工作内容。Flink CDC & MongoDB 联合实时数仓的探索实践孙家宝｜XTransfer 基础架构团队 技术专家本次演讲将分享 Flink & MongoDB 构建实时数仓的一些探索，以及 MongoDB CDC Connector 和 MongoDB Connector 的实现原理和使用实践。以上为 Flink Forward Asia 2022 实时风控 & 实时湖仓 & 数据集成专场内容节选，了解更多大会详情可点击下方链接：https://flink-forward.org.cn/移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-16
基于 Apache Flink Table Store 的全增量一体实时入湖
作者｜陈婧敏本文简要回顾了数据入湖（仓）的发展阶段，针对在数据库数据入湖中面临的问题，提出了使用 Flink Table Store 作为全增量一体入湖的解决方案，并辅以开源 Demo 的测试结果作为展示。文章主要内容包括：数据库数据集成入湖（仓）的发展阶段及面临痛点基于 Apache Flink Table Store 解决全增量一体入湖总结与展望1. 数据入湖（仓）发展阶段及面临痛点基于数据库的数据集成过程，简要来说经历了如下几个阶段。1.1 全量 + 定期增量的数据入仓Fig.1 数据入仓: 一次全量+周期增量全量数据通过 bulk load 一次性导入，定时调度增量同步任务从数据库同步增量到临时表，再与全量数据进行合并。这种方式虽然能满足一定的业务需求，但是也存在以下问题。::: ⚠️ 链路复杂，时效性差:::全量与增量需要定期的合并以获取最新的数据快照，由于不支持记录级别的更新，用户需要额外的 SQL 任务去计算去重；数据新鲜度依赖于调度，若数据存在晚到，则还需要处理数据漂移情况，一种常见处理方式是在 T +N 时刻（processing time）调度产生 T （event time）的合并任务，同时取 T ~ T + N 个分区（processing time），再从中过滤出业务时间小于等于 T （event time）的数据进行合并，这会导致数据新鲜度进一步降低。::: ⚠️ 明细查询慢，排查问题难:::虽然下游会使用各种交互式分析引擎来加速查询，但基于成本考虑，底表明细数据一般没有这种待遇，这就导致在数据正确性排查时需要直接查询明细，特别是需要查询合并前后全量和增量的明细变化来定位问题。如果业务变更，导致一批订单数据需要订正并要求生成订正之后的各类指标，则需要手工对原始表及其下游依赖表进行级联订正。1.2 全量 + 实时增量的数据入湖相对于传统数据仓库，数据湖的出现使得数据在以低成本存储的同时，数据新鲜度有了极大的提升。以 Apache Hudi 为例，它支持先做一次全量 bootstrap 构建基础表，然后基于新接入的 CDC 数据进行实时构建 基于 Hudi 的湖仓一体技术在 Shopee 的实践[1]，如 Fig.2 所示。Fig.2 数据入湖: 一次全量+实时增量由于支持记录级别的更新及删除，在存储侧就可以完成主键的去重，不再需要额外的合并任务。在数据新鲜度方面，由于流式作业会定期的触发 checkpoint 来产生全量与增量合并后的快照，故而数据新鲜度对比第一种方式（以天或小时调度产生合并快照）有了很大提升。但从另外一方面，我们也发现这种方式有以下这些问题。::: Bootstrap Index 超时及 state 膨胀:::以流模式启动 Flink 增量同步作业后，系统会先将全量表导入到 Flink state 来构建 Hoodie key（即主键 + 分区路径）到写入文件的 file group 的索引，此过程会阻塞 checkpoint 完成。而只有在 checkpoint 成功后，写入的数据才可以变为可读状态，故而当全量数据很大时，有可能会出现 checkpoint 一直超时的情况，导致下游读不到数据。另外，由于索引一直保存在 state 内，在增量同步阶段遇到了 insert 类型的记录也会更新索引，需要合理评估 state TTL，配置太小可能会丢失数据，配置过大可能导致 state 膨胀。::: 链路依然复杂，难以对齐增量点位，自动化运维成本高:::全量 + 实时增量的方式并没有简化链路的复杂度，因为它额外引入了 Kafka 的运维，需要手工对齐增量消费的点位以防止数据丢失 Change Data Capture with Debezium and Apache Hudi[2]。在启动增量 CDC 作业后，用户需要等待和观察作业的运行状态，在第一次 checkpoint 成功后，暂停作业（stop-with-savepoint）修改配置禁用 Bootstrap Index，然后从 savepoint 重启作业（ restore-from-savepoint）。整个过程操作复杂，实现自动化运维成本比较高。此外，我们回顾了一些使用 Hudi 的行业实践，发现用户需要格外注意各项配置来实现不同需求，这对易用性有一定的伤害。比如 基于 Hudi 的湖仓一体技术在 Shopee 的实践[1] 中提到的需要在平台层面监控用户的建表语句，防止在大规模写入场景配置为 COW（Copy on Write） 模式；全增量切换时用户必须格外注意 Kafka 消费点位来保证数据准确性，参数配置极大影响了作业的数据准确性及性能。2. 基于 Apache Flink Table Store 的全增量一体入湖随着基于日志的 CDC 逐步取代基于查询的 CDC，特别是 Flink SQL CDC 在 source 端已支持全增量一体同步后，全增量一体入湖（使用一个流作业完成全量同步、并持续监听增量 changelog）也成为一个新的探索方向。这种方式降低了链路复杂度，同时将全增量切换时需要手工对齐 offset 的繁琐托管给了 Flink CDC 和 checkpoint 机制，让框架层面去保障数据的最终一致性。但经过调研我们发现，在使用 Hudi 做这种尝试时遇到了以下挑战。::: 全量同步阶段数据乱序严重，写入性能和稳定性难以保障 :::在全量同步阶段面临的一个问题是多并发同时读取 chunk 会遇到严重的数据乱序，出现同时写多个分区的情况，大量的随机写入会导致性能回退，出现吞吐毛刺，每个分区对应的 writer 都要维护各自缓存，很容易发生 OOM 导致作业不稳定。虽然 Hudi 支持通过 Rate Limit Apache Hudi DeltaStreamer#Rate Limit[3] 限制每分钟的数据写入来起到一定的平滑效果，但在作业稳定性和性能吞吐之间取得平衡的调优过程对于一般用户来说门槛也较高。2.1 为什么选择 Flink Table StoreApache Table Store https://github.com/apache/flink-table-store[4] 作为 2022 年初开源的 Apache Flink 子项目，目标是打造一个支持更新的据湖存储，用于实时流式 Changelog 摄取和高性能查询。::: 大吞吐量的更新数据摄取，支持全增量一体入湖，一个 Flink 作业搞定所有:::Fig.3 Flink Table Store: 全量 + 增量一体化同步回顾前文，我们知道全增量一体化同步入湖的主要挑战在于全量同步阶段产生了大量数据乱序引起的随机写入，导致性能回退、吞吐毛刺及不稳定。而 Table Store 的存储格式采用先分区（Partition）再分桶（Bucket），每个桶内各自维护一棵 LSM（Log-structured Merge Tree）的方式（参见 Fig.4、Fig.5），每条记录通过主键哈希落入桶内时就确定了写入路径（Directory），以 KV 方式写入 MemTable 中（类似于 HashMap，Key 就是主键，Value 是记录）。在 flush 到磁盘的过程中，以主键排序合并（去重），以追加方式写入磁盘。Sort Merge 在 buffer 内进行，避免了需要点查索引来判断一条记录是 insert 还是 update 来获取写入文件的 file group 的 tagging Apache Hudi Technical Specification#Writer Expectations[5] 。另外，触发 MemTable flush 发生在 buffer 充满时，不需要额外通过 Auto-File Sizing Apache Hudi Write Operations#Writing path[6]（Auto-File Sizing 会影响写入速度 Apache Hudi File Sizing#Auto-Size During ingestion[7]）来避免小文件产生，整个写入过程都是局部且顺序的 On Disk IO, Part 3: LSM Trees [8]，避免了随机 IO 产生。使用 Table Store 作为湖存储时，只需要一条 INSERT INTO 语句就可以完成全增量同步。以如下 SQL 为例，它展示了使用一个 Flink 流作业将 MySQL 数据库中的订单表通过 Streaming 方式写入 Table Store 表，并持续消费增量数据。 -- 创建并使用 table store catalog CREATE CATALOG `table_store` WITH ( 'type' = 'table-store', 'warehouse' = 'hdfs://foo/bar' ); USE CATALOG `table_store`; -- 定义 mysql-cdc source 表 CREATE TEMPORARY TABLE `orders_cdc` ( order_id BIGINT NOT NULL, gmt_modified TIMESTAMP(3) NOT NULL, ... PRIMARY KEY (`order_id`) NOT ENFORCED ) WITH ( 'connector' = 'mysql-cdc', ... ); -- 定义 table store ods 表，按日期作分区 CREATE TABLE IF NOT EXISTS `orders` ( ... PRIMARY KEY (`dt`, `order_id`) NOT ENFORCED ) PARTITIONED BY (`dt`); -- streaming 模式下提交作业 SET 'execution.runtime-mode' = 'streaming'; -- 设置 1min 的 cp interval，对应 1min 的数据新鲜度 SET 'execution.checkpointing.interval' = '1min'; -- 一条 SQL 同步全量 + 增量，动态分区写入 INSERT INTO `orders` SELECT ..., DATE_FORMAT(gmt_modified, 'yyyy-MM-dd') AS dt FROM `orders_cdc`;Fig.4 展示了以 dt 作为分区 orders 表的存储结构，在用户指定总 bucket 数 N 后，每个分区下会生成相应的 bucket-${n} 目录，每个目录下以列存格式（orc 或 parquet）存放 hash_func(pk) % N == ${n} 的记录文件。 Fig.4 Flink Table Store 表的文件目录元数据与数据存储在表的同一级目录下，包括 manifest 目录和 snapshot 目录。manifest 目录下中记录了每次经 checkpoint 触发而提交的数据文件变更，包含新增和删除的数据文件snapshot 目录下记录了每次提交产生的 snapshot 文件，内容包括为上一次提交产生的 manifest，加上本次提交产生的 manifest 作为增量Fig.5 展示了 Fig.4 中每个 bucket 内 LSM 实现过程。我们以 Flink 流作业为例，在每次 checkpoint 时，Flink Table Store 会产生一次提交（commit），包含以下信息生成当前 table 的一个快照（snapshot）。系统会通过 snapshot pointer file（类似于指针）追踪最早产生和当前最新的 snapshot 文件snapshot 文件中包含了本次 commit 新增了哪些 manifest 文件、删除了哪些 manifest 文件每个 manifest 文件中记录了产生了哪些 sst 文件、删除了哪些 sst 文件，以及每个 sst 文件所包含记录的主键范围、每个字段的 min/max/null count 等统计信息每个 sst 文件则包含了按主键排好序的、列存格式的记录。对于 Level 0 的文件，Table Store 会异步地触发 compact 合并线程来消除主键范围重叠带来的读端 merge 开销。Fig.5 Flink Table Store 表的 LSM 实现在 Flink Table Store 0.2.0 发布时，我们测试了五亿条数据在一亿主键下的实时更新场景写入（包含插入与更新）并与 Apache Hudi MOR 及 COW 进行对比 Apache Flink Table Store 0.2.0 发布[9], Table Store 在大规模实时更新写入场景拥有良好的写入性能。::: 高效 Data Skipping 支持过滤，提供高性能的点查和范围查询:::虽然没有额外的索引，但是得益于 meta 的管理和列存格式，manifest 中保存了文件的主键的 min/max 及每个字段的统计信息，这可以在不访问文件的情况下，进行一些 predicate 的过滤orc/parquet 格式中，文件的尾部记录了稀疏索引，每个 chunk 的统计信息和 offset，这可以通过文件的尾部信息，进行一些 predicate 的过滤数据在有 filter 读取时，可以根据上述信息做如下过滤1. 读取 manifest：根据文件的 min/max、分区，执行分区和字段的 predicate，淘汰多余的文件2. 读取文件 footer：根据 chunk 的 min/max，过滤不需要读取的 chunk3. 读取剩下与文件以及其中的 chunks以上述订单表 orders 为例，当用户想要查询 dt = 2022-01-01 分区下所有 order\_id 在 100 ~ 200 之间的订单时 SELECT * FROM orders WHERE dt = '2022-01-01' AND order_id >= 100 AND order_id <= 200;Flink Table Store 会先根据 LATEST-SNAPSHOT 文件读到最近一次提交的 snapshot 文件（read committed），然后从 snapshot 中读取到对应 manifest meta 文件， 根据分区条件 dt='2022-01-01'，过滤出包含这些分区的统计信息，由于统计信息里包含了每个 sst 文件 key 的范围，所以继续执行 order\_id 在 [100, 200] 区间这个过滤条件，就能在 2022-01-01 这个目录下只读取对应的 sst 文件。我们同样基于上述数据集测试了 Flink Table Store 的查询性能 Apache Flink Table Store 0.2.0 发布[9]，在点查和范围查询的场景下，Flink Table Store 表现出众。从实现原理来说，MOR 的查询性能低于 COW、COW 的写入性能低于 MOR 是难以避免的。而在实践层面，在大规模写入场景下建立的 MOR 表也很难一键转换为 COW 来读取，所以在查询写入较多的表（MOR 表）这个前提下，Flink Table Store 的查询表现还是不俗的。::: 文件格式支持流读:::Flink Table Store 实现了 Incremental Scan，在流模式下，可以持续监听文件更新，数据新鲜度保持在分钟级别，如下所示。 -- 进入 SQL CLI，创建 catalog 和 table CREATE CATALOG table_store WITH ( 'type' = 'table-store', 'warehouse' = 'file://foo/bar/' --或 'hdfs://foo/bar' ); CREATE TABLE IF NOT EXIST my_table ( f0 INT, f1 STRING, PRIMARY KEY(f0) NOT ENFORCED ); -- 切换到 batch 模式，写入数据 SET 'execution.runtime-mode' = 'batch'; INSERT INTO my_table VALUES(1, 'Hello'); -- 新打开一个 SQL CLI 中，切换到 streaming 模式，提交流式查询 SET 'execution.runtime-mode' = 'streaming'; SET 'sql-client.execution.result-mode' = 'tableau'; SELECT * FROM my_table; -- 可以读到结果如下 +----+-------------+--------------------------------+ | op | f0 | f1 | +----+-------------+--------------------------------+ | +I | 1 | Hello | -- 在第一个 SQL CLI 中，继续写入数据 INSERT INTO my_table VALUES(1, 'Bye'), (2, '你好'); -- 可以在第二个 SQL CLI 中，观察到新增输出 (-U, 1, Hello)，(+U, 1, Bye) 和 (+I, 2, 你好) +----+-------------+--------------------------------+ | op | f0 | f1 | +----+-------------+--------------------------------+ | +I | 1 | Hello | | -U | 1 | Hello | | +U | 1 | Bye | | +I | 2 | 你好 |2.2 基于 TPC-H 数据集的全增量一体入湖 Demo前文对 Flink Table Store 解决全增量一体入湖进行了简要分析，下面一个实例演示了如何在本地单机环境下，将近六千万条订单记录作为全量数据从 MySQL 同步到 Flink Table Store，并持续消费增量更新（由 TPC-H RF1 和 RF2 产生），下游接实时聚合及查询的过程。数据源由 TPC-H 自动生成并导入 MySQL ，运行在 Docker 容器内，本地只需要下载 Flink release 包和 Flink Table Store 依赖即可完成。Demo 使用 lineitem 表中发货日期 l\_shipdate 作为业务字段定义了二级分区 l\_year 和 l\_month，时间跨度从 1992.1 ~ 1998.12，即动态写入 84 个分区。 经测试，在本地单机并发为 2，checkpoint interval 为 1 min 的配置下（每分钟更新可见）46 min 内写入 59.9 million 全量数据，每 10 min 的写入性能如下表所示，平均写入性能在 1.3 million/min。详细配置如下所示详细步骤可查看 Apache Flink Table Store 全增量一体 CDC 实时入湖。3. 总结与展望本文简要回顾了数据入湖（仓）的发展阶段，针对在数据库数据入湖中面临的问题，我们提出了使用 Flink Table Store 作为全增量一体入湖的解决方案，并辅以开源 Demo 的测试结果作为展示。我们期待用户的一线反馈及同行深入交流，欢迎大家扫码加入钉钉群一起探索。4. Reference[1] 基于 Hudi 的湖仓一体技术在 Shopee 的实践[2] Change Data Capture with Debezium and Apache Hudi[3] Apache Hudi DeltaStreamer#Rate Limit[4] https://github.com/apache/flink-table-store[5] Apache Hudi Technical Specification#Writer Expectations[6] Apache Hudi Write Operations#Writing path[7] Apache Hudi File Sizing#Auto-Size During ingestion[8] On Disk IO, Part 3: LSM Trees[9] Apache Flink Table Store 0.2.0 发布Flink Forward Asia 2022 时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-08
《2022开源大数据热力报告》发布，Flink 摘得「流处理」领域热力值 TOP1
11 月 5 日，在云栖大会一体化大数据智能峰会上，由开放原子开源基金会、X-lab 开放实验室和阿里巴巴开源委员会联合出品的《2022开源大数据热力报告》重磅发布。开放原子开源基金会副秘书长刘京娟开放原子开源基金会副秘书长刘京娟对报告进行了深度解读。报告基于公开数据研究最活跃的 102 个开源大数据项目，探寻出开源大数据技术发展背后的 “摩尔定律”：每隔 40 个月，开源项目热力值就会翻一倍，技术完成一轮更新迭代。在过去 8 年里，发生了 5 次较大规模的技术热力跃迁，多元化、一体化、云原生成为当前开源大数据发展趋势的最显著特征。定量分析 “后 Hadoop 时代” 开源趋势Hadoop 作为开源大数据技术的起源，兴起于 2006 年，至今已有 16 年历史。报告收集了从 Hadoop 发展第 10 年（即 2015 年）至今的相关公开数据，并进行了关联分析，定义了开源项目热力值研究模型，用量化指标描述开源项目的开发迭代活跃度和受开发者欢迎程度。报告所呈现的开源大数据热力图，从技术全景、技术栈分类以及项目维度对入围项目的热力表现进行洞察，将项目进程中的关键事件与热力表现关联分析，并访谈了开源基金会、知名开源项目等领域专家，尝试找到项目健康发展一般规律，并对有效提升项目影响力的方法论进行了归纳总结。开源大数据技术的 “摩尔定律”报告发现，每隔 40 个月，热力值会提升1倍，开源大数据完成一轮技术迭代升级，而且技术周期在加速缩短。在 8 年时间内，发生了多轮热力变迁，反映出背后技术的更新换代趋势。开发者对「数据查询与分析」保持了长期的开发热情，连续 8 年位居热力值榜首。2017 年，「流处理」热力值超过「批处理」，大数据处理进入实时阶段。数据规模不断扩大，数据结构也更多样化，「数据集成」从 2020 年开始爆发式增长。三大热力趋势：多元化、一体化和云原生用户需求多样化推动技术多元化。「数据湖」以 34% 的热力值年均复合增长率高居热力值增速第一位，「交互式分析」、「DataOps」紧随其后，分列第二、三位 。而原有 Hadoop 体系的产品迭代则趋于稳定，热力值年均复合增长率为 1%。从 2015 年开始，计算部分率先进入「一体化」演进历程，其中的典型代表「流批一体」在 2019 年出现了第一个热力峰值。以数据湖存储为代表的存储一体化从 2019 年起进入了一个新的发展阶段，涌现了 Delta Lake、 Iceberg 和 Hudi 等热点项目。云原生大规模重构开源技术栈。诞生于云原生时代的开源项目如雨后春笋般破土成长。「数据集成」、「数据存储」、「数据开发与管理」等领域均有重大项目更迭，新项目热力值占比已经超过了 80%。开源大数据热力榜单 TOP30本报告从 102 个入围项目中，评选出了 TOP30 热力榜单。Kibana 以 989.40 的热力值高居榜首。ClickHouse（数据查询与分析）、Airflow（数据调度与编排）、Flink（流处理）、Airbyte（数据集成）分别摘得各自细分领域的 TOP1。Pulsar、Doris、StarRocks、DolphinScheduler、SeaTunnel 等一众中国开源项目也表现出高热力趋势。把解决用户痛点作为核心竞争力，是这些优秀开源项目的共同特征，这一特征保证它们与时俱进，成为热力趋势中的 “常青树”。感谢开源中国、InfoQ 和阿里云开发者社区的战略支持；感谢对本报告内容产出做出重要贡献的 32 位专家和贡献者；感谢 CSDN、DataFun、Segmentfault思否、开源社等社区合作。报告下载地址：https://developer.aliyun.com/ebook/7816/99139?spm=a2c6h.26392459.ebook-detail.4.60f6103cug1fLyFlink Forward Asia 2022 时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-07
FFA 2022 专场解读 - Flink 核心技术
Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！FFA 2022 官网：https://flink-forward.org.cn/由 Apache Flink 核心贡献者与来自阿里巴巴、字节跳动、华为、Shopee、bilibili、美团等公司的一线技术专家解析 Flink 技术动向与应用实践，回归技术本质，打造全方位技术盛宴。Flink 容错 2.0 的最新进展梅源｜阿里云 Flink 存储引擎团队的负责人，Apache Flink 引擎架构师，Apache Flink PMC & CommitterFlink 是业界公认的大数据领域实时计算的标准，尽管如此我们也一直没有放松 Flink 在实时计算部分的进一步深耕与努力。这个 talk 将汇报 Flink 容错在过去一年中取得的一些进展和成果以及未来的展望。首先第一部分就是过去一年中我们在 checkpoint 这个部分做的提升。随着 Generic log-based incremental checkpoints 的进一步完善，Checkpoint 这个部分的提升（快速稳定的 checkpoint）也逐步趋于成熟。在这个 talk 中，我将分享一些 Changelog，unaligned checkpoint 以及 buffer debloating 相结合起来的实验结果。同时我也会讲一讲云原生背景下 rescaling 这个部分以及的一些提升，以及社区在统一 Snapshot 这个概念和操作方面所做的一些努力。Flink Shuffle 3.0: Vision, Roadmap and Progress宋辛童｜阿里云高级技术专家，Apache Flink PMC Member & CommitterFlink 诞生至今，其 Shuffle 架构的演进可以分为两个阶段：初期的 1.0 阶段仅支持最基础的数据传输功能；2.0 阶段围绕性能、稳定性与流批一体架构做出了一系列的改进。如今，随着 Flink 的应用场景与形态越来越丰富，Shuffle 架构也面临着众多新的挑战与机遇，即将迈入 3.0 阶段。本次分享，我将围绕云原生、流批融合、自适应等关键词，展现我们所描绘的 Flink Shuffle 3.0 蓝图，并介绍相关工作的规划与进展情况。具体内容包括：流批自适应 Hybrid Shuffle、云原生多级存储自适应 Shuffle、Shuffle 整体架构升级与功能整合等。Adaptive and flexible execution management for batch jobs朱翥|阿里云高级技术专家，Apache Flink PMC & Committer为了更好的支持批处理作业的执行，提高其易用性、执行效率和稳定性，我们改进了 Flink 的执行管控机制：支持动态执行计划，使得 Flink 可以基于运行时的信息来调整执行计划。基于此，我们为 Flink 引入了自动并行度设置、自动均衡下发数据量的能力。支持更灵活(更细粒度)的执行管控，使得 Flink 可以同时运行多个相同任务的执行实例。基于此，我们为 Flink 引入了预测执行的能力。除此之外，这些改进的机制也为将来进一步优化 Flink 作业执行提供了更多的可能。Flink OLAP Improvement of Resource Management and Runtime曹帝胄｜字节跳动基础架构工程师Flink OLAP 作业 QPS 和资源隔离是 Flink OLAP 计算面临的最大难题，也是字节跳动内部业务使用 Flink 执行 OLAP 计算需要解决的最大痛点。字节跳动 Flink 技术团队在去年作业调度和执行优化的基础上，对 Flink 引擎架构和功能实现进行大量深入优化，使 Flink 引擎在小规模数据量下，复杂作业执行的 QPS 从 10 提高到 100 以上，简单作业执行的 QPS 从 30 提高到 1000 以上。本次分享将从 Flink OLAP 难点和瓶颈分析、作业调度、Runtime 执行、收益以及未来规划等五个方面进行介绍。介绍 Flink 在 OLAP 遇到的难点和瓶颈。作业调度从 Slot 粒度到 TaskManager 粒度的作业资源注册、申请和释放流程改造作业初始化 JobManager 和 TaskManager 模块交互优化，支持跨作业 TaskManager 连接复用作业计算任务部署结构和序列化优化Runtime 执行作业提交和结果获取从 Pull 模型到 Push 模型TaskManager 高并发初始化计算任务 CPU 瓶颈和优化JobManager 和 TaskManager 作业执行内存优化收益调度性能提升核心业务接入收益以及未来规划Serverless 能力建设性能提升PyFlink 最新进展解读及典型应用场景介绍付典｜阿里云高级技术专家，Apache Flink PMC & CommitterPyFlink 是从 Flink 1.9 开始引入的新功能，支持用户使用 Python 语言开发 Flink 作业，极大地方便了 Python 技术栈的开发人员，降低了 Flink 作业的开发门槛，同时也方便用户在 Flink 作业中使用丰富的 Python 三方库，极大地拓宽了 Flink 的应用场景。经过 Flink 1.9 到 Flink 1.16 多个版本的功能迭代，目前 PyFlink 功能已经日趋成熟，基本覆盖了 Flink Java & Scala API 中所提供的绝大多数功能。在本次分享中，我们首先将简要介绍一下 PyFlink 项目当前所处的状态以及在刚刚发布的 Flink 1.16 版本中所支持的新功能；然后我们会通过一些具体的例子，对 PyFlink 的典型应用场景进行深入的解读，让用户对 PyFlink 的一些典型用法以及应用场景有一个直观的了解。Apache Flink 1.16 功能解读黄兴勃｜阿里云高级开发工程师，Apache Flink Committer，Flink 1.16 Release ManagerApache Flink 一直以来都是 Apache 社区最活跃且持续高速发展的项目之一，在过往的每次版本发布中，Apache Flink 都会带来很多新功能、新特性，刚刚发布的 Flink 1.16 也同样如此。在本次分享中，我们将首先介绍一下 Flink 1.16 的整体情况；然后我们将从三个方面来深入讲解 Flink 1.16 在流批一体的大方向上所做的改进，它们分别是：更稳定易用高性能的 Flink 批处理；持续领先的 Flink 流处理；蓬勃发展的 Flink 生态。Apache Flink + Volcano: 大数据场景下高效调度能力实践姜逸坤｜Volcano Reviewer，openEuler Infra Maintainer王雷博｜华为云容器服务架构师、Volcano 社区负责人Flink on Kubernetes 得到了越来越多的关注和使用，由于 Kubernetes 对批量调度支持缺乏，导致大数据场景调度经常出现资源死锁的问题，同时，缺乏队列、优先级、资源预留、多样性算力调度等高级能力。本议题将介绍 Apache Flink 社区 FLIP-250: Support Customized Kubernetes Schedulers Proposal 的最新进展和最佳实践。Flink OLAP 在字节跳动的查询优化和落地实践何润康｜字节跳动基础架构工程师本次分享将主要分为 Flink OLAP 在字节跳动的业务实践以及遇到的问题，OLAP 集群运维和稳定性治理，SQL Query Optimizer 优化，Query Executor 优化，收益和未来规划等五个部分进行介绍。Flink OLAP 在字节跳动的应用总体架构，Flink OLAP 在字节跳动的落地情况介绍业务使用过程中，运维、监控、稳定性、查询性能方面的要求和问题Flink OLAP 集群运维和稳定性Flink OLAP 监控体系完善 VS 流计算Flink OLAP 发版和稳定性治理 VS 流计算Query Optimizer 优化Plan 构建加速，包括 Plan Cache，Catalog Cache 等Optimizer 优化，丰富优化规则，包括下推能力增强，Join Filter 传递，统计信息增强等Query Executor 优化内存优化，包括 Codegen cache，ClassLoader 复用RuntimeFilter 优化收益和未来规划产品化完善，向量化引擎，物化视图，Optimizer 演进Flink Connector 社区新动向与开发指南罗根｜阿里云技术专家任庆盛｜阿里云开发工程师，Apache Flink Committer作为 Flink 生态的重要组成部分，connector 接口与通用组件在不断迭代以支持更多种类的外部系统。本议题将介绍 Flink connector 在社区的新功能与接口，包括 Sink V2 API，通用维表缓存框架，向 Apache Flink 贡献 connector 的流程，以及如何快速开发一个新的 connector 来对接外部系统。基于 Log 的通用增量 Checkpoint俞航翔｜Apache Flink ContributorFLIP-158 引入的 ChangelogStateBackend 可以为用户作业提供更稳定快速的 Checkpoint，进一步提供更快速的 Failover 过程，同时为 Transactional sinks 作业提供更小的端到端延迟。本议题将从 Checkpoint 的性能优化历程出发，介绍 ChangelogStateBackend 的基本机制、应用场景和未来规划，同时分享相关的性能测试结果。Flink Unaligned Checkpoint 在 Shopee 的优化和实践范瑞｜Tech Lead of Shopee Flink Runtime Team，Apache StreamPark Committer & Flink/Hadoop/HBase/RocksDB ContributorShopee 在 Flink 生产实践中，遇到了很多 Checkpoint 相关的问题，并尝试引入 Unaligned Checkpoint 解决部分问题。但调研后发现效果与预期有一定差距，所以在内部版本对其进行了深度改进，并将大部分改进已经反馈给了 Flink 社区。这次演讲会包含以下内容：Checkpoint 存在的问题Unaligned Checkpoint 原理介绍大幅提升 UC 收益大幅降低 UC 风险UC 在 Shopee 的生产实践和未来规划Flink state 优化以及远程 state 的探索张杨|bilibili 资深开发工程师Flink rocksdb state 的优化,调优了压缩流程,在大 state 任务场景,提升吞吐。Flink remote state 探索,基于 bilibili 内部的 kv 存储,实现存算分离,加速任务恢复,同时更好的支持 Flink 的云原生部署。StateBackend performance improvement with TerarkDB李明｜字节跳动基础架构工程师王义｜字节跳动基础架构工程师TerarkDB 是字节跳动内部对 RocksDB 做了较多的优化后衍生出的 LSM 存储引擎，以提高存储引擎的性能，降低资源开销等。本次分享将从背景、业务痛点、Flink & TerarkDB 集成、收益以及未来规划等五个方面进行介绍。介绍 RocksDBStateBackend 在生产实践中遇到的问题写放大严重导致 CPU 消耗和磁盘 IO 高SST 文件清理策略不通用导致空间不断膨胀Checkpoint 和 Compaction 共振导致 CPU 周期尖刺介绍 TerarkDB 的核心优化，并和 RocksDB 进行对比KV 分离机制：降低写放大，减少资源使用Schedule TTL GC：加速文件回收，避免文件无法回收Flink & TerarkDB 集成方案Flink 与 TerarkDB JNI 接口进行适配，支持 Flink Compaction FIlter支持 RocksDB 和 TerarkDB 两种 StateBackend 共存提供新的 Checkpoint 机制消除 CPU 周期尖刺业务收益未来规划基于 Log 的通用增量 Checkpoint 在美团的进展王非凡｜美团数据平台计算引擎工程师，Apache Flink ContributorState Changelog based checkpoint 是 checkpoint 机制的一个重要演进，我们认为能够解决一些业务痛点问题，因此对其进行了跟进与共建。本次分享将按以下几方面展开介绍：相关背景美团应用场景与验证State Changelog Restore 性能优化State Changelog 存储选型探索后续规划以上为 Flink Forward Asia 2022 核心技术专场内容节选，了解更多大会详情可点击下方链接：https://flink-forward.org.cn/移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-11-03
更快更稳更易用: Flink 自适应批处理能力演进
本文整理自阿里巴巴高级技术专家朱翥、阿里巴巴高级技术专家贺小令在 9 月 24 日 Apache Flink Meetup 的演讲。主要内容包括：Adaptive Batch SchedulerSpeculative ExecutionHybrid ShuffleDynamic Partition Pruning点击查看原文视频 & 演讲PPT Flink 是流批一体计算框架，早些年主要用于流计算场景。近些年随着流批一体概念的推广，越来越多的企业开始使用 Flink 处理批业务。虽然 Flink 在框架层面天然支持批处理，但在实际生产使用中依然存在问题。因此在近几个版本中，社区也一直在持续改进 Flink 批处理问题，这些改进体现在 API、执行与运维三个层面。在 API 层面，我们一直在改进 SQL，完善其语法，并使其能够兼容 HIVE SQL；我们也在完善 DataStream 接口来更好的支持批处理作业开发。在运维层面，我们希望 Flink batch 能够更易于在生产中使用，所以我们完善了 history server ，以更好地展示作业在运行中以及结束后的状态，同时也引入了兼容 Hive 生态的 SQLGateway。在执行层面，我们对于算子、执行计划、调度、网络层都进行了性能与稳定性的改进。其中一个主要思路是根据运行时信息，比如数据量、数据模式、执行时间、可用资源等，自适应地优化作业执行，包括根据数据量自动为作业节点设置合适的并发度，通过预测执行来发现与缓解慢节点对作业的影响，引入自适应数据传输方式来提高资源利用率与处理性能，对多分区表进行动态分区裁剪来提高处理效率。这些改进，有的使得 Flink 批处理更易于使用，有的对批处理作业的稳定性提供了保障，有的提升了作业执行性能，或是兼而有之。一、Adaptive Batch Scheduler此前，作业上线前都需要进行并发度调优。对于批处理作业的用户而言，他们遇到的情况是这样的：批处理作业往往非常多，对作业进行并发度调优会是非常大的工作量，费时费力。每日数据量可能都在变化，特别是大促期间数据会有数倍乃至数十倍的增长，因此很难预估数据，导致调优困难。同时，如果要在活动前后更改并发度配置，也会更加耗费人力。Flink 由多个计算节点串联而成的执行拓扑组成。中间节点由于算子复杂性以及数据本身的特质，难以预判数据量，很难进行节点细粒度的并发度配置。而一个全局统一的并发，则可能导致资源浪费，乃至额外的调度部署、网络传输的开销。此外，SQL 作业，除了 source 和 sink 外，只能配置全局统一的并行度，没法进行细粒度并行度设置，因此也会面临资源浪费与额外开销的问题。为了解决问题，Flink 引入了自适应批处理调度器，用户可以配置希望每个并发实例处理的数据量， Flink 会根据运行过程中实际各个节点的数据量自动决定各个逻辑节点的实际并发度，从而保证每个执行并发处理的数据量大致符合用户预期。以上配置方式的特点是配置与数据作业的数据量无关，因此比较通用，一套配置可以适用于很多作业，不需要单独为每个作业进行调优。其次，自动设置的并行度能够适配每天不同的数据量。同时，因为可以在运行时采集到每个节点实际需要处理的数据量，所以能够进行节点粒度的并行度设置，实现更优的效果。其流程如上图所示：当上游逻辑节点 A 的所有执行节点执行完并产出数据完毕后，可以采集产出数据总量，即节点B要消费的数据量。然后将信息交给并行度计算策略组件计算合适的并行度，动态生成执行节点拓扑进行调度与部署。在传统 Flink 执行中，执行拓扑是静态的，作业提交过程中即已知所有节点的并行度，因此上游在执行时即可为下游每一个消费它的执行节点划分单独的数据子分区。下游启动时只需读取对应数据子分区即可获取数据。但是在动态并发度的情况下，上游执行时下游并发度还未确定，因此需要解决的主要问题是使上游节点的执行与下游节点的并发度解耦。为了支持动态执行拓扑，我们进行了以下改进：上游节点产出的数据分区数不由下游并发度决定，而是根据下游最大分并发度来决定。如上图右侧所示，下游可能有四个并发，可以将 A 产出的数据分为四份，则下游实际决定的并发可能会有一个、两个、三个、四个，然后再为每个节点分配消费的分区范围。比如下游并发为 2 时，各自消费两个数据分区；下游并发为 3 时，可能有的消费一个数据分区，有的消费两个。最终使得上游节点执行不再受到下游并发度的制约，能够进行灵活的数据分配，动态执行拓扑的理念也得以实现。自动并发度能够实现两方面的效果：其一，用户不再需要为每个作业单独配置并行度， Flink batch 的使用更简单；其二，细粒度并发度设置可以提高对资源的利用率，避免无意义的大并发度。我们通过多 client TPC-DS 尽可能打满集群进行测试，开启了自适应并发度设置后，总执行时间缩短 7.9% 。自适应批处理调度也为后续优化提供了很好的基础。基于灵活的数据分区与分配方式，能够采集各个数据分区的实际数据量，从而在比如有数据倾斜导致各个分区大小不一的情况下，可以将小分区合并，交给同一个下游处理，使下游节点处理的数据比较均衡。其次，由于引入了动态执行拓扑的能力，可以根据执行时的信息来动态制定更优的执行计划。比如可以根据 join 节点两端各自的数据量大小来决定应该采用何种 join 方式。二、Speculative Execution生产中的热点机器无法避免。比如用户生产中作业会跑在混部集群或批作业的密集回刷等都可能导致某些机器负载特别高，使得运行在该节点上的任务远远慢于其他节点上的任务，从而拖慢整个作业的执行时间。同时，偶发的机器异常也会导致同样的问题。这些缓慢的任务会影响整个作业的执行时间，使得作业的产出基线无法得到保障。成为了部分用户使用 Flink 来进行批处理的阻碍。因此，我们在 Flink 1.16 中引入了预测执行机制。开启预测执行之后，如果 Flink 发现批处理作业中有任务明显慢于其他任务，则会为其拉起新的执行实例。这些新执行实例会与原来的慢任务实例消费同样的数据并且产出同样的结果，而原先慢任务的执行实例也会被保留下来。最先完成的实例会被调度器认可为唯一完成的实例，其数据也会被下游发现与消费。而其他实例会被主动取消，数据会被清除掉。为了实现预测执行，我们为 Flink 引入了以下组件：Slow Task Detector 主要用于定期检测与汇报慢任务。在目前的实现中，当逻辑节点的某个执行节点特别慢，超过其大部分节点执行时长中位数的某个阈值后，则会被认为是慢节点。预测执行调度器会接收到慢节点，并将慢任务所在机器节点识别为热点机器。通过黑名单机制（Blocklist Handler），将热点机器加黑，使得后续调度的新任务不会落到加黑的机器上。黑名单机制目前支持 Yarn、 K8s 与 standalone 等Flink 目前最常的用部署方式。如果慢节点运行中的执行实例数量没有达到配置上限，则会为其拉起预测执行实例直至数量上限，并部署到没有被加黑的机器上。任何执行实例结束后，调度器会识别是否有其他相关的执行实例也在运行中，如果有，则将其主动取消。结束的实例产出的数据会被展现给下游，并触发下游节点调度。我们框架层面支持了 Source 节点的预测执行，保证同一个 Source 并发的不同执行实例总是可以读取到相同的数据。基本思路是引入缓存来记录各个 Source 并发已经获取到的数据分片以及每个执行实例已经处理的分片。当一个执行实例处理完该 Source 并发当前被分配的所有分片之后，可以请求新分片，新分片也会被加入缓存中。因为在框架层面进行了统一的支持，目前大部分已经存在的 Source 不需要进行额外修改即可支持预测执行。只有在使用了新版 Source 并且其使用了自定义 SourceEvent 的情况下，需要 SourceEnumerator 实现额外接口，否则在开启预测执行时会抛出异常。该接口主要用于保证用户自定义的事件可以被交给正确的执行实例。因为开启了预测执行后，一个并发可能会有多个执行实例同时运行。我们在 Rest 与 WebUI 层面也对预测执行进行了支持。预测执行发生时，可以在作业节点详细界面看到预测执行并发的所有执行实例。同时也能在资源总览卡片上看到被加黑的 TaskManager 数量，以及没有被占用但是被加黑所以也无法被使用的 slot 数量，用户可以借此评判当前资源的使用情况。此外，在 TaskManager 界面能够查看当前被加黑的TaskManager。当前版本中，Sink 暂不支持预测执行，后续我们会优先完成对 Sink 节点预测执行的支持。其中需要解决的问题为保证每个 Sink 只会 commit 一份数据，并且其他被取消的 Sink 产生的数据可以被清理掉。此外，我们也在计划进一步改进慢任务检测策略。当前，一旦发生数据倾斜，个别执行并发的数据量可能会大于其他执行并发，因此执行时长也会大于其他节点，但此节点可能并不是慢任务。因此需要能够正确识别处理该情况，从而避免拉起无效预测执行实例浪费资源。目前的初步思路为：根据各个执行实例实际处理的数据量对任务执行时长进行归一化，这也依赖于前文提到的 Adaptive Batch Scheduler 对各个节点产出的的数据量的采集。三、Hybrid ShuffleFlink 主要有两种数据交换方式:流式 Pipeline Shuffle：其特点为上下游会同时启动，空对空传输数据，不需要落盘，因此在性能上具有一定优势。但是它对资源需求量比较大，往往需要作业能够同时获取到数倍于单节点并行度的资源方能运行，而这对于生产批处理作业而言难以满足。同时，因其有批量资源的需求，没有同时获取到则作业无法运行，多个作业同时抢夺资源时，可能会发生资源死锁。批式 Blocking Shuffle：数据会直接落盘，下游直接从上游的落盘数据中读取。交换方式使得作业对于资源的自适应能力比较强，理论上不需要上下游同时运行，只要有一个 slot 则整个作业都可以执行完成。但是性能相对较差，需要等到上游 stage 运行完之后才能运行下游 stage，同时数据全部落盘会产生 IO 开销。因此，我们希望有一种 Shuffle 模式能够将两者优势结合，在资源充足时，可以发挥流式 shuffle 的性能优势；而在资源受限的情况下，可以让作业具备批式 shuffle 的资源自适应能力，即使只有一个 slot 也能运行 。同时，适配资源的能力自适应切换，用户无需感知，无需进行单独调优。 为此，我们引入了 Hybrid Shuffle。在该模式下，上游产出结果的 Result Partition 接收到 shuffle 数据时，会将其缓存在内存中。如果上游已经启动并且与下游建立了连接，内存中的数据即可通过网络层空对空直接传输给下游，无需进行落盘；而如果下游还未启动并且上游产出的数据已经将内存填满，数据也可以 Spill 到磁盘上，使上游可以继续产出数据，不会造成反压影响上游进而导致上游无法继续处理。Hybrid Shuffle 模式不再要求上下游必须同时运行，同时，如果下游连接时上游数据已经落盘，下游仍然可以在上游往 partition 中写数据的同时读取已经落盘的数据。如果下游处理性能够高，比上游产出速度更快，落盘数据读完之后可以继续从上游内存区读取数据，又回退到空对空的数据传输方式，达到一种较优的性能。通过这样的方式，下游无需等待上游数据产出后再进行调度，上游产出数据的同时即可将下游拉起，只要有充足的资源即可与上游同时运行并读取其产出的数据。在资源有空闲的情况下，可以提高整个集群的资源利用率。需要注意，下游仍然需要在所有上游都已部署之后才能部署，一旦下游先于上游部署完成，可能还是会发生调度死锁。Hybrid Shuffle 引入了两种落盘策略：全落盘：降低异常情况下的任务重启开销。出现异常后，只需重启出现问题的节点与其下游节点即可，无需重跑上游节点，适合集群不稳定或非常容易触发 failover 的场景。选择性落盘：降低落盘开销。如果下游可以先拉起，数据则无须落盘走空对空传输；如果下游未拉起，则数据可以 spill 到磁盘上。比较适合对作业性能要求较高或集群资源数比较多而用户又希望批作业能够尽快处理完成的场景。在 Flink1.16 中，Hybrid Shuffle 相比 Blocking Shuffle ，TPC-DS 执行时间减少 7.2%。但 Hybrid Shuffle 对于广播处理场景的性能有待优化，预计在 Flink1.17 中将解决该问题，整体执行时间预计将比 Blocking Shuffle 减少 17% 。其次，当前 Hybrid Shuffle 是基于 Default Scheduler 实现的，因此不兼容自动并发设置以及预测执行。为了更好地支持批处理，还需要进行整合。四、Dynamic Partition Pruning优化器很重要的工作就是避免无效计算和冗余计算。Partition 表在生成中被广泛使用，这里我们将介绍在分区表中如何减少无效分区的读取。我们以几个从 TPC-DS 模型中简化的例子来介绍该优化。如上图所示，有一张 sales 表，partition 字段名为 slod_date ，该表共有 2000 个分区。上图中 SQL 语句指从 sales 表里面选择 slod_date=2 的数据。没有分区裁剪的情况下，需要读取所有 partition 数据，再做 filter ；有静态分区裁剪的情况下，在优化阶段即可通过 filter pushdown 等各种优化将确定的分区告知 Scan 节点。Scan 在执行过程中，只需读取特定分区，大大减少了读 IO，加快了作业执行。上图有两张表，分别是事实表 sales 表和维度表 date_dim，两张表做 join。有一个 filter 条件作用在维度表上，因此无法执行静态分区裁剪的优化。维度表 date_dim 会读取所有数据并做 filter，事实表 sales 表会读取所有 partition 再做 join 。这里只有 year = 2000 并且 sold_date = date_sk 相关数据可以被输出，可以推导出知很多 partition 数据都是无效的，但这些分区没法在静态优化阶段分析出来，需要在运行阶段根据维度表的数据动态分析出来，因此叫动态分区裁剪。动态分区裁剪的思路如下：第一步，执行 join 维度表测算子，比如 Scan(date_dim)、Filter。第二步，将第一步的 Filter 结果发给分区表算子 Scan。第三步：将步骤二的数据过滤掉无效分区，只读取有效数据。第四步：根据步骤一和三的结果完成 Join。动态分区裁剪与静态分区裁剪的区别在于，动态分区裁剪无法在优化阶段确定哪些 partition 数据有效，必须在作业执行之后方能确定。Flink 上的动态分区裁剪实现步骤如下：首先会在 Physical Plan 上加一个特殊节点 DynamicFilterDataCollector（以下简称 DataCollector），作用为将 Filter 数据进行收集并去重，只保留相关字段并发给分区表 Scan。分区表 Scan 获取到数据之后进行分区裁剪，最后完成 Join 。在 Streaming Graph 上， Source 算子（对应 Scan 节点）没有 input ，但我们希望 Source 算子能够接收 DataCollector算子传来的数据，同时维表侧 data_dim Scan 和year=2000 的Filter与右边 sales Scan 调度上没有依赖关系，可能会导致右边算子先被执行，左边算子后被执行，从而无法完成动态分区裁剪优化。因此，我们引入了 OrderEnforce 节点，其目的是为了告知调度器它们之间的数据依赖关系，从而确保左边算子优先被调度，以确保动态分区裁剪优化能够被正确执行。后续，我们也计划从框架层面来解决上述调度依赖的问题使Streaming Graph 变得更优雅。上图为具体执行图。左侧 data_dim Scan与 Filter 先执行，将数据发给 DataCollector 和 Join。为了解决 Source 算子没有 input 边的问题，我们使用了 Flink Coordinator机制，DataCollector 收集完数据之后会发给 Coordinator 并完成无效分区的裁剪，分区表 Scan 再从 Coordinator 获取有效的分区信息。Sales Scan 节点执行完后，再进行最后的 Join。 DataCollector 与 OrderEnforce 中间也有一条数据边，数据边内不会有真实的数据传输，仅用于通知调度器 DataCollector 比 OrderEnforce 先被调取起来。 上图为基于 TPC-DS 10T 数据集优化前后的性能对比，其中蓝色是非分区表，红色是分区表。优化后时间节省约 30%。更多 Flink Batch 相关技术问题，可扫码加入钉钉交流群～Q&AQ：热点机器产生慢任务时，会分配其他机器拉起实例，再重新执行慢任务。再次拉起实例时，是否还会产生热点？A：理论上有可能，因为预测执行本身是通过资源换时间的一种策略。但是生产实践证明这种机制有效，相比额外资源开销以及进一步引发热点， trade off 依然是划算的。Q：推测执行是根据数据量来判断吗？A：当前的策略是根据执行时长来判断。比如大部分任务的执行时间中位数是一分钟，有任务执行超过了 1.5 分钟，则会被认为是慢任务。具体数值可配。Q：慢节点检测是可配的吗？A：该策略目前是硬编码，暂时还不支持配置策略。后续等策略稳定后，可能会开放给用户，用户可通过二次开发或插件的形式更改慢任务检测策略。Q：推测执行机制对 DataStream API 与 Flink SQL 都能提供支持吗？A：是的。Q：拉黑机制上，是否会存在拉黑太多或拉白不及时而导致资源浪费？A：目前预测执行下的加黑比较保守，加黑默认只会持续 1 分钟。但是如果慢任务持续出现，则会不断刷新加黑时间，因此慢任务所在的慢机器节点也会一直在加黑列表中。点击查看原文视频 & 演讲PPTFlink Forward Asia 2022 时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-31
官宣｜Apache Flink 1.16 发布公告
作者 | 阿里巴巴高级技术专家、Apache Flink Committer 贺小令（晓令）Apache Flink 持续保持高速发展，是 Apache 最活跃的社区之一。Flink 1.16 共有 240 多个 Contributor 热情参与，共完成了 19 个 FLIP [1]和 1100 多个 issue，给社区带来非常多振奋人心的功能。Flink 已经是流计算领域的领跑者，流批一体的概念逐渐得到大家的认可，并在越来越多的公司成功落地。之前的流批一体更强调统一的 API 和统一的计算框架。今年，在此基础上，Flink 推出了 Streaming Warehouse[2]，进一步升级了流批一体的概念：真正完成了流批一体的计算和流批一体的存储的融合，从而实现流批一体的实时化分析。在 1.16 版本里，Flink 社区对流、批都完成了众多改进：在批处理方面，完成了易用性、稳定性、性能全方位的改进，1.16 是 Fink 批处理的里程碑式的版本，是走向成熟的重要一步。易用性：引入 SQL Gateway 并完全兼容 HiveServer2，用户可以非常方便的提交 Flink SQL 作业和 Hive SQL 作业，同时也很容易连接到原有的 Hive 生态。功能：Flink SQL 用户支持通过 Join Hint 指定 Join 策略，避免不合理的执行计划；Hive SQL 的兼容性已经达到 94%，用户可以以极低的成本完成 Hive 到 Flink 的迁移。稳定性：通过预测执行减少作业长尾以提高作业整体运行稳定性；支持自适应 HashJoin，通过失败回滚机制避免作业失败。性能：对多分区表进行动态分区裁剪以提高处理效率，TPC-DS 在 10TB 规模数据集下性能提升了 30%；支持混合 Shuffle 模式，提高资源使用率和处理性能。在流处理方面，也完成了很多重大改进：Changelog State Backend 可以为用户提供秒级甚至毫秒级 Checkpoint，从而大幅提升容错体验，同时为事务性 Sink 作业提供更小的端到端延迟体验。维表关联在流处理中广泛被使用，引入了通用的缓存机制加快维表查询速度，引入了可配置的异步模式提升维表查询吞吐，引入可重试查询机制解决维表延迟更新问题。这些功能都非常实用，解决了用户经常抱怨的痛点，支持了更丰富的场景。从 Flink SQL 诞生第一天就存在一些非确定性操作可能导致用户作业出现错误结果或作业运行异常，这给用户带来了极大的困扰。1.16 里我们花了很多大精力解决了大部分问题，未来还会持续改进。随着流批一体的进一步完善和 Flink Table Store 的不断迭代（0.2版本已发布[3]），Flink 社区正一步一步推动 Streaming Warehouse 从概念变为现实并走向成熟。理解 Streaming Warehouse流式数仓（Streaming Warehouse）更准确地说，其实是 “make data warehouse streaming”，就是让整个数仓所有分层的数据全部实时地流动起来，从而实现一个具备端到端实时性的纯流服务（Streaming Service），并且用一套统一 API 和计算框架来处理和分析所有流动中的数据。想了解更多内容请参阅文章[4]。批处理得益于我们在流处理的长期投资，流处理已经成为流计算领域的领导者。在批处理上，我们也投入更多的精力，使其成为一个优秀的批处理引擎。流批处理统一的整体体验也将会更加顺畅。SQL Gateway从各个渠道反馈中了解到，SQL Gateway[5] 一直是用户非常期待的功能，尤其是对批用户。1.16 里，该功能终于完成（设计见FLIP-91[6]）。SQL Gateway 是对 SQL Client 的扩展和增强，支持多租户和插件式 API 协议（Endpoint），解决了 SQL Client 只能服务单用户并且不能对接外部服务或组件的问题。当前 SQL Gateway 已支持 REST API 和 HiveServer2 协议，用户可以通过 cURL，Postman，各种编程语言的 HTTP 客户端链接到 SQL Gateway 提交流作业、批作业，甚至 OLAP 作业。对于 HiveServer2 协议，请参考“Hive 语法兼容”章节。Hive 语法兼容为了降低从 Hive 到 Flink 的迁移成本，这个版本里我们引入了 HiveServer2 协议并继续改进 Hive 语法的兼容性。HiveServer2 协议[7]允许用户使用 Hive JDBC/Beeline 和 SQL Gateway 进行交互，Hive 生态（DBeaver, Apache Superset, Apache DolphinScheduler, and Apache Zeppelin）也因此很容易迁移到 Flink。当用户使用 HiveServer2 协议连接 SQL Gateway，SQL Gateway 会自动注册 Hive Catalog，自动切换到 Hive 方言，自动使用批处理模式提交作业，用户可以得到和直接使用 HiveServer2 一样的体验。Hive 语法[8]已经是大数据处理的事实标准，Flink 完善了对 Hive 语法的兼容，增加了对 Hive 若干生产中常用语法的支持。通过对 Hive 语法的兼容，可以帮助用户将已有的 Hive SQL 任务迁移到 Flink，并且方便熟悉 Hive 语法的用户使用 Hive 语法编写 SQL 以查询注册进 Flink 中的表。到目前为止，基于 Hive qtest 测试集（包含12K 个 SQL 案例），Hive 2.3 版本的查询兼容性已达到 94.1%，如果排除 ACID 的查询语句，则已达到 97.3%。Join HintHint 一直是业界用来干预执行计划以改善优化器缺点的通用解决方案。Join 作为批作业中最广泛使用的算子，Flink 支持多种 Join 策略。统计信息缺失或优化器的代价模型不完善都会导致选出错误 Join 策略，从而导致作业运行慢甚至有运行失败的风险。用户通过指定 Join Hint[9]，让优化器尽可能选择用户指定的 Join 策略，从而避免优化器的各种不足，以确保批作业的生产可用性。自适应 Hash Join对于批作业而言，数据倾斜是非常常见的，而此时使用 HashJoin 可能运行失败，这是非常糟糕的体验。为了解决该问题，我们引入了自适应的 HashJoin：Join 算子运行时一旦 HashJoin 运行失败，可以自动回退到 SortMergeJoin，并且是 Task 粒度。通过该机制可确保 HashJoin 算子始终成功，从而提高了作业的稳定性。批处理的预测执行为了解决问题机器导致批作业处理慢的问题，Flink 1.16 引入了预测执行。问题机器是指存在硬件问题、突发 I/O 繁忙或 CPU 负载高等问题的机器，这些问题可能会使得运行在该机器上的任务比其他机器上的任务要慢得多，从而影响批处理作业的整体执行时间。当启用预测执行时，Flink 将持续检测慢任务。一旦检测到慢任务，该任务所在的机器将被识别为问题机器，并通过黑名单机制（FLIP-224[10]）被加黑。调度器将为慢任务创建新的执行实例并将它们部署到未被加黑的节点，同时现有执行实例也将继续运行。新的执行实例和老的执行实例将处理相同的输入数据并产出相同的结果数据。一旦任何执行实例率先完成，它将被视为该任务的唯一完成执行实例，并且该任务的其余执行实例都将被取消。大多数现有 Source 都可以使用预测执行 (FLIP-245[11])。只有当一个 Source 使用了 SourceEvent 时，它必须额外实现 SupportsHandleExecutionAttemptSourceEvent 接口以支持预测执行。目前 Sink 尚不支持预测执行，因此预测执行不会在 Sink 上发生。我们也改进了 Web UI 和 REST API (FLIP-249[12]) ，以显示任务的多个执行实例和被加黑的 TaskManager。混合 Shuffle 模式我们为批处理引入了一种新的混合 Shuffle[13] 模式。它结合了 Blocking Shuffle 和 Pipeline Shuffle（主要用于流式处理）的优点：与 Blocking Shuffle 一样，它不要求上下游任务同时运行，这允许使用很少的资源执行作业。与 Pipeline Shuffle 一样，它不要求上游任务完成后才执行下游任务，这在给定足够资源情况下减少了作业的整体执行时间。用户可以选择不同的落盘策略，以满足减少数据落盘或是降低任务重启代价的不同需求。注意：该功能为实验性的，并且默认关闭。Blocking shuffle 进一步改进在这个版本中，我们进一步改进了 Blocking Shuffle 的可用性和性能，包括自适应网络缓冲区分配、顺序 IO 优化和结果分区重用，允许多个消费者节点重用同一个物理结果分区，以减少磁盘 IO 和存储空间。在 TPC-DS 10TB规模的测试中，这些优化可以实现 7% 的整体性能提升。此外，还引入了两种压缩率更高的压缩算法（LZO 和 ZSTD）。与默认的 LZ4 压缩算法相比，可以进一步减少存储空间，但要付出一些 CPU 成本。动态分区裁剪对于批作业，生产环境中分区表比非分区表使用更为广泛。当前 Flink 已经支持静态分区裁剪，即在优化阶段，优化器将 Filter 中的 Partition 相关的过滤条件下推到 Source Connector 中从而减少不必要的分区读取。星形模型[14]是数据集市模式中最简单且使用最广泛的模式，我们发现很多用户的作业没法使用静态分区裁剪，因为分区裁剪信息在执行时才能确定，这就需要动态分区裁剪技术[15]，即运行时根据其他相关表的数据确定分区裁剪信息从而减少对分区表中无效分区的读取。通过 TPC-DS 10TB 规模数据集的验证，该功能可提升 30% 的性能。流处理在 1.1 6 中，我们在 Checkpoint、SQL、Connector 和其他领域都进行了改进，从而确保 Flink 在流计算领域继续领先。Generalized Incremental CheckpointChangelog State Backend 旨在令 Checkpoint 的间隔更短、更加可预测。这个版本在自身易用性上和与其他 State Backend 兼容性上做了诸多改进，使其达到生产可用。支持状态迁移支持 Failover 时从本地恢复引入文件缓存优化恢复过程的性能支持从 Checkpoint 进行切换优化监控体验：扩充了 Changelog 的监控指标在 Flink WebUI 上显示 Changelog 相关的配置表 1: Value State 上 Changelog Enabled / Changelog Disabled 对比 (详细配置请参考文档[16]) RocksDB Rescaling 改进及性能测试对于使用 Flink 构建的云服务应用来说，Rescaling 是一种非常频繁的操作。这个版本使用了 RocksDB 的区间删除[17]来优化增量 RocksDB State Backend 的 Rescaling 性能。区间删除被用来避免在 Rescaling 过程中大量的扫描和单点删除操作，对有大量的状态需要删除的扩并发来说，单个并发上的恢复速度可以提高 2~10 倍[18]。 改善 State Backend 的监测体验和可用性这个版本还改善了状态后台的监控体验和可用性。之前，RocksDB 的日志位于它自己的 DB 目录中，这使得调试 RocksDB 没那么容易。这个版本让 RocksDB 的日志默认留在 Flink 的日志目录中。新增了 RocksDB 相关的统计指标，以帮助调试 DB 级别的性能，例如，在 DB 内的总块缓存命中/失败计数。支持透支缓冲区透支缓冲区[19]（Overdraft Buffers）旨在缓解反压情况下 Subtask 被阻塞的概率，可以通过设置 taskmanager.network.memory.max-overdraft-buffers-per-gate [20]开启。从 1.16 开始，一个 Flink 的 Subtask 可以申请 5 个（默认）额外的透支缓冲区。透支缓冲区会轻微地增加作业的内存使用量，但可以极大地减少 Checkpoint 的间隔，特别是在开启 Unaligned Checkpoint 情况下。只有当前 Subtask 被下游 Subtasks 反压且当前 Subtask 需要请求超过 1 个网络缓冲区（Network Buffer）才能完成当前的操作时，透支缓冲区才会被使用。更多细节可以参考文档[21]。对齐 Checkpoint 超时这个版本更新了从 Aligned Checkpoint（AC） 切换到 Unaligned Checkpoint （UC） 的时间点。在开启 UC 的情况下，如果配置了 execution.checkpointing.aligned-checkpoint-timeout[22], 在启动时每个 Checkpoint 仍然是 AC，但当全局 Checkpoint 持续时间超过 aligned-checkpoint-timeout 时， 如果 AC 还没完成，那么 Checkpoint 将会转换为 UC。以前，对一个 Substask 来说，AC 到 UC 的切换需要等所有上游的 Barriers 到达后才能开始，在反压严重的情况下，在 checkpointing-timeout[23] 过期之前，下游的 Substask 可能无法完全地收到所有 Barriers，从而导致 Checkpoint 失败。在这个版本中，如果上游 Subtask 中的 Barrier 无法在 execution.checkpointing.aligned-checkpoint-timeout[24] 内发送到下游，Flink 会让上游的 Subtask 先切换成 UC，以把 Barrier 发送到下游，从而减少反压情况下 Checkpoint 超时的概率。更多细节可以参考文档[25]。流计算的非确定性Flink SQL 用户经常抱怨理解流处理的成本太高，其中一个痛点是流处理中的非确定性（而且通常不直观），它可能会导致错误的结果或异常。而这些痛点在 Flink SQL 的早期就已经存在了。对于复杂的流作业，现在可以在运行前检测并解决潜在的正确性问题。如果问题不能完全解决，一个详细的消息可以提示用户如何调整 SQL，以避免引入非确定性问题。更多细节可以参考文档[26]。维表增强维表关联在流处理中被广泛使用，在 1.16 中我们为此加入了多项优化和增强：支持了通用的缓存机制和相关指标[27]，可以加速维表查询。通过作业配置[28]或查询提示[29]支持可配置的异步模式（ALLOW_UNORDERED），在不影响正确性的前提下大大提升查询吞吐。可重试的查询机制[30]让用户解决维表数据更新延迟问题有了更多的手段。异步 I/O 支持重试为异步 I/O [31]引入了内置的重试机制，它对用户现有代码是透明的，可以灵活地满足用户的重试和异常处理需求。PyFlink在 Flink 1.15 中，我们引入了一种新的执行模式：“线程”模式。在该模式下，用户自定义的 Python 函数将通过 JNI 在 JVM 中执行，而不是在独立的 Python 进程中执行。但是，在 Flink 1.15 中，仅在 Table API 和 SQL 上的 Python 标量函数的执行上支持了该功能。在该版本中，我们对该功能提供了更全面的支持，在 Python DataStream API 中以及在 Table API 和 SQL 的 Python 表值函数中，也支持了该功能。除此之外，我们还在持续补全 Python API 所缺失的最后几处功能。在这个版本中，我们对 Python DataStream API 提供了更全面的支持：支持了旁路输出、Broadcast State 等功能，并完善了对于窗口功能的支持。我们还在 Python DataStream API 中，添加了对于更多的 Connector 以及 Format 的支持，例如添加了对于 Elasticsearch、Kinesis、Pulsar、Hybrid Source 等 Connector 的支持以及对于 Orc、Parquet 等 Format 的支持。有了这些功能之后，Python API 已经基本对齐了 Java 和 Scala API 中绝大部分的重要功能，用户已经可以使用 Python 语言完成大多数类型 Flink 作业的开发。其他新语法1.16 扩展了多个 DDL 语法以帮助用户更好的使用 SQL：USING JAR [32]支持动态加载 UDF jar包，方便平台开发者轻松实现 UDF 的管理和相关作业的提交。CREATE TABLE AS SELECT [33](CTAS) 方便用户基于已有的表和查询创建新的表。ANALYZE TABLE [34]支持用户手工为原表生成统计信息，以便优化器可以生成更优的执行计划。DataStream 中的缓存支持通过 DataStream#cache 缓存 Transformation 的执行结果。缓存的中间结果在首次计算中间结果时才生成，以便以后的作业可以重用该结果。如果缓存丢失，原始的 Transformation 将会被重新计算以得到结果。目前该功能只在批处理模式下支持。这个功能对于 Python 中的 ML 和交互式编程非常有用。History Server 及已完成作业的信息增强在这个版本中，我们加强了查看已完成作业的信息的体验。JobManager / HistoryServer WebUI 提供了详细的执行时间指标，包括任务在每个执行状态下的耗时，以及在运行过程中繁忙/空闲/反压总时间。JobManager / HistoryServer WebUI 提供了按 Task 或者 TaskManager 维度分组的主要子任务指标的聚合。JobManager / HistoryServer WebUI 提供了更多的环境信息，包括环境变量，JVM 选项和 Classpath。HistoryServer 现在支持从外部日志归档服务中浏览日志，更多细节可以参考文档[35]。Protobuf 格式Flink 现在支持 Protocol Buffers[36] (Protobuf) 格式，这允许您直接在 Table API 或 SQL 应用程序中使用这种格式。为异步 Sink 引入可配置的 RateLimitingStrategy1.15 中实现了异步 Sink，允许用户轻松实现自定义异步 Sink。这个版本里，我们对此进行扩展以支持可配置的 RateLimitingStrategy。这意味着 Sink 的实现者现在可以自定义其异步 Sink 在请求失败时的行为方式，具体行为取决于特定的 Sink。如果没有指定 RateLimitingStrategy，它将默认使用 AIMDScalingStrategy。升级说明我们尽力的让每次版本升级都平稳，但仍有一些改动需要用户升级到1.16时对现有应用程序做出一些调整。请参考 Release Notes 获取更多的升级时需要的改动与可能的问题列表细节。更多 Flink 相关技术问题，可扫码加入社区钉钉交流群～贡献者列表Apache Flink 社区感谢对此版本做出贡献的每一位贡献者：1996fanrui, Ada Wang, Ada Wong, Ahmed Hamdy, Aitozi, Alexander Fedulov, Alexander Preuß, Alexander Trushev, Andriy Redko, Anton Kalashnikov, Arvid Heise, Ben Augarten, Benchao Li, BiGsuw, Biao Geng, Bobby Richard, Brayno, CPS794, Cheng Pan, Chengkai Yang, Chesnay Schepler, Danny Cranmer, David N Perkins, Dawid Wysakowicz, Dian Fu, DingGeGe, EchoLee5, Etienne Chauchot, Fabian Paul, Ferenc Csaky, Francesco Guardiani, Gabor Somogyi, Gen Luo, Gyula Fora, Haizhou Zhao, Hangxiang Yu, Hao Wang, Hong Liang Teoh, Hong Teoh, Hongbo Miao, HuangXingBo, Ingo Bürk, Jacky Lau, Jane Chan, Jark Wu, Jay Li, Jia Liu, Jie Wang, Jin, Jing Ge, Jing Zhang, Jingsong Lee, Jinhu Wu, Joe Moser, Joey Pereira, Jun He, JunRuiLee, Juntao Hu, JustDoDT, Kai Chen, Krzysztof Chmielewski, Krzysztof Dziolak, Kyle Dong, LeoZhang, Levani Kokhreidze, Lihe Ma, Lijie Wang, Liu Jiangang, Luning Wang, Marios Trivyzas, Martijn Visser, MartijnVisser, Mason Chen, Matthias Pohl, Metehan Yıldırım, Michael, Mingde Peng, Mingliang Liu, Mulavar, Márton Balassi, Nie yingping, Niklas Semmler, Paul Lam, Paul Lin, Paul Zhang, PengYuan, Piotr Nowojski, Qingsheng Ren, Qishang Zhong, Ran Tao, Robert Metzger, Roc Marshal, Roman Boyko, Roman Khachatryan, Ron, Ron Cohen, Ruanshubin, Rudi Kershaw, Rufus Refactor, Ryan Skraba, Sebastian Mattheis, Sergey, Sergey Nuyanzin, Shengkai, Shubham Bansal, SmirAlex, Smirnov Alexander, SteNicholas, Steven van Rossum, Suhan Mao, Tan Yuxin, Tartarus0zm, TennyZhuang, Terry Wang, Thesharing, Thomas Weise, Timo Walther, Tom, Tony Wei, Weijie Guo, Wencong Liu, WencongLiu, Xintong Song, Xuyang, Yangze Guo, Yi Tang, Yu Chen, Yuan Huang, Yubin Li, Yufan Sheng, Yufei Zhang, Yun Gao, Yun Tang, Yuxin Tan, Zakelly, Zhanghao Chen, Zhu Zhu, Zichen Liu, Zili Sun, acquachen, bgeng777, billyrrr, bzhao, caoyu, chenlei677, chenzihao, chenzihao5, coderap, cphe, davidliu, dependabot[bot], dkkb, dusukang, empcl, eyys, fanrui, fengjiankun, fengli, fredia, gabor.g.somogyi, godfreyhe, gongzhongqiang, harker2015, hongli, huangxingbo, huweihua, jayce, jaydonzhou, jiabao.sun, kevin.cyj, kurt, lidefu, lijiewang.wlj, liliwei, lincoln lee, lincoln.lil, littleeleventhwolf, liufangqi, liujia10, liujiangang, liujingmao, liuyongvs, liuzhuang2017, longwang, lovewin99, luoyuxia, mans2singh, maosuhan, mayue.fight, mayuehappy, nieyingping, pengmide, pengmingde, polaris6, pvary, qinjunjerry, realdengziqi, root, shammon, shihong90, shuiqiangchen, slinkydeveloper, snailHumming, snuyanzin, suxinglee, sxnan, tison, trushev, tsreaper, unknown, wangfeifan, wangyang0918, wangzhiwu, wenbingshen, xiangqiao123, xuyang, yangjf2019, yangjunhan, yangsanity, yangxin, ylchou, yuchengxin, yunfengzhou-hub, yuxia Luo, yuzelin, zhangchaoming, zhangjingcun, zhangmang, zhangzhengqi3, zhaoweinan, zhengyunhong.zyh, zhenyu xing, zhouli, zhuanshenbsj1, zhuzhu.zz, zoucao, zp, 周磊, 饶紫轩,, 鲍健昕 愚鲤, 帝国阿三参考链接[1] https://cwiki.apache.org/confluence/display/FLINK/1.16+Release[2] https://developer.aliyun.com/article/851771[3] https://flink.apache.org/news/2022/08/29/release-table-store-0.2.0.html[4] https://developer.aliyun.com/article/851771[5] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/sql-gateway/overview/[6] https://cwiki.apache.org/confluence/display/FLINK/FLIP-91%3A+Support+SQL+Gateway[7] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/hive-compatibility/hiveserver2/[8] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/hive-compatibility/hive-dialect/overview/[9] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/sql/queries/hints/[10] https://cwiki.apache.org/confluence/display/FLINK/FLIP-224%3A+Blocklist+Mechanism[11] https://cwiki.apache.org/confluence/display/FLINK/FLIP-245%3A+Source+Supports+Speculative+Execution+For+Batch+Job[12] https://cwiki.apache.org/confluence/display/FLINK/FLIP-249%3A+Flink+Web+UI+Enhancement+for+Speculative+Execution[13] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/ops/batch/batch_shuffle/[14] https://en.wikipedia.org/wiki/Star_schema[15] https://cwiki.apache.org/confluence/display/FLINK/FLIP-248%3A+Introduce+dynamic+partition+pruning[16] https://flink-learning.org.cn/article/detail/2a107b2622171b9972293f3b062c4d52[17] https://rocksdb.org/blog/2018/11/21/delete-range.html[18] https://github.com/apache/flink/pull/19033#issuecomment-1072267658[19] https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/deployment/memory/network_mem_tuning/#overdraft-buffers[20] https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/deployment/config/#taskmanager-network-memory-max-overdraft-buffers-per-gate[21] https://nightlies.apache.org/flink/flink-docs-master/zh/docs/deployment/memory/network_mem_tuning/#%e9%80%8f%e6%94%af%e7%bc%93%e5%86%b2%e5%8c%baoverdraft-buffers[22] https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#execution-checkpointing-aligned-checkpoint-timeout[23] https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#execution-checkpointing-timeout[24] https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#execution-checkpointing-aligned-checkpoint-timeout[25] https://nightlies.apache.org/flink/flink-docs-master/zh/docs/ops/state/checkpointing_under_backpressure/#%e5%af%b9%e9%bd%90-checkpoint-%e7%9a%84%e8%b6%85%e6%97%b6[26] https://nightlies.apache.org/flink/flink-docs-master/zh/docs/dev/table/concepts/determinism/[27] https://cwiki.apache.org/confluence/display/FLINK/FLIP-221%3A+Abstraction+for+lookup+source+cache+and+metric[28] https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/config/#table-exec-async-lookup-output-mode[29] https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/hints/#2-configure-the-async-parameters[30] https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/hints/#3-enable-delayed-retry-strategy-for-lookup[31] https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/dev/datastream/operators/asyncio/#retry-support[32] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/sql/create/#create-function[33] https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/dev/table/sql/create/#as-select_statement[34] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/dev/table/sql/analyze/[35] https://nightlies.apache.org/flink/flink-docs-release-1.16/zh/docs/deployment/advanced/historyserver/[36] https://developers.google.com/protocol-buffers更多内容Flink Forward Asia 2022 时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-25
实时化浪潮下，Apache Flink 还将在大数据领域掀起怎样的变革？
Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！今年是 Flink Forward Asia（下文简称 FFA）落地中国的第五个年头，也是 Flink 成为 Apache 软件基金会顶级项目的第八年。过去这几年，Flink 一方面持续优化其流计算核心能力，不断提高整个行业的流计算处理标准，另一方面沿着流批一体的思路逐步推进架构改造和应用场景落地。伴随着实时化浪潮的发展和深化，Flink 已逐步演进为流处理的领军角色和事实标准。作为开源大数据领域的顶级盛会之一，今年的 FFA 将继续集结 Flink 最新技术动态和最佳行业实践 ，并积极拥抱生态伙伴，共建繁荣开源大数据生态。延续 FFA 惯例，会议所有议题均为开放征集而来，并由专业的议题评选委员会评分筛选，确保内容代表行业领先水平，为开发者们输出更加优质的干货。今年，我们将在 FFA 上看到阿里巴巴、字节跳动、快手、美团、华为、Shopee、运满满、米哈游、蔚来汽车、集度汽车、菜鸟、网易等全球 40+ 各行业一线厂商，围绕 Flink 核心技术、行业实践、平台建设、实时风控、实时湖仓、数据集成等多个时下热门方向，分享 80+ 干货议题，带来一场专属于开发者的技术盛宴。Flink Forward Asia 2022时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:一、重量级内容评审团FFA 2022 邀请了 11 位行业领袖及开拓者组成议题评选委员会，并继续由阿里巴巴开源技术委员会负责人贾扬清担任主席，共同为大会内容护航，他们分别是：二、Apache Flink 新方向、新应用及新成果在去年的 FFA 2021 主题演讲中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰提出了 Flink 下一步的发展方向——流式数仓（Streaming Warehouse，简称 Streamhouse），预示着 Flink 要从 Stream Processing 走向 Streaming Warehouse 去覆盖更大的场景，帮助开发者解决更多问题。Flink 社区也把拓展适合流批一体的数据存储作为重点技术方向来推进，并在前不久发布了 Flink Table Store 0.2.0。过去这一年，Flink Table Store 这一全新数据湖存储项目取得了哪些新进展？又有哪些应用实践新成果？Flink 接下来还有什么新计划？将在这次 FFA 2022 主会场上一一揭晓。本次 FFA 2022 将继续由阿里巴巴开源技术委员会负责人贾扬清进行开场演讲，Apache Flink 中文社区创始人王峰、米哈游大数据实时计算团队负责人张剑、美的集团实时数据负责人董奇、Disney 广告智能执行总监郝又超、Disney 广告智能实时计算负责人李丁哲将分享基于 Flink 的深度实践以及 Flink 下一步的规划与展望。三、九大专题，全方位解析 Apache Flink 核心技术、生态及应用除主会场的精彩内容外，大会围绕 Apache Flink 核心技术、生态及应用开设九大专题，全面分享大数据技术生态核心内容。核心技术由 Apache Flink 核心贡献者与来自阿里巴巴、字节跳动、华为、Shopee、bilibili、美团等公司的一线技术专家解析 Flink 技术动向与应用实践，回归技术本质，打造全方位技术盛宴。行业案例 + 生产实践快手、美团、字节跳动、小米、运满满、蔚来汽车、中泰证券、中原银行、中信建投、中南电力设计院等多行业实时计算领域专家详细解读 Flink 在不同企业和行业内的应用与落地，围绕业务场景、业务痛点、面临挑战、如何破局等宝贵实践经验倾囊相授。平台建设平台建设专场由来自爱奇艺、知乎、Dinky 社区、货拉拉、美团、联通、小米、StreamPark、阿里巴巴、蚂蚁集团的技术专家分享基于 Apache Flink 的实时计算平台演进与实践。实时湖仓实时湖仓专场邀请快手、bilibili、SmartNews、美团、SelectDB、OceanBase、StarRocks 等企业技术专家分享基于 Flink 的实时湖仓建设实践与思考。数据集成云原生为数据集成领域注入了全新生命力，本专场邀请小红书、小米、科杰科技、易车、京东、顺丰、XTransfer、阿里等技术专家分享基于 Flink 的数据集成系统探索与实践。流批一体流批一体专场由来自快手、京东、数禾、Shopee、蚂蚁集团等企业的技术专家为你呈现流批一体的大规模应用实践案例，详细拆解落地难点和应对方案。另有来自阿里巴巴的技术专家手把手教你如何基于 Hive SQL on Flink 构建流批一体引擎。AI 特征工程 + 实时风控AI 特征工程专场将由来自腾讯、字节跳动、阿里巴巴的技术专家带来基于 Flink 的实时特征工程平台建设思路与落地实践。实时风控专场将由网易互娱、字节跳动、京东、AirWallex、阿里巴巴的技术专家分享实时风控平台建设的实践案例。更多详情Flink Forward Asia 2022 大会最终议程以官网公布信息为准。时间：11月26日-27日PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」移动端建议观看 ApacheFlink 视频号预约观看:点击预约直播~活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-20
特征平台在数禾的建设与应用
本篇文章为数禾科技数据开发专家杨涵冰的演讲内容整理。主要内容包括：特征平台概览特征存储服务流批一体方案模型策略调用方案点击查看更多技术内容一、特征平台概览首先是特征平台的概览，整个特征平台分成四层，分别是数据服务、存储服务、计算引擎、原始存储。数据服务层提供向外的服务，主要包括四种：一是传统的 API 点查；二是圈选查询；三是事件消息；四是同步调用计算。其中同步调用计算服务是即时计算的，相当于现场进行策略运算，而 API 点查服务是预先计算并存储的。为了提供数据服务，提供特征行存和特征列存两种服务方式，分别支撑 API 点查和圈选查询。计算引擎有两个，分别是离线运算引擎和流批一体运算引擎。特征平台的最底层是原始存储，原始存储是为了支持离线运算功能，而事件存储是为了支持流批一体运算。下面以 MySQL 为例介绍简化的特征平台数据流转过程。首先是离线部分，通过 Sqoop 或者其他的抽取工具将 MySQL 数库的数据抽取到 EMR，然后经过 Hive 运算，把最终的运算结果存到 HBase 和 ClickHouse 中，分别对应特征行存和特征列存，以提供 API 点查和圈选查询服务。同时 MySQL 的 Binlog 会实时写入 Kafka，然后 Kafka 的数据会被消费进入 Flink 流批一体运算引擎，同时Kafka的数据也会被消费进入到事件存储 HBase，事件存储 HBase 的数据也会提供给Flink流批一体运算引擎。经过引擎计算以后，数据被写入 HBase 和 ClickHouse 中，此外还会发事件消息。中转到事件存储 HBase 的数据可以提供实时调用服务。二、特征存储服务接下来介绍特征存储服务。我们将特征分为四类，分别是：同步特征：实时写入、离线修正、流批一体。即时计算特征：API 调用时运算、线下批量计算，逻辑一致。实时特征：传统实时链路，实现复杂实时逻辑，一般可使用流批一体代替。离线特征：传统离线链路，实现复杂离线逻辑。为什么一定要有离线的链路，原因有以下几点：一是实时链路是一个纯增量的链路，它的链路会很长，并且在任意的环节都有可能发生问题，一旦出错，数据将会在很长的一段时间都无法被自动修正。二是实时链路对时效性有要求，特别是涉及到多流 join 的时候，一旦有延迟，需要尽快返回一个降级结果。为了控制实时特征的最终错误率，并且将错误限制在一个较小的时间段内，需要进行离线链路修正。特征存储服务会用两种方式来进行修正，一种就是同步特征，其本身自带修正，是流批一体的链路；其他特征一般是通过实时+离线+即时计算的组合方式。下面以 MySQL 为例，介绍下存储服务的整体数据流。离线部分，通过 Sqoop 抽取工具将 MySQL 数库的数据抽取到 EMR，然后经过 Hive 运算，把最终的运算结果存到 HBase 和 ClickHouse 中。同时 Binlog 会实时写入 Kafka，然后 Kafka 的数据会被消费进入 Flink 流批一体运算引擎，经过引擎计算以后，数据被写入 HBase 和 ClickHouse 中。HBase 和 ClickHouse 提供 API 点查和圈选查询服务。2.1 实时特征数据流在实时特征的数据流中，MySQL 通过 Binlog 写入 Kafka，以及其他埋点类的 Kafka 数据，经过运算以后将结果写入另外一个 Kafka，最后消费数据写入 HBase 和 ClickHouse。2.2 离线特征数据流在离线特征数据流中，MySQL 通过 Sqoop，OSS 通过 Spark 或者其他方式抽取，Kafka 通过 Flume 抽取进入 EMR，然后用 Hive 或者 Spark 运算，同时写进 HBase 和 ClickHouse。2.3 同步特征数据流在同步特征数据流中，MySQL 的 Binlog 会写进实时的 Kafka，然后 Kafka 的数据会被实时写入事件存储，同时 MySQL 也会离线修正和初始化。Flink 同时做流处理和批处理，写进 HBase 和 ClickHouse。2.4 即时计算特征数据流在即时计算特征数据流中，依托于 HBase 和 ClickHouse 的数据，提供 API 点查和圈选查询服务。以上就是整个存储服务的介绍，该部分内容涉及到特征存储服务的大部分，如图中橙色部分所示。三、流批一体方案在只提供了特征存储服务的时间里，我们发现了很多问题以及一些业务诉求。首先是一些问题：在对现有模型策略精耕细作之前，还有没有什么数据没有被使用？比如说 MySQL 里面状态变化的时间点数据。输入项离线逻辑是否已经足够完整，为什么实时输入项需要重新梳理与补充逻辑？离线输入项想要编程实时的，需要重新梳理逻辑，有些甚至过于复杂，以至于用传统的方式无法完成实时转换。不确定使用场景，无法区分点查和跑批，能不能同时覆盖？对于很多业务人员来说，并不知道想要的模型和策略最终需要用跑批还是点查，有没有什么办法能同时满足这两种需求。流式处理逻辑难以理解，为什么要流 Join，不能直接“取数”吗？对于模型开发人员，他们不了解流处理过程，因此实时特征的制作难以下沉到模型开发人员。实时模型策略空跑测试需要很长时间，能不能缩短？模型策略开发训练很快，上线开发实时输入项却需要很久，能不能加速？对于这些问题，我们提出了一些方案：【数据】存储状态变化数据，支持还原任意时刻的数据切片状态。这样做还有一个额外的好处，通过流批一体方案进行模型训练的时候不会有特征穿越的问题，因为没有办法拿到未来的数。【逻辑】流批一体，以流为主，逻辑一致，无需验证口径。训练的时候用这份数据作为训练，上线及回测时也是用相同的数据，可以保证最终的结果一致。【执行】流、批、调用一体化，自适应不同场景。【开发】使用“取数”而不是流合并，封装实时流特有概念，降低实时开发门槛。【测试】支持任意时间段回溯测试，增加实时开发测试速度。【上线】自助式的流批一体模型开发上线，减少沟通环节，增加上线效率。传统的实时流方案有 Lambda 和 Kappa 两种。Lambda 提供了实时和离线的两套逻辑，最终在数据库中将两者合并起来。Lambda 的优点是架构简单，很好地结合了离线批处理和实时流处理的优点，稳定且实时计算成本可控，并且离线数据易于订正；缺点是实时、离线数据很难保持⼀致结果，并且需要维护两套系统。3.1 流批一体方案Kappa 则是全部都用实时的逻辑，将历史的数据存下来，每次得到一个切片数据，最后合并起来。Kappa 的优点是只需要维护实时处理模块，可以通过消息重放，无需离线实时数据合并；缺点是强依赖消息中间件缓存能力，实时数据处理时存在丢失数据，这个缺点在金融领域是不能容忍的。由于 Kappa 在抛弃了离线处理模块的同时也抛弃了离线计算更加可靠稳定的特点，而 Lambda 虽然保证了离线计算的稳定，但是双系统的维护成本非常高，并且两套代码的运维非常复杂。因此，我们提出了 Lambda+Kappa 的流批一体方案。如图所示，数据流转的前半部分是 Lambda 架构，其中心是一个 HBase 的事件存储；后半部分是 Kappa 架构，供用户完成流处理和批处理。上图以 MySQL 为例展示了整体流批一体方案。首先是 MySQL 的 Binlog 进入 Kafka，同时通过离线修正以及切片把数据送到事件中心，同时用相同的 Kafka 完成实时流的触发，然后事件中心会提供数据获取及离线跑批服务。最后由元数据中心统一管理数据，统一维护数据，以避免同步的问题。Flink 提供整个逻辑服务。3.2 事件中心图中的事件中心使用 Lambda 架构存储所有变化数据，每日修正，通过冷热混存与重加热机制追求最佳性价比。此外，我们参考 Flink 增加水印机制，确保当前值同步完成。最后，事件中心提供消息的转发机制以及异步转同步的的机制，以“取数”代替流 Join，消息转发机制，异步转同步。支持触发——消息接收及触发——轮询式调用，并同时赋予该接口回溯的能力。下面介绍事件中心的村塾数据流，如图所示，MySQL、Kafka 等多个数据源通过不同的路径转发到 Kafka，然后 Flink 直接消费 Kafka，并会实时的写入 HBase 热存。此外，离线修正的数据通过 EMR 也写入 HBase 热存。另有一套 Replica 机制完成 HBase 热存和 HBase 冷存之间的复制。HBase 冷存的数据也会通过重新加热进入到 HBase 热存中。整个事件中心的存储结构如图所示，冷存里面只放主体数据，热存里面除了主题数据以外，还有三个表用来做不同的 index 工作热存一般 TTL 为 32 天，有特殊的情况也可以调整。事件中心的读取数据流中，实时触发是走是 Kafka，回溯和取数都是走 HBase 热存，内部的重加热机制完成 HBase 冷存到 HBase 热存数据的更新，这部分逻辑对于开发人员是透明的，开发人员不需要关注数据来自于哪里。下面介绍事件中心的水印机制与流 Join。假设我们要对两个流进行 Join，也可以简单理解为有两张表，通过某外键进行关联。当任何一张表发生变更时我们都需要至少触发一次最终的完整的 Join 后的记录。我们将两个流分别记录为 A 和 B，并且假设 A 流先到。那么在打开事件中心水印机制的情况下，A 流触发时，A 流的当前事件已经被记录在事件中心中。此时分为两种情况：在事件中心中可以取到 B 流的相关数据，那么说明在A流当前事件记录进事件中心到运行至读取 B 流相关数据的时间段内，B 流已经完成了事件中心的记录，此时的数据已经完整。在事件中心中无法取到 B 流的相关数据，那么由于事件中心水印机制，说明此时 B 流相关事件尚未触发。而由于A流当前事件已经被写入事件中心，那么当 B 流相关事件被触发时，一定能获得 A 流的当前事件数据，此时数据也是完整的。由此，通过事件中心水印机制，即可确保用“取数”取代流 Join 后至少会有一次拥有完整数据的计算。触发消息接收通过消息转发完成。当外部系统发起请求后，会去转发 Kafka，然后 Kafka 的数据同时会进入事件中心，接下来触发相应的计算，最后去用消息队列发送计算结果，外部系统接收这个消息的结果。同时也提供轮询式的服务，同样也是消息转发，前面与消息接收机制都一样，只是多了一个事件中心，重新存储计算结果，然后提供服务。3.3 取数一致在取数的时候还有另外一个问题，那就是不一定能拿到最新的数据，除非直接从元数据库获取数据，但这种操作一般是被禁止的，因为会给主库带来压力。为了保证数据的一致性，我们采取了一些措施。首先我们将取数一致性分为四个级别，分别是：最终一致：经过一段时间后能访问到更新的数据，整个流批一体方案默认保证最终一致。触发流强一致（可延迟）：保障触发流中的当前数据及早于当前数据的数据在对触发流的取数过程中能获取到。使用水印方案，水印不满足时进行延迟。取数强一致（可延迟）：保障取数时早于用户提出的时间要求的数据均能获取到。使用水印方案，水印不满足时进行延迟。取数强一致（无延迟）：保障取数时早于用户提出的时间要求的数据均能获取到。当水印不满足时直接从数据源增量补足，增量取数会对数据源带来压力。3.4 流批一体作业我们使用 PyFlink 实现流批一体作业，使用 python 是因为模型和策略开发人员更加熟悉 Python 语言，而Flink保证了逻辑一致性。基于 PyFlink，我们封装了复杂的触发逻辑、复杂的取数逻辑，并能够复用代码片段。PyFlink 的代码组织结构如图所示，包含出发、主逻辑、输出三部分。这三部分可以不用自己实现，只需要选择已经封装好的输出。Flink 整体数据流也简单，最上面是触发逻辑，然后触发主逻辑，主逻辑里面会有取数逻辑去完成取数，最后是输出的逻辑。在这里，触发逻辑、取数逻辑和输出逻辑的底层封装是随流批变化自适应的，所以可以同时确保输入和输出不变，逻辑本身在绝大多数情况下是不需要考虑流批环境变化。下面介绍一个 PyFlink 典型的使用流程，首先选择触发流，编写取数及预处理逻辑，可引入已发布的取数或处理逻辑代码，设置取样逻辑并试运行，获取试运行结果，在分析平台中进一步分析与训练。训练结束想要发布模型时，可在作业中选择训练完成的模型，如有需要可以设置初始化相关参数。最后是模型发布上线。四、模型策略调用方案我们提供了四种调用方案：特征存储服务方案。Flink 作业进行预运算，将运算结果写入特征存储服务平台，通过该数据服务平台对外服务。接口触发——轮询方案。调用并轮询事件中心消息转发接口，直到 Flink 作业返回运算结果。接口触发——消息接收方案。调用事件中心消息转发接口触发 Flink 作业运算，接收 Flink 作业返回的运算结果消息。直接消息接收方案。直接接收 Flink 作业返回的运算结果消息。4.1 特征存储服务方案特征存储服务分为三种情况，分别是实时、离线修正和离线初始化。当有新的变量上线或者老的变量发生逻辑变化，需要对全量的数据进行一次刷新，这时候需要离线初始化。实时流是实时触发的，离线修正和离线初始化都是批量触发。如果有取数逻辑则从 HBase 里面取数，当然取数的过程中实时和离线的作业肯定不一样，但是开发人员不用关注，因为已经封装好了。实时的 Flink 作业结果会发到 Kafka，离线修正和离线初始化的结果都会进 EMR，最后写进特征存储，也就是 HBase 和 Clickhouse。上图展示了特征存储服务方案的时序，Kafka 触发了 Flink，然后Flink运算完写如特征存储。那么在刚触发的时候，如果有外部调用，是无法获取到最新的数据的，必须要等到运算完成写入存储以后才能获取到更新的数据。4.2 接口触发——轮询方案在接口触发——轮询方案中，触发调用会触发到消息转发，转发给 Kafka，然后 Flink 将运算的结果吐入 Kafka。如果这个时候没有超过单次请求的时间，就会直接返回，这个时候触发轮询就退化成单词调用了。反之，则会继续进入事件存储 HBase，通过轮询调用获取结果。接口触发——轮询方案的时序图如上图所示，当有一个外部调用触发以后，会有一个消息转发触发了 Flink 运算。在 Flink 运算及写入数据库的过程中，会有多次轮询，如果在固定的时间还没有办法获取到，则会提示超时；如果下一次轮询的时候，数据已经写入了，则获取成功。4.3 接口触发——消息接收方案接口触发——消息接收方案是对轮训的简化。如果业务系统支持支持消息接收，那么整个链路变得比较简单，只需要通过消息转发服务触发计算，然后监听结果消息就可以了。接口触发——消息接收方案的时序是串行的。触发了以后，进行 Flink 运算，运算完成以后把结果数据通过消息接收机制传输给调用方。4.4 直接消息接收方案直接消息接收方案就是纯流式的，通过 Kafka 触发 Flink 计算，计算完数据传入消息队列，然后等对方订阅接收就可以了。整个时序也是非常的简单，如下图所示。我们把数据的使用情况分成三种，分别是即时调用、实时流、离线批数据，他们的时效性是依次递减的。我们通过事件中心把这三种情况注册到一起，最后只要通过事件中心作为中转给 Flink 提供相关的数据，对于 Flink 来说，不用关心到底是通过哪种方式来调用。最后，总结下流、批、调用一体化的四种方案：特征存储服务方案：通过特征存储服务，提供持久化的特征存储。提供 API 点查与特征圈选服务。接口触发——轮询方案：通过事件中心的消息转发与消息查询服务，提供同步调用计算服务。接口触发——消息接收方案：通过事件中心的消息转发服务，提供事件消息服务。直接消息接收方案：支持复杂事件触发，提供事件消息服务。点击查看更多技术内容Flink Forward Asia 2022 活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-20
RocketMQ Flink Catalog 设计与实践
摘要：本文为 RocketMQ Flink Catalog 使用指南。主要内容包括：Flink 和 Flink CatalogRocketMQ Flink ConnectorRocketMQ Flink Catalog作者：李晓双 ，Apache RocketMQ ContributorMentor：蒋晓峰，Apache RocketMQ Committer一、Flink 和 Flink CatalogFlink 是一个分布式计算引擎，目前已经实现批流一体，可以实现对有界数据和无界数据的处理。需要有效分配和管理计算资源才能执行流式应用程序。目前 Flink API 共抽象为四个部分：最顶层的抽象为 SQL。SQL 抽象与 Table API 抽象之间的关联是非常紧密的，并且 SQL 查询语句可以在 Table API 中定义的表上执行。第二层抽象为 Table API。Table API 是以表（Table）为中心的声明式编程（DSL）API，例如在流式数据场景下，它可以表示一张正在动态改变的表。第三层抽象是 Core APIs 。许多程序可能使用不到最底层的 API，而是可以使用 Core APIs 进行编程：其中包含 DataStream API（应用于有界/无界数据流场景）和 DataSet API（应用于有界数据集场景）两部分。第四层抽象为有状态的实时流处理。Flink Catalog 提供了元数据信息，例如数据库、表、分区、视图以及数据库或其他外部系统中存储的函数和信息。Flink 对于元数据的管理分为临时的、持久化的两种。内置的 GenericInMemoryCatalog 是基于内存实现的 Catalog，所有元数据只在 session 的生命周期内可用。JdbcCatalog 和 HiveCatalog 就是可以持久化元数据的 Catalog。Flink Catalog 是扩展的，支持用户自定义。为了在 Flink SQL 中使用自定义 Catalog，用户需要通过实现CatalogFactory接口来实现对应的 Catalog 工厂。该工厂是使用 Java 的服务提供者接口 (SPI) 发现的。可以将实现此接口的类添加到 META_INF/services/org.apache.flink.table.factories.FactoryJAR 文件中。二、RocketMQ Flink ConnectorRocketMQ 连接器为 Flink 提供从 RocketMQ Topic 中消费和写入数据的能力。Flink 的 Table API & SQL 程序可以连接到其他外部系统，用于读取和写入批处理和流式表。Source 提供对存储在外部系统（例如数据库、键值存储、消息队列或文件系统）中的数据的访问。Sink 将数据发送到外部存储系统。该项目的 Github 仓库是： https://github.com/apache/rocketmq-flink三、RocketMQ Flink Catalog3.1 设计与实现3.1.1 RocketMQ Flink Catalog 的设计主要分为两步实现一个 RocketMqCatalogFactory 基于字符串属性创建已配置 Catalog 实例的工厂。将此实现类添加到 META_INF/services/org.apache.flink.table.factories.Factory 中。继承 AbstractCatalog 实现 RocketMqCatalog，通过实现 Catalog 接口中的方法，完成对数据库、表、分区等信息的查询操作。类图如下：3.1.2 RocketMQ Flink Catalog 的存储RocketMQ Flink Catalog 的底层存储使用的是 RocketMQ Schema Registry。Flink 调用 Catalog 的时候，在 AbstractCatalog 的实现类中通过 RocketMQ Schema Registry 的客户端和 RocketMQ Schema Registry 服务端进行交互。Database : 返回默认的 default 。Table : 从 RocketMQ Schema Registry 获取对应的 Schema，然后解析 IDL 转换成 DataType。Partition : 通过 DefaultMQAdminExt 从 RocketMQ 中获取到 Partition 相关信息。RocketMQ Schema Registry 是一个 Topic Schema 的管理中心。它为 Topic（RocketMQ Topic）的注册、删除、更新、获取和引用模式提供了一个 RESTful 接口。New RocketMQ 客户端通过将 Schema 与 Subject 关联起来，可以直接发送结构化数据。用户不再需要关心序列化和反序列化的细节。3.1.3 RocketMQ Flink Catalog 支持的 API目前 RocketMQ Flink Catalog 支持对 Database、Table、Partition 的查询和判断是否存在的操作，不支持创建、修改、删除。所以在使用之前需要通过 RocketMQ Schema Registry 来创建好对应的 Schema。3.2 使用指南表环境（TableEnvironment）是 Flink 中集成 Table API & SQL 的核心概念。它负责:在内部的 Catalog 中注册 Table。注册外部的 Catalog。加载可插拔模块。执行 SQL 查询。注册自定义函数 （scalar、table 或 aggregation）。将 DataStream 或 DataSet 转换成 Table。持有对 ExecutionEnvironment 或 StreamExecutionEnvironment 的引用。3.2.1 创建并注册 CatalogTable API ：RocketMQCatalog rocketMqCatalog = new RocketMQCatalog("rocketmq_catalog", "default", "http://localhost:9876", "http://localhost:8080"); tableEnvironment.registerCatalog("rocketmq_catalog", rocketMqCatalog);SQL：TableResult tableResult = tableEnvironment.executeSql( "CREATE CATALOG rocketmq_catalog WITH (" + "'type'='rocketmq_catalog'," + "'nameserver.address'='http://localhost:9876'," + "'schema.registry.base.url'='http://localhost:8088');");3.2.2 修改当前的 CatalogTable API ：tableEnvironment.useCatalog("rocketmq_catalog");SQL：tableEnvironment.executeSql("USE CATALOG rocketmq_catalog");3.2.3 列出可用的 CatalogTable API ：String[] catalogs = tableEnvironment.listCatalogs();SQL：TableResult tableResult = tableEnvironment.executeSql("show catalogs");3.2.4 列出可用的 DatabaseTable API ：String[] databases = tableEnvironment.listDatabases();SQL：TableResult tableResult = tableEnvironment.executeSql("show databases");3.2.5 列出可用的 TableTable API：String[] tables = tableEnvironment.listTables();SQL：TableResult tableResult = tableEnvironment.executeSql("show tables");3.3 Quick Start需要提前准备可用的 RocketMQ 、RocketMQ Schema Registry：RocketMQ 部署：https://rocketmq.apache.org/docs/介绍/02quickstartRocketMQ Schema Registry 部署：https://github.com/apache/rocketmq-schema-registry3.3.1 创建 Topic创建两个 Topic，rocketmq_source 和 rocketmq_sink。3.3.2 注册 Source Schemacurl -X POST -H "Content-Type: application/json" \ -d '{"schemaIdl":"{\"type\":\"record\",\"name\":\"rocketmq_source_schema\",\"namespace\":\"namespace\",\"fields\":[{\"name\":\"name\",\"type\":\"string\"}]}"}' \ http://localhost:8088/schema-registry/v1/subject/rocketmq_source/schema/rocketmq_source_schema3.3.3 注册 Sink Schemacurl -X POST -H "Content-Type: application/json" \ -d '{"schemaIdl":"{\"type\":\"record\",\"name\":\"rocketmq_sink_schema\",\"namespace\":\"namespace\",\"fields\":[{\"name\":\"name\",\"type\":\"string\"}]}"}' \ http://localhost:8088/schema-registry/v1/subject/rocketmq_sink/schema/rocketmq_sink_schema3.3.4 添加依赖创建一个任务项目 ，添加 rocketmq-flink 的依赖 :<dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-flink</artifactId> <version>1.0.0-SNAPSHOT</version> </dependency>目前 RocketMQ Schema Registry 还没有发布正式的版本，只有快照版，如果发现 jar 找不到，可以尝试以下方法：<repositories> <repository> <id>snapshot-repos</id> <name>Apache Snapshot Repository</name> <url>https://repository.apache.org/snapshots/</url> <snapshots> <enabled>true</enabled> </snapshots> <layout>default</layout> </repository> </repositories>3.3.5 创建任务/** * @author lixiaoshuang */ public class RocketMqCatalog { public static void main(String[] args) { // 初始化表环境参数 EnvironmentSettings environmentSettings = EnvironmentSettings.newInstance().inStreamingMode().build(); // 创建 table 环境 TableEnvironment tableEnvironment = TableEnvironment.create(environmentSettings); // 注册 rocketmq catalog tableEnvironment.executeSql( "CREATE CATALOG rocketmq_catalog WITH (" + "'type'='rocketmq_catalog'," + "'nameserver.address'='http://localhost:9876'," + "'schema.registry.base.url'='http://localhost:8088');"); tableEnvironment.executeSql("USE CATALOG rocketmq_catalog"); // 从 rocketmq_source 中获取数据写入到 rocketmq_sink 中 TableResult tableResult = tableEnvironment.executeSql("INSERT INTO rocketmq_sink /*+ OPTIONS" + "('producerGroup'='topic_producer_group') */ select * from rocketmq_source /*+ OPTIONS" + "('consumerGroup'='topic_consumer_group') */"); } }启动任务并运行以后，打开 RocketMQ 控制台，往 rocketmq_source 这个 Topic 发送一条消息。然后再查看 rocketmq_sink 的状态，就会发现消息已经通过写入到 rocketmq_sink 中了。点击查看更多技术内容Flink Forward Asia 2022 活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-12
37手游基于云平台的大数据建设实践
本文整理自 37 手游大数据平台资深开发工程师史飞翔在实时数仓 Workshop · 广州站的演讲。主要内容包括：云平台大数据建设背景云平台大数据建设方案应用实践未来规划点击查看原文视频 & 演讲PPT 首先介绍一下背景。我们之前是自建的大数据集群，考虑到集群未来的扩展性、稳定性以及成本问题，决定大数据全部上云，今天的分享就是基于 IDC 集群上云的建设实践。一、云平台大数据建设背景首先看一下这张图，做大数据的同学对这些组件应该都很熟悉，刚开始我们也一样，像动物园一样，管理了很多 “小动物”。2019 年，我们的很多离线作业是基于 Hadoop 集群做的。基于这个集群之上，我们有一些 OLAP 查询场景，当时可选的组件不多，于是我们用了 Kylin、Druid。但是这只能应对一些简单的场景，复杂的场景还是没办法直接基于这些组件对外提供服务。2020 年，引入了实时计算，当时用的是社区版 Flink，其中 ClickHouse 跟 ADB 主要是做 OLAP 的查询，另外的 ElasticSearch 是用来存储画像的数据。2021 年，随着业务场景的需要，我们用到的组件也越来越多，所以不得不选用基于多数据源的查询引擎，于是引入了 Presto，这个时候可以基于 Presto 做一些联邦查询 ，Hive、MySQL、ADB、ClickHouse 等做一个打通关联。基于 Presto，我们会在上层做一个报表的查询。2022 年，我们大数据全部上云了，只需要用到三个重要组件：MaxCompute、Hologres、Flink。以上是我们大数据演进的过程，下面先分析一下 IDC 集群的情况。第一、资源成本：机器成本高；机房成本高，因为有一百台机器要有单独的机房；空闲时间多。我们的离线作业大部分在晚上运作，白天的时间基本上是比较浪费的。第二，人力成本：组件多，运维成本高。一个人要负责三四个组件的维护；组件学习成本高，一些业务开发的同学会使用我们提供的组件，对于他们来说，会有一定的学习成本；开发成本高。第三，稳定性、扩展性。IDC 集群做扩容时流程很复杂，从申请，到机器的采购，再到部署、上线等，至少要一个月的时间，扩展性很差；机房部署周期长；故障率较高。基于IDC集群的综合评估，跟云上做了一个对比。主要是两个方面：一是技术，二是业务。右边图是随着节点数的增加自建机房与基于阿里云的对比。在集群节点不断扩大的情况下，可以看到自建机房的单位成本逐渐增高，基于阿里云的单位成本基本稳定不变。从技术上：上云后用到的组件很少，维护成本低。统一套件，统一开发流程，极大的提高开发效率。实时计算开发更便捷。上面也讲到了，实时计算只需写一条 SQL 就可以了，快捷。监控齐全。以前任务出现问题很难发现，现在有了配套的监控就可以及时的发现。从业务上：可以空出更多的时间做更有业务价值的东西，数据赋能业务。数据的时效性。之前有的 15 分钟、30 分钟跑一次，现在是实时的，这是很明显的对比。从上图的对比可以看出，上云之后我们对组件做了简化。从流计算开始，Flink 社区版、Spark、Storm 直接用实时计算 Flink 替代。第二是离线计算，之前用 Hadoop、hive、Spark，现在统一存在 MaxCompute。最后一个是 OLAP 数据库，包括之前的 ClickHouse、Presto、Kylin、Druid 等，现在全部用 Hologres 替代。总体来说有以下几个方面的变化：一是效率高。上云之后首先是效率的变化，不单单是机器扩展效率，还有包括开发效率。二是成本低。我们也和 IDC 集群做了对比，上云之后整体成本会降低。三是易扩展。现在不管加存储也好、内存或者 cpu 也好，几分钟即可完成扩展。四是稳定性高。上云之后几乎还未出现过问题。二、云平台大数据建设方案先看一下总体方案设计：第一条链路是实时流，从 Kafka 过来，经过实时计算，实时计算之后会落到 Hologres。但是有一些场景需要扩展维度，实时计算时会用到配置表，是在 Hologres 基于行存来存储的配置表，通过点查的能力，把配置信息取出来做实时关联，最终落到 Hologres。第二条链路，可能也是大家常用的（传统的数据库还是要保留），我们会把传统的 MySQL 数据库通过 DataWorks 数据集成同步到 Hologres。最后一条链路是离线的，Kafka 数据通过 DataWorks 写到 MaxCompute，写完之后会在 MaxCompute 每天定时跑任务来修整第一条线的实时数据，也就是做一个离线的修正。另外我们会把 MaxCompute 里画像数据推到另外两个组件。这里说明一下，这两个组件是为了考虑到双云部署，所以我们考虑到开源的组件，StarRocks 和 HBase，这两块主要是用在画像上。最后一层是用到 Quick BI 做展示，包括用户画像也是基于 StarRocks 和 HBase 做一个查询。以上是整体的方案，下面讲一下具体的实时数仓和离线数仓。上面是实时数仓，可以看到主要来源于两个地方，一个是 MySQL，一个是 Kafka。两块数据是通过 Flink 落到 Hologres，从 DWD 到 DWS 再到 ADS 逐层清洗，最终落到 Hologres。下面是离线数仓，通过 MySQL、Kafka 落到 MaxCompute，在 MaxCompute 逐步分层，最终落到 Hologres，离线这一层会修正实时的数据。接下来会讲五个场景。第一个场景，我们用到数据集成，将 MySQL 数据、Kafka 数据通过 DataWorks 的数据集成写到 Hologres，这就是数据同步。第二种方式是 MySQL 的数据可以通过 Flink CDC 特性同步到 Hologres，这个过程只是一个简单的同步，没有做任何数据的处理。下面这些是日常开发的任务。第二个场景会经过简单的计算，这里并未涉及到数据分层，直接通过简单计算落到实时数仓。有时需要对数据进行维度的扩展，所以我们会在 Hologres 做一个视图，视图进行数据表和配置表的关联。但是这里有一个问题就是会对性能有一个损耗，如果数据量很大，则不建议这个方式。如果是比较小的数据，计算不复杂，可以走这个链路，最终做一个展示。看一下应用案例：第一是运营中台的活动，我们在做一个游戏活动时，可能会分 A、B 两个人群做代金券或者礼包的发放，对 A、B 两批人在不同阶段（登录、激活、充值等）进行统计分析，进而分析这个活动效果与收益。二是苹果后台的数据，通过实时计算得到不同阶段的转化率，包括从展示到购买，从查看到购买，从展示到查看等转化率。最后是 SDK 埋点，做了一个漏斗的模型，也是看转化过程。从下载、激活、到登录等一系列流程转化率的展示。这是第三个场景：此前的方案是把 kafka 作为中间存储，中间层 DWD、DWS 都存储在 kafka 中。这种方案的缺点是很明显的，一旦数据不一致或者数据延迟，很难排查问题。目前是基于 Hologres 来做的实时数仓，每一层数据都会实时落进去，有问题的时候比较容易追踪。我们的数仓大致分了这几个域，分别是用户域、设备域、交易域、广告域、运营域、客服域、公共域，以上是数仓分域情况。第四个场景：如右上图，多指标合并此前我们会通过双流 Join 来做，假设想通过这个表来看用户登录、激活，但它有两条流，登录是一条流，激活是一条流。我们之前可能是要把这两条流用 Flink SQL 写出来做一个 join，但是这个性能不太好，计算也会翻倍。新的方案是基于 Hologres 的主键做局部更新，登录这条链路就只做登录分析，激活就只做激活的统计。source 是两个，但是 sink 到同一张表，基于 Hologres 宽表 merge 的能力来实现这个业务需求。第五个场景，就是刚刚提到的 Kafka 数据有时维度不够，要做维多扩展。所以我们会去 Hologres 里面取行存表，行存表点查的能力很强，通过行存表补充维度信息，最终落到 Hologres 宽表。上图是 Lookup 的场景：第一是运营维度的拆解。如何理解右边黑色的部分？在一款游戏发行之后，我们会基于某一个维度做下钻的分析，看某一个游戏，比如 A 游戏下哪个联运商的占比比较高，再根据这个联运商做进一步的下钻分析。二是游戏首发时，我们可以实时地关注这个游戏的玩家动向。最后是广告效果的数据，当投放一个广告，我们要知道这个广告后期的留存情况、LTV，以及媒体测的曝光、点击、下载等数据。上图是一个实践方式：首先，上游是 Kafka 的源表。首先需要建一个 kafka 的源表，其次是建立 Hologres 目标表，最后是写一条业务逻辑 SQL，把数据 insert 到目标表，实时计算过程就完成了。还有宽表 merge 场景，上面提到我们的源是有两个 Kafka，kafka 1 和 kafka 2，分别从两个 source 端读数据，然后 sink 到同一个 Hologres 的目标表，但是一定要保证主键是相同的。第三是通过 Flink 消费 Hologres Binlog 的能力，这种场景一般是应用到充值类、订单类的数据。因为这种数据会变更，所以不像 Kafka 里面日志类的数据那么简单的处理，这时会用到 Hologres 的 Binlog，等于把 MySQL 的 Binlog 做了同步，所以 Hologres 也可以拿到 Binlog，可以直接通过这个能力去查这个表。最后，看一下实时数仓对我们有哪些影响。先看解决了哪些问题：一是数据存储的问题，以前存储组件非常多，Kylin、Druid、MySQL、Presto 等，现在统一存到 Hologres。二是千万级维表变更的问题，我们的量级非常大，大概能到 5000 万，数据要去关联 5000 万的配置表，并且要实时地做这个事情，这在之前很难做到。三是查询效率的问题。对业务来说，查询的时候非常慢，这个问题能通过 Hologres 高性能的查询解决。最后是成本问题，因为 IDC 集群的成本，包括维护成本，还有后期扩展成本都是很高的。再看带来了哪些价值？一是数据存储统一。打破了数据孤岛，37 域的数据是全通的。二是数据更加实时。之前每天的数据会半小时或者十五分钟跑一次，现在是实时计算，所见即可得，尤其是游戏首发的时候我们对数据的实时性要求非常高。三是查询效率。旧的引擎很难支撑业务的快速发展，新的数据库 Hologres 在查询性能上体验极佳。最后是开发流程简化。我们之前的开发流程是很复杂的，现在只需要实时计算这块写一个 SQL 就可以搞定了。三、应用场景上图是关于游戏的生命过程。一个游戏的诞生首先是从创意开始，怎样策划一个游戏。策划完第二步就是做研发，一个游戏能不能长期留住玩家，这一步是最关键的，包括关卡设置，关卡难度，游戏画面等等。第三步是游戏发行，研发完成后即是游戏推广了，不然就算这个游戏再好玩，没人知道、没人玩也是没有收益的，酒香也怕巷子深。发行完后最关键的就是如何留住玩家，如何长期留住玩家，在线游戏运营是重要的一个环节，维护一个良好的游戏生态。最终是获益。因为我们是一个发行公司，所以我们主要在做买量优化、异常检测、高价值玩家的预测、用户画像、效果分析等等，重点是在推广和运营。接下来重点讲买量优化以及游戏运营。上图是买量优化简单的流程图。我们会拿到一个玩家的历史数据，然后去分析特征，再结合运营平台的运营数据做一个预测，预测哪些是高留存玩家。然后会基于这些高留存玩家在投放平台进一步的投放相关游戏，最后基于投放效果数据进行反复的迭代模型、分析效果等。上图是自助分析的场景，我们的数据后台大部分是给 B 端用的，此前的一个开发模式是比较传统的，数据开发同学负责报表数据的开发，展示由前端去做页面的开发，业务从提一个需求到排期再到交付，这个过程可能要花 1-2 周。但是有了自助分析平台，我们用的是 Quick BI，业务提需求后只需要做数据集就可以完成自助分析，大概半天的时间就可以完成，甚至业务自己也可以完成一些简单的需求。上图是精细化运营，当我们做一个活动，比如发放代金券或者礼包的时候，会跟踪发放的后续情况。这里做了 AB 测试，我们先圈选一部分人，再分成 AB 两个批次，每批次 50%，后续会对这些人做触达，比如发短信，或者在游戏里发代金券等。做完这些活动之后再去统计分析活动效果，右边就是统计的结果，看看做这个活动对玩家会产生怎样的影响。这是我们用到的一个画像数据，这个画像数据其实做挺久了，从 2019 年就开始做，并且在不断的迭代，所以现在画像是很完善的。不但可以分析基础的数据，还会基于人群去做分析。基于复杂的条件圈选人群包，因为基于人群包做投放，所以还会对人群包后续的情况做一个效果的分析，包括留存的情况，LTV 数据等。上图是智能诊断，大家应该也会遇到这样的问题，如果数据有问题，一般得等到业务发现之后才进行反馈。而我们在做的这个事情，可以比业务更早发现异常的数据，这就是智能化的诊断。像右边红色部分那里一样，自动检测出异常点。比如发行了一个游戏后，某一天或者某一刻充值突然下滑（当然也有可能是上升），想知道哪些指标的影响比较大，就可以基于异常点做一个更详细的归因分析，比如我们分析出这个游戏是《斗罗大陆》或者《云上城》导致的，可以自动分析出来每个维度对游戏指标产生价值的排名，看哪些维度对这个影响最大。四、未来规划首先，我们在智能投放方面做得还不够好，所以想在智能方面投入更多的精力和时间。比如 37 手游的用户数据跟媒体数据做一个打通，这样不但可以对自己已有的画像人群分析，还可以结合媒体画像指标做进一步分析。有了这些数据可能对投放的效果也会有很大的提升。第二，智能运营。现在做的事情是每个人发送代金券、礼包，其实都是统一的，我们未来想做到千人千面，每个人发不同的代金券，不同的礼包，类似于个性化推荐，进而来提高收益。第三，智能诊断、归因分析。在海量的数据，海量的指标中，数据波动异常如何及时发现；发现异常后如何分析导致异常的原因等。目前做的还是比较初阶，这也是我们未来重点突破的地方，智能归因、智能诊断、智能化洞察。公司介绍37 手游是 37 互娱的子公司，主要负责运营，也就是发行业务。在中国大陆地区 37 手游以 10% 占有率仅次于腾讯和网易排第三。现在在非中国大陆地区也已经进入月收入过亿的俱乐部，成功发行了包括《永恒纪元》、《一刀传世》、《斗罗大陆》这几款游戏，当前已经累计 4 亿用户。点击查看原文视频 & 演讲PPTFlink Forward Asia 2022 活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-10-09
往届作品回顾 | 第四届实时计算 Flink 挑战赛
2022 第四届实时计算 Flink 挑战赛目前正在火热报名中，参赛项目提交的截止时间为 10 月 20 日，还没报名的小伙伴们要抓紧喽~！https://tianchi.aliyun.com/competition/entrance/532003/introduction今年的实时计算 Flink 挑战赛，采用了和去年 Flink Forward Asia Hackathon 相似的开放式命题。为了帮助小伙伴们更好地打开脑洞，我们在此对去年的优秀参赛作品进行回顾。2021 年的 FFA Hackathon 共有 27 支队伍晋级到决赛阶段，参赛作品主要包括对 Flink 引擎及 Connector 的改造和优化、基于 Flink 的开发及运维平台、Flink 在某个具体领域场景的应用等。Flink Forward Asia Hackathon （2021）- Apache Flink 骇客松比赛回顾引擎及 Connector在改造优化 Flink 引擎及 Connector 的参赛作品中，我们观察到参赛选手们主要关注两个场景，即离线实时、分析服务一体化的一站式数仓场景，以及流式处理中的资源动态自适应。一站式数仓在关注一站式数仓场景的参赛作品中，首先要介绍的是我们的冠军作品《基于 Flink 实现 Kafka + Iceberg 的流批一体 Hybrid Storage》。该作品通过对现有 Source 和 Sink 的串联与封装，达到同时读写流存储（Kafka）和表存储（Iceberg）的效果，简化了用户使用 Flink 实现分析服务一体化的复杂度。值得关注的是，该作品与 Flink 社区在今年上半年发布的 Flink Table Store 具有异曲同工之妙，尽管在具体的技术方案上有所区别，其目标都是解决分析服务一体化对于流表二象存储的需求。季军作品《基于 Apache Flink 的批流融合 TableSource》则是关注离线实时一体化的实现，通过在 Source 内部引入轻量级的数据整合算法，在不锁表的前提下，实现数据消费离线转实时的 Exactly-Once 语义。该作品采用的无锁数据整合方案，与 Flink CDC 去年下半年发布的 2.0 版本不谋而合，也由此可见参赛选手对离线实时一体化场景下用户痛点的准确把握。另一项季军作品《Flink SQL 算子 CDC 订阅》，通过对 Flink SQL 优化器及算子的改造，支持 SQL 任务中间计算结果的跨作业复用。其本质是将算子的状态改造成可供其他作业查询的物化视图，支持通过 Catalog 自动发现可复用的数据，支持全量、增量及全增量自动切换的消费方式。资源动态自适应亚军作品《Morphling - Flink 流作业的动态资源预测与快速调整》，根据作业运行时的指标计算单并发算子的最大数据处理能力，从而预测作业的资源需求并作出动态调整。该作品的一大亮点是，支持在作业整体数据处理不停的情况下进行局部的并发调整，具有较高的技术难度。另一参赛作品《Flink 任务自动伸缩服务》采用了相似的预测作业资源的方法，借助 Flink 已有的 Reactive Mode 实现动态资源调整，更加贴合云原生生态体系。有趣的是，该作品使用一个 Flink 任务来观测其他 Flink 任务的运行情况，判断并触发资源调整。该作品最终获得了最佳创意奖。开发运维平台此次大赛有多支参赛队伍都选择了设计研发基于 Flink 的开发及运维平台，包括通用的 Flink 作业可视化开发与管理平台，以及针对在线训练、特征工程等特定应用的平台等等。亚军作品《基于Alink、Flink SQL 实现工业化批流一体在线学习体系，赋能模型化智能报警业务》实现了一套相对完整的端到端批流一体在线学习体系。该作品采用 Flink SQL 做在离线的特征生成与样本拼接，采用基于 Flink 的机器学习算法库 Alink 做在离线训练，采用 Pravega 作为流批一体的中间件存储。作品还展示了该在线学习体系在模型华智能报警业务中的应用。季军作品《Flink 实时流计算 web 平台》展示了一个轻量的可视化 Flink 任务开发及管理平台，功能涵盖任务配置、任务启停、监控告警、日志浏览、SQL 语法提示及格式化、SQL 语句校验等。该作品功能相对完整，且完全开源可复用，截至发稿时在 Github 上已有 1.4k Star。领域场景应用此次大赛，展示 Flink 在某个特定领域或场景中应用的参赛作品是最多的，其中尤其以机器学习与人工智能方向的应用居多。《基于 GStreamer + Pravega + Flink 的实时生产线品质管控平台》以及《基于 Flink + Pravega 的数据流处理的实时工厂水果品质分类》都是采用 Flink + Pravega 进行视频流处理以及图像分类，分别获得了此次大赛的最佳实践奖和最佳创意奖。前者展示了从边缘到中心的一体化解决方案，后者则将实时计算应用在传统农业领域具有一定的新颖性。《智慧农业中的产量预测监控与模拟复盘系统》同样是基于 Flink + Pravega 来预测农作物的产量。该作品一个比较新颖的地方时，利用流式处理的重放能力，结合人工生成的可控变量（温、湿度等），进行农作物产量的模拟复盘分析，巧妙地解决了农业技术领域影响因素多、实验周期长的问题。该作品获得了大赛的最佳实践奖。《芯片软件 CI/CD 大数据分析与状态监测》立足于独特的场景。芯片软件除了具备底层技术的复杂性，还需要保证对众多平台的兼容适配，在日常开发中会产生大量的测试编译数据。利用 Flink + Pravega 对编译日志进行分析分类，能够极大幅度地降低人工成本，提高迭代效率。该作品同样获得了此次大赛的最佳实践奖。另一项获得最佳创意奖的作品是《基于 Flink 集成 Rete 网络实现规则引擎处理分析海量数据》。该作品将专家系统中用于高效匹配批量模式与批量对象的 Rete 网络与 Flink 的分布式实时处理能力相结合，以提高匹配性能、降低资源消耗。总结以上就是 2021 FFA Hackathon 中的全部获奖作品。在选题方面，去年的参赛选手们主要关注了一站式数仓、资源动态自适应、开发运维平台、AI / CEP 应用等领域。而在过去的一年里，Flink 社区先后发布了 Flink ML 2.0, Flink Table Store，Flink Kubernetes Operator 等新的子项目。在今年的实时计算 Flink 挑战赛中，参赛选手们又能利用这些原有的以及新兴的技术开出怎样的脑洞，让我们共同期待。在评选方面，我们观察到去年的获奖作品均在创新性、完成度、技术难度、与 Flink 的契合度、实用性及可复用性中的一个或多个方面有比较好的表现。在今年的实时计算 Flink 挑战赛的赛题介绍中，也明确指出评委将重点从创新性、实用性、完成度等角度评判参赛作品。最后，再次呼吁屏幕前的你，不要犹豫，召集起身边的小伙伴们，赶快报名，一起秀出你的创意吧~！https://tianchi.aliyun.com/competition/entrance/532003/introductionFlink Forward Asia 2022 正式启动 活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-30
回顾｜Apache Flink Meetup · 北京站（附问题解答 & PPT 下载）
Flink 1.16、Flink Batch、更轻量的 Checkpoint、Table Store 0.2、 Streaming Warehouse 、流批一体...这些都是 9 月 24 日 Apache Flink Meetup 的关键词。活动现场照片：https://live.photoplus.cn/live/pc/91397712/#/live活动视频回顾 & PPT 获取PC 端建议前往 Apache Flink 学习网：https://flink-learning.org.cn/activity/detail/f30571911e47478ddf4047eeb518d796移动端PPT：关注 Apache Flink 公众号，回复 0924视频：关注 ApacheFlink 视频号，查看直播回放线上问题解答01《更快更稳更易用 -- Flink 批处理能力演进》问：自适应这个是默认开启吗？答：目前没有默认开启，需要用户配置使用自适应批处理调度器来启用。具体可以参考社区文档https://nightlies.apache.org/flink/flink-docs-release-1.15/zh/docs/deployment/elastic_scaling/#adaptive-batch-scheduler问：自适应能不能解决数据倾斜问题？答：当前版本还不能。但是 Adaptive Batch Scheduler 的实现已经为数据倾斜的解决提供了基础。后续我们会根据各个数据分区的大小，对其进行分组，使得各个下游消费的数据尽可能均衡。当然，这样解决不了非常严重的热点 key 问题。不过动态执行拓扑的引入，使得引入子拓扑来对热点 key 进行拆分整合成为了可能，从而解决热点 key 的问题，我们会持续关注这方面的需求并考虑完善的解决方案。02《Flink 1.16：Hive SQL 如何平迁到 Flink SQL》问：能不能把一些额外的组件和 flink 项目分开。感觉和 flink 版本绑定了，用 sqlclient 等组件就必须用那个版本的 flink。答：目前Flink仓库的一些 connector 正在搬出 Flink 主仓库，之后 Flink 项目会瘦身。SQL Client 正在重构并通过 REST API 对接到 SQL Gateway。届时 SQL Client 可以与 Flink 版本解耦，可以同时对接多个版本的 SQL Gateway 和 Flink 集群版本。问：sql gateway 后续会支持 spark/trino 引擎吗？答：SQL Gateway 目前只面向 Flink 引擎。外部的生态系统可以通过 SQL Gateway 搭建多引擎平台。问：sql gateway 与 kyuubi 的定位是否类似？答：两者的定位和作用是类似的，都是为查询引擎提供 SQL 服务。但两者又有所不同， Kyuubi 起源于为 Spark/Hive 提供 SQL 服务，主要面向批场景。但是 Flink SQL Gateway 主要面向的是 Flink 引擎，从一开始就将流批一体的能力设计进去了，能同时很好地支撑Streaming SQL和Batch SQL的用户场景。问：sqlgateway 和 kyuubi flink 引擎有什么不同？有哪些优势吗？答：目前 SQL Gateway 在功能上对 JDBC 的支持更为完善（getPK，getColumns），支持同步/异步执行SQL，能无缝对接主流 Hive 生态工具。第二个就是 kyuubi 主要依赖 Hive 接口来暴露服务，Hive 的纯批语义无法支持 CDC 的 DELETE、UPDATE_BEFORE、UPDATE_AFTER 等消息类型，但是我们的 SQL Gateway 还提供了 REST API，对Streaming SQL提供了原生支持。第三，SQL Gateway 的 HiveServer2 Endpoint 与 Hive 做了深度集成，便于用户直接将 Hive 作业无缝迁移到 Flink。问：sqlgateway 支持哪几种模式？三种模式都支持吗？答：目前只支持 session, per-job 模式，但还不支持 application 模式。问：未来会支持 spark/presto sql 方言么？答：其实 spark 方言和 hive 方言比较类似。一些 spark sql 任务也可以使用 Hive dialect 来解析然后通过 Flink 来运行。presto sql 方言目前还没规划。问：sqlgateway 是否提供多租户能力，是否能支持鉴权功能、HA功能？答：目前支持多租户，但还不支持鉴权功能和 HA 功能，将来后续版本中支持。03《基于Log的通用增量Checkpoint》问：这是什么版本的优化答：1.15开始支持，1.16做了一些性能优化和状态特性的兼容等，基本生产可用，可以参照1.16的文档使用问：有没有一种场景是要获取上一个成功的任务的状态，接着下一个开始，又不想查数据，可以直接获取到。不想使用流任务占资源。答：是说在多个任务之间共享状态吗？这个的话可以考虑下State Processor API问：基于 log 的 checkpoint 是如何影响 flink table store 的？整个过程是怎么样的？答：可以把table store当成事务性sink来看，目前table store推荐的cp interval是1 mins，近实时，但是否实际cp能在1 mins完成，或者是否能配置更低的interval来让table stroe中的数据更实时，取决于cp完成得多快，changelog是可以在这方面做提升的问：这个通用增量 checkpoint 是以 rocksdb 为 state backend 时设置增量 checkpoint 的另一选择吗？答：两者是正交的，可以在state.backend.incremental设置为true的基础上再打开changelog04《基于 Flink CDC + Kafka 加速业务实时化》问：如果仅仅是一个库的多张表呢？只能多条语句吗？答：可以使用 CREATE DATABASE AS (CDAS) 同步同一数据库中的多张表问：除了 mysql＆kafka 数据同步外，schema 能同步到 registry 吗？答：暂不支持该功能问：flink cdc 全量和增量利用 watermark 是怎么切换的？具体是怎么配置的？答：这里的 watermark 与 Flink watermark 概念不同。为避免全量读取过程中数据发生变化产生不一致，在进行全量读取之前首先会记录当前 binlog 的位点，记为 low watermark，在全量读取结束后再记录一次 binlog 位点作为 high watermark，然后再将 low / high watermark 之间对全量数据产生的变更 binlog 合并到全量读取的数据中，实现全量数据的完全一致。问：cdc 将不同数据源同步到 kafka 中，有没有对消息体数据格式做统一，消息体是否带 schema？答：Kafka 消息统一使用 JSON 格式，不会单独记录 Schema。问：kafka catalog 在哪里记录的 topic schema 呢？答：Topic schema 不会单独记录。Kafka JSON Catalog 在读取表时会通过探测的方式首先读取多条数据、解析 JSON 来确定 schema。问：demo 里用的什么版本的 kafka答：Demo 使用了 Kafka 2.4.1，但该功能不绑定于某个 Kafka 版本。问：作业启动后中途要添加一张表的同步要怎么处理？答：暂时无法处理新表，MySQL CDC source 后续会增加动态加表的能力问：flink cdc 整库除了入 kafka 外，能入湖和入仓吗？答：商业版已支持数据同步到 Hologres，其他数据湖/仓库会陆续支持。问：flink cdc＆kafka 同一个库下大表和小表同步资源使用上有什么不同策略么？答：默认不会对不同表的资源做特殊处理，但用户可以在平台上手动配置算子并发。05《Flink Table Store 典型应用场景》问：flink table store 什么版本可用？答：flink table store 0.1.0 是 beta 版本，0.2.1 是生产可用版本。支持 flink 1.14 和 1.15 版本。问：宽表合并中若两条流没有公共 pk 怎么办？答：0.3会考虑这种场景的打宽，后续会有单独设计问：fts 会有小文件问题么？答：flink table store 在写数据的同时异步 compaction问：flink sql gateway 的进度能介绍下吗？答：flink-sql-gateway 会在1.16发布问：目前 table store 不支持流读是么？还没有changelog答：支持流读，数据库cdc可以配置changlog-producer=input来优化读取性能Flink Forward Asia 2022 正式启动 活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-21
议题征集｜Flink Forward Asia 2022 正式启动
点击投递议题在这数据量爆炸性增长的时代，开源软件如雨后春笋般出现在开发者的视野中，数据的价值被重新定义。同时，越来越多的企业开启实时化道路，数据的实时分析与计算需求与日俱增。作为主打流处理的计算引擎 Apache Flink 于 2014 年正式开源，并在 Apache 基金会的众多开源项目中，活跃度连续几年名列前茅，可谓炙手可热。据 Flink 官网数据显示，至少 2/3 的开发者来源于中国，这代表着中国开源力量日益兴起，并开始在国际化舞台上熠熠生辉。自 2018 年 Flink 中文社区成立至今，Flink 已在国内多个行业落地，并日益成为推动企业数字化转型的澎湃动力。成立之初， Flink 中文社区就引入社区顶级盛会 Flink Forward ，并于 2019 年将 Flink Forward China 正式升级为 Flink Forward Asia（简称 FFA）。Flink Forward Asia 每年都会集结最佳行业实践以及 Flink 最新技术动态等，并积极拥抱生态伙伴，共建繁荣开源大数据生态。Flink Forward Asia 2022 正式上线！作为最受社区开发者期盼的年度顶会，今年的 Flink Forward Asia 2022 已正式启动！暂定于 11 月在线上举办，探讨交流 Flink 最新动态。延续 FFA 惯例，会议所有议题均为开放征集而来，并由专业的议题评选委员会评分筛选，确保内容代表行业领先水平。超强阵容议题评选委员会FFA 2022 邀请了 10 位行业领袖及开拓者组成议题评选委员会，并继续由阿里巴巴开源技术委员会负责人贾扬清担任主席，10 位专家共同为大会内容护航。议题方向Flink Forward Asia 2022 将采用议题标签的形式呈现所有大会精彩内容，围绕 Flink 横跨多行业，新场景。每个议题可以选择 1-2 个标签。主要标签划分如下：在 Flink Forward Asia 2022，您可与全球开发者分享您的真知灼见，同各技术领域顶级专家面对面交流，探索数字化技术下的未来趋势。如果您对以上任意技术方向有积累与洞察，欢迎投递议题！每位嘉宾最多可以投递三个 Topic，投递日期截止至 10 月 14 日。过程中如有问题，可以添加下方微信沟通咨询。点击投递议题▼ 议题投递咨询 ▼近期热点活动报名｜9月24日 Apache Flink Meetup · 北京站，Flink 1.16 新版本发布！Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-16
活动报名｜9月24日 Apache Flink Meetup · 北京站，Flink 1.16 新版本发布！
点击参与线下交流Flink 1.16 新版本发布，全新功能上线！Flink Batch、更轻量的 Checkpoint、Table Store 0.2、 Streaming Warehouse 、流批一体等多重关键词汇聚在一起，会碰撞出怎样的火花？敬请期待！Apache Flink 社区 1.16 新版本发布 Meetup 来啦！9月24日 | 北京 | 线下Flink 1.16 + Flink Table Store 0.2 发布Streaming Warehouse 往前迈了重要的一步！嘉宾及议题介绍01《更快更稳更易用 -- Flink 批处理能力演进》【嘉宾介绍】贺小令，花名晓令 ，Apache Flink Committer，阿里巴巴高级技术专家。2014 年北京大学硕士毕业后加入阿里巴巴，目前是 Flink SQL 引擎优化方向负责人，长期从事 Flink 的研发工作，致力于提供高性能、低成本，稳定、可靠的计算框架。朱翥，Apache Flink PMC & Committer，阿里巴巴高级技术专家。来自阿里巴巴计算平台事业部实时计算团队，主要负责 Flink 的调度和容错的研发工作。【演讲简介】社区一直在改进 Flink 的批处理能力，其中的一个主要方向是通过运行时信息，自动的优化作业的执行，来使得作业更快、更稳定、更易用。这些改进包括，对多分区表进行动态分区裁剪来提高处理效率，根据数据量自动为作业节点设置合适的节点并行度，通过预测执行来发现和缓解慢节点对作业的影响，自动调整数据传输模式来提高资源利用率和处理性能。本次议题，我们将介绍这些改进及其后续改进计划。02《Flink 1.16：Hive SQL 如何平迁到 Flink SQL》【嘉宾介绍】伍翀，花名云邪，Apache Flink PMC member & Committer，Flink CDC 作者。就职于阿里云开源大数据平台，主要负责 Flink CDC、Flink SQL 相关的研发工作，长期以来一直专注于流处理、批处理领域。【演讲简介】流批一体是业界火热的技术方向，Flink 社区也一直引领着这个技术方向，而 Hive 兼容是流批一体中非常重要的一个里程碑。在本次议题中，我们会介绍为了让用户以最低成本地迁移 Hive SQL 作业到 Flink SQL，我们在 Flink 1.16 版本中做的一系列核心改进。我们将 Flink 的 Hive SQL 兼容性从 85% 提升到了 95%，并且引入了 SQLGateway 完全兼容了 HiveServer2 协议，还提升了 Flink Batch 作业稳定性和性能等等。最后我们会通过一个端到端的迁移样例，分享 HiveSQL 作业如何平迁到 FlinkSQL。03《基于Log的通用增量Checkpoint》【嘉宾介绍】俞航翔，Apache Flink Contributer。主要从事 Flink State/Checkpoint 方向的开发和改进【演讲简介】FLIP-158 引入的 Changelog State Backend 可以为用户作业提供更稳定快速的 Checkpoint，进一步提供更快速的 Failover 过程，同时为 Transactional sinks 作业提供更小的端到端延迟。本议题将从 Checkpoint 的发展历程出发，介绍 Changelog State Backend 的基本机制、应用场景和未来规划，同时介绍最新版本在 State 上的一些优化工作。04《基于 Flink CDC + Kafka 加速业务实时化》【嘉宾介绍】任庆盛，Apache Flink Committer，2020 年硕士毕业于卡内基梅隆大学，随后加入阿里云计算平台开源大数据团队【演讲简介】随着 Flink CDC 开源社区的蓬勃发展，Flink CDC 技术在易用性和稳定性方面不断进步，应用到越来越多的业务解决方案中。本议题将分享 Flink CDC 在开源社区和数据集成领域的最新进展，并从实际业务场景出发，针对 Flink CDC 在实时同步数据库数据时的痛点，介绍并演示如何将 Flink CDC 和 Kafka 结合，通过一站式解决方案，解决 Changelog 实时分析场景的诸多难点，为分析业务提供更实时的数据。05《Flink Table Store 典型应用场景》【嘉宾介绍】李劲松，花名之信，目前是 Apache Flink 的 PMC 成员，Apache Iceberg 和 Apache Beam 的 Committer 成员，就职于阿里云开源大数据，负责 Flink Table Store 存储，长期专注于流批一体计算和存储技术。【演讲简介】Flink Table Store 0.2 已经发布，补全了计算的生态，加强和稳定了存储的内核。本次议题主要分享 Flink Table Store 解决了什么问题，有什么典型的应用场景，并且在这些场景中有什么优势。Flink Table Store 作为流批一体在存储，如何在 Streaming Warehouse 中作为存储帮助业务达到更好的业务延时，帮助流计算扩展更多的场景。活动详情时间：9 月 24 日 13:30-18:00地点：北京朝阳区昆泰酒店PC 端直播观看：https://developer.aliyun.com/live/250182移动端建议关注 ApacheFlink 视频号预约观看预约操作：点击参与线下交流近期热点活动报名｜9月23日 实时数仓Workshop · 北京站Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-16
Apache Flink 在小米的稳定性优化和实践
摘要：本文整理自小米大数据部高级软件工程师张蛟在 Flink Forward Asia 2021 生产实践专场的演讲。主要内容包括：发展现状和规模稳定性优化及实践运维优化及实践未来规划与展望点击查看原文视频 & 演讲PPT一、发展现状及规模现阶段，我们的整体架构可以分成5层，数据从下往上流动，如上图。数据采集层主要负责收集各类数据，数据的来源分为两类，一类是埋点和业务日志以及服务日志，经由 LCS Agent 进行采集，另一类是数据库数据经由 Binlog 或 Checkpoint 数据集成等方式收集到消息队列中。以 Flink、Spark 为主的计算层对其进行处理，并最终存储到各类存储和查询服务中，供业务使用。Flink 是计算层实时和准实时处理的主要框架，在其中正发挥着越来越重要的作用，尤其是 Flink+Iceberg 数据湖技术，正在让流批一体成为现实。目前我们的集群上运行着 3000 多个作业，主力版本是 1.12，1.14 版本也已经合并上线，日均处理 10 万亿+ 条消息，PB 级的数据量，峰值数据 2 亿条/秒，运行在国内外 10 多个集群，使用超过 45000 个 CPU core，内存使用超过 200tb。在这样规模的数据处理过程中，我们遇到了许多问题。作业内存占用不可控，on Yarn 模式非常容易出现 Yarn container OOM kill，导致 container lost，引发作业频繁重启，包括框架内重启。on Yarn 模式无法支持作业自动平滑重启，在机器过保、下线、机房迁移等过程中，只能触发 failover。实时作业对负载较为敏感，启动和运行的过程中需要保证机器性能，避免因离线和在线混部造成影响。Checkpoint 作为 Flink 有状态计算数据一致性的保障，存在稳定性问题。historyserver 默认的清理策略不好设置，导致占用的磁盘空间比较大，访问慢。作业异常时难以确定异常原因和节点，需要查看大量的作业日志，导致故障排查困难。二、稳定性优化及实践首先是 Yarn container lost 的优化。Flink JobManager 首先会向 Yarn reCheckpointmanager 申请资源，Yarn reCheckpointmanager 为该申请分配资源后将分配信息返回给 JobManager，然后 JobManager 会根据分配信息去启动 taskmanager，并使之与 JobManager 进行心跳。JobManager 包括 JobMaster 和 reCheckpointmanager，它会主动发送心跳请求，探测 taskmanager 是否存活。如果 taskexecutor 因为某些原因意外被 kill，JobManager 的日志中就会提示 container lost。上图是 container lost 现象的提示之一，一般老版本的 Flink 中出现比较多。上图是 container lost 现象的另一种提示。在出现 container lost 时，如果去查看 Yarn的nodemanager 或 JobManager 中异常前后的日志，一般都可以看到类似 beyond the physical memory limit 的日志，这表明它是因为物理内存使用超限被 Yarn kill。这里需要先介绍一下 Yarn 控制内存超用的方式，Yarn Nodemanager 会启动一个 containersmonitor 的线程，这个线程会定期扫描 Nodemanager 上的 container 内存占用，从而实现内存资源的隔离。简单来说，如果某个 container 对应进程树中所有年龄大于 0 的进程，总内存使用量超过申请量的两倍，或所有年龄大于 1 的进程，总内存使用量超过上限，就表明其内存超用，需要被 kill。但实际上这种方式存在一定的问题：一是定期扫描对于内存突增的隔离性比较差，可能还没有开始扫描就已经达到系统总内存上限，导致被系统 kill；二是 Yarn 通常会开启节点资源的超卖，此时如果所有资源都被使用，会导致节点不稳定；三是如果作业只是临时的内存需求，即使此时节点仍有富余内存，也会触发 kill。针对这些问题，我们采用 Cgroup + JDK升级 + Jemalloc 的方式进行了优化。可能有人会问为什么需要进行 JDK 升级？这是因为老版本的 JDK 使用 Jemalloc 存在线程死锁的问题，另外升级最新的 JDK 也能避免其他的 JDK bug，通常这类 bug 都不容易被找到和复现。Cgroup 的方式主要是开启内存软限制，它对 container 的内存限制不再是基于单个 container 的内存申请量，而是整个 Nodemanager 的内存量。这个时候如果 NodeManager 上仍有富余内存，内存超用的 container 就可以接着使用这些富余的内存。一个节点上同时存在多个 container 内存超用导致整个节点内存达到上限，才会触发 oom event。Oom listener 对该事件进行监听并判断，如果达到节点总内存就会选取内存实际占用量超过申请量且启动时间最短、优先级最低的作业触发 oom kill。 然而，Cgroup 只是在一定程度上解决了 container 频繁被 Yarn oom kill 导致 lost 的问题，并没有完全彻底地解决。在使用的过程中，依然存在某些 container 的内存使用持续上涨，最终被 cgroup oom kill 的情况，然后我们发现该问题可能与 glibc 的内存分配 bug 有关，长期运行的进程会存在连续多块大小为 65536 的 anon 块，所以我们最终的解决方案如下：使用 Cgroup 解决内存临时超用的问题，比如 RocksDB 对内存的限制不严格、小白用户对内存的设置和使用不正确等造成的问题，然后升级 JDK 版本，解决 Jemalloc 分配时的线程死锁 bug，最后切换 Jemalloc，解决 Linux 系统下的 64M anon 分配 bug。经过一系列的优化，从上图可以看出，container lost 的频率由每月的近 5000 次减少到不到 100 次，因 Yarn oom kill 造成的作业异常重启减少了 90% 以上，效果显著。第二个优化实践是节点的平滑重启功能，流式作业是长时间运行的作业，由于大部分都运行在廉价的机器上，因此机器出现过保、硬件故障、维修下线、机房迁移等都比较常见。为了提前预防可能出现的隐患，避免框架重启造成的影响，提升云环境下作业的稳定性，解决 Yarn 模式下恢复时间过长带来的问题，我们开发了作业的平滑重启功能。将节点加入到 exclude 后，Flink recheckpoint manager 会获取到 decommission 的信息，通过解析该信息得到对应的节点，并判断当前运行任务的 container 是否运行在被 decommission 的节点上。如果是，就通过调用任务的 JobManager 的 stop with savepoint 接口去停止。平台会自动检测任务的运行状态，如果某个作业不是通过平台停止，则平台会自动将该任务重新拉起，作业从 savepoint 恢复。这个过程会进行周期性的触发并批量合并后再处理，避免消息频繁触发造成瞬时负载压力。此外，节点和 container 都会进行去重，避免对同一任务多次触发影响稳定性。另外它的触发周期远小于 sre 在下线节点时设置的下线周期，也缓解了运维压力。JobManager 会启动指标收集监控线程，并周期性地采集节点的 CPU、内存、磁盘 io 和网络 io 等指标，然后汇聚成指标集合，通过动态指标规则对指标进行判定，如果满足条件就会将其加入到节点黑名单，这样该 Application 的 container 便不会再运行在这个节点上。如果某个节点被多个 application 加入黑名单，则表明该节点可能存在问题，会自动触发作业平滑重启，并进行监控报警，以此来自动发现可能的异常节点。上图是 Flink Checkpoint 的大致流程，Checkpoint coordinator 会触发 Checkpoint Operator 进行 Checkpoint，Checkpoint Operator 生成并向下游广播 Checkpoint Barrier，然后 Snapshot State。Checkpoint Operator 完成 Checkpoint 后进行 ack，下游节点收到 Checkpoint Barrier 后，根据是否要进行对齐做对应的处理，然后进入 Checkpoint 逻辑。所有的节点都向 Checkpoint Coordinateor ack 之后，表示该次 Checkpoint 已经完成，接着向所有参与 Checkpoint 的 Operator 发送完成通知，最后 Operator 做最后的提交操作等。Checkpoint 过程中遇到的问题包括以下这些：磁盘满或其他 io 异常，会导致 Checkpoint 长期无法触发，但异常信息只存在于 JobManager 的日志中，并不影响作业的正常执行，导致潜在的隐患不容易被感知。作业因逻辑变更、调整并发、重新调度等原因，重启时默认不会从 Checkpoint 恢复，导致状态丢失或者消息积压。大并发度时 Checkpoint 小文件过多，引发大量的 HDFS RPC 负载压力。用户错误配置 Checkpoint 目录引发的恢复冲突非常不容易控制，也不易排查。针对以上问题，我们也进行了一些优化。针对磁盘满、io 异常、Kerberos 文件损坏的问题，我们会捕获异常栈，根据异常栈进行判断和重试，并在失败时增加 Checkpoint 的失败计数，超过一定次数则进行框架内的重启，或向用户发送告警，保证作业不会出现长时间的 Checkpoint 失败而从一个非常老的 Checkpoint 恢复。针对作业重启时无法从 Checkpoint 恢复的问题，优化方式是对每个作业设置默认的保留数量，并在进行 Checkpoint 时先生成一个临时的 Checkpoint Metadata 文件，只有在 Finalize 时才会被 rename 成正式的文件。接着将所有 Checkpoint 文件按最后修改时间降序排序，在其中寻找正式的 Checkpoint Metadata 文件。如果成功则表明其是一个完备的、可用于恢复的 Checkpoint 文件。在这样的设定下，必须确保文件最后修改时间的正确性。为此我们设置了任务 finish 默认不删除 Checkpoint 文件，任务在做 Savepoint 时默认不 discard 最新的 Checkpoint 文件，以确保这两类文件最后修改时间的正确性。通过以上方式保证了任务能自动从最新的、完备的状态进行恢复，需要重新处理的数据和状态尽量少。另外，如果任务已经找到最新的、完备的 Checkpoint 并可以用来恢复，这表明前面的 Savepoint 和 Checkpoint 已经可以清理，由此减少空间的占用。于是我们通过为 Savepoint 设置生命周期来清理全量 Savepoint；对于增量的 Checkpoint，为了避免清除掉正在使用的状态，会先去读取其 Metadata 文件的内容，将其中用到的状态文件对应的父文件夹保留，其余的进行清理，从而确保在不影响状态恢复的前提下，尽量减少文件数和空间占用。针对用户随意配置 Checkpoint 目录导致状态恢复冲突和引发负载压力的问题，通过在 Metadata 文件中增加作业名和时间戳，当前的作业名与存储的作业名不同则会提示告警信息，恢复的 Checkpoint 的时间戳与当前时间存在较大的差异，也会有告警信息。小文件是使用 HDFS 经常遇到的问题，由于 HDFS 适合于存储大块文件，所以必须对小文件进行优化来提升性能和稳定性。方法是在进行 Checkpoint 时对小文件写入进行合并，比如将多个小文件写入到 sequence file 中，形成一个大的文件，这可能会造成空间浪费，但是对降低 HDFS Namenode 负载压力效果比较明显。此外通过联邦集群的方式，使用多个 Namenode 均衡 RPC 请求负载，每一个 Namenode 都是一个相对独立的服务，然后对用户作业规范其 Checkpoint 目录，使其访问能够被均衡到多个 Namenode 上，再对旧的 HDFS 文件通过挂载表的形式读旧写新，逐步实现自动迁移到新的统一的规范目录下。接下来介绍一个案例，该案例来自小米数据采集服务，图示是他们非常简单的架构图，主要是将多个源端 SDK 的埋点和数据收集到消息队列中，然后使用 Flink 进行 ETL，最终存储到 Doris 中并在看板上进行展示。目前该业务已经接入 750+ 国内外业务，日均处理 1600亿+ 条消息。通过采用 Checkpoint 相关的优化手段，将 RPC 延迟降低了约 40%，减少了小文件。同时在作业通过 stop with savepoint 启停时，保证了恢复的正确性，确保了 exactly once 的语义。三、运维优化实践Flink Historyserver 对作业运维非常有效，尤其是它能在作业停止后，查看作业的统计信息，如果作业异常退出或处理结果有问题，我们又因为一些原因无法及时查看相关日志，就可以在将来通过 Historyserver 查看。Flink Historyserver 会在每一次定时清理时获取上一次清理已经被缓存的作业 ID，再获取本次已经打包的历史日志信息，然后判断历史日志是否已经超过了配置的最大值，若是，就会将后面的历史日志直接执行清理，否则就会判断上一次缓存的作业在当次历史日志中是否存在，如果不存在也会执行清理。但上述流程存在一系列的问题，一个是服务重启会造成当前缓存的已下载的作业信息丢失，如果在重启之间该作业的历史日志也丢失，就会形成悬浮的缓存作业，本地缓存的作业将会长期存在，无法清理。当前已打包的历史日志信息不支持过期，导致大量的日志存留于 HDFS 和本地磁盘，且会长期存在，不仅影响访问的速度，也会造成磁盘空间的较大浪费。缓存下来的作业历史日志最大值难以确定，基础服务如 HDFS 等如果出现异常，会导致同时出现大量失败，冲走有效日志。另外当前默认并没有记录 Taskmanager 上的日志，非常不利于异常排查，针对上述问题我们也做了相应优化。一个是读取当前已经缓存到本地磁盘的作业历史日志信息，并将其与历史日志记录进行对比，从而避免出现悬浮的缓存作业；支持历史日志的最长保留时间，超过其生命周期就会进行清理，相比于当前支持的历史日志最大保留数量，更加科学合理；另外我们也支持了 Taskmanager 和 Container 历史数据的打包和清理，更全面地记录作业在异常退出时的各项信息，方便排查问题。作业的全链路心跳监控功能主要是对作业的链路延时进行监控，实现方式是通过在 Stream Checkpoint 中插入特殊标记，标记信息包括作业的名称、当前的时间，名称的生成方式是 op+operator 在整个链路的 index 以及 subtask 在 operator 的 index，非 Checkpoint 节点会在收到标记后更新名称，并用当前的时间减去 Checkpoint 插入的时间生成从 Checkpoint 到该 subtask 的耗时，并上报到 Metrics Reporter 中，最终对这些 metrics 进行计算，通过这种方式可以发现链路中的异常节点，监测作业的数据异常丢失，还能够通过心跳信息的插入频率预估其影响。心跳标记在遇到多个下游链路时并不是随机选择链路，而是同时广播到多条链路中，因此可能会出现心跳监控标记信息过多的情况，影响正常作业的处理性能。这时就出现了一个矛盾点，全链路心跳监控采样越频繁，对各节点处理性能的监控就越及时准确，但同时也会造成信息过多、影响正常数据的处理。针对这个问题，我们进行了以下三个方面的改进和处理：一是将 chain operator metrics 信息进行合并上报，因为它的监控信息基本相同，这样可以减少上报的数据量。二是通过 restful 接口动态启停监控，这样只有在有异常时才会进行采样和监控，正常情况下不影响作业的运行。三是通过对采样进行周期性的合并和处理，实现了对任务 pipeline 数据量和延迟的预估以及监控功能。restful 接口动态启停监控功能不仅能动态启停心跳监控，我们发现还有其他场景也能从这个功能中受益，因此我们对其进行了扩展。简单的代码修改就能让它支持其他配置的动态调整，包括 Checkpoint 配置，如 Checkpoint 周期和超时时间，动态日志的级别等。当作业出现性能或 Checkpoint 问题时，可以通过 restful 接口动态开启、问题确定后动态停止，这样就能解决心跳信息过多的问题。在负载突增、短时数据倾斜导致 Checkpoint 超时，动态调整 Checkpoint 超时时间能避免作业因 Checkpoint 超时而失败，它也能避免由于 Checkpoint 长时间不成功导致数据积压更多、数据倾斜问题更严重而陷入的死循环。同时它还能用于确定超时时间，用户可以通过动态调整的方式，不断测试最适合作业的超时时间，减少了压测过程中的作业启停次数。它也支持其他配置的调整，比如动态调整日志级别，但是需要注意的是调整后的配置并没有持久化，会因为框架重启或作业的重启而失效。四、未来规划未来，我们将在以下方面继续探索：持续开发并优化自动弹性伸缩容的功能。Flink1.13 开始提供了自动弹性伸缩容的功能，但是目前并不完善，要在生产环境上用起来还需要做不少的工作。版本收敛是很多Flink开发人员都会遇到的一个问题。Flink 社区的发展比较快，版本的发布和迭代也是非常快。为了降低运维压力，紧跟社区，这也是势在必行的。对 state 读写性能进行优化，提升大状态作业的性能。Heartbeat timeout 也是目前线上对稳定性影响比较大的问题，我们也会进行跟进和优化。对作业启动和恢复性能进行优化，减少作业因各种原因造成的断流是 Flink 社区和许多业务非常关注的问题，我们同样也有面临着这样的压力。继续打磨批流融合能力，完善对 batch 模式和数据湖等的支持，也是现在的热点，我们希望能在这上面进行更多探索，从而更好地支撑业务，也让 Flink 的应用更加广泛。点击查看原文视频 & 演讲PPT近期热点活动报名｜9月23日 实时数仓Workshop · 北京站Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-08
活动报名｜9月23日 实时数仓Workshop · 北京站
点击参与线下交流随着数字化业务的增长，企业的数据量呈现爆发式增长，数据仓库已经成为企业数据发展到一定规模后必然提供的基础服务之一。数据的时效性，成为数据仓库建设中必不可少的一环，企业最常做的就是通过实时数仓建设，满足对数据的快速探索。在实际业务中，实时数仓需要支持数据实时写入与更新、业务敏捷快速响应、数据自助分析、运维操作便捷、云原生弹性扩缩容等一列需求，而这就依赖一款强大的实时数仓引擎。阿里云实时计算 Flink 版作为一款大数据流式计算引擎，提供全增量一体化数据同步技术、强大的流式 ETL 等能力，支持海量数据实时写入处理；新一代实时数仓引擎阿里云 Hologres 能同时解决 OLAP 多维分析、在线服务、离线数据加速等多个业务查询场景。通过阿里云实时计算 Flink 版与阿里云 Hologres 的强强结合，实现全链路的数据探索实时化、数据分析敏捷化，快速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。9月23日，实时数仓Workshop · 北京站将聚焦 Flink&Hologres 实时数仓在数据链路中扮演的角色与在智能商业中的重要价值，由业内各界的实时数仓实践者一同探讨实时计算未来趋势、开源生态发展、实时数仓场景在各行业中的实践与应用及平台智能化的探索与思考。嘉宾及议题介绍01《Flink X Hologres构建企业级一站式实时数仓》刘一鸣｜阿里云高级产品专家随着实时数仓的普及，在线化、一站式、敏捷化成为实时数仓新的发展趋势，阿里云Hologres支持高吞吐写入与更新、PB级数据秒级查询以及高并发的在线服务查询，兼容PG生态，与Flink深度融合，解决传统数仓加工链路长、数据出口多、数据更新难等问题，提供一站式实时数仓标准解决方案，加速企业实时数仓建设。02《淘菜菜 - 基于Flink和Hologres的高可用实时数仓架构升级之路》汪宇｜阿里巴巴淘菜菜事业部数据技术专家阿里淘菜菜（简称TCC）主营社区团购，为了更好支持业务发展，在不断演进其技术架构。2020年开始与Hologres合作，历经2次大的架构升级，从传统多组件的架构升级为现在稳定的高可用实时数仓2.0，承载上千万RPS写入、几百T数据存储、秒级查询响应及提供稳定高可用的服务能力。主要介绍淘菜菜基于Flink+Hologres搭建实时数仓的最佳实践，内容主要包括高可用实时架构方案、场景实践以及成本治理等。03《预计算技术+Hologres在阿里采集流量分析产品中的实践》康凯｜阿里巴巴技术专家阿里采集流量分析是阿里集团统一的全域流量数据分析平台。提供实时、离线数据分析，构建宏观概览数据、坑位点击分布、路径分析、成交转化、用户细分等流量数据分析闭环，帮助业务掌握流量现状、定位流量问题和提升流量转化。本次议题主要介绍基于AQP、Bitmap、预计算等技术，并结合Hologres，支撑业务查询响应时间降低至秒级、毫秒级，满足集团内各业务快速了解、分析、决策业务的目的。04《阿里妈妈Dolphin智能计算引擎基于Flink+Hologres实践》徐闻春｜阿里巴巴技术专家Dolphin智能计算引擎是支撑阿里妈妈百万商家的AI一体化超融合引擎，提供OLAP分析、AI在线计算、实时特征和批量计算等能力，服务于人群圈选、洞察分析、人群定向以及营销推荐场景，帮助广告主投放更精准，提升投放效果。本次议题主要介绍基于Flink+Hologres技术构建的Dolphin引擎在广告场景上的最佳实践。05《阿里云实时计算Flink版产品介绍与演示》乐洋｜阿里云高级产品专家围绕Flink的相关场景，包括调优、运维、开发等，以及实时数仓相关解决方案。06《从ELK到EFK——结合Flink和Elasticsearch新特性重构全观测方案》朱杰｜Elastic 资深解决方案架构师赵弘扬｜阿里云高级产品专家近几年，随着IT架构逐步向云的衍进，传统的IT运维、日志/指标监控与分析、安全分析等手段，也逐渐从独立的日志、指标、分布式追踪系统迈向云上统一和融合的全观测平台。“开源云服务”和“全观测”这两个近期在国内非常时兴的概念，相结合会碰撞出什么样的火花？如何基于云上的海量存储能力、计算能力，处理企业IT架构所面临的数据量大、数据预处理量大、链路时效性要求高和告警任务复杂高频等艰巨的问题？本次分享的内容将为大家介绍并分析：阿里云上的Elasticsearch和Flink服务，是如何高效、低成本地解决上述问题，实现全观测降本增效的目标。活动详情线下时间：2022年9月23日 13:30-18:00 地点：北京市朝阳区望京昆泰酒店线上时间：2022年9月24日 9:00-12:00PC 端：https://developer.aliyun.com/live/250170移动端建议关注 ApacheFlink 视频号预约观看预约操作：点击参与线下交流近期热点活动报名｜9月24日 Apache Flink Meetup · 北京站，Flink 1.16 新版本发布！Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-08
Apache Flink Table Store 0.2.0 发布
作者｜Jingsong Lee jingsonglee0@gmail.comApache Flink 社区很高兴地宣布发布 Apache Flink Table Store 0.2.0。在这个版本中，增加了 Hive、Spark 和 Trino 等计算引擎的对接支持，并且稳定了存储的格式。欢迎大家试用和反馈！Flink Table Store 仓库地址：https://github.com/apache/flink-table-store项目文档和用户指南请查看：https://nightlies.apache.org/flink/flink-table-store-docs-release-0.2/Flink Table Store 是什么Flink Table Store是一个数据湖存储，用于实时流式 Changelog 摄取 (比如来自 Flink CDC 的数据) 和高性能查询。作为一种新型的可更新数据湖，Flink Table Store 具有以下特点：大吞吐量的更新数据摄取，同时提供良好的查询性能。具有主键过滤器的高性能查询，响应时间最快可达到百毫秒级别。流式读取在 Lake Storage 上可用，Lake Storage 还可以与 Kafka 集成，以提供毫秒级流式读取。功能在这个版本中，我们完成了许多令人兴奋的功能。Catalog此版本引入了 Table Store 自己的 Catalog，在 Catalog 下创建的表，持久化保存表信息等元数据，可以跨 session 访问存量表。默认情况下元数据都保存在 DFS 上。也支持配置 Hive Metastore 的自动同步。CREATE CATALOG tablestore WITH ( 'type'='table-store', 'warehouse'='hdfs://nn:8020/warehouse/path', -- optional hive metastore 'metastore'='hive', 'uri'='thrift://<hive-metastore-host-name>:<port>' ); USE CATALOG tablestore; CREATE TABLE my_table ...当开启 Hive Metastore 时，你可以比较方便的使用 Hive 引擎来查询 Flink Table Store。生态在本版本中，我们不仅支持 Flink 1.15，也支持了 Flink 1.14，并为多个计算引擎提供读取支持。我们会保持 Flink 引擎和 Flink Table Store 的全面结合，构建完整的流批一体计算和存储的流式数仓。此外，Flink Table Store 也支持了更多的计算引擎，包括 Hive/Spark/Trino 等，从而可以兼容更多的生态，便于在现有生产环境中使用。如果你有关于生态的需求和想法，比如想让 Spark 或 Hive 支持写入 Flink Table Store，欢迎通过扫描文末的二维码入群交流，或者在 Flink 社区创建 issue 进行讨论。Append-only 表Append-only 表功能是一种性能改进，只接受 INSERT_ONLY 的数据以 Append 到存储，而不是更新或删除现有数据，适用于不需要更新的用例（如日志数据同步）。CREATE TABLE my_table ( ... ) WITH ( 'write-mode' = 'append-only', ... )流式写入 Append-only 表也具有异步 Compaction，从而不需要担心小文件问题。Bucket 扩缩容单个 Bucket 内是一个单独的 LSM 结构，Bucket 的数量会影响性能：过小的 Bucket 数量会导致写入作业有瓶颈，吞吐跟不上写入速度。过大的 Bucket 数量会导致有大量小文件，且影响查询速度。Flink Table Store 允许用户通过 ALTER TABLE 命令调整存储桶数量，并通过 INSERT OVERWRITE 重新组织必要的分区，旧分区保持不变。性能测试在以下的模块里，我们创建了关于流计算更新和查询的 Benchmark：https://github.com/apache/flink-table-store/tree/master/flink-table-store-benchmark更新性能和查询性能是互相权衡的，所以在性能测试中不能单独衡量更新性能或者查询性能。如果只考虑查询性能，那么 Copy On Write (COW) 是最适合的技术方案，但这种设计下更新时会覆写所有数据，因此是以牺牲更新性能为代价的。如果只考虑更新性能，那么 Merge On Read (MOR) 是最适合的技术方案，但这种设计下会在读取时对数据进行合并，从而影响查询的性能。Flink Table Store 目前只支持 MOR 模式，但通过 Data Skipping 等技术对查询性能做了优化。下面对比了 Flink Table Store 和 Hudi MOR、Hudi COW，在实时更新场景的写入（包含插入和更新）与查询性能。目前湖存储中，只有 Hudi 比较好的支持了流更新写入，而 Iceberg 和 Delta 更适合使用批 SQL 的 MERGE INTO 来完成更新，所以这里只对比了 Hudi。测试方法：通过 Flink SQL 向定义了主键的表里写入定量的随机数据，测量耗时以及平均的 Cpu 消耗，以此衡量存储的更新性能。通过 Spark SQL 查询写好数据的表，测量三种 Query：查询全部数据、查询主键的某个范围、点查某个主键，以此衡量存储的查询性能。测试用例：总量：数据总条数 5 亿条。主键：随机的数据，随机范围是 1 亿。大小：每条数据大概 150 字节。此测试用例比较简单，如有需要可以利用 benchmark 构建更复杂的用例来贴合自己的生产场景。测试环境：Flink 版本: 1.14.5Spark 版本：3.2.2Flink Table Store 版本: 0.2.0Hudi 版本：0.11.1集群：三台物理机的 Hadoop 集群Flink 集群参数：Spark 集群参数：Flink Table Store 参数：Hudi 参数：写入性能 (throughput / core)：查询性能 (秒) (Flink Table Store vs Hudi MOR)：查询性能 (秒) (Flink Table Store vs Hudi COW)：结论，面向此测试用例：Flink Table Store 对比 Merge On Read 有着比较好的更新性能和查询性能。Flink Table Store 对比 Copy On Write 有着比较好的更新性能，但是查询所有数据不如 COW，Flink Table Store 是一个 Merge On Read 的技术，有 Merge 的开销，但是 Merge 的效率非常高。Flink Table Store 因为保持了有序性，直接查询表可以有很好的 Data Skipping，点查甚至可以达到 100ms 以内的延迟。如果你有任何关于 Benchmark 的想法，请与我们联系。如果有你感兴趣的场景，可以添加用例到 benchmark 项目中。下一步在即将发布的 0.3.0 版本中，您可以期待以下功能：Lookup：支持 Flink Dim Lookup Join。(即将来临)并发更新：多个 Flink 作业写入同一张 Flink Table Store 表。Compaction分离：单独的任务完成Compaction。物化视图：Flink Table Store 提供预聚合模型。变更日志生成：为各种 MergeEngine 生成准确的变更日志。多引擎的写支持：支持 Spark、Hive 写入 Flink Table Store。Flink Table Store 长期目标是满足批流一体对存储的所有要求，并构建实时低成本的 Streaming Data Warehouse。如果您有业务上需求，请联系我们！交流钉钉交流群如下，欢迎大家来交流存储相关的想法。近期热点实时数仓Workshop · 广州站 9.15 邀您参加！Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-09-02
技术解析｜Doris Connector 结合 Flink CDC 实现 MySQL 分库分表 Exactly Once 精准接入
本篇文档将演示如何使用 Apache Doris Flink Connector 结合 Flink CDC 以及 Doris Stream Load 的两阶段提交，实现 MySQL 数据库分库分表实时高效接入，并实现 Exactly Once。一、概述在实际业务系统中为了解决单表数据量大带来的各种问题，我们通常采用分库分表的方式对库表进行拆分，以达到提高系统的吞吐量。但是这样给后面数据分析带来了麻烦，这个时候我们通常试将业务数据库的分库分表同步到数据仓库时，将这些分库分表的数据合并成一个库、一个表，便于我们后面的数据分析。本篇文档我们将演示如何基于 Flink CDC 结合 Apache Doris Flink Connector 及 Doris Stream Load 的两阶段提交，实现 MySQL 数据库分库分表实时高效的接入到 Doris 数据仓库中进行分析。1.1 什么是 CDCCDC 是 Change Data Capture 变更数据获取的简称。核心思想是，监测并捕获数据库的变动（包括数据或数据表的插入 INSERT、更新 UPDATE、删除 DELETE 等），将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。CDC 技术应用场景也非常广泛，包括：数据分发：将一个数据源分发给多个下游，常用于业务解耦、微服务。数据集成：将分散异构的数据源集成到数据仓库中，消除数据孤岛，便于后续的分析。数据迁移：常用于数据库备份、容灾等。1.2 为什么选择 Flink CDCFlink CDC 基于数据库日志的 Change Data Capture 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 、Oceanbase、TiDB、SQLServer 等数据库。Flink CDC 的下游则更加丰富，支持写入 Kafka、Pulsar 消息队列，也支持写入 Hudi、Iceberg 、Doris 等，支持写入各种数据仓库及数据湖中。同时，通过 Flink SQL 原生支持的 Changelog 机制，可以让 CDC 数据的加工变得非常简单。用户通过 SQL 便能实现数据库全量和增量数据的清洗、打宽、聚合等操作，极大地降低了用户门槛。此外， Flink DataStream API 支持用户编写代码实现自定义逻辑，给用户提供了深度定制业务的自由度。Flink CDC 技术的核心是支持将表中的全量数据和增量数据做实时一致性的同步与加工，让用户可以方便地获每张表的实时一致性快照。比如一张表中有历史的全量业务数据，也有增量的业务数据在源源不断写入、更新。Flink CDC 会实时抓取增量的更新记录，实时提供与数据库中一致性的快照，如果是更新记录，会更新已有数据；如果是插入记录，则会追加到已有数据，整个过程中，Flink CDC 提供了一致性保障，即不重不丢。Flink CDC 具有如下优势：Flink 的算子和 SQL 模块更为成熟和易用；Flink 作业可以通过调整算子并行度的方式轻松扩展处理能力；Flink 支持高级的状态后端（State Backends），允许存取海量的状态数据；Flink 提供更多的 Source 和 Sink 等生态支持；Flink 有更大的用户基数和活跃的支持社群，问题更容易解决。而且 Flink Table / SQL 模块将数据库表和变动记录流（例如 CDC 的数据流）看做是同一事物的两面，因此内部提供的 Upsert 消息结构（+I表示新增、-U表示记录更新前的值、+U表示记录更新后的值，-D表示删除）可以与 Debezium 等生成的变动记录一一对应。1.3 什么是 Apache DorisApache Doris 是一个现代化的 MPP 分析型数据库产品。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris 的分布式架构非常简洁，易于运维，并且可以支持 10PB 以上的超大数据集。Apache Doris 可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。可以使数据分析工作更加简单高效！1.4 Two-phase commit什么是 Two-phase commit（2PC）在分布式系统中，为了让每个节点都能够感知到其他节点的事务执行状况，需要引入一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协调者（Coordinator），被中心节点调度的其他业务节点叫做参与者（Participant）。2PC 将分布式事务分成了两个阶段，两个阶段分别为提交请求（投票）和提交（执行）。协调者根据参与者的响应来决定是否需要真正地执行事务，具体流程如下：提交请求（投票）阶段协调者向所有参与者发送 prepare 请求与事务内容，询问是否可以准备事务提交，并等待参与者的响应。参与者执行事务中包含的操作，并记录 undo 日志（用于回滚）和 redo 日志（用于重放），但不真正提交。参与者向协调者返回事务操作的执行结果，执行成功返回 yes，否则返回 no。提交（执行）阶段分为成功与失败两种情况。若所有参与者都返回 yes，说明事务可以提交：协调者向所有参与者发送 Commit 请求。参与者收到 Commit 请求后，将事务真正地提交上去，并释放占用的事务资源，并向协调者返回 Ack。协调者收到所有参与者的 Ack 消息，事务成功完成。若有参与者返回 no 或者超时未返回，说明事务中断，需要回滚：协调者向所有参与者发送 Rollback 请求。参与者收到 Rollback 请求后，根据 undo 日志回滚到事务执行前的状态，释放占用的事务资源，并向协调者返回 Ack。协调者收到所有参与者的 Ack 消息，事务回滚完成。1.5 Flink 2PCFlink 作为流式处理引擎，自然也提供了对 Exactly Once 语义的保证。端到端的 Exactly Once 语义，是输入、处理逻辑、输出三部分协同作用的结果。Flink 内部依托检查点机制和轻量级分布式快照算法 ABS 保证 Exactly Once。而要实现精确一次的输出逻辑，则需要施加以下两种限制之一：幂等性写入（idempotent write）、事务性写入（transactional write）。预提交阶段的流程每当需要做 Checkpoint 时，JobManager 就在数据流中打入一个屏障（barrier），作为检查点的界限。屏障随着算子链向下游传递，每到达一个算子都会触发将状态快照写入状态后端的动作。当屏障到达 Kafka sink 后，通过 KafkaProducer.flush() 方法刷写消息数据，但还未真正提交。接下来还是需要通过检查点来触发提交阶段：提交阶段流程只有在所有检查点都成功完成这个前提下，写入才会成功。这符合前文所述 2PC 的流程，其中 JobManager 为协调者，各个算子为参与者（不过只有 Sink 一个参与者会执行提交）。一旦有检查点失败，notifyCheckpointComplete() 方法就不会执行。如果重试也不成功的话，最终会调用 abort() 方法回滚事务。1.6 Doris Stream Load 2PC1.6.1 Stream LoadStream Load 是 Apache Doris 提供的一个同步的导入方式，用户通过发送 HTTP 协议发送请求将本地文件或数据流导入到 Doris 中。Stream Load 同步执行导入并返回导入结果。用户可直接通过请求的返回体判断本次导入是否成功。Stream Load 主要适用于导入本地文件，或通过程序导入数据流中的数据。使用方法：用户通过Http Client 进行操作，也可以使用 Curl 命令进行curl --location-trusted -u user:passwd [-H ""...] -T data.file -H "label:label" -XPUT http://fe_host:http_port/api/{db}/{table}/_stream_load这里为了是防止用户重复导入相同的数据，使用了导入任务标识 Label。强烈推荐用户同一批次数据使用相同的 Label。这样同一批次数据的重复请求只会被接受一次，保证了 At-Most-Once。1.6.2 Stream Load 2PCAapche Doris 最早的 Stream Load 是没有两阶段提交的，导入数据的时候直接通过 Stream Load 的 HTTP 接口完成数据导入，只有成功和失败。这种在正常情况下是没有问题的，在分布式环境下可能为因为某一个导入任务是失败导致两端数据不一致的情况，特别是在 Doris Flink Connector 里，之前的 Doris Flink Connector 数据导入失败需要用户自己控制，做异常处理，如果导入失败之后，将数据保存到指定的地方（例如 Kafka），然后手动处理。如果 Flink Job 因为其他问题突然挂掉，这样会造成部分数据成功、部分数据失败，而且失败的数据因为没有 Checkpoint，重新启动 Job 也没办法重新消费失败的数据，造成两端数据不一致。为了解决上面的这些问题，保证两端数据一致性，我们实现了 Doris Stream Load 2PC，原理如下:提交分成两个阶段第一阶段，提交数据写入任务，这个时候数据写入成功后，数据状态是不可见的，事务状态是 PRECOMMITTED数据写入成功之后，用户触发 Commit 操作，将事务状态变成 VISIBLE，这个时候数据可以查询到如果用户要方式这一批数据只需要通过事务 ID，对事务触发 Abort 操作，这批数据将会被自动删除掉1.6.3 Stream Load 2PC 使用方式在 be.conf 中配置 disable_stream_load_2pc=false（重启生效）并且 在 HEADER 中声明 two_phase_commit=true发起预提交：curl --location-trusted -u user:passwd -H "two_phase_commit:true" -T test.txt http://fe_host:http_port/api/{db}/{table}/_stream_load触发事务 Commit 操作：curl -X PUT --location-trusted -u user:passwd -H "txn_id:18036" -H "txn_operation:commit" http://fe_host:http_port/api/{db}/_stream_load_2pc对事物触发 abort 操作：curl -X PUT --location-trusted -u user:passwd -H "txn_id:18037" -H "txn_operation:abort" http://fe_host:http_port/api/{db}/_stream_load_2pc1.7 Doris Flink Connector 2PC我们之前提供了 Doris Flink Connector ，支持对 Doris 表数据的读，Upsert、Delete（Unique key 模型），但是存在可能因为 Job 失败或者其他异常情况导致两端数据不一致的问题。为了解决这些问题，我们基于 FLink 2PC 和 Doris Stream Load 2PC 对 Doris Connector 进行了改造升级，保证两端 Exactly Once。我们会在内存中维护读写的 Buffer，在启动的时候，开启写入，并异步的提交，期间通过 HTTP Chunked 的方式持续的将数据写入到 BE，直到 Checkpoint 的时候，停止写入，这样做的好处是避免用户频繁提交 HTTP 带来的开销，Checkpoint 完成后会开启下一阶段的写入。在这个 Checkpoint 期间，可能是多个 Task 任务同时在写一张表的数据，这些我们都会在这个 Checkpoint 期间对应一个全局的 Label，在 Checkpoint 的时候将这个 Label 对应的写入数据的事务进行统一的一次提交，将数据状态变成可见。如果失败 Flink 在重启的时候会对这些数据通过 Checkpoint 进行回放。这样就可以保证 Doris 两端数据的一致。二、系统架构下面我们通过一个完整示例来看怎么去通过 Doris Flink Connector 最新版本（支持两阶段提交），来完成整合 Flink CDC 实现 MySQL 分库分表实时采集入库。这里通过 Flink CDC 完成 MySQL 分库分表数据采集。然后通过 Doris Flink Connector 来完成数据的入库。最后利用 Doris 的高并发、高性能的OLAP分析计算能力对外提供数据服务。三、MySQL 安装配置3.1 安装 MySQL快速使用 Docker 安装配置 MySQL，具体参照下面的连接：https://segmentfault.com/a/11900000215235703.2 开启 MySQL Binlog进入 Docker 容器修改 /etc/my.cnf 文件，在 [mysqld] 下面添加以下内容：log_bin=mysql_bin binlog-format=Row server-id=1然后重启 MySQLsystemctl restart mysqld3.3 准备数据这里演示我们准备了两个库 emp_1和emp_2, 每个库下面主备了两张表 employees_1，employees_2。并给出了一下初始化数据：CREATE DATABASE emp_1; USE emp_1; CREATE TABLE employees_1 ( emp_no INT NOT NULL, birth_date DATE NOT NULL, first_name VARCHAR(14) NOT NULL, last_name VARCHAR(16) NOT NULL, gender ENUM ('M','F') NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no) ); INSERT INTO `employees_1` VALUES (10001,'1953-09-02','Georgi','Facello','M','1986-06-26'), (10002,'1964-06-02','Bezalel','Simmel','F','1985-11-21'), (10003,'1959-12-03','Parto','Bamford','M','1986-08-28'), (10004,'1954-05-01','Chirstian','Koblick','M','1986-12-01'), (10005,'1955-01-21','Kyoichi','Maliniak','M','1989-09-12'), (10006,'1953-04-20','Anneke','Preusig','F','1989-06-02'), (10007,'1957-05-23','Tzvetan','Zielinski','F','1989-02-10'), (10008,'1958-02-19','Saniya','Kalloufi','M','1994-09-15'), (10009,'1952-04-19','Sumant','Peac','F','1985-02-18'), (10010,'1963-06-01','Duangkaew','Piveteau','F','1989-08-24'); CREATE TABLE employees_2 ( emp_no INT NOT NULL, birth_date DATE NOT NULL, first_name VARCHAR(14) NOT NULL, last_name VARCHAR(16) NOT NULL, gender ENUM ('M','F') NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no) ); INSERT INTO `employees_2` VALUES (10037,'1963-07-22','Pradeep','Makrucki','M','1990-12-05'), (10038,'1960-07-20','Huan','Lortz','M','1989-09-20'), (10039,'1959-10-01','Alejandro','Brender','M','1988-01-19'), (10040,'1959-09-13','Weiyi','Meriste','F','1993-02-14'), (10041,'1959-08-27','Uri','Lenart','F','1989-11-12'), (10042,'1956-02-26','Magy','Stamatiou','F','1993-03-21'), (10043,'1960-09-19','Yishay','Tzvieli','M','1990-10-20'), (10044,'1961-09-21','Mingsen','Casley','F','1994-05-21'), (10045,'1957-08-14','Moss','Shanbhogue','M','1989-09-02'), (10046,'1960-07-23','Lucien','Rosenbaum','M','1992-06-20'); CREATE DATABASE emp_2; USE emp_2; CREATE TABLE employees_1 ( emp_no INT NOT NULL, birth_date DATE NOT NULL, first_name VARCHAR(14) NOT NULL, last_name VARCHAR(16) NOT NULL, gender ENUM ('M','F') NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no) ); INSERT INTO `employees_1` VALUES (10055,'1956-06-06','Georgy','Dredge','M','1992-04-27'), (10056,'1961-09-01','Brendon','Bernini','F','1990-02-01'), (10057,'1954-05-30','Ebbe','Callaway','F','1992-01-15'), (10058,'1954-10-01','Berhard','McFarlin','M','1987-04-13'), (10059,'1953-09-19','Alejandro','McAlpine','F','1991-06-26'), (10060,'1961-10-15','Breannda','Billingsley','M','1987-11-02'), (10061,'1962-10-19','Tse','Herber','M','1985-09-17'), (10062,'1961-11-02','Anoosh','Peyn','M','1991-08-30'), (10063,'1952-08-06','Gino','Leonhardt','F','1989-04-08'), (10064,'1959-04-07','Udi','Jansch','M','1985-11-20'); CREATE TABLE employees_2( emp_no INT NOT NULL, birth_date DATE NOT NULL, first_name VARCHAR(14) NOT NULL, last_name VARCHAR(16) NOT NULL, gender ENUM ('M','F') NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no) ); INSERT INTO `employees_1` VALUES (10085,'1962-11-07','Kenroku','Malabarba','M','1994-04-09'), (10086,'1962-11-19','Somnath','Foote','M','1990-02-16'), (10087,'1959-07-23','Xinglin','Eugenio','F','1986-09-08'), (10088,'1954-02-25','Jungsoon','Syrzycki','F','1988-09-02'), (10089,'1963-03-21','Sudharsan','Flasterstein','F','1986-08-12'), (10090,'1961-05-30','Kendra','Hofting','M','1986-03-14'), (10091,'1955-10-04','Amabile','Gomatam','M','1992-11-18'), (10092,'1964-10-18','Valdiodio','Niizuma','F','1989-09-22'), (10093,'1964-06-11','Sailaja','Desikan','M','1996-11-05'), (10094,'1957-05-25','Arumugam','Ossenbruggen','F','1987-04-18');四、Doris 安装配置这里我们以单机版为例：首先下载 Doris 1.1 release版本：https://doris.apache.org/downloads/downloads.html解压到指定目录：tar zxvf apache-doris-1.1.0-bin.tar.gz -C doris-1.1解压到目录结构是这样的：. ├── apache_hdfs_broker │ ├── bin │ ├── conf │ └── lib ├── be │ ├── bin │ ├── conf │ ├── lib │ ├── log │ ├── minidump │ ├── storage │ └── www ├── derby.log ├── fe │ ├── bin │ ├── conf │ ├── doris-meta │ ├── lib │ ├── log │ ├── plugins │ ├── spark-dpp │ ├── temp_dir │ └── webroot └── udf ├── include └── lib配置 FE 和 BE：cd doris-1.0 # 配置 fe.conf 和 be.conf,这两个文件分别在fe和be的conf目录下 打开这个 priority_networks 修改成自己的IP地址，注意这里是CIDR方式配置IP地址 例如我本地的IP是172.19.0.12，我的配置如下： priority_networks = 172.19.0.0/24 ###### 在be.conf配置文件最后加上下面这个配置 disable_stream_load_2pc=false注意这里默认只需要修改 fe.conf 和 be.conf 同样的上面配置就可以。默认 FE 元数据的目录在 fe/doris-meta 目录下。BE 的数据存储在 be/storage 目录下。启动 FE：sh fe/bin/start_fe.sh --daemon启动 BE：sh be/bin/start_be.sh --daemonMySQL 命令行连接 FE，这里新安装的 Doris 集群默认用户是 Root 和 Admin，密码是空：mysql -uroot -P9030 -h127.0.0.1 Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 41 Server version: 5.7.37 Doris version trunk-440ad03 Copyright (c) 2000, 2022, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show frontends; +--------------------------------+-------------+-------------+----------+-----------+---------+----------+----------+------------+------+-------+-------------------+---------------------+----------+--------+---------------+------------------+ | Name | IP | EditLogPort | HttpPort | QueryPort | RpcPort | Role | IsMaster | ClusterId | Join | Alive | ReplayedJournalId | LastHeartbeat | IsHelper | ErrMsg | Version | CurrentConnected | +--------------------------------+-------------+-------------+----------+-----------+---------+----------+----------+------------+------+-------+-------------------+---------------------+----------+--------+---------------+------------------+ | 172.19.0.12_9010_1654681464955 | 172.19.0.12 | 9010 | 8030 | 9030 | 9020 | FOLLOWER | true | 1690644599 | true | true | 381106 | 2022-06-22 18:13:34 | true | | trunk-440ad03 | Yes | +--------------------------------+-------------+-------------+----------+-----------+---------+----------+----------+------------+------+-------+-------------------+---------------------+----------+--------+---------------+------------------+ 1 row in set (0.01 sec)将BE节点加入到集群中：mysql>alter system add backend "172.19.0.12:9050";这里是你自己的IP地址查看BE：mysql> show backends; +-----------+-----------------+-------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------------------------+--------+---------------+-------------------------------------------------------------------------------------------------------------------------------+ | BackendId | Cluster | IP | HeartbeatPort | BePort | HttpPort | BrpcPort | LastStartTime | LastHeartbeat | Alive | SystemDecommissioned | ClusterDecommissioned | TabletNum | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | MaxDiskUsedPct | Tag | ErrMsg | Version | Status | +-----------+-----------------+-------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------------------------+--------+---------------+-------------------------------------------------------------------------------------------------------------------------------+ | 10002 | default_cluster | 172.19.0.12 | 9050 | 9060 | 8040 | 8060 | 2022-06-22 12:51:58 | 2022-06-22 18:15:34 | true | false | false | 4369 | 328.686 MB | 144.083 GB | 196.735 GB | 26.76 % | 26.76 % | {"location" : "default"} | | trunk-440ad03 | {"lastSuccessReportTabletsTime":"2022-06-22 18:15:05","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false} | +-----------+-----------------+-------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------------------------+--------+---------------+-------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)Doris 单机版安装完成。五、Flink 安装配置5.1 下载安装 Flink 1.14.4wget https://dlcdn.apache.org/flink/flink-1.14.4/flink-1.14.5-bin-scala_2.12.tgz tar zxvf flink-1.14.4-bin-scala_2.12.tgz需要将下面的依赖拷贝到 Flink 安装目录下的 lib 目录下，具体的依赖的 lib 文件如下：wget https://jiafeng-1308700295.cos.ap-hongkong.myqcloud.com/flink-doris-connector-1.14_2.12-1.0.0-SNAPSHOT.jar wget https://repo1.maven.org/maven2/com/ververica/flink-sql-connector-mysql-cdc/2.2.1/flink-sql-connector-mysql-cdc-2.2.1.jar启动 Flink：bin/start-cluster.sh启动后的界面如下：六、开始同步数据到 Doris6.1 创建 Doris 数据库及表create database demo; use demo; CREATE TABLE all_employees_info ( emp_no int NOT NULL, birth_date date, first_name varchar(20), last_name varchar(20), gender char(2), hire_date date, database_name varchar(50), table_name varchar(200) ) UNIQUE KEY(`emp_no`, `birth_date`) DISTRIBUTED BY HASH(`birth_date`) BUCKETS 1 PROPERTIES ( "replication_allocation" = "tag.location.default: 1" );6.2 进入 Flink SQL Client bin/sql-client.sh embedded 开启 Checkpoint，每隔 10 秒做一次 CheckpointCheckpoint 默认是不开启的，我们需要开启 Checkpoint 提交事务。Source 在启动时会扫描全表，将表按照主键分成多个 Chunk。并使用增量快照算法逐个读取每个 Chunk 的数据。作业会周期性执行 Checkpoint，记录下已经完成的 Chunk。当发生 Failover 时，只需要继续读取未完成的 Chunk。当 Chunk 全部读取完后，会从之前获取的 Binlog 位点读取增量的变更记录。Flink 作业会继续周期性执行 Checkpoint，记录下 Binlog 位点，当作业发生 Failover，便会从之前记录的 Binlog 位点继续处理，从而实现 Exactly Once 语义。SET execution.checkpointing.interval = 10s;注意：这里是演示，生产环境建议 Checkpoint 间隔 60 秒。6.3 创建 MySQL CDC 表在 Flink SQL Client 下执行下面的 SQLCREATE TABLE employees_source ( database_name STRING METADATA VIRTUAL, table_name STRING METADATA VIRTUAL, emp_no int NOT NULL, birth_date date, first_name STRING, last_name STRING, gender STRING, hire_date date, PRIMARY KEY (`emp_no`) NOT ENFORCED ) WITH ( 'connector' = 'mysql-cdc', 'hostname' = 'localhost', 'port' = '3306', 'username' = 'root', 'password' = 'MyNewPass4!', 'database-name' = 'emp_[0-9]+', 'table-name' = 'employees_[0-9]+' );'database-name' = 'emp_[0-9]+'：这里是使用了正则表达式，同时连接多个库'table-name' = 'employees_[0-9]+'：这里是使用了正则表达式，同时连接多个表查询 CDC 表，我们可以看到下面的数据，标识一切正常select * from employees_source limit 10;6.4 创建 Doris Sink 表CREATE TABLE cdc_doris_sink ( emp_no int , birth_date STRING, first_name STRING, last_name STRING, gender STRING, hire_date STRING, database_name STRING, table_name STRING ) WITH ( 'connector' = 'doris', 'fenodes' = '172.19.0.12:8030', 'table.identifier' = 'demo.all_employees_info', 'username' = 'root', 'password' = '', 'sink.properties.two_phase_commit'='true', 'sink.label-prefix'='doris_demo_emp_001' );参数说明：connector ：指定连接器是 Dorisfenodes：Doris FE 节点 IP 地址及 HTTP Porttable.identifier ：Doris 对应的数据库及表名username：Doris 用户名password：Doris 用户密码sink.properties.two_phase_commit：指定使用两阶段提交，这样在 Stream load 的时候，会在 Http header 里加上 two_phase_commit:true ，不然会失败sink.label-prefix ：这个是在两阶段提交的时候必须要加的一个参数，才能保证两端数据一致性，否则会失败其他参数参考官方文档：https://doris.apache.org/zh-CN/docs/ecosystem/flink-doris-connector.html这个时候查询 Doris sink 表是没有数据的select * from cdc_doris_sink;6.5 将数据插入到 Doris 表里执行下面的 SQL：insert into cdc_doris_sink (emp_no,birth_date,first_name,last_name,gender,hire_date,database_name,table_name) select emp_no,cast(birth_date as string) as birth_date ,first_name,last_name,gender,cast(hire_date as string) as hire_date ,database_name,table_name from employees_source;然后我们可以看到 Flink WEB UI 上的任务运行信息这里我们可以看看 TaskManager 的日志信息，会发现这里是使用两阶段提交的，而且数据是通过 Http chunked 方式不断朝 BE 端进行传输的，直到 Checkpoint，才会停止。Checkpoint 完成后会继续下一个任务的提交。2022-06-22 19:04:08,321 INFO org.apache.doris.flink.sink.writer.DorisStreamLoad [] - load Result { "TxnId": 6963, "Label": "doris_demo_001_0_1", "TwoPhaseCommit": "true", "Status": "Success", "Message": "OK", "NumberTotalRows": 40, "NumberLoadedRows": 40, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 35721, "LoadTimeMs": 9046, "BeginTxnTimeMs": 0, "StreamLoadPutTimeMs": 0, "ReadDataTimeMs": 0, "WriteDataTimeMs": 9041, "CommitAndPublishTimeMs": 0 } .... 2022-06-22 19:04:18,310 INFO org.apache.doris.flink.sink.writer.DorisStreamLoad [] - load Result { "TxnId": 6964, "Label": "doris_demo_001_0_2", "TwoPhaseCommit": "true", "Status": "Success", "Message": "OK", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 0, "LoadTimeMs": 9988, "BeginTxnTimeMs": 0, "StreamLoadPutTimeMs": 0, "ReadDataTimeMs": 0, "WriteDataTimeMs": 9983, "CommitAndPublishTimeMs": 0 } 2022-06-22 19:04:18,310 INFO org.apache.doris.flink.sink.writer.RecordBuffer [] - start buffer data, read queue size 0, write queue size 36.6 查询 Doris 数据这里插入了 636 条数mysql> select count(1) from all_employees_info ; +----------+ | count(1) | +----------+ | 634 | +----------+ 1 row in set (0.01 sec) mysql> select * from all_employees_info limit 20; +--------+------------+------------+-------------+--------+------------+---------------+-------------+ | emp_no | birth_date | first_name | last_name | gender | hire_date | database_name | table_name | +--------+------------+------------+-------------+--------+------------+---------------+-------------+ | 10001 | 1953-09-02 | Georgi | Facello | M | 1986-06-26 | emp_1 | employees_1 | | 10002 | 1964-06-02 | Bezalel | Simmel | F | 1985-11-21 | emp_1 | employees_1 | | 10003 | 1959-12-03 | Parto | Bamford | M | 1986-08-28 | emp_1 | employees_1 | | 10004 | 1954-05-01 | Chirstian | Koblick | M | 1986-12-01 | emp_1 | employees_1 | | 10005 | 1955-01-21 | Kyoichi | Maliniak | M | 1989-09-12 | emp_1 | employees_1 | | 10006 | 1953-04-20 | Anneke | Preusig | F | 1989-06-02 | emp_1 | employees_1 | | 10007 | 1957-05-23 | Tzvetan | Zielinski | F | 1989-02-10 | emp_1 | employees_1 | | 10008 | 1958-02-19 | Saniya | Kalloufi | M | 1994-09-15 | emp_1 | employees_1 | | 10009 | 1952-04-19 | Sumant | Peac | F | 1985-02-18 | emp_1 | employees_1 | | 10010 | 1963-06-01 | Duangkaew | Piveteau | F | 1989-08-24 | emp_1 | employees_1 | | 10011 | 1953-11-07 | Mary | Sluis | F | 1990-01-22 | emp_1 | employees_1 | | 10012 | 1960-10-04 | Patricio | Bridgland | M | 1992-12-18 | emp_1 | employees_1 | | 10013 | 1963-06-07 | Eberhardt | Terkki | M | 1985-10-20 | emp_1 | employees_1 | | 10014 | 1956-02-12 | Berni | Genin | M | 1987-03-11 | emp_1 | employees_1 | | 10015 | 1959-08-19 | Guoxiang | Nooteboom | M | 1987-07-02 | emp_1 | employees_1 | | 10016 | 1961-05-02 | Kazuhito | Cappelletti | M | 1995-01-27 | emp_1 | employees_1 | | 10017 | 1958-07-06 | Cristinel | Bouloucos | F | 1993-08-03 | emp_1 | employees_1 | | 10018 | 1954-06-19 | Kazuhide | Peha | F | 1987-04-03 | emp_1 | employees_1 | | 10019 | 1953-01-23 | Lillian | Haddadi | M | 1999-04-30 | emp_1 | employees_1 | | 10020 | 1952-12-24 | Mayuko | Warwick | M | 1991-01-26 | emp_1 | employees_1 | +--------+------------+------------+-------------+--------+------------+---------------+-------------+ 20 rows in set (0.00 sec)6.7 测试删除mysql> use emp_2; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +-----------------+ | Tables_in_emp_2 | +-----------------+ | employees_1 | | employees_2 | +-----------------+ 2 rows in set (0.00 sec) mysql> delete from employees_2 where emp_no in (12013,12014,12015); Query OK, 3 rows affected (0.01 sec)验证 Doris 数据删除mysql> select count(1) from all_employees_info ; +----------+ | count(1) | +----------+ | 631 | +----------+ 1 row in set (0.01 sec)七、总结本文主要介绍了 Flink CDC 分库分表怎么实时同步，以及其结合 Apache Doris Flink Connector 最新版本整合的 Flink 2PC 和 Doris Stream Load 2PC 的机制及整合原理、使用方法等。希望能给大家带来一点帮助。转载｜SelectDB 公众号作者｜张家锋近期活动实时数仓Workshop · 广州站 9.15 邀您参加！Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-30
5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布
点击免费下载2022版《Apache Flink 行业案例集》Apache Flink 是 Apache 软件基金会的顶级项目，也是当下被广泛使用的开源大数据计算引擎之一。基于它 “流批一体” 的技术，越来越多的企业选择 Apache Flink 应用于自身的业务场景，如数据集成、数据分析、数据仓库、实时分析、实时大屏等场景中，解决实时计算的需求。近年来，Apache Flink 开始广泛应用于推荐、广告和搜索等机器学习业务场景，已覆盖近百家企业的绝大多数实时计算需求，包括互联网娱乐、游戏、电商、金融、证劵、通信等多个行业。为了帮助读者更全面和深入地了解 Flink 技术如何在实际生产场景中落地，《Apache Flink 案例集》2022版专刊诞生。希望通过这本刊物，可以让读者了解到大量来自不同领域的公司在数据集成、数据分析（BI）、人工智能（AI）、云原生以及企业数字化转型等应用场景中使用 Apache Flink 解决实际生产问题的成功案例，其中既包含传统和新兴的互联网公司，也包含通信、证券、银行等传统企业。希望这些真实的生产实践案例和经验能够帮助大家更好的理解和使用 Apache Flink，加速更多企业的实时化平台搭建和业务转型。本书亮点5大业务场景，20+厂商真实案例分享；深入了解小米、网易、快手、美团、京东、b站等知名互联网企业建设经验，干货满满；传统金融行业实战案例首次公开，深入探讨传统行业数字化转型之路。精彩内容抢先看近期活动实时数仓Workshop · 广州站 9.15 邀您参加！Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-26
实时数仓Workshop · 广州站 9.15 邀您参加！
点击参与线下交流随着数字化业务的增长，企业的数据量呈现爆发式增长，数据仓库已经成为企业数据发展到一定规模后必然提供的基础服务之一。数据的时效性，成为数据仓库建设中必不可少的一环，企业最常做的就是通过实时数仓建设，满足对数据的快速探索。在实际业务中，实时数仓需要支持数据实时写入与更新、业务敏捷快速响应、数据自助分析、运维操作便捷、云原生弹性扩缩容等一列需求，而这就依赖一款强大的实时数仓引擎。阿里云实时计算 Flink 版作为一款大数据流式计算引擎，提供全增量一体化数据同步技术、强大的流式 ETL 等能力，支持海量数据实时写入处理；新一代实时数仓引擎阿里云 Hologres 能同时解决 OLAP 多维分析、在线服务、离线数据加速等多个业务查询场景。通过阿里云实时计算 Flink 版与阿里云 Hologres 的强强结合，实现全链路的数据探索实时化、数据分析敏捷化，快速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。9月15日，实时数仓 Workshop · 广州站将聚焦 Flink & Hologres 实时数仓在数据链路中扮演的角色与在智能商业中的重要价值，由业内各界的实时数仓实践者一同探讨实时计算未来趋势、开源生态发展、实时数仓场景在各行业中的实践与应用及平台智能化的探索与思考。嘉宾及议题介绍01《阿里云实时计算Flink版产品介绍与演示》乐洋｜阿里云高级产品专家围绕Flink的相关场景，包括包括调优、运维、开发等，以及实时数仓相关解决方案02《Flink和Hologres构建企业级一站式实时数仓》余文兵｜阿里巴巴技术专家随着实时数仓的普及，在线化、一站式、敏捷化成为实时数仓新的发展趋势，阿里云Hologres支持高吞吐写入与更新、PB级数据秒级查询以及高并发的在线服务查询，兼容PG生态，与Flink深度融合，解决传统数仓加工链路长、数据出口多、数据更新难等问题，提供一站式实时数仓标准解决方案，加速企业实时数仓建设。03《37手游基于云平台的大数据建设实践》史飞翔｜37手游大数据平台高级开发工程师传统的大数据架构服务器、运维成本高，扩展性有限，维护组件较多，监控不够完善。上云拐点已经到来，开源大数据上云已成为业界共识。如何在云上低成本存储的同时又实现弹性计算的需求，如何仅通过sql实现流式计算，如何解决业务查询报表慢的问题，本次分享将为你揭晓答案，欢迎大数据技术爱好者交流和探讨！04《Flink+Hologres实时数仓在Lazada的建设及应用》徐鑫豪｜Lazada数据技术专家本次会介绍Flink和Hologres架构在Lazada的落地实践。Lazada基于Flink和Hologres技术构建的实时数仓，快速提供业务小二的多种OLAP多维分析能力，支撑Lazada AB实验、营销分析等数据平台场景，助力业务快速增长。05《从ELK到EFK——结合Flink和Elasticsearch新特性重构全观测方案》朱杰｜Elastic 资深解决方案架构师赵弘扬｜阿里云高级产品专家近几年，随着IT架构逐步向云的衍进，传统的IT运维、日志/指标监控与分析、安全分析等手段，也逐渐从独立的日志、指标、分布式追踪系统迈向云上统一和融合的全观测平台。“开源云服务”和“全观测”这两个近期在国内非常时兴的概念，相结合会碰撞出什么样的火花？如何基于云上的海量存储能力、计算能力，处理企业IT架构所面临的数据量大、数据预处理量大、链路时效性要求高和告警任务复杂高频等艰巨的问题？本次分享的内容将为大家介绍并分析：阿里云上的Elasticsearch和Flink服务，是如何高效、低成本地解决上述问题，实现全观测降本增效的目标。活动详情时间：2022年9月15日 13:30-18:00地点：广东省广州市天河区珠江新城W酒店PC 端直播观看：https://developer.aliyun.com/live/250086移动端建议关注 ApacheFlink 视频号预约观看点击参与线下交流延伸阅读阿里云实时计算 Flink 版 x Hologres: 构建企业级一站式实时数仓2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-24
阿里云实时计算 Flink 版 x Hologres: 构建企业级一站式实时数仓
作者｜徐榜江 余文兵 赵红梅编辑｜伍翀随着大数据的迅猛发展，企业越来越重视数据的价值，这就意味着需要数据尽快到达企业分析决策人员，以最大化发挥数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的快速探索。在业务建设过程中，实时数仓需要支持数据实时写入与更新、业务敏捷快速响应、数据自助分析、运维操作便捷、云原生弹性扩缩容等一系列需求，而这就依赖一个强大的实时数仓解决方案。阿里云实时计算 Flink 版（以下简称“阿里云 Flink”）提供全增量一体化数据同步技术、强大的流式 ETL 等能力，支持海量数据实时入仓入湖。阿里云 Hologres 作为新一代实时数仓引擎能同时解决 OLAP 多维分析、在线服务、离线数据加速等多个业务查询场景，通过阿里云 Flink 与 Hologres 的强强结合，实现全链路的数据探索实时化、数据分析敏捷化，快速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。在本文中，我们将会介绍阿里云 Flink、阿里云 Hologres 在构建实时数仓上所具备的核心能力以及二者结合的最佳解决方案，用户通过阿里云 Flink+Hologres 实时数仓解决方案，可以显著降低数仓建设门槛，让数据发挥更大的价值，助力各行各业实现数字化升级。一、Flink CDC 核心能力Apache Flink 是开源的大数据流式计算引擎，支持处理数据库、Binlog、在线日志等多种实时数据，提供端到端亚秒级实时数据分析能力，并通过标准 SQL 降低实时业务开发门槛。伴随着实时化浪潮的发展和深化，Flink 已逐步演进为流处理的领军角色和事实标准，并蝉联 Apache 社区最活跃项目。Flink CDC 是阿里云计算平台事业部 2020 年 7 月开源的一款数据集成框架，与 Flink 生态深度融合，具有全增量一体化、无锁读取、并发读取、分布式架构等技术优势，既可以替代传统的 DataX 和 Canal 工具做数据同步，也支持数据库数据实时入湖入仓，同时还具备强大的数据加工能力。在构建实时数仓的过程中，数据采集是必需的组件。在传统的 ETL 架构里，采集层国外用户通常选择 Debezium，国内用户则习惯用 DataX 和 Canal，采集工具负责采集数据库的全量数据和增量数据。采集到的数据会输出到消息中间件如 Kafka，然后通过 Flink 计算引擎实时消费消息中间件数据做计算层的数据清洗和数据加工，加工完成后再写入目的端（装载层），通常是各种数据库、数据湖和数据仓库。在传统 ETL 链路中，数据采集工具与消息队列是比较重的组件，可能维护在不同的团队，在上游的数据源有业务变更或者这些组件需要升级维护时，整个链路的维护成本会非常大。通过使用 Flink CDC 去替换上图中的数据采集组件与消息队列，将采集层（Extraction）和计算层（Transformation）合并，简化了整个 ETL 分析链路，用户可以使用更少的组件完成数据链路的搭建，整体架构带来更低的运维开销和更少的硬件成本、更好的数据链路稳定性、以及降低端到端的数据延迟。除了稳定性的提升，Flink CDC 的另一个优势就是用户只需要写 SQL 脚本就能完成 CDC 数据的清洗，加工和同步，极大地降低了用户使用门槛。除全增量一体化同步能力外，阿里云 Flink CDC 还提供了表结构变更自动同步、整库同步、分库分表合并同步等诸多企业级特性，方便用户快速打通数据孤岛，实现业务价值。1.1 全增量一体化同步Flink CDC 通过增量快照读取算法在开源数据集成领域率先支持了无锁读取、并行读取、断点续传、不丢不重四个重要特性。其中无锁读取彻底解决了数据同步对上游业务数据库的死锁风险，并行读取很好地满足了海量数据同步的需求，断点续传和不丢不重特性则是提升了同步链路的稳定性和可靠性。增量快照读取算法的核心思路就是在全量读取阶段把表分成一个个 chunk 进行并发读取，在进入增量阶段后只需要一个 task 进行单并发读取 Binlog 日志，在全量和增量自动切换时，通过无锁算法保障一致性。这种设计在提高读取效率的同时，进一步节约了资源，实现了全增量一体化的数据同步。配合阿里云实时计算产品提供的资源自动调优特性，Flink CDC 作业的资源可以做到自动扩缩容，无需手动介入。1.2 表结构变更自动同步随着业务的迭代和发展，数据源的表结构变更是经常会发生的操作。用户需要及时地去修改数据同步作业以适配最新的表结构，这一方面带来了较大的运维成本，也影响了同步管道的稳定性和数据的时效性。阿里云 Flink 支持通过 Catalog 来实现元数据的自动发现和管理，配合 CTAS （Create Table AS）语法，用户可以通过一行 SQL 实现数据的同步和表结构变更自动同步。Flink SQL> USE CATALOG holo; Flink SQL> CREATE TABLE user AS TABLE mysql.`order_db`.`user`; CTAS 语句会解析成一个 Flink 作业执行，这个 Flink 作业源头支持读取数据变更和表结构变更并同步到下游，数据和表结构变更都可以保证顺序，上述 CTAS 语句运行时结构变更同步的效果如下图所示。示例如果在上游 MySQL 的 user 表中新增一列 age，并插入一条 id 为 27，年龄为 30 的记录。MySQL> ALTER TABLE `user` ADD COLUMN `age` INT; MySQL> INSERT INTO `user` (id, name, age) VALUES (27, 'Tony', 30);user 表上的数据和结构变更都能实时地自动同步到下游 Hologres 的 user 表中，id 为 12,16 和 19 的历史数据，新增的列会自动补 NULL 值。1.3 整库同步在实时数仓构建中，用户经常需要将整个数据库同步到数仓中做进一步的分析，一张表一个同步作业的方式不但浪费资源，也会给上游数据库产生较大的压力。针对这类用户痛点，阿里云 Flink CDC 提供了整库同步特性。整库同步功能通过 CDAS (Create Database AS) 语法配合 Catalog 实现。Flink SQL> USE CATALOG holo; Flink SQL> CREATE DATABASE holo_order AS DATABASE mysql.`order_db` INCLUDING ALL TABLES;例如 MySQL Catalog 和 Hologres Catalog 配合 CDAS 语法，可以完成 MySQL 到 Hologres 的全增量数据同步。CDAS 语句会解析成一个 Flink 作业执行，这个 Flink 作业自动解析源表的表结构及相应的参数，并将指定的一个或多个数据库同步到下游 Hologres 数仓中，整个过程用户无需手写 DDL 语句，无需用户在 Hologres 提前创建表，就能快速实现数据的整库同步。CDAS 作业默认提供表结构变更同步能力，所有表的结构变更都会按照发生顺序同步至下游 Hologres 实时数仓，CDAS 语法也支持过滤不需要同步的表。1.4 分库分表合并同步分库分表是高并发业务系统采用的经典数据库设计，通常我们需要将分库分表的业务数据汇聚到一张数仓中的大表，方便后续的数据分析，即分库分表合并同步的场景。针对这种场景，阿里云 Flink CDC 提供了分库分表合并同步特性，通过在 CTAS 语法支持源库和源表的正则表达式，源数据库的分表可以高效地合并同步到下游 Hologres 数仓中。Flink SQL> USE CATALOG holo; Flink SQL> CREATE TABLE order AS TABLE mysql.`order_db.*`.`order_.*`;上述 CTAS 语句中的源库名 order_db. 是个正则表达式，可以匹配当前 MySQL 实例下的 order_db01，order_db02 和 order_db03 三个库，源表名 order_ 也是个正则表达式，可以匹配三个库下所有以 order_打头的表。 针对分库分表同步场景，用户只需要提供分库分表的正则表达式就可以将这多张分库分表合并同步到下游 Hologres 数仓的 ordder 表中。与其他 CDAS 语句一样，分库分表同步场景默认提供表结构变更自动同步特性，下游 Hologres 表的 schema 为所有分表合并后的最宽 schema。分库分表同步时每行记录所属的库名和表名会作为额外的两个字段自动写入到 user 表中，库名(上图中 db 列)、表名(上图中 tbl 列)和原主键(上图中 id 列) 会一起作为下游 Hologres user 表的联合主键，保证 Hologres user 表上主键的唯一性。二、Hologres 核心能力阿里云 Hologres 是自研的一站式实时数据仓库引擎，支持海量数据实时写入、实时更新、实时分析，支持标准 SQL（兼容 PostgreSQL 协议），提供 PB 级数据多维分析（OLAP）与即席分析以及高并发低延迟的在线数据服务（Serving），与阿里云 Flink、MaxCompute、DataWorks 等深度融合，为企业提供离在线一体化全栈数仓解决方案。2.1 高性能实时写入与更新数据写入的时效性是实时数仓的重要能力之一。对于 BI 类等延迟不敏感的业务查询，如果写入时延几秒甚至几分钟可能是可以接受的。而对于很多生产系统，如实时风控、实时大屏等场景，要求数据写入即可见。如果写入出现延迟，就会查询不到最新的数据，严重影响线上业务决策。在实时数仓整个数据处理链路中，Hologres 作为一站式实时数据仓库引擎，提供海量数据高性能的实时写入，数据写入即可查询，无延迟。同时在数仓场景上，数据来源复杂，会涉及到非常多的数据更新、修正的场景，Hologres 可以通过主键（Primary Key, PK）提供高性能的 Upsert 能力，整个写入和更新过程确保 Exactly Once，满足对对数据的合并、更新等需求。下图为 Hologres 128C 实例下，10 个并发实时写入 20 列的列存表的测试结果。其中竖轴表示每秒写入记录数，横轴为 4 个写入场景：Append Only：写入表无主键，写入能力 230 万+的 RPS。INSERT：写入表有主键，如果主键冲突就丢弃新行，写入能力 200 万 RPS。UPDATE-1：写入表有主键，表中原始数据量为 2 亿，按照主键 Upsert，写入能力 80 万的 RPS。UPDATE-2：写入表有主键，表中数据量为 20 亿，按照主键做 Upsert，写入能力 70 万的 RPS。2.2 实时 OLAP 分析Hologres 采用可扩展的 MPP 全并行计算，支持行存、列存、行列共存等多种存储模式，同时支持多种索引类型。通过分布式处理 SQL 以及向量化的算子，能够将 CPU 资源发挥到极致，从而支持海量数据亚秒级分析，无需预计算，就能支持实时多维分析、即席分析等多种实时 OLAP 分析的场景，再直接无缝对接上层应用/服务，满足所见即所得的分析体验。下图为 Hologres 128C 实例下，TPCH 100G 标准数据集下的测试结果，横轴表示 query，纵轴是响应时间：2.3 高性能在线服务随着实时数仓的广泛应用，越来越多的企业把实时数仓作为在线服务系统提供在线查询。Hologres 作为 HSAP（Hybrid Serving and Analytics Processing, 服务与分析一体化）的最佳落地实践，除了具备处理分析型 Query 的能力外，还具备十分强大的在线服务 Serving 能力(高 QPS 点查)，例如 KV 点查与向量检索。在 KV 点查场景中，Holgres 通过 SQL 接口可以支持百万级的 QPS 吞吐与极低的延时。通过 Hologres 能够做到一套系统、一份数据支持同时 OLAP 分析和在线服务两种场景，简化数据架构。下图为 Hologres 128C 实例下，CPU 消耗 25%的点查测试性能：2.4 读写分离高可用实时数据仓库 Hologres 提供高 QPS 低延迟的写入能力，支持在线服务的查询场景，还支持复杂的多维分析 OLAP 查询。当不同类型，不同复杂的任务请求到 Hologres 实例上时，Hologres 不仅需要确保任务的正常运行，还要确保系统的稳定性。当前 Hologres 支持通过共享存储的一主多从子实例的高可用架构，实现了完整的读写分离功能，保障 不同业务场景的 SLA。读写分离：实现了完整的读写分离功能，保障不同业务场景的 SLA，在高吞吐的数据写入和复杂的 ETL 作业、OLAP 查询、AdHoc 查询、在线服务等场景中，系统负载物理上完全隔离，不会因写入任务产生了查询任务的抖动。多类型负载资源隔离：一个主实例可以配置四个只读实例，实例之间可以根据业务情况配置不同规格，系统负载物理上完全隔离，避免相互影响而带来抖动。实例间数据毫秒级异步同步延迟：P99 5ms 内。2.5 Binlog 订阅类似于传统数据库 MySQL 中的 Binlog 概念，Binlog 用来记录数据库中表数据的修改记录，比如 Insert/Delete/Update 的操作。在 Hologres 中，表的 Binlog 是一种强 Schema 格式的数据，Binlog 记录的序列号（BigInt），在单 shard 内单调递增，类似于 Kafka 中的 Offset 概念。通过阿里云 Flink 消费 Hologres Binlog，可以实现数仓分层间的全链路实时开发，在分层治理的前提下，缩短数据加工端到端延迟，同时提升实时数仓分层的开发效率。三、阿里云 Flink x Hologres 一站式企业级实时数仓解决方案3.1 实时数仓 ETLETL( Extract-Transform-Load)是比较传统的数据仓库建设方法，业务库的数据 Binlog 经过阿里云 Flink 的 ETL 处理之后，数据写入到实时数仓 Hologres 中，然后进行各类数据查询分析。ETL 的方法核心是需要在数仓中具备完善的数仓模型分层，通常按照 ODS（Operational Data Source）> DWD（Data Warehouse Detail）> DWS（Data Warehouse Summary）> ADS（Application Data Service）分层，整个数仓链路比较完善。在这个链路中，需要将数据源比如 MySQL 的 Binlog 数据通过阿里云 Flink CDC 同步到消息队列 Kafka，再通过阿里云 Flink 将 ODS 的数据进行过滤，清洗，逻辑转化等操作，形成对不同的业务主题模型的 DWD 数据明细层，同时将数据发送到 Kafka 集群，之后再通过阿里云 Flink 将 DWD 的数据进行轻度的汇总操作，形成业务上更加方便查询的 DWS 轻度汇总层数据，再将数据写入 Kafka 集群。最后再面向业务具体的应用层的需求，在 DWS 层基础上通过阿里云 Flink 实时处理形成 ADS 数据应用层，写入实时数仓 Hologres 进行存储和分析，支持业务各种不同类型的报表，画像等业务场景。实时数仓 ETL 的处理优点是数仓各种层次比较完备，职责清晰，但是缺点是 Flink 结合 Kafka 集群维护复杂，处理链路比较长，历史数据修正复杂，ADS 应用层的数据实时性会弱，其次数据在各个 Kafka 中不便于查询，不便于检查数据质量，也不便于实现 schema 的动态变化。3.2 实时数仓 ELT随着业务对数据的时效性要求越来越高时，相较于 ETL 复杂繁杂的处理链路，业务需要更快速的将数据实时入仓，因此 ELT 变成了比较流行的处理方法。ELT 是英文 Extract-Load-Transform 的缩写，我们可将 ELT 理解为一个数据迁移集成的过程。在这个过程中，我们可以对数据源关系型数据库比如 MySQL、PostgresSQL 和非关系型数据库比如 HBase、Cassandra 等业务库的 Binlog，消息队列比如 Datahub、Kafka 中的埋点采集日志等数据，经过阿里云 Flink 实时抽取，然后加载到 Hologres 中进行相关的 OLAP 分析和在线服务。在这个链路中，阿里云 Flink 负责数据的实时入仓以及数据的清洗关联，清洗后的数据实时写入 Hologres，由 Hologres 直接存储明细数据。在 Hologres 中可以简化分层，以明细层为主，按需搭配其他汇总层，通过 Hologres 强大的数据处理能力直接对接报表、应用等上层查询服务。上层的分析 SQL 无法固化，通常在 ADS 层以逻辑视图（View）封装 SQL 逻辑，上层应用直接查询封装好的 View，实现即席查询。实时数仓中采取 ELT 的方式进行建设，会给数据和业务带来比较大的收益，详细如下：灵活性：将原始的业务数据直接入仓，形成 ODS 层的数据，在数仓中通过 View 可以灵活地对数据进行转换(Transformation)的处理，View 可以随时根据业务进行调整。成本低：数据仓库的架构比较清晰，链路比较短，运维成本比较低。指标修正简单：上层都是 View 逻辑封装，只需要更新底表的数据即可，无需逐层修正数据。但是该方案也存在一些缺点，当 View 的逻辑较为复杂，数据量较多时，查询性能较低。因此比较适合于数据来源于数据库和埋点系统，对 QPS 要求不高，对灵活性要求比较高，且计算资源较为充足的场景。3.3 实时数仓分层（Streaming Warehouse 方案）按照传统数仓的开发方法论，采用 ODS>DWD>DWS>ADS 开发的方法，通过阿里云 Flink 和 Hologres Binlog 的组合关系，支持层与层之间有状态的全链路事件实时驱动。在该方案中，数据通过阿里云 Flink CDC 实时入仓至 Hologres，再通过阿里云 Flink 订阅 Hologres Binlog，实现数据在不同层次之间的连续加工，最后写入 Hologres 对接应用查询。通过这个方案，Hologres 可以达到像 Kafka、Datahub 等消息队列同等的能力，增加数据复用的能力，一个 Table 的数据既可以提供给下游阿里云 Flink 任务消费，还可以对接上游 OLAP/在线服务查询，不仅节省了成本，还简化数仓架构，同时也让数仓中的每一个层次都可以实时构建、实时查询，提升数据的流转效率。3.4 流批一体数仓在实时数仓中，流计算任务和批处理任务都是分两条工作流进行开发的，也即是 Kappa 架构模式。在这套数仓架构中，会存在人力成本过高，数据链路冗余，数据口径不一致，开发效率低下的一些问题。为了解决这些问题，阿里云 Flink+Hologres 提供了流批一体的能力。在该场景中，将输入层统一变成 Hologres，通过一套业务逻辑代码达到流和批处理的能力，其中 Flink SQL 的 Stream 任务消费 Hologres Binlog 提供流式处理，Flink SQL 的 Batch 任务读取 Hologres 表的原始数据达到批处理能力，经过 Flink 统一的计算处理之后，统一写入存储至 Hologres。阿里云 Flink 结合 Hologres 的流批一体技术，统一了数据输入层、实时离线计算层和数据分析存储层，极大的提升了数据开发的效率，保证了数据的质量。四、典型应用场景阿里云 Flink 与 Hologres 深度集成，助力企业快速构建一站式实时数仓：可通过阿里云 Flink 实时写入 Hologres，高性能写入与更新，数据写入即可见，无延迟，满足实时数仓高性能低延迟写入需求；可通过阿里云 Flink 的全量读取、Binlog 读取、CDC 读取、全增量一体化等多种方式，读取 Hologres 源表数据，无需额外组件，统一计算和存储，加速数据流转效率；可通过阿里云 Flink 读取 Hologres 维表，助力高性能维表关联、数据打宽等多种应用场景；阿里云 Flink 与 Hologres 元数据打通，通过 Hologres Catalog，实现元数据自动发现，极大提升作业开发效率和正确性。通过阿里云 Flink 与 Hologres 的实时数仓标准解决方案，能够支撑多种实时数仓应用场景，如实时推荐、实时风控等，满足企业的实时分析需求。下面我们将会介绍阿里云 Flink + Hologres 的典型应用场景，助力业务更加高效的搭建实时数仓。4.1 海量数据实时入仓实时数仓搭建的第一步便是海量数据的实时入仓，基于阿里云 Flink CDC 可以简单高效地将海量数据同步到实时数仓中，并能将增量数据以及表结构变更实时同步到数仓中。而整个流程只需在阿里云 Flink 上定义一条 CREATE DATABASE AS DATABASE 的 SQL 即可（详细步骤可参考 实时入仓快速入门 ）。经测试，对于 MySQL 中的 TPC-DS 1T 数据集，使用阿里云 Flink 64 并发，只需 5 小时便能完全同步到 Hologres，TPS 约 30 万条/秒。在增量 Binlog 同步阶段，使用阿里云 Flink 单并发，同步性能达到 10 万条/秒。4.2 双流 Join数据实时入仓形成了 ODS 层的数据后，通常需要将事实数据与维度数据利用 Flink 多流 Join 的能力实时地打平成宽表，结合 Hologres 宽表极佳的多维分析性能，助力上层业务查询提速。阿里云 Flink 支持以全增量一体化的模式读取 Hologres 表，即先读取全量数据再平滑切换到读取 CDC 数据，整个过程保证数据的不重不丢。因此基于阿里云 Flink 可以非常方便地实时加工和打宽 Hologres 的 ODS 层数据，完成 DWD 层的宽表模型构建。4.3 宽表 Merge数据仓库中我们通常需要关心的就是建模，数据模型通常分为四种：宽表模型、星型模型、雪花模型、星座模型（Hologres 均支持），在这里我们重点要提到的是宽表模型的建设。宽表模型通常是指将业务主体相关的指标、维表、属性关联在一起的模型表，也可以泛指将多个事实表和多个维度表相关联到一起形成的宽表。宽表建设通常的做法就是通过阿里云 Flink 的双流 Join 来实现，包括 Regular Join，Interval Join，Temporal Join。对于主键关联的场景（即 Join 条件分别是两条流的主键），我们可以将 Join 的工作下沉到 Hologres 去做，通过 Hologres 的局部更新功能来实现宽表 Merge，从而省去了 Flink Join 的状态维护成本。比如广告场景中，一个 Flink 任务处理广告曝光数据流，统计每个产品的曝光量，以产品 ID 作为主键，更新到产品指标宽表中。同时，另一个 Flink 任务处理广告点击数据流，统计每个产品的点击量，也以产品 ID 作为主键，更新到产品指标宽表中。整个过程不需要进行双流 Join，最终 Hologres 会自己完成整行数据的组装。基于得到的产品指标宽表，用户可以方便地在 Hologres 进行广告营销的分析，例如计算产品的 CTR=点击数/曝光数。下图和代码示例展示了如何从双流 Join 改为宽表 Merge。CREATE TABLE ods_ad_click ( product_id INT, click_id BIGINT, click_time TIMESTAMP ) WITH ('connector'='datahub', 'topic'='..'); CREATE TABLE ods_ad_impressions ( product_id INT, imp_id BIGINT, imp_time TIMESTAMP ) WITH ('connector'='datahub', 'topic'='..'); CREATE TABLE dws_ad_product ( product_id INT, click_cnt BIGINT, imp_cnt BIGINT, PRIMARY KEY (product_id) NOT ENFORCED ) WITH ('connector'='hologres','insertOrUpdate'='true'); INSERT INTO dws_ad_product (product_id, click_cnt) SELECT product_id, COUNT(click_id) as click_cnt FROM ods_ad_click GROUP BY product_id; INSERT INTO dws_ad_product (product_id, imp_cnt) SELECT product_id, COUNT(imp_id) AS imp_cnt FROM ods_ad_impressions GROUP BY product_id;使用 Hologres 宽表的 Merge 能力，不仅可以提升流作业的开发效率，还能减少流作业所需要的资源消耗，也能够更容易的维护各个流作业，让作业之间不会相互影响。但需要注意的是，宽表 Merge 仅限于使用在主键关联的场景，并不适用于数仓中常见的星型模型和雪花模型，所以在大部分场景仍需使用 Flink 的双流 Join 来完成宽表建模。4.4 实时维表 Lookup在实时数仓中，在构建 DWD 层的数据过程中，一般都是通过阿里云 Flink 来读取消息队列比如 Datahub 上的 ODS 数据，同时需要关联维表来形成 DWD 层。在阿里云 Flink 的计算过程中，需要高效的读取维表的能力，Hologres 可以通过高 QPS 低延迟的点查能力来满足实现这类场景需求。比如我们需要通过 ODS 的数据去 Join 维表形成 DWD 层的时候，就可以利用 Hologres 提供的点查能力，在该模式中，通常使用行存表的主键点查模式提高维表的 Lookup 效率。具体的实现类似如下：五、典型用户案例依托阿里云 Flink+Hologres 解决方案，企业可以快速构建一站式实时数仓，助力实时推荐、实时风控、实时大屏等多种业务场景，实现对数据的快速处理，极速探索查询。目前该方案已在阿里巴巴内部、众多云上企业生产落地，成为实时数仓的最佳解决方案之一。以某知名全球 TOP20 游戏公司业务为例，其通过阿里云 Flink+Hologres 实时数仓方案，替换开源 Flink+Presto+HBase+ClickHouse 架构，简化数据处理链路、统一数仓架构、统一存储、查询性能提升 100%甚至更多，完美支撑数据分析、广告投放、实时决策等多个场景，助力业务快速增长。5.1 业务困难：ETL 链路复杂、OLAP 查询慢客户原数仓架构使用全套开源组件，架构图如下。其中开源 Flink 做 ETL 处理，处理后写入 ClickHouse、StarRocks 等 OLAP 引擎。这套架构遇见的主要痛点有：1、ETL 链路复杂为了解决数据实时 ETL，客户通过 Flink CDC + Hudi 做流批一体。但由于上游业务数据经常变更表结构，而开源 Flink CDC 缺乏 Schema Evolution 的能力，每次表结构变更都需要任务重新启动，操作非常麻烦，浪费大量开发时间。Hudi 的查询性能不满足业务需求，还需要再加一个 Presto 做加速查询，造成链路冗余。2、OLAP 架构冗余，查询慢客户主要是靠买量发行作为游戏推广的重要手段，为了解决广告归因的实时决策场景对查询加速的需要，于是部署了开源 Presto、ClickHouse、HBase 等多套集群搭建混合 OLAP 平台。带来的问题有：平台需要维护多套集群，导致运维变得非常复杂。开发需要在各种 SQL 中切换，为开发团队带来了许多困扰。由于 ClickHouse 缺乏主键，在归因分析时需要使用 Last Click 模型，带来了大量的额外工作。同时 OLAP 引擎的查询性能没有办法很好的满足业务需求，没办法根据数据实时决策。数据需要在多个 OLAP 系统中存储，造成存储冗余，导致成本压力剧增。基于上面的痛点，客户开始重新做技术选型，并使用阿里云 Flink+Hologres 来替换现有的开源数仓架构。5.2 架构升级：阿里云 Flink+Hologres 统一数据存储与服务通过阿里云 Flink+Hologres 替换后的数据链路如下：数据源数据通过 Flink CDC 能力写入 Kafka 做前置清洗，清洗后通过阿里云 Flink 进行 ETL 处理。阿里云 Flink 经过 ETL 后的数据实时写入 Hologres，通过 Hologres 替换了 Kafka 作为实时数仓的中间数据层，统一了流批存储。在 Hologres 中根据 ODS > DWD > DWS 层汇总加工。在 ODS 层，阿里云 Flink 订阅 Hologres Binlog，计算后写入 Hologres DWD 层，DWD 层在 Hologres 中汇总成 DWS 层，最后 DWS 对接上层报表和数据服务等业务。为了存储的统一，也将原离线 Hive 数据替换成阿里云 MaxCompute，以 MaxCompute 为离线主要链路。因 Hologres 与 MaxCompute 的高效互通能力，Hologres 通过外表离线加速查询 MaxCompute，并将历史数据定期归档至 MaxCompute。5.3 业务收益：架构统一，性能提升 100%通过架构升级后，客户的显著业务收益如下：依托阿里云 Flink+Hologres，数据可以实时写入 Hologres，写入即可见，并且 Hologres 有主键，能够支撑高性能的写入更新能力，百万级更新毫秒级延迟。阿里云 Flink 提供 Schema Evolution 的能力，自动感知上游表结构变更并同步 Hologres，改造后的实时 ETL 链路通过订阅 Hologres Binlog 日志来完成，降低链路维护成本。通过 Hologres 统一了数据查询出口，经过客户实测，Hologres 可以达到毫秒级延迟，相比开源 ClickHouse 性能提升 100%甚至更多，JOIN 查询性能快 10 倍。升级后数仓架构变得更加灵活简洁，统一了存储，只需要一套系统就能满足业务需求，降低运维压力和运维成本。了解更多：[1] 阿里云实时计算 Flink： https://www.aliyun.com/product/bigdata/sc[2] 阿里云实时数仓 Hologres： https://www.aliyun.com/product/bigdata/hologram[3] Flink X Hologres 联合解决方案： https://developer.aliyun.com/article/786306[4] 数据实时入仓入湖快速入门: https://help.aliyun.com/document_detail/374270.html2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-19
活动预约｜9.3 Lakehouse Meetup
直播地址：https://developer.aliyun.com/live/2500119月3日下午13:30，飞天club 与 StreamNative 联合举办 Lakehouse Meetup，邀请阿里巴巴、StreamNative 的 4 位技术专家一起探讨数据湖仓解决方案。具体议程如下：01毕岩（寻径）｜ 阿里巴巴技术专家《基于数据湖格式构建数据湖仓架构》解析数据湖仓架构关键特性，并简述三个数据湖格式。结合 Delta Lake 和 Hudi，分享阿里云 EMR 在经典数仓场景的使用案例。最后介绍阿里云 EMR+DLF 提供的整体数据湖仓解决方案。02陈航 ｜ StreamNative 高级工程师《APACHE PULSAR 的湖仓一体方案：PULSAR 的 LAKEHOUSE 分层存储集成详解》Apache Pulsar 是一种用于缓存数据并在不同系统之间解耦的消息总线。为了支持长期的主题数据存储，我们引入了分层存储，将冷数据卸载到分层存储中，例如 GCS、S3、HDFS 等。但是，当前卸载的数据是由 Pulsar 管理的非开放格式数据，是原始的数据格式，且只有 Pulsar 可以访问数据。因此很难将其与其他大数据组件集成，例如 Presto、Flink SQL 和 Spark SQL。为了解决这个问题，我们引入了 Lakehouse 来管理卸载数据，并与当前的主题冷数据卸载机制集成。我们可以使用 Lakehouse 提供的所有功能，例如事务支持、Schema 强制和 BI 支持等。我们会根据数据位置从 BookKeeper 或分层存储中读取数据，进行流数据读取。由于 Lakehouse 的开放存储格式，我们可以支持 Lakehouse 所维持的各种生态系统读取数据。为了支持流卸载并使卸载机制更具可扩展性，我们引入了按 reader 卸载机制来从主题中读取数据并写入分层存储。此外，我们还可以通过 offloader 提供压缩服务后端，并将主题作为表。键的每个更新操作都被转换为表的 upsert 操作。03陈玉兆（玉兆）｜ 阿里巴巴技术专家《Apache Hudi 实时湖仓解决方案》基于 Hudi 的数仓解决方案Hudi 的核心场景使用 Hudi 构建 Pulsar 分级存储近期 Roadmap04张勇 ｜ StreamNative 软件工程师《整合 PULSAR 和 LAKEHOUSE 数据：使用 CONNECTOR 将 PULSAR TOPIC 中的数据 SINK 到 LAKEHOUSE STORAGE》我们可能会使用不同的系统来处理不同应用场景中的流数据，在这些系统间整合数据可能会存在问题。本演讲将聚焦于 Lakehouse Connector，讨论如何使用此工具将 Pulsar Topic 中的数据 Sink 至 Lakehouse。直播地址：https://developer.aliyun.com/live/250011
-
发表了文章 2022-08-16
基于 Flink x TiDB，智慧芽打造实时分析新方案
摘要：本文整理自智慧芽数据仓库架构师曲明星在 Flink Forward Asia 2021 实时数仓专场的分享。本篇内容主要分为三个部分：产品架构技术架构未来计划点击查看直播回放 & 演讲PPT一、产品架构上图是智慧芽APP 的产品架构图，包括后台管理系统、AI、内容引擎、帮助中心，为客户提供知识产权信息化服务和科技创新情报系统。二、技术架构2.1 原实时分析方案上图是原来的实时分析方案。流程大致是客户检索一个条件，通过分析 API 把客户检索的相关条件发送到不同的搜索引擎。这种方案会产生 4 个问题：对检索性能产生影响；复杂分析需要开发插件支持；跨多个搜索引擎分析复杂度高；不同维度的数据无法存储。在建立实时数仓前，收集了业务要求实时数仓特点：秒级响应；准实时数据更新；能支持一定量的并发能力；与搜索引擎数据保持一致；支持复杂分析的能力；支持统一使用方式及主流特性；支持与搜索引擎交互；支持存储容量横向扩展的能力。上图是数据平台概览。从下往上看：最下层是数据底座，包括数据存储和数据计算，其中数据计算层由 Spark、Kafka、Flink 组成；中间层是数据平台，包括数据开发、数据分类、数据管理和数据服务；上层是数据应用，主要有数据业务、外部分析服务和内部分析业务构成。2.2 新实时分析方案新的技术选型主要基于 TiDB，主要包括数据存储、数仓服务两个部分。数仓服务分为安全检查、驱动表管理、缓存管理、集群负载检查以及执行器等部分。选择 TiDB 是因为它是云原生并且社区活跃、满足 TP 及 AP 业务场景、丰富的生态工具及多平台以及其使用简单，兼容 MySQL 以及大数据能力。选择 Flink 也是因为它是一个开源的大数据计算引擎，并且有活跃的云原生社区，能够满足对数据的及时性要求，一致性方面有 exactly-once 语义，同时具备低延迟高吞吐量。在线业务数据写入流程：把源头的数据变更放到消息队列中去，通过索引程序将数据分发到不同的搜索引擎，同时搜索引擎也会给索引程序发送消息。离线分析技术体系：整个离线分析技术体系比较依赖于 oss。将每日的增量数据离线放到 oss 里，对全量的数据进行一些比较复杂的分析。离线业务数据写入流程：数据变更会触发持久流化至 oss，oss 同时会和历史流进行合并在 oss 放一份全量数据。2.3 原用户行为分析方案原用户行为分析方案是非常复杂的方案，这个方案在前端有 JS 和 Java 的 API，JS 会将用户的埋点数据放置到 Segment 中去，同时有 Gainsight 和 AMPLITUDE 两个合成化引擎。2.4 新用户行为分析方案新的用户行为分析方案相对比较简洁。首先收集用户的行为数据，通过 Kinesis 以流的方式接到到 Flink，再进行一些实时指标的计算，并将计算结果存放于不同的表中，给我们提供了可视化的开发。2.5 Flink + Iceberge 探索在 Flink + Iceberge 的探索中，将几百 G 左右的表以流的方式放到 Kafka 中，再推送到 oss 中。目前，市面上缺乏成熟的解决方案，所以没有把这个方式应用到生产环境上。三、未来计划云原生数据库架构迁移；提供更完善的指标和取数系统；建设数据生产的全链路监控和预警；供支撑公司数据消费和服务能力；在线实时分析数仓及其数据处理管道的继续演进；打造云原生数据技术体系和新一代大数据平台；提供数据网关入口，提供统一的数据出口、提高数据应用效率。Patsnap 是一家科技创新情报 SaaS 服务商。通过机器学习、计算机视觉、自然语言处理（NLP）等人工智能技术为全球领先的科技公司、高校和科研机构、金融机构等提供大数据情报服务。点击查看直播回放 & 演讲PPT2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-09
基于 Flink 构建大规模实时风控系统在阿里巴巴的落地
本⽂由社区志愿者邹志业整理，内容来源⾃阿里云实时计算产品经理李佳林（风元）在 7 月 5 日 Flink 峰会（CSDN 云原生系列）的演讲。主要内容包括：基于 Flink 构建风控系统阿里风控实战大规模风控技术难点阿里云 FY23 风控演进计划点击查看直播回放 & 演讲PPT目前 Flink 基本服务于集团的所有 BU ，在双十一峰值的计算能力达到 40 亿条每秒，计算任务达到了 3 万多个，总共使用 100 万+ Core ；几乎涵盖了集团内的所有具体业务，比如：数据中台、AI中台、风控中台、实时运维、搜索推荐等。一、基于 Flink 构建风控系统风控是一个很大的话题，涉及到规则引擎、NoSQL DB、CEP 等等，本章主要讲一些风控的基本概念。在大数据侧，我们把风控划分成 3 × 2 的关系：2 代表风控要么是基于规则的，要么是基于算法或模型的；3 代表包括三种风控类型：事先风控、事中风控和事后风控。1.1 三种风控业务对于事中风控和事后风控来讲，端上的感知是异步的，对于事先风控来讲，端上的感知是同步的。对于事先风控这里稍做一些解释，事先风控是把已经训练好的模型或者把已经计算好的数据存在 Redis 、MongoDB 等数据库中；一种方式是端上有类似 Sidden 、Groovy 、Drools 这样的规则引擎直接去 Redis 、MongoDB 取数据来返回结果；另外一种方式是基于 Kubeflow KFserving ，端上请求过来之后基于训练好的算法和模型返回结果。整体来讲这两种方式的时延都在 200 毫秒左右，可以作为一个同步的 RPC 或 HTTP 请求。对于 Flink 相关的大数据场景是一个异步的风控请求，它的异步时效性非常低，通常是一秒或者两秒。如果追求超低时延，则可以认为它是一种事中的风控，风控决策过程可以由机器介入处理。很常见的一种类型是用 Flink SQL 做指标阈值的统计、用 Flink CEP 做行为序列规则分析，还有一种是用 Tensorflow on Flink ，在 Tensorflow 中进行算法描述，然后用 Flink 来执行 Tensorflow 规则的计算。1.2 Flink 是规则风控最佳选择目前 Flink 是阿里集团内的风控最佳选择，主要有三个原因：事件驱动毫秒级的延迟流批一体1.3 规则风控三要素在规则风控里面有三个要素，后面讲的所有内容都是围绕这三者展开的：事实 Facts：是指风控事件，可能来自业务方或者日志埋点，是整个风控系统的输入；规则 Rules：往往是由业务侧来定义，即这个规则要满足什么样的业务目标；阈值 Threshold：规则所对应描述的严重程度。1.4 Flink 规则表达增强对于 Flink 来说，可以分成无状态规则和有状态规则两类，其中有状态规则是 Flink 风控的核心：无状态规则：主要是做数据的 ETL，一种场景是当某个事件的一个字值段大于 X 就触发当前的风控行为；另一种场景是 Flink 任务的下游是一个基于模型或算法的风控，在 Flink 侧不需要做规则判断，只是把数据向量化、归一化，例如多流关联、Case When 判断等把数据变成 0/1 的向量，然后推送到下游的 TensorFlow 做预测。有状态规则：统计型规则：基于统计分析的计算规则，比如 5 分钟以内访问次数大于 100 次，则认为触发了风控；序列型规则：事件序列中，某事件对前序后序事件有影响，比如点击、加入购物车、删掉三个事件，这种连续的行为序列是一个特殊行为，可能认为这个行为在恶意降低商家商品的评价分数，但这三个事件独立来看并不是一个风控事件；阿里云实时计算 Flink 完善了基于序列的规则能力，为云上和集团内的电商交易场景提供技术护航；混合型规则：统计型和序列性两者组合。二、阿里风控实战本章主要介绍阿里在工程上是如何满足上面提到的风控三要素。从整体的技术来看，目前分成感知、处置和洞察三个模块：感知：目的是感知所有的异常以及提前发现问题，比如捕捉一些与常见数据分布不同的数据类型，并输出这种异常的列表；又比如说某年因为骑行政策的调整头盔销售量升高，连带着就会出现相关产品的点击率、转化率上升，这种情况需要及时被感知捕捉到，因为它是一个正常的行为而非作弊；处置：即如何做规则的执行，现在有小时、实时、离线三道防线，相比于之前单条策略的匹配，关联和集成之后的准确性会更高，比如就关联最近一段时间内某些用户的持续行为来进行综合研判；洞察：为了发现一些当前没有感知，同时也没有办法直接用规则描述的风控行为，比如风控需要对样本进行高度抽象来进行表示，要先投影到合适的子空间，然后再结合时间维度在高维里面发现一些特征来做新异常的识别。2.1 阶段一：SQL 实时关联 & 实时统计在这个阶段有一个基于 SQL 评价风控系统，用简单的 SQL 做一些实时的关联、统计，比如用 SQL 进行聚合操作 SUM(amount) > 50 ，其中规则就是 SUM(amount)，规则对应的阈值是 50；假设现在有 10、20、50、100 这 4 种规则同时在线上运行，因为单Flink SQL作业只能执行一种规则，那么就需要为这4个阈值分别申请 4 个 Flink Job。优点是开发逻辑简单，作业隔离性高，但缺点是极大浪费计算资源。2.2 阶段二：Broadcast Stream阶段一的风控规则主要问题是规则和阈值不可变，在 Flink 社区目前会有一些解决方案，比如基于 BroadcastStream 来实现，在下面的图中 Transaction Source 负责事件的接入，Rule Source 则是一个BroadcastStream，当有新的阈值时可以通过 BroadcastStream 广播到各个算子。举个例子，判断在一分钟以内连续访问超过 10 次的风控对象，但是在 618 或双 11 可能要把它变成 20 或 30 次，才会被风控系统下游的在线系统感知到。如果在第一阶段的话，只有两种选择：第一种是所有的作业全量在线上跑；第二种是在某一刻停止掉一个Flink作业，新拉起一个基于新指标的作业。如果是基于 BroadcastStream 就可以实现规则指标阈值的下发，直接修改线上指标阈值而不需要作业重启。2.3 阶段三：Dynamic CEP阶段二的主要问题是只能做到指标阈值的更新，虽然它极大的方便了个业务系统，但实际上很难满足上层业务。诉求主要有两个：结合 CEP 以实现行为序列的感知；结合 CEP 后依然能做到动态修改阈值甚至是规则本身。阶段三，阿里云 Flink 做了 CEP 相关的高度抽象，解耦了 CEP 规则和 CEP 执行节点，也就是说规则可以存在 RDS、Hologres 等外部第三方存储里，CEP 作业发布上去之后，就可以加载数据库中的 CEP 规则来做到动态替换，因此作业的表达能力会增强。其次是作业的灵活性会增强，比如想看到某一个 APP 下面的一些行为并对这个行为的指标阈值做更新，可以通过第三方存储更新 CEP 规则而非 Flink 本身。这样做还有一个优势是可以把规则给暴露给上层业务方，来让业务真真正正的撰写风控规则，我们成为一个真正的规则中台，这就是动态 CEP 能力所带来的好处。在阿里云的服务中，动态 CEP 能力已经被集成在最新版本中，阿里云全托管 Flink 服务极大的简化了风控场景的开发周期。2.4 阶段四：Shared Computing在阶段三的基础上再往前一步，阿里云实践出 "共享计算" 的解决方案。这套共享计算的方案中，CEP 规则完全可以被建模平台来描述，暴露给上层客户或业务方一个非常友好的规则描述平台，可以通过类似拖拉拽或者其他的方式进行耦合，然后在调度引擎上选择事件接入源来运行规则。比如现在两个建模都是服务于淘宝 APP，完全可以落到同一个 Fact 的 Flink CEP 作业上，这样就可以把业务方、执行层和引擎层完全解耦。当前阿里云共享计算的解决方案已经非常成熟，有丰富的客户落地实践。2.5 阶段五：业务开发和平台建设分离在引擎侧、平台侧和业务侧三方之间，阶段四可以做到引擎侧和平台侧之间的解耦，但是对业务侧来讲依然是高度绑定的。两者的工作模式依然是甲方和乙方的协同关系，即 业务侧掌握着业务规则，平台侧接受业务团队的风控需求，从而进行风控规则的开发。但平台团队通常人员优先，而业务团队随着业务发展会越来越壮大。这个时候业务侧本身可以抽象出来一些基本概念，沉淀出一些业务共性的规范，并组装成一个比较友好的 DSL ，然后通过阿里云完全解耦的 Open API 实现作业的提交。由于要同时支持集团内接近 100 个 BU，没有办法为每一个 BU 都做定制化的支持，只能把引擎的能力尽可能的开放出去，然后业务侧通过 DSL 的封装提交到平台上，真正做到了只暴露一个中台给客户。三、大规模风控技术难点本章主要介绍一些大规模风控的技术难点，以及阿里云在全托管 Flink 商业化产品中如何突破这些技术难点。3.1 细粒度资源调整在流计算系统中，数据源往往不是阻塞的节点。上游的数据读取节点由于没有计算逻辑不存在性能问题，下游的数据处理节点才是整个任务的性能瓶颈。由于 Flink 的作业是以 Slot 来做资源划分的，默认 Source 节点和工作节点具有相同的并发度。在这种情况下我们希望可以单独调整 Source 节点和 CEP 工作节点的并发度，比如在下图中可以看到某个作业的 CEP 工作节点并发度可以达到 2000，而 Source 节点则只需要 2 个并行度，这样可以极大的提升 CEP 节点的工作性能。另外是对 CEP 工作节点所在的 TM 内存、CPU 资源的划分，在开源 Flink 中 TM 整体同构的，也就是说 Source 节点和工作节点是完全相同的规格。从节省资源的角度考虑，真实生产环境下 Source 节点并不需要 CEP 节点一样多的内存、CPU 资源， Source 节点只需要较小的 CPU 和内存就已经能够满足数据抓取。阿里云全托管 Flink 可以实现让 Source 节点和 CEP 节点运行在异构的 TM 上，即 CEP 工作节点 TM 资源显著大于 Source 节点 TM 资源，CEP 工作执行效率会变得更高。考虑细粒度资源调整带来的优化，云上全托管服务相比自建 IDC Flink 可节约 20% 成本。3.2 流批一体 & 自适应 Batch Scheduler流引擎和批引擎如果没有采用相同一套执行模式往往会遇到数据口径不一致的情况，出现这种问题的原因是流规则在批规则下很难真正的完全描述出来；比如在 Flink 中有一个特殊的 UDF，但是在 Spark 引擎中却并没有对应的 UDF。当这种数据口径不一致的时候，选择哪一方面的数据口径就成为了一个非常重要的问题。在 Flink 流批一体的基础上，用流模式描述的 CEP 规则，完全可以在批模式下以相同的口径再跑一次并得到一样的结果，这样就不需要再去开发批模式相关的 CEP 作业。在此之上，阿里实现了自适应的 Batch Scheduler。其实 CEP 规则每天的效果产出并不一定是均衡的，比如说今天的行为序列中并没有任何异常行为，下游只有很少的数据输入，此时会为批分析预留一个弹性的集群；当 CEP 的结果很少时，下游的批分析只需要很小的资源，甚至每个批分析工作节点的并行度都不需要在一开始的时候就指定，工作节点可以根据上游数据的输出以及任务负载来自动调整批模式下的并行度，真正做到了弹性批分析，这是阿里云 Flink 流批一体 Batch Scheduler 的独特优势。3.3 合并读取降低公共层压力这是在实践中遇到的问题，当前的开发模式基本都是基于数据中台的，比如实时数仓。在实时数仓的场景下，数据源可能不会很多，但是中间层 DWD 会变得很多，中间层可能会被演化成很多 DWS 层，甚至也会演变成很多数据集市给到各个部门来使用，这种情况下单表的读取压力会很大。通常多个源表彼此关联（打宽）从而形成一个 DWD 层 ，从单个源表的视角看，它会被多个 DWD 表依赖。DWD 层也会被多个不同业务域的作业消费形成 DWS。基于这种情况阿里实现了基于 Source 的合并，只需要读一次 DWD 在 Flink 侧会帮你加工成多张业务域的 DWS 表，可以非常大的减缓对公共层的执行压力。3.4 KV 分离设计的状态后端CEP 节点在执行的时候，会涉及到非常大规模的本地数据读取，尤其是在行为序列的计算模式下，因为需要缓存前面所有的数据或者是一定时间内的行为序列。在这种情况下，比较大的一个问题是对后端状态存储（比如：RocksDB）有非常大的性能开销，进而会影响 CEP 节点的性能。目前阿里实现了 KV 分离设计的状态后端，阿里云 Flink 默认使用 Gemini 作为状态后段，CEP 场景下实测性能至少有 100% 的提升。3.5 维度数据分区加载风控在很多情况下是要基于历史行为来做分析的，历史的行为数据一般都会存在 Hive 或 ODPS 表里，这个表的规模可能是 TB 级别的。开源的 Flink 默认需要在每一个维表节点上加载这个超级大的维度表，这种方式实际上是不现实的。阿里云实现了基于 Shuffle 来做内存数据的分割，维表节点只会加载属于当前这个 Shuffle 分区的数据。四、阿里云 Flink FY23 风控演进计划对于阿里云整体来讲，FY23 的演进计划包括如下内容：表达力增强观测性增强执行能力增强性能增强欢迎使用云产品进行体验，多提意见，共同进步。点击查看直播回放 & 演讲PPT2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-05
字节跳动 Flink 状态查询实践与优化
摘要：本文整理自字节跳动基础架构工程师，Apache Flink Contributor 马越在 Flink Forward Asia 2021 平台建设专场的演讲。主要内容包括：背景State Processor API 介绍StateMeta Snapshot 机制State as Database使用 Flink Batch SQL 查询任务状态未来展望点击查看直播回放 & 演讲PDF一、背景众所周知，Flink 中的 State 保存了算子计算过程的中间结果。当任务出现异常时，可以通过查询任务快照中的 State 获取有效线索。但目前对于 Flink SQL 任务来说，当我们想要查询作业 State 时，通常会因为无法获知 State 的定义方式和具体类型等信息，而导致查询 State 的成本过高。为了解决这个问题，字节跳动流式计算团队在内部提出了 State Query on Flink SQL 的解决方案——用户通过写 SQL 的方式就可以简单地查询 State。本文将主要介绍字节跳动在 Flink 状态查询这方面所进行的相关工作。二、State Processor API 介绍提到状态查询，我们自然会联想到 Flink 在 1.9 版本提出的特性 -- State Processor API。使用 State Processor API，我们可以将作业产生的 Savepoint 转换成 DataSet，然后使用 DataSet API 完成对 State 的查询、修改和初始化等操作。下面简单介绍一下如何使用 State Processor API 来完成 State 的查询：首先创建 ExistingSavepoint 用来表示一个 Savepoint。初始化 ExistingSavepoint 时需要提供 Savepoint 路径和 StateBackend 等信息；然后实现 ReaderFunction 用于重新注册所需要查询的 State 以及定义处理 State 的方式。查询状态的过程中会遍历所有的 Key 并按照我们定义的方式去操作 State；最后，调用 Savepoint.readKeyedState 并传入算子的 uid 和 ReaderFunction，就可以完成 State的查询。接下来为大家简述一下 State 查询背后的原理。在 Savepoint 目录中包含两种文件，一种是状态数据文件，比如上图中的 opA-1-state ，这个文件里面保存着算子 A 在第一个 SubTask 状态的明细数据；还有一种元数据文件，对应上图中的 _metadata，元数据文件中保存了每个算子和状态文件的映射关系。当我们在进行状态查询的时候。首先在 Client 端会根据 Savepoint 路径去解析 metadata 文件。通过算子 ID，可以获取需要查询的状态所对应的文件的句柄。当状态查询真正执行时，负责读取状态的 Task 会创建一个新的 StateBackend，然后将状态文件中的数据恢复到 Statebackend 中。等到状态恢复完成之后就会遍历全部的 Key 并把对应的状态交给 ReaderFunction 处理。有些同学可能会问，既然社区已经提供了查询 State 的功能，我们为什么还要去做同样的工作呢？主要是因为我们在使用 State Processor API 的过程中发现一些问题：每次查询 State 我们都需要独立开发一个 Flink Batch 任务，对用户来说具有一定的开发成本；实现 ReaderFunction 的时候需要比较清晰地了解任务状态的定义方式，包括 State 的名称、类型以及 State Descriptor 等信息，对用户来说使用门槛高较高；使用 State Processor API 时，只能查询单个算子状态，无法同时查询多个算子的状态；无法直接查询任务状态的元信息，比如查询任务使用了哪些状态，或者查询某个状态的类型。总体来说，我们的目标有两个，一是降低用户的使用成本；二是增强状态查询的功能。我们希望用户在查询 State 时能用最简单的方式；同时也不需要知道任何信息。此外，我们还希望用户能同时查询多个算子的 State ，也可以直接查询作业使用了哪些 State，每个 State 的类型是什么。因此，我们提出了 State Query on Flink SQL 的解决方案。简单来说是把 State 当成数据库一样，让用户通过写 SQL 的方式就可以很简单地查询 State。在这个方案中，我们需要解决两个问题：如何对用户屏蔽 State 的信息：参考 State Processor API 我们可以知道，查询 State 需要提供非常多的信息，比如 Savepoint 路径、 StateBacked 类型、算子 id 、State Descriptor 等等。通过 SQL 语句显然难以完整地表述这些复杂的信息，那么查询状态到底需要哪些内容，我们又如何对用户屏蔽 State 里复杂的细节呢？这是我们面对的第一个难点。如何用 SQL 表达 State：State 在 Flink 中的存储方式并不像 Database 一样，我们如何去用 SQL 来表达状态的查询过程呢？这是我们要解决的另一个难点。三、StateMeta Snapshot 机制首先我们来回答第一个问题，查询一个 State 需要哪些信息呢 ？可以参考上文中 State Processor API 的示例，当我们创建 ExistingSavepoint 和 ReaderFunction 的时候，我们需要提供的信息有 Savepoint 路径、Backend 类型、OperatorID、算子 key 的类型、State 名称以及 Serializer 等等，我们可以将这些统一称为状态的元信息。对于 Flink SQL 任务来说，要清楚地了解这些信息，对用户来说门槛是非常高的。我们的想法是让用户只需要提供最简单的信息，即 Savepoint ID ，然后由 Flink 框架把其他的元信息都存在 Savepoint 中，这样就可以对用户屏蔽 State 那些复杂的细节，完成状态的查询。因此，我们引入了 StateMeta Snapshot 机制。StateMeta Snapshot 简单来说就是把状态的元信息添加到 Savepoint Metadata 的过程，具体步骤如下：首先在 State 注册的时候，Task 会把 operatorName\ID\KeySerializer\StateDescriptors 等元信息都保存在 Task 的内存中；触发 Savepoint 时，Task 会在制作快照的同时，对状态的元信息也同样进行快照。快照完成之后将状态的元信息 (StateMeta) 和状态文件的句柄 (StateHandle) 一起上报给 JobManager；JobManager 在收到所有 Task 上报的 StateMeta 信息之后 ，将这些状态元信息进行合并，最后会把合并之后的状态元信息保存到 Savepoint 目录里名为 stateInfo 的文件中。之后在状态查询时就只需解析 Savepoint 中的 stateInfo 文件，而不再需要用户通过代码去输入这些 State 的元信息。通过这样的方式可以很大程度地降低用户查询状态的成本。四、State as Database接下来我们来回答第二个问题，我们如何用 SQL 来表达 State。其实社区在设计 State Processor API 的时候就提出了一些解决思路，也就是 State As Database。 在传统的数据库中，通常用 Catalog、Database、Table 这个三个元素来表示一个 Table，其实我们也可以将用样的逻辑到映射到 Flink State 上。我们可以把 Flink 的 State 当作一种特殊的数据源，作业每次产生的 Savepoint 都当作一个独立 DB 。在这个 DB 中，我们将 State 元信息、State 的明细数据，都抽象成不同的 Table 暴露给用户，用户直接查询这些 Table 就可以获取任务的状态信息。首先我们来看如何把 State 表示为 Table。我们都知道在 Flink 中，常用的 State 有两种类型，分别是 KeyedState 和 OperatorState。对于 OperatorState 来说，它只有 Value 这一个属性，用来表示这个 State 具体的值。因此我们可以把 OperatorState 表示为只包含一个 Value 字段的表结构。对于 KeyedState 来说，每个 State 在不同的 Key 和 Namespace 下的值可能都不一样， 因此我们可以将 KeyedState 表示为一个包含 Key、Namespace、Value 这三个字段的表结构。当我们抽象出了单个 State 之后，想要表示多个 State 就比较容易了。可以看到在上图的例子中，这个算子包含 3 个 State，分别是两个 KeyedState 和一个 OperatorState，我们只需要将这些 Table 简单的 union 起来，再通过 state_name 字段去区分不同的 State，就可以表示这个算子中所有的 State。最后还有一个问题，我们如何知道一个任务到底用了哪些 State 或者这些 State 的具体类型呢？为了解决这个问题，我们定义了一种特殊表 -- StateMeta ，用来表示一个 Flink 任务中所有 State 的元信息。StateMeta 中包含一个任务中每个 State 的名称、State 所在的算子 ID 、算子名称 、Key 的类型和 Value 的类型等等，这样用户直接查询 StateMeta 这个表就能获取任务中所有状态的元信息。五、使用 Flink Batch SQL 查询任务状态以上就是状态查询方案的整体介绍。那我们到底如何去查询一个 State 呢，我们以一个 Word Count 任务为例来说明。首先，我们需要创建一个 Flink SQL 任务并启动。通过 web-ui 可以看到这个任务中包含三个算子，分别是 Source，Aggregate 还有 Sink。然后，我们可以触发 Savepoint，当 Savepoint 制作成功之后获取对应的 SavepointID。我们可以通过 SavepointID 去完成作业状态的查询。假如我们现在对 Flink SQL 任务中状态的使用一无所知，那么首先我们需要查询的就是这个 Flink 任务中包含哪些 State 以及这些 State 的类型。我们可以从 StateMeta 表获取这些信息。如上图中场景一所示，通过查询 StateMeta 表，可以看到这个任务包含一个 ListState 和一个 ValueState，分别存在于 Source 算子和 Aggregate 算子中。此外，有些对 Flink 比较了解的同学知道，KafkaSource 中的 State 是用于记录当前消费的 Offset 信息。如场景二所示，我们可以通过查询 Source 算子的状态，获取到任务中消费 Kafka Topic 的 Partition 和 Offset 信息。还有一种比较常见的场景，比如下游的业务同学发现某个 key（比如 key_662）的结果异常。我们在定位问题的时候可以直接去查询作业中 aggregate 算子中的状态，同时去指定 key 等于 key_662 作为查询条件。如上图场景三所示，通过查询的结果可以看到，当 key 为 662 时对应的聚合结果是 11290。用户使用这样的方式就可以比较方便地验证状态是否正确。六、未来展望未来，我们计划进一步丰富 State 的功能，目前我们支持了使用 SQL 查询 State 的功能 ，其实社区还提供了 State 修改和初始化的能力。在一些场景下，这些能力也比较重要。比如，我们已知状态中的部分 key 计算错误，希望将状态中这部分的数据进行修正；或者任务逻辑发生变更以后和之前的状态不能完全兼容， 这个时候我们希望可以通过状态修改和初始化的能力去生成一个新的 Savepoint。同样，在使用方式上我们也希望用户能直接使用 SQL 中 insert 和 update 语法来完成状态的修改和初始化操作。其次，我们会进一步加强 State 的可用性。我们使用 DAG 编辑的方案解决了作业拓扑发生变化时产生的状态不兼容问题，但是当 Flink SQL 任务修改字段时 State Serializer 可能会变化，同样导致状态无法兼容。针对这种情况我们设计了完整的 Flink SQL State Schema Evolution 方案，可以极大的增强 Flink SQL 任务发生变化之后状态的恢复能力，目前方案正在落地中。此外，我们还提供了完善的状态恢复事前检查能力，能够做到在任务上线之前就检查出状态是否兼容并告知用户，避免状态不兼容引起的作业启动失败对线上造成影响。点击查看直播回放 & 演讲PDF2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网了解报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-08-02
中原银行实时风控体系建设实践
摘要：本文整理自中原银行数据平台中心开发工程师陈玉强在 Flink Forward Asia 2021 行业实践专场的演讲。主要内容包括：建设体系选型 & 架构应用场景建设成效点击查看直播回放 & 演讲PDF一、建设体系银行是经营风险的企业，对风险进行识别、衡量、定价和防范的能力是银行核心竞争力。中原银行构建了面向反欺诈、信用风险、运营风险的业务全流程风控体系。银行业务的申请、交易、营销等环节都可能存在欺诈行为，随着技术发展，在欺诈行为团伙化、隐蔽化、专业化、实时化情况下进行反欺诈难度越来越大。同时，随着业务种类增多，传统的专家规则评分卡模型难以应付复杂的风控场景，需要借助大数据、实时计算、机器学习、知识图谱等高新技术打造高质量的授信能力。此外，是否能够及时发现和化解业务运营风险，包括流程风险、员工异常行为、资产及负债流动性风险也面临较大挑战。传统技术应对这些挑战时难以实时获取用户多渠道的操作行为，难以达到全方位、实时化的防控效果。传统风控体系普遍基于专家规则进行测算，存在规则触发阈值难以控制、吸收低饱和噪音数据难度大等特点，很难通过累计规则数量来提升精准度。此外，传统系统间相对孤立、数据流通难度大、数据孤岛的情况导致了专家规则制定和模型训练难度大，不利于整体风控效果。新的风控体系首先实现了实时化，通过流计算、内存计算等技术提高数据处理的时效性，做到了及时识别跨系统的风险行为，并通过云原生、资源弹性等技术提高系统的高并发能力。在提升硬实力的同时更注重智能化，将基于概率的机器学习模型与专家规则结合，充分释放大数据价值，避免专家规则经验盲区。此外，通过打造平台化的产品，形成不同场景的快速支撑能力和完善的风控体系。近三年我们经历了对实时计算的探索、尝试和平台化建设，并将实时计算技术应用至反欺诈、事件驱动、实时 OLAP 等多种场景，2021 年底任务数量和日均处理数据量都提升数倍。在风控方面，经历了从引入国外决策系统到自研决策平台的转变，2021 年自研决策平台已经开始承接新需求和部分国外决策系统迁移而来的规则模型。智能风控体系能力模型可以总结为：风险特征识别及计算实时化；融合专家规则与机器学习模型通过复杂编排提供智能化的决策能力；通过平台化屏蔽技术细节，给用户提供友好的使用体验。在风控体系中通过标准化来制定规范、构建数据标准和开放数据能力。并通过构建 ModelOps 管理体系实现风险模型从需求到投产的全生命周期管理。此外，通过低代码、可视化的方式有助于降低使用门槛。二、选型 & 架构在本体系架构中，Flink 主要用于数据清洗、实时维表加工与关联以及窗口计算等场景，通过预计算、内存计算、聚合计算实现基础指标、衍生指标、复合指标的加工，为决策模型提供特征支持。模型编排专注于编排决策集、评分卡、决策树、决策表等丰富和易用规则模型，同时在规则中可以调用指标服务、算法模型服务共同参与逻辑运算。风控体系基于云原生架构和开源技术实现，支持报文、接口、多种类型数据库。通过数据源、维表、参数配置界面化，并支持用户用 Flink SQL 编写业务逻辑，极大程度降低了实时计算的使用门槛。通过可视化编排 (DAG) 将规则/模型/指标引擎的计算能力进行组合以支撑风控决策。此外还有一些特色功能，如 SQL 评分、网关分流等。实时指标可以用于专家规则，实时特征可以供在线 (online) 模型训练。机器学习平台使用离线 (offline) 数据进行模型训练和模型推理，同时结合规则筛选出来的风险数据，基于离线数据进行有监督和无监督的算法训练。三、应用场景反欺诈是交易的重要环节，通常会基于黑白名单、知识图谱、司法、税务、工商等内外部数据对交易数据打宽，打宽后的数据用于专家规则和机器学习模型。交易发起系统会根据智策平台的决策结果对交易放行或加强验证。风险结果数据可作为样本，用于图数据进行关联挖掘或特征分析，或者用于有监督学习。技术实现方面，针对交易请求，智策平台会根据 DAG 编排逻辑来调用不同的计算引擎，并返回计算结果。同时，实时计算平台会使用交易系统数据库的变化数据计算交易/行为等实时指标。此外，历史数据会被抽取到离线数仓和数据湖中，供下游的机器学习平台使用。对授信狭义且简单的理解就是金融机构向客户提供资金的行为。智策平台通过评分卡、决策集等方式承载了贷前阶段 50 余个场景，日均接收授信请求约 3 万笔；对于以批量数据处理为主的贷中、贷后环节，日均处理数据 1300 万条。授信场景较交易反欺诈场景在技术架构明显的差异在于它需要外部数据支持。智策平台将关联了内外部数据的交易变量进行专家规则运算、机器学习模型推理。授信场景暂时没有使用实时指标。员工行为、信贷管理、舆情分析都在运营风险的范畴内，将冲正行为、机具管理等场景数据加工成离线运营风险指标，将高敏感行为数据加工为实时指标，通过智策平台对两类指标进行规则、模型运算而得出预警结果，进而形成风险核查事件、名单等。结果数据也会作为风险特征样本来训练算法和挖掘风险。运营风险的技术架构比较直观，每天将历史业务数据同步到数据仓库，在数仓中完成风险指标的加工，同时离线数据也会被用于模型训练。智策平台每天定时对离线指标进行规则运算，并将风险预警结果推送给下游运营系统。四、建设成效业务成效方面，反欺诈系统对接了 14 个渠道，105 类场景，在传统反欺诈技术上引入流计算实现实时反欺诈，助力管控了 1 万多高危账户，协助阻断转出资金超千万元，实现了全年线上交易零欺诈损失。授信方面，支撑了全周期的信贷场景，包括额度评估、风险定价、贷后预警等 50 多个场景，每天处理进件 3 万余笔。每天批量处理运营指标数据 30 余万，同时通过 Flink 每天实时处理员工行为数据约 3000 万条，具备实时发现内部的高风险行为的能力。技术成效方面，智策平台每天接收业务交易请求 5 万余笔，响应时间约 8 毫秒 (最新数据)。规则和模型编排场景响应时间小于 3 秒，每天处理批量数据约 1800 万条。实时计算平台日均处理数据 2.7TB，较年初增长了 5 倍。在平台化基础上，本体系具备灵活编排专家规则和机器学习模型的能力，每天调用机器学习模型服务超过 2 万次。公司简介：中原银行是河南省唯一的省级法人银行，截止 2021 年 6 月 30 号，总资产为 7530.02 亿。中原银行在收获众多荣誉的同时也在不断自我超越，在知名的《银行家》、《财富》等排行榜中的排名较往年都有提升。点击查看直播回放 & 演讲PDF2022第四届 实时计算FLINK挑战赛49万奖金等你来拿！延续 “鼓励师计划”，赢取丰厚礼品！点击进入赛事官网了解报名参赛更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-07-27
Beyond Stream Processing ！第四届实时计算 Flink 挑战赛启动，49 万奖金等你来拿！
欢迎点击赛事官网了解更多信息生活中的事件都可以通过实时计算来解决，以 Flink 为工具解决一个实际问题，成为了今年实时计算 Flink 挑战赛的赛题。小到日常学习、工作、生活中的点滴琐事，大到城市管理、金融交易、疫情防控等国计民生，都可以成为你的选题。Beyond Stream Processing——第四届实时计算 Flink 挑战赛正式启动！连续三年，挑战赛的命题涉及日常生活中的方方面面。比如通过运用 Flink，Analytics Zoo，Proxima 等平台和技术，引导选手在垃圾分类，实时疫情追踪等热点民生问题上进行了思考和创新；去年更是和阿里巴巴人工智能治理与可持续发展实验室（AAIG）一起开辟了数据安全赛题，首次公开了 100 万流量作弊识别真实数据集！并应用 Intel SGX 加密技术保障风控模型数据安全。今年，阿里云将携手英特尔启用全新的 Hackathon 模式举办此次比赛，采用开放式命题形式，旨在探索 Flink 在应用实践中的更多可能性。大赛组委会将按需为每组选手提供由第三代英特尔®至强®可扩展处理器助力的阿里云 ECS 云服务器，用于开发、测试及 Demo 展示。本届比赛将继续面向全社会开放，个人、高等院校、科研单位、企业、创客团队等人员均可报名参赛。赛题背景作为全球顶级的开源大数据处理引擎，Apache Flink 一方面在实时计算领域保持着技术领先优势，另一方面随着流批一体、流式数仓等理念的提出也在向更多应用场景辐射。参赛选手可以充分发挥想象力、创造力，以 Flink 为工具解决一个实际问题。大赛尤其鼓励能够结合所选题目的特点，对 Flink 本身做出创新和改进的参赛作品。选手需要使用（但不仅限于使用）Flink 及其生态里的各种工具，包括各类 Connector、Table Store、机器学习、复杂事件处理、Stateful Functions 等来完成自己的参赛作品。赛程安排本次大赛分为初赛、评审和决赛三个阶段，时间安排如下：报名与实名认证（即日起—2022年10月20日，UTC+8）参赛项目提交（即日起—2022.10.20，UTC+8）初赛评审（2022.10.20-2022.11.1，UTC+8）初赛放榜（2022.11.5，UTC+8）决赛准备与辅导（2022.11.6-2022.11.26，UTC+8）现场决赛（暂定 2022.12，UTC+8）初赛阶段，参赛队伍需要把自己的项目方案打包提交至天池项目后台，专家评审组会进行作品评审，根据评审结果，选择出决赛入围队伍名单。会从参赛作品的完成度、难度、与 Flink 结合程度、创新性、实用性、评委个人意见等维度给出评分。进入决赛后，组委会会安排决赛辅导期。决赛辅导和现场决赛阶段，大赛组委会将按需为每组选手提供由第三代英特尔®至强®可扩展处理器助力的阿里云 ECS 云服务器，用于开发、测试及 Demo 展示。现场决赛团队需提前按照要求准备答辩 PPT，评委会将采用打分方式选出获奖作品。活动激励据悉，本次大赛最终将产生冠军队伍 1 支，奖金 10 万人民币；亚军队伍 2 支，奖金各 8 万人民币；季军队伍 3 支，奖金各 5 万人民币及最佳实践、最佳创意两个奖项，每个队伍 2 支，奖金 2 万人民币。冠军：1 支队伍，每支队伍奖金 10 万亚军：2 支队伍，每支队伍奖金 8 万季军：3 支队伍，每支队伍奖金 5 万最佳创意：2 支队伍，每支队伍奖金 2 万最佳实践：2 支队伍，每支队伍奖金 2 万同时，本次大赛在报名阶段还将延续上一届的 “鼓励师计划” 玩法，成功邀请小伙伴参赛即可成为鼓励师赢取丰厚的礼品！（礼品可通过天池粮票兑换）天池粮票 礼品 650定制大号鼠标垫1800阿里云定制卫衣3000Flink定制双肩包欢迎点击赛事官网了解更多信息更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-07-26
Flink 在 讯飞 AI 营销业务的实时数据分析实践
摘要：本文整理自科大讯飞中级大数据工程师汪李之在 Flink Forward Asia 2021 的分享。本篇内容主要分为四个部分：业务简介数仓演进场景实践未来展望点击查看直播回放 & 演讲PDF一、业务简介构建实时数据分析平台是为了更好的解决业务对更高数据时效性的需求，先简单介绍一下业务流程。从日常的场景说起，当我们打开手机 APP 时，常会看到广告。在这样一个场景中，涉及到了两个比较重要的角色。一是手机 APP，即流量方；另一个是投广告的广告主，如支付宝、京东会投放电商广告。广告主购买流量方的流量投广告就产生了交易。讯飞构建了一个流量交易平台，流量交易平台主要的职能是聚合下游流量，上游再对接广告主，从而帮助广告主和流量方在平台上进行交易。讯飞还构建了投放平台，这个平台更侧重于服务广告主，帮助广告主投放广告，优化广告效果。在上述的业务流程图中，APP 与平台交互时会向平台发起请求，然后平台会下发广告，用户随后才能看到广告。用户看到广告的这个动作称之为一次曝光，APP 会把这次曝光行为上报给平台。如果用户点击了广告，那么 APP 也会上报点击行为。广告在产生之后发生了很多行为，可以将广告的整个过程称为广告的一次生命周期，不仅限于图中的请求、曝光、点击这三次行为，后面可能还有下单、购买等。在这样一个业务流程中，业务的核心诉求是什么呢？在广告的生命周期中有请求、曝光和点击等各种行为，这些行为会产生对应的业务日志。那么就需要从日志生成数据供业务侧分析，从日志到分析的过程中就引入了数仓构建、数仓分层，数据呈现的时效性就带来了实时数据仓库的发展。二、数仓演进上图是一个典型的数仓分层框架，最底层是 ODS 数据，包括业务日志流、OLTP 数据库、第三方文档数据。经过 ETL 将 ODS 层的数据清洗成业务模型，也就是 DWD 层。最初是建立了 Spark 数仓，将业务日志收集到 Kafka 中再投递到 HDFS 上，通过 Spark 对日志进行清洗建模，然后将业务模型再回写到 HDFS 上，再使用 Spark 对模型进行统计、分析、输出报表数据。后续，讯飞沿用了 Spark 技术栈引入了 spark-streaming。随后逐渐将 spark-streaming 迁移到了 Flink 上，主要是因为 Flink 更高的时效性和对事件时间的支持。当初 spark-streaming 的实践是微批的，一般设置 10 秒或是 30 秒一批，数据的时效性顶多是秒级的。而 Flink 可以支持事件驱动的开发模式，理论上时效性可以达到毫秒级。当初基于 spark-streaming 的实时数据流逻辑较为简陋，没有形成一个数仓分层的结构。而 Flink 可以基于 watermark 支持事件时间，并且支持对延迟数据的处理，对于构建一个业务逻辑完备的数仓有很大的帮助。由上图可见，ODS 的业务日志收集到 Kafka 中，Flink 从 Kafka 中消费业务日志，清洗处理后将业务模型再回写到 Kafka 中。然后再基于 Flink 去消费 Kafka 中的模型，提取维度和指标，统计后输出报表。有些报表会直接写到 sql 或 HBase 中，还有一些报表会回写到 Kafka 中，再由 Druid 从 Kafka 中主动摄取这部分报表数据。在整个数据流图中 Flink 是核心的计算引擎，负责清洗日志、统计报表。三、场景实践3.1 ODS - 日志消费负载均衡ODS 业务中，请求日志量级大，其他日志量级小。这样请求日志（request_topic）在 Kafka 上分区多，曝光和点击日志（impress/click_topic）分区少。最初是采用单 source 的方法，创建一个 FlinkKafkaConsumer011 消费所有分区，这可能导致 task 消费负载不均。同一 topic 的不同分区在 task 上可均匀分配，但不同 topic 的分区可能会被同一 task 消费。期望能达到的消费状态是：量级大的 topic，其 task 和 partition 一一对应，量级小的 topic 占用剩下的 task。解决方法是把单 source 的消费方式改成了多 source union 的方式，也就是创建了两个 consumer，一个 consumer 用来消费大的 topic，一个 consumer 用来消费小的 topic，并单独为它们设置并行。3.2 DWD - 日志关联及状态缓存DWD 是业务模型层，需要实现的一个关键逻辑是日志关联。基于 sid 关联广告一次生命周期中的不同行为日志。业务模型记录了 sid 级别的维度和指标。最初是基于 30s 的 window 来做关联，但这种方式会导致模型输出较第一次事件发生延迟有 30s，并且 30s 仅能覆盖不到 12% 的曝光日志。如果扩大窗口时间则会导致输出延迟更多，并且同一时刻存在的窗口随时间增长，资源消耗也比较大。后续改成了基于状态缓存的方式来实现日志关联，即 ValueState。同一 sid 下的日志能够访问到相应的 ValueState。不过为保证及时输出，将请求、曝光、点击等不同指标，拆分到了多条数据中，输出的数据存在冗余。随着业务的增长和变化，需要缓存的状态日益变大，内存已无法满足。于是我们将状态从内存迁移至 HBase 中，这样做的好处是支持了更大的缓存，并且 Flink checkpoint 负载降低。但同时也带来了两个问题：引入第三方服务，需要额外维护 HBase；HBase 的稳定性也成为计算链路稳定性的重要依赖。在 HBase 状态缓存中，遇到一个数据倾斜的问题，某条测试 sid 的曝光重复上报，每小时千次量级。如上图，该条 sid 对应的状态达到 MB 级别，被频繁的从 HBase 中取出并写回，引起频繁的 gc，影响所在 task 的性能。解决办法是根据业务逻辑对 impress 进行去重。3.3 DWS - 实时 OLAP在 DWD 层基于 Flink 的事件驱动已经实现了实时模型，再由 Flink 来消费处理实时模型，从中提取出维度和指标，然后逐条的向后输出。在这个过程中已是能输出一个实时 OLAP 的结果了，但也需要有个后端的存储来承接，我们因此引入了 Druid。Druid 可以支持数据的实时摄入，并且摄入的结果实时可查，也可以在摄入的同时做自动的聚合。上图左侧：每张表需要启动常驻任务等待 push 过来的数据。常驻任务被动接收数据，易被压崩；常驻任务异常重启麻烦，需要清理 zk 状态；常驻任务的高可用依赖备份任务，浪费资源。上图右侧：一张报表对应一个 Kafka 消费任务。消费任务自己控制摄入速率更加稳定；任务可依赖 offset 平滑的失败自启。3.4 ADS - 跨源查询Presto 是分布式的 SQL 查询引擎，可从不同的数据源抽取数据并关联查询。但会带来 Druid 的下推优化支持不完善的问题。3.5 流批混合现状如上图所示是 Lambda 大数据框架，流式计算部分是 Kafka+Flink，批处理则是 HDFS+Spark。流式计算的特点：响应快，秒级输出；可重入性差，难以重复计算历史日志；流的持续性重要，异常需迅速介入。批处理的特点：响应慢，小时级输出；可重入性好，可重复计算历史数据；数据按小时粒度管理，个别异常可从容处理。流批混合痛点：两遍日志清洗的计算量；两套技术框架；数据一致性问题。四、未来展望流批混合优化，直接将实时模型输出到 HDFS。好处是：避免了对日志的重复清洗；统一了建模的技术框架；支持延迟数据对模型的更新。但也有以下两个问题：实时模型重复，量级更大，计算消耗大；支持数据更新的技术如 Hudi，会改变模型的使用方式，对后续使用者不友好。最后聊一下对 Flink-SQL 的想法：检索近 10 分钟的某条异常日志、快速评估近 10 分钟新策略的效果都属于即时、微批、即席查询。批处理链路小时级响应太慢；实时检索系统如 ES，资源消耗大。可以利用 Kafka + Flink-SQL 解决上述问题，Kafka + Flink-SQL 也是今后计划尝试的方向。点击查看直播回放 & 演讲PDF更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-07-21
基于 Flink CDC 实现海量数据的实时同步和转换
摘要：本文整理自 Apache Flink Committer，Flink CDC Maintainer，阿里巴巴高级开发工程师徐榜江（雪尽）在 5 月 21 日 Flink CDC Meetup 的演讲。主要内容包括：Flink CDC 技术传统数据集成方案的痛点基于 Flink CDC 的海量数据的实时同步和转换Flink CDC 社区发展点击查看直播回放 & 演讲PDF一、Flink CDC 技术CDC 是 Change Data Capture 的缩写，是一种捕获变更数据的技术，CDC 技术很早就存在，发展至今，业界的 CDC 技术方案众多，从原理上可以分为两大类：一类是基于查询的 CDC 技术 ，比如 DataX。随着当下场景对实时性要求越来越高，此类技术的缺陷也逐渐凸显。离线调度和批处理的模式导致延迟较高；基于离线调度做切片，因而无法保障数据的一致性；另外，也无法保障实时性。一类是基于日志的 CDC 技术，比如 Debezium、Canal、 Flink CDC。这种 CDC 技术能够实时消费数据库的日志，流式处理的模式可以保障数据的一致性，提供实时的数据，可以满足当下越来越实时的业务需求。上图为常见开源 CDC 的方案对比。可以看到 Flink CDC 的机制以及在增量同步、断点续传、全量同步的表现都很好，也支持全增量一体化同步，而很多其他开源方案无法支持全增量一体化同步。Flink CDC 是分布式架构，可以满足海量数据同步的业务场景。依靠 Flink 的生态优势，它提供了 DataStream API 以及 SQL API，这些 API 提供了非常强大的 transformation 能力。此外，Flink CDC 社区和 Flink 社区的开源生态非常完善，吸引了很多社区用户和公司在社区开发共建。Flink CDC 支持全增量一体化同步，为用户提供实时一致性快照。比如一张表里有历史的全量数据，也有新增的实时变更数据，增量数据不断地往 Binlog 日志文件里写，Flink CDC 会先同步全量历史数据，再无缝切换到同步增量数据，增量同步时，如果是新增的插入数据（上图中蓝色小块），会追加到实时一致性快照中；如果是更新的数据（上图中黄色小块），则会在已有历史数据里做更新。Flink CDC 相当于提供了实时物化视图，为用户提供数据库中表的实时一致性快照，用于可以对这些数据做进一步加工，比如清洗、聚合、过滤等，然后再写入下游。二、传统数据集成方案的痛点上图为传统数据入仓架构 1.0，主要使用 DataX 或 Sqoop 全量同步到 HDFS，再围绕 Hive 做数仓。此方案存在诸多缺陷：容易影响业务稳定性，因为每天都需要从业务表里查询数据；天级别的产出导致时效性差，延迟高；如果将调度间隔调成几分钟一次，则会对源库造成非常大的压力；扩展性差，业务规模扩大后极易出现性能瓶颈。上图为传统数据入仓 2.0 架构。分为实时和离线两条链路，实时链路做增量同步，比如通过 Canal 同步到 Kafka 后再做实时回流；全量同步一般只做一次，与每天的增量在 HDFS 上做定时合并，最后导入到 Hive 数仓里。此方式只做一次全量同步，因此基本不影响业务稳定性，但是增量同步有定时回流，一般只能保持在小时和天级别，因此它的时效性也比较低。同时，全量与增量两条链路是割裂的，意味着链路多，需要维护的组件也多，系统的可维护性会比较差。上图为传统 CDC ETL 分析架构。通过 Debezium、Canal 等工具采集 CDC 数据后，写入消息队列，再使用计算引擎做计算清洗，最终传输到下游存储，完成实时数仓、数据湖的构建。传统 CDC ETL 分析里引入了很多组件比如 Debezium、Canal，都需要部署和维护， Kafka 消息队列集群也需要维护。Debezium 的缺陷在于它虽然支持全量加增量，但它的单并发模型无法很好地应对海量数据场景。而 Canal 只能读增量，需要 DataX 与 Sqoop 配合才能读取全量，相当于需要两条链路，需要维护的组件也增加。因此，传统 CDC ETL 分析的痛点是单并发性能差，全量增量割裂，依赖的组件较多。三、基于 Flink CDC 的海量数据的实时同步和转换Flink CDC 的方案能够给海量数据的实时同步和转换带来什么改善？Flink CDC 2.0 在 MySQL CDC 上实现了增量快照读取算法，在最新的 2.2 版本里 Flink CDC 社区 将增量快照算法抽象成框架，使得其他数据源也能复用增量快照算法。增量快照算法解决了全增量一体化同步里的一些痛点。比如 Debezium 早期版本在实现全增量一体化同步时会使用锁，并且且是单并发模型，失败重做机制，无法在全量阶段实现断点续传。增量快照算法使用了无锁算法，对业务库非常友好；支持了并发读取，解决了海量数据的处理问题；支持了断点续传，避免失败重做，能够极大地提高数据同步的效率与用户体验。上图为全增量一体化的框架。整个框架简单来讲就是将数据库里的表按 PK 或 UK 切分成 一个个 chunk ，然后分给多个 task 做并行读取，即在全量阶段实现了并行读取。全量和增量能够自动切换，切换时通过无锁算法来做无锁一致性的切换。切换到增量阶段后，只需要单独的 task 去负责增量部分的数据解析，以此实现了全增量一体化读取。进入增量阶段后，作业不再需要的资源，用户可以修改作业并发将其释放。我们将全增量一体化框架与 Debezium 1.6 版本做 简单的 TPC-DS 读取测试对比，customer 单表数据量 6500 万，在 Flink CDC 用 8 个并发的情况下，吞吐提升了 6.8 倍，耗时仅 13 分钟，得益于并发读取的支持，如果用户需要更快的读取速度，用户可以增加并发实现。Flink CDC 在设计时，也考虑了面向存储友好的写入设计。在 Flink CDC 1.x 版本中，如果想实现 exactly-once 同步，需要配合 Flink 提供的 checkpoint 机制,全量阶段没有做切片，则只能在一个 checkpoint 里完成，这会导致一个问题：每个 checkpoint 中间要将这张表的全量数据吐给下游的 writer，writer 会将这张表的全量数据混存在内存中，会对其内存造成非常大的压力，作业稳定性也特别差。Flink CDC 2.0 提出了增量快照算法后，通过切片能够将 checkpoint 粒度降至 chunk， 并且 chunk 大小是用户可配置的，默认是 8096 条，用户可以将其调至更小，减轻 writer 的压力，减少内存资源的使用，提升下游写入存储时的稳定性。全增量一体化之后， Flink CDC 的入湖架构变得非常简单，且不会影响业务的稳定性；能够做到分钟级的产出，也就意味着可以实现近实时或实时分析；并发读取实现了更高的吞吐，在海量数据场景下有着不俗的表现；链路短，组件少，运维友好。有了 Flink CDC 之后，传统 CDC ETL 分析的痛点也得到了极大改善，不再需要 Canal、Kafka 消息队列等组件，只需要依赖 Flink，实现了全增量一体化同步和实时 ETL 加工的能力，且支持并发读取，整个架构链路短，组件少，易于维护。依托于 Flink DataStream API 以及易用的 SQL API ，Flink CDC 还提供了非常强大完善的 transformation 能力，且在 transformation 过程中能够保证 changelog 语义。在传统方案里，在 changelog 上做 transformation 并保证 changelog 语义是非常难以实现的。海量数据的实时同步和转换示例 1：Flink CDC 实现异构数据源的集成这个业务场景是业务表比如产品表和订单表在 MySQL 数据库里，物流表存在 PG 数据库里，要实现异构数据源的集成，并且在集成过程做打宽。需要将产品表、订单表与物流表做 Streaming Join 之后再将结果表写入库里。借助 Flink CDC，整个过程只需要用 5 行 Flink SQL 就能够实现。这里使用的下游存储是 Hudi，整个链路可以得到分钟级甚至更低的产出，使围绕 Hudi 做近实时的分析成为了可能。海量数据的实时同步和转换示例 2：Flink CDC 实现分库分表集成Flink CDC 对分库分表做了非常完善的支持，在声明 CDC 表时支持使用正则表达式匹配库名和表名，正则表达式意味着可以匹配多个库以及这多个库下的多张表。同时提供了 metadata column 的支持，可以知道数据来自于哪个 数据库、来自于哪张表，写入下游 Hudi 时，可以带上 metadata 声明的两个列，将 database_name、table_name 以及原始表中的 主键（例子中为 id 列）作为新的主键，只需三行 Flink SQL 即可实现分库分表数据的实时集成，非常简单。依托于 Flink 丰富的生态，能够实现很多上下游的扩展，Flink 自身就有丰富的 connector 生态。 Flink CDC 加入之后，上游有了更丰富的源可以摄取，下游也有丰富的目的端可以写入。海量数据的实时同步和转换示例 3：三行 SQL 实现单品累计销量实时排行榜这个 Demo 演示在无需任何依赖的前提下，通过 3 行 SQL 实现商品的实时排行榜。 首先在 Docker 里添加 MySQL 和 ElasticSearch 镜像， ElasticSearch 是目的端。将 Docker 拉起后，下载 Flink 包以及 MySQL CDC 和 ElasticSearch 的两个 SQL Connector jar。拉起 Flink 集群和 SQL Client。在 MySQL 内建库建表，灌入数据，更新后再用 Flink SQL 做一些实时加工和分析，写入 ES。在 MySQL 的数据库里构造一张订单表并插入数据。 上图第一行 SQL 是创建订单表，第二行是创建结果表，第三行是做 group by 的查询实现实时排行榜功能，再写入到第二行 SQL 创建的 ElasticSearch 表中。我们在 ElasticSearch 里做了可视化呈现，可以查看到随着 MySQL 中订单源源不断地更新，ElasticSearch 的排行榜会实时刷新。四、Flink CDC 社区发展在过去的一年多时间，社区发了 4 个大版本， contributor 和 commits数量在不断增长，社区也越来越活跃。我们一直坚持将核心的 feature 全部提供给社区版，比如 MySQL 的百亿级超大表、增量快照框架、MySQL 动态加表等高级功能。最新的 2.2 版本中同样新增了很多功能。首先，数据源方面，支持了 OceanBase、PolarDB-X、SqlServer、TiDB。此外，不断丰富了 Flink CDC 的生态，兼容了 Flink 1.13 和 1.14 集群，提供了增量快照读取框架。另外，支持了 MySQL CDC 动态加表以及对 MongoDB 做了完善，比如支持指定的集合，通过正则表达式使其更加灵活友好。除此之外，文档也是社区特别重要的一部分。我们提供了独立的版本化社区网站，在网站里不同版本对应不同版本的文档，提供了丰富的 demo 以及中英文的 FAQ，帮助新手快速入门。在社区的多个关键指标，比如创建的 issue 数，合并的 PR 数，Github Star 数上，Flink CDC 社区的表现都非常不错。Flink CDC 社区的未来规划主要包含以下三个方面：框架完善：增量快照框架目前只支持 MySQL CDC ，Oracle、PG 和 MongoDB 正在对接中，希望未来所有数据库都能够对接到更好的框架上；针对 Schema Evolution 和整库同步做了一些探索性的工作，成熟后将向社区提供。生态集成：提供更多 DB 和更多版本；数据湖集成方面希望链路更通畅；提供一些端到端的方案，用户无须关心 Hudi 和 Flink CDC 的参数。易用性：提供更多开箱即用的体验以及完善文档教程。问答Q：CDC 什么时候能够支持整库同步以及 DDL 的同步？A：正在设计中，因为它需要考虑到 Flink 引擎侧的支持与配合，不是单独在 Flink CDC 社区内开发就可以实现的，需要与 Flink 社区联动。Q：什么时候支持 Flink 1.15A：目前生产上的 Flink 集群还是以 1.13、1.14 为主。社区计划在 2.3 版本中支持 Flink 1.15，可以关注 issue：https://github.com/ververica/flink-cdc-connectors/issues/1363，也欢迎贡献。Q：有 CDC 结果表写入 Oracle 的实践吗？A：1.14 版本的 Flink 暂不支持，这个是因为 Sink 端的 JDBC Connector 不支持 Oracle dialect，Flink 1.15 版本的 JDBC Connector 已经支持了 Oracle dialect，1.15 版本的 Flink 集群可以支持。Q：下个版本能否支持读取 ES？A：还需要考察 transactional log 机制以及它是否适合作为 CDC 的数据源。Q：能做到单 job 监控多表 sink 多表吗？A：可以实现单作业监控多表 sink 到多个下游表；但如果是 sink 到多表，需要 DataStream 进行分流，不同的流写到不同的表。Q：Binlog 日志只有最近两个月的数据，能否支持先全量后增量读取？A：默认支持的就是先全量后增量，一般 binlog 保存七天或两三天都可以。Q：2.2 版本 MySQL 没有主键，全量如何同步？A：可以回退到不用增量快照框架；在增量快照框架上，社区已有组件的 issue，预计将在社区 2.3 版本提供支持。点击查看直播回放 & 演讲PDF 更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-07-19
网易游戏 Flink SQL 平台化实践
摘要：本文整理自网易游戏资深开发工程师林小铂在 Flink Forward Asia 2021 平台建设专场的演讲。主要内容包括：网易游戏 Flink SQL 发展历程基于模板 jar 的 StreamflySQL v1基于 SQL Gateway 的 StreamflySQL v2未来工作点击查看直播回放 & 演讲PDF一、网易游戏 Flink SQL 发展历程网易游戏实时计算平台叫做 Streamfly，这个名字取名自电影《驯龙高手》中的 Stormfly。由于我们已经在从 Storm 迁移到 Flink，所以将 Stormfly 中的 Storm 替换成了更为通用的 Stream。Streamfly 前身是离线作业平台 Omega 下的名为 Lambda 的子系统，它负责了所有实时作业的调度，最开始开始支持 Storm 和 Spark Streaming，后来改为只支持 Flink。在 2019 年的时候我们将 Lambda 独立出来以此为基础建立了 Streamfly 计算平台。随后，我们在 2019 年底开发并上线了第一个版本 Flink SQL 平台 StreamflySQL。这个版本基于模板 jar 提供了基本 Flink SQL 的功能，但是用户体验还有待提升，因此我们在 2021 年年初从零开始重新建设了第二个版本的 StreamflySQL，而第二个版本是基于 SQL Gateway。要了解这两个版本的不同，我们需要先回顾下 Flink SQL 的基本工作流程。用户提交的 SQL 首先会被 Parser 解析为逻辑执行计划；逻辑执行计划经过 Planner Optimizer 优化，会生成物理执行计划；物理执行计划再通过 Planner CodeGen 代码生成，翻译为 DataStream API 常见的 Transformation；最后 StreamGraphGenerator 会将这些 Transformation 转换为 Flink 作业的最终表示 JobGraph 提交到 Flink 集群。上述一系列过程都发生在 TableEnvironment 里面。取决于部署模式的不同，TableEnvironment 可能运行在 Flink Client 或者 JobManager 里。Flink 现在支持 3 种集群部署模式，包括 Application、 Per-Job 和 Session 模式。在 Application 模式下，TableEnvironment 会在 JobManager 端运行，而在其余两种模式下，TableEnvironment 都运行在 Client 端。不过这三种模式都有一个共同的特点，TableEnvironment 都是一次性的，会在提交 JobGraph 之后自动退出。为了更好地复用 TableEnvironment 提高效率和提供有状态的操作，有的项目会将 TableEnvironment 放到一个新的独立 Server 端进程里面去运行，由此产生了一种新的架构，我们称之为 Server 端 SQL 编译。相对地，还有 Client 端 SQL 编译。有同学可能会问，为什么没有 JobManager 端 SQL 编译，这是因为 JobManager 是相对封闭的组件，不适合拓展，而且即使做了达到的效果跟 Client 端编译效果基本一样。所以总体来看，一般就有 Client 和 Server 两种常见的 Flink SQL 平台架构。Client 端 SQL 编译，顾名思义就是 SQL 的解析翻译优化都在 Client 端里进行（这里的 Client 是广义的 Client，并不一定是 Flink Client）。典型的案例就是通用模板 jar 和 Flink 的 SQL Client。这种架构的优点是开箱即用，开发成本低，而且使用的是 Flink public 的 API，版本升级比较容易；缺点是难以支持高级的功能，而且每次都要先启动一个比较重的 TableEnvironment 所以性能比较差。然后是 Server 端 SQL 编辑。这种架构将 SQL 解析翻译优化逻辑放到一个独立的 Server 进程去进行，让 Client 变得非常轻，比较接近于传统数据库的架构。典型的案例是 Ververica 的 SQL Gateway。这种架构的优点是可拓展性好，可以支持很多定制化功能，而且性能好；缺点则是现在开源界没有成熟的解决方案，像上面提到 SQL Gateway 只是一个比较初期的原型系统，缺乏很多企业级特性，如果用到生产环境需要经过一定的改造，而且这些改造涉及比较多 Flink 内部 API，需要比较多 Flink 的背景知识，总体来说开发成本比较高，而且后续版本升级工作量也比较大。编者按：Apache Flink 社区目前正在开发 SQL Gateway 组件，将原生提供 Flink SQL 服务化的能力，并兼容 HiveServer2 协议，计划于 1.16 版本中发布，敬请期待。感兴趣的同学可以关注 FLIP-91 [1] 和 FLIP-223 [2] 了解更多，也非常欢迎大家参与贡献。回到我们 Flink SQL 平台，我们 StreamflySQL v1 是基于 Client 端 SQL 编译，而 v2 是基于 Server 端的 SQL 编译。下面就让我逐个介绍一下。二、基于模板 jar 的 StreamflySQL v1StreamflySQL v1 选择 Client 端 SQL 编译的主要原因有三个:首先是平台集成。不同于很多公司的作业调度器用大数据中比较主流的 Java 编写，我们的 Lambda 调度器是用 Go 开发的。这是因为 Lambda 在设计之初支持了多种实时计算框架，出于松耦合和公司技术栈的考虑，Lambda 以 Go 作为开发语言，会采用与 YARN 类似的动态生成 Shell 脚本的方式来调用不同框架的命令行接口。这样松耦合的接口方式给我们带来很大的灵活性，比如我们可以轻松支持多个版本的 Flink，不需要强制用户随着系统版本升级，但同时也导致没办法直接去调用 Flink 原生的 Java API。第二个原因是松耦合。开发的时候 Flink 版本是1.9，当时 Client API 比较复杂，不太适合平台集成，并且当时社区也在推动 Client 的重构，所以我们尽量避免依赖 Client API去开发 Flink SQL 平台。第三个原因是实践经验。因为模板 jar + 配置中心模式在网易游戏内部已经有了比较多的应用，所以我们在这方面积累了很多实践经验。综合之下我们很自然地采用了模板 jar + 配置中心的架构来实现 v1 版本。上图是 v1 版本的整体架构图。我们在主要在 Lambda 作业平台的基础上新增了 StreamflySQL 后端作为配置中心，负责根据用户提交的 SQL 和作业运行配置加上通用的模板 jar 来生成一个 Lambda 作业。总体的作业提交流程如下:用户在前端的 SQL 编辑器提交 SQL 和运行配置。StreamflySQL 后端收到请求后生成一个 Lambda 作业并传递配置 ID。然后 Lambda 启动作业，背后是执行 Flink CLI run 命令来提交作业。Flink CLI run 命令会启动 Flink Client 来加载并执行模版 jar 的 main 函数，这时会读取 SQL 和配置，并初始化 TableEnvironment。TableEnvironment 会从 Catalog 读取必要的 Database/Table 等元信息。这里顺带一提是，在网易游戏我们没有使用统一的 Catalog 来维护不同组件的元信息，而是不同组件有自己的元数据中心，对应不同的 Catalog。最后 TableEnvironment 编译好 JobGraph，以 Per-Job Cluster 的方式部署作业。StreamflySQL v1 实现了 Flink SQL 平台从零到一的建设，满足了部分业务需求，但仍有不少痛点。第一个痛点是响应慢。以一个比较典型的 SQL 来说，以模板 jar 的方式启动作业需要准备 TableEnviroment，这可能会花费 5 秒钟，然后执行 SQL 的编译优化包括与 Catalog 交互去获取元数据，也可能会花费 5 秒钟；编译得到jobgraph之后还需要准备 per-job cluster，一般来说也会花费 20 秒以上；最后还需要等待 Flink job的调度，也就是作业从 scheduled 变成 running 的状态，这个可能也需要 10 秒钟。总体来说，v1 版本启动一个 Flink SQL 作业至少需要 40 秒的时间，这样的耗时相对来说是比较长的。但是仔细分析这些步骤，只有 SQL的编译优化和 job 调度是不可避免的，其他的比如 TableEnvironment 和 Flink cluster 其实都可以提前准备，这里的慢就慢在资源是懒初始化的，而且几乎没有复用。第二个痛点是调试难。我们对 SQL 调试的需求有以下几点：第一点是调试的 SQL 与线上的 SQL 要基本一致。第二点是调试 SQL 不能对线上的数据产生影响，它可以去读线上的数据，但不能去写。第三点，因为调试的 SQL 通常只需要抽取少量的数据样本就可以验证 SQL 的正确性，所以我们希望限制调试 SQL 的资源，一方面是出于成本的考虑，另外一方面也是为了防止调试的 SQL 与线上作业产生资源竞争。第四点，因为调试 SQL 处理的数据量比较少，我们希望以更快更便捷的方式获取到结果。在 v1 版本中，我们对上述需求设计了如下解决方案：首先对于调试的 SQL，系统会在 SQL 翻译的时候将原来的一个 Sink 替换为专用的 PrintSink，这解决了需求中的前两点。然后对 PrintSink 进行限流，通过 Flink 的反压机制达到总体的限流，并且会限制作业的最长执行时间，超时之后系统会自动把作业结束掉，这解决了需求中的资源限制这点。最后为了更快地响应，调试的作业并不会提交到 YARN 集群上去运行，而是会在 Lamdba 服务器本地开启开启一个 MiniCluster 去执行，同时也方便我们从标准输出去提取 PrintSink 的结果，这点解决了需求中的最后一点。调试模式的架构如上图所示，比起一般的 SQL 提交流程，主要区别在于作业不会提交到 YARN 上，而是在 Lambda 服务器的本地执行，从而节省了准备 Flink 集群的开销，并且更容易管控资源和获取结果。上述调试解决方案基本可用，但是实际使用过程中依然存在不少问题。第一，如果用户提交的 SQL 比较复杂，那么 SQL 的编译优化可能会耗费比较久的时间，这会导致作业很容易超时，在有结果输出之前可能就被系统结束掉，同时这样的 SQL 也会给服务器造成比较大的压力。第二，该架构没法去调试时间窗口比较长的作业或者需要 Bootstrap State 的作业。第三，因为执行结果是在作业结束之后才批量返回的，不是在作业执行过程中就流式返回，因此用户需要等到作业结束——通常是 10 分钟以上才可以看到结果。第四，在 SQL 的翻译阶段把调试 SQL 的 Sink 替换掉，这个功能是通过改造 Flink 的 Planner 来实现的，相当于业务逻辑入侵到了 Planner 里面，这样并不优雅。第三个痛点是 v1 版本只允许单条 DML。相比传统的数据库，我们支持的 SQL 语句是很有限的，比如，MySQL 的 SQL 可以分成 DML、DQL、DDL 和 DCL。DML 用于操控数据，常见的语句有 INSERT / UPDATE / DELETE。StreamflySQL v1 只支持了 INSERT，这和 Flink SQL 是保持一致的。Flink SQL 用 Retract 模式 — 也就是类似 Changelog 的方式 — 来表示 UPDATE/DELETE，所以只支持 INSERT，这点其实没有问题。DQL 用于查询数据，常见语句是 SELECT。这在 Flink SQL 是支持的，但因为缺乏 Sink 不能生成一个有意义的 Flink 作业，所以 StreamflySQL v1 不支持 DQL。DDL 用于定义元数据，常见语句是 CREATE / ALTER /DROP 等。这在 StreamflySQL v1 版本是不支持的，因为模板 jar 调用 SQL 的入口是 sqlUpdate，不支持纯元数据的操作，而且为纯元数据的操作单独启动一个 TableEnvironment 来执行也是完全不划算。最后是 DCL，用于管理数据权限，比如 GRANT 跟 REVOKE 语句。这个 Flink SQL 是不支持的，原因是 Flink 目前只是数据的用户而不是管理者，DCL 并没有意义。综合来看，v1 版本只支持了单条 DML，这让我们很漂亮的 SQL 编辑器变得空有其表。基于以上这些痛点，我们在今年调研并开发了 StreamflySQL v2。v2 采用的是 Server 端 SQL 编译的架构。三、基于 SQL Gateway 的 StreamflySQL v2我们的核心需求是解决 v1 版本的几个痛点，包括改善用户体验和提供更完整的 SQL 支持。总体的思路是采用 Server 端的 SQL 编译的架构，提高可拓展性和性能。此外，我们的集群部署模式也改成 Session Cluster，预先准备好集群资源，省去启动 YARN application 的时间。这里会有两个关键问题。首先是我们要完全自研还是基于开源项目？在调研期间我们发现 Ververica 的 SQL Gateway 项目很符合我们需求，容易拓展而且是 Flink 社区 FLIP-91 SQL Gateway 的一个基础实现，后续也容易与社区的发展方向融合。第二个问题是，SQL Gateway 本身有提交作业的能力，这点跟我们已有的 Lambda 平台是重合的，会造成重复建设和难以统一管理的问题，比如认证授权、资源管理、监控告警等都会有两个入口。那么两者应当如何进行分工？我们最终的解决方案是，利用 Session Cluster 的两阶段调度，即资源初始化和作业执行是分离的，所以我们可以让 Lambda 负责 Session Cluster 的管理，而 StreamflySQL 负责 SQL 作业的管理，这样能复用 Lambda 大部分的基础能力。这是 StreamflySQL v2 的架构图。我们将 SQL Gateway 内嵌到 SpringBoot 应用中，开发了新的后端。总体看起来比 v1 版本要复杂，原因是原本的一级调度变成了会话和作业的两级调度。首先用户需要创建一个 SQL 会话，StreamflySQL 后端会生成一个会话作业。在 Lambda 看来会话作业是一种特殊作业，启动时会使用 yarn-session 的脚本来启动一个 Flink Session Cluster。在 Session Cluster 初始化之后，用户就可以在会话内去提交 SQL。StreamflySQL 后端会给每个会话开启一个 TableEnvironment，负责执行 SQL 语句。如果是只涉及元数据的 SQL，会直接调用 Catalog 接口完成，如果是作业类型的 SQL，会编译成 JobGraph 提交到 Session Cluster 去执行。v2 版本很大程度上解决了 v1 版本的几个痛点:在响应时间方面，v1 常常会需要 1 分钟左右，而 v2 版本通常在 10 秒内完成。在调试预览方面，v2 不需要等作业结束，而是在作业运行时，将结果通过 socket 流式地返回。这点是依赖了 SQL gateway 比较巧妙的设计。对于 select 语句，SQL Gateway 会自动注册一个基于 socket 的临时表，并将 select 结果写入到这个表。在 SQL 支持方面，v1 只支持 DML，而 v2 借助于 SQL Gateway 可以支持 DML/DQL/DDL。不过 SQL Gateway 虽然有不错的核心功能，但我们使用起来并不是一帆风顺，也遇到一些挑战。首先最为重要的是元数据的持久化。SQL Gateway 本身的元数据只保存在内存中，如果进程重启或是遇到异常崩溃，就会导致元数据丢失，这在企业的生产环境里面是不可接受的。因此我们将 SQL Gateway 集成到 SpringBoot 程序之后，很自然地就将元数据保存到了数据库。元数据主要是会话元数据，包括会话的 Catalog、Function、Table 和作业等等。这些元数据按照作用范围可以分为 4 层。底下的两层是全局的配置，以配置文件的形式存在；上面两层是运行时动态生成的元数据，存在数据库中。上层的配置项优先级更高，可以用于覆盖下层的配置。我们从下往上看这些元数据：最底层是全局的默认 Flink Configuration，也就是我们在 Flink Home 下的 flink-conf yaml 配置。再上面一层是 Gateway 自身的配置，比如部署模式（比如是 YARN 还是 K8S），比如默认要出册的 Catalog 和 Function 等等。第三层是 Session 会话级别的 Session Configuraion，比如会话对应的 Session Cluster 的集群 ID 或者 TaskManager 的资源配置等等。最上面一层是 Job 级别的配置，包括作业动态生成的元数据，比如作业 ID、用户设置 checkpoint 周期等等。这样比较灵活的设计除了解决了元数据持久化的问题，也为我们的多租户特性奠定了基础。第二个挑战是多租户。多租户分为资源和认证两个方面：在资源方面，StreamflySQL 利用 Lambda 作业平台可以在不同的队列启动 Session Cluster，它们的 Master 节点和资源很自然就是隔离的，所以没有像 Spark Thrift Server 那样不同用户共用一个 Master 节点和混用资源的问题。在认证方面，因为 Session Cluster 属于不同用户，所以 StreamflySQL 后端需要实现多租户的伪装。在网易游戏，组件一般会使用 Kerberos 认证。我们采用多租户实现的方式是使用 Hadoop 的 Proxy User，先登录为超级用户，然后伪装成项目用户来向不同组件获取 delegation token，这里的组件主要是 Hive MetaStore 跟 HDFS，最后把这些 token 存到 UGI 里面并用 doAS 的方式来提交作业。第三个挑战是水平拓展。为了高可用和拓展服务能力，StreamflySQL 很自然需要以多实例的架构部署。因为我们已经将主要的状态元数据存到数据库，我们可以随时从数据库构建出一个新的 TableEnvironment，所以 StreamflySQL 实例类似普通 Web 服务一样非常轻，可以很容易地扩容缩容。但是并不是所有状态都可以持久化的，另外有些状态我们故意会不持久化。比如用户使用 SET 命令来改变 TableEnvironment 的属性，比如开启 Table Hints，这些属于临时属性，会在重建 TableEnvironment 后被重置。这是符合预期的。再比如用户提交 select 查询做调试预览时，TaskManager 会与 StreamflySQL 后端建立 socket 链接，而 socket 链接显然也是不可持久化的。因此我们在 StreamflySQL 的多实例前加了亲和性的负载均衡，按照 Session ID 来调度流量，让在正常情况下同一个用户的请求都落到同一个实例上，确保用户使用体验的连续性。第四个挑战是作业状态管理。其实这里的状态一词是双关，有两个含义：第一个含义是作业的运行状态。SQL gateway 目前只是提交 SQL 并不监控后续的运行状态。因此，StreamflySQL 设置了监控线程池来定时轮询并更新作业状态。因为 StreamflySQL 是多实例的，它们的监控线程同时操作同一个作业的话，可能会有更新丢失的问题，所以我们这里使用了 CAS 乐观锁来保证过时的更新不会生效。然后我们会在作业异常退出或者无法获取状态时进行告警，比如 JobManager 进行 failover 的情况下，我们无法得知 Flink 作业的状态，这时系统就会发出 disconnected 的异常状态告警。第二个含义是 Flink 的持久化状态，即 Flink State。原生的 SQL gateway 并没有管理 Flink 的 Savepoint 和 Checkpoint，因此我们加上了 stop 和 stop-with-savepoint 的功能，并强制开启 retained checkpoint。这使得在作业遇到异常终止或者简单 stop 之后，再次重启时系统可以自动查找到最新的 checkpoint。这里我可以分享下我们的算法。其实自动查找最新 checkpoint 的功能 Lambda 也有提供，但是 Lambda 假设作业都是 Per-Job Cluster，因此只要查找集群 checkpoint 目录里最新的一个 checkpoint 就可以了。但这样的算法对 StreamflySQL 却不适用，因为 Session Cluster 有多个作业，最新的 checkpoint 并不一定是我们目标作业的。因此，我们改为了使用类似 JobManager HA 的查找方式，先读取作业归档目录元数据，从里面提取最新的一个 checkpoint。四、未来工作未来我们首先要解决的一个问题是 State 迁移的问题，即用户对 SQL 进行变更后，如何从原先的 Savepoint 进行恢复。目前只能通过变更类型来告知用户风险，比如通常而言加减字段不会造成 Savepoint 的不兼容，但如果新增一个 join 表，造成的影响就很难说了。因此后续我们计划通过分析 SQL 变更前后的执行计划，来预先告知用户变更前后的状态兼容性。第二个问题是细粒度的资源管理。目前我们并不能在作业编译时去指定 SQL 的资源，比如 TaskManager 的 CPU 和内存在 Session Cluster 启动之后就确定了，是会话级别的。目前调整资源只能通过作业并行度调整，很不灵活并且容易造成浪费。现在 Flink 1.14 已经支持了 DataStream API 的细粒度资源管理，可以在算子级别设置资源，但 SQL API 现在还没有计划，后续我们可能参与进去推动相关议案的进展。最后是社区贡献。我们对 SQL Gateway 有一定使用经验，而且也对其进行了不少的改进，后续希望这些改进能回馈给 Flink 社区，推动 FLIP-91 SQL Gateway 的进展。点击查看直播回放 & 演讲PDF更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
-
发表了文章 2022-07-13
Apache Flink ML 2.1.0 发布公告
来源｜Apache Flink 官方博客Apache Flink 社区很荣幸地宣布 Apache Flink ML 2.1.0 版本正式发布！本次发布的版本重点改进了 Flink ML 的基础设施，例如 Python SDK，内存管理，以及性能测试框架，来帮助开发者基于 Flink ML 开发具有高性能，高稳定性，以及高易用性的机器学习算法库。基于本次发版中提出的改进，以及我们得到的性能测试结果，我们相信 Flink ML 的基础设施已经准备好提供给社区开发者使用，来开发高性能的、支持 Python 环境的机器学习算法库。我们鼓励您下载该版本 [1] 并通过 Flink 邮件列表 [2] 或 JIRA [3] 与社区分享您的反馈！我们希望您喜欢新版本，并且我们期待了解您的使用体验。重要特性1. 算子接口和基础设施1.1 支持算子级别粒度的内存管控在之前的版本中，机器学习算子的内部状态数据，例如需要被缓存并在每轮迭代中重复读取的训练数据，是被储存在 state backend 中。这些数据之前只能是全量放在内存中，或者全量放在磁盘上。前一种情况，状态数据量大的情况下，可能导致 OOM 和降低作业稳定性。后一种情况，由于每轮迭代会需要从磁盘读取全量数据并且进行反序列化，在状态数据量不大的情况下，性能低于把数据放在内存中的做法。这个问题增加了开发者开发高性能和高稳定性算子的难度。在本次发版中，我们改进了 Flink ML 的基础设施，允许指定一个算子可以使用的托管内存配额。在算子状态数据量低于配额的情况下，这些状态数据会被存放在 Flink 的管控内存中。当算子状态数据量高于配额时，超出配额的数据会被存放在磁盘上，以避免产生 OOM。算法开发者可以使用这个机制允许算子对于不同的输入数据量，都能提供最佳性能。开发者可以参考 KMeans 算子的代码来学习使用这个机制。1.2 开发在线训练算法的基础设施的改进Flink ML 的一个重要目标是推动在线训练算法的发展。在上一个版本中，我们通过提供 setModelData() 和 getModelData() 方法，让在线训练算法的模型数据能以无限数据流的形式被传输和保存，增强了 Flink ML API 对于在线训练算法的支持能力。本次发版进一步改进和验证了 Flink ML 基础设施对于在线训练算法的支持能力。本次发版添加了 2 个在线训练算法 (i.e. OnlineKMeans and OnlineLogisticRegression)，并提供了单元测试，验证和测试了这些算法的正确性。这两个算法引入了 global batch size，模型版本等概念，并提供了指标和接口来设置和读取相应的信息。虽然这两个算法的预测准确率还没经过调优，但是这些工作将帮助我们进一步建立开发在线训练算法的最佳实践。我们希望越来越多的社区贡献者能加入我们，共同完成这个目标。1.3 算法性能测试框架一个易于使用的性能测试框架对于开发和维护高性能的 Flink ML 算法库是至关重要的。本次发版添加了一个性能测试框架，支持编写可插拔可复用的数据生成器，可以读入 JSON 格式的配置，并将性能测试结果以 JSON 格式输出，以支持可定制化的性能测试结果可视化分析。我们提供了开箱可用的脚本将性能测试结果转换为图表。感兴趣的读者可以阅读这份文档 [4] 来了解如何使用这个测试框架。2. Python SDK本次发版增强了 Python SDK 的基础设施，支持 Python 算子调用相应的 Java 算子来完成训练和推理。Python 算子可以提供和 Java 算子相同的性能。这个功能可以极大提升 Python 算法库的开发效率，让算法开发者可以为一套算法同时提供 Python 和 Java 算法库，而无需重复实现算法的核心逻辑。3. 算法库本次发版延续之前的算法库开发工作，为多种机器学习算法类别添加了代表性的算法，来验证 Flink ML 基础设施的功能和性能。以下是本次发版中新增加的算法：特征工程: MinMaxScaler, StringIndexer, VectorAssembler, StandardScaler, Bucketizer在线学习: OnlineKmeans, OnlineLogisiticRegression回归算法: LinearRegression分类算法: LinearSVC评估算法: BinaryClassificationEvaluator为了帮助用户学习和使用 Flink ML 算法库，我们在 Apache Flink ML 网站 [5] 上为每个算法提供了相应的 Python 和 Java 样例程序。并且我们提供了每个算法的性能测试配置文件 [6] 以支持用户验证 Flink ML 的性能。感兴趣的读者可以阅读这份文档 [4] 来了解如何运行这些算法的性能测试。升级说明有关升级过程中可能需要做出的调整及确认，请参阅原文发布公告 [7]。发布说明和相关资源用户可以查看发布说明 [8] 来获得修改和新功能的详细列表。源代码可以从 Flink 官网的下载页面 [1] 获得，最新的 Flink ML Python 发布可以从 PyPI [9] 获得。贡献者列表Apache Flink 社区感谢对此版本做出贡献的每一位贡献者：Yunfeng Zhou, Zhipeng Zhang, huangxingbo, weibo, Dong Lin, Yun Gao, Jingsong Li and mumuhhh.参考链接：[1] https://flink.apache.org/downloads.html[2] https://flink.apache.org/community.html#mailing-lists[3] https://issues.apache.org/jira/browse/flink[4] https://github.com/apache/flink-ml/blob/master/flink-ml-benchmark/README.md[5] https://nightlies.apache.org/flink/flink-ml-docs-release-2.1/[6] https://github.com/apache/flink-ml/tree/master/flink-ml-benchmark/src/main/resources[7] https://flink.apache.org/news/2022/07/12/release-ml-2.1.0.html[8] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351141[9] https://pypi.org/project/apache-flink-ml点击进入 Flink 中文学习网更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc
2023年02月
-
02.03 16:44:52
发表了文章
2023-02-03 16:44:52
Flink Table Store 典型应用场景
Flink PMC 李劲松（之信）9 月 24 日在 Apache Flink Meetup 的分享。
-
02.01 17:00:49发表了文章
2023-02-01 17:00:49
基于 Flink+Pravega 的游戏服务器监控与调节系统设计
第四届实时计算 Flink 挑战赛季军队伍工一611项目介绍文章。
2023年01月
-
01.30 17:15:32发表了文章
2023-01-30 17:15:32
网易游戏实时 HTAP 计费风控平台建设
在网易互娱计费数据中心开发计费实时风控需求的实践中，基于 Flink 和 TiDB，在实时计算、非结构化存储、HTAP 实践等技术领域做了大量的探索，积淀了不少业界前沿的实践经验，本次演讲旨在与分享和讨论其中的关键技术和最佳实践。
-
01.18 16:33:24发表了文章
2023-01-18 16:33:24
中原银行对金融行业实时数仓的现状与发展趋势思考
本文内容介绍了银行业常见的实时场景和解决方案，然后针对银行业报表依赖维度表计算的特点，提出了基于 Flink Table Store 作为数据存储，进而构建流式数仓的解决方案。
-
01.16 17:44:12发表了文章
2023-01-16 17:44:12
Disney 流媒体广告 Flink 的应用实践
Disney 广告智能执行总监郝又超、Disney 广告智能实时计算负责人李丁哲，在 FFA 主会场的演讲。
-
01.13 18:25:05发表了文章
2023-01-13 18:25:05
Apache Flink 社区 2022 年度报告：Evolution, Diversity, Connection
通过 Evolution、Diversity、Connection 三个关键词，从年度最佳实践、核心技术演进、开源技术生态等多维度盘点过去一年的成果，与各位开发者一同见证社区成长。
-
01.12 18:18:42发表了文章
2023-01-12 18:18:42
PyFlink 最新进展解读及典型应用场景介绍
阿里巴巴高级技术专家付典，在 FFA 核心技术专场的分享。
-
01.10 15:42:28发表了文章
2023-01-10 15:42:28
Flink 批作业的运行时自适应执行管控
阿里云高级技术专家朱翥（长耕），在 FFA 核心技术专场的分享。本篇内容是关于在过去的一年中，Apache Flink 对运行时的作业执行管控进行的一些改进。
-
01.05 16:01:21发表了文章
2023-01-05 16:01:21
基于 Log 的通用增量 Checkpoint
Apache Flink Contributor 俞航翔 9 月 24 日在 Apache Flink Meetup 的演讲内容整理。
-
01.03 17:59:19发表了文章
2023-01-03 17:59:19
Flink 容错恢复 2.0 2022 最新进展
2022 年度，Flink 容错 2.0 这个项目在社区和阿里云产品的进展。
2022年12月
-
12.29 16:34:25发表了文章
2022-12-29 16:34:25
Flink Shuffle 3.0: Vision, Roadmap and Progress
阿里云高级技术专家宋辛童 (五藏)，在 FFA 2022 核心技术专场的分享。
-
12.28 17:17:48发表了文章
2022-12-28 17:17:48
上云节省 35%计算资源，420 个运维人天：运满满实时计算实践和思考
满帮实时数据团队 TL 欧锐，在 FFA 2022 行业案例专场的分享。
-
12.22 16:32:53发表了文章
2022-12-22 16:32:53
FFA 2022 主会场 Keynote：Flink Towards Streaming Data Warehouse
Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问）在 FFA 2022 主会场的分享。
-
12.19 15:12:58发表了文章
2022-12-19 15:12:58
Flink 在米哈游的应用实践
米哈游大数据实时计算团队负责人张剑在 FFA 2022 主会场的分享。
-
12.15 17:49:50发表了文章
2022-12-15 17:49:50
Flink Unaligned Checkpoint 在 Shopee 的优化和实践
介绍 Shopee 对 Unaligned Checkpoint 的改进、对 Flink 社区的贡献以及内部的实践和落地。
-
12.14 14:48:24发表了文章
2022-12-14 14:48:24
Flink 1.16：Hive SQL 如何平迁到 Flink SQL
Apache Flink PMC&Committer 伍翀（云邪）在 9.24 Apache Flink Meetup 的演讲内容整理。
-
12.08 14:55:39发表了文章
2022-12-08 14:55:39
云与开源，共植数字世界的根
阿里巴巴集团副总裁、阿里巴巴开源技术委员会负责人贾扬清在 FFA 2022 的分享。
-
12.05 16:02:50发表了文章
2022-12-05 16:02:50
FFA 2022 收官总结｜活动报告出炉，实时即未来！
FFA 2022 完美收官，一起来看看这次大会带来了哪些内容！
2022年11月
-
11.28 15:25:45发表了文章
2022-11-28 15:25:45
Flink Forward Asia 2022 主论坛概览
Flink Forward Asia（FFA）峰会成功举行，一起来看看这次大会主论坛带来了哪些内容！
-
11.26 12:55:24发表了文章
2022-11-26 12:55:24
投入上百人、经历多次双 11，Flink 已经足够强大了吗？
经历多年双 11，Flink 已经足够强大了吗？
-
11.25 18:00:54发表了文章
2022-11-25 18:00:54
Flink CDC 2.3 发布，持续优化性能，更多连接器支持增量快照，新增 Db2 支持
Flink CDC 2.3 发布，新增 Db2 数据源，MongoDB CDC 和 Oracle CDC支持增量快照，MySQL CDC 性能大幅提升
-
11.23 18:24:26发表了文章
2022-11-23 18:24:26
“后 Hadoop 时代”，大数据从业者如何应对新技术趋势带来的挑战?
对于大数据从业者们来说，开源大数据项目热力迁徙背后的技术发展逻辑及如何应对新技术趋势带来的挑战？刘京娟、贾扬清、王峰在此解读。
-
11.21 13:53:43发表了文章
2022-11-21 13:53:43
直播预约｜FFA 2022 主会场，11月26日正式上线
Flink Forward Asia 2022 将于 11 月 26 - 27 日正式上线
-
11.18 17:19:45发表了文章
2022-11-18 17:19:45
FFA 2022 专场解读 - 流批一体 & 平台建设 & AI 特征工程
Flink Forward Asia 2022 流批一体 & 平台建设 & AI 特征工程专场内容节选
-
11.17 17:27:37发表了文章
2022-11-17 17:27:37
FFA 2022 专场解读 - 实时风控 & 实时湖仓 & 数据集成
Flink Forward Asia 2022 实时风控 & 实时湖仓 & 数据集成专场内容节选
-
11.16 18:26:06发表了文章
2022-11-16 18:26:06
基于 Apache Flink Table Store 的全增量一体实时入湖
本文简要回顾了数据入湖（仓）的发展阶段，针对在数据库数据入湖中面临的问题，提出了使用 Flink Table Store 作为全增量一体入湖的解决方案，并辅以开源 Demo 的测试结果作为展示。
-
11.14 16:11:55发表了文章
2022-11-14 16:11:55
FFA 2022 专场解读 - 行业案例 & 生产实践
Flink Forward Asia 2022 行业案例专场 & 生产实践专场内容节选
-
11.08 15:08:20发表了文章
2022-11-08 15:08:20
《2022开源大数据热力报告》发布，Flink 摘得「流处理」领域热力值 TOP1
文中附报告下载地址～
-
11.07 16:08:35发表了文章
2022-11-07 16:08:35
FFA 2022 专场解读 - Flink 核心技术
核心技术专场，一线技术专家解析 Flink 技术动向与应用实践。
-
11.03 16:31:56发表了文章
2022-11-03 16:31:56
更快更稳更易用: Flink 自适应批处理能力演进
朱翥、贺小令在 9.24 Apache Flink Meetup 的演讲内容整理。
2022年10月
-
10.31 14:12:49发表了文章
2022-10-31 14:12:49
官宣｜Apache Flink 1.16 发布公告
Flink 社区正一步一步推动 Streaming warehouse 从概念变为现实并走向成熟。
-
10.25 11:35:26发表了文章
2022-10-25 11:35:26
实时化浪潮下，Apache Flink 还将在大数据领域掀起怎样的变革？
Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！
-
10.20 11:12:13发表了文章
2022-10-20 11:12:13
特征平台在数禾的建设与应用
介绍特征平台概览、特征存储服务、流批一体方案、模型策略调用方案。
-
10.20 10:36:49发表了文章
2022-10-20 10:36:49
RocketMQ Flink Catalog 设计与实践
RocketMQ Flink Catalog 使用指南
-
10.20 10:30:18发表了文章
2022-10-20 10:30:18
2022 云栖大会 | 听「开源人说」，看 Flink 社区的八年
听百味技术人生，品激荡开源江湖！
-
10.12 10:07:55发表了文章
2022-10-12 10:07:55
37手游基于云平台的大数据建设实践
37手游大数据平台资深开发工程师史飞翔在实时数仓 Workshop 广州站的演讲。
-
10.09 10:00:54发表了文章
2022-10-09 10:00:54
往届作品回顾 | 第四届实时计算 Flink 挑战赛
2022 第四届实时计算 Flink 挑战赛火热报名中，提交截止时间为 10 月 20 日。
2022年09月
-
09.30 10:23:35发表了文章
2022-09-30 10:23:35
回顾｜Apache Flink Meetup · 北京站（附问题解答 & PPT 下载）
9月24日，Apache Flink Meetup 线上问题解答 + PPT 获取方式
-
09.21 16:07:30发表了文章
2022-09-21 16:07:30
议题征集｜Flink Forward Asia 2022 正式启动
FFA 2022 议题火热征集中，投递日期截止至 10 月 14 日。
-
09.16 18:14:27发表了文章
2022-09-16 18:14:27
活动报名｜9月24日 Apache Flink Meetup · 北京站，Flink 1.16 新版本发布！
Flink 1.16 新版本 x Flink Table Store 0.2 发布！线下交流+线上直播同步开启
-
09.16 14:54:57发表了文章
2022-09-16 14:54:57
Apache Flink 在小米的稳定性优化和实践
小米大数据部高级软件工程师张蛟在 FFA 2021 的演讲。
-
09.08 11:49:51发表了文章
2022-09-08 11:49:51
活动报名｜9月23日 实时数仓Workshop · 北京站
9.23 线下活动，9.24 线上视频回顾。
-
09.08 10:02:52发表了文章
2022-09-08 10:02:52
Apache Flink Table Store 0.2.0 发布
增加了 Hive、Spark 和 Trino 等计算引擎的对接支持，并且稳定了存储的格式。
-
09.02 10:30:38发表了文章
2022-09-02 10:30:38
技术解析｜Doris Connector 结合 Flink CDC 实现 MySQL 分库分表 Exactly Once 精准接入
本文主要介绍了 Flink CDC 分库分表怎么实时同步，以及其结合 Apache Doris Flink Connector 最新版本整合的 Flink 2PC 和 Doris Stream Load 2PC 的机制及整合原理、使用方法等。
2022年08月
-
08.30 15:31:35发表了文章
2022-08-30 15:31:35
5 大类应用场景，26 个大厂真实生产案例分享，2022 年度 Apache Flink 案例集发布
2022 版《Apache Flink 行业案例集》免费下载
-
08.26 10:34:45发表了文章
2022-08-26 10:34:45
实时数仓Workshop · 广州站 9.15 邀您参加！
9月15日，聚焦 Flink + Hologres 实时数仓在数据链路中扮演的角色与在智能商业中的重要价值。
-
08.24 09:49:07发表了文章
2022-08-24 09:49:07
阿里云实时计算 Flink 版 x Hologres: 构建企业级一站式实时数仓
阿里云 Flink、阿里云 Hologres 构建实时数仓上所具备的核心能力以及二者结合的最佳解决方案。
-
08.19 14:19:02发表了文章
2022-08-19 14:19:02
活动预约｜9.3 Lakehouse Meetup
9月3日下午 13:30 开始，一起探讨数据湖仓解决方案。
-
08.16 09:44:43发表了文章
2022-08-16 09:44:43
基于 Flink x TiDB，智慧芽打造实时分析新方案
智慧芽数据仓库架构师曲明星在 FFA 2021 的演讲。
-
08.09 17:28:01发表了文章
2022-08-09 17:28:01
基于 Flink 构建大规模实时风控系统在阿里巴巴的落地
阿里云实时计算产品经理李佳林（风元）在 Flink 峰会的演讲。
-
发表了文章
2023-02-03
Flink Table Store 典型应用场景
-
发表了文章
2023-02-01
基于 Flink+Pravega 的游戏服务器监控与调节系统设计
-
发表了文章
2023-01-30
网易游戏实时 HTAP 计费风控平台建设
-
发表了文章
2023-01-18
中原银行对金融行业实时数仓的现状与发展趋势思考
-
发表了文章
2023-01-16
Disney 流媒体广告 Flink 的应用实践
-
发表了文章
2023-01-13
Apache Flink 社区 2022 年度报告：Evolution, Diversity, Connection
-
发表了文章
2023-01-12
PyFlink 最新进展解读及典型应用场景介绍
-
发表了文章
2023-01-10
Flink 批作业的运行时自适应执行管控
-
发表了文章
2023-01-05
基于 Log 的通用增量 Checkpoint
-
发表了文章
2023-01-03
Flink 容错恢复 2.0 2022 最新进展
-
发表了文章
2022-12-29
Flink Shuffle 3.0: Vision, Roadmap and Progress
-
发表了文章
2022-12-28
上云节省 35%计算资源，420 个运维人天：运满满实时计算实践和思考
-
发表了文章
2022-12-22
FFA 2022 主会场 Keynote：Flink Towards Streaming Data Warehouse
-
发表了文章
2022-12-19
Flink 在米哈游的应用实践
-
发表了文章
2022-12-15
Flink Unaligned Checkpoint 在 Shopee 的优化和实践
-
发表了文章
2022-12-14
Flink 1.16：Hive SQL 如何平迁到 Flink SQL
-
发表了文章
2022-12-08
云与开源，共植数字世界的根
-
发表了文章
2022-12-05
FFA 2022 收官总结｜活动报告出炉，实时即未来！
-
发表了文章
2022-11-28
Flink Forward Asia 2022 主论坛概览
-
发表了文章
2022-11-26
投入上百人、经历多次双 11，Flink 已经足够强大了吗？
-
回答了问题
2022-01-06
Flink Forward Asia 2021 有奖问答
各位开发者，正确的提问是：
- 进入对应专场问答入口
- 添加回答：议题标题 + 问题 (而不是专场 + 问题哦)
还请关注 1 月 8-9 日的直播～
赞0 踩0 评论0 -
提交了问题
2021-12-29
Flink Forward Asia 2021 有奖问答
-
提交了问题
2021-12-28
Flink Forward Asia 2021 机器学习专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 生产实践专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 开源解决方案专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 流批一体专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 实时数仓专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 实时数据湖专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 平台建设专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 行业实践专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 核心技术专场
-
提交了问题
2021-12-28
Flink Forward Asia 2021 主会场
-
回答了问题
2019-07-17
实时计算Flink sink端写出到同名的DataHub和RDS，如何处理？
在create table的时候别名使用不同别名即可。
create table a <- 不同别名
()；create table b
();赞0 踩0 评论0 -
提交了问题
2018-10-26
实时计算Flink sink端写出到同名的DataHub和RDS，如何处理？
-
回答了问题
2019-07-17
flink on yarn大家实际生产上，是用yarn session方式还是single yarn job？这两个方式如何选择
社区了解到的，Single Job 更多些
赞0 踩0 评论0 -
回答了问题
2019-07-17
大神，请教一下阿里的Blink平台业务方使用是强制要求只能写sql和udf么？
参考下Hadoop过渡到Hive，绝大部分MR都使用SQL替换了。从软件演化角度来看，高阶表达更利于业务迭代。
阿里云实时计算(Blink) 实际上支持非SQL，购买独享模式，使用TableAPI或者DataStreamAPI都可以。
赞0 踩0 评论0 -
回答了问题
2019-07-17
Flink在Yarn HA模式下报错
修改为
yarn.client.failover-proxy-provider=org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider赞0 踩0 评论0 -
提交了问题
2018-10-18
Flink在Yarn HA模式下报错