《程序員》雜志2014年10月刊《凌云》云計(jì)算大數(shù)據(jù)阿里云ODPShadoop 摘要：ODPS是分布式的海量數(shù)據(jù)處理平臺，提供了豐富的數(shù)據(jù)處理功能和靈活的編程框架。本文從ODPS面臨的挑戰(zhàn)、技術(shù)架構(gòu)、Hadoop遷移到ODPS、應(yīng)用實(shí)踐注意點(diǎn)等方面帶領(lǐng)我們初步了解了ODPS的現(xiàn)狀與前景。

初識ODPS

ODPS是分布式的海量數(shù)據(jù)處理平臺，提供了豐富的數(shù)據(jù)處理功能和靈活的編程框架，主要的功能組件有如下幾個(gè)。

• Tunnel服務(wù)：數(shù)據(jù)進(jìn)出ODPS的唯一通道，提供高并發(fā)、高吞吐量的數(shù)據(jù)上傳和下載服務(wù)。
• SQL：基于SQL92并進(jìn)行了本地化擴(kuò)展，可用于構(gòu)建大規(guī)模數(shù)據(jù)倉庫和企業(yè)BI系統(tǒng)，是應(yīng)用最為廣泛的一類服務(wù)。
• DAG編程模型：類似Hadoop MapReduce，相對SQL更加靈活，但需要一定的開發(fā)工作量，適用于特定的業(yè)務(wù)場景或者自主開發(fā)新算法等。
• Graph編程模型：用于大數(shù)據(jù)量的圖計(jì)算功能開發(fā)，如計(jì)算PageRank。
• XLIB：提供諸如SVD分解、邏輯回歸、隨機(jī)森林等分布式算法，可用于機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘等場景。
• 安全：管控ODPS中的所有數(shù)據(jù)對象，所有的訪問都必須經(jīng)過鑒權(quán)，提供了ACL、Policy等靈活強(qiáng)大的管理方式。

ODPS采用抽象的作業(yè)處理框架將不同場景的各種計(jì)算任務(wù)統(tǒng)一在同一個(gè)平臺之上，共享安全、存儲、數(shù)據(jù)管理和資源調(diào)度，為來自不同用戶需求的各種數(shù)據(jù)處理任務(wù)提供統(tǒng)一的編程接口和界面。

和阿里云的其他云計(jì)算服務(wù)一樣，ODPS也是采用HTTP RESTful服務(wù)，并提供Java SDK、命令行工具（Command Line Tool，CLT）和上傳下載工具dship，以及阿里云官網(wǎng)提供統(tǒng)一的管理控制臺界面。在阿里內(nèi)部，有多個(gè)團(tuán)隊(duì)基于ODPS構(gòu)建交互界面的Web集成開發(fā)環(huán)境，提供數(shù)據(jù)采集、加工、處理分析、運(yùn)營和維護(hù)的一條龍服務(wù)。基于ODPS進(jìn)行應(yīng)用開發(fā)，最直接的是使用CLT以及dship等工具。如果不能滿足需要，也可以進(jìn)一步考慮使用ODPS SDK或RESTful API等進(jìn)行定制開發(fā)，如圖1所示。

圖1? ODPS應(yīng)用開發(fā)模式

如果你的業(yè)務(wù)發(fā)展需要一個(gè)足夠強(qiáng)大、能開箱即用的大數(shù)據(jù)處理平臺，并且不想花費(fèi)太多精力去關(guān)注這一切如何實(shí)現(xiàn)與運(yùn)維，那么ODPS是一個(gè)非常理想的選擇。

規(guī)模的挑戰(zhàn)

在DT時(shí)代，數(shù)據(jù)是寶貴的生產(chǎn)資料，但不斷擴(kuò)大的數(shù)據(jù)規(guī)模給ODPS帶來了極大的挑戰(zhàn)。在阿里內(nèi)部就曾直面這種情況：在可以預(yù)見的時(shí)間內(nèi)，單個(gè)集群的規(guī)模無法再容納所有的數(shù)據(jù)。

解決方案是擴(kuò)大單集群的規(guī)模，同時(shí)讓應(yīng)用系統(tǒng)可以管理多個(gè)集群。在這個(gè)背景下，ODPS作為一個(gè)海量數(shù)據(jù)的處理平臺，結(jié)合5K項(xiàng)目開發(fā)了多集群管理的功能，使得數(shù)據(jù)處理的規(guī)模跨上了一個(gè)新的臺階。當(dāng)單個(gè)計(jì)算集群的存儲或計(jì)算容量不足時(shí)，將數(shù)據(jù)重新分布到新的集群上。更重要的一點(diǎn)是，這種跨多個(gè)集群的能力，對上層應(yīng)用是透明的，用戶在運(yùn)行SQL或者Graph模型時(shí)，不必了解數(shù)據(jù)是分布在哪個(gè)物理集群上，如圖2所示。

圖2? ODPS的跨集群能力

網(wǎng)站日志分析

這里，我們將基于最常見的網(wǎng)站日志分析這一應(yīng)用場景，實(shí)踐如何通過ODPS來構(gòu)建企業(yè)數(shù)據(jù)倉庫，包括數(shù)據(jù)的導(dǎo)入導(dǎo)出以及清洗轉(zhuǎn)換。其ETL過程與基于傳統(tǒng)數(shù)據(jù)庫的解決方法并不完全一致，在數(shù)據(jù)傳輸環(huán)節(jié)并沒有太多的清洗轉(zhuǎn)換，這項(xiàng)工作是在數(shù)據(jù)加載到ODPS后，用SQL來完成的。在數(shù)據(jù)加載到ODPS后，可以充分利用平臺的水平擴(kuò)展能力，處理的數(shù)據(jù)量可以輕松地?cái)U(kuò)展到PB級別，而且作為一個(gè)統(tǒng)一的平臺，除構(gòu)建數(shù)據(jù)倉庫外，在ODPS中利用內(nèi)置的功能即可進(jìn)行數(shù)據(jù)挖掘和建模等工作。在實(shí)際工作中，數(shù)據(jù)采集、數(shù)倉構(gòu)建和數(shù)據(jù)挖掘等都是由不同的團(tuán)隊(duì)來完成的，針對這一情況，ODPS中提供了完善的安全管理功能，可以精確地控制每個(gè)人可以訪問到的數(shù)據(jù)內(nèi)容（下例中為突出主要的過程，忽略了用戶的授權(quán)管理）。

數(shù)據(jù)來源于網(wǎng)站酷殼（CoolShell.cn）上的HTTP訪問日志數(shù)據(jù)（access.log），格式如下：

一個(gè)典型的企業(yè)數(shù)據(jù)倉庫通常包含數(shù)據(jù)采集、數(shù)據(jù)加工和存儲、數(shù)據(jù)展現(xiàn)等幾個(gè)過程，如圖3所示。

圖3? 數(shù)據(jù)倉庫主要過程

數(shù)據(jù)采集

真實(shí)的網(wǎng)站日志數(shù)據(jù)中不可避免地會存在很多臟數(shù)據(jù)，可以先通過腳本對源數(shù)據(jù)做簡單的處理解析，去掉無意義的信息，例如第二個(gè)字段“-”。在數(shù)據(jù)量比較大的情況下，單機(jī)處理可能成為瓶頸。這時(shí)可以將原始的數(shù)據(jù)先上傳到ODPS，充分利用分布式處理的優(yōu)勢，通過ODPS SQL對數(shù)據(jù)進(jìn)行轉(zhuǎn)換。

在ODPS中，大部分的數(shù)據(jù)都是以結(jié)構(gòu)化的表形式存在的，因此第一步要創(chuàng)建ODS層源數(shù)據(jù)表。由于數(shù)據(jù)是每天導(dǎo)入ODPS中，所以采取分區(qū)表，以日期字符串作為分區(qū)，在ODPS CLT中執(zhí)行SQL如下：

假設(shè)當(dāng)前數(shù)據(jù)是20140301這一天的，添加分區(qū)如下：

解析后的數(shù)據(jù)文件在/home/admin/data/20140301/output.log下，通過dship命令導(dǎo)入ODPS中，如下：

數(shù)據(jù)加工和存儲

在ods_log_tracker表中，request字段包含三個(gè)信息：HTTP方法、請求路徑和HTTP協(xié)議版本，如“GET /articles/4914.html HTTP/1.1”。在后續(xù)處理中，會統(tǒng)計(jì)方法為GET的請求總數(shù)，并對請求路徑進(jìn)行分析，因而可以把原始表的request字段拆解成三個(gè)字段method、url和protocol。這里使用的是ODPS SQL內(nèi)置的正則函數(shù)解析的字符串并生成表dw_log_parser：

與傳統(tǒng)的RDBMS相比，ODPS SQL面向大數(shù)據(jù)OLAP應(yīng)用，沒有事務(wù)，也沒有提供update和delete功能。在寫結(jié)果表時(shí)，盡量采用INSERT OVERWRITE到某個(gè)分區(qū)來保證數(shù)據(jù)一致性（如果用戶寫錯(cuò)數(shù)據(jù)，只需要重寫該分區(qū)，不會污染整張表）。如果采用INSERT INTO某張表的方式，那么在作業(yè)因各種原因出現(xiàn)中斷時(shí)，不方便確定斷點(diǎn)并重新調(diào)度運(yùn)行。

ODPS SQL提供了豐富的內(nèi)置函數(shù)，極大方便了應(yīng)用開發(fā)者。對于某些功能，如果SQL無法完成的話，那么可以通過實(shí)現(xiàn)UDF（用戶自定義函數(shù)）來解決。例如希望將ip字段轉(zhuǎn)化成數(shù)字形式，從而和另一張表關(guān)聯(lián)查詢，可以實(shí)現(xiàn)UDF，如下：

編譯生成JAR包udf_ip2num.jar，將它作為資源上傳到ODPS，然后創(chuàng)建函數(shù)并測試，如下：

表dual（需要用戶自己創(chuàng)建）類似于Oracle中的dual表，包含一列和一行，經(jīng)常用于查詢一些偽列值（pseudo column），是SQL開發(fā)調(diào)試的利器。

對于較復(fù)雜的數(shù)據(jù)分析需求，還可以通過ODPS DAG（類似MapReduce）編程模型來實(shí)現(xiàn)。篇幅限制，這里不一一介紹。

圖4? PV/UV展示結(jié)果

數(shù)據(jù)展現(xiàn)

應(yīng)用數(shù)據(jù)集市往往是面向業(yè)務(wù)需求對數(shù)據(jù)倉庫表進(jìn)行查詢分析，例如統(tǒng)計(jì)基于終端設(shè)備信息的PV和UV，生成結(jié)果表adm_user_measures。R是一款開源的、功能強(qiáng)大的數(shù)據(jù)分析工具。通過R來繪圖，展示結(jié)果報(bào)表可以有兩種方式：一是通過dship命令將數(shù)據(jù)導(dǎo)出到本地，再通過R展現(xiàn)結(jié)果；二是在R環(huán)境中安裝RODPS Package，直接在R中讀取表中的數(shù)據(jù)并展現(xiàn)。在RStudio中，基于小樣本數(shù)據(jù)統(tǒng)計(jì)的展現(xiàn)結(jié)果如圖4所示。

遷移到ODPS

Hadoop作為開源的大數(shù)據(jù)處理平臺，已得到了廣泛應(yīng)用。在使用Hadoop集群的用戶，可以比較輕松地遷移到ODPS中，因?yàn)镺DPS?SQL與Hive?SQL語法基本一致，而MapReduce作業(yè)可以遷移到更加靈活的DAG的執(zhí)行模型。對于數(shù)據(jù)的遷移，可以通過ODPS?Tunnel來完成。

數(shù)據(jù)通道服務(wù)ODPS Tunnel是ODPS與外部交互的統(tǒng)一數(shù)據(jù)通道，能提供高吞吐量的服務(wù)并且能夠水平進(jìn)行服務(wù)能力的擴(kuò)展。Tunnel服務(wù)的SDK集成于ODPS SDK中。實(shí)際上，dship也是調(diào)用SDK實(shí)現(xiàn)的客戶端工具，支持本地文件的導(dǎo)入導(dǎo)出。我們鼓勵用戶根據(jù)自己的場景需求，開發(fā)自己的工具，例如基于SDK開發(fā)對接其他數(shù)據(jù)源（如RDBMS）的工具。

把海量數(shù)據(jù)從Hadoop集群遷移到ODPS的基本思路是：實(shí)現(xiàn)一個(gè)Map Only程序，在Hadoop的Mapper中讀取Hadoop源數(shù)據(jù)，調(diào)用ODPS SDK寫到ODPS中。執(zhí)行邏輯大致如圖5所示。

Hadoop MapReduce程序的執(zhí)行邏輯主要包含兩階段：一是在客戶端本地執(zhí)行，如參數(shù)解析和設(shè)置、預(yù)處理等，這在main函數(shù)完成；二是在集群上執(zhí)行Mapper，多臺Worker分布式執(zhí)行map代碼。在Mapper執(zhí)行完成后，客戶端有時(shí)還會做一些收尾工作，如執(zhí)行狀態(tài)匯總。

圖5? Hadoop到ODPS的數(shù)據(jù)遷移

這里，我們在客戶端本地的main函數(shù)中解析參數(shù)，創(chuàng)建UploadSession，把SessionID傳給Mapper，Mapper通過SessionID獲取UploadSession，實(shí)現(xiàn)寫數(shù)據(jù)到ODPS。當(dāng)Mapper執(zhí)行完成后，客戶端判斷執(zhí)行結(jié)果狀態(tài)，執(zhí)行Session的commit操作，把成功上傳的數(shù)據(jù)Move到結(jié)果表中。

默認(rèn)情況下，Hadoop會自動根據(jù)文件數(shù)劃分Mapper個(gè)數(shù)。在文件大小比較均勻時(shí)，這種方式?jīng)]什么問題。然而存在大文件時(shí)，整個(gè)大文件只在一個(gè)Mapper中執(zhí)行可能會很慢，造成性能瓶頸。這種情況下，應(yīng)用程序可自己對文件進(jìn)行切分。

下面實(shí)現(xiàn)一個(gè)類Hdfs2ODPS來完成這個(gè)功能。其中run函數(shù)完成了前面提到的主要邏輯，主要代碼如下（其中包括了對ODPS Tunnel的使用）：

在這個(gè)函數(shù)中，首先調(diào)用函數(shù)parseArguments對參數(shù)進(jìn)行解析（后面會給出），然后初始化DataTunnel和UploadSession。創(chuàng)建UploadSession后，獲取SessionID，并設(shè)置到conf中，在集群上運(yùn)行的Mapper類會通過該conf獲取各個(gè)參數(shù)。然后，調(diào)用runJob函數(shù)，其代碼如下：

runJob函數(shù)設(shè)置Hadoop conf，然后通過JobClient.runJob(conf);啟動Mapper類在集群上運(yùn)行，最后調(diào)用conf.getNumMapTasks() 獲取Task數(shù)，Task數(shù)即上傳到ODPS的并發(fā)數(shù)。在Mapper中，可以通過conf.getLong("mapred.task.partition")獲取Task編號，其值范圍為[0, NumMapTasks)。因此，在Mapper中可以把Task編號作為上傳的blockid。客戶端在Mapper成功返回時(shí)，就完成commit所有的Session。

應(yīng)用實(shí)踐注意點(diǎn)

與單機(jī)環(huán)境相比，在ODPS這樣的分布式環(huán)境中進(jìn)行開發(fā)，思維模式上需要有很大轉(zhuǎn)變。下面分享一些實(shí)踐中的注意點(diǎn)。

在分布式環(huán)境下，數(shù)據(jù)傳輸需要涉及不同機(jī)器的通信協(xié)作，可以說它是使用ODPS整個(gè)過程中最不穩(wěn)定的環(huán)節(jié)，因?yàn)樗且粋€(gè)開放性問題，由于數(shù)據(jù)源的不確定，如文件格式、數(shù)據(jù)類型、中文字符編碼格式、分隔符、不同系統(tǒng)（如Windows和Linux）下?lián)Q行符不同，double類型的精度損失等，存在各種未知的情況。臟數(shù)據(jù)也是不可避免的，在解析處理時(shí)，往往是把臟數(shù)據(jù)寫到另一個(gè)文件中，便于后續(xù)人工介入查看，而不是直接丟棄。在上傳數(shù)據(jù)時(shí)，Tunnel是Append模式寫入數(shù)據(jù)，因而如果多次寫入同一份數(shù)據(jù)，就會存在數(shù)據(jù)重復(fù)。為了保證數(shù)據(jù)上傳的“冪等性”，可以先刪除要導(dǎo)入的分區(qū)，再上傳，這樣重復(fù)上傳也不會存在數(shù)據(jù)重復(fù)。收集數(shù)據(jù)是一切數(shù)據(jù)處理的開始，所以必須非常嚴(yán)謹(jǐn)可靠，保證數(shù)據(jù)的正確性，否則在該環(huán)節(jié)引入的正確性問題會導(dǎo)致后續(xù)處理全部出錯(cuò)，且很難發(fā)現(xiàn)。

對于數(shù)據(jù)處理流程設(shè)計(jì)，要特別注意以下幾點(diǎn)。

• 數(shù)據(jù)模型：好的數(shù)據(jù)模型事半功倍。
• 數(shù)據(jù)表的分區(qū)管理：如數(shù)據(jù)每天流入，按日期加工處理，則可以采取時(shí)間作為分區(qū)，在后續(xù)處理時(shí)可以避免全表掃描，同時(shí)也避免由于誤操作污染全表數(shù)據(jù)。
• 數(shù)據(jù)傾斜：這是作業(yè)運(yùn)行慢的一個(gè)主要原因，數(shù)據(jù)傾斜導(dǎo)致某臺機(jī)器成為瓶頸，無法利用分布式系統(tǒng)的優(yōu)勢，主要可以從業(yè)務(wù)角度解決。
• 數(shù)據(jù)的產(chǎn)出時(shí)間：在數(shù)據(jù)處理Pipeline中，數(shù)據(jù)源往往是依賴上游業(yè)務(wù)生成的，上游業(yè)務(wù)的數(shù)據(jù)產(chǎn)出延遲很可能會影響到整個(gè)Pipeline結(jié)果的產(chǎn)出。
• 數(shù)據(jù)質(zhì)量和監(jiān)控：要有適當(dāng)?shù)谋O(jiān)控措施，如某天發(fā)生數(shù)據(jù)抖動，要找出原因，及時(shí)發(fā)現(xiàn)潛在問題。
• 作業(yè)性能優(yōu)化：優(yōu)化可以給整個(gè)Pipeline的基線留出更多時(shí)間，而且往往消耗資源更少，節(jié)約成本。
• 數(shù)據(jù)生命周期管理：設(shè)置表的生命周期，可以及時(shí)刪除臨時(shí)中間表，否則隨著業(yè)務(wù)規(guī)模擴(kuò)大，數(shù)據(jù)會膨脹很快。

此外，數(shù)據(jù)比對、A/B測試、開發(fā)測試和生產(chǎn)盡可能采用兩個(gè)獨(dú)立的Project。簡言之，在應(yīng)用開發(fā)實(shí)踐中，要理解計(jì)費(fèi)規(guī)則，盡可能優(yōu)化存儲計(jì)算開銷。

ODPS現(xiàn)狀和前景

阿里巴巴提出了“數(shù)據(jù)分享第一平臺”的愿景，其多年來堅(jiān)持投資開發(fā)ODPS平臺的初心就是希望有一天能夠以安全和市場的模式，讓中小互聯(lián)網(wǎng)企業(yè)能夠使用阿里巴巴最寶貴的數(shù)據(jù)。阿里內(nèi)部提出了所有數(shù)據(jù)“存、通和用”，將不同業(yè)務(wù)數(shù)據(jù)關(guān)聯(lián)起來，發(fā)揮整體作用。ODPS目前正在發(fā)展中，它在規(guī)模上，支持淘寶核心數(shù)據(jù)倉庫，每天有PB級的數(shù)據(jù)流入和加工；在正確性上，支持阿里金融的小額無擔(dān)保貸款業(yè)務(wù)，其對數(shù)據(jù)計(jì)算的準(zhǔn)確性要求非常苛刻；在安全上，支持支付寶數(shù)據(jù)全部運(yùn)行在ODPS平臺上，由于支付寶要符合銀行監(jiān)管需要，對安全性要求非常高，除了支持各種授權(quán)和鑒權(quán)審查，ODPS平臺還支持“最小訪問權(quán)限”原則：作業(yè)不但要檢查是否有權(quán)限訪問數(shù)據(jù)，而且在整個(gè)執(zhí)行過程中，只允許訪問自己的數(shù)據(jù)，不能訪問其他數(shù)據(jù)。

前面的示例只是展現(xiàn)了ODPS的冰山一角。作為阿里巴巴云計(jì)算大數(shù)據(jù)平臺，ODPS采用內(nèi)聚式平臺系統(tǒng)架構(gòu)，各個(gè)組件緊湊內(nèi)聚，除了結(jié)構(gòu)化數(shù)據(jù)處理SQL、分布式編程模型MapReduce外，還包含圖計(jì)算模型、實(shí)時(shí)流處理和機(jī)器學(xué)習(xí)平臺，如圖6所示。

圖6? ODPS功能模塊

隨著ODPS對外開放的不斷推進(jìn)和第三方數(shù)據(jù)的流入，相信會有各種創(chuàng)新在ODPS上生根發(fā)芽、開花結(jié)果。

盡管如此，云計(jì)算和大數(shù)據(jù)是兩個(gè)新興的領(lǐng)域，技術(shù)和產(chǎn)品發(fā)展日新月異。作為一個(gè)平臺，雖然ODPS已在阿里內(nèi)部被廣泛使用，但在產(chǎn)品和技術(shù)上還有很多方面需要進(jìn)一步完善和加強(qiáng)，希望ODPS能夠和云計(jì)算大數(shù)據(jù)應(yīng)用共同成長，成為業(yè)界最安全、最可靠和最方便易用的平臺。

本文主要內(nèi)容節(jié)選自作者即將出版的新書《ODPS權(quán)威指南》。

本文作者：張?jiān)七h(yuǎn)，長期工作于數(shù)據(jù)倉庫及BI領(lǐng)域，先后任職于建設(shè)銀行、TCS及惠普，2011年加入阿里云，擔(dān)任ODPS產(chǎn)品經(jīng)理，主要負(fù)責(zé)SQL模塊的產(chǎn)品功能。經(jīng)歷了阿里金融等數(shù)據(jù)倉庫在ODPS上的建設(shè)過程，作為登月一號項(xiàng)目的PM負(fù)責(zé)將小微金服離線數(shù)據(jù)平臺遷移到ODPS。

李妹芳，阿里數(shù)據(jù)平臺事業(yè)部工程師，曾譯有《Linux系統(tǒng)編程》、《數(shù)據(jù)之美》、《數(shù)據(jù)可視化之美》等書，其新書《ODPS權(quán)威指南》即將上市。

總結(jié)

以上是生活随笔為你收集整理的ODPS技术架构及应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。