2024年，袋鼠云接到了一個不小的挑戰。

一家貨幣交易所的技術負責人在通話里直接說：“我們現在業務都跑在 AWS（亞馬遜云平臺）?上了，你們的產品（數棧大數據平臺）能不能不改代碼直接跑在 AWS 上？最好別重學。能跑，還得跑得快。”

出海浪潮下，這樣的需求并不稀奇。真正能在 AWS 上 做到“穩定、高性能、權限閉環、體驗一體化”的大數據產品，至今仍是少數。這要求中國的技術公司開始走入一個新戰場——不能再是提供“給中國客戶用的技術”，而是需要適配全球主流云廠商的底層邏輯，用一種全球通用的方式去可靠交付。

所以袋鼠云在全面開啟出海戰略之后，下定決心不僅要讓數棧能跑在 AWS 上，還要在 AWS 上跑得好。

不是兼容AWS，而是重做一遍適配體系

對大多數國產數據平臺來說，“適配 AWS”的第一步就是找兼容層：看看 EMR 支不支持 Spark、Flink 能不能訪問 Hdfs，S3或者向Yarn提交任務，再配點訪問策略，就認為大功告成了。

但會很快發現，這種兼容，是一種“不確定性”的存在。

比如：S3 是最終一致性，任務寫完數據后，別的任務讀不到；Flink 的 checkpoint 寫 S3 時丟失元數據；Glue 的 Catalog 怎么都連不上 Hive 元數據；權限策略在多個服務之間不通……

客戶想要的是“業務跑得起來”，但工程師面對的，是“生態全斷裂”。

于是袋鼠云決定重新來過。不是兼容 AWS，而是跟它“合拍”：真正理解 AWS 的每一層能力——從存儲->調度->元數據，從AK&SK->IAM Roles認證——并逐層打通。

這不是插件級適配，而是系統級改造。

數棧對接訪問AWS-EMR的認證、調度、元數據訪問鏈路圖

打造一套“全球化的數據中臺”

開頭提到的貨幣交易所的客戶最終成為了數棧的首批 AWS 適配合作用戶。項目初期，他們面臨的典型問題不止一個：

• 數據調度工具三天兩頭掛，沒人知道任務跑沒跑完；

• 計算引擎寫入 S3 的數據總有一致性問題，結果算出來總感覺差一口氣；

• 每個業務線的數據自己接、自己處理、自己維護，一套數據平臺成了十幾塊孤島。

在袋鼠云看來，這不是產品的問題，而是出海數據基礎設施“整體系統性”的問題。

數棧在 AWS 上的適配目標，是搭建一套真正“全球可用”的數據中臺能力。所以我們拆開了五個維度，逐一重構。

存儲適配：不只是能讀寫 S3，而是要“寫得穩、讀得快、控得細”

S3 是 AWS 上的默認存儲選項，但它有個常被忽略的特性——最終一致性。這意味著，你剛寫進去的數據，不一定立刻能讀到。對于流處理、調度依賴、實時寫入的作業來說，這幾乎是“隱形炸彈”。

客戶之前用的是開源 Hadoop 的 S3AFileSystem 接入方式，讀取慢、目錄雜亂、偶發數據“看不見”。袋鼠云對接了 AWS 的原生優化版本?EmrFileSystem的方式，徹底解決了這個問題。

EmrFileSystem讀寫 HDFS配置

EMRFS 有三點關鍵優勢：

• 支持 強一致性視圖（Consistent View），寫完立馬能讀，Flink/Spark 流任務更穩定；

• 支持?目錄緩存與智能分段上傳，大文件寫入快、列表速度更快；

• 支持與 IAM 和 Lake Formation 聯動的權限管控，讓“讀寫誰的數據”不再靠腳本設權限。

計算整合：不只是跑得動 Spark/Flink，而是自動彈性、精細調度

客戶的數據處理任務很雜，有周期性批量任務，有高頻流式計算，還有一些重資源的查詢任務。最早他們用開源集群，調度器負載高就卡死，恢復得靠“看運氣”。

袋鼠云幫助他們把核心任務運行在?EMR on EC2 集群上，也就是 AWS 原生的彈性 Hadoop/Spark 平臺。數棧的調度系統自動識別任務資源需求，提交給 EMR，系統會自動拉起集群、運行任務、再釋放資源。

AWS EMR集群對接

對客戶而言，效果非常直觀：

• 計算資源彈性拉升，不用擔心凌晨高峰資源不夠；

• 作業失敗自動重試+告警，運維壓力大幅下降；

• EMR 成本按分鐘計費，資源利用率提升 40%+。

一句話總結就是：以前靠人盯著調度器跑，現在調度器自己知道怎么跑最合適

?元數據對接：用 Glue Catalog 做平臺級數據資產管理器

元數據聽起來抽象，但對于有幾十上百個表、成千上萬個字段的業務平臺來說，“我有哪些表？結構是不是最新的？別的團隊能不能也用？”這就是數據工程的真實日常。

數棧原本用自建?Hive Metastore?管理表結構，遷到 AWS EMR后，我們對接了 Glue Catalog，把所有表的結構、分區、存儲路徑、Schema?變更，統一托管到 Glue 里。

Glue Catalog數據源構建

Glue Catalog元數據構建

這帶來兩個立竿見影的好處：

• 不用再維護一個獨立的元數據庫，Glue 是 serverless 的，自動托管、高可用；

• 所有在 S3、Redshift、Athena 上的數據分析工具，都可以用 Glue 的元數據，真正實現數據資產“一處定義、處處可用”。

而且 Glue 自帶自動 Schema 爬蟲（Crawler），文件一落地，表結構自動生成，再也不需要工程師人肉注冊。

權限控制：不是“能防”，而是“可管理、可審計、可精細分發”

數據權限在出海場景里從不是錦上添花，而是剛需，尤其是面向多團隊、多角色甚至多租戶的系統。

通過AK&SK的方式構建Glue Catalog

袋鼠云能夠支持AK&SK和IAM的認證以及結合IAM Poclic+數據庫自身權限管理實現資源+數據庫級別的訪問控制：

• 安全效果得到增強，IAM+數據庫雙重認證，憑證泄密也無法通過非法IP進行訪問，能夠實現最小權限的安全落地。

• 運維管理能力提升，統一的身份管理，基于IAM策略實現動態授權，通過aws審計報告自動生成來提神自動化水平。

• 業務合規效果增強，滿足了監管需求，實現了多租戶隔離防止跨租戶泄密，審計日志的追蹤鏈路完整。

• 成本優化效果明顯，資源利用率提升，運維成本降低，安全事件損失減少。

這讓客戶在面對“誰能看交易金額、誰能查鏈上地址”這樣的問題時，不用再靠信任——權限系統自己就能給出答案

產品體驗：界面沒變，但能力變了

袋鼠云做了那么多 AWS 原生集成，對客戶來說最直觀的感受其實是：“體驗沒變。”

拖拽建模、任務調度、血緣分析、實時開發、資產管理……界面還是那個數棧，學習成本沒有提升。但背后的一切都已經跑在 AWS 上，跑得更穩定、更彈性、更安全。

實時開發Catalog管理

客戶說：“用你們的產品，我不用去理解 EMR 里 Spark 怎么配置，Glue Catalog 怎么建表，權限策略怎么穿透，這就夠了。”

出海這件事，技術不能只是“能跑”

“能跑”，是底線；“能跑好”，才是出海平臺的基本功。

數棧與 AWS 的聯合適配，不是為了解決某一個技術問題，而是為了解決出海企業在 “高彈性 + 高安全 + 高治理要求”環境下構建統一數據中臺的需求。

袋鼠云不想把國產技術硬搬過去，而是要在全球通用的云體系下，讓真正想在海外落地的數據業務，有一塊穩定、彈性、好用的“數字地基”。

這不是兼容，這是重構。這不是跑通，而是跑贏。

越來越多的中國企業正在走向全球，這也是數棧為什么要在 AWS 上，重做一遍中臺的真正原因。袋鼠云相信，真正的出海能力，絕不是簡單的“向外復制”，而是深度嵌入全球云生態、以業務為核心進行技術重構。未來，數棧還會繼續拓展全球主流云平臺的適配能力，為更多出海企業構建屬于他們的全球數智基建。