Facebook、亞馬遜等巨頭是如何建造自己的資料庫的？

Facebook的工程師發明了Presto，一種針對點對點分析進行優化的定製分布式的SQL查詢引擎。

在Keen IO，我們認為會運用事件數據的公司才具有競爭優勢，世界領先的科技公司證明了這一點。但是我們仍然對Facebook、Amazon、Airbnb、Pinterest和Netflix數據團隊所做的事情感到驚訝。他們為軟體和企業從數據中獲取信息而制定了新標準。

由於他們的產品用戶量極大，所以這些團隊必須不斷地定義規模分析的方法。他們已經在數據架構中投入了數百萬美元，並且在大多數公司中，數據團隊的規模超過了整個工程部門的規模。

我們建立了Keen IO，是為了以讓大多數軟體工程團隊無需從頭架設所有內容，就可以利用最新的大型事件數據技術。但是，如果您對如何成為巨頭公司感到好奇，那麼請從最好的公司中收集一些架構。

Netflix

Netflix擁有9300萬用戶，沒有交互缺陷。正如他們的工程團隊在Netflix數據管道的演變中描述的那樣，他們每天大約捕獲5000億個事件，每天大約有1.3 PB的數據傳輸。在高峰時段，他們每秒將記錄800萬次事件。他們僱用了100多個數據工程師或分析師。

以下是上述文章中數據架構的簡化視圖，其中顯示：開源系統Apache Kafka，搜索伺服器Elastic Search，亞馬遜雲存儲服務AWS S3，進行大數據處理的Apache Spark，運行框架Apache Hadoop和大數據分析服務EMR作為主要組件。

Facebook

擁有超過10億的活躍用戶，Facebook有世界上最大的數據倉庫之一，存儲超過300PB。該數據被用於廣泛的應用：從傳統的批處理到圖形分析，機器學習和實時互動式分析。

為了進行大規模的互動式查詢，Facebook的工程師發明了Presto，一種針對點對點分析進行優化的定製分布式的SQL查詢引擎。每天有1000多名Facebook員工使用Presto，通過Hive、HBase和Scribe的可插拔後端數據存儲，每天執行查詢次數超過30000次。

體系結構 :

後端數據存儲 :

Airbnb

Airbnb支持超過1億用戶瀏覽200多萬的房屋列表。他們智能地向這些用戶提供新的旅行建議的能力，這對他們的成長有很大影響。

Airbnb的數據科學經理Elena Grewal在去年的會議「建立一個世界級的分析團隊」上提到，他們已經將Airbnb的數據團隊擴展到擁有30多名工程師的規模。這是每人每年500萬的投資。

在博客《數據基礎架構》一文中，AirbnbEng建築師James Mayfield、Krishna Puttaswamy、Swaroop Jagadish和Kevin Longdescribe描述了構建數據結構的基本要素以及如何為關鍵任務數據提供更高的可靠性。他們嚴重依賴Hive和Apache Spark，並使用了Facebook的Presto。

AIRBNB的數據基礎結構 :

Pinterest

Pinterest每月有超過1億的用戶瀏覽超過100億的網頁瀏覽量。截至2015年，他們將數據團隊擴展到擁有250多名工程師的規模。他們的基礎設施依賴於開源系統Apache Kafka，數據處理框架Storm，系統基礎架構Hadoop，開源資料庫HBase和GPU渲染器Redshift。

數據管道結構圖 :

Pinterest團隊不僅需要追蹤大量客戶相關的數據。像其他社交平台一樣，他們還需要向廣告商提供詳細的分析。黃彤波在《Behind the Pins: Building Analytics at Pinterest》一文中寫道：為了滿足這一需求，他們改進了自己的分析堆棧。以下是Pinterest團隊如何使用Apache Kafka，AWS S3和HBase的示意圖：

Pinterest商業數據分析結構圖 :

Twitter / Crashlytics

每天實時處理50億次會議。Ed Solovey介紹了Crashlytics Answers團隊構建的一些架構，用於處理數十億的日常移動設備事件。

信息流接收 :

存儲 :

批處理計算 :

加速計算 :

總覽 :

Keen IO的數據架構

正如我之前提到的，我們構建了Keen數據介面（API），以便任何開發人員都可以使用世界一流的數據架構，而無需擁有一個龐大的團隊構建一大堆基礎架構。成千上萬的工程團隊使用Keen的API來捕獲、分析、流式傳輸和嵌入事件數據，包括實時和批處理應用程序。

雖然使用Keen的開發人員在發送事件或運行查詢時不需要知道幕後發生的情況，但下面是處理其請求的體系結構：

Keen IO 信息處理結構圖 :

在輸入方面，負載均衡器處理數十億個傳入的帖子請求。事件流來自於應用程序，網站，連接設備，伺服器，計費系統等等。事件需要驗證、排序和可選擇地豐富額外的元數據，如IP-地理查詢。這一切都發生在幾秒鐘內。

一旦安全地存儲在Apache Cassandra中，事件數據就可以通過REST API進行查詢。我們的架構（通過Apache Storm，DynamoDB，Redis和AWS lambda等技術）支持從原始傳入數據實時數據探索，到應用程序和面向客戶報告的緩存查詢的各種查詢需求。Keen每天查詢數萬個事件屬性，並為成千上萬的客戶構建報告，自動化和數據挖掘界面。

感謝團結一致的數據工程界，不斷發明新的數據技術、開源，並分享他們的知識。如果沒有這麼多工程隊伍的基礎工作，沒有與我們天天一起合作的人，我們的團隊也不可能有今天。歡迎各方的意見和反饋。

特別感謝文章中提到的的作者和建築師：Netflix的Steven Wu，Facebook Presto、AirbnbEng和Pinterest的工程師Martin Traverso，以及Crashlytics Answers的Ed Solovey。

文章來自：36Kr

文章鏈接：http://36kr.com/p/5073792.html

翻譯來自：蟲洞翻翻譯者ID：王煒 編輯：郝鵬程

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！