作為全球數據驅動型企業的典範，Meta 的大規模數據工程實踐為行業樹立了標杆。本文深度解析其數據基礎設施，涵蓋從 Exabyte 級數據倉庫（Hive/ORC 存儲、名稱空間分區）到混合計算引擎（Presto/Spark 離線分析 + Scuba 實時查詢），再到 Daiquery/Bento 開發工具與 Unidash 可視化平台。揭秘 Meta 如何通過 UPM 流水線管理、分析庫集成及自動化監控，構建支撐千億級日活的高效數據鏈路，展現湖倉架構、流批融合及雲原生設計的工程化落地經驗，為企業數據智能建設提供可複用的技術藍圖。
文章來源：https://medium.com/@AnalyticsAtMeta/data-engineering-at-meta-...從一個寬泛的視角，介紹了 facebook 的 data engineers 使用的一些技術工具和框架The data warehouse
內部使用了 ORC的一個fork，對讀做了優化，鏈接
facebook 的數倉規模是 EB 級別的，所以一個數據中心放不下，需要跨幾個機房存儲
他們使用了 namespace 這個概念，混合了邏輯和物理位置
而一個表 就確定屬於某個 namespace 的，這樣一個 namespace 下的查詢就不會跨機房了
但如果要跨 namespace 查詢，就需要將 A 表拷貝，或者 B 表拷貝到對應的機房每個表都按照 ds 分區，也就是 YYYY-MM-DD 分區的，一般是數據產生的時間，也有其他方式分區的
數據一般保留 90天，超過了就 歸檔，或者刪除數據如何寫入數倉的通過 data workflows 和管道寫入的，data workflows服務端和客户端拿到日誌生產環境圖數據日的每日快照Data discovery, data catalog
facebook 內部有一個叫 iData 的檢查平台，是基於 web 的
開發人員可以根據 table 等關鍵字做搜索，檢查平台為基於多個指標，如數據新鮮度文檔下游使用數量，ad hoc queries, other pipelines or dashboards可以查找表的列類型，表的所有者
其他一些數據資產維度，比如 上游、下游的依賴等等Presto and Spark: Querying the warehouse
主要是用 presto、spark 做查詢
內部維護了一個分支，做了一些定製化修改，也會定期合併開源分支，同時也會提交修改到開源所以內部使用主要就是基於spark、presto 方言寫的 sql
一些複雜的邏輯會用 java、scala、python 來實現
data engineer, data scientist, software engineerpresto 主要是做 adhoc 查詢，spark主要是複雜的 join 查詢
一般 presto 會查詢 幾十億行的數據，大概幾秒，如果有聚會、join 需要幾分鐘Scuba: Real-time analytics
facebook 內部的一個實時分析框架，用來分析日誌的趨勢
facebook 每天會產生 幾百P 的數據，用户行為，代碼變更，這個框架就用來實時分析這種變化，並提供開發人員展示Scuba 的數據來自於客户端、或者服務端的 log
Scuba 可以通過 web UI 查詢，類似於 Kibana，這樣就不用寫程序了，一般是生成 過去 5分鐘的趨勢報告
或者通過一種 SQL 方言查詢
最後數據會寫入到 hiveDaiquery & Bento: Query and analysis notebooks
data engineers 每天都會使用的工具之一
基於 web 的方式，可以查詢任何數據源warehouse (either through Presto or Spark)Scuba其他任何源查詢結果會以表格的方式展示，當然也可以 用其他形式展示
Daiquery 不支持其他複雜的查詢
對此可以使用 Bento，這是 Jupyter 的內部實現，可以用 python 或者 R 做查詢
很多 data scientists 用這個做機器學習、或者數據分析Unidash: Dashboarding
類似於 Apache Superset、Tableau
比如工程師可以在 Daiquery 寫查詢，創建圖表，然後導入 dashboard 中
而每次查詢，再加載這個效率太低了這裏可以用 預聚會來加速，facebook 內部維護了一個 presto 改進的實現 RaptorX，有 10倍加速
這是通過緩存了通用的數據來加速的RaptorX: Building a 10X Faster Presto
dashboard 可以通過 web 接口創建，也可以通過 python 來創建
Software development
內部使用了 高度定製化的 Visual Studio Code 作為 IDE，包括了一堆內置的插件，由專門的 team 維護
內部使用 Mercurial 的 fork版本作為源碼控制，現在已經將其開源了 Sapling: Source control that’s user-friendly and scalable
採用的是 monorepo 代碼管理方式所有的 pipelines 和內部工具 都在一個倉庫日誌定義，配置對象 在其他兩個倉庫工程師會開發 pipelines，用來創建重要的數據集，之後通過分析工具或者 dashboard 來做查詢，提供決策支撐
這些內部的基礎設置工具，也會提交到 公司基礎設置部門Writing pipelines
數據流水線基本都是用 sql 寫的，然後包裝進 python 代碼裏面，再編排和調度
內部使用的調度框架是：Dataswarm，基於 AirFlow 做的修改流水線是基於算子的，也就是 DAG 圖
Dataswarm 中的大多數子算包括WaitFor operators，等待某個其他操作Query operators，運行查詢，基於 presto、或者sparkData quality operators，對插入的數據做自動校驗Data transfer operators，數據轉換Miscellaneous operators，如發送 email，聊天通知，調用 API，執行腳本等代碼定義的流水線類似這樣：
內部的 VSCode擴展，在保存或者計算 DAG 時，會執行這些 流水線邏輯
如果 SQL 有問題，自定義的擴展會提示
也運行工程師 基於真實數據調度一個測試用例，並將結果寫到臨時表中UPM: Advanced pipeline features
一個內部的 統一 sql 前端
可以做的事情相當於是 spark + presto 方言語法分析，判斷sql 是否合法做一些 sql 校驗根據 select 中的列，可以檢查出上下游的 血緣關係比如，可以自動推斷 所有的 WaitFors 依賴
Enabling static analysis of SQL queries at Meta
工程師通過 DAG 來檢查 UPM 推斷的依賴是否正確Analytics Libraries
除了 UPM，還有其他一些庫，用來創建複雜的pipelines
這些管道手動創建比較難
Analytics and Product-Market Fit產生的一個 摘要風格的表
這個表包含了三個維度列productcountryhas_log_session以及兩個聚合列total_session_time_minutestotal_distinct_users_hllHyperLogLog in Presto: A significantly faster way to handle cardinality estimationMonitoring & operations
相當於 Dataswarm UI，一個基於 web 的界面
用來監控 pipeline 的，這個工具叫：CDM (Central Data Manager)
有點類似 Airflow 的 Tree View，除此之外還包括：快速識別失敗的 task，並找到對應的 log定義和運行回填導航到上游依賴識別上游阻塞，遞歸的導航上游依賴，自動的找到 root，發現阻塞原因如果不滿足 SLA，則啓動通知報警設置監控數據質量檢查監控動態任務和歷史性能。
