ODPS技術架構及應用實踐

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

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所示。

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

數據通道服務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模式寫入數據，因而如果多次寫入同一份數據，就會存在數據重複。為了保證數據上傳的「冪等性」，可以先刪除要導入的分區，再上傳，這樣重複上傳也不會存在數據重複。收集數據是一切數據處理的開始，所以必須非常嚴謹可靠，保證數據的正確性，否則在該環節引入的正確性問題會導致後續處理全部出錯，且很難發現。

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

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

阿里巴巴提出了「數據分享第一平台」的願景，其多年來堅持投資開發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權威指南》即將上市。