企業級大數據平臺建設參考 | 淘寶&滴滴&美團&360&快手&京東

企業級大數據平臺建設參考 | 淘寶&滴滴&美團&360&快手&京東

大數據技術與架構 大數據技術與架構

本文結合小編本身的經驗而且參考了淘寶&滴滴&美團&360&快手等各個大廠大數據平臺建設的思路。在尊重事實的基礎上從新組織了語言和內容，旨在給讀者揭開一個完善的大數據平臺的組成和發展過程。
大數據平臺是爲了計算，現今社會所產生的愈來愈大的數據量，以存儲、運算、展示做爲目的的平臺。大數據技術是指從各類各樣類型的數據中，快速得到有價值信息的能力。適用於大數據的技術，包括大規模並行處理（MPP）數據庫，數據挖掘電網，分佈式文件系統，分佈式數據庫，雲計算平臺，互聯網，和可擴展的存儲系統。總結，大數據平臺的出現伴隨着業務的不斷髮展，數據的不斷增加，數據需求的不斷增長，數據分析及挖掘的場景而逐步造成。本文講述淘寶&滴滴&美團&360&快手等各大互聯網公司的大數據平臺的發展歷程，爲你們提供建設大數據平臺的基本思路。

淘寶大數據平臺

淘寶多是中國互聯網業界較早搭建了本身大數據平臺的公司，下圖是淘寶早期的 Hadoop 大數據平臺，比較典型。

雲梯數據倉庫架構-圖來源於《淘寶大數據平臺之路》
淘寶的大數據平臺基本分紅三個部分，上面是數據源與數據同步；中間是雲梯 1，也就是淘寶的 Hadoop 大數據集羣；下面是大數據的應用，使用大數據集羣的計算結果。數據源主要來自 Oracle 和 MySQL 的備庫，以及日誌系統和爬蟲系統，這些數據經過數據同步網關服務器導入到 Hadoop 集羣中。其中 DataExchange 非實時全量同步數據庫數據，DBSync 實時同步數據庫增量數據，TimeTunnel 實時同步日誌和爬蟲數據。數據所有寫入到 HDFS 中。

數據同步工具-圖來源於《淘寶大數據平臺之路》
在Hadoop中的計算任務會經過天網調度系統，根據集羣資源和做業優先級，調度做業的提交和執行。計算結果寫入到HDFS，再通過DataExchange同步到MySQL和Oracle數據庫。處於平臺下方的數據魔方、推薦系統等從數據庫中讀取數據，就能夠實時響應用戶的操做請求。
淘寶大數據平臺的核心是位於架構圖左側的天網調度系統，提交到Hadoop集羣上的任務須要按序按優先級調度執行，Hadoop集羣上已經定義好的任務也須要調度執行，什麼時候從數據庫、日誌、爬蟲系統導入數據也須要調度執行，什麼時候將Hadoop執行結果導出到應用系統的數據庫，也須要調度執行。能夠說，整個大數據平臺都是在天網調度系統的統一規劃和安排下進行運做的。
DBSync、TimeTunnel、DataExchange這些數據同步組件也是淘寶內部開發的，能夠針對不一樣的數據源和同步需求進行數據導入導出。這些組件淘寶大都已經開源，咱們能夠參考使用。

滴滴數據平臺演進之路

到目前爲止大概經歷了三個階段，第一階段是業務方自建小集羣；第二階段是集中式大集羣、平臺化；第三階段是 SQL 化。

圖片圖來源於《滴滴大數據平臺演進之路》
離線計算平臺架構以下。滴滴的離線大數據平臺是基於Hadoo 2（HDFS、Yarn、MapReduce）和Spark以及Hive構建，在此基礎上開發了本身的調度系統和開發系統。調度系統和前面其餘系統同樣，調度大數據做業的優先級和執行順序。開發平臺是一個可視化的SQL編輯器，能夠方便地查詢表結構、開發SQL，併發布到大數據集羣上。

圖來源於《滴滴大數據平臺演進之路》
此外，滴滴還對HBase重度使用，並對相關產品（HBase、Phoenix）作了一些自定義的開發，維護着一個和實時、離線兩個大數據平臺同級別的HBase平臺，它的架構圖以下。

圖來源於《滴滴大數據平臺演進之路》
來自於實時計算平臺和離線計算平臺的計算結果被保存到HBase中，而後應用程序經過Phoenix訪問HBase。而Phoenix是一個構建在HBase上的SQL引擎，能夠經過SQL方式訪問HBase上的數據。
爲了最大程度方便業務方開發和管理流計算任務，滴滴構建了以下圖所示的實時計算平臺。在流計算引擎基礎上提供了 StreamSQL IDE、監控報警、診斷體系、血緣關係、任務管控等能力。

圖來源於《滴滴大數據平臺演進之路》

美團數據平臺

咱們以數據流的架構角度介紹一下整個美團數據平臺的架構，大數據平臺的數據源來自MySQL數據庫和日誌，數據庫經過Canal得到MySQL的binlog，輸出給消息隊列Kafka，日誌經過Flume也輸出到Kafka，同時也會迴流到ODPS。

圖來源於《美團大數據平臺》
Kafka的數據會被流式計算和批處理計算兩個引擎分別消費。流處理使用Storm進行計算，結果輸出到HBase或者數據庫。批處理計算使用Hive進行分析計算，結果輸出到查詢系統和BI（商業智能）平臺。
數據分析師能夠經過BI產品平臺進行交互式的數據查詢訪問，也能夠經過可視化的報表工具查看已經處理好的經常使用分析指標。公司高管也是經過這個平臺上的天機系統查看公司主要業務指標和報表。

圖來源於《美團大數據平臺》
這幅圖是離線數據平臺的部署架構圖，最下面是三個基礎服務，包括Yarn、HDFS、HiveMeta。不一樣的計算場景提供不一樣的計算引擎支持。若是是新建的公司，其實這裏是有一些架構選型的。Cloud Table是本身作的HBase分裝封口。咱們使用Hive構建數據倉庫，用Spark在數據挖掘和機器學習，Presto支持Adhoc上查詢，也可能寫一些複雜的SQL。對應關係這裏Presto沒有部署到Yarn，跟Yarn是同步的，Spark 是 on Yarn跑。目前Hive仍是依賴Mapreduce的，目前嘗試着Hive on tez的測試和部署上線。
另外咱們得知，在實時數倉的建設中，美團已經從原來的Storm遷移至Flink，Flink的API、容錯機制與狀態持久化機制均可以解決一部分使用Storm中遇到的問題。Flink不只支持了大量經常使用的SQL語句，基本覆蓋了經常使用開發場景。並且Flink的Table能夠經過TableSchema進行管理，支持豐富的數據類型和數據結構以及數據源。能夠很容易的和現有的元數據管理系統或配置管理系統結合。
美團大數據平臺的整個過程管理經過調度平臺進行管理。公司內部開發者使用數據開發平臺訪問大數據平臺，進行ETL（數據提取、轉換、裝載）開發，提交任務做業並進行數據管理。

360數據平臺演進之路

奇麟（Qirin），是由360系統部研發的一站式大數據平臺，完整覆蓋了大數據的採、存、管、算、用整個大數據開發和處理流程，目前服務於整個集團 30+部門，1000+用戶，服務器 25000+，存儲數據量 EB 級。能夠幫助業務部門快速構建本身的數據平臺及數據產品。

從功能上，奇麟主要由如下模塊構成（自底向上）：
（1） 資源管理：用於各種大數據服務資源的申請和管理，以及訪問權限的申請與管理，包括存儲資源、計算資源等；
（2） 元數據管理：基於資源管理，爲其餘模塊提供統一視圖，將整個大數據處理平臺（流程）貫穿起來。元數據管理一方面支持奇麟系統平臺資源，同時也支持用戶導入外部自有資源，進而託管應用；
（3） 數據聚集：用於將外部數據聚集到大數據存儲中，包括實時和離線的數據聚集；
（4） 任務開發：批流合一的任務平臺，用於開發、調度、監控實時和離線數據處理任務；
（5） 交互分析：用於使用 SQL 快速查詢探索數據，以及簡單的可視化分析和結果展現；
（6） 數據服務：基於以上各子系統能力，提供知足若干場景的 SaaS 服務，好比數據歸檔備份、跨集羣的數據傳輸，以及對外提供數據共享等；
（7） 權限中心：用於管理資源帳號權限以及開發組權限；
（8） 系統管理：提供一些系統基礎功能的管理
面向業務，奇麟思考的是經過提供簡單易用的一站式大數據處理的平臺，下降使用門檻，簡化大數據平臺工做，幫助業務釋放數據價值，賦能業務。

奇麟經過模塊化設計，使得各個模塊能夠靈活組裝和運行，針對不一樣的司內外業務場景，能夠快速造成不一樣的大數據解決方案和產品。

快手大數據服務化平臺

大數據服務化業務架構以下所示，Data Lake 數據湖中存儲原始數據，通過數據開發以後，造成按主題域組織的數據資產。此時數據資產一般是在數據倉庫，訪問速度較慢，所以須要經過數據加速到更高速的存儲介質，最後通過多場景服務接口，服務於業務。

在技術架構方面，數據接口形式有 RPC 和 HTTP 兩類接口。RPC 接口不須要重複創建連接，且傳輸數據時會被高效序列化，適用於高吞吐場景下的微服務，實現負載均衡、流控、降級、調用鏈追蹤等功能。相對而言，HTTP 接口傳輸效率低一些，但使用很是簡單。

快手大數據服務化平臺從2017年演化至今，已經支持多類應用場景，涵蓋直播、短視頻、電商、商業化等在線業務，生產者中臺等準在線業務，運營系統等偏內部數據系統等，目前平臺在線業務總 QPS 達到 1000W，平均延遲在毫秒級；對於準在線業務和內部數據系統，基於CH、Druid等多種數據引擎，支持多種靈活查詢。數據服務平臺支持了多種模式API，很好知足了多元化需求。
快手大數據服務化平臺高可用保障：

彈性服務

數據服務是部署在容器雲環境，容器雲是快手自研的彈性可伸縮的容器服務，部署在其中的RPC服務會註冊到 KESS （快手自研服務註冊與發現中心），供主調方去調用，若有離羣壞點，會自動摘除。服務調用是基於 RPC，全鏈路都有監控，包括服務可用性、延遲、QPS、容器CPU、容器內存等狀況。

資源隔離

資源隔離是可用性保障的常見手段之一，經過隔離將意外故障等狀況的影響面下降。不論是微服務，仍是存儲，咱們都按照業務 + 優先級（高、中、低）粒度隔離部署，獨立保障，業務之間互不影響、業務內不一樣級別也互不影響。同一業務線內可能有多個不一樣數據服務，經過混合部署，提升資源使用率。

全鏈路監控

服務很難避免出現問題或者故障，一旦出現問題，及早發現及早介入是很是重要的。服務平臺構建了全鏈路監控，包括：

• 數據同步：對數據資產同步至高速存儲的過程進行監控，包括數據質量檢測（過濾髒數據）、同步超時或者失敗檢測等
• 服務穩定性：構建一個獨立的哨兵服務，來監測每一個API的運行指標（如延遲、可用性等），客觀的評估健康度
• 業務正確性：數據服務須要確保用戶訪問的數據內容和數據資產表內容是一致的，所以哨兵服務會從數據一致性層面去探查，確保每一個API的數據一致性
  
  快手大數據服務平臺的能力建設會朝着統一的 OneService 體系前進。主要包括三個方面：
• 支持豐富的數據源：包括大寬表、文本文件、機器學習模型（模型也是一種數據資產），來構建完善的數據服務。
• 支持多樣取數方式：除了支持同步快速取數以外，還支持異步查詢取數、推送結果、定時任務等多樣化方式，以知足業務多種場景需求。
• 建設統一的API網關：集成權限管控、限流降級、流量管理等於一體，不只平臺建立的服務能夠註冊進API網關，用戶本身開發的API也可註冊進API網關，從而享受已有的基礎網關能力，爲業務提供數據服務能力。

  京東 EB 級全域大數據平臺

京東整個平臺經歷了很長的建設和發展歷程。這個歷程包括了五個階段：

規模化階段

主要完成了技術棧的計算存儲分離升級，依託數據中心網絡技術的提高，減弱對計算本地性的依賴，打散存儲熱點，提升計算穩定性；同時定製存儲與計算優化機型，獨立進行容量規劃，大幅下降IT資源成本。在存儲上實現了穩定的萬臺規模HDFS集羣，並在其上全面落地了糾刪碼技術，實現高效高壓縮比的大數據存儲；再在計算上進行了跨層的優化，從調度層、引擎層和應用層分別進行了深度的改進；最後經過全生命週期管理保障平臺的存儲計算能力持續處於健康狀態。

體系化階段

從金融業務，物流業務，電商業務，保險業務、健康業務等不一樣業務的特色和需求出發，逐步構建成標準化、可管理、可維護、可理解、可複製、一站式、體系化的數據中臺，解決了前面提到的業務複雜、數據異構、煙囪化開發、建設成本高等問題。
經過數據層面全鏈路的規範、盤點、治理，以及平臺工具層面業務標準化支撐，打造出京東全集團體系化數據中臺。
總而言之，體系化是數據中臺的核心目標之一，覆蓋了數據從生產、計算、存儲、消費的全生命週期，爲數據價值的高效發揮提供了堅實基礎。
基於體系化建設的經驗，咱們也沉澱和打磨各項數據能力，提煉出一系列的產品化解決方案。這種體系化建設的方法論和實踐經驗，讓咱們在業務快速佈局、快速發展的階段中，可以使數據很是高效的輸入到決策引擎，造成快速的商業決策。

一方面，京東在任務調度、數據分發、狀態恢復等方面進行了深度定製優化，大幅提高了系統魯棒性，也經歷了屢次大促洪峯的考驗；另外一方面落地了基於容器的雲原生彈性資源調度，打造了全自研的自愈框架，實現自動化自適應的故障恢復能力，能有效的保障系統和平臺的穩定性。
其次，Easy Realtime 平臺是企業級應用平臺，集成了一站式雲代碼開發，並直接對接雲原生實時計算平臺。
平臺的建設目標是讓沒有任何代碼開發能力的一線業務同事，例如京東的採銷同事，甚至是 ISV 代理，通過短期培訓，可以具有 SQL 能力、快速上手，自主實現業務決策開發。

智能化階段

平臺裏有幾個核心的算法引擎，包括 9N-FL 聯邦學習引擎。支撐這些引擎的基礎是面向整個算法領域的雲化資源管理系統，它與面向數據的管理系統無縫集成，造成一站式的數據算法解決方案，最終賦能京東的零售業務、健康業務、金融業務等, 推進業務的高速發展。

商業化階段

基於以上四個階段的發展，京東最終打造出依託於實際業務支撐經驗的，可同時支持多領域應用(零售、物流、金融、健康等)的全域大數據平臺。它包含的系統、工具、產品和方法論，與業內主流數據中臺也有必定的共通之處。