MaxCompute/DataWorks 數據集成與開發實踐

摘要：在2017杭州雲棲大會阿里雲數加DataWorks專場上，阿里雲產品專家代俊峰(花名：普陽)為大家分享了如何藉助阿里雲數加DataWorks工具進行數據集成和開發，分享了如何藉助DataWorks實現從數據處理手工作坊到數據加工工廠的跨越轉變。

本文內容根據嘉賓演講視頻以及PPT整理而成。

從整體的角度來看，數據的開發主要包括以下五個環節：

1. 總體架構

2. 數據集成

3. 數據建模

4. 數據開發

5. 運維調度

一、總體架構

其實DataWorks在2009年9月份的時候就已經開始研發了，當時還是基於Hadoop的體系進行研發的。談到為什麼要研發DataWorks這樣的一個工具，其實是因為在沒有DataWorks工具的時候，很多數據的開發工作是非常痛苦的，最開始做大數據分析處理的時候就是自己搭建幾十台Hadoop的機器，然後寫一些腳本去處理數據。當時Hive還沒有出來，所以需要自己寫MapReduce程序，之後包裹成shell腳本，再進行調度，但是這個過程中就會遇到很多如下圖所示的問題。

即便是一個小公司，僅有幾個人進行協同開發，互相之間的業務也需要進行協同調度。每個公司都會有一些開源的工具，比如很多互聯網公司都會使用MongoDB、MySQL等資料庫，還可能會使用一些新興的資料庫。以上這些資料庫都會被一線的開發人員所使用，所以需要將數據打到這些資料庫裡面去。剛開始可能是使用Oracle存儲了一億條數據，然後數據倉庫就跑不下去了，所以很多阿里巴巴的技術實踐都是在業務的逼迫下摸爬滾打尋找到的解決方案。阿里巴巴的所有數據都會匯聚到MaxCompute裡面，也是由於業務的需求或者說逼迫實現的。

在DataWorks長達8年的發展過程中，逐漸累積出來的一些工具，最開始的時候IDE開發環境都沒有外部的界面，最開始的時候就是使用一個Notepad或者Sublime來編寫代碼，然後上傳文件，自己進行ftp操作。阿里巴巴是一家數據驅動的公司，而對於一些非計算機專業的同學而言，可能連CPU和內存都不清楚，所以如果既需要他們去學習SQL開發，也需要去學習ftp命令，會是一件很痛苦的事情，這樣也會使得公司的運轉效率很低。所以後來DataWorks逐漸開發了圖形化的IDE界面來做數據集成，即便是非計算機專業的同學來做一些任務也是很容易的事情。今天，阿里巴巴每天活躍的「小二」就有六千多萬，他們的工作都需要依靠阿里巴巴的平台進行數據處理，這在全世界範圍來看都是不可想像的。雖然當時阿里巴巴在剛開始做的時候也並沒有想到會達到今天這樣的規模，但是經歷了這麼多年的時間，才發現阿里巴巴其實真的是一家數據驅動的公司。

其實在數據集成方面的這些功能現在看上去非常高大上，而這些功能的實現卻是由無數個阿里員工所貢獻的力量一點點積累沉澱而成的，而並非某一個天才的設計師的功勞。

如上圖所示的是數據工廠大圖，本次將會著重分享對於研發最為重要的數據集成、數據開發、監控運維以及實時分析這幾個部分的功能。

二、數據集成

全域數據匯聚

數據研發的第一步就是數據集成。數據集成其實是一個臟活、累活，對於小公司而言還好，而對於中型企業或者大型企業而言，就會存在很多的數據源，而針對於每一個數據源都進行單獨研發則會是一件非常痛苦的事情。不同的業務需求有很多的同步方式，比如實時的binlog同步、歷史數據批量或者增量同步等，而這些不同的同步方式都是隨著業務的實踐中經驗不斷積累而沉澱下來的。在阿里巴巴內部，這些都不只是一個工具，而是成熟的功能化應用，所以在這裡面就會有可視化的監控工具幫助用戶便捷高效地解決問題。當數據研發過程中沒有錯誤發生的時候其實很容易，一旦發生了錯誤或者出現性能的瓶頸則需要很好的工具進行支撐。

從下圖中也可以看到，DataWorks在數據集上擁有一個非常優秀的架構。

全程可視化

接下來分享DataWorks的數據集成具體是怎樣實現的。DataWorks擁有一個全程可視化的界面，之前的時候其他的一些公司往往會使用Oracle或者MySQL的Load工具編寫shell腳本，而對於開發人員而言，想要使用這些工具卻需要記憶很多參數。但是如果公司想要成為一家業務驅動的公司可能會存在很多的BU，而這些BU不可能花費重金聘請資深的數據專家或者架構師，而更可能僅僅聘請一個不懂計算機但是懂業務的同學來實現數據同步工作。而通過使用DataWorks的圖形化界面就可以解決70%~80%的數據同步問題，如果實在不行還可以使用腳本化的界面，這也都比單純記憶許多參數要好，可以通過使用JSON格式的面向對象的配置方式解決複雜的數據系統的配置問題。阿里巴巴每天同步的數據可能會達到幾十PB量級，當業務更加分化的時候，專門負責監控的角色可能會同時負責上萬個數據同步任務。而其實數據集成是一個任務，這個任務下面會分為不同的Task，Task會有不同的Pipeline通道，而每個Pipeline如果出現問題都可以進行精細化的監控。

三、數據開發

數倉規範

對於整個數據開發而言，都會有一套數據倉庫的開發規範，而且這套理論上規範大家都是比較認可的。對於大型的公司而言，其數據量也非常大，他們非常渴望按照阿里巴巴的數倉理論進行開發，但事實上如果沒有DataWorks這套工具，大家在進行數倉開發的時候還是小作坊的開發模式。當需要將數據研發過程發展成流水線的時候，必須要有一套數倉的開發規範，來保證流水線的高效、安全和穩定，進而驅動數據的研發。

而如今數據的研發已經遠遠不再是早期的產生一個報表來看看數據的情況了，在阿里巴巴這樣的公司中就存在數據的三字經——「聚、通、用」，其中的「聚」指的就是數據的匯聚。「通」指的是數據要融合貫通，如果數據拿過來之後，數據之間不做連接和融合以及進一步的精細化加工，數據獲取就是沒有任何意義的，舉個常見的例子，一個交易的數據和一個退款的數據，如果將這兩個數據放在一起就可以做一個交易退款的比例分析。再比如淘寶和微博關聯起來，分析微博關注以及點贊、點擊數據的關係。所以只有將這些數據放在像MaxCompute大型的DataLake的時候，在海量數據的關聯、融合和分析中才能做到別人永遠做不到的事情。

工藝流程

如下圖所示，DataWorks實現了一整套的數據開發的工藝流程。通過基礎服務的設施、數據分析、集成開發以及資源調度這樣一整套流程，以及完整的角色分工可以保證數據開發過程像現代化工廠一樣有生產人員和維護人員來保障數據高效穩定的產出。

功能圖譜

下圖是數據開發的核心功能圖譜。正如前面所提到的，一個集成環境會擁有一個代碼編輯器，如果是多人協作，一旦代碼寫錯了，就可以與代碼倉庫中上一個代碼版本進行對比，進而實現對於代碼的管理和協同。此外，整個資源的監控與調度以及元數據管理都可以在其中得以實現。

數據模型層次結構

從數據研發的分層上來說，DataWorks支持不同的應用層。每個應用層都會有一個項目空間，應用層的開發和基礎層的開發是分門別類的，但是他們又相互依賴，底層的數據為上層的數據提供服務，上層不同應用之間互相依賴和授權以及互相使用，這樣就有一個層次結構的模型來支撐，而這個層次模型的實現也是通過DataWorks工具賦能的。

數據建模

從下圖可以看到，DataWorks提供了數據建模的工具，如果熟悉也可以手工寫一個DDR工具來創建表，這種方法也是可以的。但是如果需要做大型的任務，比如阿里巴巴在收購優酷之後，需要將優酷的數據併入阿里巴巴，其中涉及到的表非常多，所以在整個建模的過程中，一個人的思路可能是不夠全面的，可能需要多人進行協同開發，而多人系統編輯模型則是一個非常麻煩和痛苦的過程。而且通過使用DataWorks，這個過程就像是使用Office 365在線協作一樣，通過大家協同地編輯模型然後實現的一鍵式發布提交到開發環境或者生產環境，這樣就極大地提高了效率。

數據血緣分析

下圖所展現的是數據開發之前，在進行需求分析的時候的數據血緣分析。比如對於一個產品經理而言，在進行數據分析的時候往往不知道會使用哪一張表，不理解每一張表的具體含義是什麼，所以效率會比較低。而在DataWorks的數據分析中，提供了數據血緣分析的工具，這樣就可以知道應該使用哪一張表、這張表對於其他表產生了什麼影響以及其他的表會對於這張表產生什麼影響，當出現表的欄位增加、減少等變化的時候會提前進行通知，使得開發人員可以事先進行維護，可以非常精細地幫助用戶了解表級別以及欄位級別的依賴關係，進而進行很好的數據研發。

業務流程單元

對於大型企業而言，在同一個工作空間下可能會發展到上百甚至上千個SQL，這時候就會變成一團亂麻，難於維護。而DataWorks有業務流程的概念，可以把相關的業務整合起來形成一個完整、高效的面向業務的流程。

代碼編輯器

其實產品的關注點就是無窮無盡的細節，下圖所展現的就是DataWorks中還在進行研發的功能。普通情況下，可能只需要寫兩三百行SQL代碼，而當業務越來越複雜的時候，可能典型的SQL需要500行，比較複雜的SQL可能會達到2000行甚至3000行。其實在寫SQL的時候，大家會注意到往往會有很多的from、join等，在看代碼的時候除了非常有經驗的SQL開發人員可以一目了然地看出關係，而對於一般的開發人員而言，看這樣的SQL是非常痛苦的。DataWorks所提供的編輯器非常強大，提供了代碼的摺疊、縮略圖以及鳥瞰幫助開發人員定位代碼，還可以通過SQL結構化的方式直觀地看到數據共同部件的分布圖，可以非常方便地幫助開發人員定位問題。

代碼編輯器核心的思路就是提供一個類似於Notepad的工具讓大家在裡面寫代碼，但是它不是一個簡單的文本編輯器，而是一個完全高度結構化的東西，可以從各個維度和角度將代碼進行各種變換，進而幫助理解代碼。正如一句程序員之間的那句名言「代碼是寫給人看的」，這種編輯器是為了幫助程序員提高開發效率的，幫助人理解代碼。所以當我們寫了SQL開發任務之後，DataWorks編輯器就可以幫助理解其內部所用到的表以及歷史上、空間上以及版本變化上的關係以及結構上的語法樹，可以提供非常多的結構幫助開發者理解。對於具體細節代碼而言，可以提供智能的提示，甚至寫一個子查詢所得到的欄位，在外部引用的時候也可以自動提示，以及代碼的預編譯以及實時的語法提醒。而這些看似簡單的功能，在真正實施過程中並不是那麼容易的，之所以DataWorks能夠做到是因為其底層使用阿里巴巴自研的MaxCompute，技術團隊之間可以實現非常緊密的協作，所以可以實現看起來很細節但是做起來非常複雜的事情。而對於複雜代碼的理解，就可以藉助之前提到的縮略圖以及代碼摺疊等各種各樣的展示方式幫助大家提高開發效率。

全局調度

最終任務發布完成之後，如果僅是一兩個任務使用shell配置一下就可以了，而對於像阿里巴巴這樣數據驅動的企業而言，數據加工的任務也會越來越多，如果任務數量到達1000的時候，如果沒有非常好的調度工具就會做不下去了。而如圖所示的調度圖僅是一個小例子，這可能僅僅是阿里巴巴整個調度系統的百萬分之一，僅僅是整個森林中的一片葉子。在實際業務中可以支持分鐘、小時、天、周、月等周期性調度，並且可以支持千萬級的並發。阿里巴巴的調度系統不同於其他的調度系統，它是基於無狀態任務的，屬於觸發的依賴，這樣就實現了非常高效的並發執行。隨著業務量不斷地發展，只有非常強大的調度支撐系統才能保障業務的正常運行。

工作流設計

DataWorks也提供了如下圖所示一整套工作流的設計機制來保障業務，可以幫助用戶更好地理解業務。

四、監控運維

任務管理

在監控運維層面，熟悉DataWorks產品的同學都知道，DataWorks提供了一套完整的數據加工工藝和數據開發規範，分為了開發環境和生產環境。而在從開發環境到生產環境之間進行代碼遷移的過程中，DataWorks提供了測試的接入。其實尤其是對於一些大型企業，補數據是一件非常頭疼的事情，可能晚寫了一些代碼上傳之後認為萬事大吉了，但是其實工作只完成了一半，因為需要補充之前的數據，才能進行數據的對比分析。因此DataWorks也提供了補數據的功能，用戶可以將過去30天或者過去90天的數據補充起來，為下一輪數據分析提供服務。從下圖也可以看出，從依賴關係到產生實例有特別多不同的實例產生進行維護，其中非常貼心的功能就是可以層層展開，可以看到每一層屬性的操作日誌以及運行日誌，也就是對於該節點做了什麼事情以及該節點做了什麼事情，這個節點是什麼樣的代碼以及版本情況等，都可以在DataWorks裡面進行機動化管理。如果沒有這樣一個環境，可能會需要用戶開發無數個工具，效率就會非常低下。

精細周期控制

下圖所示的是實例的精細化調度。每天的任務可以依賴小時的任務，這樣會追蹤並生成一個運行的實例，按照配置可以有條不紊地執行。

智能預測

下圖所示的是智能產出的效果圖。數據在使用的時候都是輸出到一線的系統中，即便是晚5分鐘產出都需要賠付用戶的，所以必須要能夠保證數據能夠及時產出。

五、DataWorks 大數據開發核心流程

最後回顧整個DataWorks 大數據研發的流程，通過找數據、申請數據、建表、圖形化拖拽的集中開發環境、臨時查詢的開發、集成的圖形化界面、圖形化的IDE環境以及監控報警等一步步實現大數據開發，以上這些都是看似非常細小的工具，但是正是這些工具保證了業務有條不紊地開展，這些工具組織起來就實現了DataWorks產品的目標。DataWorks不是一個手工作坊式的數據研發工具，而是真正的數據生產進入大規模生產、協作、監控與運維時代的高端生產工具。

原文

推薦閱讀：