Flink 在顺丰的使用实践

Flink 中文社区


 ▼

摘要：

本⽂由社区志愿者苗文婷收拾，内容源⾃顺丰科技大数据渠道研制工程师



首要内容为：

1. 建造布景
   
2. 建造思路
   
3. 落地实践
   
4. 运用事例
   
5. 未来规划
   

Tips：


点击


「阅览原





文」

  

欢迎咱们给 Flink 点赞送 star~

一、建造布景

顺丰是国内抢先的快递物流归纳服务商，通过多年的开展，顺丰运用大数据技能支撑高质量的物流服务。以下是一票快件的流通进程，能够看到从客户下单到终究客户收件的整个进程是十分长的，其间触及的一些处理逻辑也比较杂乱。为了应对杂乱事务的应战，顺丰进行了数据仓库的探究。

传统数仓首要分为离线和实时两个部分：

• 离线部分以固定的核算逻辑，通过守时调度，完结数据抽取，清洗，核算，终究产出报表；

• 而实时部分则是需求驱动的，用户需求什么，就立刻着手开发。

这种数仓架构在数据量小、对实时性要求不高的情况下运转得很好。但是跟着事务的开展，数据规划的扩大和实时需求的不断添加，传统数仓的缺陷也被扩大了。

• 
  从事务方针的开发功率来看
  
  

  
  

  实时指标选用的是需求驱动的、纵向烟囱式的开发形式，需求用户手写 Flink 使命进行开发，这种开发方法功率低门槛高，输出的方针很难一致办理与复用。

• 
  从技能架构方面来看
  
  

  
  

  
  

• 
  从渠道办理的视点来看
  
  

  
  

  传统数仓的实时方针开发是比较粗豪的，没有 Schema 的标准，没有元数据的办理，也没有打通实时和离线数据之间的联络。
  

  
  

  为了处理传统数仓的问题，顺丰开端了实时数仓的探究。实时数仓和离线数仓实践上处理的都是相同的事务问题，最大的差异就在于时效性。
  

• 离线数仓有小时级或天级的推迟；
  

• 而实时数仓则是秒级或分钟级的推迟。
  

其他特性，比方数据源、数据存储以及开发方法都是比较附近的。因而，咱们期望：

• 用户能从传统数仓滑润迁移到实时数仓，坚持杰出的体会；

• 一起一致实时和离线架构，加快数据产出，削减开发的撕裂感；

• 加强渠道办理，下降用户运用门槛，进步开发功率也是咱们的方针。

二、建造思路

通过总结，咱们提炼出以下 3 个实时数仓的建造思路。

1. 首要是通过一致数仓标准、元数据以及开发流程，使得用户到达开发体会上的批流一致。

2. 随后，引进 Hudi 加快数仓宽表，依据 Flink SQL 建造咱们的实时数仓。

3. 终究是加强渠道办理，进行数仓渠道化建造，完成数据一致接入、一致开发、以及一致的元数据办理。

1. 批流一致的实时数仓

建造批流一致的实时数仓能够分为以下 3 个阶段：

■ 1.1 一致数仓标准

首要，无规则不成方圆，建造数仓必须有一致的数仓标准。一致的数仓标准包含以下几个部分：

• 规划标准

• 命名标准

• 模型标准

• 开发标准

• 存储标准

• 流程标准

一致好数仓标准之后，开端数仓层级的区分，将实时和离线一致规划数仓层级，分为 ODS、DWD、DWS、ADS 层。

■ 1.2 一致元数据

依据以上一致的数仓标准和层级区分模型，能够将实时和离线的元数据进行一致办理。下流的数据办理进程，比方数据字典、数据血缘、数据质量、权限办理等都能够到达一致。这种一致能够沉积实时数仓的建造效果，使数仓能更好的落地施行。

■ 1.3 依据 SQL 一致开发流程

开发人员都知道，运用 DataStream API 开发 Flink 使命是比较杂乱的。在数据量比较大的情况下，假如用户运用 API 不标准或许开发才能缺乏，或许会导致功能和稳定性的问题。假如咱们能将实时开发的进程一致到 SQL 上，就能够到达削减用户开发本钱、学习本钱以及运维本钱的意图。

之前提到过咱们现已一致了实时和离线的元数据，那么就能够将上图左面的异构数据源和数据存储笼统成一致的 Table ，然后运用 SQL 进行一致的数仓开发，也便是将离线批处理、实时流处理以及 OLAP 查询一致 SQL 化。

■ 1.4 实时数仓计划比照

• 
  Lambda 架构
  
  

  Lambda 架构是在原有离线数仓的基础上，将对实时性要求比较高的部分剥离出来，添加了一个实时速度层。Lambda 架构的缺陷是需求保护实时和离线两套架构和两套开发逻辑，保护本钱比较高，别的两套架构带来的资源耗费也是比较大的。

  
  

• 
  
  
  

  为了应对 Lambda 架构的缺陷，Jay Kreps 提出了 ，移除了原有的离线部分，运用纯流式引擎开发。的最大问题是，流数据重放处理时的吞吐才能达不到批处理的等级，导致重放时发生必定的延时。

  
  

• 
  实时数仓计划比照与实践需求
  

  在实在的出产实践中，并不是必定要严厉遵从标准的 Lambda 架构或 ，能够是两者的混合。比方大部分方针运用流式引擎开发，少部分重要的方针运用批处理开发，并添加数据校正的进程。

  在顺丰的事务场景中，并非一切用户都需求纯实时的表，许多用户的报表仍是依靠离线 T+1 调度产出的宽表，假如咱们能够加快宽表的产出，那么其他报表的时效性也能相应地得到进步。

  别的，这个离线 T+1 调度产出的宽表，需求聚合 45 天内多个数据源的全量数据，不管是 Lambda 架构仍是 ，都需求对数据进行全量聚合，假如能够直接更新宽表，就能够防止全量从头核算，大大下降资源耗费和延时。

  
  

2. 引进 Hudi 加快宽表

之前说过，保护 Lambda 架构的杂乱性在于需求一起保护实时和离线两套系统架构。而关于这个缺陷，咱们能够通过批流一致来战胜。

通过权衡，咱们决议改造原有 Lambda 架构，通过加快它的离线部分来建造数仓宽表。此刻，就需求一个东西来实时快速的更新和删去 Hive 表，支撑 ACID 特性，支撑历史数据的重放。依据这样的需求，咱们调研了市面上的三款开源组件：Delta Lake、Iceberg、Hudi，终究挑选 Hudi 来加快宽表。

■ 2.1 Hudi 要害特性

Hudi 的要害特性包含：可回溯历史数据，支撑在大规划数据会集依据主键更新删去数据；支撑数据增量消费；支撑 HDFS 小文件紧缩。这些特性刚好能满意咱们的需求。

■ 2.2 引进 Hudi 加快宽表

引进 Hudi 有两种方法加快数仓。首要，在 ODS 层引进 Hudi 完成实时数据接入，将 ODS 层 T+1 的全量数据抽取改成 T+0 的实时接入，从数据源头完成 Hive 表的加快。

别的，运用 Flink 消费 Kafka 中接入的数据，进行清洗聚合，通过 Hudi 增量更新 DWD 层的 Hive 宽表，将宽表从离线加快成准实时。

■ 2.3 构建实时数仓宽表示例

这儿通过一个比如介绍怎么构建实时数仓宽表。

假定运单宽表由运单表，订单表和用户表组成，别离包含运单号、运单状况、订单号、订单状况、用户 ID、用户名等字段。

首要将运单表数据刺进宽表，运单号作为宽表主键，而且将运单号和订单号的映射存入暂时表。当订单表数据更新后，首要相关用户维表，获取用户名，再从暂时表中获取对应运单号。终究依据运单号将订单表数据增量刺进宽表，以更新宽表状况。

3. 终究架构

引进 Hudi 后，依据 Lambda 架构，咱们定制化的实时数仓终究架构如下图所示。实时速度层通过 CDC 接入数据到 Kafka，选用 Flink SQL 处理 Kafka 中的数据，并将 ODS 层 Kafka 数据清洗核算后通过 Hudi 准实时更新 DWD 层的宽表，以加快宽表的产出。离线层选用 Hive 存储及处理。终究由 ADS 层供给一致的数据存储与服务。

除了制定数仓标准和构建数仓架构，咱们还需求构建数仓渠道来束缚开发标准和流程，进步开发功率，进步用户体会。

三、落地实践

1. Hudi On Flink

顺丰是最早将 Hudi On Flink 引进出产实践的公司，顺丰内部运用版别依据 T3 出行的内部分支进行了许多修正和完善，大大进步了 Hudi on Flink 的功能和稳定性。

■ 1.1 完成原理

这儿介绍下 Hudi On Flink 的原理。Hudi 原先与 Spark 强绑定，它的写操作本质上是批处理的进程。为了解耦 Spark 而且一致 API ，Hudi On Flink 选用的是在 Checkpoint 期间攒批的机制，在 Checkpoint 触发时将这一批数据Upsert 到 Hive，依据 Upsert 成果一致提交或回滚。

H
udi On Flink 的完成流能够分解为几个进程：

1. 首要运用 Flink 消费 Kafka 中的 Binlog 类型数据，将其转化为 Hudi Record。

2. Hudi Record 进入 InstantTime Generator，该 Operator 并不对数据做任何处理，只担任转发数据。它的作用是每次 Checkpoint 时在 Hudi 的 Timeline 上生成大局仅有且递加的 Instant，并下发。

3. 随后，数据进入 Partitioner ，依据分区途径以及主键进行二级分区。分区后数据进入 File Indexer ，依据主键找到在 HDFS 上需求更新的对应文件，将这个对应联系按文件 id 进行分桶，并下发到下流的 WriteProcessOperator 。

4. WriteProcessOperator 在 Checkpoint 期间会积累一批数据，当 Checkpoint 触发时，通过 Hudi 的 Client 将这批数据 Upsert 到 HDFS 中，而且将 Upsert 的成果下发到下流的 CommitSink 。

5. CommitSink 会搜集上游一切算子的 upsert 成果，假如成功的个数和上游算子的并行度持平时，就以为本次 commit 成功，并将 Instant 的状况设置为 success ，不然就以为本次 commit 失利并进行回滚。

■ 1.2 优化

顺丰依据社区代码对 Hudi On Flink 进行了一些优化，首要意图是增强功能和进步稳定性。

• 
  二级分区
  
  

  关于增量写入的场景，大部分的数据都写入当天的分区，或许会导致数据歪斜。因而，咱们运用分区途径和主键 id 完成二级分区，防止攒批进程中单个分区数据过多，处理数据歪斜问题。

• 
  文件索引
  

  Hudi 写入进程的瓶颈在于怎么快速找到记载要写入的文件并更新。为此 Hudi 供给了一套索引机制，该机制会将一个记载的键 + 分区途径的组合映射到一个文件 ID. 这个映射联系一旦记载被写入文件组就不会再改动。Hudi 当时供给了 HBase、Bloom Filter 和内存索引 3 种索引机制。但是通过出产实践，HBase 索引需求依靠外部的组件，内存索引或许存在 OOM 的问题，Bloom Filter 存在必定的误算率。

  咱们研讨发现，在 Hudi 写入的 parquet 文件中存在一个躲藏的列，通过读取这个列能够拿到文件中一切数据的主键，因而能够通过文件索引获取到数据需求写入的文件途径，并保存到 Flink 算子的 state 中，也防止了外部依靠和 OOM 的问题。

• 
  索引写入别离
  
  

  原先 Hudi 的 Upsert 进程，写入和索引的进程是在一个算子中的，算子的并行度只由分区途径来决议。咱们将索引和写入的进程进行别离，这样能够进步 Upsert 算子的并行度，进步写入的吞吐量。

• 
  毛病康复
  
  

  终究咱们将整个流程的状况保存到 Flink State 中，规划了一套依据 State 的毛病康复机制，能够确保端到端的 exactly-once 语义。

2. 实时数仓的产品化

在实时数仓产品化方面，咱们也做了一些作业。供给了包含数据接入、元数据办理、数据处理在内的数仓开发套件。

■ 2.1 实时数据接入

实时数据接入选用的是表单式的流程接入方法，屏蔽了杂乱的底层技能，用户只需求通过简略的操作就能够将外部数据源接入到数仓系统。以 MySQL 为例，用户只需求挑选 MySQL 数据源，渠道就会主动抽取并展现 Schema ，用户承认 Schema 之后，就会将 Schema 刺进到渠道元数据中。

■ 2.2 实时元数据更新