物聯網大數據處理技術與實踐InternetofThings

BigDataprocessingTechnologyandPractice大數據處理技術的發展大數據存儲和管理技術1大數據計算技術2大數據分析技術3人工智能研究的基本內容4人工智能的主要應用和研究領域5PARTONE1大數據存儲和管理技術師傅領進門，學藝在自身。------中國諺語大數據存儲和管理技術大數據每年都在激增龐大的信息量，加上已有的歷史數據信息，對整個業界的數據存儲、處理帶來了很大的機遇與挑戰。對于大數據的存儲，存在以下問題和挑戰：容量問題延遲問題安全問題靈活性...大數據存儲和管理技術數據在存儲設備上以數據塊的形式存儲，人們對物理數據進行直接訪問和查詢文件系統以文件為單位對數據進行訪問和管理數據庫在文件系統上增加了一個抽象層，用戶可以根據數據模型對文件中的數據進行記錄級新增、截取、更新、刪除等操作傳統的數據存儲和管理技術：與傳統的單機版文件系統及數據庫不同，對于大數據的存儲和管理，由于數據規模巨大，必須將數據存儲在多個機器中，并且在多臺機器中共享這些數據。這時，就需要采用新的文件系統技術。面向大數據的文件系統在多臺機器中存儲與共享數據：以手工的方式共享文件FTP技術被用來共享文件網絡文件系統（NetworkFileSystem,NFS），最初的分布式文件系統分布式文件系統搭建在傳統文件系統之上，它必須允許用戶在企業內部網上的任一計算機上訪問自己的文件，程序可以像對待本地文件一樣存儲和訪問遠程文件。為了達到此效果，分布式文件系統必須解決一些基本問題。這些問題包括：1).程序如何尋址遠程文件，像對待本地文件一樣訪問遠程文件？2).元數據管理問題3).一致性問題4).并發文件更新問題上世紀八十年代出現的網絡文件系統主要解決思路是實現客戶端和文件（存儲）服務器的交互問題。在緩存和一致性管理方面，Sun公司的網絡文件系統NFS采用了簡單的弱一致性方式：對于緩存的數據，客戶端周期性（30秒）去詢問服務器，查詢文件被最后修改的時間，如果本地緩存數據的時間早于該時間，則讓本地緩存數據無效，下次讀取數據時就去服務器獲取最新的數據。服務器對外提供統一的命名空間（目錄樹），存儲服務器節點之間不共享存儲空間，每個服務器存儲不同目錄子樹的方式實現擴展。網絡文件系統的服務器之間缺乏負載均衡和容錯機制，不同服務器之間的存儲空間也不能得以均衡利用，可靠性差，文件（存儲）服務器的可擴展性問題十分突出：每個存儲服務器所支持的存儲容量局限于SCSI總線的限制而難以擴展。網絡文件系統90年代，存儲區域網（StorageAreaNetwork，SAN）成為解決存儲系統可擴展性的最有效的途徑。SAN是用網絡取代SCSI總線，從而使存儲系統的容量與性能的可擴展性都得以極大提高。在SAN網絡中，可以接入多個存儲節點，每個節點都對外提供I/O通道，在寫入數據時，服務器端可以并行寫入到多個存儲節點中，從而顯著提高I/O吞吐量。早期的SAN主要用于集群計算系統中。存儲區域網分布式集群文件系統分布式集群文件系統：在傳統文件系統基礎上，每臺計算機各自提供自己的存儲空間，并各自協調管理所有計算機節點中的文件，節點通過前端網絡發送請求讀寫數據。典型代表Google文件系統GFS雅虎工程師開發了HDFSGlusterFS、Ceph、Lustre、MooseFS等分布式集群文件系統HDFS對大文件采用分塊存儲，非常適合在以計算為主和超大文件存儲的應用環境下，支持對大文件的每一塊進行獨立地計算處理。HDFS可以在集群內進行文件塊的移動遷移，將文件塊遷移到計算空閑的機器上，以充分利用CPU計算資源，加快數據處理速度。同時，分塊導致了文件難以修改數據。Ceph的主要目標是設計成可輕松擴展到數PB容量、基于POSIX、沒有單點故障、對多種工作負載提供高性能的訪問。目前Ceph支持OpenStack、CloudStack、OpenNebula、Hadoop等。GlusterFS是完全與POSIX標準兼容的分布式集群文件系統。分布式內存文件系統Tachyon可以在集群里以訪問內存的速度來訪問存在tachyon里的文件Tachyon是框架在分布式文件存儲和各種計算框架之間的一種中間件主要職責是將那些不需要落地到普通文件系統里的文件，落地到分布式內存文件系統中，來達到共享內存、提高效率，同時可以達到減少內存冗余、GC時間等的目的面向大數據的數據庫系統：并行數據庫是指那些在無共享的體系結構中進行數據庫操作的數據庫系統。這些系統大部分采用了關系數據模型并且支持SQL語句查詢，但為了能夠并行執行SQL的查詢操作，系統中采用了兩個關鍵技術：關系表的水平劃分：根據某種策略將關系表中的元組分布到集群中的不同節點上，這些節點上的表結構是一樣的，這樣就可以對元組并行處理SQL查詢的分區執行：首先為SQL查詢生成總的執行計劃，再拆分成能夠在各個節點上獨立執行的子計劃。在執行時，每個節點將中間結果發送到某一特定節點進行聚集產生最終結果。并行數據庫優點：擁有較高的性能和可用性缺點：沒有較好的可伸縮性；系統的容錯性較差只適合小規模集群，以及資源需求相對固定的應用程序NoSQL數據管理系統由于傳統關系數據庫（Oracle、MSSQLServer和MySQL等）不擅長處理模式不確定性的數據、使傳統關系數據庫表結構變得復雜和對事務管理的嚴格要求嚴重影響了系統在分布式環境下的可用性和可伸縮性等原因，出現了NoSQL數據管理系統。NoSQL（NotOnlySQL）數據存儲和管理系統是指那些非關系型的、分布式的、不保證遵循ACID原則的數據存儲系統,并分為key-value存儲、文檔數據庫和圖數據庫這3類。根據CAP定理，對于分布式系統來說，系統的一致性(consistency，C)、可用性(availability，A)和分區容錯性(partitiontolerance，P)三者是不可能同時實現的，任何設計高明的分布式系統只能同時保障其中的兩個性質。如以上的NoSQL數據庫中，Cassandra,Dynamo滿足CAP定理中的AP；BigTable,MongoDB滿足CP；而關系數據庫,如MySQL和Postgres滿足AC。NoSQL數據管理系統NoSQL典型地遵循BASE原則，更加強調讀寫效率、數據容量以及系統可擴展性.NoSQL數據庫一般只支持簡單的key/value接口，只支持根據惟一的鍵值(key)定義在一個數據項上的讀寫操作。支持事務的分布式NoSQL--FoundationDB優點：相對于復雜的關系數據庫系統，其主要優點在于其查詢速度快、支持大規模數據存儲且支持高并發，非常適合只需要通過主鍵進行簡單查詢的應用場景。缺點：它本身沒有任何表示約束和關系的機制，因此數據完整性的保障完全依賴客戶程序本身；由于目前出現了很多NoSQL數據存儲系統的產品或工具，但由于缺乏統一標準，彼此之間兼容性差等。NewSQL數據管理系統NewSQL能夠提供SQL數據庫的質量保證，也能提供NoSQL數據庫的可擴展性。VoltDB是NewSQL的實現之一，其開發公司的CTO宣稱，它們的系統使用NewSQL的方法處理事務的速度比傳統數據庫系統快45倍。VoltDB可以擴展到39個機器上，在300個CPU內核中每分鐘處理1600萬事務，其所需的機器數比Hadoop集群要少很多。NewSQL的出現：2012年Google在OSDI上發表了Spanner的論文，2013年在SIGMOD發表了F1的論文。這兩篇論文讓業界第一次看到了關系模型和NoSQL的擴展性在超龐大集群規模上融合的可能性。這種可擴展、高性能的SQL數據庫被稱為NewSQL，其中“New”用來表明與傳統關系型數據庫系統的區別。PARTTWO2大數據計算技術批處理計算模式

批量數據三大特征數據體量巨大數據精確度高數據價值密度低大數據的批處理系統適用于先存儲后計算，實時性要求不高，同時數據的準確性和全面性更為重要的場景。批處理計算模式批量數據處理適合大型、相對成熟的作業，但可能浪費時間，因為處理結果與預期差異大。MapReduce編程模型在批處理計算中廣泛應用，因為它具有良好的性價比、易于使用和可伸縮性。離線批處理計算模式適用于靜態數據，但對于實時性要求高的應用不夠強大，因為它有一些局限性，如中間數據傳輸難以優化、任務重啟開銷大等。交互式查詢計算模式數據查詢和分析是迭代的交互過程，對實時性要求高，大數據環境下需要改進響應時間，引入索引和內存計算等手段，如Spark和Dremel系統。Spark系統：是高效的開源集群計算系統，利用內存快速處理數據，比Hadoop快10倍~100倍，兼容Hadoop存儲API，支持交互式查詢。Dremel系統：交互式數據分析系統，處理PB級數據，秒級響應，嵌套數據模型適合大規模數據和相關查詢，結合Web搜索技術，能夠實現并發執行查詢。流處理計算模式流處理計算的現狀流處理計算的方式流處理的應用流處理計算的現狀流數據具有持續到達、規模大且速度快等特點，通常不會對所有數據進行永久化存儲，而基本在內存中完成。流數據處理方式更多地依賴于內存中設計巧妙的概要數據結構。在云計算和大數據環境下面臨新的挑戰，流處理仍舊是研究熱點。物聯網領域由于大量實時產生的感知數據，也對流處理計算模式有廣泛的需求。流處理計算的方式流處理兩種典型的處理方式：真正的流處理方式：計算是針對一條新的記錄進行一次。

（例如Storm，其響應時間可以達毫秒級。）微批處理方式：將流數據分為很多小的片段，針對每個片段進行一次處理。（例如SparkStreaming，響應時間難以達到毫秒級。）流處理的應用Twitter的Storm系統

Storm是一套分布式、可靠、可容錯的用于處理流數據的系統。其流式處理作業被分發至不

同類型的組件,每個組件負責一項簡單的、特定的處理任務。Storm提供了簡單的類似于MapReduce的編程模型，降低了實時處理的復雜性。它也具有擁有良好的水平擴展能力,其流式計算過程是在多個線程、進程和服務器之間并行進行的。Linkedin的Samza系統

Samza與Kafka的關系可以類比MapReduce與HDFS的關系。Samza系統由3個層次組成,包括流式數據層(Kafka)、執行層(YARN)、處理層(SamzaAPI).一個Samza任務的輸入與輸出均是流。

Samza使用Kafka來保證所有消息都會按照寫入分區的順序進行處理,絕對不會丟失任何消息。SparkStreaming系統

SparkStreaming是SparkAPI的一個擴展，它并不會像Storm那樣一次一個地處理數據流，而是在處理前按時間間隔預先將其切分為一段一段的微批處理作業。大數據實時處理的架構：Lambda及KappaLambda架構是由Storm的作者NathanMarz提出的一個實時大數據處理框架。Lambda架構將大數據系統構建為多個層次。

理想狀態下，任何數據訪問都可以通過對數據的直接查詢獲取，但是，若數據達到相當大的一個級別（例如PB），且還需要支持實時查詢時，就需要耗費非常龐大的資源。大數據實時處理的架構：Lambda及Kappa

在Lambda架構中，實現batchview的部分被稱之為批處理層（Batchlayer）。主要包含兩個職責：

存儲主數據集（不變的持續增長的數據集）

針對這個主數據集進行預運算

大數據實時處理的架構：Lambda及Kappa加速層只處理最近的數據，它會在接收到新數據時，進行一種增量的計算。

大數據實時處理的架構：Lambda及Kappa

針對Lambda架構的缺點，LinkedIn的工程師JayKreps提出了應對大數據實時處理的另外一種方式，即Kappa架構。

在Kappa架構中，流處理系統來處理輸入的數據，流處理系統的輸出直接進入數服務層，而應用直接從服務層獲取查詢結果。也就是說Kappa只有兩層：實時處理層和服務層。大數據實時處理的架構：Lambda及Kappa

在Kappa架構中，不需要對數據的處理開發和維護兩套不同的系統，因此系統復雜度減少了。

但是，由于Kappa架構去掉了批處理層，因此其不適合用來管理一些需要利用大量歷史數據進行批處理的應用。例如在某些大規模機器學習應用場景需要海量的歷史數據進行模型訓練時，Kappa架構可能會無法勝任。Kappa架構層次圖PARTTHREE3大數據分析技術大數據分析技術傳統數據分析主要針對結構化數據展開，且形成了成熟的技術體系，但大數據數據的規模效應給很多傳統單機版的機器學習和數據挖掘算法帶來了很多的挑戰。主要體現在：數據量的膨脹數據深度分析需求的增長傳統結構化數據分析在傳統工業、電子商務、政務以及科學研究等應用領域產生了大量的結構化數據，許多數據挖掘的技術已成功用于一些結構化數據分析的應用。例如：統計機器學習、時空挖掘技術、高速數據流與傳感器數據中的模式。文本數據分析文本數據分析是指從無結構的文本中提取有用信息或知識的過程。文本分析技術包括信息提取、主題建模、摘要(summarization)、分類、聚類、問答系統和觀點挖掘等技術。多媒體數據分析多媒體數據分析是指從圖像、語音等多媒體數據中提取知識。多媒體分析研究覆蓋范圍較廣,包括多媒體識別、多媒體摘要、多媒體標注、多媒體索引和檢索、多媒體