獨家解讀：魅族數據平台的設計哲學和核心架構
由最初的純設備生產廠商漸漸發展為今天的智能設備設計商和互聯網服務提供商，「魅族」轉眼間已經歷了十年的成長，其Flyme系統也在逐漸走向成熟。而依託於Flyme的魅族互聯網服務也逐漸發展起來，隨之而來的大數據需求也日漸增多。
為將海量數據得以更高效的應用，沉澱大批高質用戶標籤，並用數據輔以應用商和廣告主的經營決策，魅族數據平台建設工作隨之而起，迄今為止已兩年有餘。
魅族數據平台採用了業界主流的計算平台和開源技術，涵蓋了Hadoop生態、流計算、機器學習等領域。截止現階段，魅族數據平台已完成對魅族關聯業務的各項數據支撐，長期計劃中，它也將全面投入魅族AI計算平台和機器學習/AI業務的支撐能力研發中。
為了進一步探究魅族數據平台的技術迭代演進之路，了解其背後的選型思路、技術創新和在不斷邁進過程中所踩過的坑、所規劃的解決方案，InfoQ對魅族數據平台經理莫涵宇進行了深度專訪，和他一起聊聊魅族數據平台的設計哲學和核心架構。
魅族為何要研發數據平台，源於哪些痛點？該款平台主要面向什麼樣的用戶？
莫涵宇：早期魅族互聯網業務的各種數據需求無法得到滿足，使用第三方數據服務存在種種限制，更談不上數據資產價值最大化的訴求，解決這些問題是魅族大數據團隊成立的初衷。而一個穩定強大的大數據平台也成為我們開展服務的基礎，基於此我們研發了魅族大數據平台。 目前魅族大數據平台的用戶主要是基於 Flyme 生態的魅族互聯網業務，此外還包括魅族科技其他非互聯網業務，如財務、營銷、手機研發、供應鏈、客服等。
在兩年多的建設中，魅族數據平台經歷了幾次較大迭代？每次迭代都有哪些重大變化？
莫涵宇：在魅族平台發展及架構演進過程中一直強調數據是根本，是最重要的資產，同時強調保護用戶隱私，所以從一開始就堅持數據獲取走自研之路，而技術上更多堅持 Hadoop 開源組件為基礎，並通過交流學習緊跟社區步伐，快速迭代實施。
總的來說，魅族大數據平台架構演進大致經歷了如下幾個階段：
摸索階段：在這個階段，魅族自研了簡單的行為上報 SDK，業務接入後開始可以統計 APP 啟動次數、使用時長等基礎指標。當時的 Hadoop 集群只有 6 台機器，ETL 過程也只是通過腳本方式來調度，統計報表因為沒有直接可用組件，使用的是 Java+ 前端方式直接開發，效率比較低下。
平台基礎框架搭建期：抱著拿來主意的思想，調度系統 1.0 及統計分析 1.0 版本在同事舊的經驗基礎上快速迭代開發上線。雖然調度系統並發不高，統計報表配置走的是 xml 配置方式，但魅族大數據專職的 ETL 同學已經可以基於調度平台進行模型設計、報表開發。接入的業務範圍及輸出形式也有了較大增長。
平台快速發展期：隨著接入業務增長，業務對數據及平台的需求急劇增長，在此階段調度系統進行了幾輪快速的迭代，同時行為上報新 SDK、WebIDE、流平台、用戶寬表等平台也快速推進上線。魅族平台初步具備了實時處理、簡單的 SQL 查詢能力。
平台完善期：經過一輪快速的平台建設，雖然一些基礎平台及功能已經具備，但產品體驗、性能、穩定性問題開始初顯。在不影響業務的前提下，對多個平台進行了重構升級：1、行為上報升級為集 APP 註冊、SDK 管理、自助測試等功能一體的統一上報平台；2、調度系統升級為集成開發平台，從原來 Shell 驅動改為基於 Java 開發的 Core+Runner 架構；3、魅族流平台經過多輪優化，處理了各種技術上的坑後穩定性有了顯著的提升；4、用戶寬表發展為用戶洞察平台等：在基礎平台功能及穩定性逐步完善的過程中，在滿足業務運營需求基礎上，直接為業務提供更多的支撐，比如對推薦、AI 等業務的支持。
產品導向期：經過前幾個階段的建設，魅族大數據平台體系基本建立。為了更好的提升數據服務的影響面，推進數據價值的落地實現，數據團隊由早期被動接收需求變為主動貼近業務，與此同時對數據平台產品化、開放度、細節提出了更高的要求。目前我們正處於這個階段。
魅族數據平台採用了哪些業界主流的計算平台和開源技術（請例舉幾項，並解釋為何採用）？為滿足平台性能及其他需求，魅族是否有哪些自研組件？
莫涵宇：魅族數據平台的基礎計算平台都使用了業界主流的開源框架和技術，如 Hadoop、Spark、Hive、HBase、Kafka、Storm 等幾乎大部分主流的數據開源技術，採用這些開源技術的好處顯而易見。
首先相對商用產品，使用開源技術使得開發成本大幅度降低；其次，功能的訂製可以更靈活和快速；此外，這些主流開源技術均有來自全世界的頂尖專家在參與研發和維護，使用它們能讓我們更快的跟上行業技術的發展。
當然每家企業的應用場景都有自身特點和特殊性，開源框架和技術並不能完全解決我們所有的需求，所以我們針對性的研發了一些組件。例如：
為了解決 Sqoop 配置複雜、難以統計和跟蹤的問題，我們研發了 cetus-Loader 組件，以實現文件到文件、資料庫到文件、文件到資料庫的傳輸，支持 MySQL、Hive、HBase 和文件系統，支持簡單的配置和豐富的日誌，並能在發生故障時（在保證性能的前提下）方便的回溯問題並解決故障。
另外，我們的流計算平台也進行了自研組件的整合。單純使用 MQ、Spark Streaming、Storm 等都不能讓整個流計算串起來，我們開發了介面組件、業務配置組件和平台管理組件，通過這些組件把幾種開源框架整合起來，讓整個流計算具備高可用可擴展易管理的特性，才真正解決了我們實時計算的需求。
您能否為 InfoQ 讀者重點講解從數據接入、數據清洗、存儲計算到監控等環節，魅族數據平台的運作原理以及各個環節技術選型上的思考（包括走過的坑和解決方案的調整）？
莫涵宇：如圖所示，魅族數據平台邏輯上分為數據源層，接入層，數據倉庫和計算層，數據介面和應用層這些大的層次，數據的流動基本上會是從左至右的模式，數據的價值最終體現在介面和數據應用層，對於這些層面使用的組件，我們也經過較為謹慎的選型和多次迭代。
首先，早期基於業務規模較小的狀況，我們的數據接入層並沒有做特別的選型測試，而是完全自研開發了一個分揀程序進行數據的接入，隨著數據量和業務規模的不斷增長，我們發現原有的程序在擴展性和性能上都出現了瓶頸。最終我們結合同行的一些經驗和自己的測試，重新規划了接入層的架構和實現，設計了新的接入組件：其中採集 SDK 一直是自研，主要考量是公司安卓領域的經驗豐富，相關人才儲備充足；批量數據載入組件 Cetus-Loader 考慮到行業內基礎調用的相關技術非常成熟，我們仍然採取自研的體系，通過各種產品的標準 API 調用結合適當的預處理和配置去實現，配合管理平台也實現了數據接入流程的跟蹤；我們的流平台 mz-Stream 除了業務管理部分，基礎計算組件採用了 MetaQ 和 SparkStreaming，選用 metaq 有一些歷史原因，從性能評估來看沒有太大的問題，同時該組件已經是公司使用得較為成熟的組件，有專人維護，而 SparkStreaming 在 MiniBatch 處理上已經被證明了其靈活性和高效性。當然，從業界最流行的組件看，未來針對這兩個部分我們還會再評估 Kafka 和 Strom 的引入。
當數據接入數據倉庫後，我們會進行數據清洗（大部分清洗工作會在入庫後進行）、存儲和各種計算，這些過程我們選用了 Hadoop 生態的組件。這裡的原因也很簡單，Hadoop 有經過各大商業環境驗證的比較成熟的解決方案，有足夠強大的社區更新和支撐，HDFS、Hive、HBase、Spark 等都在各種領域證明自身的能力，從成本和效率的角度考慮，這些組件是不二的選擇，至於 Kerberos、Ambari 等附加組件的使用也同樣是圍繞 Hadoop 而取捨。
經過基本處理形成領域和主題模型數據集，為我們的數據應用提供了豐富的數據來源。在數據介面和數據應用這一層，考慮到易於訂製和擴展的需求，我們主要使用 Java 自研了各種數據產品，這些數據產品也同時使用了例如 Kylin、ES、Vertica 等查詢引擎組件，為我們互動式應用提供支撐。
最後，貫穿這些環節需要一套任務調度系統和任務 / 指標監控系統。通過對一些開源產品，例如 Kettle 的分析，也包括專業人員過往的經驗支撐，我們還是採取自研策略，相關產品對於每個過程的處理進行合理的任務調度，最大化計算資源的利用率，監控任務的執行情況和指標的合理性，對流平台的輸入和輸出對賬，幫助整個數據應用的流程更為順暢和高效。
這裡順便也提一個任務調度的坑。早期由於任務數較少，我們研發的第一版任務調度系統依賴了 Orale 存儲過程和觸發器進行邏輯計算，隨著任務數和複雜度的增加，這種架構很快就捉襟見肘，我們不得不花費了很大的精力在短時間內重構了全新的任務調度系統，再花費了很長的時間進行迭代優化，更多使用內存計算和事件消息的機制。這個教訓告訴我們在選型的時候簡單的技術方案可以給我們當前的工作節省不少時間和精力，但如果對業務發展估計不足導致的技術前瞻性不足有時候也可能帶來更大的代價。
是否有 Hadoop 集群演化過程的經驗可以分享？遇到的主要問題和解決方案有哪些？
莫涵宇：魅族 Hadoop 集群一直堅持 Apache 社區路線，未使用商業服務。在演化過程中遇到、解決的問題不少，比較重要的問題有：
HDFS 問題：HDFS 是大數據平台的存儲組件，它的穩定性對其他生態組件及整個大數據平台影響是非常明顯的，對於功能 BUG，我們主要採用源碼補丁修復升級、版本整體升級、調用規避等策略，必要時做些源碼修復；對於 HDFS 性能問題，我們主要採取參數優化、集群按需拆分、架構調整 (如 HDFS Federation)、版本整體升級等策略；
Hadoop 生態技術組件協同工作時的兼容性問題：對選定的技術版本棧（Hadoop、Spark、HBase、Hive）等，進行整合部署調試，抽調典型生產任務類型進行驗證，修復遇到的問題，並制定上線計劃，分步驟實施上線。
計算性能問題：1、引入當下主流的內存計算引擎（如 Spark、Tez）等，替代老舊的 MR，實現計算平台整體性能提升；2、引入 Dr.Elephant、Eagle 等開源監控工具，經過團隊技術消化並定製後，推廣上線，實時監控並幫助開發人員去優化作業參數配置，從而達到提升計算性能的目的；3、定期的經驗技術分享講座、常態化的平台技術答疑。
數據及集群安全問題：隨著數據及業務的快速增長，安全問題愈發突出，國家也出台政策文件號召重視大數據安全建設。魅族作為一個負責任的企業，一直把用戶數據、用戶隱私安全當作頭等大事。2017 年，魅族大數據整合社區成熟開源技術（Kerberos、Ranger）以及自研 SCT 通用許可權制等措施，重新梳理調整平台架構，建設了規範化、系統化的平台安全體系，實現後台終端到前端 Web 的安全許可權控制全覆蓋，同時也在公司層面逐步整理並制定向國家標準看齊的大數據安全規範。
能否分享一下 OLAP 引擎探索思路和目前的進展？
莫涵宇：一般來說，OLAP 引擎整體分為 OLAP 模型構建和解析引擎、數據查詢引擎兩個部分。我們最開始希望基於 Mondrain 做二次開發，與各類查詢引擎對接。在預研過程中發現其與流行的一些大數據查詢引擎存在兼容性問題、而使用傳統 RMDB 又存在大數據量時的查詢性能問題，另外各類查詢引擎的擴展適配代價過高。因此我們先決定打造一個面向大數據的統一查詢引擎，之後 Mondrain 與這個統一的查詢引擎對接 (作為模型構建和解析引擎)。
而這個統一查詢引擎應該具有以下特點：
A. 統一的 DSL；
B. 具備解析器和查詢優化器；
C. 結合元數據和用戶請求自動完成查詢的 Pushdown；
D. 集成安全和監控解決方案；
E. 通過組合不同查詢引擎的優勢能力，在大數據環境下，面對篩選、模糊匹配、高基維排序、多維度聚合、實時性上都能夠有比較好的表現。
我們在 OLAP 引擎建設中也做了一些工作：
A. 統一 DSL 目前已經接入 Kylin 和 MySQL，並在內部統計分析平台部分需求中上線；
B. 已經和公司統一監控進行了對接，安全方面通過 Ranger 擴展方式接入了自研的 SCT；
C. 正在嘗試接入 ClickHouse，未來計劃接入一些實時性較好、模糊搜索排序方面性能優秀的查詢引擎，補充現有選型的不足；
D. 正在完善跟元數據平台的對接，以實現不同場景的查詢 Pushdown。
魅族數據平台自研的自助分析、駕駛艙 (移動數據分析) 能夠幫助使用者解決哪些問題？優勢是什麼？我們同時注意到，數據平台未來也計劃在 AI 上加大技術投入，賦予其自身更多的 AI 能力，您是否能具體講講你們的技術實踐計劃？
莫涵宇：關於駕駛艙這個產品的研發，主要來源於管理層的需求。我們發現管理層經常無法坐在電腦前工作，他們需要在移動辦公過程中隨時查看一些業務數據，但單純通過網頁展示一方面有安全隱患，另一方面登錄環節也是一個麻煩事，基於此我們提出了移動數據分析的概念，開發了駕駛艙這個產品。這個產品主要特點是在可視化呈現上可以靈活的嵌入 H5 頁面，是一個靈活的 Hybrid 應用；數據上與內部的統計分析系統共享後台，保持數據的一致性；在安全上採取了充分的保障策略，通過系統指紋驗證可以直接登錄也簡化了繁瑣的登錄流程。目前產品除了服務高管也已經在業務負責人中推廣開，幫助各業務的同事方便的查看數據進行決策。
另外，針對非技術領域的同事，我們還開發了自助分析平台，這個平台主要的特點體現在前端交互部分，通過可視化操作的組件，用戶不需要懂 SQL，可以通過簡單的拖拉拽完成動態分析或者構建自定義報表，未來這個平台還需要支持更豐富的 OLAP 操作。我知道有人會問，Tableau 這些工具不是實現得很好么，其實在我們看來，Tableau 功能足夠強大，但很多細節並不好用，包括一些時間控制項，包括數據量較大的時候內存的控制，以及對一些訂製需求的快速支持上都有局限性，這些因素促使我們開發一個更適合我們使用的數據可視化分析平台。
關於 AI 領域的探索業內的領先企業已經走得挺遠了，我們同樣需要能跟上時代的步伐，應對未來的挑戰。針對 AI 領域的研究，我們目前計劃在知識圖譜，意圖識別上做一些探索。
首先，知識圖譜是很多 AI 應用的基礎，包括搜索，推薦，意圖的推斷都能發揮重要的作用，當然考慮到百科圖譜對我們來說代價太大，我們也不會往百科的方向發展，目前我們還處在業務調研的階段，通過業務分析去界定建設圖譜的領域和範圍。
意圖識別是另一個重要的 AI 研究方向，它與 NLP、模式識別和知識圖譜都有關係。儘管業內已經有很多智能助手應用，但正如眾多創業公司、團體還在意圖識別領域發力一樣，我們也認為市場足夠廣闊，垂直領域也足夠豐富，我們會結合我們自己的場景去持續加強意圖識別能力，除了進一步增強 onemind 能力，還可以應用在自身的智能助手，智能客服，搜索推斷等領域。
目前魅族內部基於這個大數據平台做了哪些產品或應用？在哪些方面給魅族帶來了提升？是否可以分享一到兩個具體的案例？
莫涵宇：在魅族數據平台的建設過程中，我們針對實際的業務場景開發了一系列的數據產品和數據應用，包括統計分析平台 Orion，集成開發平台 Cetus，統一許可權管理平台 SCT，用戶洞察平台（用戶畫像），自助分析平台 lyra，數據統一上報平台 Norma 等，除了前面介紹過的產品，這裡再介紹兩個案例（原稿中有用戶洞察平台的案例，這裡沒了）：
針對數據開發流程複雜的情況，我們研發了集成開發平台 Cetus，這個平台主要包括 webIDE 和調度系統兩個部分。webIDE 是我們統一的編碼平台，通過 web 編輯窗口進行腳本語言的編碼，目前支持 HQL、Python、Shell 幾種，平台也預留了更多語法的擴展性；調度系統實現數據處理日常任務的調度管理、各種查詢、任務相關操作和故障處理，它與 webIDE 直接打通，用戶可以直接編碼後發布到調度系統或者直接在調度系統調用編碼環境直接編寫代碼。Cetus 平台把我們日常的數據開發工作通過 IDE 管理起來，降低了任務開發上傳腳本等流程的複雜度，同時把調度配置，故障處理等都整合在一個統一的平台下，大大提升了我們的開發效率的效果，很好的提升了用戶體驗。
另一個體現數據平台效率的產品是我們的用戶洞察平台。這個平台的核心是用戶畫像系統，我們通過用戶行為和設備屬性的統計以及演算法預測，建立了較為完善的用戶畫像，通過洞察平台可以對用戶進行精準圈選，自定維度的洞察以及內容投放，平台同時也提供 API 調用，實現可被第三方系統和平台的調用的能力；豐富的用戶畫像數據也成為推薦演算法的重要數據源，尤其是用戶興趣偏好標籤，這些標籤在各項內容推薦業務中發揮著重要的作用。隨著用戶洞察平台的完善，魅族互聯網業務越來越依賴這一平台，通過對用戶的精準識別我們大幅改善了內容推送的效果，很好的提升了用戶體驗。
您能否談談平台的價值和發展？您認為應該如何評估大數據平台的技術能力？從哪幾個維度？魅族數據平台下一步的發展規劃有哪些？技術上是否計劃開源？
莫涵宇：數據平台並不那麼顯山露水，很多情況下甚至就像一座冰山，人們看到的只有那麼一角，而在水面下有一個龐大的身軀支撐著整體。但大數據領域的人都知道，數據平台的能力決定了數據應用能達到的高度，所以對數據平台的價值我持絕對肯定的觀點，也會不遺餘力的推動平台向業界領先水平追趕。
評估一個大數據平台的能力，在我看來優秀的大數據平台應該具備以下一些特點：
高效性：包括執行的效率和開發的效率，相同的複雜度下單位時間處理的數據量越大則執行效率越高，相同的複雜度下開發流程越簡單，則開發的效率越高。
穩定性：顧名思義就是平台正常運轉和性能的穩定性，異常次數越少，異常時間越短則穩定性越高。
易用性：其實也是和效率相關的，對於用戶來說，平台本身的交互應該更合理，讓用戶以更舒服的方式使用平台，更快的獲得需要的結果。
安全性：這是一個不容忽視的問題，數據安全隱患無論對社會影響還是企業責任都是嚴重問題。
擴展性：當前的技術條件下我覺得優秀的數據平台應該具備良好的擴展性，資源投入的增加與處理能力提升應該儘可能趨於線性。
成本：企業投入和產出肯定要有一個合理的規劃，開源技術的流行，Hadoop 生態的火爆，其實很大一個原因也還是考慮了成本。
魅族數據平台雖然經歷了兩年多的建設，但仍然在快速發展中，未來我們有兩方面的規劃，一方面仍然是提升對內服務的能力，對魅族業務做更好的支撐，另一方面，我們希望嘗試走出去，首先給我們上下游的合作方，接入魅族開放平台的開發者和企業提供一些數據平台服務，包括 Flyme 生態下的排行分析、應用分析、Push 效果分析、行業報告等。
最後，開源這個方向是美好的，我們也期望能對行業做出一些力所能及的貢獻，也能在社區開發者交流中獲得更多成長，但目前來看條件還不是那麼成熟，短期可能還沒有該項計劃。
採訪嘉賓
莫涵宇（Neeke），魅族數據平台高級經理，具有十五年工作經驗和十四年數據倉庫與大數據開發應用經驗，先後服務於某電信系統集成商，阿里巴巴，YY，魅族科技，過往主要從事數據平台建設，架構設計，數據處理等領域工作，目前負責魅族大數據平台的管理和整體業務規劃，包括數據平台建設和數據應用服務（數據處理，報表，分析，預測，推薦演算法，AI 圖像和語義）
TAG:InfoQ |