华人澳洲中文论坛

热图推荐

    Flink 流批一体在字节跳动的探究与理论

    [复制链接]

    2022-9-9 07:32:30 33 0

    配景


    字节跳动旗下具有今日头条、抖音等多款产品,天天办事着数亿用户,由此发生的数据量和计算量也是很大的:
    EB 级别海量的存储空间天天均匀 70PB 数据的增量每秒钟百万次数的实时保举申请超过 400 万核的流式计算资源、500 万核的批式计算资源这对咱们的全部架构,包罗计算架构和存储架构都带来了微小的应战。
    业务窘境


    如上图所示,左侧是一个十分典型,业界运用也得多的数据链路图。这个数据链路是一个典型的 Lamda 架构,全部数据链路分为批式计算链路和流式计算链路。
    在字节跳动外部,通常需求批式计算和流式计算两条链路独特办事于上游的运用。
    批式计算链路中,咱们次要运用 Spark 引擎,经过 Spark 引擎在批式存储中拿到数据,通过 ETL 的计算后,存入上游的存储,从而办事上游的运用。流式计算链路,也是咱们全部实时保举、实时信息流的中心链路。咱们会经过动静核心件把实时数据进行缓存存入,而后应用 Flink 实时计算引擎进行处置,处置后通过动静两头件的缓存传输存入上游的存储,来办事上层的运用。全部计算架构分红两条链路,带来了两个对比重大的问题:
    计算不同源保护本钱高。批式计算次要使用 Spark 引擎,流式计算使用 Flink 引擎。保护两套引擎就象征着使用两套代码,工程师的保护本钱和学习本钱都十分高。数据统一性和品质难以保障。两套代码之间不克不及互相复用,所以数据的统一性和数据的品质难以保障。无奈混合调度形成资源挥霍。批式计算和流式计算的顶峰期是不同的。对流式计算来讲,用户的使用顶峰期个别是白昼或早晨十二点以前,那末这些时间段也就是流式计算的顶峰,此时对计算资源的需要是十分高的。相对于而言,批式计算对运算时间并无严格的限度,好比能够在早晨十二点之后到早上6、7点之间进行少量运算。所以,假如流式计算和批式计算的资源无奈进行混合调度,那末就无奈对运算资源进行错峰使用,形成资源的微小挥霍。存储不同源数据纷歧致,保护本钱高。假如两条链路同时办事于上游运用的话,那末两套存储零碎也是分隔开的,仍然存在数据纷歧致的问题。同时,保护流式、批式两套存储零碎的本钱也十分高。针对上述窘境,在字节跳动外部,咱们选择了流批一体的解决计划
    甚么是流批一体
    那末,甚么是流批一体呢?
    从计算层面来说,就是用同一个引擎、同一套代码及一样的 API ,同时处置无限的数据流和有限的数据流,同时应答在线处置和离线处置(其中无限数据的处置对应离线处置,而有限数据的处置则对应在线处置),达到降本增效的目的。在存储方面,流批一体即存储零碎可以同时知足流式数据和批式数据的存储,并可以无效地进行协同以及元数据信息的更新。架构体系使用流批一体后,数据流向如下图左侧流程图所示。


    无论是流式数据仍是批式数据,均可以间接或通过简略加工后存入一致存储中。然后,使用流批一体一致的计算引擎进行 ETL 计算,再办事上游的运用。由此,全部流批一体的架构本质上完成了计算同源和存储同源。
    计算同源。用一套代码、一套逻辑去处置流式工作和批式工作,达到了降本增效的目的,同时也大幅晋升了资源利用率。存储同源。在存储方面一致存储,防止了存储资源的挥霍,同时也在很大的水平上防止了数据纷歧致。字节跳动的流批一体理论在字节跳动,咱们使用 Flink 作为流批一体一致的计算引擎,Iceberg 作为流批一体一致的存储形式。简略的数据流向如下图。


    在下游取到信息后,按照 Binlog 信息,使用 BMQ(字节跳动自研的云原生动静队列引擎) 也就是动静两头件产品,将数据实时传输到流批一体计算引擎 Flink 中,进行流式处置或批式处置后,将全部数据 更新到 Iceberg 数据湖。数据湖的存储底座也是字节跳动自研的存储底座——大数据文件存储(CloudFS)。
    为何选择 Flink
    咱们为何会选择 Flink 作为流批一体的计算引擎呢?
    次要缘故在于,Flink 是一个面向无限流和有限流有形态计算的散布式计算框架,它可以反对流处置和批处置两种运用类型。
    在传统意义上,Flink 是一个有限的数据流。但若咱们用一个个的时间窗口把有限的数据流进行切分,咱们就失掉得多无限数据流,对 Flink 来讲,批式数据只是流式数据的一种特例。


    无论是有限数据流仍是无限处置流,Flink 均可以经过同一种 API、同一套代码进行处置之后,办事上游的数据。这样的流程也能够极大地增加工程师的学习和保护本钱。


    能够说,Flink 无论是从下层的代码层面、SDK 层面、API 层面,仍是上层的调度器层面,都是针对流批一体的总体架构来进行设计的,是能够从上至下残缺地反对流批一体的数据处置引擎。


    Flink 流批一体架构
    保举零碎流批一体理论
    上面以字节跳动的保举零碎为例,向大家论述字节跳动外部使用流批一体的典型理论。
    保举零碎在字节跳动占领侧重要的地位。今日头条的旧事、抖音的视频,每一个条信息流都需求由保举零碎进行保举。如前文所述,全部保举零碎天天承载着宏大的保举工作量和数据量。
    在保举零碎的全部数据处置链路中,流式处置和批式处置都占领侧重要的地位。尤为是在特点计算模块,保举零碎需求为用户实时地保举信息流,包管实时性和精确性,同时也需求进行模型训练以晋升保举精确性。双数据链路的设计带来了诸多问题。
    双链路存在的中心问题


    保举零碎数据链路笼统图
    在流式链路中,咱们接纳用户申请,获取用户的实时在线特点,这些实时在线特点通过实时的流式处置之后,再结合在线特点库,就能失掉一个对比宏大的特点组。随后,将全部特点组输出到在线预测模型中,就能失掉预测的后果,从而实时地为用户保举信息流。
    同时,这些特点也会被存入离线存储(如 HDFS)中,后续会利用这些特点进行线下的批式模型训练。关于离线训练来讲,存入 HDFS 中的数据,通过批式的 ETL 处置后,输出到离线的模型训练中,训练出的模型能够用于更新在线办事的模型,从而更精确地办事用户。
    但是,正如上文所述,保举零碎的数据链路分了在线和离线两个体系,所以保举零碎在计算和使用在线特点和离线特点时,需求分别使用两种不同计算引擎和存储进行在、离线特点处置,带来了下列问题:
    对流处置和批处置分别保护两套代码,业务本钱太高特点回溯难度大如何使用历史数据初始化形态难定义数据不一致,存储本钱高Flink SQL 完成计算一体针对这些业务窘境和中心问题,咱们使用了 Flink SQL 去完成全部计算的流批一体。在全部数据处置链路中,咱们基于 Flink 引擎,使用 Flink SQL 的形式同时处置流式工作和批式工作,由此能够达到:
    同时反对 Unbounded、Bounded 数据源反对 Join 和 Union流批一体的履行模式自定义一致 Sink Connectors经过 Flink SQL 完成流批一体后,全部数据链路在计算的速度、特点的迭代,及业务降本增效上都取患了极大的效果。次要缘故在于使用 Flink SQL 完成流批一体后:
    同一份代码既能够实时计算,又能够批式计算节俭开发本钱,减速特点迭代进程


    如上图所示,保举零碎中的特点需求按期回溯并用以更新保举模型,包管在线保举的精确性。使用 Flink SQL 完成了流批计算一体后,咱们能够用同一套代码去进行实时计算和批式计算,批式计算能够使用与实时计算一样的代码进行历史数据的回溯,这就包管了数据统一。
    Iceberg 完成存储一体
    在存储方面,咱们选用了 Iceberg 作为一致的存储格局。如下图所示,特点数据通过字节跳动自研的动静队列引擎 BMQ 一致地流入 Flink 引擎,在 Flink SQL 进行处置之后,再 Upsert 到全部数据库傍边,进行一致的办理。


    基于 Iceberg 完成特点的一致存储,具备下列才能:
    存储流批一体,反对元数据的更新和办理提供 ACID 包管和快照功用并发读写计算存储引擎解耦Arrow 向量化数据传输小文件 Compaction优化收益从总体业务收益来看,采取 Flink + Iceberg 的流批一体架构后,取患了较为显著的降本增效成果:
    保护一套数据处置代码,人力本钱大幅升高特点存储本钱升高40%以上Arrow 数据传输进行特点训练,CPU 损耗升高13%,网络 IO 升高40%云原生计算流批一体解决计划
    云原生计算团队将字节跳动外部流批一体计划进行整合优化后,输入了云原生计算平台——一个开箱即用的、基于 Kubernets 的大数据 & AI 开发平台。
    云原生计算平台部署灵敏,既能以火山引擎的私有云为底座,也能以专有云及其余的 Kubernets 底座进行部署。
    在火山引擎资源底座的根底之上,咱们还提供丰硕的资源调度战略、自动化流水线的 CICD 交付,以及丰硕的资源办理、数据办理、功课办理等功用。


    云原生计算平台架构
    在此之上,是字节跳动流批一体解决计划的中心引擎。
    首先是流批一体的存储。流批一体存储次要是由两部份组成,一部份是火山引擎自研的大数据一致存储 CloudFS——作为全部存储层和数据减速层为下游的引擎提供办事。另外一部份是 Iceberg,咱们以 Iceberg 为存储层,利用下层的 Table Format 进行元数据信息的办理。与此同时,经过对数据和源数据的操作,减少全部数据流数据的管控性和流转速度。
    其次是三款计算引擎。
    Flink 实时计算引擎。咱们在全部链路中会把 Flink 作为流批一体的引擎。Spark 批式计算引擎。Spark 其实也是一款流批一体的计算引擎,在批式计算有它共同的劣势。Ray 静态引擎。Ray 静态引擎相对于较新。咱们用全部 Ray 静态引擎来做资源的极致扩缩、极致弹性,办事数据挖掘场景。在三款次要的计算引擎以外,还有字节跳动自研的云原生动静引擎 BMQ,及凋谢搜寻引擎 Open Search。经过这五款引擎,咱们打造了一个端到真个数据链路——数据存入大数据一致文件存储(CloudFS)之后,经由不同的引擎进行处置,办事下层业务。
    平台管控台 UI 及大数据开发平台一致办理数据处置进程,同时全部云原生计算平台生态凋谢,能够对接各种大数据开发平台以及 AI 开发的 Studio IDE。
    最下层是运用层。由主引擎及存储组成的流批一体解决计划,能够造成数据可视化、平安及金融风控、数据化经营等解决计划,端到端地办事数字营销,实时大屏、车联网等业务场景。
    总的来讲,在云原生计算平台流批一体解决计划中,咱们选择了 Flink 作为流批一体的计算引擎,CloudFS 和 Iceberg 作为流批一体的一致存储,办事机器学习场景和数据处置场景,无论是字节外部的保举零碎,仍是对内部提供办事,都可以针对这两种场景提供齐备的办事。
    以后,云原生计算平台旗下私有云产品流式计算 Flink 版大数据文件存储(CloudFS)都在收费公测中,扫码中转官网,欢送请求试用:
    流式计算 Flink 版-火山引擎
    大数据文件存储-火山引擎
    另外,云原生计算平台部署灵敏反对私有云、混合云及多云部署,片面贴合企业上云战略,理解更多混合云信息,欢送关注大众号【字节跳动云原生计算】,经过后盾分割云原生计算小助手
    相干文章保举
    亿级用户面前的字节跳动云原生计算最好理论
    字节跳动使用 Flink State 的教训分享
    字节跳动基于 Iceberg 的海量特点存储理论
    收费公测|火山引擎大数据文件存储公测现已开启

    发表回复

    您需要登录后才可以回帖 登录 | 立即注册

    返回列表 本版积分规则

    :
    中级会员
    :
    论坛短信
    :
    未填写
    :
    未填写
    :
    未填写

    主题43

    帖子50

    积分228

    图文推荐