2017年，ofo向市場投入了一千多萬輛單車，這些單車的投放、營運和排程需要大量資料的支援。本文将從ofo選擇MaxCompute的理由以及資料完整性、任務排程、Proxy服務三個方面的實戰應用，分享ofo 在MaxCompute的大資料開發之路。
演講嘉賓簡介：龍利民，ofo大資料，大資料副總監。
PPT材料下載下傳位址： https://yq.aliyun.com/download/2728 視訊位址： https://edu.aliyun.com/lesson_1010_8792?spm=5176.10731542.0.0.bVmNS6#_8792 産品位址： https://www.aliyun.com/product/odps 本次分享主要包括以下内容：一、ofo為什麼選擇
MaxCompute二、實戰應用
1.
資料完整性
2. 任務排程
3. Proxy服務
一、 ofo 為什麼選擇首先，回顧一下2016年。當時，ofo的資料分析師還在使用Excel+MySQL這樣原始的方式來制作報表。在這樣的背景下，要求一名研發人員利用兩周的時間開發出資料平台。
那麼，如何完成這個任務呢？首先，分析一個資料平台主要包括哪些部分。其中，首要問題是叢集（大資料下僅利用MySQL經常出現查挂的情況）。有了叢集之後，需要進行資料的裝載，這就涉及到ETL。對外界來說，他們更關心的是資料本身，是以還需要BI平台，這部分也是需要大量投入的。有了BI平台之後，就可以在平台上制作報表，且涉及到報表的排程。
其中，最首要的問題還是叢集，是自建叢集還是使用雲服務？在進行這一選擇時，主要從以下六個次元進行考量。
· 存儲：事實上，存儲也決定了性能。阿裡雲中就使用了ORC，它是一種列式存儲。而MaxCompute使用的也是列式存儲。
· 計算：計算性能的要求就是減少耗時。比如，一句SQL語句執行二三十分鐘，這樣的計算性能顯然是不可接受的。
· 費用：費用這一因素通常是不需要考慮的。對于一般小公司而言，MaxCompute按量後付費是最好的選擇。
· 穩定性：穩定性需要長期使用才能得以展現，是以這裡不做過分強調。
·
UDF
：共享單車的特性決定了在計算中涉及大量“點”的計算。這裡必須用到UDF函數，是以，如果不支援UDF，則不納入選擇範圍。
· 文檔：MaxCompute的文檔寫的非常的詳細。
綜合了多方面的因素，我們最終選擇了MaxCompute。那麼，在使用了一年半後，其結果怎麼樣呢？下面簡單介紹幾個事例。
· 實錘一：某同僚在ofo工作一年寫的SQL，超過前5年的總和；
· 實錘二：對比自建EMR叢集和MaxCompute：叢集成本 2 vs 1，運維成本 6 vs 1；
· 實錘三：新孵化項目，業務運轉良好的前提下，日費用不到50元。
二、 實戰應用上面介紹的是選擇MaxCompute的原因，下面介紹一些在使用過程中的經驗。
1. 資料完整性：資料不準的問題是資料分析師最擔心的問題。但更令人擔心的是，看到資料時無法得知它到底準不準！造成這個問題的一個重要原因就是資料不完整。比如，昨天共産生了100萬條資料，但隻上傳了99萬條。是以，一定要保證資料的完整性。
· 資料完整性的定義：程式計算的時候確定T+1天的資料是完整的，非割裂的，即原子的；
· 不注重資料完整性的做法：通過時間來約定計算，資料間的計算依賴也是基于時間；
不注重資料完整性的後果：很難發現資料的錯誤，需要人力來排查問題；如果不在邏輯上解決掉，會重複出現。
期望中的資料完整性隻存在兩種情況，要麼有資料，且一定是對的，要麼就沒有資料。
在實際應用中，如何解決資料完整性的問題呢？解決方案主要包括以下幾點。
用指令的 tunnel upload上傳資料，不用SDK；（利用tunnel upload上傳資料時，對檔案來說，它是具有原子性的，不會存在檔案隻上傳了一半的情況。而SDK是行級上傳的。）
維護資料标記。（當資料被上傳到MaxCompute之後要對資料進行标記，比如當天的資料是否傳完，後續的計算也會基于這一标記進行，不會對未ready的資料進行計算。）
做到這幾點後，在實際應用中起到了非常顯著的效果：沒有出現一起，因為資料不完整導緻的資料不準的情況。
在程式上保證了資料完整性後，還要思考另一個問題：自發查詢的資料完整性如何解決。比如在HUE中查詢時，使用者不知道資料是否是完整的。關于解決方案，這裡先埋個伏筆，後面會進行詳細介紹。
2. 任務排程：每天有近千張報表需要排程計算，報表間的關系會存在互相依賴的問題。如何有效的協作，是任務排程需要解決的問題。
任務排程主要分為下面三種。
中間表、寬表：我們将最原始的資料表稱為原表，比如每天産生的訂單表、優惠券表等。但在實際查詢中需要将這些表進行關聯。比如，想要查詢某個訂單中的優惠券資訊，如果不建立寬表則每次查詢都需要寫join語句。
計算報表：計算後用于統計的表。
結果寬表：計算報表會存入資料庫，這樣就會導緻資料庫中存在非常大量的表。建立結果寬表以便于分析師找到想要分析的名額。
下圖展示了對任務排程的期望。
第一，并發，多機多程序，以減少程序挂掉伺服器挂掉帶來的影響。
第二，協作，要求能建立依賴關系。比如先計算完某張表後再計算依賴它的表。
第三，可監控，當出現故障時能及時報警。
第四，可擴充性，在任務排程中寫的語句不僅是SQL，也有可能是python腳本或shell等。第五，資源隔離，在資源排程中要注意，不能讓大的SQL把資源全部占用，一旦資源被全部占用，整個計算都會卡住。
下面介紹在實際應用中使用的任務排程技術架構。資料庫中存儲了每天要計算的任務，生産者從資料庫中取資料，并核實資料完整性和依賴關系，核實狀态是否為ready，核實完成後進入隊列，狀态變為waiting，消費者從隊列中擷取資料并将狀态改為running，最後将狀态寫回資料庫。在這一過程中，每個任務都需要将其心跳的狀态同步到資料庫中，比如某個生産者挂掉之後，如果沒有心跳機制，那麼它擷取的任務将有可能永遠在waiting狀态。
MaxCompute主要包括兩種使用方式：預付費和後付費。預付費，有一個單獨的資源池，其中的資源可使用但有上限，并且已經提前付費。後付費，有一個共享的資源池，大家需要搶占資源。
在實際應用中包括以下規則：
大任務使用後付費
優先級高任務使用預付費
優先把預付費填滿
預付費隊列滿了，使用後付費
3. Proxy 服務下圖展示了Proxy endpoint可以解決的問題。
：比如兩個人重複執行了一樣的SQL語句，且資料沒有更新。那麼第二次執行的時候，會直接傳回上一次的結果。這樣，第二次查詢的過程不會占用MaxCompute的資源。這樣，就可以減少執行耗時，提升體驗。同時，降低資源開銷，節約成本。
· 安全控制：不再對外暴露key，建構業務自由賬号，不同的人會擁有不同的賬号。同時，建構内網的IP白名單。MaxCompute的白名單是針對外網的，而在内網中也會有很多台機器，如果所有内網機器都擁有通路權限，也是不安全的。
· 友善統計：SQL開銷統計到人，并且也可以友善地按部分來計費。
那麼，在實際應用中應該如何做呢？總體來講分為下圖兩種方案。
方案一：代理轉發。收到資料後轉發到MaxCompute然後再通過response傳回。
方案二：服務端在調用SDK。利用MaxCompute SDK，每次獲得請求後，解析請求中的參數，再傳回給SDK。
由于方案二的工作量較大，我們選擇了方案一，它具有以下優點。
開發工作量小
Pyodps更新也不影響
對于潛在的API接口具有相容性
隻實作我們自由賬号體系
ip白名單控制
下圖展示了其核心代碼。
下面簡單介紹其中的部分代碼。
對所有url進行規則判斷，正規表達式中寫的越多就會越優先命中。
主要是用于解決SQL代碼重複執行的問題。
主要解決指令行的問題。MaxCompute主要分為兩個入口，一個是SDK，另一個是指令行。SDK是比較易于實作的。而指令行中會自己生成taskname，每一次請求都會check其taskname。
另外，建構安全控制時，一定要有自己的簽名。不能使用用戶端上傳的簽名，我們隻能使用用戶端上傳的SSID的字首。
上面的代碼中實作了總體的流程，但具體實作過程中還存在一些問題。
難點1：如何確定優化後結果和實際執行結果一緻？
從SQL中提取表資訊和分區資訊
在一定延時内，擷取表資料的更新資訊
解決方案：建構SQL文法樹，提取出表，目前還沒解決分區
另起新程序，捕獲表和分區的最後一次修改時間
難點2：指令行傳回的适配，為什麼呢？
task name 由用戶端生成，例如：console_query_task_152696399361
taskstatus和instanceprogress都會去校對服務端傳回的資訊中的task name, 一旦和用戶端的task name不一緻，會出現：FAILED: task status unknown
用戶端會從server的所有task name中查找到和自己一樣的task name。
儲存曆史所有請求的task name
傳回所有的task name
通過Proxy服務，取得了不錯的效果：提升了體驗，具體例子：第一次sql執行耗時的70秒，再次執行不隻需要0.9秒；
減低了費用，整體費用減低了一半；
提升了安全的可控性，不暴露sercret_key給同僚；
每個業務配置設定1個賬号，能友善統計費用；
解決了前面提到的資料完整性問題。
如需了解更多關于MaxCompute産品和技術資訊，可加入“MaxCompute開發者交流”釘釘群；
群号11782920，或掃描如下二維碼加入釘釘群。