解決大規模數據的高效計算與存儲

Ⅰ 大數據需突破存儲、性能瓶頸

大數據需突破存儲、性能瓶頸
大數據的核心是大量數據的分析能力
在亟待優先解決的IT問題千頭萬緒的情況下，在大數據價值日益凸顯的背景下，企業需要首先提高數據中心的成本效益，以滿足不斷變化的業務需求，加大大數據的應用和相關基礎設施的構建，滿足對於大數據環境下數據中心高性能、高可擴展性、高安全性和高可用性的要求。
大數據核心分析能力需要強大的後台支撐
所謂大數據，最為核心的就要看對於大量數據的核心分析能力。但是，大數據核心分析能力的影響不僅存在於數據管理策略、數據可視化與分析能力等方面，從根本上也對數據中心IT基礎設施架構甚至機房設計原則等提出了更高的要求。為了達到快速高效的處理大量數據的能力，整個IT基礎設施需要進行整體優化設計，應充分考量後台數據中心的高節能性、高穩定性、高安全性、高可擴展性、高度冗餘，基礎設施建設這五個方面，同時更需要解決大規模節點數的數據中心的部署、高速內部網路的構建、機房散熱以及強大的數據備份等問題。
大數據離不開效益型數據中心的構建
深入了解大數據應用的數據中心經濟學對於提高企業的實際利潤率，具有十分重要的價值。數據中心經濟學能夠提供一個框架，幫助IT管理者認識存儲的總體擁有成本（TCO）的長期價值影響。利用數據中心經濟學確定存儲決策、計算資源的准確支出，將能夠幫助企業系統化地持續降低成本，並更好的支持企業採用大數據技術。
大數據更需要突破存儲、性能瓶頸
大數據應用除了數據規模巨大之外，還意味著擁有龐大的文件數量。因此如何管理文件系統層累積的元數據是一個難題，處理不當的話會影響到系統的擴展能力和性能，而傳統的NAS系統就存在這一瓶頸。所幸的是，基於對象的存儲架構就不存在這個問題，它可以在一個系統中管理十億級別的文件數量，而且還不會像傳統存儲一樣遭遇元數據管理的困擾。基於對象的存儲系統還具有廣域擴展能力，可以在多個不同的地點部署並組成一個跨區域的大型存儲基礎架構。此外，大數據應用還存在實時性的問題，特別是涉及到與網上交易或者金融類相關的應用。

Ⅱ 大數據處理的五大關鍵技術及其應用

作者 | 網路大數據

來源 | 產業智能官

數據處理是對紛繁復雜的海量數據價值的提煉，而其中最有價值的地方在於預測性分析，即可以通過數據可視化、統計模式識別、數據描述等數據挖掘形式幫助數據科學家更好的理解數據，根據數據挖掘的結果得出預測性決策。其中主要工作環節包括：

大數據採集 大數據預處理 大數據存儲及管理 大數據分析及挖掘 大數據展現和應用(大數據檢索、大數據可視化、大數據應用、大數據安全等)。

一、大數據採集技術

數據是指通過RFID射頻數據、感測器數據、社交網路交互數據及移動互聯網數據等方式獲得的各種類型的結構化、半結構化(或稱之為弱結構化)及非結構化的海量數據，是大數據知識服務模型的根本。重點要突破分布式高速高可靠數據爬取或採集、高速數據全映像等大數據收集技術;突破高速數據解析、轉換與裝載等大數據整合技術;設計質量評估模型，開發數據質量技術。

大數據採集一般分為：

大數據智能感知層：主要包括數據感測體系、網路通信體系、感測適配體系、智能識別體系及軟硬體資源接入系統，實現對結構化、半結構化、非結構化的海量數據的智能化識別、定位、跟蹤、接入、傳輸、信號轉換、監控、初步處理和管理等。必須著重攻克針對大數據源的智能識別、感知、適配、傳輸、接入等技術。

基礎支撐層：提供大數據服務平台所需的虛擬伺服器，結構化、半結構化及非結構化數據的資料庫及物聯網路資源等基礎支撐環境。重點攻克分布式虛擬存儲技術，大數據獲取、存儲、組織、分析和決策操作的可視化介面技術，大數據的網路傳輸與壓縮技術，大數據隱私保護技術等。

二、大數據預處理技術

完成對已接收數據的辨析、抽取、清洗等操作。

抽取：因獲取的數據可能具有多種結構和類型，數據抽取過程可以幫助我們將這些復雜的數據轉化為單一的或者便於處理的構型，以達到快速分析處理的目的。

清洗：對於大數據，並不全是有價值的，有些數據並不是我們所關心的內容，而另一些數據則是完全錯誤的干擾項，因此要對數據通過過濾「去噪」從而提取出有效數據。

三、大數據存儲及管理技術

大數據存儲與管理要用存儲器把採集到的數據存儲起來，建立相應的資料庫，並進行管理和調用。重點解決復雜結構化、半結構化和非結構化大數據管理與處理技術。主要解決大數據的可存儲、可表示、可處理、可靠性及有效傳輸等幾個關鍵問題。開發可靠的分布式文件系統(DFS)、能效優化的存儲、計算融入存儲、大數據的去冗餘及高效低成本的大數據存儲技術;突破分布式非關系型大數據管理與處理技術，異構數據的數據融合技術，數據組織技術，研究大數據建模技術;突破大數據索引技術;突破大數據移動、備份、復制等技術;開發大數據可視化技術。

開發新型資料庫技術，資料庫分為關系型資料庫、非關系型資料庫以及資料庫緩存系統。其中，非關系型資料庫主要指的是NoSQL資料庫，分為：鍵值資料庫、列存資料庫、圖存資料庫以及文檔資料庫等類型。關系型資料庫包含了傳統關系資料庫系統以及NewSQL資料庫。

開發大數據安全技術：改進數據銷毀、透明加解密、分布式訪問控制、數據審計等技術;突破隱私保護和推理控制、數據真偽識別和取證、數據持有完整性驗證等技術。

四、大數據分析及挖掘技術

大數據分析技術：改進已有數據挖掘和機器學習技術;開發數據網路挖掘、特異群組挖掘、圖挖掘等新型數據挖掘技術;突破基於對象的數據連接、相似性連接等大數據融合技術;突破用戶興趣分析、網路行為分析、情感語義分析等面向領域的大數據挖掘技術。

數據挖掘就是從大量的、不完全的、有雜訊的、模糊的、隨機的實際應用數據中，提取隱含在其中的、人們事先不知道的、但又是潛在有用的信息和知識的過程。

數據挖掘涉及的技術方法很多，有多種分類法。根據挖掘任務可分為分類或預測模型發現、數據總結、聚類、關聯規則發現、序列模式發現、依賴關系或依賴模型發現、異常和趨勢發現等等;根據挖掘對象可分為關系資料庫、面向對象資料庫、空間資料庫、時態資料庫、文本數據源、多媒體資料庫、異質資料庫、遺產資料庫以及環球網Web;根據挖掘方法分，可粗分為:機器學習方法、統計方法、神經網路方法和資料庫方法。

機器學習中，可細分為歸納學習方法(決策樹、規則歸納等)、基於範例學習、遺傳演算法等。統計方法中，可細分為:回歸分析(多元回歸、自回歸等)、判別分析(貝葉斯判別、費歇爾判別、非參數判別等)、聚類分析(系統聚類、動態聚類等)、探索性分析(主元分析法、相關分析法等)等。神經網路方法中，可細分為:前向神經網路(BP演算法等)、自組織神經網路(自組織特徵映射、競爭學習等)等。資料庫方法主要是多維數據分析或OLAP方法，另外還有面向屬性的歸納方法。

數據挖掘主要過程是：根據分析挖掘目標，從資料庫中把數據提取出來，然後經過ETL組織成適合分析挖掘演算法使用寬表，然後利用數據挖掘軟體進行挖掘。傳統的數據挖掘軟體，一般只能支持在單機上進行小規模數據處理,受此限制傳統數據分析挖掘一般會採用抽樣方式來減少數據分析規模。

數據挖掘的計算復雜度和靈活度遠遠超過前兩類需求。一是由於數據挖掘問題開放性，導致數據挖掘會涉及大量衍生變數計算，衍生變數多變導致數據預處理計算復雜性;二是很多數據挖掘演算法本身就比較復雜，計算量就很大，特別是大量機器學習演算法，都是迭代計算，需要通過多次迭代來求最優解，例如K-means聚類演算法、PageRank演算法等。

從挖掘任務和挖掘方法的角度，著重突破：

可視化分析。數據可視化無論對於普通用戶或是數據分析專家，都是最基本的功能。數據圖像化可以讓數據自己說話，讓用戶直觀的感受到結果。 數據挖掘演算法。圖像化是將機器語言翻譯給人看，而數據挖掘就是機器的母語。分割、集群、孤立點分析還有各種各樣五花八門的演算法讓我們精煉數據，挖掘價值。這些演算法一定要能夠應付大數據的量，同時還具有很高的處理速度。 預測性分析。預測性分析可以讓分析師根據圖像化分析和數據挖掘的結果做出一些前瞻性判斷。 語義引擎。語義引擎需要設計到有足夠的人工智慧以足以從數據中主動地提取信息。語言處理技術包括機器翻譯、情感分析、輿情分析、智能輸入、問答系統等。 數據質量和數據管理。數據質量與管理是管理的最佳實踐，透過標准化流程和機器對數據進行處理可以確保獲得一個預設質量的分析結果。

預測分析成功的7個秘訣

預測未來一直是一個冒險的命題。幸運的是，預測分析技術的出現使得用戶能夠基於歷史數據和分析技術(如統計建模和機器學習)預測未來的結果，這使得預測結果和趨勢變得比過去幾年更加可靠。

盡管如此，與任何新興技術一樣，想要充分發揮預測分析的潛力也是很難的。而可能使挑戰變得更加復雜的是，由不完善的策略或預測分析工具的誤用導致的不準確或誤導性的結果可能在幾周、幾個月甚至幾年內才會顯現出來。

預測分析有可能徹底改變許多的行業和業務，包括零售、製造、供應鏈、網路管理、金融服務和醫療保健。AI網路技術公司Mist Systems的聯合創始人、首席技術官Bob fridy預測:「深度學習和預測性AI分析技術將會改變我們社會的所有部分，就像十年來互聯網和蜂窩技術所帶來的轉變一樣。」。

這里有七個建議，旨在幫助您的組織充分利用其預測分析計劃。

1.能夠訪問高質量、易於理解的數據

預測分析應用程序需要大量數據，並依賴於通過反饋循環提供的信息來不斷改進。全球IT解決方案和服務提供商Infotech的首席數據和分析官Soumendra Mohanty評論道:「數據和預測分析之間是相互促進的關系。」

了解流入預測分析模型的數據類型非常重要。「一個人身上會有什麼樣的數據?」 Eric Feigl - Ding問道，他是流行病學家、營養學家和健康經濟學家，目前是哈佛陳氏公共衛生學院的訪問科學家。「是每天都在Facebook和谷歌上收集的實時數據，還是難以訪問的醫療記錄所需的醫療數據?」為了做出准確的預測，模型需要被設計成能夠處理它所吸收的特定類型的數據。

簡單地將大量數據扔向計算資源的預測建模工作註定會失敗。「由於存在大量數據，而其中大部分數據可能與特定問題無關，只是在給定樣本中可能存在相關關系，」FactSet投資組合管理和交易解決方案副總裁兼研究主管Henri Waelbroeck解釋道，FactSet是一家金融數據和軟體公司。「如果不了解產生數據的過程，一個在有偏見的數據上訓練的模型可能是完全錯誤的。」

2.找到合適的模式

SAP高級分析產品經理Richard Mooney指出，每個人都痴迷於演算法，但是演算法必須和輸入到演算法中的數據一樣好。「如果找不到適合的模式，那麼他們就毫無用處，」他寫道。「大多數數據集都有其隱藏的模式。」

模式通常以兩種方式隱藏:

模式位於兩列之間的關系中。例如，可以通過即將進行的交易的截止日期信息與相關的電子郵件開盤價數據進行比較來發現一種模式。Mooney說:「如果交易即將結束，電子郵件的公開率應該會大幅提高，因為買方會有很多人需要閱讀並審查合同。」

模式顯示了變數隨時間變化的關系。「以上面的例子為例，了解客戶打開了200次電子郵件並不像知道他們在上周打開了175次那樣有用，」Mooney說。

3 .專注於可管理的任務，這些任務可能會帶來積極的投資回報

紐約理工學院的分析和商業智能主任Michael Urmeneta稱:「如今，人們很想把機器學習演算法應用到海量數據上，以期獲得更深刻的見解。」他說，這種方法的問題在於，它就像試圖一次治癒所有形式的癌症一樣。Urmeneta解釋說:「這會導致問題太大，數據太亂——沒有足夠的資金和足夠的支持。這樣是不可能獲得成功的。」

而當任務相對集中時，成功的可能性就會大得多。Urmeneta指出:「如果有問題的話，我們很可能會接觸到那些能夠理解復雜關系的專家」 。「這樣，我們就很可能會有更清晰或更好理解的數據來進行處理。」

4.使用正確的方法來完成工作

好消息是，幾乎有無數的方法可以用來生成精確的預測分析。然而，這也是個壞消息。芝加哥大學NORC (前國家意見研究中心)的行為、經濟分析和決策實踐主任Angela Fontes說:「每天都有新的、熱門的分析方法出現，使用新方法很容易讓人興奮」。「然而，根據我的經驗，最成功的項目是那些真正深入思考分析結果並讓其指導他們選擇方法的項目——即使最合適的方法並不是最性感、最新的方法。」

羅切斯特理工學院計算機工程系主任、副教授shanchie Jay Yang建議說:「用戶必須謹慎選擇適合他們需求的方法」。「必須擁有一種高效且可解釋的技術，一種可以利用序列數據、時間數據的統計特性，然後將其外推到最有可能的未來，」Yang說。

5.用精確定義的目標構建模型

這似乎是顯而易見的，但許多預測分析項目開始時的目標是構建一個宏偉的模型，卻沒有一個明確的最終使用計劃。「有很多很棒的模型從來沒有被人使用過，因為沒有人知道如何使用這些模型來實現或提供價值，」汽車、保險和碰撞修復行業的SaaS提供商CCC信息服務公司的產品管理高級副總裁Jason Verlen評論道。

對此，Fontes也表示同意。「使用正確的工具肯定會確保我們從分析中得到想要的結果……」因為這迫使我們必須對自己的目標非常清楚，」她解釋道。「如果我們不清楚分析的目標，就永遠也不可能真正得到我們想要的東西。」

6.在IT和相關業務部門之間建立密切的合作關系

在業務和技術組織之間建立牢固的合作夥伴關系是至關重要的。客戶體驗技術提供商Genesys的人工智慧產品管理副總裁Paul lasserr說:「你應該能夠理解新技術如何應對業務挑戰或改善現有的業務環境。」然後，一旦設置了目標，就可以在一個限定范圍的應用程序中測試模型，以確定解決方案是否真正提供了所需的價值。

7.不要被設計不良的模型誤導

模型是由人設計的，所以它們經常包含著潛在的缺陷。錯誤的模型或使用不正確或不當的數據構建的模型很容易產生誤導，在極端情況下，甚至會產生完全錯誤的預測。

沒有實現適當隨機化的選擇偏差會混淆預測。例如，在一項假設的減肥研究中，可能有50%的參與者選擇退出後續的體重測量。然而，那些中途退出的人與留下來的人有著不同的體重軌跡。這使得分析變得復雜，因為在這樣的研究中，那些堅持參加這個項目的人通常是那些真正減肥的人。另一方面，戒煙者通常是那些很少或根本沒有減肥經歷的人。因此，雖然減肥在整個世界都是具有因果性和可預測性的，但在一個有50%退出率的有限資料庫中，實際的減肥結果可能會被隱藏起來。

六、大數據展現與應用技術

大數據技術能夠將隱藏於海量數據中的信息和知識挖掘出來，為人類的社會經濟活動提供依據，從而提高各個領域的運行效率，大大提高整個社會經濟的集約化程度。

在我國，大數據將重點應用於以下三大領域：商業智能 、政府決策、公共服務。例如：商業智能技術，政府決策技術，電信數據信息處理與挖掘技術，電網數據信息處理與挖掘技術，氣象信息分析技術，環境監測技術，警務雲應用系統(道路監控、視頻監控、網路監控、智能交通、反電信詐騙、指揮調度等公安信息系統)，大規模基因序列分析比對技術，Web信息挖掘技術，多媒體數據並行化處理技術，影視製作渲染技術，其他各種行業的雲計算和海量數據處理應用技術等。

Ⅲ 如何利用Mahout和Hadoop處理大規模數據

利用Mahout和Hadoop處理大規模數據
規模問題在機器學習演算法中有什麼現實意義?讓我們考慮你可能需要部署Mahout來解決的幾個問題的大小。
據粗略估計，Picasa三年前就擁有了5億張照片。 這意味著每天有百萬級的新照片需要處理。一張照片的分析本身不是一個大問題，即使重復幾百萬次也不算什麼。但是在學習階段可能需要同時獲取數十億張照片中的信息，而這種規模的計算是無法用單機實現的。
據報道，Google News每天都會處理大約350萬篇新的新聞文章。雖然它的絕對詞項數量看似不大，但試想一下，為了及時提供這些文章，它們連同其他近期的文章必須在幾分鍾的時間內完成聚類。
Netflix為Netflix Prize公布的評分數據子集中包含了1億個評分。因為這僅僅是針對競賽而公布的數據，據推測Netflix為形成推薦結果所需處理的數據總量與之相比還要大出許多倍。
機器學習技術必須部署在諸如此類的應用場景中，通常輸入數據量都非常龐大，以至於無法在一台計算機上完全處理，即使這台計算機非常強大。如果沒有 Mahout這類的實現手段，這將是一項無法完成的任務。這就是Mahout將可擴展性視為重中之重的道理，以及本書將焦點放在有效處理大數據集上的原因，這一點與其他書有所不同。
將復雜的機器學習技術應用於解決大規模的問題，目前僅為大型的高新技術公司所考慮。但是，今天的計算能力與以往相比，已廉價許多，且可以藉助於 Apache Hadoop這種開源框架更輕松地獲取。Mahout通過提供構築在Hadoop平台上的、能夠解決大規模問題的高質量的開源實現以期完成這塊拼圖，並可為所有技術團體所用。
Mahout中的有些部分利用了Hadoop，其中包含一個流行的MapRece分布式計算框架。MapRece被谷歌在公司內部得到廣泛使用 ，而Hadoop是它的一個基於Java的開源實現。MapRece是一個編程範式，初看起來奇怪，或者說簡單得讓人很難相信其強大性。 MapRece範式適用於解決輸入為一組"鍵 值對"的問題，map函數將這些鍵值對轉換為另一組中間鍵值對，rece函數按某種方式將每個中間鍵所對應的全部值進行合並，以產生輸出。實際上，許多問題可以歸結為MapRece問題，或它們的級聯。這個範式還相當易於並行化：所有處理都是獨立的，因此可以分布到許多機器上。這里不再贅述 MapRece，建議讀者參考一些入門教程來了解它，如Hadoop所提供的
Hadoop實現了MapRece範式，即便MapRece聽上去如此簡單，這仍然稱得上是一大進步。它負責管理輸入數據、中間鍵值對以及輸出數據的存儲;這些數據可能會非常龐大，並且必須可被許多工作節點訪問，而不僅僅存放在某個節點上。Hadoop還負責工作節點之間的數據分區和傳輸，以及各個機器的故障監測與恢復。理解其背後的工作原理，可以幫你准備好應對使用Hadoop可能會面對的復雜情況。Hadoop不僅僅是一個可在工程中添加的庫。它有幾個組件，每個都帶有許多庫，還有(幾個)獨立的服務進程，可在多台機器上運行。基於Hadoop的操作過程並不簡單，但是投資一個可擴展、分布式的實現，可以在以後獲得回報：你的數據可能會很快增長到很大的規模，而這種可擴展的實現讓你的應用不會落伍。
鑒於這種需要大量計算能力的復雜框架正變得越來越普遍，雲計算提供商開始提供Hadoop相關的服務就不足為奇了。例如，亞馬遜提供了一種管理Hadoop集群的服務 Elastic MapRece，該服務提供了強大的計算能力，並使我們可通過一個友好的介面在Hadoop上操作和監控大規模作業，而這原本是一個非常復雜的任務。

Ⅳ 如何高效處理大量數據的統計問題

你這個問題太籠統了，大量數據，究竟有多大？數據是什麼類型的？要解決什麼樣的統計問題？針對每個具體問題都有不同的高效演算法可以選擇，不能一概而論的。當然這是你自己編程解決的情況，你也可以直接使用成熟的資料庫系統或SPSS來解決很多統計問題

Ⅳ 大數據存儲與應用特點及技術路線分析

大數據存儲與應用特點及技術路線分析

大數據時代，數據呈爆炸式增長。從存儲服務的發展趨勢來看，一方面，對數據的存儲量的需求越來越大；另一方面，對數據的有效管理提出了更高的要求。大數據對存儲設備的容量、讀寫性能、可靠性、擴展性等都提出了更高的要求，需要充分考慮功能集成度、數據安全性、數據穩定性，系統可擴展性、性能及成本各方面因素。

大數據存儲與應用的特點分析

「大數據」是由數量巨大、結構復雜、類型眾多數據構成的數據集合，是基於雲計算的數據處理與應用模式，通過數據的整合共享，交叉復用形成的智力資源和知識服務能力。其常見特點可以概括為3V:Volume、Velocity、Variety(規模大、速度快、多樣性)。

大數據具有數據規模大(Volume)且增長速度快的特性，其數據規模已經從PB級別增長到EB級別，並且仍在不斷地根據實際應用的需求和企業的再發展繼續擴容，飛速向著ZB(ZETA-BYTE)的規模進軍。以國內最大的電子商務企業淘寶為例，根據淘寶網的數據顯示，至2011年底，淘寶網最高單日獨立用戶訪問量超過1.2億人，比2010年同期增長120%,注冊用戶數量超過4億，在線商品數量達到8億，頁面瀏覽量達到20億規模，淘寶網每天產生4億條產品信息，每天活躍數據量已經超過50TB.所以大數據的存儲或者處理系統不僅能夠滿足當前數據規模需求，更需要有很強的可擴展性以滿足快速增長的需求。

(1)大數據的存儲及處理不僅在於規模之大，更加要求其傳輸及處理的響應速度快(Velocity)。

相對於以往較小規模的數據處理，在數據中心處理大規模數據時，需要服務集群有很高的吞吐量才能夠讓巨量的數據在應用開發人員「可接受」的時間內完成任務。這不僅是對於各種應用層面的計算性能要求，更加是對大數據存儲管理系統的讀寫吞吐量的要求。例如個人用戶在網站選購自己感興趣的貨物，網站則根據用戶的購買或者瀏覽網頁行為實時進行相關廣告的推薦，這需要應用的實時反饋;又例如電子商務網站的數據分析師根據購物者在當季搜索較為熱門的關鍵詞，為商家提供推薦的貨物關鍵字，面對每日上億的訪問記錄要求機器學習演算法在幾天內給出較為准確的推薦，否則就丟失了其失效性；更或者是計程車行駛在城市的道路上，通過GPS反饋的信息及監控設備實時路況信息，大數據處理系統需要不斷地給出較為便捷路徑的選擇。這些都要求大數據的應用層可以最快的速度，最高的帶寬從存儲介質中獲得相關海量的數據。另外一方面，海量數據存儲管理系統與傳統的資料庫管理系統，或者基於磁帶的備份系統之間也在發生數據交換，雖然這種交換實時性不高可以離線完成，但是由於數據規模的龐大，較低的數據傳輸帶寬也會降低數據傳輸的效率，而造成數據遷移瓶頸。因此大數據的存儲與處理的速度或是帶寬是其性能上的重要指標。

(2)大數據由於其來源的不同，具有數據多樣性的特點。

所謂多樣性，一是指數據結構化程度，二是指存儲格式，三是存儲介質多樣性。對於傳統的資料庫，其存儲的數據都是結構化數據，格式規整，相反大數據來源於日誌、歷史數據、用戶行為記錄等等，有的是結構化數據，而更多的是半結構化或者非結構化數據，這也正是傳統資料庫存儲技術無法適應大數據存儲的重要原因之一。所謂存儲格式，也正是由於其數據來源不同，應用演算法繁多，數據結構化程度不同，其格式也多種多樣。例如有的是以文本文件格式存儲，有的則是網頁文件，有的是一些被序列化後的比特流文件等等。所謂存儲介質多樣性是指硬體的兼容，大數據應用需要滿足不同的響應速度需求，因此其數據管理提倡分層管理機制，例如較為實時或者流數據的響應可以直接從內存或者Flash(SSD)中存取，而離線的批處理可以建立在帶有多塊磁碟的存儲伺服器上，有的可以存放在傳統的SAN或者NAS網路存儲設備上，而備份數據甚至可以存放在磁帶機上。因而大數據的存儲或者處理系統必須對多種數據及軟硬體平台有較好的兼容性來適應各種應用演算法或者數據提取轉換與載入(ETL)。

大數據存儲技術路線最典型的共有三種：

第一種是採用MPP架構的新型資料庫集群，重點面向行業大數據，採用Shared Nothing架構，通過列存儲、粗粒度索引等多項大數據處理技術，再結合MPP架構高效的分布式計算模式，完成對分析類應用的支撐，運行環境多為低成本 PC Server，具有高性能和高擴展性的特點，在企業分析類應用領域獲得極其廣泛的應用。

這類MPP產品可以有效支撐PB級別的結構化數據分析，這是傳統資料庫技術無法勝任的。對於企業新一代的數據倉庫和結構化數據分析，目前最佳選擇是MPP資料庫。

第二種是基於Hadoop的技術擴展和封裝，圍繞Hadoop衍生出相關的大數據技術，應對傳統關系型資料庫較難處理的數據和場景，例如針對非結構化數據的存儲和計算等，充分利用Hadoop開源的優勢，伴隨相關技術的不斷進步，其應用場景也將逐步擴大，目前最為典型的應用場景就是通過擴展和封裝 Hadoop來實現對互聯網大數據存儲、分析的支撐。這裡面有幾十種NoSQL技術，也在進一步的細分。對於非結構、半結構化數據處理、復雜的ETL流程、復雜的數據挖掘和計算模型，Hadoop平台更擅長。

第三種是大數據一體機，這是一種專為大數據的分析處理而設計的軟、硬體結合的產品，由一組集成的伺服器、存儲設備、操作系統、資料庫管理系統以及為數據查詢、處理、分析用途而特別預先安裝及優化的軟體組成，高性能大數據一體機具有良好的穩定性和縱向擴展性。

以上是小編為大家分享的關於大數據存儲與應用特點及技術路線分析的相關內容，更多信息可以關注環球青藤分享更多干貨

Ⅵ 大數據方面核心技術有哪些

大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、資料庫、數據倉庫、機器學習、並行計算、可視化等。

1、數據採集與預處理：

Flume NG實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據；

Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。

2、數據存儲：

Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。

HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。

3、數據清洗：MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算

4、數據查詢分析：

Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。

Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。

5、數據可視化：對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。

Ⅶ 大數據採集與存儲的基本步驟有哪些

數據抽取

針對大數據分析平台需要採集的各類數據，分別有針對性地研製適配介面。對於已有的信息系統，研發對應的介面模塊與各信息系統對接，不能實現數據共享介面的系統通過ETL工具進行數據採集，支持多種類型資料庫，按照相應規范對數據進行清洗轉換，從而實現數據的統一存儲管理。

數據預處理

為使大數據分析平台能更方便對數據進行處理，同時為了使得數據的存儲機制擴展性、容錯性更好，需要把數據按照相應關聯性進行組合，並將數據轉化為文本格式，作為文件存儲下來。

數據存儲

除了Hadoop中已廣泛應用於數據存儲的HDFS，常用的還有分布式、面向列的開源資料庫Hbase，HBase是一種key/value系統，部署在HDFS上，與Hadoop一樣，HBase的目標主要是依賴橫向擴展，通過不斷的增加廉價的商用伺服器，增加計算和存儲能力。

關於大數據採集與存儲的基本步驟有哪些，青藤小編就和您分享到這里了。如果您對大數據工程有濃厚的興趣，希望這篇文章可以為您提供幫助。如果您還想了解更多關於數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。

Ⅷ 五種大數據處理架構

五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
Apache Hadoop
· 僅流處理框架：
Apache Storm
Apache Samza
· 混合框架：
Apache Spark
Apache Flink
大數據處理框架是什麼？
處理框架和處理引擎負責對數據系統中的數據進行計算。雖然「引擎」和「框架」之間的區別沒有什麼權威的定義，但大部分時候可以將前者定義為實際負責處理數據操作的組件，後者則可定義為承擔類似作用的一系列組件。
例如Apache Hadoop可以看作一種以MapRece作為默認處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop並取代MapRece。組件之間的這種互操作性是大數據系統靈活性如此之高的原因之一。
雖然負責處理生命周期內這一階段數據的系統通常都很復雜，但從廣義層面來看它們的目標是非常一致的：通過對數據執行操作提高理解能力，揭示出數據蘊含的模式，並針對復雜互動獲得見解。
為了簡化這些組件的討論，我們會通過不同處理框架的設計意圖，按照所處理的數據狀態對其進行分類。一些系統可以用批處理方式處理數據，一些系統可以用流方式處理連續不斷流入系統的數據。此外還有一些系統可以同時處理這兩類數據。
在深入介紹不同實現的指標和結論之前，首先需要對不同處理類型的概念進行一個簡單的介紹。
批處理系統
批處理在大數據世界有著悠久的歷史。批處理主要操作大容量靜態數據集，並在計算過程完成後返回結果。
批處理模式中使用的數據集通常符合下列特徵…
· 有界：批處理數據集代表數據的有限集合
· 持久：數據通常始終存儲在某種類型的持久存儲位置中
· 大量：批處理操作通常是處理極為海量數據集的唯一方法
批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時，必須將數據集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中數據維持自己的狀態。
需要處理大量數據的任務通常最適合用批處理操作進行處理。無論直接從持久存儲設備處理數據集，或首先將數據集載入內存，批處理系統在設計過程中就充分考慮了數據的量，可提供充足的處理資源。由於批處理在應對大量持久數據方面的表現極為出色，因此經常被用於對歷史數據進行分析。
大量數據的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。
Apache Hadoop
Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社區獲得極大關注的大數據框架。基於谷歌有關海量數據處理所發表的多篇論文與經驗的Hadoop重新實現了相關演算法和組件堆棧，讓大規模批處理技術變得更易用。
新版Hadoop包含多個組件，即多個層，通過配合使用可處理批數據：
· HDFS：HDFS是一種分布式文件系統層，可對集群節點間的存儲和復制進行協調。HDFS確保了無法避免的節點故障發生後數據依然可用，可將其用作數據來源，可用於存儲中間態的處理結果，並可存儲計算的最終結果。
· YARN：YARN是Yet Another Resource Negotiator（另一個資源管理器）的縮寫，可充當Hadoop堆棧的集群協調組件。該組件負責協調並管理底層資源和調度作業的運行。通過充當集群資源的介面，YARN使得用戶能在Hadoop集群中使用比以往的迭代方式運行更多類型的工作負載。
· MapRece：MapRece是Hadoop的原生批處理引擎。
批處理模式
Hadoop的處理功能來自MapRece引擎。MapRece的處理技術符合使用鍵值對的map、shuffle、rece演算法要求。基本處理過程包括：
· 從HDFS文件系統讀取數據集
· 將數據集拆分成小塊並分配給所有可用節點
· 針對每個節點上的數據子集進行計算（計算的中間態結果會重新寫入HDFS）
· 重新分配中間態結果並按照鍵進行分組
· 通過對每個節點計算的結果進行匯總和組合對每個鍵的值進行「Recing」
· 將計算而來的最終結果重新寫入 HDFS
優勢和局限
由於這種方法嚴重依賴持久存儲，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁碟空間通常是伺服器上最豐富的資源，這意味著MapRece可以處理非常海量的數據集。同時也意味著相比其他類似技術，Hadoop的MapRece通常可以在廉價硬體上運行，因為該技術並不需要將一切都存儲在內存中。MapRece具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。
MapRece的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop集群快速實現某些應用時依然需要注意這個問題。
圍繞Hadoop已經形成了遼闊的生態系統，Hadoop集群本身也經常被用作其他軟體的組成部件。很多其他處理框架和引擎通過與Hadoop集成也可以使用HDFS和YARN資源管理器。
總結
Apache Hadoop及其MapRece處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的非常大規模數據集。通過非常低成本的組件即可搭建完整功能的Hadoop集群，使得這一廉價且高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的兼容與集成能力使得Hadoop可以成為使用不同技術的多種工作負載處理平台的底層基礎。
流處理系統
流處理系統會對隨時進入系統的數據進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。
· 流處理中的數據集是「無邊界」的，這就產生了幾個重要的影響：
· 完整數據集只能代表截至目前已經進入到系統中的數據總量。
· 工作數據集也許更相關，在特定時間只能代表某個單一數據項。
處理工作是基於事件的，除非明確停止否則沒有「盡頭」。處理結果立刻可用，並會隨著新數據的抵達繼續更新。
流處理系統可以處理幾乎無限量的數據，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）數據，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優化。
功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個數據執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些類型的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。
此類處理非常適合某些類型的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程序錯誤日誌，以及其他基於時間的衡量指標是最適合的類型，因為對這些領域的數據變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的數據。
Apache Storm
Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據，通過比其他解決方案更低的延遲提供結果。
流處理模式
Storm的流處理可對框架中名為Topology（拓撲）的DAG（Directed Acyclic Graph，有向無環圖）進行編排。這些拓撲描述了當數據片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。
拓撲包含：
· Stream：普通的數據流，這是一種會持續抵達系統的無邊界數據。
· Spout：位於拓撲邊緣的數據流來源，例如可以是API或查詢等，從這里可以產生待處理的數據。
· Bolt：Bolt代表需要消耗流數據，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨後相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。
Storm背後的想法是使用上述組件定義大量小型的離散操作，隨後將多個組件組成所需拓撲。默認情況下Storm提供了「至少一次」的處理保證，這意味著可以確保每條消息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理消息。
為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。
為避免這些問題，通常建議Storm用戶盡可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智能地處理重復消息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個鏈接，此時Trident將是你唯一的選擇。盡管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。
Trident拓撲包含：
· 流批（Stream batch）：這是指流數據的微批，可通過分塊提供批處理語義。
· 操作（Operation）：是指可以對數據執行的批處理過程。
優勢和局限
目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。
Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。
Core Storm無法保證消息的處理順序。Core Storm為消息提供了「至少一次」的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重復。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。
在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。
總結
對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟體。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。
Apache Samza
Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用於很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩沖，以及狀態存儲。
Samza可使用YARN作為資源管理器。這意味著默認情況下需要具備Hadoop集群（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。
流處理模式
Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：
· Topic（話題）：進入Kafka系統的每個數據流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。
· Partition（分區）：為了將一個話題分散至多個節點，Kafka會將傳入的消息劃分為多個分區。分區的劃分將基於鍵（Key）進行，這樣可以保證包含同一個鍵的每條消息可以劃分至同一個分區。分區的順序可獲得保證。
· Broker（代理）：組成Kafka集群的每個節點也叫做代理。
· Procer（生成方）：任何向Kafka話題寫入數據的組件可以叫做生成方。生成方可提供將話題劃分為分區所需的鍵。
· Consumer（消耗方）：任何從Kafka讀取話題的組件可叫做消耗方。消耗方需要負責維持有關自己分支的信息，這樣即可在失敗後知道哪些記錄已經被處理過了。
由於Kafka相當於永恆不變的日誌，Samza也需要處理永恆不變的數據流。這意味著任何轉換創建的新數據流都可被其他組件所使用，而不會對最初的數據流產生影響。
優勢和局限
乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。
例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。
這種對Kafka的緊密依賴在很多方面類似於MapRece引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。
Samza與Kafka之間緊密的關系使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理後創建的話題。這一切並不會對資料庫等負載密集型基礎架構造成額外的壓力。
直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。
Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得「至少一次」的交付保障，但面對由於數據可能多次交付造成的失敗，該技術無法對匯總後狀態（例如計數）提供精確恢復。
Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易於配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。
總結
對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間並不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。
混合處理系統：批處理和流處理
一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，藉此讓不同的處理需求得以簡化。
如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不同處理模式如何進行統一，以及要對固定和不固定數據集之間的關系進行何種假設。
雖然側重於某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不僅可以提供處理數據所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、互動式查詢等多種任務。
Apache Spark
Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapRece引擎基於各種相同原則開發而來的Spark主要側重於通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。
Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成並取代MapRece引擎。
批處理模式
與MapRece不同，Spark的數據處理工作全部在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態的處理結果均存儲在內存中。
雖然內存中處理方式可大幅改善性能，Spark在處理與磁碟有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可創建代表所需執行的全部操作，需要操作的數據，以及操作和數據之間關系的Directed Acyclic Graph（有向無環圖），即DAG，藉此處理器可以對任務進行更智能的協調。
為了實現內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數據集），即RDD的模型來處理數據。這是一種代表數據集，只位於內存中，永恆不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，並最終回溯至磁碟上的數據。Spark可通過RDD在無需將每個操作的結果寫回磁碟的前提下實現容錯。
流處理模式
流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特徵方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數據流視作一系列非常小的「批」，藉此即可通過批處理引擎的原生語義進行處理。
Spark Streaming會以亞秒級增量對流進行緩沖，隨後這些緩沖會作為小規模的固定數據集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。
優勢和局限
使用Spark而非Hadoop MapRece的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數據集。
Spark的另一個重要優勢在於多樣性。該產品可作為獨立集群部署，或與現有Hadoop集群集成。該產品可運行批處理和流處理，運行一個集群即可處理不同類型的任務。
除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、互動式查詢等任務提供更好的支持。相比MapRece，Spark任務更是「眾所周知」地易於編寫，因此可大幅提高生產力。
為流處理系統採用批處理的方法，需要對進入系統的數據進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數據，提高整體吞吐率，但等待緩沖區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。
由於內存通常比磁碟空間更貴，因此相比基於磁碟的系統，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數為資源付費的環境中，這一特性通常可以抵消增加的成本。
Spark內存計算這一設計的另一個後果是，如果部署在共享的集群中可能會遇到資源不足的問題。相比HadoopMapRece，Spark的資源消耗更大，可能會對需要在同一時間使用集群的其他任務產生影響。從本質來看，Spark更不適合與Hadoop堆棧的其他組件共存一處。
總結
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高內存佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。
Apache Flink
Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理數據視作具備有限邊界的數據流，藉此將批處理任務作為流處理的子集加以處理。為所有處理任務採取流處理為先的方法會產生一系列有趣的副作用。
這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構（該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果）。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後才可行的。
流處理模型
Flink的流處理模型在處理傳入數據時會將每一項視作真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：
· Stream（流）是指在系統中流轉的，永恆不變的無邊界數據集
· Operator（操作方）是指針對數據流執行操作以產生其他數據流的功能
· Source（源）是指數據流進入系統的入口點
· Sink（槽）是指數據流離開Flink系統後進入到的位置，槽可以是資料庫或到其他系統的連接器
為了在計算過程中遇到問題後能夠恢復，流處理任務會在預定時間點創建快照。為了實現狀態存儲，Flink可配合多種狀態後端系統使用，具體取決於所需實現的復雜度和持久性級別。
此外Flink的流處理能力還可以理解「事件時間」這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味著可以通過某種有趣的方式確保執行順序和分組。
批處理模型
Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。
Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。
另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。藉此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。
優勢和局限
Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。
Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。
Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關系型資料庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行「增量迭代」，或僅對數據中有改動的部分進行迭代。
在用戶工具方面，Flink提供了基於Web的調度視圖，藉此可輕松管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，藉此了解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。
Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。
目前Flink最大的局限之一在於這依然是一個非常「年幼」的項目。現實環境中該項目的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨著快速開發周期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署
總結
Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。
結論
大數據系統可使用多種處理技術。
對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的Hadoop將會是一個好選擇。
對於僅需要流處理的工作負載，Storm可支持更廣泛的語言並實現極低延遲的處理，但默認配置可能產生重復結果並且無法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團隊使用，以及更簡單的復制和狀態管理。
對於混合型工作負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支持更完善，具備各種集成庫和工具，可實現靈活的集成。Flink提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。