AI專家：大數據知識圖譜——實戰經驗總結
作為數據科學家，我想把行業***知識圖譜總結并分享給技術專家們，讓大數據知識真正轉化為互聯網生產力!大數據與人工智能、云計算、物聯網、區塊鏈等技術日益融合，成為全球最熱的戰略性技術，給大數據從業者帶來了***的發展機遇，同時也對大數據工程師提出了高標準的技能要求。大數據具有海量性、多樣性、高速性和易變性等特點，映射到大數據平臺建設要求，不僅要具備海量數據采集、并行存儲、靈活轉發、高效調用和智能分析的通用Paas服務能力，而且能快速孵化出各種新型的Saas應用的能力。
要實現這個目標，架構設計至少要滿足三個總體技術要求：
一是把分布式大數據平臺的基礎數據服務能力建設擺在首位。規劃出支撐PB級規模數據運營能力的云平臺架構，運用經典設計原則和設計模式的架構之美，吸納業內主流分布式技術的思想精髓，深耕主流平臺服務模式到現代微架構的演變內涵;
二是用系統架構設計和微服務建設思想武裝團隊，持續撰寫多維度的架構藍圖，推動團隊協同作戰;
三是圍繞大數據全棧技術體系解決項目實戰中的各類難題，制定主流技術規范和設計標準，通過平臺核心組件方式快速迭代出新型業務。從設計要求來講，大數據平臺服務的整體設計要具備全面、全局、權衡的關鍵技術要求，不僅能全面提煉國內外優秀架構和解決方案的精華，而且要理解分布式技術的底層設計思想;不僅能全局了解上下游技術生態和業務結合的設計過程，而且要游刃有余的處理系統功能和性能問題;不僅能權衡新技術引入和改造舊系統的成本估算，而且要推動作戰團隊輕松駕馭新技術。
- ***個總體技術要求：把分布式大數據平臺的基礎數據服務能力建設擺在首位。規劃出支撐PB級規模數據運營能力的創新云平臺架構，運用經典設計原則和設計模式的架構之美，吸納業內主流分布式技術的思想精髓，深耕主流平臺服務模式到現代微架構的演變內涵。
- 第二個總體技術要求：用系統架構設計和微服務建設思想武裝團隊，持續撰寫多維度的架構藍圖，推動團隊協同作戰。架構師不僅要具備大型云平臺架構的實戰經驗之外，更要有大智慧和戰略思維，通過藍圖來推動和管理好每一個產品的全生命周期。
- 第三個總體技術要求：圍繞大數據全棧技術體系解決項目實戰中的各類難題，制定主流技術規范和設計標準，通過平臺核心組件方式快速迭代出新型業務。針對設計規范的重要性，我們不妨用《孫子兵法》的大智慧來分析一下。
從系統整體技術能力出發，提出物聯網大數據平臺的八個通用微服務的技術要求，包括大數據的高并發采集服務、靈活分發服務、高可擴展海量存儲服務、高并發展海量存儲服務、高可靠海量存儲服務、自定義遷移服務、基于機器學習的智能分析服務和基于Spark生態的實時計算服務，具體如下：
高并發采集服務：
- 支持多種移動終端和物聯網數據的可擴展接入，并具備大規模接入并發處理能力。能夠兼容主流行業通用的可擴展協議和規范，并采用高可靠的集群或者負載均衡技術框架來解決。如引入Mina或者Netty技術框架后適配各種多種移動終端接入。標準化接入要求常用的字節流、文件、Json等數據格式符合主流標準格式。
靈活分發服務：
- 按照分析應用需求，轉發不同的數據類型和數據格式，交互方式之一是主流的消息中間件MQ或者Kafka，保證高效的轉發并轉換數據給數據服務運營方。交互的方式之二是Restful 方式，保證數據可以按照協議規范進行安全可靠的數據轉發和傳輸。
高可擴展海量存儲服務：
- 支持數據類型和數據表可擴展，對物聯網大數據進行海量存儲和計算，尤其適用于初創公司研發***用戶之內的大數據平臺。
高可并發海量存儲服務：
- 支持數據類型和數據量的高速增長，對物聯網大數據進行批處理，適合構建PB級數據量和***用戶量的云平臺。
高可靠海量存儲服務：
- 支持物聯網多源異構數據的統一高效和海量存儲，并提供易于擴展的行業數據的離線計算和批處理架構，適合構建ZB級數據量和億級用戶量的分布式大平臺。
基于Spark生態的實時計算服務：
- 支持對物聯網大數據智能分析能力，通過企業級中間件服務框架提供安全可靠接口，實現數據實時統計和計算。
基于機器學習的智能分析服務：
- 支持安全高效的機器學習算法，通過支持分布式分類、聚類、關聯規則等算法，為用戶和物聯網機構提供個性化的智能分析服務。
自定義遷移服務：
- 支持對物聯網大數據的整體遷移和同步，通過數據轉換和數據遷移工具對不同數據類型和數據格式進行整體遷移，實現數據集的自定義生成。
01高并發采集微服務
面對千倍用戶量和萬倍數據量的增長速度，如何保證物聯網大數據在比較快的時間內進入平臺?應對用戶量的增長，如何在規定的時間內完成采集?在硬件設備處理能力之外，讓數據更快的匯聚到平臺是核心需求。具體考慮如下：
滿足采集來自不同的廠家、移動設備類型、傳輸協議的行業數據的需求。我們在接口設計中完全可以針對不同設備和傳輸協議來設計，就是借用“分而治之”的用兵之道，“分而治之” 就是把一個復雜的算法問題按一定的“分解”方法分為等價的規模較小的若干部分，然后逐個解決，分別找出各部分的解，把各部分的解組成整個問題的解，這種樸素的思想也完全適合于技術設計，軟件的體系結構設計、模塊化設計都是分而治之的具體表現。其中策略模式就是這個思想的集中體現。策略模式定義了一個公共接口，各種不同的算法以不同的方式實現這個接口。
滿足高并發需求。需要借助消息隊列、緩存、分布式處理、集群、負載均衡等核心技術，實現數據的高可靠、高并發處理，有效降低端到端的數據傳輸時延，提升用戶體驗。借用“因糧于敵”的思想。“因糧于敵”的精髓是取之于敵，勝之于敵，以戰養戰，動態共存。我們常說的借用對手優勢發展自己并整合資源就是這個思想的集中體現。正式商用的系統需要借助高性能中間件來并行處理數據，達到不丟包下的低延遲。我們采用商用的Mina 負載均衡技術框架，可以支持多種設備和傳輸協議(HTTP、TCP、UDP)的數據接入，可以滿足每秒上萬并發數的數據接入需求。針對以上的核心需求分析和技術定位，我們可以借助第三方中間件和采用設計模式實現個性化業務，來解決接口的集中化、可擴展性、靈活性等問題，借助Mina的Socket NIO技術魅力，適配高并發的數據接口IOFilterAdapter進行反序列化編碼，適配高并發的數據接口IOHandlerAdapter進行業務處理。
02 靈活轉發微服務
靈活轉發能力的總體設計中要考慮接口和消息中間件兩種方式，其中消息中間件可支撐***用戶規模的消息并發，適用于物聯網、車聯網、移動 Apps、互動直播等領域。它的應用場景包括：
- 一是在傳統的系統架構，用戶從注冊到跳轉成功頁面，中間需要等待系統接口返回數據。這不僅影響系統響應時間，降低了CPU吞吐量，同時還影響了用戶的體驗。
- 二是通過消息中間件實現業務邏輯異步處理，用戶注冊成功后發送數據到消息中間件，再跳轉成功頁面，消息發送的邏輯再由訂閱該消息中間件的其他系統負責處理。
- 三是消息中間件的讀寫速度非常的快，其中的耗時可以忽略不計。通過消息中間件可以處理更多的請求。
主流的消息中間件有Kafka、RabbitMQ、RocketMQ，我們來對比一下它們性能，Kafka是開源的分布式發布-訂閱消息系統，歸屬于Apache***項目，主要特點是基于Pull模式來處理消息消費，追求高吞吐量，主要用于日志收集和傳輸。自從0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務;RabbitMQ是Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、安全。AMQP協議用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。RocketMQ是阿里開源的消息中間件，由Java語言開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。RocketMQ設計思想源于Kafka，但并不是Kafka的一個Copy，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景。結合上述服務優勢對比，在第三章我們會使用最主流的ActiveMQ消息中間件來處理數據轉發，在第六章我們采用分布式的Kafka實現數據轉發。
03 高可擴展海量存儲服務
高可擴展是大數據處理的核心需求之一。實際工作中，當用戶量在100萬以內，而且數據量在TB級別以內，常常可以選擇用Mysql數據庫，靈活、成熟和開源的Mysql數據庫是初創公司的***。我們考慮使用縱表實現系統靈活可擴展，讓經常使用的數據放在一個數據表中，讓靈活變化的字段實現字典表模式，讓內容常發生變化的數據對象盡量采用JSON格式。著名的OpenMRS系統在Mysql數據庫中實現了自定義表格，讓醫生可以實現靈活自定義表格，收集自己的臨床試驗數據，讓用戶自己每天可以記錄自己的飲食信息。這樣的設計就能實現了應用場景的普適性。我們借鑒OpenMRS的核心思想來構建一個基于Mysql的小規模的物聯網大數據模型。應用場景就是：一個患者到多個醫院，進行體檢并記錄了各個生理指標。我們根據應用場景來建立數據模型。患者表構建為Patient表，醫院表構建為Location表，體檢構建為Encounter表，測量構建為Observation表，體檢類型描述構建為Concept表，采用五張表的多表關聯實現了普適的可擴展數據模型，在第三章節會詳細闡述。
高可擴展的另外一個接口實現就是Restful架構。Restful接口是安全開放平臺的主流接口風格。一般的應用系統使用Session進行登錄用戶信息的存儲和驗證，而大數據平臺的開放接口服務的資源請求則使用Token進行登錄用戶信息的驗證。Session主要用于保持會話信息，會在客戶端保存一份cookie來保持用戶會話有效性，而Token則只用于登錄用戶的身份鑒權。所以在移動端使用Token會比使用Session更加簡易并且有更高的安全性。Restful架構遵循統一接口原則，統一接口包含了一組受限的預定義的操作，不論什么樣的資源，都是通過使用相同的接口進行資源的訪問。接口應該使用預先定義好的主流的標準的Get/Put/Delete/Post操作等。在第三章節會詳細闡述。
04 高并發海量存儲服務
MongoDB是適用于垂直行業應用的開源數據庫，是我們高并發存儲和查詢的***的數據庫。MongoDB能夠使企業業務更加具有擴展性，通過使用MongoDB來創建新的應用，能使團隊提升開發效率。
我們具體分析一下關系模型和文檔模型的區別。關系模型是按照數據對象存到各個相應的表里，使用時按照需求進行調取。舉例子來說，針對一個體檢數據模型設計，在用戶管理信息中包括用戶名字、地址、聯系方式等。按照第三范式，我們會把聯系方式用單獨的一個表來存儲，并在顯示用戶信息的時候通過關聯方式把需要的信息取回來。但是MongoDB的文檔模式，存儲單位是一個文檔，可以支持數組和嵌套文檔，這個文檔就可以涵蓋這個用戶相關的所有個人信息，包括聯系方式。關系型數據庫的關聯功能恰恰是它的發展瓶頸，尤其是用戶數據達到PB級之后，性能和效率會急速下降。
我們采用MongoDB設計一個高效的文檔數據存儲模式。首先考慮內嵌， 把同類型的數據放在一個內嵌文檔中。內嵌文檔和對象可以產生一一映射關系，比如Map可以實現存儲一個內嵌文檔。如果是多表關聯時，可以使用在主表里存儲一個id值，指向另一個表中的 id 值，通過把數據存放到兩個集合里實現多表關聯， 目前在MongoDB的4.0之后開始支持多文檔的事務處理。
我們采用AngularJS框架設計一個高并發調用系統。一提到數據調用就想到了JQuery框架，JQuery框架的設計思想就是在靜態頁面基礎上進行DOM元素操作。目前最成熟的數據調用的主流框架之一是AngularJS框架，AngularJS特別適合基于CRUD的Web應用系統。它簡化了對Web開發者的經驗要求，同時讓Web本身變得功能更強。AngularJS對DOM元素操作都是在Directive中實現的，而且一般情況下很少自己直接去寫DOM操作代碼，只要你監聽Model，Model發生變化后View也會發生變化。AngularJS框架強調UI應該是用Html聲明式的方式構建，數據和邏輯由框架提供的機制自動匹配綁定。AngularJS有著諸多優勢的設計思想，最為核心的是：數據理由、依賴注入、自動化雙向數據綁定、語義化標簽等。依賴注入思想實現了分層解耦，包括前后端分離和合理的模塊化組織項目結構，讓開發者更關注于每一個具體的邏輯本身，從而加快了開發速度，提升了系統的質量。雙向綁定是它的精華所在，就是從界面的操作能實時反映到數據，數據的變更能實時展現到界面，數據模型Model和視圖View都是綁定在了內存映射$Scope上。
下面是我設計的AngularJS 的項目框架，可以應用于所有業務系統，在第四章的體檢報告可視化展示中詳細闡述。建立MVC的三層框架，先建立一個單頁視圖層Main.html, 然后創建一個模型層Service.js, ***創建一個控制層App.js, App.js中包括多個模塊的JS和Html文件，這樣就構建了一個完整的AngularJS MVC框架。
05 高可靠海量存儲服務
高可靠海量存儲是大數據處理的核心需求之一。實際工作中，常常需要實現多模態、不同時間顆粒度的行業數據的統一高效和海量存儲，并提供易于擴展的離線計算和批處理架構，例如，引入 Hadoop和Spark的大數據存儲與計算方案。高可靠數據海量存儲的總體設計中要吸納主流的Hadoop架構，Hadoop集群是一個能夠讓用戶輕松架構和使用的分布式計算平臺，用戶可以在Hadoop上開發和運行處理海量數據的應用程序。它主要有以下幾個優點：
高可靠性。Hadoop按列存儲和處理數據的能力值得信任。Hadoop能夠在節點之間動態地移動數據，并保證各個節點的動態平衡，因此處理速度非常快。
高擴展性。Hadoop是在可用的列簇中分配數據并完成計算任務的，這些集簇可以方便地擴展到數以千計的節點中。
高容錯性。Hadoop能夠自動保存數據的多個副本，并且能夠自動將失敗的任務重新分配。
數據海量存儲的彈性設計中要吸納主流的HBase架構。它是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統，適用于結構化的存儲，底層依賴于Hadoop的HDFS，利用HBase技術可在廉價PCServer上搭建起大規模結構化存儲集群。因此HBase被廣泛使用在大數據存儲的解決方案中。從應用場景分析，因為HBase存儲的是松散的數據，如果應用程序中的數據表每一行的結構是有差別的，使用HBase***，因為HBase的列可以動態增加，并且列為空就不存儲數據，所以如果你需要經常追加字段，且大部分字段是NULL值的，那可以考慮HBase。因為HBase可以根據Rowkey提供高效的查詢，所以你的數據都有著同一個主鍵Rowkey。具體實現見第六章節。
06 實時計算服務
實時計算的總體設計中要考慮Spark生態技術框架。Spark 使用 Scala 語言進行實現，它是一種面向對象、函數式編程語言，能夠像操作本地集合對象一樣輕松地操作分布式數據集(Scala 提供一個稱為 Actor 的并行模型)。Spark具有運行速度快、易用性好、通用性。Spark 是在借鑒了 MapReduce 思想之上發展而來的，繼承了其分布式并行計算的優點并改進了 MapReduce 明顯的缺陷，具體優勢分析如下：
Spark 把中間數據放到內存中，迭代運算效率高。MapReduce 中計算結果需要落地，保存到磁盤上，這樣勢必會影響整體速度，而 Spark 支持 DAG 圖的分布式并行計算的編程框架，減少了迭代過程中數據的落地，提高了處理效率。
Spark 容錯性高。Spark 引進了彈性分布式數據集 RDD (Resilient Distributed Dataset) 的抽象，它是分布在一組節點中的只讀對象集合，這些集合是彈性的，如果數據集一部分丟失，則可以根據“血統“對它們進行重建。另外在 RDD 計算時可以通過 CheckPoint 來實現容錯。
Spark 具備通用性。在Hadoop 提供了 Map 和 Reduce 兩種操作基礎上，Spark 又提供的很多數據集操作類型有，大致分為：Transformations 和 Actions 兩大類。Transformations 包括 Map、Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、oin、Cogroup、MapValues、Sort 和 PartionBy 等多種操作類型，同時還提供 Count, Actions 包括 Collect、 Reduce、Lookup 和 Save 等操作。
強大的SparkMLlib機器學習庫，旨在簡化機器學習的工程實踐工作，并方便擴展到更大規模。MLlib由一些通用的學習算法和工具組成，包括分類、回歸、聚類、協同過濾、降維等，同時還包括底層的優化原語和高層的管道API。具體實現見第六章節。
07 基于機器學習的智能分析服務
智能分析服務的總體設計中要考慮Spark MLlib工具。當今主流的建模語言包括R語言，Weka，Mahout和Spark等，我們來分析一下它們的基因和應用場景。
R是一種數學語言，里面封裝了大量的機器學習算法，但是它是單機的，不能夠很好的處理海量的數據。Weka和R語言類似，里面包含大量經過良好優化的機器學習和數據分析算法，可以處理與格式化數據轉換相關的各種任務，唯一的不足就是它對高內存要求的大數據處理遇到瓶頸。
Mahout是hadoop的一個機器學習庫，有海量數據的并發處理能力，主要的編程模型是MapReduce。而基于MapReduce的機器學習在反復迭代的過程中會產生大量的磁盤IO，即本次計算的結果要作為下一次迭代的輸入，這個過程中只能把中間結果存儲磁盤，然后在下一次計算的時候從新讀取，這對于迭代頻發的算法顯然是致命的性能瓶頸。所以計算效率很低。現在Mahout已經停止更新MapReduce算法，向Spark遷移。另外，Mahout和Spark ML并不是競爭關系，Mahout是MLlib的補充。
MLlib是Spark對常用的機器學習算法的實現庫，同時包括相關的測試和數據生成器。Spark的設計就是為了支持一些迭代的Job, 這正好符合很多機器學習算法的特點。在邏輯回歸的運算場景下，Spark比Hadoop快了100倍以上。Spark MLlib立足于內存計算，適應于迭代式計算。而且Spark提供了一個基于海量數據的機器學習庫，它提供了常用機器學習算法的分布式實現，工程師只需要有 Spark基礎并且了解機器學習算法的原理，以及方法中相關參數的含義，就可以輕松的通過調用相應的 API 來實現基于海量數據的機器學習過程。具體實現見第八章節。
08 自定義遷移服務
數據遷移能力的總體設計中要考慮Sqoop框架。Sqoop是一個目前Hadoop和關系型數據庫中的數據相互轉移的主流工具，可以將一個關系型數據庫(MySQL ,Oracle ,Postgres等)中的數據導入到Hadoop的HDFS中，也可以將HDFS的數據導入到關系型數據庫中。作為ETL工具，使用元數據模型來判斷數據類型，并在數據從數據源轉移到Hadoop時確保類型安全的數據處理。Sqoop框架可以進行大數據批量傳輸設計，能夠分割數據集并創建Hadoop任務來處理每個區塊。具體實現見第九章節。
【本文為51CTO專欄作者“移動Labs”原創稿件，轉載請聯系原作者】
