关于flink:快手实时数仓保障体系研发实践

摘要：本文整顿自快手实时计算数据团队技术专家李天朔在 Flink Forward Asia 2021 实时数仓专场的演讲。次要内容包含：

1. 业务特点及实时数仓保障痛点
2. 快手实时数仓保障体系架构
3. 春节流动实时保障实际
4. 将来布局

点击查看直播回放 & 演讲 PDF

一、业务特点及实时数仓保障痛点

• 快手最大的业务特点就是数据量大。每天入口流量为万亿级别。对于这么大的流量入口，须要做正当的模型设计，避免反复读取的适度耗费。另外还要在数据源读取和标准化过程中，极致压迫性能保障入口流量的稳固执行。
• 第二个特点是诉求多样化。快手业务的需要包含流动大屏的场景、2B 和 2C 的业务利用、外部外围看板以及搜寻实时的撑持，不同的场景对于保障的要求都不一样。如果不做链路分级，会存在高低优先级凌乱利用的景象，对于链路的稳定性会产生很大的影响。此外，因为快手业务场景的外围是做内容和创作者的 IP，这就要求咱们构建通用维度和通用模型，避免反复烟囱建设，并且通过通用模型疾速撑持利用场景。
• 第三个特点是流动场景频繁，且流动自身有很高的诉求。外围诉求次要为三个方面：可能体现对公司大盘指标的牵引能力、可能对实时参与度进行剖析以及流动开始之后进行玩法策略的调整，比方通过对红包老本的实时监控疾速感知流动成果。流动个别都会有上百个指标，但只有 2-3 周的开发工夫，这对于稳定性的要求就很高。
• 最初一个特点是快手的外围场景。一个是提供给高管的外围实时指标，另外一个是提供给 C 端的实时数据利用，比方快手小店、创作者核心等。这对数据精度的要求极其高，呈现问题须要第一工夫感知并染指解决。

以上因素形成了快手实时数仓建设和保障场景的必要性。

在实时数仓保障的起始阶段，咱们借鉴了离线侧的保障流程和标准，依照生命周期划分了三个阶段：研发阶段、生产阶段和服务阶段。

• 研发阶段 构建了模型设计规范、模型开发标准以及公布的 checklist。
• 生产阶段 次要构建底层监控能力，对于时效性、稳定性、准确性几个方面进行监控，并且按照监控能力进行 SLA 优化和治理晋升。
• 服务阶段 明确了上游对接的服务规范和保障级别，以及对于整个服务的价值评估。

然而相比于离线，实时的学习老本颇高，实现以上建设后，各个结算仍然存在几个问题：

• 研发阶段：Flink SQL 的学习曲线相比于 Hive SQL 更高，容易在开发阶段引入隐患。另外，实时计算场景下，流动呈现洪峰时是否疾速生产，也是一个未知数。最初，DWD 层的反复生产对于实时侧的资源挑战也很大，在抉择数据源和依赖关系时须要思考资源问题。
• 生产阶段：state 没有清理机制会导致状态变大、作业频繁失败。另外高优先级和低优先级部署须要机房隔离，因而须要在上线前就安顿好，上线后再进行调整，老本会比离线高很多。
• 服务阶段：对于一个实时工作，最无奈承受的就是作业流程失败、重启，导致数据反复或者曲线掉坑的问题。为了防止这类问题，须要有标准化的计划，而离线大概率能够保障重启后数据一致性。

形象来看，实时数仓相比于离线，还存在几个保障难点，具体体现在以下几个方面：

• 高时效性。相比于离线的执行工夫，实时状况下，提早分钟级就要染指运维，对时效性要求很高。
• 复杂性。次要体现在两个方面：一方面数据不是导入即可查，数据逻辑验证的难度更高；另外一方面，实时大多是有状态，服务产生问题的时候状态不肯定可能被残缺保留，会存在很多无奈复现的 bug。
• 数据流量大。整体的 QPS 比拟高，入口流量级别在亿级。
• 问题随机性。实时数仓产生问题的工夫点更加随机，没有法则可循。
• 开发能力参差不齐。如何保障通用场景的开发计划对立，避免因开发计划不同而产生不可控的问题。

二、快手实时数仓保障体系架构

基于以上保障的难度，咱们设计了两条思路来解决，次要分为两个方面：

• 一方面是以开发生命周期为根底的正向保障思路，确保每一个生命周期都有标准和计划领导，标准化 80% 的惯例需要。
• 另一方面是以故障注入和场景模仿为根底的反向保障思路，通过场景模仿和故障注入，确保保障措施真正落地并合乎预期。

2.1 正向保障

正向保障的整体思路如下：

1. 开发阶段 次要做需要调研，针对开发过程中根底层如何开发、应用层如何开发进行标准化解决，能够解决 80% 的通用需要，残余 20% 的个性化需要通过计划评审的形式来满足，同时一直从个性化需要中积淀标准化计划。
2. 测试阶段 次要做品质验证和离线侧比照以及压测资源预估。自测阶段次要通过离线实时的一致性比照、server 看板和实时后果比照来保障整体准确性。
3. 上线阶段 次要针对重要工作上线须要筹备的预案，确认上线前动作、上线中部署形式和上线后的巡检机制。
4. 服务阶段 次要是针对于指标做监控和报警机制，确保服务是在 SLA 规范之内的。
5. 最初是 下线阶段，次要做资源的回收和部署还原工作。

快手的实时数仓分为三个档次：

• 第一，DWD 层。DWD 层逻辑侧比较稳定且很少有个性化，逻辑批改分为三种不同的格局数据：客户端、服务端和 Binlog 数据。

  • 第一项操作是拆分场景，因为实时数仓没有分区表的逻辑，所以场景拆分的目标是生成子 topic，避免反复生产大 topic 的数据。
  • 第二个操作就是字段标准化，其中包含纬度字段的标准化解决、脏数据的过滤、IP 和经纬度一一映射关系的操作。
  • 第三是解决逻辑的维度关联，通用维度的关联尽量在 DWD 层实现，避免上游过多流量依赖导致维表压力过大，通常维表是通过 KV 存储 + 二级缓存的形式来提供服务。
• 第二，DWS 层。这里有两种不同的解决模式：一是以维度和分钟级窗口聚合为根底的 DWS 层，为上游可复用场景提供聚合层的撑持；二是单实体粒度的 DWS 层数据，比方原始日志里外围用户和设施粒度的聚合数据，能够极大地缩小 DWD 层大数据量的关联压力，并可能更无效地进行复用。DWS 层数据也须要进行维度裁减，因为 DWD 层数据量过大，无奈齐全 cover 维度关联的场景，因而维度关联 QPS 过高并有肯定延时的需要，须要在 DWS 层实现。
• 第三，ADS 层。它的外围是依赖 DWD 层和 DWS 层的数据进行多维聚合并最终输入后果。

基于以上设计思路，不难发现针对 DWD 和 DWS 的拆流的逻辑、字段荡涤标准化和维度关联，都是针对不同格局但逻辑雷同。能够把根底的逻辑开发成模板化 SDK，后续雷同逻辑都应用雷同的 SDK API 办法。这样有两个益处，反复的逻辑不须要再复制一遍代码，一些优化的教训和教训也积淀在了模板里。

针对 ADS 层数据，咱们通过业务需要积淀出诸多解决方案，比方多维度的 PV/UV 如何计算、榜单如何计算、指标卡的 SQL 如何表白以及散布类存在回撤的场景如何产出。

SQL 自身上手快、效率高，能大规模简化开发工夫，但它的执行效率相比于 API 有肯定的劣势，所以针对于根底储层和 DWS 层大流量场景，咱们还是应用 API 进行开发，应用层通过 SQL 进行开发。

快手的大部分流动中，业务最关注的指标是某些维度下参加人数、支付金钱的累计曲线，并且心愿可能产出一个每分钟计算 0 点到以后时刻的曲线，这类指标开发笼罩了 60% 左右的流动侧需要。那么开发过程中有哪些难点呢？

用惯例的滚动窗口 + 自定义状态的计算对数据进行去重有一个弊病：如果窗口乱序较大，会造成数据失落重大，影响数据的准确性。如果心愿数据更准，就要接受更大的数据提早，而想要提早低一些就可能存在数据不精确的状况。此外，异常情况下会存在数据从某一个工夫点开始回溯的场景，回溯场景下增大吞吐量会因为取最大工夫戳导致两头后果失落。

为了解决这个问题，快手自研了渐进式窗口的解决方案，它存在两个参数，天级别的窗口和输入的分钟步长。整体的计算分为两个局部，首先产出一个天级别的窗口，读取数据源依照 key 进行分筒，把 key 雷同的数据分到同一个筒内，而后依照事件工夫进行 watermark 推动，超过对应的窗口步长就会触发窗口计算。

如上图所示，key=1 的数据分到同一个 task，task watermark 更新到超过步长产生的小窗口之后会合并产出 bitmap 和 pv 的计算结果，并发送给上游数据，依照 servertime 落到对应的窗口，并且通过 watermark 机制进行触发。在 global window 进行合筒操作时，会把分筒的后果进行累加和去重，最终输入后果。这样如果存在乱序和晚到的数据就不会抛弃数据，而是会记录提早之后的工夫节点，更好地保障了数据的准确性，整体的数据差别从 1% 降落到 0.5%。

另外一方面，watermark 超过步长 window 窗口就触发计算，曲线提早能够管制在一分钟以内实现，更好地保障了时效性。最初通过 watermark 管制步长的窗口输入能够保障步长窗口每个点都进行输入，输入曲线最大水平保障了平滑性。

上图是一个具体的 SQL 案例，外部是一个依照 deviceID 分筒，而后构建 cumulate window 的过程。window 有两个局部，一个是按天累计的计算参数，另外一个是 watermark 划分窗口的参数，外层会对不同分筒产生的指标进行聚合计算。

在上线阶段，首先是做好工夫线的保障标准，包含工夫、操作人、预案内容、操作记录和检查点。

1. 流动前，部署工作确保没有计算热点、check 参数是否正当、察看作业状况以及集群状况；
2. 流动中，查看指标输入是否失常、工作状态巡检以及遇到问题的故障应答和链路切换；
3. 流动后，下线流动工作、回收流动资源、复原链路部署及复盘。

这里的链路是从 Kafka 数据源开始导入到 ODS、DWD、DWS 层，针对 C 端用户会导入到 KV 存储里，针对剖析类场景会导入到 ClickHouse，最初生成数据服务。咱们将工作分成 4 个等级，p0 ~ p3。

• P0 工作是流动大屏，C 端利用对于 SLA 的要求是秒级提早以及 0.5% 内误差，然而整体保障工夫比拟短，个别流动周期都在 20 天左右，元旦类流动 1~2 天内实现。咱们应答提早的计划是针对于 Kafka 和 OLAP 引擎都进行了多机房容灾，针对于 Flink 做了热备双机房部署。
• 针对 P1 级别的工作，咱们对 Kafka 和 OLAP 引擎进行双机房部署，一方面双机房部署能够做容灾逃生，另一方面在线机房的配置比拟好，很少呈现机器故障导致作业重启的状况。
• 针对 P2 和 P3 级别的工作，咱们在离线机房部署，如果存在一些资源空缺的状况，会先进行 P3 工作，腾挪资源给其余工作应用。

服务阶段次要分成 4 个档次：

• 第一，SLA 监控次要监控整体产出指标的品质、时效性和稳定性。
• 第二，链路工作监控次要对工作状态、数据源、处理过程、输入后果以及底层工作的 IO、CPU 网络、信息做监控。
• 第三，服务监控次要包含服务的可用性和提早。
• 最初是底层的集群监控，包含底层集群的 CPU、IO 和内存网络信息。

准确性的指标具体包含以下三局部：离线实时指标一致性用来保障整体的数据处理逻辑是正确的，OLAP 引擎和利用接口一致性用来保障服务的解决逻辑是正确的，指标逻辑谬误报警用来保障业务逻辑是正确的。

• 准确性报警又分成 4 个方面，准确性、波动性、一致性和完整性。准确性包含主备链路侧的一些比照，维度下钻是否精确；波动性是掂量继续指标的稳定范畴，避免稳定大产生的异样；一致性和完整性通过枚举和指标度量保障产出统一且不存在完好的状况。
• 时效性的指标也有 3 个，接口提早的报警、OLAP 引擎报警和接口表 Kafka 提早报警。拆分到链路层面，又能够从 Flink 工作的输出、解决和输入三个方面进行剖析：输出外围关注提早和乱序状况，避免数据抛弃；解决外围关注数据量和解决数据的性能指标；输入则关注输入的数据量多少，是否触发限流等。
• 稳定性的指标有 2 个，一个是服务和 OLAP 引擎的稳定性、批流提早，另一个是 Flink 作业的复原速度。Flink 作业 failover 之后是否疾速复原，对于链路的稳定性也是很大的考验。稳定性次要关注作业执行的负载状况，以及对应服务依赖的状态、整体集群的负载以及单个工作的负载。咱们通过指标进行报警，指标拆解的子目标进行监控，构建整体的监控报警体系。

2.2 反向保障

线上流动失常的开发测试很难模仿真正的线上环境和压测进度，所以反向保障的重点是要测试流动流量预期的状况下是否扛住洪峰，以及呈现故障时如何解决？

外围思路是通过压测演练来模仿流动洪峰的实在场景。首先通过单作业压测确定每个作业的资源散布和作业所在集群的编排形式，通过全链路压测确保集群资源应用在肯定水位并且安稳生产洪峰，不会过大或过小。其次，进行容灾建设，次要针对作业失败、生产提早、机房故障等提出了一些保障伎俩。而后，通过演练的形式，确保这些伎俩能够被失常应用并且可能达到预期成果。最初，针对演练的预期和指标进行复盘和链路危险的改良。

咱们构建了本人的压测链路，下面是失常的链路，上面是压测链路。首先读取线上 topic 的数据作为压测链路的初始数据源，利用 rate limit 算法进行流量管制。比方有 4 个 task，心愿取得 1 万 QPS，那么每个 task 生成的 QPS 会限度在 2500，并且生成数据的过程中会利用人群包批改对应的 user 和生成的工夫戳，模仿当天实在的用户数。

读取压测的数据源 topic 并通过作业处理生成新的 topic 后，如何判断压测是否真正通过，有三个规范：

• 第一，确保作业输出读取提早为毫秒级，且作业自身无任何反压。
• 第二，CPU 的利用率不超过整体资源的 60%，保障集群有空余 buffer。
• 第三，计算结果和人群包保持一致，证实逻辑是正确的。

通过单作业压测之后，咱们能够失去很多信息用于领导后续工作。比方，能够证实流动能在预期流量下保障 SLA，能够挖掘作业性能瓶颈，领导优化达成对应规范以及场景 benchmark，不便低优作业的资源部署。

实现单作业压测之后，还是无奈判断所有作业是否齐全启动。对于 Flink 机房整体的 CPU、IO 还有 memory 压力等状况，咱们能够把每个作业依照压测目标值启动起来，察看整体作业和集群的体现。

那么如何判断全链路压测是否通过呢？也有三个规范：

• 第一，确保作业输出读取提早为毫秒级，且无反压。
• 第二，CPU 利用率整体不超过 60%。
• 第三，计算结果最终和人群包保持一致。

通过全链路压测之后，能够证实流动在预期流量的峰值状况下可能保障 SLA，确保 QPS 作用下作业的资源编排状况，提前确定每个作业所需的资源和部署参数，确保每个数据源上游最大流量信息，为后续的限流保障提供根底。

故障演练有两种形式：

• 一个是单作业的故障演练，包含 Kafka topic 作业故障、Flink 作业失败以及 Flink 作业 CP 失败。
• 二是更体系化的故障，比方链路故障，比方单机房故障如何保障失常产出，流动流量超过预期很多如何防止雪崩效应？某个作业 lag 超过一个小时，须要多久能复原？

容灾建设分为两个局部，链路的故障容灾和链路的容量保障。

链路的故障容灾保障外围是解决单机房和单作业失败复原工夫长的问题和服务的稳定性问题。Kafka 自身能够做双机房容灾，生成流量会写入到两个机房的 Kafka，呈现单机房故障时会主动把流量切换到另外一个机房，而且保障 Flink 作业无感知。另外一方面机房故障复原之后，能够主动探测 Kafka 机房的状态退出流量。

同样，容灾策略也实用于 OLAP 引擎。针对于 Flink 工作，咱们热备部署了双链路，主备链路同逻辑，某个机房呈现故障时能够间接将利用侧 OLAP 引擎切换到另一个链路应用，保障利用端对于故障是无感知的。

链路容量的保障是为了解决两个问题：如果流动流量超过预期很多，如何保障稳定性？如果产生了 lag，评估须要多久可能追赶生产提早？

依据之前全链路压测的后果，可能失去每个工作入口的最大流量，并且将这个流量值作为作业的最大限流值，当流动流量超过了预期很高，数据源侧会触发读取限流，Flink 作业会依照压测最大负载执行。这个时候作业生产虽有提早，然而可能爱护链路中其余作业失常运行。并且在洪峰完结后，能够依据 lag 数据和入口流量计算出作业恢复正常须要的工夫，这个是链路的故障容灾和容量保障的外围措施。

三、春节流动实时保障实际

春节流动有以下几个需要：

• 高稳定性，海量数据要求链路整体保持稳定或呈现故障可能疾速复原。
• 高时效性，亿级别流量下，要求大屏指标卡秒级提早、曲线 1 分钟级别提早。
• 高准确性，简单链路状况下，离线和实时指标差别不超过 0.5%。
• 高灵活性，可能反对流动过程中的多维分析利用场景。

春节流动的整体计划分为正向和反向的保障措施。

正向保障措施的根底是监控报警体系，分为两个局部。一方面是对时效性、准确性、稳定性做 SLA 指标报警建设。另外一方面是基于链路的监控体系建设，包含链路监控、链路依赖的服务可用性监控以及集群资源监控。

在监控体系的根底之上，正向保障措施次要是做开发阶段、测试阶段和上线阶段的标准化。开发阶段 80% 的需要通过标准化模板来解决，而 20% 的残余需要能够通过评审的形式解决危险问题。测试阶段通过比照的形式保障逻辑准确性，上线阶段做分期部署和工作巡检。

反向保障措施须要构建两个根底能力。第一是压测能力，次要是通过单作业压测确定工作性能瓶颈，从而更好地领导优化；通过全链路压测确定作业是否可能扛过洪峰，并为容灾能力提供数据根底。容灾能力次要是通过多机房部署、限流、重试、降级，确保在有故障的状况下有对应的计划。

最初通过故障演练的形式，一方面引入各个组件的故障定位，另一方面模仿流量峰值的状况，确保压测和容灾能力真正得以执行。

最初在上线阶段通过工夫线预案保障流动前、中、后操作步骤都有迹可循，流动完结后对于我的项目进行复盘，发现问题并反馈到正反两个方向的保障体系能力建设。

春节流动的实际取得了微小的胜利。时效性方面，面对上亿级别的流量洪峰，大屏外围链路指标卡秒级提早，曲线类一分钟内提早，单个工作解决数据量在万亿级别之上，在流量高峰期是秒级提早。准确性方面，外围链路离线和实时工作差别 0.5% 以内，大促流动过程无数据品质问题，无效应用 FlinkSQL 渐进式窗口开发，大幅度降低窗口失落导致的精度损失，数据差别从 1% 降到 0.5%。稳定性方面，外围链路依赖组建双机房容灾、Flink 集群热备双链路部署，呈现问题秒级切换，压测和容灾能力的积淀，为当前的流动保障体系建设奠定根底。

四、将来布局

基于对现有的方法论和利用场景的思考，咱们对将来布局也做了延长。

• 第一，保障能力建设。针对压测和故障注入造成标准化剧本预案，预案执行通过平台能力自动化操作。压测之后，可能对问题进行智能诊断，将过往的一些专家教训进行积淀。
• 第二，批流一体。过往的流动利用场景过程中，批和流是齐全割裂的两套体系，咱们在一些场景下做了流批一体的实际，并且正在推动整体平台化建设，通过对立 SQL 的形式晋升整体开发效率，并且机器错峰应用能够缩小作业压力。
• 第三，实时数仓建设。通过丰盛实时数仓内容层面，以及开发组件的积淀和 SQL 化的伎俩，达成开发效率的晋升，最终达到降本提效的目标。

点击查看直播回放 & 演讲 PDF

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…