LAS 服務(wù)是什么？LAS 有哪些優(yōu)化特性？本文將從基礎(chǔ)概念、數(shù)據(jù)庫(kù)內(nèi)核特性優(yōu)化、數(shù)據(jù)服務(wù)化、業(yè)務(wù)實(shí)踐等角度全方位介紹湖倉(cāng)一體架構(gòu)在LAS的探索與實(shí)踐。

LAS服務(wù)是什么？

在了解 Las 服務(wù)是什么之前，先來(lái)了解一下數(shù)據(jù)平臺(tái)整體行業(yè)的發(fā)展趨勢(shì)，大概分為三個(gè)階段。

第一階段，一般被稱為傳統(tǒng)數(shù)倉(cāng)，一種從 1980 年開(kāi)始的基于傳統(tǒng)數(shù)據(jù)庫(kù)技術(shù)來(lái)做的 BI 分析場(chǎng)景。在這種架構(gòu)下，通常計(jì)算和存儲(chǔ)是高度一體的。整體系統(tǒng)能支撐的計(jì)算能力，依賴于服務(wù)提供商的硬件配置，整體成本高，存在物理上限，擴(kuò)展起來(lái)比較麻煩。

第二階段，隨著技術(shù)的演進(jìn)， 2010 年開(kāi)始出現(xiàn)了以 Hadoop 技術(shù)體系為主流的傳統(tǒng)數(shù)據(jù)湖。在以 Hadoop 技術(shù)為主的數(shù)據(jù)平臺(tái)架構(gòu)下，通常可以支持服務(wù)在普通硬件上面去部署，整體的計(jì)算和存儲(chǔ)的擴(kuò)展性都得到了解決。基于開(kāi)源技術(shù)生態(tài)，多個(gè)大型公司也參與到數(shù)據(jù)湖技術(shù)發(fā)展中來(lái)，整體生態(tài)繁榮度也在逐步提升。

但在這一階段凸顯出了一個(gè)問(wèn)題，隨著生態(tài)技術(shù)的發(fā)展，越來(lái)越多的開(kāi)源組件開(kāi)始累積。對(duì)于一個(gè)企業(yè)來(lái)說(shuō)，為了解決不同領(lǐng)域的問(wèn)題，需要運(yùn)維多個(gè)開(kāi)源的組件，來(lái)滿足不同領(lǐng)域的數(shù)據(jù)需求，就導(dǎo)致整個(gè)企業(yè)的技術(shù)運(yùn)維成本逐步提升。

基于這個(gè)問(wèn)題，隨著技術(shù)的進(jìn)一步發(fā)展，在 2020 年，湖倉(cāng)一體的架構(gòu)開(kāi)始被提出。

相比起傳統(tǒng)數(shù)據(jù)湖，湖倉(cāng)一體架構(gòu)支持原生的 ACID 能力，支持像 BI 分析、報(bào)表分析，機(jī)器學(xué)習(xí)和流式分析多種類型的計(jì)算范式，以及云上的對(duì)象存儲(chǔ)和彈性計(jì)算能力。以上能力，讓湖倉(cāng)一體架構(gòu)能夠有效地去解決企業(yè)的對(duì)數(shù)據(jù)規(guī)模，以及對(duì)計(jì)算能力的彈性伸縮需求。同時(shí)，湖倉(cāng)一體可以在很大程度上規(guī)避傳統(tǒng) Lambda 架構(gòu)存在的多個(gè)計(jì)算組件，或者多種架構(gòu)范式導(dǎo)致的架構(gòu)負(fù)擔(dān)，讓企業(yè)能夠更專注地去解決他們的業(yè)務(wù)價(jià)值。

LAS 就是基于湖倉(cāng)一體的架構(gòu)進(jìn)行設(shè)計(jì)的。從上圖來(lái)看，LAS 架構(gòu)整體上分為三個(gè)部分。最上層是開(kāi)發(fā)工具層，開(kāi)發(fā)工具層會(huì)通過(guò)計(jì)算層提供的統(tǒng)一 SQL 訪問(wèn)服務(wù)去訪問(wèn)計(jì)算層，根據(jù)用戶的 SQL 類型自動(dòng)做 SQL 解析。所有引擎計(jì)算能力統(tǒng)一由彈性容器服務(wù)來(lái)提供，可以支持彈性伸縮，按需使用。

再往下就是湖倉(cāng)一體的存儲(chǔ)層。首先，湖倉(cāng)一體存儲(chǔ)會(huì)通過(guò)統(tǒng)一的元數(shù)據(jù)服務(wù)，向計(jì)算層提供統(tǒng)一的元數(shù)據(jù)視圖，屏蔽底層的具體元數(shù)據(jù)實(shí)現(xiàn)細(xì)節(jié)，可以使多個(gè)引擎無(wú)縫對(duì)接到統(tǒng)一的元數(shù)據(jù)服務(wù)。

接下來(lái)是湖倉(cāng)存儲(chǔ)引擎，它主要提供了事務(wù)管理能力，也就是 ACID 的能力，以及對(duì)數(shù)據(jù)批流一體的讀寫(xiě)能力。

再往下就是 LAS 基于火山引擎對(duì)象存儲(chǔ)服務(wù) TOS 和 CloudFS ，來(lái)提供 EB 級(jí)的數(shù)據(jù)存儲(chǔ)能力和數(shù)據(jù)訪問(wèn)的緩存加速能力。

以上就是 LAS 整體的技術(shù)架構(gòu)。

LAS 數(shù)據(jù)湖內(nèi)核剖析

這一版塊將向大家呈現(xiàn) LAS 數(shù)據(jù)湖內(nèi)核的特性及優(yōu)化。

LAS 的數(shù)據(jù)湖內(nèi)核—— ByteLake 它是什么？

首先，ByteLake 是基于開(kāi)源 Apache Hudi 進(jìn)行內(nèi)部增強(qiáng)的湖倉(cāng)一體存儲(chǔ)引擎，提供湖倉(cāng)一體的存儲(chǔ)能力。

它的第一個(gè)主要能力是提供了湖倉(cāng)統(tǒng)一的元數(shù)據(jù)服務(wù)，完全兼容開(kāi)源的 Hive Metastore，可以無(wú)縫對(duì)接多種計(jì)算引擎。第二個(gè)主要能力是可以支持對(duì)海量數(shù)據(jù)的 Insert，完全兼容 Hive SQL，可以平遷傳統(tǒng)數(shù)倉(cāng)場(chǎng)景下的 Hive 任務(wù)。第三，ByteLake 支持對(duì)大規(guī)模歷史數(shù)據(jù)的 Update 和 Delete，以及對(duì)新增數(shù)據(jù)的 Upsert 和 Append 能力。最后，ByteLake 支持流批一體的讀寫(xiě)能力，提供流式讀寫(xiě)的 source 和 sink，支持近實(shí)時(shí)分析。

ByteLake 又是怎么做到這些能力的呢？接下來(lái)從以下幾個(gè)特性來(lái)展開(kāi)闡述。

如何實(shí)現(xiàn)高效數(shù)據(jù)更新？

第一個(gè)場(chǎng)景是流式寫(xiě)入更新場(chǎng)景。在這種場(chǎng)景下，最明顯的特點(diǎn)就是小批量數(shù)據(jù)頻繁寫(xiě)入更新。但主要的問(wèn)題是如何去定位要寫(xiě)入的記錄呢？是做 update 操作還是 insert 操作？

在這樣的背景下，ByteLake 提供了一種 Bucket Index 的索引實(shí)現(xiàn)方案。

這是基于哈希的一種索引實(shí)現(xiàn)方案。它可以快速地去定位一條記錄所對(duì)應(yīng)的 Fail Group，從而快速定位當(dāng)前記錄是否已經(jīng)存在，來(lái)判斷這一條記錄是做 Update 還是做 Insert 操作，從而可以快速地將這種小規(guī)模的數(shù)據(jù)去添加到 Append Log。在讀取時(shí)，通過(guò) Compaction 就可以將 LogFile 和 BaseFile 里邊的數(shù)據(jù)進(jìn)行 Merge 去重，從而達(dá)到數(shù)據(jù)更新的效果。

針對(duì)日志數(shù)據(jù)入湖，通常來(lái)說(shuō)是不需要主鍵的，這種基于 Hash 索引的實(shí)現(xiàn)方式，是需要有 Shuffle 操作的。因?yàn)樵诨?Hash 的索引實(shí)現(xiàn)中，當(dāng)一批數(shù)據(jù)過(guò)來(lái)之后，會(huì)根據(jù)這一批數(shù)據(jù)去找分別對(duì)應(yīng)的 File Group，再基于 File Group 去聚合要更新的這些數(shù)據(jù)，通過(guò)同一個(gè) Task，去更新同一個(gè) File Group 來(lái)實(shí)現(xiàn)原子寫(xiě)入。

在數(shù)據(jù) Shuffle 的過(guò)程，其實(shí)對(duì)于數(shù)據(jù)湖日志寫(xiě)入是有額外的開(kāi)銷的，但 ByteLake 提供了一種 Non index 的實(shí)現(xiàn)方案，去掉了索引的約束，可以減少數(shù)據(jù) Shuffle 的過(guò)程，從而達(dá)到快速入湖的能力。

存量數(shù)據(jù)如何高效更新?

存量數(shù)據(jù)，一大特點(diǎn)就是數(shù)據(jù)量大，單表的規(guī)模可能有幾百 TB ，甚至到 PB 的級(jí)別。針對(duì)于這種大規(guī)模的歷史數(shù)據(jù)的更新場(chǎng)景，如何去提升更新性能？其實(shí)最主要的就是要如何去降低數(shù)據(jù)更新的規(guī)模。

基于此，ByteLake 提出了一種實(shí)現(xiàn)方案——Column Family，將單表多列的場(chǎng)景分別存儲(chǔ)到不同列簇。不同的文件可以基于 Row Number 進(jìn)行聚合，合并后就是一個(gè)完整的行。如果要更新歷史數(shù)據(jù)，只需要去找到要更新的那些列對(duì)應(yīng)的 Column Family 對(duì)應(yīng)的文件，把這些文件做一些局部更新，就可以達(dá)到整體更新的效果。從而在很大程度上減少這些非必要數(shù)據(jù)的掃描，提升存量歷史數(shù)據(jù)更新場(chǎng)景的性能。

如何提升并發(fā)性能？

談到并發(fā)，通常會(huì)有兩部分內(nèi)容。比如有很多個(gè)任務(wù)同時(shí)去往 ByteLake 引擎里邊寫(xiě)數(shù)據(jù)，這就意味著有大批量的任務(wù)去訪問(wèn) ByteLake 的 MetaStore Service。在這種場(chǎng)景下，ByteLake MetaStore Service 就會(huì)成為一個(gè)性能瓶頸。

為了突破這個(gè)瓶頸，除了無(wú)限的堆加資源之外，另一個(gè)比較有效的方案就是增加緩存。通過(guò)元數(shù)據(jù)服務(wù)端去緩存比較熱點(diǎn)的數(shù)據(jù)，比如 Commit Metadata 和 Table Metadata，來(lái)達(dá)到服務(wù)端的性能提升。

另外一塊，是在引擎?zhèn)茸鰞?yōu)化。比如在 Flink 引擎層面將 Timeline 的讀取優(yōu)化到 JobManager 端。同一個(gè)任務(wù)下，只要 JobManager 去訪問(wèn) Hive ByteLake MetaStore Service，緩存到 JobManager 的本地之后，所有的 TaskManager 只要去訪問(wèn) JobManager 本身緩存的 Timeline 信息就可以了。

從單個(gè)任務(wù)的視角來(lái)看，比如多個(gè)任務(wù)要同時(shí)去更新同一張表，這種情況下要保證數(shù)據(jù)的正確性，同時(shí)又能保證并發(fā)性能，應(yīng)該如何來(lái)做？ByteLake 提供的解決方案——基于樂(lè)觀鎖的一個(gè)并發(fā)控制。

針對(duì)多任務(wù)寫(xiě)同一個(gè)表的場(chǎng)景，ByteLake 可以支持多種并發(fā)策略的設(shè)置。業(yè)務(wù)可以根據(jù)對(duì)數(shù)據(jù)一致性的要求，以及對(duì)數(shù)據(jù)并發(fā)性能的要求，選擇靈活的并發(fā)策略，來(lái)達(dá)到它的數(shù)據(jù)并發(fā)寫(xiě)入的性能指標(biāo)。

LAS 數(shù)據(jù)湖服務(wù)化設(shè)計(jì)

這個(gè)版塊將向大家呈現(xiàn) ByteLake 服務(wù)化過(guò)程中的一些設(shè)計(jì)實(shí)踐。

CatalogService ：統(tǒng)一的元數(shù)據(jù)視圖

CatalogService 主要提供了與 HMS 的兼容接口，同時(shí)為所有的查詢引擎提供了統(tǒng)一的元數(shù)據(jù)視圖，解決了異構(gòu)數(shù)據(jù)源的元數(shù)據(jù)管理問(wèn)題。

CatalogService 整體分三層，第一層是 Catalog Federation，提供統(tǒng)一的視圖和跨地域的數(shù)據(jù)訪問(wèn)能力。以及提供了對(duì)源數(shù)據(jù)請(qǐng)求的路由能力，可以根據(jù)元數(shù)據(jù)請(qǐng)求的類型，支持通過(guò) Mapping 的方式，來(lái)路由不同的服務(wù)請(qǐng)求對(duì)應(yīng)的底層元數(shù)據(jù)服務(wù)實(shí)例。

第二層是 CatalogService 下層的具體元數(shù)據(jù)服務(wù)的實(shí)現(xiàn)，比如 Hive MetaStore Service 以及 ByteLake MetaStore Service 等。可能還有不同的元數(shù)據(jù)服務(wù)對(duì)接到 CatalogService，來(lái)統(tǒng)一向上層引擎提供這種元數(shù)據(jù)服務(wù)。

最后一層是 MetaStore 的存儲(chǔ)層，它通過(guò)插件式的方式來(lái)提供不同的存儲(chǔ)引擎，來(lái)滿足上層不同元數(shù)據(jù)服務(wù)實(shí)例的存儲(chǔ)要求。

BMS 詳解

湖倉(cāng)一體元數(shù)據(jù)管理服務(wù)

Bytelake MetaStore Service，簡(jiǎn)稱 BMS，它是一個(gè)湖倉(cāng)一體的元數(shù)據(jù)管理服務(wù)，整體的架構(gòu)分為以下幾個(gè)部分。首先第一個(gè)就是 Catalog，Catalog 是對(duì)單表的元數(shù)據(jù)訪問(wèn)的抽象。主要邏輯是通過(guò) MetaStore Client 來(lái)訪問(wèn) Meta Server，同時(shí)它會(huì)去緩存單表的 Schema 信息以及屬性等信息。

另外一部分就是 Meta Server，也就是 BMS 里邊最核心的部分。它主要是包含兩大部分服務(wù)層，第一是 Bytelake MetaStore 元數(shù)據(jù)服務(wù)模型，比如 Table Service，Timeline Service，Partition Service 和 Snapshot Service。存儲(chǔ)層提供了 MetaStore 所有元數(shù)據(jù)的存儲(chǔ)能力。最后一部分就是 Eventbus， Eventbus 主要目的是為了將元數(shù)據(jù)的 CUD 事件發(fā)送給監(jiān)聽(tīng)者，來(lái)達(dá)到元數(shù)據(jù)信息的分發(fā)和同步。

元數(shù)據(jù)寫(xiě)入流程

關(guān)于元數(shù)據(jù)寫(xiě)入流程，簡(jiǎn)單來(lái)講，當(dāng)有一個(gè) Client 去提交了 Instant 之后，Bytelake Catalog 會(huì)去訪問(wèn) Bytelake Meta Store 的接口，會(huì)將 Instance 改成 Completed，然后將請(qǐng)求發(fā)到 Bytelake 的 MetaStore，之后 Bytelake MetaStore Server 會(huì)做一個(gè)原子提交。

在此之后，Timeline Service 會(huì)把提交的狀態(tài)更新到數(shù)據(jù)庫(kù)里邊。接下來(lái)這些分區(qū)信息將再被提交給 Partition Service，同步到對(duì)應(yīng)的分區(qū)存儲(chǔ)表里去。最后一步，把這些所有的變更作為一個(gè)快照，同步到 Snapshot Service 里，它會(huì)把文件層面的變更存儲(chǔ)到數(shù)據(jù)庫(kù)里，做持久化存儲(chǔ)。

元數(shù)據(jù)讀取流程

對(duì)于源數(shù)據(jù)的讀取流程，舉個(gè)例子，有一個(gè)計(jì)算引擎它讀取了一個(gè) SQL，通過(guò) SQL 解析拿到一張表，這張表會(huì)通過(guò)Bytelake Catalog Service去請(qǐng)求Bytelake MetaStore，最終會(huì)路由到 Table Service 拿到這些表的信息。

拿到表的信息做 SQL Plan 優(yōu)化的時(shí)候，會(huì)做一些分區(qū)的下推或裁剪。這個(gè)時(shí)候會(huì)去請(qǐng)求到 Bytelake 的 Partition Service 做過(guò)濾，接著會(huì)根據(jù)分區(qū)信息去掃描文件，在此過(guò)程中會(huì)去請(qǐng)求 Timeline Service 獲取對(duì)應(yīng)的 Timeline 信息。接下來(lái)，基于 Timeline 的信息時(shí)間去 Snapshot Service 拿到對(duì)應(yīng)文件，再通過(guò) SQL 執(zhí)行器來(lái)實(shí)現(xiàn)數(shù)據(jù)文件的讀取。

元數(shù)據(jù)變更通知

元數(shù)據(jù)變更通知具體的實(shí)現(xiàn)流程主要依托于兩個(gè)部分。

一是 Eventbus，二是 listener。所有的元數(shù)據(jù)請(qǐng)求都會(huì)發(fā)送到 Eventbus，由 Eventbus 分發(fā)事件到所有已經(jīng)注冊(cè)的 Listener 上面。listener 再根據(jù)下游系統(tǒng)的需求，去訂閱 Eventbus 里邊的對(duì)應(yīng)事件類型進(jìn)行響應(yīng)，從而達(dá)到讓上下游的組件感知到元數(shù)據(jù)的變化，實(shí)現(xiàn)元數(shù)據(jù)的同步。

TMS 詳解：

統(tǒng)一表管理服務(wù)

LAS 的另外一個(gè)服務(wù)——TMS，全稱是 Table Management Service。它主要解決的問(wèn)題是異步任務(wù)的托管優(yōu)化。為什么會(huì)做異步任務(wù)的托管優(yōu)化？因?yàn)檎?lái)講，F(xiàn)linker SQL 任務(wù)寫(xiě) ByteLake 表的過(guò)程，其實(shí)就是把批量的數(shù)據(jù)寫(xiě)入下游表里邊去。隨著時(shí)間的推移，一個(gè)是 Commit 的日志非常多，另外一個(gè)是小文件非常多。通常的 Flink 引擎層面的實(shí)現(xiàn)方案，是在數(shù)據(jù)寫(xiě)了一定的次數(shù)后，追加一個(gè) Compaction 操作，把之前寫(xiě)入的文件做一個(gè)壓縮。

但針對(duì)流式任務(wù)去做 Compaction，對(duì)正常的流式任務(wù)穩(wěn)定性有很大影響，因?yàn)閴嚎s本身是一個(gè)開(kāi)銷比較大的動(dòng)作，對(duì)流式計(jì)算資源的消耗是很難去評(píng)估的，會(huì)導(dǎo)致整個(gè)流式寫(xiě)入任務(wù)的波動(dòng)，從而影響流式寫(xiě)入任務(wù)的穩(wěn)定性。

基于此，LAS 提供了一個(gè)統(tǒng)一的表管理服務(wù)，異步托管這些本身內(nèi)置到引擎內(nèi)部的任務(wù)，統(tǒng)一由 Table Management Service 來(lái)托管。它整體的架構(gòu)是一個(gè)主從架構(gòu)，主要包含的組件一個(gè)是 Event Receiver，用來(lái)接收 Metastore 下發(fā)的一個(gè) Event。PlanGenerator 就是根據(jù) Meta store Server 下發(fā)的 Event 信息，來(lái)觸發(fā) Action Plan 的生成。

什么是 Action Plan？簡(jiǎn)單講，就是這一次要做哪些事情，比如你要做一個(gè)壓縮任務(wù)，還是做一次歷史文件的清理，還是做一些小文件的合并，都稱為 Action Plan。Job Scheduler 就是去調(diào)度需要被執(zhí)行的 Acting Plan。

什么是 Job Manager？它主要用于和集群交互，比如 Yarn 或 K8S，管理 Action Plan 對(duì)應(yīng)的執(zhí)行任務(wù)，做一些任務(wù)運(yùn)維層面的工作。

執(zhí)行計(jì)劃生成

就執(zhí)行計(jì)劃生成展開(kāi)來(lái)講，Plan Generator 會(huì)接收 Metastore 下發(fā)的一些事件，根據(jù)用戶在表的 DDL 里的配置策略，來(lái)決定是否要生成執(zhí)行計(jì)劃。

這個(gè)策略通常會(huì)有幾種，比如，一種基于它 Delta Commit 的數(shù)量，連續(xù)提交了多次達(dá)到了一定的閾值，就會(huì)觸發(fā)一個(gè) Action Plan 的生成，來(lái)做一次數(shù)據(jù)的壓縮。另外一種，是根據(jù) Log File 的大小，來(lái)判斷 Compaction 操作是否需要執(zhí)行。PlanGenerator 策略會(huì)根據(jù)當(dāng)前 Log File 的 Meta 信息，來(lái)決定是否要觸發(fā) Action Plan 的生成。

執(zhí)行計(jì)劃調(diào)度管理

執(zhí)行計(jì)劃生成結(jié)束之后，最后一步就是怎么去調(diào)度管理執(zhí)行計(jì)劃。執(zhí)行計(jì)劃調(diào)度的核心流程主要由 Job Scheduler 來(lái)做，Job Scheduler 會(huì)定時(shí)地去輪詢已經(jīng)生成的 Action Plan，再分發(fā)給 Job Manager。Job Manager 拿到了 Action Plan 之后，會(huì)到集群上提交一個(gè)任務(wù)，同時(shí)不斷去輪詢?nèi)蝿?wù)的狀態(tài)，更新任務(wù)的狀態(tài)到數(shù)據(jù)庫(kù)，保證 Action Plan 執(zhí)行的可靠性和穩(wěn)定性。通常 JobScheduler 一般會(huì)有先進(jìn)先出的調(diào)度策略，來(lái)保證 Action Plan 達(dá)到預(yù)期調(diào)度效果。

LAS 在字節(jié)跳動(dòng)的業(yè)務(wù)實(shí)踐?

抖音電商在湖倉(cāng)一體架構(gòu)下的業(yè)務(wù)實(shí)踐

抖音電商的業(yè)務(wù)場(chǎng)景，主要是營(yíng)銷大促、流量診斷以及物流狀態(tài)的監(jiān)控。他們的業(yè)務(wù)痛點(diǎn)是什么？數(shù)據(jù)量大，計(jì)算邏輯復(fù)雜，同質(zhì)數(shù)據(jù)源也比較多，寬表的構(gòu)建成本比較高，包括一些其他的技術(shù)問(wèn)題。還有一個(gè)痛點(diǎn)就是計(jì)算周期長(zhǎng)，增量計(jì)算成本比較高。

基于 LAS 湖倉(cāng)一體架構(gòu)下，可以解決哪些問(wèn)題呢？

首先，通過(guò) LAS 快數(shù)據(jù)入湖能力，可以解決多數(shù)據(jù)源的快速入湖。把外部的業(yè)務(wù)系統(tǒng)和業(yè)務(wù)日志，通過(guò) LAS 這種實(shí)時(shí)入湖能力快速導(dǎo)入到 ODS 層。通過(guò)離線數(shù)倉(cāng)可以直接引用 ODS 層的準(zhǔn)實(shí)時(shí)入庫(kù)數(shù)據(jù)，來(lái)達(dá)到離線數(shù)倉(cāng)的日增量數(shù)據(jù)，同步提升數(shù)據(jù)的時(shí)效性。

其次，實(shí)時(shí)數(shù)倉(cāng)中 DW 層的一些明細(xì)數(shù)據(jù)，也可以通過(guò)流式入湖的能力，直接導(dǎo)入到 ByteLake，達(dá)到數(shù)據(jù)復(fù)用的目的。當(dāng)把這些數(shù)據(jù)導(dǎo)到了 ByteLake 之后，針對(duì)大寬表場(chǎng)景，就可以基于 ByteLake 的多流拼接能力，直接在底層的存儲(chǔ)引擎層，實(shí)現(xiàn)寬表的構(gòu)建。從而解決在常規(guī)場(chǎng)景下，通過(guò) Flink SQL 做多源或多流 join，導(dǎo)致的任務(wù)狀態(tài)比較大，或者任務(wù)處理復(fù)雜度比較高的這種穩(wěn)定性問(wèn)題，從而更好地去保障業(yè)務(wù)數(shù)據(jù)的及時(shí)性和穩(wěn)定性。

消費(fèi)行業(yè)傳統(tǒng)數(shù)倉(cāng)架構(gòu)升級(jí)

消費(fèi)行業(yè)的客戶場(chǎng)景，實(shí)際就是在零售場(chǎng)景下的財(cái)務(wù)管理、庫(kù)存管理相關(guān)的一些計(jì)算場(chǎng)景。客戶的實(shí)現(xiàn)方案基于傳統(tǒng)的數(shù)據(jù)庫(kù)，業(yè)務(wù)和離線分析的請(qǐng)求都是統(tǒng)一在一個(gè)傳統(tǒng)數(shù)據(jù)庫(kù)上邊來(lái)做的。

在這種場(chǎng)景下，其實(shí)整個(gè) RDBMS 要同時(shí)承接業(yè)務(wù)處理邏輯和離線 ETL 分析邏輯。隨著業(yè)務(wù)數(shù)據(jù)量的增長(zhǎng)，很快就會(huì)發(fā)現(xiàn)傳統(tǒng)數(shù)據(jù)庫(kù)的計(jì)算能力和存儲(chǔ)支撐能力達(dá)到了上限，導(dǎo)致計(jì)算能力不足，擴(kuò)展性比較差，無(wú)法在滿足后續(xù)的業(yè)務(wù)數(shù)據(jù)規(guī)模的上量。

LAS 針對(duì)這種場(chǎng)景的解決方案，是將客戶的離線 ETL 的分析場(chǎng)景，通過(guò)實(shí)時(shí)集成的方式直接導(dǎo)入到 LAS 里邊，通過(guò) LAS 的彈性計(jì)算能力，為用戶的 ETL 分析場(chǎng)景提供有效的算力保障。在滿足客戶低成本約束的情況下，達(dá)到客戶預(yù)期的計(jì)算效果，和對(duì)數(shù)據(jù)產(chǎn)出的及時(shí)性的要求。同時(shí)會(huì)通過(guò)云上的 ByteHouse 服務(wù)來(lái)解決客戶自建的 CK 的運(yùn)維成本以及性能調(diào)優(yōu)的問(wèn)題。優(yōu)化了原有的基于 RDBMS 的數(shù)據(jù)鏈路，保證業(yè)務(wù)數(shù)據(jù)量快速增長(zhǎng)的同時(shí)，滿足它的底層的算力要求。

湖倉(cāng)一體架構(gòu)下的批流融合計(jì)算

典型場(chǎng)景就是數(shù)據(jù)實(shí)時(shí)入湖，客戶的數(shù)據(jù)源會(huì)通過(guò) Flink SQL 持續(xù)地去寫(xiě)入到 LAS 的 Bytelake 表里。但下游如果是一個(gè)離線任務(wù)，其實(shí)用戶沒(méi)辦法很便利地去判斷數(shù)據(jù)寫(xiě)到了哪個(gè)位置，或者分區(qū)數(shù)據(jù)現(xiàn)在是不是已經(jīng)完備的。

如果僅依賴系統(tǒng)時(shí)間來(lái)實(shí)現(xiàn)，比如在上游的這種 Flink SQL 任務(wù)，在寫(xiě)入過(guò)程正常時(shí)倒沒(méi)有特別大的問(wèn)題。但是一旦上游 Flink SQL 任務(wù)出現(xiàn)一些數(shù)據(jù)積壓或者任務(wù)異常的場(chǎng)景，下游依賴系統(tǒng)時(shí)間去調(diào)度，就會(huì)存在某些分區(qū)會(huì)出現(xiàn)數(shù)據(jù)空洞或數(shù)據(jù)偏移的問(wèn)題。例如本來(lái)數(shù)據(jù)應(yīng)該落在 7 點(diǎn)的分區(qū)，因?yàn)樯嫌蔚倪@些 SQL  任務(wù)的消費(fèi)延遲，導(dǎo)致 7 點(diǎn)的數(shù)據(jù)并沒(méi)有準(zhǔn)時(shí)地落下來(lái), 導(dǎo)致下游去消費(fèi) 7 點(diǎn)的數(shù)據(jù)的時(shí)候，拿到的是一個(gè)不完整的數(shù)據(jù)，導(dǎo)致出現(xiàn)數(shù)據(jù)空洞或數(shù)據(jù)偏移的問(wèn)題。

針對(duì)這種場(chǎng)景，LAS 提供了一種叫歸檔的能力，也就是在 Flink SQL 寫(xiě)入的過(guò)程中，會(huì)基于業(yè)務(wù)事件時(shí)間實(shí)時(shí)寫(xiě)入對(duì)應(yīng)的數(shù)據(jù)分區(qū)。通過(guò) ByteLake 提供歸檔能力，分區(qū)數(shù)據(jù)就緒后，可自動(dòng)生成一個(gè)歸檔標(biāo)簽。下游的 spark SQL 任務(wù)可以根據(jù)分區(qū)是否有歸檔標(biāo)簽，來(lái)判斷對(duì)應(yīng)分區(qū)的數(shù)據(jù)是否就緒，來(lái)決定當(dāng)前離線任務(wù)是不是要調(diào)度起來(lái)。

這項(xiàng)能力的實(shí)現(xiàn)邏輯，其實(shí)就是 Flink SQL 每次去提交一個(gè) Commit 的時(shí)候，會(huì)去判斷當(dāng)前提交的業(yè)務(wù)的事件時(shí)間，是否比當(dāng)前的未提交分區(qū)的時(shí)間超過(guò)了某一個(gè)閾值。比如當(dāng)前分區(qū)的時(shí)間是 7 點(diǎn)，F(xiàn)link SQL 在持續(xù)提交微批數(shù)據(jù)的時(shí)候，它判斷出來(lái)當(dāng)前的最小的業(yè)務(wù)時(shí)間已經(jīng)到 7 點(diǎn)半了，而業(yè)務(wù)定義的可容忍的延遲間隔是 15 分鐘， ByteLake 認(rèn)為這個(gè)數(shù)據(jù)其實(shí)已經(jīng)寫(xiě)完了，就會(huì)把 7 點(diǎn)的分區(qū)數(shù)據(jù)打上一個(gè)歸檔標(biāo)簽，來(lái)標(biāo)示數(shù)據(jù)已經(jīng)完成了。下游就可以去正常地去消費(fèi) 7 點(diǎn)的分區(qū)數(shù)據(jù)，從而保證數(shù)據(jù)的完整性。

在提供了這種歸檔能力的情況下，LAS 的整體計(jì)算鏈路就可以實(shí)現(xiàn)批流融合。比如 ODS 的 ByteLake 表是一個(gè)準(zhǔn)實(shí)時(shí)的表，下層的 Spark SQL 任務(wù)可以直接通過(guò) Spark ETL 去做處理，產(chǎn)出一個(gè)離線表。可能后邊還會(huì)有一些 SQL 場(chǎng)景依賴離線表做數(shù)據(jù)的準(zhǔn)實(shí)時(shí)消費(fèi)。在這種情況下，F(xiàn)link SQL 會(huì)再生成一張 ByteLake 表，這張表同樣可以被下游的 Spark SQL 的離線任務(wù)依賴，從而達(dá)到在整個(gè) Pipeline 里，做到批流計(jì)算相互融合的狀態(tài)。