共计 5681 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：本文整顿自美团实时数仓平台负责人姚冬阳在 Flink Forward Asia 2021 实时数仓专场的演讲。次要内容包含：
- 平台建设现状
- 遇到的问题及解决
- 将来布局
点击查看直播回放 & 演讲 PDF
一、平台建设现状
美团于 2018 年首次引入 Flink 实时计算引擎，过后的实时数仓概念还不太遍及，平台只提供了 Flink Jar 工作的生命周期治理和监控报警。
2019 年，咱们留神到实时计算的次要利用场景是解决离线数仓时效性低的问题。离线数仓曾经比拟成熟，通过 SQL 形式开发很简略，而数仓的实时局部次要通过 Flink DataStream API 来开发，门槛比拟高，而且与离线数仓的开发方式相比较为割裂。因而，咱们开始调研实时数仓的解决方案，指标是升高开发门槛，并尝试推广 FlinkSQL，最终将美团的实时数仓平台取名为 NAU。
2020 年，美团实时数仓平台正式上线。它向业务提供 FlinkSQL 作业开发入口，次要负责两个方面的工作：
- 首先，将实时数仓常见的数据源与离线表概念对齐，用数据模型进行治理；
- 其次，提供 FlinkSQL 开发配套的效率工具，比方校验和调试性能。
然而在理论推广过程中，咱们发现业务在 FlinkSQL 的运维方面门槛仍然比拟高，因而，咱们将接下来的工作重点转向了运维核心。
FlinkSQL 作业运维的痛点次要集中在两个方面：有状态 SQL 作业部署的断流问题和 SQL 作业的异样定位问题。为此，咱们通过 Checkpoint 长久化和状态生成的异步化来解决第一个问题，并通过提供作业的主动诊断来解决第二个问题。目前，整个实时数仓的平台化建设曾经初步齐备，将来咱们会在开发和运维能力上一直精细化，并且持续推动公司业务数仓架构的进化，比方流批生产的一体化、生产服务的一体化。
实时数仓目前已根本笼罩了公司的全副业务，为 100 多个业务团队提供了反对，比方美团优选、美团买菜、金融、骑行等业务。托管了 7000 多个实时数据模型，次要为 Kafka 表和 KV 表模型。线上运行 FlinkSQL 作业 4000+，新增的实时 SQL 作业占比曾经达到 70% 以上。从数据上看，FlinkSQL 曾经能够解决美团实时数仓大部分流解决的问题。
接下来以美团业务中的两个实时数仓生产链路为例，具体分享 FlinkSQL 的理论利用。
利用场景 1 是基于 FlinkSQL + OLAP 的实时生产链路。这个业务链路的实时数据源有两个，别离是业务 DB 的变更事件和业务服务的日志事件，这些事件首先会被收集到 Kafka 中，而后 DB 事件会按表名散发到新的 Kafka 中，DB 和日志的数据也会在这一层进行格局上的对立并实现实时数仓的 ODS 层。而后业务会应用 FlinkSQL 来荡涤和关联 ODS 层的数据，生成实时数仓的主题宽表，最初写入 OLAP 查问引擎做实时剖析。对于时效性要求不高的场景，局部业务还会在 OLAP 引擎上配置分钟级别的调度来缩小雷同查问的压力。
利用场景 2 与场景 1 的不同点在于，业务实时数仓的主题宽表数据并不是间接写入 OLAP 查问引擎，而是持续写入 Kafka，应用 FlinkSQL 做 APP 层的指标聚合，最终把预计算的指标数据写入 OLAP、DB 或 KV 这类应用层的存储。这种形式更适宜对接数据服务，因为它兼顾了数据的时效性和高 QPS 的查问。
上图是实时数仓平台的架构，分为集成、开发、运维、治理、平安 5 个模块别离建设。
集成模块次要关注的是数据模型的治理，具体包含 Kafka 和 KV 两种模型治理，治理的内容有数据源的 schema 信息和连贯信息等。
开发模块次要关注的是 FlinkSQL 转化业务需要，比方提供版本治理来记录业务需要的迭代过程，提供 FlinkSQL 的校验和调试，来确保开发的 SQL 正确表白了业务逻辑，反对业务应用自定义的 Flink UDF 函数和自定义的 Format 解析，让 FlinkSQL 能够扩大满足更多业务需要场景。
运维模块关注的是 SQL 作业的部署和运行时的监控。在监控方面，咱们提供了 SQL 作业的监控报警、异样日志和作业诊断，可能帮忙业务疾速发现和定位作业的异样；部署方面，咱们提供 SQL 作业的快照治理、AB 部署和参数调优，来帮忙业务解决 SQL 作业变更时的问题。
治理模块关注的是实时数仓的数据品质、资源老本，通过建设实时数仓的 DQC 监控，帮忙业务发现上游数据或产出数据的异样值 / 异样稳定；通过链路血统和资源计费，让业务能够量化实时数仓的生产成本，不便进行老本治理。
平安模块次要关注的是对数据流向的管控，提供数据源读写权限的治理和受限域机制，保障公司业务数据的安全性。
二、遇到的问题及解决
在理论推广 FlinkSQL 的过程中，咱们也面临了不少挑战。
2.1 双流关联大状态问题
首先是双流关联的大状态问题，FlinkSQL 的双流关联会保留左右流的历史数据来相互关联，须要关联的工夫距离越长，保留的历史数据就会越多，状态也就会越大。比方，要关联订单的下单事件和退款事件，并保障计算结果的正确性，须要思考这两个事件产生的距离，可能是一个月甚至更久。
上图左侧是一个双流关联的有状态 SQL 作业，图中的 Mem 和 Disk 组成了 SQL 作业的 TaskManager 节点，SQL 作业状态后端应用 RocksDB，状态长久化在 HDFS 文件系统上。一开始咱们尝试把 SQL 作业的状态设置为保留一个月，但 SQL 作业会变得不稳固，呈现内存超限、状态读取性能降落等问题，只能一直减少作业的 TM 数和内存大小来缓解。
即便这样，业务上依然存在两个痛点。首先是关联数据初始化难，目前公司 Kafka 数据源对历史回溯有限度，因而业务不能构建出残缺的历史状态，即便 Kafka 反对了更久的回溯，状态初始化的效率也仍然是一个问题。其次，内存资源开销大，特地是当多个 SQL 作业关联雷同的数据源时，须要为每个 SQL 作业都调配相应的内存资源，不同 SQL 作业间的状态是隔离的，作业间雷同的关联数据不能复用。
对于上述问题，咱们提出了冷热关联拆散的解决方案。假如关联两天前的数据是绝对低频的且状态回滚不会超过两天，那么能够定义两天前的数据为冷数据，两天之内的数据为热数据。
解决方案
如上图所示，左侧的 SQL 作业通过设置状态保留时长，只保留 T+0 和 T+1 这两天的热数据，而 T+2 及更久以前的冷数据则通过批工作每天从 Hive 同步到外存 KV 中。关联时，若状态中的热数据不存在，则再通过拜访外存 KV 来关联冷数据。右侧是另外一个 SQL 作业须要关联雷同的数据源，它与左侧的 SQL 作业共享外层 KV 中的冷数据。
对于第一个痛点，因为状态管制在了两天内，SQL 作业上线时，关联数据初始化的数据量失去了管制。对于第二个痛点，因为两天前的大部分数据都保留在外层 KV 中，不同的 SQL 作业都能够查问外存 KV，从而能够节俭大量内存资源。
2.2 SQL 变更状态复原问题
第二个问题是有状态 SQL 逻辑变更后状态如何复原？FlinkSQL 反对有状态的增量计算，状态是增量计算的历史累计，实际上业务须要批改逻辑的状况很多，上图右侧列出了一些常见的 SQL 变更状况，比方新增聚合指标、批改原指标口径、减少过滤条件、新增数据流关联、减少聚合维度等。
举个例子，业务减少了更多服务维度，在数据产品上就须要扩大剖析的维度，因而也须要批改 FlinkSQL 减少聚合维度。然而上述 SQL 逻辑变动后却不能从之前的状态复原，因为历史状态对于变更后的 SQL 不能保障其完整性，即便复原后也不能百分百保障后续计算的正确性。这种状况下，业务为了保证数据的正确性，须要从历史回溯从新计算，回溯的过程会导致线上断流，但业务又不心愿就义太多的时效性。
解决方案
针对这个问题，咱们给出了三种解决方案。
解法 1：双链路切换。此解法的要害是再搭建一条雷同的实时链路作为备用链路，当变更有状态 SQL 时，能够在备用链路上做回溯，从新计算历史数据，回溯实现后先验证备用链路的后果数据，确保没问题后再在链路最上游的数据服务层切换读取的表，实现整个变更流程。
解法 2：旁路状态生成。与双链路切换不同点在于，这里变更的是链路上的单个作业，思路是长期启动一个旁路作业来回溯，构建出新逻辑的状态，验证数据实现后再重启线上作业，以此实现 SQL 和状态的同时切换。
解法 3：历史状态迁徙，前两个办法的思路比拟相似，都是基于历史数据从新计算，构建出新状态。但这个思路是基于历史状态迁徙出新状态，这种办法构建出的新状态尽管不能保障完整性，但在某些状况下，业务也是能够承受的。目前咱们通过革新 State Process API 反对在 SQL 算子及其上下游关系不变的状况下，容许 Join 和 Agg 算子来新增列。
上述三种形式各有长处，能够从普适性、资源老本、线上断流、期待时长四个维度来对以上三个解决方案进行横向比拟。
普适性是指在保证数据正确的前提下反对的 SQL 变更范畴，前两个办法都是从新计算，状态是残缺的，因而比计划 3 的普适性更高。
资源老本是指实现 SQL 变更所须要的额定 Flink 或 Kafka 资源，办法 1 须要构建整条链路，须要更多的 Flink 和 Kafka 资源，因而老本最高。
线上断流指的是在变更过程中导致上游数据提早的时长，办法 1 是在数据服务层做切换，简直没有断流；办法 2 的断流时长取决于作业从状态复原的速度；办法 3 除了状态复原，还须要思考状态迁徙的速度。
期待时长指的是实现整个变更流程须要的工夫，前两个办法都须要从新计算，因而比办法 3 的等待时间更长。
上图是办法 2 的平台自动化流程。流程分为七个阶段，变更流程执行的工夫较长，可能须要几十分钟，通过流程条以及图中每个阶段的执行日志能够让用户感触到变更的进度和状态。咱们还为用户做了自动化指标查看，比方在第 2 个阶段的旁路数据回溯中，咱们会查看作业生产 Kafka 的积压指标，来判断回溯是否实现，实现后主动制作新逻辑状态。再比方在第 6 个阶段，原作业从旁路作业启动时会比拟 Kafka Offset 指标来比拟两个作业的生产进度，确保线上作业重启后不会少发数据。
2.3 FlinkSQL 调试繁琐问题
遇到的第 3 个问题是 FlinkSQL 调试繁琐，操作步骤多，业务须要创立额定的作业和 Kafka，还要将导出的后果进行存储。此外，输出结构简单，为了针对性地调试某种输出场景，业务须要写代码来构建音讯并写入数据源，甚至须要对多个不同数据源音讯到来的程序进行管制。上图左侧能够看到，为了做 FlinkSQL 调试，须要手动搭建一条与线上隔离的调试链路，而后写入 Mock 数据。
解决方案
针对上述问题的解法是：基于文件调试一键化。首先业务在 Web 端能够在线编辑 Mock 数据，Mock 数据是有界的音讯序列，它的初始化能够先从线上抽样，而后再由业务进行批改。业务构建完 Mock 数据后，会将 SQL 作业的 Mock 数据长久化到右侧的 S3 文件对象零碎上。业务在 Web 端点击调试，左侧发动的调试工作会在与线上隔离的服务器上单过程执行，执行时会从 S3 获取之前上传的 Mock 数据，而且能够依据 Mock 数据指定的多源音讯之间的达到程序和音讯之间的发送距离来执行，执行实现后会将输入后果也长久化到 S3，最初在 Web 端查问 S3 出现给业务。
更多状况下业务不须要批改 Mock 数据，只须要做抽样和执行两步操作。另外咱们也反对了一些调试的高级性能，比方反对管制音讯的程序和距离。
上图是基于以上解法的调试工具。业务会为 SQL 作业创立多个测试用例，其中包含了 Source 的 Mock 数据和 Sink 的预期后果。执行调试后，会查看所有测试用例的通过状况，通过的条件是要保障后果流 Merge 之后的表与预期表数据统一。
2.4 SQL 作业异样定位问题
第 4 个问题是 FlinkSQL 作业的异样定位。作业异样是指作业生产 Kafka 呈现了积压，为了解决这个问题，须要定位出产生积压的起因。而定位起因时，归因的门路比较复杂，排查门槛比拟高。另外因为归因的门路短少系统化的积淀，定位破费的工夫也比拟长。随着 SQL 作业的数量越来越多，如果齐全依赖人工排查，工作量将会十分微小。
解决方案
针对上述为的解决办法是实现 SQL 作业的自动化异样诊断。通过 Flink Reporter 上报 SQL 作业的运行指标，并长久化到 TSDB 中用于历史查问。同时也会长久化 SQL 作业的运行日志，报警服务会依据规定监控 SQL 作业上报的 Kafka Offset 指标，当生产的 Offset 落后于生产的 Offset 时，会断定位作业产生生产积压，而后发出报警并下发异样事件，诊断服务会监听报警服务的异样事件。
异样产生时，依据异样工夫窗口内作业日志和作业指标剖析异样起因，诊断服务能够通过减少规定来积淀人工排查的教训。比方产生了 Restart，就会从日志中依据关键字来提取异样信息，未产生 Restart 则会依据反压指标找出瓶颈节点，而后联合 GC 指标、数据歪斜、火焰图等来剖析瓶颈的起因，最初提出调优倡议。
上图展现了诊断出业务音讯脏数据的例子。图中的运行详情一栏会给出 SQL 作业在每个工夫检查点的诊断状况，绿色表明运行失常，红色表明作业存在异样，通过这个工夫线能够分明看到异样产生的工夫点。诊断后果栏中能够看到异样的起因、详情和倡议。比方在这个事例中，起因是业务音讯存在脏数据，在详情中能够看到导致作业异样的原始音讯内容，在倡议中会提醒业务配置脏数据的解决策略。
三、将来布局
将来，美团实时数仓平台的布局次要包含以下两个方面。
- 首先，是流批一体开发运维，咱们行将在实时数仓平台集成数据湖存储，并凋谢 FlinkSQL 的批作业，在存储和计算层都做到流批对立，进步工作效率。
- 其次，是作业的主动调优，持续晋升作业诊断的准确率以及作业重启的效率。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…
