導讀
Atlas 是一家富有創新精神的新加坡旅遊科技初創公司，由連續創業企業家 Mary 及其團隊於 2019 年底成立。公司利用互聯網技術高效聚合和分發全球廉價航空公司的特價機票，服務於全球旅遊業生態系。技術部門需要與包括航空公司、線上旅行社（OTA）、機票代理、技術和預訂公司、支付公司等參與者進行數據交換，以提供卓越的客戶服務。近期Atlas進行了數據平台升級，在原來的數據架構基礎上引入新一代湖倉一體SaaS數據平台。
引入雲器數據平台 Lakehouse 後，在銷售轉化漏鬥營運分析等場景能夠給營運人員提供即時新鮮度的數據，以及低延遲高並行的穩定的查詢服務；在使用雲器Lakehouse之後，最佳化了原來采購了固定資源規格的儲存服務的限制，從存放7天的數據最佳化成無限擴充套件可以低成本存放 365 天的數據，能支撐業務方的歷史數據的查詢需求的範圍也變得更加寬泛，極大擴充套件數據價值挖掘的範圍，支撐起更長客戶的生命周期管理。
Atlas 作為一家提供高品質最優惠飛行路線方案出行服務的公司，其業務範圍涉及 「線上票務預訂服務、最優惠路線規劃、輔營服務升級推薦」 等方面。作為整個產業鏈上的數據中心樞紐，Atlas 采集匯聚了航空公司、OTA 平台等多方數據，對公司上下遊、內外部提供數據分析及交換共享服務。
在公司創立之初，本著 「用數據支持科學決策」 的理念，公司迅速成立了數據平台小組，敏捷搭建了第一代數據平台，快速支撐公司業務上線，為上下遊決策鏈提供重要的數據支撐。數據平台小組面對的持續挑戰有三點：
數據規模持續擴大
伴隨著公司業務的蓬勃發展，數據采集來源的範圍愈加廣闊：航司票務數據、購票平台訂單、使用者行為日誌，第三方平台數據等，使得數據整合規模慢慢擴大，數據增量最大峰值也不斷重新整理出新的高度，如使用者搜尋日誌數據已經達到 6~7 億+ /日。
業務需求多元發展
公司業務需求也在向豐富多元化拓展，航旅業務分析場景在向多維立體化的方向演進，分析指令碼的復雜度逐步提升。
時效性要求逐漸升高
另一方面，一部份決策業務對數據的及時有效性也提出了更高的要求，從原先按日更新和統計的頻率，逐步變為了每天多次更新，如：每若幹小時、每半小時，每 5 分鐘甚至更短的更新頻率。
挑戰具體的說，是數據平台必須應對從低頻數據更新轉向高頻，以及每日數據增量的持續擴大，這兩者共同導致了巨大的儲存開銷。為了首先解決數據及時性的重要且緊迫問題，數據平台組在原有的離線架構基礎上，基於Flink 快速搭建了即時數據加工鏈路。這一改進確實解決了數據及時性問題，並且暫時滿足了業務需求。然而，這也使得數據架構演進為離線和即時兩套鏈路共存的狀態，形成了典型的 Lambda 組裝架構。
圖1：Atlas原有數據平台架構
客觀地評估目前的架構，我們認為它能支持已知的需求，但也有確定的瓶頸和問題。舉例說明：即時和離線雙鏈路的割裂性隨著時間的推移，會逐漸產生內部不可調和的矛盾：
統計口徑難以被統一 ： 即時鏈路與離線鏈路由於有兩條處理鏈路，對於相同統計指標的計算結果，不可避免會有數據結果不一致的情況發生。此類問題花費了業務人員和數據技術團隊非常多的資源和時間，包括排查、配合、溝通、確認根因，影響效率。
「難以收斂」的數據治理需求： 數據規模的擴大與數據治理的復雜性成正比，多條數據鏈路和不一致的數據口徑讓數據治理工作難以收斂。原本計劃用於支撐業務擴張的技術資源被釘選在數據治理的工作中，較難做出有效改善，兩方面同時作用成為了一個惡性迴圈。
開發復雜性問題： 兩個鏈路間進行切換偵錯上線。由於離線和即時是兩種不同的技術，有著不同的開發語言和開發工具，因此這個過程總是需要離線和即時兩邊的人員做技術對接，同時還有可能牽扯到業務理解不同，拉上業務方一起重新理解需求，進一步損耗企業內部資源。
維護復雜性問題： 由多套元件所組成的 Lambda 架構，每個元件都需要一定的運維手段來進行維護。儲存與計算的擴縮容、日誌的清理、任務的運維監控等，均由多種不同的工具所承載。例如出現數據執行故障，排查問題需要跨越一個個系統尋找可能的原因。平台維護復雜性高、維護頻率高、工作負載大，也同樣是令人頭疼的事情。
圖2：Atlas原數據架構
數據平台計畫組評估認為，系統的復雜度引起的一系列問題，長期來看不能透過擴張人力解決，切換到一個更簡化的架構方案定為下一階段的主要任務。並且現實的壓力也很快就出現了，有兩點外部因素的改變推動升級任務要盡快完成。
一、隨業務發展，數據量在加速膨脹。公司數據平台在 Lambda 架構下平穩運轉，業務發展進一步提速，數據量加速地膨脹。大約半年的蜜月期過後，使用者搜尋日誌數據已經突破 8 億+ /日，航空公司票務采集數據突破 7 億+ /日，數據平台開始暴露了第一個業務阻塞性問題：在 BI 分析即時查詢的場景下，由於過大的數據量，使得某些聚合分析無法穩定計算，統計數據介面頻繁超時，這對業務側產生了一些不小的負面影響，使得公司內部營運和外部服務的品質均受到了挑戰。
二、AI 的出現帶來了新的創新機會時間視窗。而此時，卻又正值 AI 技術風口到來之際，Atlas 正欲向著結合 AI 新技術領域探索與產品力的提升的大方向上進發，公司的業務發展節奏絕對不能受此影響而陷入停滯。公司高層幾番討論過後，把目光的焦點放在了對數據平台架構升級這件事情上。主要考慮以下幾個核心目標：
首要的任務便是 解決燃眉之急的介面呼叫超時問題。 現有平台上 Clickhouse 在面向 BI 分析查詢的場景下，所提供的查詢服務響應時間出現了明顯波動，超過 1 分鐘便會導致服務超時。其本質原因是 CK 在多表關聯查詢場景下的效能並不十分理想。這個問題處理不好會直接影響每日下遊的票務搜尋查詢分析服務，進而影響 B 端客戶的體驗。這一條是最嚴重的一條，需要最優先被解決。
其次是 從整體平台架構上來看，企業數據資產存在著割裂性：
當前的平台架構包含了即時、離線、線上分析查詢等多種數據處理引擎，使得同一份 Raw Data 在不同的加工鏈路中流轉，在不同的計算引擎中冗余儲存。此外，數據品質、數據完整性標準不一，使得企業的數據治理難度上升了一個梯度，連同下遊的業務分析指標存在不一致。這一條間接影響了已有業務上的決策活動；
而且資料倉儲各元件之間開放性不足，如果單獨構建數據湖以滿足開放性，又與資料倉儲之間存在著重復建設，會進一步加劇企業數據資產 「湖」 與 「倉」 之間的割裂性。資料倉儲內的結構化數據，與數據湖中的半結構化、非結構化數據，無法做到安全的共享或是許可權的統一管理。因此也難以承接公司未來面向 AI 方向上的需求。這一條間接影響了未來公司業務的發展節奏。
在運維方向上，公司平台組管理層提出： 原有數據平台需要自運維、自組合、自拼裝， 這也是耗費較大的人力成本的重要因素之一，同時也是業務方領導認為技術同學總把關註點和精力放在平台技術和運維上，難以聚焦業務價值提升本身的一個關鍵因素。這一條可以間接解放技術側資源，釋放到業務價值上。
圖3：Atlas原數據架構割裂問題
從更長期發展的角度考慮，作為一家出海數據型服務公司，Atlas 對數據的智慧化以及數據價值發現和挖掘等方面有超出一般初創公司的要求。尤其在 2023 年大模型技術出現後，隨著線上購票客戶對產品使用者體驗的要求一再升級，單程、轉機、往返票價的即時精準預測需求應運而生，公司對數據的即時性、智慧化也有著更強的訴求。這些都需要新的數據平台能夠很好地 支撐 AI 演算法相關業務 的開展。對此，公司提出 3 個關鍵性要素：
開放性 ：數據平台不再是單一的資料倉儲，要有數據湖的開放內容。即能夠對統一數據湖中的數據進行多種類別的工作負載，包括 AI 計算。Atlas 自身采集的數據也逐漸向圖片、文本、日誌等半結構化/非結構化數據擴充套件，數據入湖後可以從大模型 prompt 到一些私有模型訓練，以滿足預測多種路線方案的數據套用需求。對於當前已經使用其他的演算法框架如：Spark，TensorFlow 等，需要平台有後設資料和底層數據檔開放的支撐能力，這樣就同時需要新的平台具備外插計算引擎的能力。
可延伸性 ：數據平台需要在儲存上做到靈活可延伸，滿足持續增長的數據體量。在計算上需要支持按峰谷時段進行彈性伸縮，在伸展階段計算效能盡量做到保持線性增長。
統一性 ：數據平台能夠資料倉儲和數據湖做統一的數據許可權管理，使用統一的後設資料系統對資料倉儲和數據湖做統一的抽象。因此需要一個具備湖倉一體數據管理能力的計算平台。
需求的梳理
綜上所述，Atlas 的對於企業數據平台架構升級的直接痛點與潛在因素整理如下。
直接痛點：
BI 側查詢響應存在抖動，查詢效能不穩定： 企業數據規模的增長導致 Clickhouse 在多維度聚合統計查詢上的響應時間達到 60 秒以上，無法滿足 BI 側 SuperSet 的查詢時長限制。根據實際測試數據，查詢響應時間呈現線性增長，影響了 BI 側使用者體驗，可能延誤決策過程。透過最佳化 Clickhouse 查詢引擎和索引機制，可減少查詢響應時間，提高查詢效率，避免查詢超時。
Atlas 期望進一步降低成本消耗，提高生產效率： 企業希望透過進一步降低數據平台成本，提高整體營運效率。成本問題包括硬體和軟體采購成本、維護、升級和人力資源。目前數據平台的營運成本占據企業整體成本的一部份，而隨著業務規模的增長，這一比例可能進一步上升。透過引入更高效的數據儲存和處理技術，最佳化數據平台的架構，可以降低硬體和軟體成本，提高整體成本效益。
潛在因素：
企業的數據資產割裂： 即時鏈路和離線鏈路之間的割裂導致數據儲存上的冗余，增加了數據同步和管理的復雜性，嚴重時還會導致數據的不一致性。期望透過整合即時和離線數據處理流程，構建統一的數據儲存結構，解決數據冗余和不一致性的問題，提高數據平台的整體穩定性和可維護性。
業務向更即時方向發展的挑戰： 隨著公司的發展狀態，部份線上產品服務與部份業務分析決策均希望向更即時化的方向演進，以提升產品服務力和 B 端使用者體驗。然而，這需要在保證即時性的同時，兼顧成本問題。在行業競爭加劇的當下環境，使用者側對即時數據的需求逐漸增加，業務需要更加靈活和快速地響應市場變化。期望能在盡量滿足業務對即時性的需求的同時，還能盡可能地控制成本。
資料倉儲與數據湖的割裂： 隨著未來可能涉足 AI 方向的嘗試，當前資料倉儲與數據湖之間存在割裂，會阻礙了企業在人工智慧領域的發展。資料倉儲和數據湖分別在數據儲存和管理上有各自的特點，如果整合得不當可能會導致數據在 AI 套用中的使用效率。期望透過構建數據湖與資料倉儲的無縫連線，實作數據的互通互聯，可以為未來的 AI 嘗試提供更為完善的數據基礎，促進企業在人工智慧領域的創新和發展。
運維復雜性：
原有平台的運維工作量隨架構的復混成與數據的膨脹，以及元件缺乏擴充套件性等因素，消耗了較大的人力資源。因此期望選用一個全托管的數據平台提升效能，減少運維成本，免除手動擴縮容、刪查日誌等問題，讓運維開發人員聚焦數倉建設及專註業務創新是我們的重點最佳化目標。
方案的選擇和驗證
確認了以上幾點作為目標和要解決的問題後，公司平台技術團隊與業務團隊達成一致的目標，即升級數據平台。技術團隊認真做了平台架構的選型和對比，設計完整的方案。在經歷了幾番嘗試和驗證後，最終嘗試到了雲器的 Lakehouse 湖倉一體化平台，並且在驗證的基礎上也做了和 Spark 及 MPP 架構一些產品的對比，如下：
圖4：產品對比
雲器的解決方案團隊首先針對 Atlas 的現有架構進行數據整合方案的設計。由於票務數據與搜尋日誌的上遊鏈路的資料來源都統一匯總到 Kafka，因此開發一個程式從 Kafka 讀取數據並每分鐘落盤到 OSS 上 1 個檔，再使用雲器 Studio OSS 數據同步 功能將數據寫入 Lakehouse，在這個操作過程中 ODS 層保留原始 Json 數據，在 DWD 層完成 Json 檔格式的轉化和後續的匯聚。此方案滿足了即時場景從源頭 kafka 到最終數據平台消費端，數據新鮮度在 10 分鐘內的需求，並逐步向 5 分鐘逼近，最重要的是成本遠小於一個行程常駐的即時處理任務；互動式分析場景 8 億條數據多維聚合與關聯查詢效能能夠滿足套用側需求。且由於數據傳輸在 OSS 內部，避開 「公網」 網路傳輸，因此也降低了整體的儲存和網路傳輸成本。
圖5：基於雲器Lakehouse的數據整合鏈路
在 Atlas 的數據體系中，原始數據的采集和儲存傳輸均是使用 Json 格式進行的，透過雲器 Lakehouse 的 from_json 函式進行一次性欄位展平。按照生產實際情況，數據以 Json 格式 Kafka 寫入 OSS，5 分鐘間隔從 OSS 離線同步到 Lakehouse，數據落盤後及透過 SQL Volume Load 直接完成 Json 數據的拆表及欄位打平。完成數據解析後鏈路 SQL 關聯、聚合、去重等加工計算，到數據套用側的 Ad Hoc、BI 查詢、API 呼叫延遲滿足 10 分鐘 ~ 5 分鐘的要求。
圖6：基於雲器Lakehouse的數據儲存
在計算引擎的查詢效能方面，我們選定一個典型場景對引擎進行了驗證測試，測試數據從 OSS 進行載入到雲器 Lakehouse 後，在 通用型虛擬計算集群（General Purpose Virtual Cluster） 中進行預處理，然後生產結果表在雲器 分析型虛擬計算集群（Analytical Purpose Virtual Cluster） 中直接供業務系統進行查詢。以下是一些效能驗證情況。首先我們驗證的是超過 7 億條數據的查詢情況，在與原有平台相同或更低的資源規格下，引擎可以在 10 秒內返回數據。對此，平台組進行了多種型別的多輪查詢驗證，在未進行過效能調優的基礎上，基本上能按照線性的擴充套件要求，透過擴大計算資源規格，能夠相應地按比例減少計算消耗的時間，因此獲得了令技術團隊和業務團隊都十分滿意的效能指標。
圖7：雲器Lakehouse查詢效能驗證效果
接著繼續進行數據層面的最佳化，最終 7 億條數據 5 個 key 的開窗用時大約 3 分鐘，比調研過的同類即時數倉產品 2 億條的 case 還快了一少半。令人滿意的是，在整個查詢計算的過程中，雲器做到了資源的按量收費，和計算資源的自動彈性伸縮。對此，平台組還專門對虛擬計算集群進行了專項的驗證，從結果上來看，計算資源基本上都是毫秒級拉起，分鐘內銷毀。確保了計算成本盡量的最小化。
同時，從數據湖與數據滄湖後設資料統一管理的層面，雲器 Lakehouse 既能儲存和管理以結構化的數據，又能儲存管理半/非結構化的數據。這樣就使得數據平台升級成了湖倉一體的架構。在這個方面，公司演算法團隊也協助進行了一些驗證。透過雲器的 Python SDK 與 Catalog SDK，存取到了底層同一份的原始數據檔，經過簡單的程式處理，最終與數倉中 SQL 處理結果相一致。滿足了公司統一數據管理，簡化平台架構，簡化數據治理的訴求。
數據平台的遷移和實施
公司經過平台產品方案的選定，迅速啟動相關的數據遷移工作，整個遷移工作在雲器交付團隊的幫助下，用時大約半個月時間，可以說效率比較不錯。
圖8：遷移時間軸
遷移工作中一些主要的關鍵點，這裏做了一些梳理，首先雲器作為一個全托管的數據平台，全程為客戶提供技術兜底，效果兜底。雲器的團隊和 Atlas 的團隊一起完成了平滑的湖倉對接和遷移驗證，還透過自身的專業能力和經驗，沈澱了一套完整的搬站遷移 SOP 標準流程和搬站工具，涵蓋了 schema 轉換遷移、任務遷移、數據遷移、數據正確性校驗等多個方面。在這個過程中，也解決了一些問題，比如：
存量任務遷移：數據遷移往往比較簡單，有很多自研工具或者生態工具可以使用，任務遷移往往挑戰比較多，雲器LH語法層面相容 Spark3 SQL 語法標準並在其上做了很多擴充套件，其他的如果是 RDD 開發 / Java 開發 / 其他方言 SQL，會涉及到語法轉換問題，存在一定工作量，這部份使用了工具進行轉化。
遷移實施過程中需要對正確性 / 效能等指標的驗收確認等工作，這部份使用工具化進行的，在這個過程中專門研發搬站遷移工具，目前已經比較成熟能夠從開源大數據平台和商業化大數據平台進行數據遷移和搬站工作，包括流量並行評估，後設資料 Schema 讀取、任務遷移、數據遷移、數據比對等功能，已經相對比較成熟。
作為數據開發和運維工程師，是否有一套完整的工作台是非常關註的指標，在雲器提供產品手冊，包括基本語法，功能介紹，最佳實踐等的基礎上，我們深度使用了雲器的一站式平台產品 Studio 進行數據的整合、開發、治理和排程，能大幅提高數據遷移和數倉建設的效率。
圖9：雲器產品能力介紹
在整個遷移過程中，系統特性方面進行梳理和總結，重點解決了以下幾個方面的問題作為重點關註點：
重建數倉體系： 從數據匯聚治理開始定義數據業務目標，數據品質治理和采集最佳化，做整體數倉設計，並協助完成實施。
整合即時數據流和離線數據流一體化： 實作了即時離線架構統一建設和效能提速，提高數據服務的時效性，使原有的數據報表服務從T+1 升級到分鐘級。
SaaS 服務： 新平台采用按使用量計費的模式計算、儲存、網路等資源的實際使用量進行計算降本 50%，運維及使用成本降低 70% 以上。
高並行低延遲的計算集群架構： 支持數據產品團隊 SaaS 自訂報表能力，擴充套件客戶業務數據分析和洞察維度，實作每個客戶獨特的客製化報表。
升級後的效果和業務價值
效能達到質變效果：在原先的架構中，對於 7~8 億條搜尋數據的關聯分組聚合查詢，常常無法及時返回結果。在使用雲器 Lakehouse 後，查詢時間僅需約 10 秒，為業務營運分析提供了穩定且高效的查詢服務。
「無限」 儲存：之前，Atlas 采購了固定資源規格的儲存服務，僅能存放約近 7 天的數據量。而切換到雲器 Lakehouse 後，不僅儲存單價成本更低，還支持理論上的 「無限」 擴充套件。現在，我們可以存放近一年的數據，滿足了業務側對歷史數據查詢需求的更廣泛範圍。
全托管、免運維：過去，數據平台維護人員需要人工清理磁盤、刪除日誌、擴容伺服器，排查計算引擎的偶發問題。而現在，這些任務均由雲器 Lakehouse 產品及其 SRE 團隊負責。Atlas 解放了技術人力資源，省時省力，讓平台維護工作變得更加輕松。
減少 「內耗」 成本：對比原來的數據架構，儲存和計算的成本均得到有效控制，開發語言的統一也使得即時和離線任務的轉化不再需要 「兩三撥人」 參與，湖上建倉參照同一份數據，數據治理問題也迎刃而解。並且在數據架構最佳化的基礎上，進一步壓縮最佳化了運維成本。使用 SaaS 數據平台產品後，引擎能力的提升以及 SaaS 按量付費，所帶來的直接成本降低達 50% 以上，由於平台運維方向的最佳化，僅不到一個人就可以在雲器產品化基礎上做到了高效生產運維和安全生產。
業務擴充套件：以前業務人員的取數需求，分析查詢慢，甚至跑不出來。現在可以快速產出結果，由於具備線性擴充套件性，既不需要擔心未來數據量更大時會重蹈覆轍，也可以透過增大計算集群規格來縮短查詢時間。
穩定性提升：原平台需要平台組成員自行拼裝搭建，在遇到一些技術瓶頸時往往透過尋找社群相關問題或提問，得不到有效的保障。使用雲器 Lakehouse 後，其產品從設計模式上就重視考慮雲原生分布式架構，然後根據多年生產運維經驗元件專家服務值班團隊，常態化 7x24 保障集群穩定與安全。同時對於新功能的釋出，也設計了一套灰度釋出上線的機制，對於一些我們嘗鮮的新功能，會做隔離性保護。目前已經支撐 Atlas 在十一國慶和春節期間的報表數據加工和業務查詢洪峰，從效果來看，目前對於 SLA 的保障是比較有信心的。
展望和期待
同樣作為創業公司，雲器科技願意與我們一起探索人工智慧的場景建設，共同成長，相互支持，互為陪跑。在產品研發過程中，雲器科技采用了湖倉的底層架構，旨在解決這些問題。盡管當時大型語言模型並不像現在這樣熱門，但 Atlas 仍然選擇了這個方向，進行了開放式的設計。數據儲存在數倉中，但同時也是開放的，可以被其他引擎消費。而雲器在設計產品擴充套件性時，也很好地兼顧了這一點。在計算靈活性和可延伸性方面，Atlas 采用混合編程模式，例如 Python 和 SQL 的結合，以確保計算的開放性和管理性。這樣，我們的平台具備了擴充套件性，能夠應對未來更多的技術突破和叠代。
Atlas 還計劃同雲器科技一起探索更多有趣的場景。其中之一是使用 AI 和機器學習來準確預測航空公司的定價區間。結合雲器科技提供的面向 AI 的數據基礎設施具備的湖倉一體，AI workload 整合，統一的數據管理等基礎能力，基於航空公司提供的航班、機票和輔助服務資訊，進行 遠/近期 - 直達/轉機 - 單程/往返 多段航程的票價預測、行李托運 / 餐食服務預測、最優惠路線規劃等。
