Hulu大資料架構與應用經驗

摘要

Hulu大資料架構部門負責人董西成為我們分享Hulu在大資料架構與應用上的實踐經驗。

Overview

上圖是hulu整體的大資料架構。我們的架構和其它架構基本都是大同小異，只在幾個地方稍有不同。

Hulu在yarn上主要跑了四種東西，批處理、互動式計算、流式處理和服務。

我們自己開發了一個互動式計算引擎Nesto，在執行服務這一塊，我們有一個工具叫Voidbox。

在這之上，我們還提供了各種各樣的工具，方便使用者使用整個叢集。比如客戶端管理工具Firework，還有統一的配置管理中心Horcrux，以及其它的工具。

除此之外，在上圖右邊可以看到我們用了兩個叢集管理工具，Cloudera Manager和Hawkeye。

我們有4個clusters、3個datacenters，這些基礎設施都是被北京和美國的所有團隊共享。目前在大資料基礎架構這一塊大約有十個人在負責整個叢集的運維優化和開發。

作為一個大資料基礎運維團隊，有一部分工作就是運維。運維必然需要一個強大的管理和監控系統，Hawkeye主要是幫助使用者更好地瞭解資料或應用程式的變化，主要分為三部分。

第一個是報表。我們會給各個團隊週期性地傳送一些報表，這些報表裡包括了冷熱資料的分佈、小檔案的分佈以及資料增長情況。讓各團隊瞭解資料的變化。

第二個是各種報警。有服務級別的報警、資料增長的報警、大的應用程式報警、服務狀態的報警等等。這些報警資訊有的會傳送給資料團隊，有的會傳送給基礎設施團隊，以瞭解整個叢集的運營情況。

我們還有自動化的程式，自動根據磁碟或者機器的狀況產生任務，把它傳送給常駐機房的團隊，幫助我們進行修復。

Firework整合了hulu內部所有的Hadoop位置資訊和版本資訊。如果想用Firework訪問不同的叢集，只需要用相應的命令指令要訪問哪一個機房，它會自動從中央倉庫上把對應的版本快取在本地，然後通過應用對應的客戶端來訪問Central。

目前Spark已經升級到了2.1版本，我們在內部版本里打了超過30個比較大的patches。

sparkstreaming和kafka結合的時候，任何的風吹草動都會使spark streaming出現問題，因為它在穩定性這一塊非常差，現在開源社群還沒有解決這個問題。

每一個spark會有很多executors，有時候客戶需要除錯各個executors。我們會採用一些啟發式的演算法，動態地探測各個executors的執行情況並對出現問題的executors採取一些措施。

我們有high cpu的applications，針對這樣的應用程式，我們允許使用者來定製每個節點可以跑的executors個數。

以上的例子都是我們對spark內部做的一些調整和優化，來幫助使用者提高spark的穩定性和效能。

現在出現了越來越多的OLAP引擎，OLAP通常會分為三層。

如上圖所示，最底層就是各種各樣的OLAP引擎，有Impala、Presto、Nesto以及Druid。

上面是基於OLAP引擎開發的應用，比如多維分析、時間序列分析、Cohort的分析以及使用者流通率分析。

最頂層就是各種各樣的視覺化系統，Tableau和Hulu BI Portal。

OLAP引擎中比較好用的就要算Presto了。Hulu在Presto裡面啟用了Resource group特性，可以把OLAP的資源分成若干個資源池，給不同的組來使用。

ElasticPresto就是可伸縮的Presto，根據查詢的負載，動態地增加或者減少計算資源。在這一塊yarn為我們提供了很好的作業系統。把Presto執行到yarn上，可以簡化部署，滾動升級變得非常容易，並可以根據負載的情況不斷彈性伸縮可用的計算資源。

Hulu自己開發了一個計算引擎Nesto，它主要是解決巢狀式資料查詢的問題。

Hadoop Multi-DC

Challenge

Components

總結

構建基本的工具來更好地為使用者服務，為使用者的特殊案例定製開源專案，為特殊場景構建新系統。