作者 jopen 2013-12-18 20:33:58
2011 年小規(guī)模試水
這一階段的主要工作是建立了一個小的集群，并導(dǎo)入了少量用戶進(jìn)行測試。為了滿足用戶的需求，我們還調(diào)研了任務(wù)調(diào)度系統(tǒng)和數(shù)據(jù)交換系統(tǒng)。
我們使用的版本是當(dāng)時最新的穩(wěn)定版，Hadoop 0.20.203 和 Hive 0.7.1。此后經(jīng)歷過多次升級與 Bugfix?，F(xiàn)在使用的是 Hadoop 1.0.3+ 自有 Patch 與 Hive 0.9+ 自有 Patch?？紤]到人手不足及自己的 Patch 不多等問題，我們采取的策略是，以 Apache 的穩(wěn)定版本為基礎(chǔ)，盡量將自己的修改提交到社區(qū)，并且應(yīng)用這些還沒有被接受的 Patch。因?yàn)楝F(xiàn)在 Hadoop 生態(tài)圈中還沒有出現(xiàn)一個類似 Red Hat 地位的公司，我們也不希望被鎖定在某個特定的發(fā)行版上，更重要的是 Apache Jira 與 Maillist 依然是獲取 Hadoop 相關(guān)知識、解決 Hadoop 相關(guān)問題最好的地方（Cloudera 為 CDH 建立了私有的 Jira，但人氣不足），所以沒有采用 Cloudera 或者 Hortonworks 的發(fā)行版。目前我們正對 Hadoop 2.1.0 進(jìn)行測試。
在前期，我們團(tuán)隊(duì)的主要工作是 ops+solution，現(xiàn)在 DBA 已接手了很大一部分 ops 的工作，我們正在轉(zhuǎn)向 solution+dev 的工作。
我們使用 Puppet 管理整個集群，用 Ganglia 和 Zabbix 做監(jiān)控與報警。
集群搭建好，用戶便開始使用，面臨的第一個問題是需要任務(wù)級別的調(diào)度、報警和工作流服務(wù)。當(dāng)用戶的任務(wù)出現(xiàn)異常或其他情況時，需要以郵件或者短 信的方式通知用戶。而且用戶的任務(wù)間可能有復(fù)雜的依賴關(guān)系，需要工作流系統(tǒng)來描述任務(wù)間的依賴關(guān)系。我們首先將目光投向開源項(xiàng)目 Apache Oozie。Oozie 是 Apache 開發(fā)的工作流引擎，以 XML 的方式描述任務(wù)及任務(wù)間的依賴，功能強(qiáng)大。但在測試后，發(fā)現(xiàn) Oozie 并不是一個很好的選擇。
Oozie 采用 XML 作為任務(wù)的配置，特別是對于 MapReduce Job，需要在 XML 里配置 Map、Reduce 類、輸入輸出路徑、Distributed Cache 和各種參數(shù)。在運(yùn)行時，先由 Oozie 提交一個 Map only 的 Job，在這個 Job 的 Map 里，再拼裝用戶的 Job，通過 JobClient 提交給 JobTracker。相對于 Java 編寫的 Job Runner，這種 XML 的方式缺乏靈活性，而且難以調(diào)試和維護(hù)。先提交一個 Job，再由這個 Job 提交真正 Job 的設(shè)計，我個人認(rèn)為相當(dāng)不優(yōu)雅。
另一個問題在于，公司內(nèi)的很多用戶，希望調(diào)度系統(tǒng)不僅可以調(diào)度 Hadoop 任務(wù)，也可以調(diào)度單機(jī)任務(wù)，甚至 Spring 容器里的任務(wù)，而 Oozie 并不支持 Hadoop 集群之外的任務(wù)。
所以我們轉(zhuǎn)而自行開發(fā)調(diào)度系統(tǒng) Taurus（https://github.com/dianping/taurus）。Taurus 是一個調(diào)度系統(tǒng)， 通過時間依賴與任務(wù)依賴，觸發(fā)任務(wù)的執(zhí)行，并通過任務(wù)間的依賴管理將任務(wù)組織成工作流；支持 Hadoop/Hive Job、Spring 容器里的任務(wù)及一般性任務(wù)的調(diào)度/監(jiān)控。
圖 1 Taurus 的結(jié)構(gòu)圖
圖 1 是 Taurus 的結(jié)構(gòu)圖，Taurus 的主節(jié)點(diǎn)稱為 Master，Web 界面與 Master 在一起。用戶在 Web 界面上創(chuàng)建任務(wù)后，寫入 MySQL 做持久化存儲，當(dāng) Master 判斷任務(wù)觸發(fā)的條件滿足時，則從 MySQL 中讀出任務(wù)信息，寫入 ZooKeeper；Agent 部署在用戶的機(jī)器上，觀察 ZooKeeper 上的變化，獲得任務(wù)信息，啟動任務(wù)。Taurus 在 2012 年中上線。
另一個迫切需求是數(shù)據(jù)交換系統(tǒng)。用戶需要將 MySQL、MongoDB 甚至文件中的數(shù)據(jù)導(dǎo)入到 HDFS 上進(jìn)行分析。另外一些用戶要將 HDFS 中生成的數(shù)據(jù)再導(dǎo)入 MySQL 作為報表展現(xiàn)或者供在線系統(tǒng)使用。
我們首先調(diào)研了 Apache Sqoop，它主要用于 HDFS 與關(guān)系型數(shù)據(jù)庫間的數(shù)據(jù)傳輸。經(jīng)過測試，發(fā)現(xiàn) Sqoop 的主要問題在于數(shù)據(jù)的一致性。Sqoop 采用 MapReduce Job 進(jìn)行數(shù)據(jù)庫的插入，而 Hadoop 自帶 Task 的重試機(jī)制，當(dāng)一個 Task 失敗，會自動重啟這個 Task。這是一個很好的特性，大大提高了 Hadoop 的容錯能力，但對于數(shù)據(jù)庫插入操作，卻帶來了麻煩。
考慮有 10 個 Map，每個 Map 插入十分之一的數(shù)據(jù)，如果有一個 Map 插入到一半時 failed，再通過 Task rerun 執(zhí)行成功，那么 fail 那次插入的一半數(shù)據(jù)就重復(fù)了，這在很多應(yīng)用場景下是不可接受的。而且 Sqoop 不支持 MongoDB 和 MySQL 之間的數(shù)據(jù)交換，但公司內(nèi)卻有這需求。最終我們參考淘寶的 DataX，于 2011 年底開始設(shè)計并開發(fā)了 Wormhole。之所以采用自行開發(fā)而沒有直接使用 DataX 主要出于維護(hù)上的考慮，而且 DataX 并未形成良好的社區(qū)。
2012 年大規(guī)模應(yīng)用
2012 年，出于成本、穩(wěn)定性與源碼級別維護(hù)性的考慮，公司的 Data Warehouse 系統(tǒng)由商業(yè)的 OLAP 數(shù)據(jù)庫轉(zhuǎn)向 Hadoop/Hive。2012 年初，Wormhole 開發(fā)完成；之后 Taurus 也上線部署；大量應(yīng)用接入到 Hadoop 平臺上。為了保證數(shù)據(jù)的安全性，我們開啟了 Hadoop 的 Security 特性。為了提高數(shù)據(jù)的壓縮率，我們將默認(rèn)存儲格式替換為 RCFile，并開發(fā)了 Hive Web 供公司內(nèi)部使用。2012 年底，我們開始調(diào)研 HBase。
圖 2 Wormhole 的結(jié)構(gòu)圖
Wormhole（https://github.com /dianping/wormhole） 是一個結(jié)構(gòu)化數(shù)據(jù)傳輸工具，用于解決多種異構(gòu)數(shù)據(jù)源間的數(shù)據(jù)交換，具有高效、易擴(kuò)展等特點(diǎn)，由 Reader、Storage、Writer 三部分組成（如圖 2 所示）。Reader 是個線程池，可以啟動多個 Reader 線程從數(shù)據(jù)源讀出數(shù)據(jù)，寫入 Storage。Writer 也是線程池，多線程的 Writer 不僅用于提高吞吐量，還用于寫入多個目的地。Storage 是個雙緩沖隊(duì)列，如果使用一讀多寫，則每個目的地都擁有自己的 Storage。
當(dāng)寫入過程出錯時，將自動執(zhí)行用戶配置的 Rollback 方法，消除錯誤狀態(tài)，從而保證數(shù)據(jù)的完整性。通過開發(fā)不同的 Reader 和 Writer 插件，如 MySQL、MongoDB、Hive、HDFS、SFTP 和 Salesforce，我們就可以支持多種數(shù)據(jù)源間的數(shù)據(jù)交換。Wormhole 在大眾點(diǎn)評內(nèi)部得到了大量使用，獲得了廣泛好評。
隨著越來越多的部門接入 Hadoop，特別是數(shù)據(jù)倉庫（DW）部門接入后，我們對數(shù)據(jù)的安全性需求變得更為迫切。而 Hadoop 默認(rèn)采用 Simple 的用戶認(rèn)證模式，具有很大的安全風(fēng)險。
默認(rèn)的 Simple 認(rèn)證模式，會在 Hadoop 的客戶端執(zhí)行 whoami 命令，并以 whoami 命令的形式返回結(jié)果，作為訪問 Hadoop 的用戶名（準(zhǔn)確地說，是以 whoami 的形式返回結(jié)果，作為 Hadoop RPC 的 userGroupInformation 參數(shù)發(fā)起 RPC Call）。這樣會產(chǎn)生以下三個問題。
（1）User Authentication。假設(shè)有賬號A和賬號B，分別在 Host1 和 Host2 上。如果惡意用戶在 Host2 上建立了一個同名的賬號A，那么通過 RPC Call 獲得的 UGI 就和真正的賬號A相同，偽造了賬號A的身份。用這種方式，惡意用戶可以訪問/修改其他用戶的數(shù)據(jù)。
（2）Service Authentication。Hadoop 采用主從結(jié)構(gòu)，如 NameNode-DataNode、JobTracker-Tasktracker。Slave 節(jié)點(diǎn)啟動時，主動連接 Master 節(jié)點(diǎn)。Slave 到 Master 的連接過程，沒有經(jīng)過認(rèn)證。假設(shè)某個用戶在某臺非 Hadoop 機(jī)器上，錯誤地啟動了一個 Slave 實(shí)例，那么也會連接到 Master；Master 會為它分配任務(wù)/數(shù)據(jù)，可能會影響任務(wù)的執(zhí)行。
（3）可管理性。任何可以連到 Master 節(jié)點(diǎn)的機(jī)器，都可以請求集群的服務(wù)，訪問 HDFS，運(yùn)行 Hadoop Job，無法對用戶的訪問進(jìn)行控制。
從 Hadoop 0.20.203 開始，社區(qū)開發(fā)了 Hadoop Security，實(shí)現(xiàn)了基于 Kerberos 的 Authentication。任何訪問 Hadoop 的用戶，都必須持有 KDC（Key Distribution Center）發(fā)布的 Ticket 或者 Keytab File（準(zhǔn)確地說，是 Ticket Granting Ticket），才能調(diào)用 Hadoop 的服務(wù)。用戶通過密碼，獲取 Ticket，Hadoop Client 在發(fā)起 RPC Call 時讀取 Ticket 的內(nèi)容，使用其中的 Principal 字段，作為 RPC Call 的 UserGroupInformation 參數(shù)，解決了問題（1）。Hadoop 的任何 Daemon 進(jìn)程在啟動時，都需要使用 Keytab File 做 Authentication。因?yàn)?Keytab File 的分發(fā)是由管理員控制的，所以解決了問題（2）。最后，不論是 Ticket，還是 Keytab File，都由 KDC 管理/生成，而 KDC 由管理員控制，解決了問題（3）。
在使用了 Hadoop Security 之后，只有通過了身份認(rèn)證的用戶才能訪問 Hadoop，大大增強(qiáng)了數(shù)據(jù)的安全性和集群的可管理性。之后我們基于 Hadoop Secuirty，與 DW 部門一起開發(fā)了 ACL 系統(tǒng)，用戶可以自助申請 Hive 上表的權(quán)限。在申請通過審批工作流之后，就可以訪問了。
JDBC 是一種很常用的數(shù)據(jù)訪問接口，Hive 自帶了 Hive Server，可以接受 Hive JDBC Driver 的連接。實(shí)際上，Hive JDBC Driver 是將 JDBC 的請求轉(zhuǎn)化為 Thrift Call 發(fā)給 Hive Server，再由 Hive Server 將 Job 啟動起來。但 Hive 自帶的 Hive Server 并不支持 Security，默認(rèn)會使用啟動 Hive Server 的用戶作為 Job 的 owner 提交到 Hadoop，造成安全漏洞。因此，我們自己開發(fā)了 Hive Server 的 Security，解決了這個問題。
但在 Hive Server 的使用過程中，我們發(fā)現(xiàn) Hive Server 并不穩(wěn)定，而且存在內(nèi)存泄漏。更嚴(yán)重的是由于 Hive Server 自身的設(shè)計缺陷，不能很好地應(yīng)對并發(fā)訪問的情況，所以我們現(xiàn)在并不推薦使用 Hive JDBC 的訪問方式。
社區(qū)后來重新開發(fā)了 Hive Server 2，解決了并發(fā)的問題，我們正在對 Hive Server 2 進(jìn)行測試。
有一些同事，特別是 BI 的同事，不熟悉以 CLI 的方式使用 Hive，希望 Hive 可以有個 GUI 界面。在上線 Hive Server 之后，我們調(diào)研了開源的 SQL GUI Client——Squirrel，可惜使用 Squirrel 訪問 Hive 存在一些問題。
基于以上考慮，我們自己開發(fā)了 Hive Web，讓用戶通過瀏覽器就可以使用 Hive。Hive Web 最初是作為大眾點(diǎn)評第一屆 Hackathon 的一個項(xiàng)目被開發(fā)出來的，技術(shù)上很簡單，但獲得了良好的反響?，F(xiàn)在 Hive Web 已經(jīng)發(fā)展成了一個 RESTful 的 Service，稱為 Polestar（https://github.com/dianping /polestar）。
圖 3 Polestar 的結(jié)構(gòu)
圖 3 是 Polestar 的結(jié)構(gòu)圖。目前 Hive Web 只是一個 GWT 的前端，通過 HAProxy 將 RESTfull Call 分發(fā)到執(zhí)行引擎 Worker 執(zhí)行。Worker 將自身的狀態(tài)保存在 MySQL，將數(shù)據(jù)保存在 HDFS，并使用 JSON 返回數(shù)據(jù)或數(shù)據(jù)在 HDFS 的路徑。我們還將 Shark 與 Hive Web 集成到了一起，用戶可以選擇以 Hive 或者 Shark 執(zhí)行 Query。
一開始我們使用 LZO 作為存儲格式，使大文件可以在 MapReduce 處理中被切分，提高并行度。但 LZO 的壓縮比不夠高，按照我們的測試，Lzo 壓縮的文件，壓縮比基本只有 Gz 的一半。
經(jīng)過調(diào)研，我們將默認(rèn)存儲格式替換成 RCFile，在 RCFile 內(nèi)部再使用 Gz 壓縮，這樣既可保持文件可切分的特性，同時又可獲得 Gz 的高壓縮比，而且因?yàn)?RCFile 是一種列存儲的格式，所以對于不需要的字段就不用從I/O讀入，從而提高了性能。圖 4 顯示了將 Nginx 數(shù)據(jù)分別用 Lzo、RCFile+Gz、RCFfile+Lzo 壓縮，再不斷增加 Select 的 Column 數(shù)，在 Hive 上消耗的 CPU 時間（越小越好）。
圖 4 幾種壓縮方式在 Hive 上消耗的 CPU 時間
但 RCFile 的讀寫需要知道數(shù)據(jù)的 Schema，而且需要熟悉 Hive 的 Ser/De 接口。為了讓 MapReduce Job 能方便地訪問 RCFile，我們使用了 Apache Hcatalog。
社區(qū)又針對 Hive 0.11 開發(fā)了 ORCFile，我們正在對 ORCFile 進(jìn)行測試。
隨著 Facebook、淘寶等大公司成功地在生產(chǎn)環(huán)境應(yīng)用 HBase，HBase 越來越受到大家的關(guān)注，我們也開始對 HBase 進(jìn)行測試。通過測試我們發(fā)現(xiàn) HBase 非常依賴參數(shù)的調(diào)整，在默認(rèn)配置下，HBase 能獲得很好的寫性能，但讀性能不是特別出色。通過調(diào)整 HBase 的參數(shù)，在 5 臺機(jī)器的 HBase 集群上，對于 1KB 大小的數(shù)據(jù)，也能獲得 5 萬左右的 TPS。在 HBase 0.94 之后，HBase 已經(jīng)優(yōu)化了默認(rèn)配置。
原來我們希望 HBase 集群與主 Hadoop 集群共享 HDFS，這樣可以簡化運(yùn)維成本。但在測試中，發(fā)現(xiàn)即使主 Hadoop 集群上沒有任何負(fù)載，HBase 的性能也很糟糕。我們認(rèn)為，這是由于大量數(shù)據(jù)屬于遠(yuǎn)程讀寫所引起的。所以我們現(xiàn)在的 HBase 集群都是單獨(dú)部署的。并且通過封裝 HBase Client 與 Master-Slave Replication，使用 2 套 HBase 集群實(shí)現(xiàn)了 HBase 的 HA，用來支撐線上業(yè)務(wù)。
2013 年持續(xù)演進(jìn)
在建立了公司主要的大數(shù)據(jù)架構(gòu)后，我們上線了 HBase 的應(yīng)用，并引入 Spark/Shark 以提高 Ad Hoc Query 的執(zhí)行時間，并調(diào)研分布式日志收集系統(tǒng)，來取代手工腳本做日志導(dǎo)入。
現(xiàn)在 HBase 上線的應(yīng)用主要有 OpenAPI 和手機(jī)團(tuán)購?fù)扑]。OpenAPI 類似于 HBase 的典型應(yīng)用 Click Stream，將開放平臺開發(fā)者的訪問日志記錄在 HBase 中，通過 Scan 操作，查詢開發(fā)者在一段時間內(nèi)的 Log，但這一功能目前還沒有對外開放。手機(jī)團(tuán)購?fù)扑]是一個典型的 KVDB 用法，將用戶的歷史訪問行為記錄在 HBase 中，當(dāng)用戶使用手機(jī)端訪問時，從 HBase 獲得用戶的歷史行為數(shù)據(jù)，做團(tuán)購?fù)扑]。
當(dāng) Hive 大規(guī)模使用之后，特別是原來使用 OLAP 數(shù)據(jù)庫的 BI 部門的同事轉(zhuǎn)入后，一個越來越大的抱怨就是 Hive 的執(zhí)行速度。對于離線的 ETL 任務(wù)，Hadoop/Hive 是一個良好的選擇，但動輒分鐘級的響應(yīng)時間，使得 Ad Hoc Query 的用戶難以忍受。為了提高 Ad Hoc Query 的響應(yīng)時間，我們將目光轉(zhuǎn)向了 Spark/Shark。
Spark 是美國加州大學(xué)伯克利分校 AMPLab 開發(fā)的分布式計算系統(tǒng)，基于 RDD（Resilient Distributed Dataset），主要使用內(nèi)存而不是硬盤，可以很好地支持迭代計算。因?yàn)槭且粋€基于 Memory 的系統(tǒng)，所以在數(shù)據(jù)量能夠放進(jìn) Memory 的情況下，能夠大幅縮短響應(yīng)時間。Shark 類似于 Hive，將 SQL 解析為 Spark 任務(wù)，并且 Shark 復(fù)用了大量 Hive 的已有代碼。
在 Shark 接入之后，大大降低了 Ad Hoc Query 的執(zhí)行時間。比如 SQL 語句：
select host, count(1) from HIPPOLOG where dt = '2013-08-28' group by host order by host desc;
在 Hive 執(zhí)行的時間是 352 秒，而 Shark 只需要 60~70 秒。但對于 Memory 中放不下的大數(shù)據(jù)量，Shark 反而會變慢。
目前用戶需要在 Hive Web 中選擇使用 Hive 還是 Shark，未來我們會在 Hive 中添加 Semantic-AnalysisHook，通過解析用戶提交的 Query，根據(jù)數(shù)據(jù)量的大小，自動選擇 Hive 或者 Shark。另外，因?yàn)槲覀兡壳笆褂玫氖?Hadoop 1，不支持 YARN，所以我們單獨(dú)部署了一個小集群用于 Shark 任務(wù)的執(zhí)行。
Wormhole 解決了結(jié)構(gòu)化數(shù)據(jù)的交換問題，但對于非結(jié)構(gòu)化數(shù)據(jù)，例如各種日志，并不適合。我們一直采用腳本或用戶程序直接寫 HDFS 的方式將用戶的 Log 導(dǎo)入 HDFS。缺點(diǎn)是，需要一定的開發(fā)和維護(hù)成本。我們希望使用 Apache Flume 解決這個問題，但在測試了 Flume 之后，發(fā)現(xiàn)了 Flume 存在一些問題：Flume 不能保證端到端的數(shù)據(jù)完整性，數(shù)據(jù)可能丟失，也可能重復(fù)。
例如，F(xiàn)lume 的 HDFSsink 在數(shù)據(jù)寫入/讀出 Channel 時，都有 Transcation 的保證。當(dāng) Transaction 失敗時，會回滾，然后重試。但由于 HDFS 不可修改文件的內(nèi)容，假設(shè)有 1 萬行數(shù)據(jù)要寫入 HDFS，而在寫入 5000 行時，網(wǎng)絡(luò)出現(xiàn)問題導(dǎo)致寫入失敗，Transaction 回滾，然后重寫這 10000 條記錄成功，就會導(dǎo)致第一次寫入的 5000 行重復(fù)。我們試圖修正 Flume 的這些問題，但由于這些問題是設(shè)計上的，并不能通過簡單的 Bugfix 來解決，所以我們轉(zhuǎn)而開發(fā) Blackhole 系統(tǒng)將數(shù)據(jù)流導(dǎo)入 HDFS。目前 Blackhole 正在開發(fā)中。
總結(jié)
圖 5 是各系統(tǒng)總體結(jié)構(gòu)圖，深藍(lán)部分為自行開發(fā)的系統(tǒng)。
圖 5 大眾點(diǎn)評各系統(tǒng)總體結(jié)構(gòu)圖
在這 2 年多的 Hadoop 實(shí)踐中，我們得到了一些寶貴經(jīng)驗(yàn)。
作者房明，大眾點(diǎn)評網(wǎng)平臺架構(gòu)組高級工程師，Apache Contributor。2011 年加入點(diǎn)評網(wǎng)，目前負(fù)責(zé)大數(shù)據(jù)處理的基礎(chǔ)架構(gòu)及所有 Hadoop 相關(guān)技術(shù)的研發(fā)。
聯(lián)系客服
