首页 快递行业资讯 Flink 在顺丰的使用实践

Flink 在顺丰的使用实践

Flink 中文社区  ▼ 摘要: 本⽂由社区志愿者苗文婷收拾,内容源⾃顺丰科技大数据渠道研制工程师 首要内容为: 建造布景 建造思路 落地实践 运用事例 未来规划 Tips: 点…






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 实时元数据更新



本文来自网络,不代表快递资讯网立场。转载请注明出处: http://www.llaiot.com/express-industry-information/3153.html
上一篇
下一篇

为您推荐

返回顶部