英語流利說基礎數據平臺

隨著大數據產品的日益成熟與穩定，如今不少互聯網公司在數據產品所投入的運維工作已經越來越少，另外，加上國內云服務的不斷普及，建立一套自己的大數據基礎平臺的成本也將變的更低。本文將向大家簡要介紹流利說是怎樣基于 AWS（Amazon Web Services）服務構建自己的大數據平臺。

數據平臺架構

• 存儲系統 - 從 HDFS 到 S3

從架構圖中，可以看出，我們選用了 Amazon 的 S3 作為整個平臺的存儲層，這使得我們在整個平臺的任何一處地方都可以很輕松的獲取數據，而作為同一類別的產品 Hadoop HDFS，我們對于它的定位，則是輔助 MapReduce / Yarn 的運行，其本身不存儲任何 Job 的最終數據。當然我們確實有一段時間，所有的 ETL 數據存儲到 HDFS，但后來我們發現其不利于集群的擴展。比如集群在做伸縮性擴展時，DataNode 節點需要退役，移動數據的成本太大，造成擴展集群的時間太長。

而另外一個重要的因素在于，我們基于 S3，在其上構建了數個 EMR（Amazon Elastic MapReduce）集群，而這些集群之間是相互獨立的，這樣我們可以基于 S3 和 EMR 做到存儲層面的共享，而在計算資源層面做到隔離。

• 計算資源 – EMR

Amazon EMR 在于我們可以很方便并快速的構建一個基于 Hadoop，Spark，Hive等大數據產品的計算集群，如果不是需要長久服役，我們可以在其所有 Job 完成之后，銷毀集群，而并不影響數據的持久化，因為所有的數據都保存在 S3。事實上，我們每天的 ETL Job 正以 T+1 的方式使用這一類型的集群，當所有 Job 完成之后，調度系統會立即銷毀集群（下文會講到我們是如何管理并使用集群的）。

另外一點，對于集群上的任務，他們的特點可能都不太一樣，比如推薦和算法業務可能對集群的計算能力要求較高，而 ETL 類型的任務，可能又對存儲或內存要求較高。因此我們在構建集群之前，可以通過指定機型來達到這樣的效果，并在后期任務節點上做到伸縮性擴展。

• 服務發布 – Consul

縱向來看，平臺的所有節點在啟動之初都會向 Consul 注冊自己，如果是 EMR 類型的節點，其本身作為一種計算服務， Master 節點會向 Consul 發布一個新的服務， 因此后期我們在向集群提交任務時，實際上并不需要指定集群地址，而只需要告訴 Execution Service（任務與集群管理服務），我需要一個可以作為推薦系統的集群即可。

后面，我們會講到流利說的 Execution Service ，它是一個 Master/Slave 架構類型的系統，因此單點的 Master 并不能保證HA（高可用性）。事實上該系統在構建之初，也會向 Consul 發布服務，所以調度系統在向 Execution Service 提交任務時，并不需要指定 Master 節點。

• 任務與EMR集群管理系統 - Execution Service

Execution Service（以下稱為ES）用來管理EMR集群的創建，擴容，以及銷毀，另外還負責每天流利說所有調度任務的提交，執行，以及結果的反饋。 目前ES支持的任務類型包括 Bash，HQL（Hive SQL Script），以及 Spark。所有對集群的操作，以及提交的任務，我們統一維護到 MySQL 中。

• Airflow

流利說目前所有的 ETL 任務都是通過 Airflow 來調度的，并且 Airflow Task 之間的依賴性可通過 Python 來定義，這使得我們的學習以及維護成本更低。ETL 的基本流程是，我們通過數據同步工具，把數據以 T+1 的方式從 MongoDB / Redis Dump 到 S3，并且在此過程中，同樣會把表的結構同步到 S3，然后利用最新的表結構和數據，在 Hive 中建立相對應的庫和表。對于原始數據，一般數據最初以 Json 的格式保存到一個名為 raw_data 的庫中，在后續的 ETL Job 中，我們會對 raw_data 庫中的表進行清洗，計算以及轉換，最終數據以 ORC 或是 Parquet 的方式保存到 Prod 的庫中。 另外，Airflow的調度同樣承擔每天集群的構建工作，整個生命周期類似 Start -> CreateCluster -> Jobs submission --> TerminateCluster --> End.

• 數據查詢工具 - Presto

Hive 在批處理上表現不錯，但在交互式查詢上，可能一個很小的查詢就需要幾十秒甚至數分鐘； 因此對于這類查詢，我們引入了 Presto，并且其依賴的數據源仍然在 S3 上。我們對Presto 維護了自己的分支，并且開發了 Presto UI 供數據分析人員使用。流利說是一家以數據驅動產品的公司，數據分析師以及產品經理，甚至銷售每天會有若干的查詢需要立即得到結果。除了基于 Presto，它需要擁有比較友好的UI，以及考慮到人員變動，我們需要做更嚴格的權限控制。另外，對于大量編寫 SQL 的數據分析師，我們在 Sublime 上做了 Presto 插件，這使得在編寫腳本時，天然擁有了高亮顯示，字符提示等優勢，當你完成腳本編寫后，可以通過 Command + E 來執行你在 Sublime 中所選擇的查詢語句。

Execution Service 系統架構

ES 由一個 Master 和多個 Executor 節點組成，其支持單機與集群兩種運行模式。Master 節點主要負責任務狀態的管理工作，并把任務的元數據保存至數據庫，而任務的執行腳本以及第三方所依賴的包，會打包上傳到 S3（如果是單機模式，并不會上傳 S3，而是保存至本地的 Job 目錄下）。所有的 Executor 會從數據庫中不斷拉取待執行的任務，Executor 之間采用搶占式設計，這里如果某一個 Executor 搶到可以運行的任務，并會更新其任務的狀態。

• 任務提交以及執行過程

我們說到任務，其中包括了啟動 EMR 集群這樣一種特殊操作，客戶端在提交任務之前，會向 Consul 申請當前有無可用的 ES 服務，當然客戶端可以手動指定 ES 集群的地址。Consul會返回當前正常服役的 ES Master 地址，接著客戶端會向 Master 申請 Job ID，并把所要運行的相關腳本打包發送給 Master，如果是啟動集群的任務，Master只會在 Meta 中創建一個待啟動集群的一條指令；如果是 Bash / Hive / Spark 類型的任務，Master會把 Job 上傳到 S3。在 Executor 成功獲取任務之后，客戶端會向 Executor 申請獲取 Job 的日志，這是一個不斷 Pull Log 的過程，而 Executor 會啟動相應任務類型的Runner，來處理任務。

我們再以 Spark 的任務為例，來描述 Runner 的整個執行過程：Spark 與 Hive 兩種類型的任務，他們的執行過程是一樣的，而 Bash 類的任務，一般在 Executor 本機執行。在集群可用之后，客戶端可以向集群提交計算任務，而在 Runner 從 Meta 中獲取任務之后，Runner 隨后會從 S3 下載執行的任務包到本地，并且解壓。Runner 會創建提交任務的相關命令，以及任務所對應的輸出流，以及錯誤流的文件。之后會把整個目錄，以無密鑰的方式，推向 EMR 集群的 Master 節點，而后 Runner 會再次以遠程執行的方式，在 Master 節點提交 Hive 以及 Spark 任務。并把相應的輸出，以及錯誤流保存到本地，此時客戶端在不斷輪循中獲取到任務執行的實時日志。

• EMR 集群創建過程

以創建集群為例，我們來描述 Runner 的整個執行過程： 在獲取到需要啟動集群的指令后，Job 中最少需要包括集群的名稱，啟動用戶的相關權限，以及 EMR 集群的 Master / Slave 的機型，以及各自的數量。當然這里還有一些 IAM 的信息。接著，Runner 以客戶端提供的這些信息，開始構建集群，并不斷等待集群創建完成。在構建集群的過程中，EMR 集群的狀態會隨之變化，一般來講，集群狀態為 waiting 時，即表示集群可用。在集群創建完成之后，我們對 EMR 集群做了必要的配置，如 Consul 的注冊、Hive元數據的配置、以及 Yarn 集群的一些相關參數的調整，而這一系列步驟，我們稱之為 bootstrap，它由一系列 Bash 腳本構成。 之后我們重新啟動 Hive 以及 Yarn 服務。這個過程結束之后，即表示集群創建完畢，而客戶端此時可以選擇等待集群創建完畢，也可以立即響應退出。（這兩種方式分別提供給兩種場景使用，如調度系統，在創建集群時， 需要等待集群創建完成之后，再調度后面的任務）

• 集群的伸縮性擴展 - Resize

在集群創建之后，或是 Job 的運行過程中，往往會根據實際情況，對集群的節點數量甚至節點類型進行微調。比如在出現意外情況時，需要修補一段很長時間的數據，往往會提升集群的計算節點（Node Manager）數量，如 ETL 類型的 Job，那么會添加內存優化的機型作為計算節點。我們把這樣的過程稱之為對集群的 Resize 操作，整個 Resize 可在數分鐘內完成并加入集群。 而 EMR 集群本身由 Master / Core / Task 三種節點角色組成（Core 與 Task 節點的區別，是在于 Core 節點有 DataNode 進程），ES 同時支持對這三種節點的數量進行調整。 當然這樣的操作，在數量上是有限制的。

• 客戶端（CLI）命令

為了更為直觀的了解 ES，我們以 Hive Job 為例，來看一下 CLI 的命令。我們創建一個名為 hive_job 目錄，然后在該目錄下，創建一個名為 run_main.hql 的腳本文件，文件內容如：

show databases;
use temp;
show tables;

如我們想向nobody用戶所屬的集群，提交上述腳本，那么客戶端命令可以如下這樣：

bin/submit_task -d hive_job/ -t hive -u nobody -p

總結

本文簡要介紹了流利說基礎數據平臺的核心模塊，以及 Execution Service 的系統架構。目前數據平臺已趨于穩定，但隨著流利說每日的數據激增，除了集群的總體計算能力的擴展，我們后期更希望在集群的資源利用率方面做更多的和探索與實戰。

 

來自：http://mp.weixin.qq.com/s?__biz=MzI0NjIzNDkwOA==&mid=2247483686&idx=1&sn=dde5a27f70b3c8e4394cec632c219389