網際網路大廠的大資料解決方案
滴滴的大資料體系
我們先來看一組來自滴滴出行的資料：
截止到 2021 年 7 月，滴滴注冊使用者已超過 6.5 億，年運送乘客達 150 億人次，每日處理資料 4875+TB，日定位數超過 200 億，每日路徑規劃請求超過 500 億次。
那這樣龐大的資料量，背後是由一個怎樣的大資料體系作為支撐呢？如下是在全球軟體開發大會上講解的滴滴大資料研發平台。
- 最上層的紅色箭頭标志展示的是一個基于大資料平台開發工程的釋出流程，當然，這個流程跟大資料的關系并不是很大，任何一個工程基本都要遵照這個過程進行釋出。
- 緊挨着的流程是機器學習部分，機器學習會涉及資料挖掘 / 資料分析 / 資料應用幾個步驟。
- 再往下是實時計算解決方案和離線計算解決方案。
- 在架構圖的最底層是相關的支援，包括了資料安全、資料管理、開發運維和計算引擎四個部分。
就滴滴公布的大資料發展曆程來看。
- 滴滴大資料先經曆了裸奔時代：引擎初建，即通過 Sqoop 從 MySQL 導入 Hadoop，使用者通過指令行通路大資料；
- 然後逐漸引進了相關的工具化建設，但是這個階段的工具還處于各自為政、四分五裂的狀态：租戶管理、權限管理、任務排程等；
- 在那之後，逐漸産生了平台化思維，開始搭建一站式的智能開發和生産平台，使其可以覆寫整個離線場景，并且内置開發和生産兩套邏輯環境，規範資料開發、生産和釋出流程；
- 最後，也就是最新的一套大資料架構，在一站式開發生産平台的基礎上進行了更多的擴充，已經可以集離線開發、實時開發、機器學習于一體。
阿裡雲大資料體系
飛天大資料平台和 AI 平台支撐了阿裡巴巴所有的應用，是阿裡巴巴 10 年大平台建設最佳實踐的結晶，是阿裡大資料生産的基石。下圖是飛天大資料的産品架構：
- 最下面是計算存儲引擎，這裡面包含了通用的存儲和計算架構。存儲方面，OSS 是阿裡雲的雲存儲系統，底層的 HDFS 檔案存儲系統，以及其他的各種 DB 系統；在計算架構方面，有 MapReduce 這種離線計算平台、實時計算平台、圖計算引擎、互動式分析引擎等。
- 在存儲和計算的基礎上，是全域資料內建，這裡面主要是對資料的各種采集和傳輸，支援批量同步、增量同步、實時同步等多種傳輸方式。
- 內建後的資料進入到統一進制資料中心，統一進行任務排程。
- 再往上是開發層，通過結合各種算法和機器學習手段開發各種不同的應用。
- 最上面的資料綜合治理，其實是在大資料全流程起到保障作用的一些子產品，包含了智能監控、資料安全等子產品。
美團的大資料體系
這是美團早些年公開的大資料體系架構：
- 最左側是美團的各種業務服務，從這些業務的資料庫和日志，可以通過資料傳輸、日志采集等手段對資料進行彙總，一方面對于計算需求，直接進入到 Storm 流式計算架構進行計算，把結果存儲于 HBase 等各種資料庫中，并在業務上應用；另一方面，資料彙總到Hadoop 架構的存儲中心，經過各種解析和結構化存儲在 Hive 表中，并在各種機器學習和資料挖掘項目中進行應用。
- 在底層，是圍繞着 Hadoop 架建構設的排程系統、配置中心，以及資料開放平台。
- 在最右側，是經過內建的查詢中心和查詢引擎，并通過平台化開發建立了一套資料分析産品平台。
當然，美團的大資料體系不是一蹴而就的，也是随着時間的推移不斷疊代和演進的：
- 在最早的 2011 年，美團基本還處于資料裸奔的狀态，隻有在有需求的時候才手工開發一個資料報表；
- 在 2011 年下半年引入了整個資料倉庫的概念，梳理了所有資料流，設計了整個資料體系；
- 2012 年上了四台 Hadoop 機器，後面十幾台，到最後的幾千台以支撐各個業務的使用；
- 對于實時計算部分，在 2014 年開始啟動應用，與此同時，也開始進行各種平台化的封裝，以使得這些開源的工具架構能夠更好地為業務所用；
- 時至今日，距離這個分享又過去了五年，在美團最新公開的一些關于大資料的文章和視訊分享上，我們也可以看到整個大資料體系發生了長足的進展，不管是在平台化的演進還是對于現今技術的應用方面，都已經有了飛速的變化。
大資料體系的共同點
一口氣看了這麼多網際網路大廠的大資料體系解決方案：
- 其中有比較早期的大資料體系，如 2016 年的美團大資料架構；
- 也有比較偏向于業務型的大資料架構，如滴滴的大資料平台；
- 也有用于通用解決方案的大資料體系，比如阿裡飛天大資料平台産品架構。
它們屬于不同的公司，作用于不同的業務，當然會有很多的不同點，但是不難看出，在大資料體系的發展過程中，也存在着很多相同的部分。
子產品化
大資料體系涉及了關于資料的一系列動作。随着大資料體系建設的逐漸完善，各個步驟變得更加清晰可分，不管是存儲、排程、計算都被拆分成單獨的子產品，進而可以支援更多的業務，并根據需要進行靈活的選用。
平台化
實施大資料的公司往往都有各種各樣的業務，早期的大資料一定是圍繞着各個業務去單獨建設的，但是随着時間的流逝，各個業務之間的大資料體系存在着各種各樣的差異，這就使得業務之間的資料互動成了一個難以跨越的鴻溝，建設一個把各業務的相似點統一起來，又能夠包容各業務的差别的平台，讓這些資料發揮出更大的價值成了一個迫在眉睫的需求。
實時化
實時化一直是網際網路公司不懈追求的。在大資料體系的演進中也充分展現了這一點。
最早期的開源大資料架構 Hadoop 都是基于磁盤開發的，不管是底層資料的存儲還是計算的中間結果存儲都放在磁盤上，而且其中的計算架構 MapReduce 也是基于離線的資料批處理，沒辦法對實時資料進行計算。
而看現在幾大公司的大資料體系，實時計算已經成了大資料體系中一個非常重要的組成部分。
不完善
根據最近幾年的工作經驗，雖然大資料體系在不斷地發展和變化，各種新技術不斷地應用，但是大資料體系還遠沒有達到一個完善的水準，其中仍然存在着各種各樣的問題。我們的資料在不停地生産，規模不斷擴大，雖然說各種硬體的性能在提升，價格在下降，但是這仍然是公司非常巨大的一筆開支；同時，在大資料的治理方面還很欠缺，随着資料的不斷增長，資料的共享和合理利用效率在不斷地下降，同時在資料安全方面也存在着很大的隐患。是以，關于大資料架構的疊代還遠沒有結束，在未來肯定還會有更多更好的解決方案推陳出新，解決舊問題，滿足新需求。