從演算法和平台架構看魅族大數據技術積澱

演算法和數據架構本來就是相輔相承的，互相運作才能達到最佳效果。同樣，演算法和數據處理也是操作系統的核心部分。魅族手機操作系統 Flyme 在為用戶提供優秀的交互體檢和完美的服務過程中，利用機器學習技術和大數據平台架構的搭建，給用戶最精準的內容推薦，和流暢的操作感受。

以下是對李夢婷博士和張歡引老師的採訪，就機器學習、演算法提升，和數據平台架構優化等問題進行解答。如果想要面對面請教二位技術問題，可以來參加在 ArchSummit 深圳架構師峰會上舉辦的魅族技術晚場活動，兩位老師到時候均會帶領不同的小組進行更深入的技術話題討論，報名鏈接請戳「閱讀原文」。

InfoQ：在目前的個性化推薦以及互聯網廣告平台中，用戶畫像應用是非常廣泛的。魅族主要是通過幾個維度來刻畫一個用戶的，每個維度具體又包含什麼？

李夢婷：魅族團隊主要從六個方面刻畫用戶：人口屬性（比如性別，年齡等，可為用戶提供基本的人群服務）、位置屬性（比如常駐省份、常駐城市等，可為用戶提供場景化服務）、設備屬性（比如屏幕尺寸、電池容量等，可為用戶提供最佳的使用感受），業務屬性（比如使用時長、操作偏好等，可為用戶提供更好的業務體驗），興趣屬性（比如金融、體育等，可為用戶精準推薦感興趣的內容），最後一個是消費屬性（比如常用支付方式等，可為用戶提供更貼心的服務）。

InfoQ：如果用戶特徵和標註集合缺失的話，常規機器學習方法難以發揮應有的效用。根據魅族的實踐，是如何解決這類問題的？

李夢婷：數據缺失是一種很常見的情況，碰到這種狀況，我們的團隊通常會先根據其他已有的特徵來計算出相似用戶群，從而填充某些缺失的畫像特徵值。除此之外，部分特徵我們也會結合先驗知識（Priori Knowledge，是先於經驗的知識），甚至是採用人工標註或者與第三方機構合作的方式，構造出標註樣本。這些樣本除了用於機器學習訓練之外，也會在一些特定的場景直接用，比如直接人群定向。

InfoQ：經過長時間的功能完善，目前為止，魅族智能思維引擎 One Mind 又做了哪些性能和演算法模型上的改進？

李夢婷：One Mind 在之前的幾個版本基礎上已經做了非常多的技術和功能改進，比如引入深度學習技術，能夠更加準確地識別出用戶當前的狀態，以及挖掘用戶的行為習慣，進而給出智能化決策，提供各種使用場景下的智能解決方案；在」快省穩「方面，我們對演算法進行了優化，提升了使用 App 預測的效率，並且引入了天氣、位置等環境因素，從而使得預測結果命中率更高。

InfoQ：從您的角度來看，若要更好的實現您當前研究的推薦等工作，那麼魅族接下來需要在移動 AI 方面有哪些投入？需要更關注哪些 AI 技術點？

李夢婷：可以說，AI 只是一小部分，提升一項功能的實力，需要從整個產品的綜合角度來考量，我覺得主要可以歸納為以下幾方面：

• 系統本身：延續之前提出的「快省穩」觀念，採用個性化的系統資源調度方案，從根本上提升用戶體驗；

• 精準推薦：在信息泛濫的今天，讓用戶始終能夠快速準確地獲取到自己感興趣的信息，從內容層面上提升用戶體驗；

• 智能應用：探索前沿深度學習技術，為用戶提供語音指令、圖像處理等人工智慧應用，從使用層面上提升用戶體驗。

李夢婷多次談到「提升用戶體驗」，可見，魅族是真的希望通過技術手段提高產品的可用性，進而獲取用戶的好口碑。聽完李夢婷的講解，我們再來聽聽魅族數據平台研發組長、架構師張歡引老師關於魅族大數據平台搭建的那些事。張歡引老師目前主要負責魅族數據平台研發團隊管理，組織關鍵技術及架構評審。在大數據平台構建方面有豐富的經驗。

InfoQ：您之前負責過千萬級以上項目的架構設計、開發部署工作，對於架構設計和部署工作，您覺得需要遵循什麼樣的規律，需要提前考慮避免哪些設計上的坑？有沒有什麼經驗可以簡單分享？

張歡引：高併發架構設計需要遵循的規律或者原則是有很多的，在這裡，我就從高併發、高可用的角度簡單做下個人的經驗匯總和梳理：

• 抽象化：將產品或業務中的對象進行抽象，方便業務擴展，避免業務發展或一些小的變動而去重新設計架構。

• 分層原則，並儘可能把請求往前移：互聯網產品一般分為用戶層（瀏覽器、客戶端等）、接入層、應用層、服務層、數據層，並通過一些措施將不必要的請求儘可能擋在靠前一點的層級，比如 CDN 緩存、靜態緩存、有效性判斷等。

• 模塊化原則：將複雜問題通過模塊化、介面化等進行簡化，同時各模塊儘可能無狀態設計，方便做橫向擴展、負載均衡，避免單節點等問題。

• 優化瓶頸點：找出整個架構中各層、各模塊對併發影響最大的地方並細化設計。比如說瓶頸在數據層，可以考慮採用分庫分表分區、DB 緩存、NoSQL 技術等方案；比如發現一個模塊處理量上不去，但負載一直比較低，這就應該考慮提高併發量或是引入非同步處理。

• 做好監控及自我防護：這個原則更多的是提高系統的可用性，監控（或收集、反饋）是自我防護的前提。自我防護的方式方法很多，比如說限流（惡意請求屏蔽，防雪崩處理）、分流（負載均衡、故障節點自動踢除、跨機房部署）等，在必要時需考慮降級處理。

關於架構設計需要規避的坑及一些實用的經驗，這裡也簡單分享幾點：

• 架構設計不能脫離業務本身。在做設計前，必須對業務受眾、產品形態、產品交互及基礎數據配置進行深入思考，並做適當的歸納、抽象后再進行設計，同時要考慮後面可能會出現什麼樣的問題。

• 對用戶規模、系統請求量、後續增長等進行評估，從而確定架構目標、可能存在的瓶頸點。同時我們也要避免過度設計，比如說一個小項目，在可預期較長時間內數據量不會超過一兩百萬，數據表設計時卻刻意使用分庫分表。

• 盡量復用已成熟的組件，而不重新製造輪子。

• 對於架構中會使用的新技術、新組件，一定要做好預研，並結合業務場景進行測試（包括性能測試）、分析。避免為了使用新技術而使用，比如一個項目，使用 MySQL 就能滿足查詢性能要求，但剛學了 NoSQL，聽說查詢有較大提升，結果刻意把表拆解為 NoSQL 的多份數據，最後複雜度大大提高。

• 針對已有系統架構進行升級時，必須考慮新舊系統兼容性問題，並確定新系統上線方案。

• 緩存是種使用比較多而且有效的手段，但要避免設計考慮不全造成數據不一致。

InfoQ：魅族的大數據平台搭建，更多的是針對移動用戶的數據採集、行為分析，可不可以簡單介紹一下魅族大數據平台架構演進歷程？

張歡引：在魅族平台發展及架構演進過程中一直強調數據為本，數據是最重要的資產，同時強調保護用戶隱私，所以從一開始就堅持數據獲取走自研之路，而技術上更多堅持 Hadoop 開源組件為基礎，並通過多溝通、多學習的方式快速迭代實施。總的來說，魅族大數據平台架構演進大致經歷了如下幾個階段：

• 摸索階段：這一階段，魅族自己開發了個體用戶行為上報 SDK，業務接入后開始統計 App 啟動次數、使用時長等基礎指標。當時 Hadoop 集群才 6 台，對應的 ETL 過程都是通過腳本方式來調度。統計報表因為沒有直接可用組件，使用的是「Java+ 前端」的方式直接開發，效率比較低。

• 平台基礎框架搭建期：抱著拿來主義的思想，調度系統 1.0 及統計分析 1.0 版本在舊的經驗基礎上快速迭代開發上線。雖然調度系統併發不高，統計報表配置走的是 XML 配置方式，但魅族大數據專職的 ETL 同學已經可以基於調度平台進行模型設計、報表開發。接入的業務範圍及輸出形式也有了較大增長。

• 平台快速發展期：隨著接入業務增長，業務對數據及平台的需求急劇增長。在此階段調度系統進行了幾輪快速的迭代，同時行為上報 SDK、WebIDE、流平台、用戶寬表等平台也快速推進上線。魅族平台初步具備了實時處理、簡單的 SQL 查詢能力。

• 平台完善期：經過一輪快速的平台建設，雖然一些基礎平台及功能已經具備，但產品體驗、性能、穩定性問題開始暴露。在不影響業務的前提下，對多個平台進行了重構升級：行為上報升級為集 App 註冊、SDK 管理、自助測試等功能於一體的統一上報平台；調度系統升級為集成開發平台；從時間輪詢觸發 shell 調度模式發展為 core+runner polling 架構；魅族流平台經過多輪優化並處理了各種技術上的坑后，穩定性有了顯著的提升；用戶寬表發展為用戶洞察平台等。在基礎平台功能及穩定性逐步完善的過程中，在滿足業務運營需求基礎上，直接為業務提供更多的支撐，比如說內容推薦、AI 等業務的支持，自助能力的提升等等。

• 產品導向期：或稱精耕細作期。經過前幾個階段的鋪墊，魅族大數據平台體系基本建立。為了更好的擴大數據的價值，數據團隊由早期被動接收需求，逐漸向主動貼近業務轉變，與此同時對數據平台產品化、開放度、細節點提出了更高的要求。目前我們正處在這個關鍵階段。

InfoQ：目前，您主要負責包括統一上報、集成開發平台及流計算平台、用戶分析洞查、自助分析、智能推薦等魅族大數據技術平台體系基本建立工作，期間是不是一帆風順的？有沒有嘗試新的技術和方案？

張歡引：整體來說，平台建設的方向及各階段的核心目標是對的，但具體的執行過程中困難重重，像人員招聘困難，資源與需求不匹配，業務方對數據持懷疑態度、早期數據基礎組件比較欠缺、快速增長帶來成本增長等。但是公司對大數據平台建設給出了有效的支持，在前述的幾個階段快速發展后，已經為公司從進銷存、固件、各 App 等的運營、業務支撐等提供了全方位的數據支持。

在技術及方案選擇上，魅族大數據平台的建設一直在不斷緊跟行業前沿，預研並嘗試一些最新的技術和方案。比如用戶洞查平台 ES、HBase 的使用、流平台前期 MetaQ、Spark Stream 的使用及後面 Kafka，Storm 的接入；數據安全 Kerberos，Ranger 的使用等。在此過程中也踏了一些坑，走了一些彎路，當然其中也有一些是受限於需求緊迫及當時依賴的平台或組件而做出的選擇。

InfoQ：因為您會對內部技術架構進行前期的評審，所以想問一下，評審過程中會考慮哪些因素，有什麼規則或者長遠的考慮？

張歡引：評審是一件很有意思的事情，因為你需要處在一個更高的角度來給出你的想法和更好的解決方案，既要能提出問題，還要能解決問題。通常情況下會考慮如下一些因素：

• 該功能與產品定位是否一致，目前的緊急程度如何？

• 用戶受眾、規模及增長預期如何？

• 與公司或團隊其他項目的關係如何，是否可以復用？

• 技術選型是否有做實際的場景測試？測試結果、結論如何？

• 方案是否可行，是否有現成平台或組件可用？該方案是最終方案還是臨時方案。是否存在技術瓶頸？業務單點等問題？

• 該方案的成本如何（包括帶寬、伺服器、計算資源），對用戶體驗及隱私是否有影響？

• 該方案後繼運維及運營成本如何等。

在海量數據時代，對數據挖掘和研究的方式方法會更多，數據的價值也會被更大化的挖掘。希望大數據技術愛好者能共同參與到技術經驗交流，合力開採大數據這座礦山，交流地址戳「閱讀原文」