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

初識ODPS

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

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

ODPS采用抽象的作業處理框架將不同場景的各種計算任務統一在同一個平臺之上，共享安全、存儲、數據管理和資源調度，為來自不同用戶需求的各種數據處理任務提供統一的編程接口和界面。

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

圖1? ODPS應用開發模式

如果你的業務發展需要一個足夠強大、能開箱即用的大數據處理平臺，并且不想花費太多精力去關注這一切如何實現與運維，那么ODPS是一個非常理想的選擇。

規模的挑戰

在DT時代，數據是寶貴的生產資料，但不斷擴大的數據規模給ODPS帶來了極大的挑戰。在阿里內部就曾直面這種情況：在可以預見的時間內，單個集群的規模無法再容納所有的數據。

解決方案是擴大單集群的規模，同時讓應用系統可以管理多個集群。在這個背景下，ODPS作為一個海量數據的處理平臺，結合5K項目開發了多集群管理的功能，使得數據處理的規模跨上了一個新的臺階。當單個計算集群的存儲或計算容量不足時，將數據重新分布到新的集群上。更重要的一點是，這種跨多個集群的能力，對上層應用是透明的，用戶在運行SQL或者Graph模型時，不必了解數據是分布在哪個物理集群上，如圖2所示。

圖2? ODPS的跨集群能力

網站日志分析

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

數據來源于網站酷殼（CoolShell.cn）上的HTTP訪問日志數據（access.log），格式如下：

一個典型的企業數據倉庫通常包含數據采集、數據加工和存儲、數據展現等幾個過程，如圖3所示。

圖3? 數據倉庫主要過程

數據采集

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

在ODPS中，大部分的數據都是以結構化的表形式存在的，因此第一步要創建ODS層源數據表。由于數據是每天導入ODPS中，所以采取分區表，以日期字符串作為分區，在ODPS CLT中執行SQL如下：

假設當前數據是20140301這一天的，添加分區如下：

解析后的數據文件在/home/admin/data/20140301/output.log下，通過dship命令導入ODPS中，如下：

數據加工和存儲

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

與傳統的RDBMS相比，ODPS SQL面向大數據OLAP應用，沒有事務，也沒有提供update和delete功能。在寫結果表時，盡量采用INSERT OVERWRITE到某個分區來保證數據一致性（如果用戶寫錯數據，只需要重寫該分區，不會污染整張表）。如果采用INSERT INTO某張表的方式，那么在作業因各種原因出現中斷時，不方便確定斷點并重新調度運行。

ODPS SQL提供了豐富的內置函數，極大方便了應用開發者。對于某些功能，如果SQL無法完成的話，那么可以通過實現UDF（用戶自定義函數）來解決。例如希望將ip字段轉化成數字形式，從而和另一張表關聯查詢，可以實現UDF，如下：

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

表dual（需要用戶自己創建）類似于Oracle中的dual表，包含一列和一行，經常用于查詢一些偽列值（pseudo column），是SQL開發調試的利器。

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

圖4? PV/UV展示結果

數據展現

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

遷移到ODPS

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

數據通道服務ODPS Tunnel是ODPS與外部交互的統一數據通道，能提供高吞吐量的服務并且能夠水平進行服務能力的擴展。Tunnel服務的SDK集成于ODPS SDK中。實際上，dship也是調用SDK實現的客戶端工具，支持本地文件的導入導出。我們鼓勵用戶根據自己的場景需求，開發自己的工具，例如基于SDK開發對接其他數據源（如RDBMS）的工具。

把海量數據從Hadoop集群遷移到ODPS的基本思路是：實現一個Map Only程序，在Hadoop的Mapper中讀取Hadoop源數據，調用ODPS SDK寫到ODPS中。執行邏輯大致如圖5所示。

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

圖5? Hadoop到ODPS的數據遷移

這里，我們在客戶端本地的main函數中解析參數，創建UploadSession，把SessionID傳給Mapper，Mapper通過SessionID獲取UploadSession，實現寫數據到ODPS。當Mapper執行完成后，客戶端判斷執行結果狀態，執行Session的commit操作，把成功上傳的數據Move到結果表中。

默認情況下，Hadoop會自動根據文件數劃分Mapper個數。在文件大小比較均勻時，這種方式沒什么問題。然而存在大文件時，整個大文件只在一個Mapper中執行可能會很慢，造成性能瓶頸。這種情況下，應用程序可自己對文件進行切分。

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

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

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

應用實踐注意點

與單機環境相比，在ODPS這樣的分布式環境中進行開發，思維模式上需要有很大轉變。下面分享一些實踐中的注意點。

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

對于數據處理流程設計，要特別注意以下幾點。

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

此外，數據比對、A/B測試、開發測試和生產盡可能采用兩個獨立的Project。簡言之，在應用開發實踐中，要理解計費規則，盡可能優化存儲計算開銷。

ODPS現狀和前景

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

前面的示例只是展現了ODPS的冰山一角。作為阿里巴巴云計算大數據平臺，ODPS采用內聚式平臺系統架構，各個組件緊湊內聚，除了結構化數據處理SQL、分布式編程模型MapReduce外，還包含圖計算模型、實時流處理和機器學習平臺，如圖6所示。

圖6? ODPS功能模塊

隨著ODPS對外開放的不斷推進和第三方數據的流入，相信會有各種創新在ODPS上生根發芽、開花結果。

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

本文主要內容節選自作者即將出版的新書《ODPS權威指南》。

本文作者：張云遠，長期工作于數據倉庫及BI領域，先后任職于建設銀行、TCS及惠普，2011年加入阿里云，擔任ODPS產品經理，主要負責SQL模塊的產品功能。經歷了阿里金融等數據倉庫在ODPS上的建設過程，作為登月一號項目的PM負責將小微金服離線數據平臺遷移到ODPS。

李妹芳，阿里數據平臺事業部工程師，曾譯有《Linux系統編程》、《數據之美》、《數據可視化之美》等書，其新書《ODPS權威指南》即將上市。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。