前段時間有報道稱，有學者質疑“大資料”理論，也有矽谷公司負責人質疑大資料應用的效果。結合2011年Gartner關於BI（Business Intelligence）應用70%-80%都失敗的一個調查結論（這裡的fail是誇張的說法，更確切地講應該是沒有達到預期效果），本文就來談談為什麼會出現這樣的問題，大資料應用落地的瓶頸是什麼？為什麼大資料應用容易失敗？為什麼大資料應用需要敏捷？敏捷大資料方法論又是什麼，包括那些關鍵技術，系統架構如何設計等等問題，希望能為業界大資料應用落地提供一點有價值的參考。

大資料應用落地的主要瓶頸是什麼？

我在前文《論大資料的泡沫、價值與應用陷阱》有說到，大資料現象源於我們對未來不確定性的恐懼，和應對軟體在加速吞噬世界（軟體越來越龐雜，操作越來越自動化，資料越來越豐富，而大部分人卻對其原理和特性卻知之甚少）這一大背景下的管理失控問題。大資料規律的可預測性創造了一種新的知識體系和管理思維，但分析模型的黑箱和操作的自動化卻削弱了人類對其深層規律的理解和探索能力，機器的量化能力與人的主觀判斷能力短時間內還難以有機融合，大資料應用不缺預測模型、計算資源和資料科學家，而是缺乏提出正確問題和利用大資料工具解決問題的能力，就好比用大炮沒有打到蚊子，我們不能說大炮沒用，而會說這個人的方法搞錯了。

在這裡我還是要推薦下我自己建的大資料學習交流扣扣裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 

“Between 70% to 80% of business intelligence projects fail”- Gartner, Feb. 2011

大資料分析的核心目標是，面向過去，發現數據規律，歸納已知；面向未來，挖掘資料趨勢，預測未知。從而通過大資料分析提高對事物的理解和決策處置能力，最終實現智慧化。不管是商業智慧，機器智慧，人工智慧，還是智慧客服，智慧問答，智慧推薦，智慧醫療、智慧交通等相關技術和系統，其本質都是朝著這一目標在演進。隨著雲端計算平臺和開源大資料系統（如Hadoop、Spark、Storm等）的高速發展，獲得大資料基礎設施建設相關技術和支援越來越容易。同時，移動網際網路和物聯網技術所具備的全面資料採集能力，客觀上促進了大資料的積累和爆發。但是，大資料應用要落地，除了需要上述提出正確問題和利用大資料工具解決問題的能力之外，個人認為還面臨如下幾個方面的主要瓶頸：

1）IT向DT（Data Technology,DT）技術泛型的轉變，使得傳統硬體和軟體技術架構面臨挑戰，大規模平行計算、量子計算機、深度神經網路晶片、分散式儲存系統、GPU大規模計算等都是對傳統IT技術架構的顛覆。現階段各種大資料分析相關的開源技術和系統百花齊放，大資料技術生態體系龐雜，技術門檻較高也間接說明了這一點。研究、研發人員要跟上這一波技術變革還需要時間去消化和積累，特別是學術界和工業界的結合，對大資料應用來講至關重要，深度學習領域的突破就是例證。如何在掌握有限技術的條件下（或受制於核心技術人才的情況下），能快速進行大資料應用研究和落地應用，需要從技術選型角度進行深入探討、分析和評估。

2）傳統商業智慧（Business Intelligence, BI）應用的失敗教訓太多，專案週期漫長，考驗客戶耐性，應用投入成本高，最終成果多是昂貴的豪華報表，沒有達到預期效果。另外，傳統資料倉庫和資料集市架構下，面對海量資料的儲存能力、擴充套件能力、併發能力弱等問題無法從根本解決。大資料分析如何從BI專案中總結失敗教訓和獲得經驗，大資料應用與傳統BI系統是融合還是代替？企業大資料技術架構如何與發源於網際網路巨頭的主流大資料技術框架有機統一？也還有很多問題需要深入總結，解決不好就會事倍功半。

3）大資料應用的標準化和產品化問題。針對大資料的多源異構、動態性、關聯性等特點，對大資料分析流程和應用進行標準化的管理，對離線分析、線上分析、實時分析、記憶體分析等計算框架的融合處理，對影象、文字、視訊、音訊、網頁、關係資料庫等多源異構資料進行跨模態建模，對大資料分析結果的應用效果進行量化與評價。不管是從技術選型角度還是業務支撐角度，都還有很多問題需要實戰經驗的積累和支援，想要一勞永逸地解決不現實。

4）除了前述探討的大資料應用面臨的挑戰之外，從大資料架構本身的技術角度分析還需要解決如下幾個關鍵問題：高可擴充套件性，能支援大規模資料增長和大量業務分析的快速擴充套件等；高容錯性和穩定性，能支援大資料分析的失敗情況和進行自動恢復等；高效能和並行支援，能在海量資料條件下快速完成多種計算模型和分析處理；多源異構環境支援，能處理多模態資料和多種分析任務；開放性和共享支援，能提供標準的資料和開發介面，支援資料和系統整合；效率和成本的控制，能在有限的時間、人力和財力條件下提高系統性能等，這對大資料系統架構的設計提出了較高要求。

5）大資料管理思維和開發、應用實施的脫節，大資料強化了定量科學和客觀方法的地位，但事實上，現階段很多企業領導，包括技術人員對大資料的處理和使用仍然是主觀性的，而且面對機器學習的黑箱，對模型的缺陷和適用範疇很難有深入把握，這樣的話通過大資料探勘分析量化的結果也未必更符合客觀事實，大資料不等於好資料，如何切實輔助決策才是關鍵。

再則，大資料是非常碎片化的，大資料不只是谷歌，亞馬遜，BAT等網際網路企業，每一個行業、企業裡面都有它去關注資料的痕跡：一條生產線上的實時感測器資料，車輛身上的感測資料，高鐵裝置的執行狀態資料，交通部門的監控資料等等；其次，現在的開源大資料系統架構和工具集來源於網際網路巨頭，這種技術架構不一定適合傳統企業和政府關聯機構，因為不同組織機構所擁有的資料型別和結構可能大不相同；再次，從大資料應用過程和特點來看，資料科學的本質是迭代，就好比嬰兒的學習一樣，輸入-迴應-反饋-學習-再輸入，持續訓練和學習才會產生智慧，大資料分析系統是一樣的道理，自適應優化和持續改進是大資料系統的必備特徵。所以，這就需要大資料技術架構具有極強的靈活性、可擴充套件性，或者說敏捷性。

 大資料應用為什麼需要敏捷？

上述五個方面的大資料應用瓶頸分析可以看到，大資料應用要切實落地併產生應有價值還要較長的路要走，當然這取決於我們的期望，在《企業大資料應用三段論》一文中，有明確的界定，大資料應用的效果不能輕易否定，當然也不能太樂觀，關鍵還是看處於那個階段，技術成熟度和設計研發能力如何等等。為什麼大資料需要敏捷，或者說我為什麼提出敏捷大資料，主要基於上述大資料應用瓶頸的判斷：大資料應用落地面臨很多現實問題，首先我們看大資料的應用過程和特點（如圖1），大資料要完成的是一種將各方面源資料（零散的、相關的圍繞某行業或者某分析主題的資料）通過ETL組織成為主題資料，從主題資料中提煉資訊特徵，從特徵挖掘中發現規律和有價值的知識，就規律和預測等知識資訊形成決策支援並進行應用和追蹤評估，最後反饋回大資料系統進行反覆驗證、優化並持續迭代的閉環資訊處理過程。

圖1 大資料應用金字塔模型

其次，有沒有通用的大資料應用架構和流程？一般來講，不同行業、不同企業、不同應用場景，採用的技術架構和分析流程也會有差異；再次，大資料應用落地需面對的現實問題眾多，專案週期漫長，考驗客戶耐性，技術生態龐雜，複合型人才少，一將難求，應用效果如何量化也還沒標準，使用者參與度低，難達預期目標，機器學習資料實驗，如何應用於資料工程等等問題，對大資料分析的系統架構、關鍵技術及應用方法論，提出了較高要求，下面就來看敏捷大資料能否解決一些問題。

 敏捷大資料方法論

（1）何為敏捷？

何為敏捷，我們先看幾個概念：

敏捷開發（Agile Development），以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷管理（Agile Management），敏捷管理是規劃和指導專案流程的迭代方法，與敏捷軟體開發一樣，敏捷專案是在叫做迭代的小型部門中完成的。每個迭代都由專案團隊審查和評判，從迭代的評判中獲得的資訊用於決定專案的下一個步驟。由於開發週期短，對需求管理恰當，敏捷管理正在從軟體研發行業延伸到已經採取專案化管理的大部分行業中。

精益生產（Lean Production），簡稱“精益”，是衍生自日本豐田生產方式的一種管理哲學，由美國麻省理工學院教授詹姆斯．P．沃麥克等專家通過“國際汽車計劃(IMVP)”對全世界17個國家90多個汽車製造廠的調查和對比分析，認為日本豐田汽車公司的生產方式是最適用於現代製造企業的一種生產組織管理方式，精益生產是通過系統結構、人員組織、執行方式和市場供求等方面的變革，使生產系統能很快適應使用者需求不斷變化，並能使生產過程中一切無用、多餘的東西被精簡，最終達到包括市場供銷在內的生產的各方面最好結果的一種生產管理方式。

精益思維（Lean Thinking）和精益管理（Lean Management），源於精益生產，精益管理由最初的在生產系統的管理實踐成功，已經逐步延伸到企業的各項管理業務，也由最初的具體業務管理方法，上升為戰略管理理念。精益管理要求企業的各項活動都必須運用“精益思維” (Lean Thinking)。“精益思維”的核心就是以最小資源投入，包括人力、裝置、資金、材料、時間和空間， 創造出儘可能多的價值，為顧客提供新產品和及時的服務。

圖. 現代軟體工程，基礎技術工具棧已經很成熟，搭積木式敏捷開發與精益製造有著相似理念

從上述概念定義可以看出，敏捷和精益是對孿生姐妹，其關鍵詞涉及需求進化，迭代，視覺化，循序漸進，可整合可執行，精益，最小資源投入等。單體應用系統建設，傳統軟體工程對敏捷開發和精益管理思想的需求並不迫切，而面對多源、異構、協作式大資料系統的架構設計、研發和專案實施來講，敏捷和精益設計理念至關重要，為什麼這樣講？下圖是典型的傳統資訊化技術架構與大資料系統架構的一個對比，有經驗的朋友們應該可以看出一些端倪。

圖2 傳統資訊系統與大資料系統架構對比

在這裡我還是要推薦下我自己建的大資料學習交流扣扣裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 

上圖左邊部分為傳統資訊化技術架構，右邊部分為常見大資料系統架構，當然其中具體的技術元件選型根據不同的需求也不一樣，這種架構不是固定的，其中每個元件至少有幾個替代品，而且可以根據需要進行擴充套件。從這個圖我們可以得出這樣的結論，傳統資訊系統可以一人打天下，而大資料系統的核心思想卻是分散式和團結協作，一個人的力量再大，智慧再高，精力再強，也不如一群人有效整合後的力量大，而大資料系統架構就是負責多方面的整合（Hadoop,Spark等大資料基礎系統架構同理，如圖3-Hadoop系統架構示意圖），換句話說，這就像是軟體研發或生產過程中的敏捷和精益管理，由公司大領導（Master）進行分配任務，人員調配，每位員工（slave）努力完成自己負責的小目標工作，各級主管進行橫向和縱向協同，有效整合起來就是公司的大目標，可見大資料系統架構的演變已經是很接近人類社會協作的思想了。而要有效支撐大資料系統架構的分散式協作能力，敏捷和精益設計思想是很有必要的參考。

圖3 Hadoop系統架構示意圖

 （2）敏捷大資料定義

那什麼是敏捷大資料呢，本文暫且給出一個初步的定義（還不夠成熟）：“敏捷大資料是基於資料科學的迭代性本質和敏捷研發管理思想，利用構件化、服務化和容器化等技術，對大資料系統架構和關鍵元件協作等進行精益設計，逐步實現多層次資料的融合處理和多種計算框架、模型的擴充套件和高效管理，快速響應大資料分析需求，快速構建大資料生產系統，快速迭代大資料分析能力，從而提升大資料系統的分析效率和大資料決策價值”。敏捷大資料的核心要素遵從SFV原則（Small，Fast，Validation, SFV）：一是小、二是快、三是證，小的業務分析目標切入，快速出原型快速迭代，證明有效之後再擴張。從某種程度上講，傳統BI專案的失敗很多是沒有把握好這三個原則，而網際網路企業的大資料系統能成功，能使開源大資料技術百花齊放，是因為把握好了這三個原則。

敏捷大資料要解決如下關鍵問題：如何實現統一的、標準化的、模組化、可配置的大資料架構，以解決不同型別的異構子系統之間難以有效整合的問題。應用功能可以使用已有的功能元件組合而成，通過服務複用降低成本，在元件之間交換的資料形式應當標準化和介面化；元件的組合只需少量程式設計或配置便可以完成，常用模型和工具的整合標準化，如何簡化使用，可以對非程式設計師提供開箱即用的資料探勘和分析能力；大資料應用全程（採集、儲存、分析、管理）視覺化操作。基於資料科學的迭代性本質和利用高效元件化工具，對大資料各功能子系統（模組）進行元件化，模型標準化設計，並根據實際需求快速選型、快速配置、快速搭建大資料原型系統，快速迭代大資料分析結果，並順應不斷變化的需求，儘快將原型轉化成生產系統。在快速迭代、快速反饋、閉環驗證過程中，讓客戶逐步完成大資料分析的系統思維和管理思維變革，天下武功，唯快不破，快小證原則和精益設計，這是敏捷大資料應用的核心目標。

圖4 敏捷迭代開發示意圖

（3）敏捷大資料流程優化

根據敏捷大資料快、小、證SFV原則，我們對傳統的跨行業資料探勘標準流程（Cross-industry Standard Process for Data Mining ,CRISP-DM）進行了改進，提出了基於微服務和容器（後續敏捷大資料關鍵技術章節會做詳細介紹）的敏捷大資料處理流程（Agile Big Data Processing based on Micro-services）,如下圖：

圖5. CRISP-DM流程與敏捷大資料處理流程

敏捷大資料處理流程相比傳統資料探勘流程，從兩個層面進行了擴充套件：首先是架構上採用基於容器的微服務技術進行支撐；其次針對傳統資料探勘模型、系統和現實決策反饋的脫節問題，根據資料科學迭代性本質特點，對模型系統和現實決策反饋兩個過程分別進行自適應迭代升級和智慧決策進化支援。通過這種擴充套件，使得敏捷大資料方法論與傳統資料探勘技術，以及和新興的主流大資料框架，能在架構和流程上進行互補和融合。要實現敏捷大資料SFV原則，敏捷大資料架構的設計至關重要。敏捷大資料架構需要在元件化管理、資料融合、資源排程、服務抽象、部署運維、計算模型和標準資料集的服務化，以及敏捷大資料處理流程等多個層面，進行科學有效地設計支撐。核心目標是要實現大資料的融合處理和分析功能的服務化、標準化和流程化，基於資料融合和微服務技術，設計模組化、可配置的大資料分析平臺，對微服務的構建和管理進行快速實現，通過各種微服務的劃分、組合、編排和動態配置，形成可複用的、可擴充套件的和可靈活調整的大資料分析系統，從而實現敏捷大資料目標。

4．敏捷大資料關鍵技術

大資料時代，各種新興技術和計算框架層出不窮，加之分析需求的不斷變化，如何使大資料架構能隨時調整以適應業務需求，跟上技術更新的步伐，是大資料應用要解決的關鍵問題，這也是為什麼提出敏捷大資料架構的本質原因。面對大型企業動輒數十個上百個資訊系統，如何通過跨物理、虛擬、公共和私有云環境實現一致性、互操作性和可移植性，對IT基礎設施來講是極大的挑戰。所以微服務和容器技術應運而生，微服務實現系統模組的元件化和獨立自治執行，容器能實現輕量級的虛擬化，而且完全使用沙箱機制，相互之間沒有任何介面。微服務、容器與雲端計算技術的天然結合，及其快速的研發、部署、維護優勢，使得基於微服務和容器的敏捷大資料應用潛力巨大。

在這裡我還是要推薦下我自己建的大資料學習交流扣扣裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 

 （1）微服務技術

服務的本質就是行為的抽象，面向物件的方法是從物件實體這個維度對世界進行描述，而面向服務（SOA）則是從行為模式這個維度對世界進行描述，本質上是兩種不同維度的描述方法。

圖6. 軟體服務化發展歷程

由於資料科學的迭代性本質，大資料分析即服務成為應用熱點，而微服務與容器技術能有效支援本文提出的敏捷大資料SFV核心原則。近年來，微服務（設計思想發源於康威定律，如圖7）成為網際網路和大資料企業的研究和設計熱點，諸如谷歌、亞馬遜、Facebook、百度、京東、攜程等公司都在採用微服務理論和技術進行產品的設計、研發和部署。Netflix公司的Adrian Cockcroft將微服務稱為“細化SOA(Service Oriented Architecture, SOA)”，並認為這是一套具備開創意義的新型架構。敏捷之父Martin Fowler在他的《Micro services》一文中給出了微服務的定義，概括來說，微服務設計思想是一種使用若干小服務開發龐大應用的方法，每個服務執行在自己的程序中，通過輕量級的通訊機制進行資訊互動，每個微服務的粒度基於業務能力大小進行構建，並可以由不同的程式語言實現，構建的服務鏈能夠通過容器等技術進行自動化部署。

圖7. 康威定律（Conway’s Law），系統的結構受限於設計這個系統的組織的溝通結構。由於系統的結構可能會隨著設計的深入而變化，所以必須保持設計的精簡與靈活。

從上述微服務定義可以看到，去中心化、原子化、獨立自治、快速組合、自動部署等特性是微服務技術的核心要素，中心思想是將一個單體應用構架打散，把原來龐大的應用層功能切分成粒度較小的微服務模組，資料庫也按微服務功能單元進行相應的拆分進行支援（如圖8所示），採用基於雲的容器技術單獨執行這些服務模組，通過網路和輕量級通訊機制將這些分解的服務模組協同連線起來，形成微服務簇和網路，完成大型複雜任務，這種通過將複雜系統切分成若干小的微服務模組的方式，其分散式、低耦合架構能極大地適應大資料分散式處理特性。

圖8 傳統單體應用架構與微服務架構的區別

 （2）容器技術

微服務技術採用類似搭積木的構建方法，使得服務之間不相互影響，而且同一個系統的微服務可以採用不同的開發語言和資料庫技術。但是面對大型企業動輒數十、上百個資訊系統，如何通過跨物理、虛擬、公共和私有云環境實現一致性、互操作性和可移植性，對IT基礎設施來講是極大的挑戰。所以容器技術應運而生，容器最早由Docker公司提出並應用於自家的PaaS雲服務平臺，近年來獲得廣泛認可，很多大型企業開始將單體應用系統微服務化，並部署在容器中。容器基於作業系統之上能實現相比傳統虛擬化技術（如VMware）更輕量級的虛擬化，而且完全使用沙箱機制，相互之間沒有介面。Hadoop的子系統Kubernetes已經能支援基於雲端計算和Docker容器技術的微服務開發和部署，容器技術與雲端計算的天然結合及其快速的研發、部署、維護優勢，對於微服務和敏捷大資料架構的設計和實現具有重要支撐作用。 

圖9 Docker容器架構圖

 （3）資料融合技術

由於大資料呈現的關聯性、動態性、多源異構性等特點，導致大資料的儲存、挖掘、分析和理解面臨極大挑戰。如何對多種形態格式的資料進行統一標準化融合處理，是敏捷大資料要解決的關鍵問題。與一般的大資料融合目標不同，本文主要從構建標準資料集的角度進行大資料多粒度融合，通過構建統一資料單元（unified data units，UDU）來支援多模態特徵融合和多種型別、結構資料集的封裝融合。將多源異構資料進行抽取、融合、整合為支援不同計算模型處理的UDU資料集，是多粒度資訊融合技術的核心目標。統一資料單元是獨立的和靈活的實體資料集，可隨資料來源和分析需求的變化進行快速重組、調整和更新。通過資訊融合形成的UDU標準資料集，是進行敏捷大資料處理的基礎。

在這裡我還是要推薦下我自己建的大資料學習交流扣扣裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 

針對機器學習各類模型的資料適配特點，我們提出了一種標準資料集定義：統一資料單元（UDU）對大資料多個層次和粒度的資訊進行融合處理。特別是對多模態資料，通過統一資料單元設計方法能實現資料的儲存優化和機器學習模型資料輸入的標準化，以統一資料單元作為敏捷大資料系統的基本資料組織和處理單元，能提高大資料分析模型和演算法的適應性和敏捷性，提升大資料處理能力。多粒度資訊融合設計如下圖所示。

圖10 大資料多粒度資訊融合設計

上圖的UDU統一資料單元至少可以支援三個層面的大資料融合，一是特徵級融合，支援跨模態特徵（如時間+空間特徵）的大資料計算模型處理；二是資料級融合，支援多維資料立方體（Data Cube），資料集市（星型，雪花型模式）等資料模式和資料結構的融合；三是模型級融合，從不同模型任務（如分類、聚類、預測、關聯等模型）角度支援相應的資料單元處理。設計和構造大資料統一資料單元，需進行如下三個環節的處理。

1）特徵抽取：對結構化資料、半結構化資料和非結構化資料進行資料整合和特徵抽取，抽取出資料中的各類不同特徵，包括時間特徵、空間特徵或其他全域性特徵等，實現對資料相關的位置屬性、時間空間關聯屬性和其他觀測屬性等的特徵描述。

2）融合封裝：抽取出來的各類資料特徵，或者初步預處理後的資料，根據不同的計算模型資料處理特點和要求，封裝成結構和格式統一的資料處理單元，形成標準分析資料集，為上層的挖掘計算服務提供快速資料適配。可以通過元資料定義方法和XML/JSON等技術，實現不同種類的統一資料單元定義，對每類統一資料單元進行基本資訊和各類屬性定義和描述，包括標識ID、基本屬性、語義屬性、結構屬性等內容。3）服務介面：封裝好的統一資料單元資料集，針對不同的挖掘計算服務模型實現快速資料適配，設計統一的資料單元呼叫介面，通過介面定義和引數設定對封裝資料單元進行解析，並對資料集各類屬性特徵、結構資訊等進行提取。

敏捷大資料系統架構

根據上述敏捷大資料關鍵技術的分析，如何設計實現有效的敏捷大資料系統架構是敏捷大資料應用的重點內容。下面以交通大資料處理為例，對其敏捷處理架構進行了初步設計。由於交通大資料的複雜性和分析目標的多樣性，對傳統的資料探勘分析模式和大資料技術架構提出了挑戰。例如，針對海量交通曆史靜態資料，需採用離線批處理技術，而動態實時流交通資料則需要流式計算框架進行處理。另外，對文字、影象、視訊、感測器等多模態資料需採用不同的機器學習模型進行處理，如何進行跨模態的融合計算分析也是應用難點。針對交通大資料分析需求的變更和擴充套件，大資料系統如何進行快速響應和功能、模型的擴充和調整，是面向交通的敏捷大資料架構設計要解決的關鍵問題。

換句話說，要能根據不同的交通大資料分析需求設計靈活的處理架構進行支援，大資料架構要能從採集、儲存、計算、應用多個層面，滿足不同分析需求的變更或擴張。基於敏捷大資料方法論及其關鍵技術的分析和研究，從資料採集整合、大規模資料儲存和資料融合、多模式/多模態計算微服務、資料應用4個層面進行了敏捷大資料架構設計。通過基於多粒度大資料整合融合構建統一資料單元，形成標準資料集，通過基於微服務的計算模型抽象和匯聚層處理，實現交通大資料探勘的敏捷化、服務化。採用標準介面和外掛開發的方式，對大資料主流處理框架（如Hadoop、Spark、Storm等）能進行統一配置管理，基於即插即用的構件化和服務化設計，各層子系統和元件可根據分析目標進行快速選型、靈活配置，構建原型和迭代升級（如下圖中根據兩條虛線不同的設計路徑，可以快速配置實現歷史資料庫資料的批處理分析，或公網採集資料的流處理分析），敏捷大資料總體架構設計如下圖所示。

圖11 面向交通的敏捷大資料總體架構設計

1)資料採集層：分3個層面的採集技術進行支援，一是傳統業務系統資料庫和半結構化、結構化資料的採集和整合，如採用Sqoop技術進行關係資料庫和Hadoop系統之間的資料抽取和交換；二是交通實時流資料的採集，包括實時感測器資料、定位軌跡資料和其他實時流資料；三是交通公共資料的採集，包括公網的資料爬取、開放平臺的資料介面、行業公共資料庫的資料交換等。對採集到的資料需進行提取、轉換和載入（extract-transform-load，ETL）處理，包括資料抽取、轉換、清洗和隱私脫敏等預處理工作，預處理整合後的資料進入交通大資料雲端儲存中心。

2)資料儲存層：交通領域資料規模巨大，資料儲存層需設計基於雲端計算的分散式雲端儲存系統，以支援海量資料的儲存擴充套件。提供基於雲的列式儲存、NoSQL儲存或資料倉庫儲存能力；根據業務需求和快速配置，可切換相應的分散式儲存模式，還可根據需要對傳統BI系統的資料倉庫和資料集市進行整合。利用Hadoop叢集提供PB級儲存能力擴充套件，同時Hadoop YARN 和Spark Mesos等叢集資源管理框架可支援多種儲存模式和計算模式（主要對儲存和計算兩個層面資源進行管理，如圖中雙向箭頭所示）的雲資源排程。在此基礎上，對各類儲存資料進行多粒度資訊融合，構建統一資料處理單元，為計算服務層提供標準化的分析資料集。

3)資料計算層：針對交通大資料多源、異構、海量等特徵，傳統的計算模型難以直接處理。資料計算層需滿足主流大資料處理框架的各種計算模型與方法實現，如基於雲端計算並行框架，實現基於Hadoop批處理、Storm流處理、Spark記憶體處理的高效資料探勘與機器學習。資料計算層採用基於統一資料處理單元和計算模式、模型微服務化的大資料分析框架，通過構建多種微服務簇網路（主要分計算微服務、資料微服務和流程微服務，涵蓋儲存和計算兩個層面，如圖中雙向箭頭所示），為應用層提供支援MapReduce、Storm、Spark等多種計算模式下的多種資料探勘模型與方法（如分類、聚類、序列等）；根據大資料分析需求和資料特徵，可基於元件配置和服務治理技術進行各類服務的快速切換和靈活管理。

4)資料應用層：資料應用層首先要滿足智慧交通各類大資料分析需求，包括基本的視覺化與查詢、展示、探索等，分析結果能結合知識庫應用於決策支援。另外，大資料系統本身管理方面，針對構件化和微服務設計，需對相關中介軟體進行設計，實現服務治理、元件配置、安全、介面等功能，以支撐儲存層和計算層各類微服務的敏捷管理。

在這裡我還是要推薦下我自己建的大資料學習交流扣扣裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 

敏捷大資料架構的關鍵內容除了資料融合UDU層面之外，另外一個關鍵環節就是對多種計算模式框架、多種計算模型的微服務化設計，包括計算框架、模型和演算法的微服務化、資料獲取呼叫的微服化和分析流程的微服務化等層面。其核心是計算微服務，如MapReduce批處理服務、Storm流處理服務、Spark記憶體處理服務，每種大的計算框架微服務下包含具體挖掘模型等小粒度的計算微服務支援（如分類模型服務、序列模型服務）等。由於微服務詳細技術涉及面比較廣，包括微服務的註冊、定位、發現和搜尋（基於分散式一致演算法Paxos和Zookeeper框架等），微服務的輕量級通訊機制如REST(Representational State Transfer)、RPC(Remote Procedure Call Protocol)、IPC(Inter-Process Communication)等，微服務的容錯處理（熔斷、限流、負載均衡等），微服務容器化和服務的測試、部署等方面。由於篇幅原因，各方面的技術細節這裡不做贅述，大家可以參考專業資料進行了解。在敏捷大資料架構和資料融合統一資料單元基礎上，進行了大資料分析層的微服務設計，如下圖。

圖12  面向交通的大資料分析微服務化設計

大資料分析微服務化的核心理念是一個服務只專注做好一類或一個分析，服務的粒度和分析功能大小、邊界要匹配，服務方（計算微服務）和消費方（基於微服務的分析功能）要能解耦，即調整或升級一個微服務不能影響其他微服務。大資料分析微服務設計主要內容包括如下幾個方面。

1）大資料分析業務抽象和微服務劃分：按多模式計算框架分，有MapReduce批處理框架、Storm流式處理框架、Spark記憶體處理框架、圖計算框架等；按挖掘模型分，有分類、聚類、序列、多模態、多工等不同種類計算模型。針對交通大資料各類分析需求和資料處理特點，進行大資料業務分析和抽象建模，並選擇相應的計算模型和計算框架進行支撐，再決定需要哪些微服務，並實現微服務的劃分和組合，設定好微服務網路的總體設計目標，並通過統一的微服務介面（Microservices API Gateway）進行呼叫。

2）微服務簇設計及契約介面定義：針對大資料處理特點，服務層中的微服務分3類進行規劃設計，資料微服務簇負責從UDU標準資料集中進行資料獲取、資料同步和更新等操作；計算微服務簇是敏捷大資料處理的核心，按多模式計算框架和多類計算模型兩個維度進行挖掘分析服務的統籌設計；流程微服務簇負責資料微服務、計算微服務的協同處理，同時對系統元件的配置管理和排程進行支援。各類微服務通過REST、RPC等輕量級通訊機制和MessageBroker等訊息服務進行互動和聯絡[14]，構建微服務簇網路，並通過服務路由進行統一管理和排程。

3）微服務治理和容器部署：由各類微服務簇連線成的微服務網路，其高效協調工作離不開微服務治理技術和容器管理技術。通過服務路由和服務治理負責各種大小微服務的註冊、搜尋、發現、通訊和統一配置，最後基於雲端計算和容器技術進行微服務的自動部署和動態管理。

 敏捷大資料應用評述

本文提出的敏捷大資料架構在一定程度上實現了大資料融合處理和挖掘計算的服務化、標準化和流程化。基於統一資料單元和計算、流程微服務設計思想，對微服務的構建和管理進行快速實現，通過各種微服務的劃分、組合、編排和動態配置，能構建模組化、可配置、可複用、可擴充套件的敏捷大資料分析系統。相比傳統大資料處理架構，敏捷大資料架構在如下幾個方面具有明顯優勢（見表1）。

表1  敏捷大資料架構與傳統大資料架構比較分析

從上述各項特性的比較分析可以看到，敏捷大資料架構除了支援大規模資料增長之外，更重要的是能適應大資料分析業務的擴充套件和變化，通過容器和服務化技術，具備高容錯性和穩定性，能支援大資料分析的失敗處理和自動恢復等，能在海量資料條件下快速完成多種計算模型和分析處理，能基於資料融合單元和計算服務化技術，支援多模態計算和多模式計算任務處理，能在有限的成本條件下提高大資料分析效率。

當然要實現一套有效的敏捷大資料架構，不同的業務需求或採用不同的技術路線，所做的工作可能有較大差異，所以本文的標題定義為方法論。條條大路通羅馬，技術只是工具，關鍵還是方法論和指導思想。另外在架構詳細設計和實現方面，還有幾個難點需要突破，由於大資料計算框架眾多、每種框架下所支援的分析模型也很多、視覺化庫更多…這些計算框架的技術架構和開發語言、介面定義標準可能都不一樣，敏捷大資料架構如何通過構建化、外掛化等技術對上述工具集進行標準化和流程化的快速整合，這是敏捷實現要解決的主要問題。

我們結合正在規劃建設的綜合交通大資料分析雲服務平臺，以本文提出的敏捷大資料方法論及架構設計，作為關鍵技術選型和技術路線實現的指導思想，並進行了初步應用。綜合交通大資料分析雲服務平臺的主要目標是通過大資料技術解決交通資源的供需智慧匹配和瓶頸預測分析問題。應用多粒度資訊融合和多模態計算微服務技術，對交通大資料進行整合、融合和挖掘；採用定量分析和定性分析相結合的機器學習進行供求配置預測，為智慧出行推薦、交通樞紐瓶頸分析、多模接駁換乘、實時交通管控等智慧交通關鍵環節提供大資料分析和決策支援。由於綜合交通大資料多源異構、時空關聯和動態處理等特點，傳統大資料架構面臨擴充套件性、相容性、穩定性諸多問題。基於敏捷大資料方法論，設計了面向智慧交通的具有構件化、雲服務化、容器化特性的敏捷大資料架構，為綜合交通大資料分析雲服務平臺的研發提供了切實參考和應用指導，並在一定程度上提高了開發效率和控制了技術風險。

總結與展望

探討了大資料應用落地的主要瓶頸和麵臨的挑戰。針對大資料特點及其分析瓶頸問題，分析了傳統資訊化技術架構與大資料系統架構的區別，基於敏捷、精益和迭代設計思想，首次提出了敏捷大資料方法論，並對其概念定義、核心要素、流程優化和關鍵技術等內容進行了論述，通過分析敏捷大資料的設計緣由，基於傳統資料探勘流程改進，設計了面向微服務的敏捷大資料處理流程，並對其關鍵支撐技術進行了初步研究和探索。構建了基於微服務和多粒度資訊融合技術的敏捷大資料架構，並結合實際案例對交通大資料微服務化、交通大資料融合等關鍵技術環節進行了詳細設計和論述。

敏捷大資料的提出是基於資料科學迭代性本質，為各行業大資料應用環境下的高效、靈活大資料系統建設和機器學習、知識發現提供了新方法、新思路和新的技術架構，希望能通過敏捷設計最大程度降低成本、控制風險，從而發揮出大資料的應用價值，相比傳統大資料處理方法和技術架構，本方法論的重要意義和參考價值不言而喻。當然，敏捷大資料作為一個新的涵蓋多種前沿資訊科技的跨領域應用研究問題，還需要在設計方法、關鍵技術和系統架構等方面進行深入探索和應用實踐。

關注微信公眾號：程式設計師交流互動平臺！獲取資料學習！