1.3.3　大數據技術

1.大數據處理

文獻[81]指出，數據科學（data science）涉及通過原理、過程和技術來理解特定現象的數據（自動化）分析。從某種程度上說，數據科學的終極目標是改進決策支持，這在商界通常是最重要的。隨著信息通信技術的發展，普通民眾從各類媒體上獲得的印象不同，人們通常認為的大多數數據處理實際上并不屬于數據科學的范疇。數據領域的工程（engineering）和處理（processing）是數據科學得以開展的前提。具體來說，數據領域的工程和處理包含了大量的大數據技術，這些技術的進化和相互作用充實了數據科學的內涵和外延，造就了自動化的、由數據驅動的決策。

文獻[82]首先給出大數據的概念，其次闡述大數據分析及其有益之處，然后給出了進行成功的大數據分析的必備條件，最后討論了大數據領域的隱私保護。要實現成功的大數據分析，首先需要具備執行支持和贊助，這與大多數常規的分析類項目相同，例如商業智能（business intelligence）^[83][84]。大數據分析的前提條件與常規的分析類項目的主要區別如下：

（1）清晰的商業需求

眾所周知，潛在的項目應當是商業性質的，而并非由技術驅動。項目應當是為了滿足具體的商業需求，例如解決一個具體的問題或者嘗試抓住一個機會。文獻[85]指出，在大多數商業機構和組織中，最初的大數據分析需求都關注于以消費者為導向的目標，使用已有的和新近獲得的內部數據來構建與消費者的良好關系，進而改進商業運行模式并改善消費者的體驗。針對上述觀點，文獻[86]指出成功的大數據分析倡議應當始于具體的或是嚴密定義的目標的集合，而不應當采用邊走邊看的方法，在構建模型的過程中逐步探索可能出現的結果。文獻[87]對大數據分析在不同產業領域的應用案例進行了羅列：

·汽車保險（automobile insurance）^[88]：價格調整、客戶風險分析和欺詐檢測等。

·電信技術（telecommunication）^[89]：跨社交網絡的服務模式分析、消費者社交網絡的盈利狀況和客戶流失最小化（churn minimization）。

·制造、分發和零售（manufacturing，distribution and retail）^[90]：跟蹤貨架可用性、評估促銷展示的影響、評估促銷活動的有效性，以及庫存管理、價格調整和點擊量分析。

·交通和物流（transportation and logistics）^[91]：實時的車隊管理和RFID資產跟蹤。

·公共事業（utility）^[92]：分析智能電網數據來確定可變的價格模型，分析海量智能儀表的數據來預測能源需求、設計定制化的資費方案。

·游戲行業（gaming）^[93]：分析游戲體驗來給游戲研發者提供反饋，找尋游戲中的增值服務推銷機遇。

·執法機關（law enforcement）^[94]：分析人與人之間的關聯來識別出潛在且容易制造麻煩的群體，確定個體或組織的位置。

（2）強大且堅定的資助

沒有強大的資助，任何IT項目都難以獲得成功，大數據分析項目也不例外。如果項目在企業中是部門級別的，那么通常由獨立的部門進行資助。如果項目的戰略意義重大，涉及整個企業，那么應當得到高級管理者的支持。文獻[85]指出，在企業接納大數據的初期，首席信息官（Chief Information Officer，CIO）通常主導了所需的經費，而隨著相關的技術基礎設施逐步完善，企業從上到下均認識到大數據帶來的商業價值之后，資助轉變為由涉及特定功能需求的主管來決定，例如首席營銷官（Chief Marketing Officer，CMO）、首席財務官（Chief Finance Officer，CFO）和首席執行官（Chief Executive Officer，CEO）。

（3）商業活動與分析策略的匹配

在實施大數據分析項目前，務必要確定其所支持的商業戰略。這也是絕大多數大數據分析項目是由商業決策而非IT部門決定的原因。對于基于分析的商業組織來說，實際上商業活動和分析策略是相輔相成、缺一不可的。如果沒有分析與相應的決策，商業戰略是不可能獲得成功的。在這方面，在線零售商巨頭是最佳的典范，例如淘寶、京東、當當網和亞馬遜。為眾人所熟知的分析案例是產品推薦，當消費者瀏覽零售商的網站時，推薦引擎將消費者的查找關鍵字、歷史點擊情況、購物車內容分析、在其他店鋪的歷史消費情況和當前產品性價比等進行綜合考量，然后給用戶推送最容易達成交易的產品名目。不為公眾所熟知的商業智能應用包括報表（reporting）、數據實時監測（dashboard）、計分卡（scorecard）、需求預測（demand forecasting）、價格調整（pricing）、產品返修分析（produce return analysis）、細分市場分析（market segmentation analysis）、營銷活動管理（campaign management）和搜索引擎優化（search engine optimization）。

（4）基于事實的決策文化

機構或者組織要從大數據分析中獲益，那么其所做的決定必須基于“事實”（即由分析產生的結果）。此外，必須持續進行驗證以確定怎樣做才是最好的。一般來說，改變如何進行決策的文化要比解決技術問題更具有挑戰性。例如“奧克蘭運動家隊”（Oakland Athletics）和比利·比恩（Billy Beane）經理的故事^[95]，為了推行新的分析方法，比恩不得不挑戰擁有多年棒球經驗的反對者的權威和影響力。現在，每個競技體育團隊都依賴大數據分析來做各類決定，例如在美式足球中什么時候做出兩分轉換（two-point conversion）。

（5）優秀且強大的數據基礎設施

數據對商業智能和分析來說是至關重要的。當擁有優秀且強大的數據基礎設施時，各類應用程序通常可以在數天內研發完成。相反，缺乏良好的數據基礎設施會導致應用程序的研發無法進行。一般來說，IT部門十分清楚數據基礎設施的重要性，但其他部門通常默認數據基礎設施是已有的，并且不樂于協助提供需要創建和維護數據基礎設施所需的各類資料。優秀且強大的數據基礎設施涵蓋了如下要點：技術革新（technology advance）、數據倉庫（data warehouse）、數據集市應用程序（data mart application）、分析沙盒（analytical sandbox）、內存中的分析（in-memory analytics）、數據庫中的分析（in-database analytics）、列式數據庫（columnar database）、流式處理引擎和復雜事件處理引擎（streaming and complex event processing engine）、基于云的服務（cloud-based service）、Hadoop和MapReduce、非關系數據庫（non-relational database）以及平臺的選擇和集成（platform selection and integration）。

（6）正確的分析工具

盡管傳統的商業智能供應商宣稱他們的產品支持數據挖掘和數據預測兩個方面的分析，但實際使用過程中的情況通常不能令人滿意，例如將數據進行簡單的分割、轉化和可視化并不是數據挖掘。數據挖掘需要使用包含復雜算法和過程的軟件工具，這些復雜算法和過程的設計初衷就是為了尋找數據中隱藏的關系。在分析軟件領域，統計分析系統（Statistical Analysis System，SAS）^[1]以及統計產品與服務解決方案（Statistical Product and Service Solution，SPSS）^[2]是這方面的先驅。統計分析系統是由多個專業模塊構成的，例如數據的訪問、存儲、分析、報表、圖形、預測等。這些模塊共同支持以數據為中心的四大任務：數據訪問、數據管理、數據呈現和數據分析。統計產品與服務解決方案在2000年之前的名稱為社會科學統計軟件包（Statistical Package for the Social Sciences，SPSS）。目前，統計產品與服務解決方案的研發由IBM公司主導，其具有完善的數據輸入、分析、報表等功能，具有完善的數據接口以及功能模塊。同類的統計分析產品還有RapidMiner^[3]、Minitab^[4]、R^[5]和GNU PSPP^[6]等。

（7）優秀的分析人員

盡管大數據分析的主要環節和操作目前都實現了自動化，但具有扎實專業基礎知識以及從業經驗的分析師仍然必不可少。文獻[96]指出，在大數據分析與應用的領域，數據科學家和終端用戶之間必不可少的連接紐帶就是數據分析師。一般來說，數據分析師分為兩類：商業智能分析師（business intelligence analyst）和企業分析師（enterprise analyst）。商業智能分析師隸屬于商業智能分析部門，其面向整個組織架構開展工作。企業分析師在各個部門從事數據分析工作，例如策劃與運營部、市場部以及后勤部等。商業智能分析師對整個組織架構的數據以及相關數據分析工具的認知通常要優于企業分析師。例如，商業智能分析師可以設計和實現企業范疇的計分表系統，管理信息系統（Management Information System，MIS）專業的畢業生比較適合商業智能分析師這個職位。企業分析師對自身所在部門的數據和相關數據分析工具更加熟悉一些。例如，供應鏈分析師能夠通過分析對供應鏈進行過程優化，其中包含了原材料選購、物流運輸、倉儲管理和產品分發等環節。絕大多數組織都同時擁有這兩類分析師，他們在日常工作中各司其職并互相合作。

2.三代大數據處理技術

文獻[97]給出了大數據處理技術發展的時間線，并將大數據處理技術的發展劃分為三代：批處理（batch processing）、實時處理（real-time processing）和混合計算（hybrid computation）。

（1）批處理

第一代大數據處理技術批處理始于2003年，彼時谷歌（Google）發表了關于谷歌文件系統（Google File System，GFS）^[98]和分布式計算框架（MapReduce framework）^[99]的論文。2005年，Doug Cutting基于谷歌文件系統GFS和分布式計算框架MapReduce的論文研發了Hadoop^[100]。在此后的一段時間內，業界的商業巨頭和各類組織均未遇到切實的大數據問題，因此可以認為第一代大數據處理實際上始于2006年，彼時Hadoop剛剛誕生不久^[101]。2008年，雅虎（Yahoo）發布了Hadoop的一個穩定版本，并開始著手在MapReduce之上的抽象層進行工作。同樣是在2008年，雅虎發布了Hadoop體系結構中的一個重要組件Pig^[102]。此外，Facebook在2009年發布了Hadoop體系結構中的另一個重要組件Hive^[103]。此后，Hadoop以其可靠性和穩定性在批處理領域贏得了廣泛的應用。目前，Hadoop是批處理技術領域中的事實標準（de facto），且批處理領域未見更新的研究進展。

批處理技術是用來處理海量靜態（static）數據的。換言之，批處理所處理的數據是系統中已經存儲過的數據。對于已經啟動的批處理任務，新產生的數據不再參與處理過程。批處理技術所對應的系統的主要特點是可擴展性。為了更好地應對大數據的海量規模，進而獲得高可擴展性，批處理技術大多采用并行的分布式處理架構，例如著名的MapReduce。MapReduce技術具有如下優點：1）給出了簡單且統一的數據視圖；2）與生俱來的可擴展性；3）針對影響分布式軟件編寫的諸多挑戰因素（例如潛在的硬件失效、網絡狀態的波動和設備的異質性），MapReduce極大程度地屏蔽了編程的復雜性。除了上述優點，MapReduce在特定的應用環境下還具有一些不足^[104]，例如，針對大多數實時性系統和應用的數據分析事務通常都需要迭代運行若干次。這對原始的MapReduce來說是無法實現的。對于該問題，學界和業界已有一些相關的改進方案^{[105][106][107][108]}。此外，對于用戶日益增長的數據分析需求，如何更好地實現高效的數據處理，需要針對實時性、流計算、數據的訪問與索引化等進行改進。總體來說，批處理技術具有良好的可靠性，但批處理的過程通常需要較長的時間來完成。因此，批處理技術無法適用于時延要求低的應用。如前所述，批處理在啟動之后無法對新的數據進行處理，其不能在執行過程中被中斷或者重配置。

（2）實時處理

第二代大數據處理技術實時處理始于2010年，彼時以雅虎和推特（Twitter）為代表的全球性公司面臨不僅要處理海量靜態數據，還要處理海量的實時數據或流數據的難題。于是，雅虎在2010年研發了名為分布式流計算平臺（distributed stream computing platform）的框架^[109]，簡稱S4。該框架是第一個面向實時處理的解決方案。第二代大數據處理技術的另一個里程碑是面向分布式容錯實時計算（distributed and fault-tolerant real-time computation）的Storm^[110]。2011年，Nathan Marz開發了Storm框架，并由推特以開源的形式發布。類似地，作為一個創始于2008年的Hadoop數據管理軟件與服務提供商，Cloudera在2011年發布了日志收集系統Flume^[111]，該系統是一個面向海量數據的、具備高可用性和高可靠性的分布式日志采集和聚合系統。領英（Linkedin）在2011年發布了一個分布式流處理平臺Kafka^[112]，該平臺是一種高吞吐量的分布式發布/訂閱消息系統。此外，領英還在2013年研發了針對狀態可擴展的流處理（stateful scalable stream processing）的Samza^[113]技術。谷歌在2013年針對因特網規模的容錯流處理研發了Millwheel^[114]技術。目前，實時處理技術正在持續發展中，新型的技術也在不斷地涌現出來，但是還沒有類似批處理領域中的Hadoop的事實標準。

實時處理技術主要針對的是大數據的速度（Velocity）特性。換言之，實時處理能夠以較低的時延來處理流數據。這類處理技術在分布式和并行化方面或多或少借鑒了與批處理技術相同的設計理念，而為了獲得較低的時延，實時處理技術還對存儲在內存（memory）中的小規模數據集進行分析。因此，實時處理技術類似于小型化批處理的無限序列，其中需要處理的數據來源于內存/主存（primary storage），而不是輔存（secondary storage）。在具體實現中，實時處理技術采用的是無盤化（diskless）技術。目前，面向異質數據源的流數據處理得到了廣泛的應用，常見的案例如下：1）智慧城市（Smart City）中的交通指揮、能源供給、視頻監控和垃圾收集等；2）輿情管理（public opinion management）中的移動設備定位、社交網絡分析、音視頻甄別和災害預警等；3）生產和物流（production and logistics）中的工業傳感器管理、品質控制、質量溯源、生產優化、物流優化等；4）影音娛樂，包括廣告推送、游戲平臺、電視頻道和音頻廣播等。

（3）混合計算

第三代大數據處理技術混合計算始于2012年，其標志為Nathan Marz研發了拉姆達體系結構（Lambda architecture）^[115]。拉姆達體系結構是一個實時的大數據處理框架，其基本理念如下：大數據系統的架構分為三個層次，即批處理層（batch layer）、服務層（service layer）和實時處理層（speed layer），其能夠滿足實時大數據系統的關鍵性要求，例如高容錯性、低延時性和高擴展性等。目前，混合計算方面的相關技術在保持發展，學界和業界認為其將是未來十年內極具挑戰性的研究領域。

混合計算技術的出現源于眾多應用領域都對批處理技術與實時處理技術的結合存在需求，因此產生了拉姆達體系結構這個混合處理模型。在拉姆達體系結構中，批處理層管理主要數據集，通常該數據集存儲在分布式文件系統中，并且其數據是不可變的（unchangeable）。服務層從數據倉庫中加載數據并生成批處理視圖，負責為各類查詢提供批處理的結果。實時處理層只針對有低時延需求的應用所涉及的新數據進行處理。一般來說，為了獲得完整的數據分析結果，需要對批處理視圖和實時處理視圖都進行查詢，然后將結果進行合并（merge）。此時，需要對同步、結果組合以及模塊協調（module coordination）等事務進行處理。換言之，在混合計算模型中，批處理技術對所有現存的數據進行處理，以產生批處理結果。批處理對整個數據集進行循環式的處理，單次執行需要較長的時間，因此新的數據只能等待下一次批處理任務時再加入數據集進行處理。針對批處理耗時較長這個問題，引入實時處理技術進行彌補。實時處理技術對新的數據進行實時處理，以產生流處理結果。與批處理技術不同，實時處理技術僅對新數據進行處理，即未被批處理任務分析過的數據。合并上述兩個結果，可以形成最終的結果。

3.大數據處理的生命周期和典型工具

大數據處理的各項技術通常都涉及整個大數據的生命周期。文獻[116]提出了一種科學數據生命周期管理（Scientific Data Lifecycle Management，SDLM）模型，分析了現代數據管理中涉及的主要階段以及反映出的具體細節。此外，該文獻還提出了科學數據基礎設施（Scientific Data Infrastructure，SDI）模型，并為大數據的研究者提供了建立交互類數據項目的基礎。文獻[117]對大數據生態系統體系結構中所涉及的構件進行了詳細的闡述，并通過對相關重要構件的分析總結出了大數據所面臨的主要挑戰。此外，其還給出了大數據生態系統中大數據的生命周期。具體來說，從數據的產生到數據的最終消費包含以下環節：數據源（data source）、數據采集與注冊（data collection and registration）、數據過濾與分類（data filter and classification）、數據分析與建模（data analytics and modeling）、數據可視化（data visualization）以及數據消費者（data consumer）。文獻[118]中闡述的DataONE模型指出數據生命周期包含如下的閉環階段：采集（collect）、確保（assure）、描述（describe）、保存（preserve）、發現（discover）、集成（integrate）、分析（analyze）和計劃（plan），計劃階段所得到的方案與結論又反饋給采集階段，如此往復，形成閉環。

文獻[97]將大數據的生命周期分為數據獲取（data acquisition）、數據存儲（data storage）、數據分析（data analysis）以及結果（result），并且將前述大數據處理的三代技術中相關的工具映射至數據獲取、數據存儲和數據分析三個環節來進行分類討論，詳情如表1-2所示。在數據獲取階段，通常涉及從多源異構的數據源獲取數據，這些數據源可能是批處理數據源，也有可能是實時流數據源；在數據存儲階段，需要對前一階段已經獲取到的數據進行存儲，以便進行后續的分析與處理，常見的存儲方式有磁盤（disk）形式和無盤（diskless）形式。在數據分析階段，針對不同的應用需求，會運用各類模型和算法來對數據進行分析與處理。在表1-2中，三代技術中不同的處理階段所涉及的工具存在重疊。此外，對于混合計算技術，其本身同時涉及批處理技術和實時處理技術，實現混合計算模型的技術也要比單純的批處理技術和實時處理技術更加復雜；鑒于混合計算技術的上述特點，這里不對在數據的獲取、存儲與分析方面所涉及的具體工具做特別的劃分。

（1）HDFS

Hadoop^[7]分布式文件系統（Hadoop Distributed File System，HDFS）目前是Apache Hadoop項目的一個子項目，與已有的分布式文件系統有很多相似之處。此外，作為專門針對商業化硬件（commodity hardware）設計的文件系統，HDFS的獨特之處也很明顯：首先其具有很高的容錯性，其次可以部署在較為廉價的硬件上，最后能夠提供高吞吐量的應用數據訪問能力。對于終端用戶而言，HDFS就是一個傳統的文件系統，具有文件和目錄的創建、修改、刪除等常規操作。HDFS采用主/從（Master/Slave）體系結構。單個HDFS集群僅包含一個名稱節點（NameNode），其提供元數據服務，管理文件系統的命名空間（namespace），并引導用戶對文件的訪問。此外，單個HDFS集群可以包含多個數據節點（DataNode），數據節點負責管理與自身相關聯的存儲空間。HDFS對外給出文件系統的命名空間作為用戶對數據進行訪存的接口。在HDFS內部，單個文件通常被分割成多個塊（block），這些塊存儲在一系列數據節點上。由名稱節點在整個HDFS集群的命名空間上執行文件和目錄的打開、讀取和關閉等操作。文件的塊與數據節點之間的映射也是由名稱節點管理的。數據節點基于名稱節點的指令來實施塊的創建、復制和刪除等。

（2）Sqoop

Sqoop^[8]是一個在Hadoop和關系數據庫服務器之間傳送數據的工具，方便大量數據的導入導出工作，其支持多種類型的數據存儲軟件。Sqoop的核心功能為數據的導入和導出。導入數據：從諸如MySQL、SQL Server和Oracle等關系數據庫將數據導入到Hadoop下的HDFS、Hive和HBase等數據存儲系統。導出數據：從Hadoop的文件系統中將數據導出至關系數據庫。Sqoop的一個顯著特點是可以使用MapReduce將數據從傳統的關系數據庫導入到HDFS中。Sqoop作為一個通用性的工具，只需要在一個節點上安裝，因此安裝和使用十分便捷。

（3）Flume

Flume是由Hadoop生態系統中著名的軟件公司Cloudera于2011年發布，該軟件能夠支持分布式海量日志的采集、集成與傳輸，以實時的方式從數據發送方獲取數據，并傳輸給數據接收方。Flume具有兩個顯著的特點：可靠性和可擴展性。針對可靠性，其提供了從強到弱的三級保障，即End-to-end、Store on failure和Best effort。針對可擴展性，其采用三層的體系結構，即Agent、Collector和Storage，每層都可以在水平方向上進行擴展。Flume以Agent的方式運行，單個Agent包含Source、Channel和Sink三個組件，由Agent對數據進行收集，然后交付給存儲機制。從多個數據源收集到的日志信息依次經過上述三個組件，然后存入HDFS或HBase中。因此，通過Flume可以將數據便捷地轉交給Hadoop體系結構。

（4）Scribe

Scribe^[9]是由Facebook開發的分布式日志系統，在Facebook內部已經得到了廣泛的應用。Scribe能夠針對位于不同數據源的日志信息進行收集，然后存儲至某個統一的存儲系統，這個存儲系統可以是網絡文件系統（Network File System，NFS），也可以是分布式文件系統。Scribe的體系結構由三部分組成：Scribe Agent、Scribe和Storage。第一部分Scribe Agent為用戶提供接口，用戶使用該接口來發送數據。第二部分Scribe接收由Scribe Agent發送來的數據，根據各類數據所具有的不同topic再次分發給不同的實體。第三部分Storage包含多種存儲系統和介質。Scribe的日志收集行為只包括主動寫入的日志，Scribe自身沒有主動抓取日志的功能。因此，用戶需要主動向Scribe Agent發送相關的日志信息。

（5）HBase

HBase^[10]的全稱為Hadoop Database，是基于谷歌BigTable的開源實現，其使用Hadoop體系結構中的HDFS作為基本的文件系統。谷歌根據BigTable的理念設計實現了谷歌文件系統GFS，但是該方案未開源。HBase可以稱為BigTable的山寨版，是開源的。HBase在Hadoop體系結構中的位置介于HDFS和MapReduce之間，其架構為主/從形式，內部的兩個核心構件為Master和RegionServer。HBase是建立在HDFS之上的分布式面向列的數據庫，能夠針對海量結構化數據實現隨機的實時訪問，其設計理念和運行模式都充分利用了HDFS的高容錯性。由于HBase是面向列的，因此它在數據庫的表中是按照行進行排序的。在HBase中，所有的存儲內容都是字節，任何要存儲的內容都需要先轉換成字節流的形式，此外數據庫的行鍵值按照字節進行排序，同時形成了索引。

（6）MapReduce

MapReduce^[11]是Hadoop體系結構中極為重要的核心構件之一。作為一個分布式的并行計算模型，MapReduce包含的兩個單詞分別具有特定的含義：“Map”表示“映射”；“Reduce”表示“歸約”。上述兩個概念的基本理念源于函數式編程語言（functional programming language）。與傳統的編程語言不同，函數式編程語言是一類非馮諾依曼式的程序設計語言，其編程范式的抽象程度很高，主要由原始函數、定義函數和函數型構成。MapReduce的這種設計思想使分布式并行程序設計的難度得以簡化，用戶將已有的代碼稍加修改就能夠運行在分布式環境下。在實際應用場景中，大多數情況下收集到的大量多源異構數據都不具有特定的規律和特征。MapReduce的工作過程能夠在一定程度上將上述數據按照某種規律進行歸納和總結。在“Map”階段，通過指定的映射函數提取數據的特征，得到的結果的形式為鍵值對<key,value>。在“Reduce”階段，通過指定的歸約函數對“Map”階段得到的結果進行統計。對于不同的具體問題，所需要的歸約函數的個數可能千差萬別。總體來說，MapReduce具有開發難度低、擴展性強和容錯性高三個顯著特點。盡管其分布式并行計算模型能大幅度提高海量數據的處理速度，但受限于大數據的規模，通常MapReduce的作業例程的執行時間為分鐘級，隨著數據量的增加，耗時若干天也很普遍。

（7）Hive

Hive^[12]針對數據倉庫來提供類似SQL語句的查詢功能，其能夠將以結構化形式存儲的數據映射成數據庫表，主要應用場景為多維度數據分析和海量結構化數據離線分析。Hive的體系結構主要包含用戶接口、元數據存儲、解釋器、編譯器、優化器和執行器。雖然使用MapReduce也能夠實現查詢，但是對于邏輯復雜度高的查詢，用戶在實現時難度較大。Hive提供類似于SQL的語法接口，降低了學習成本，提高了開發效率。Hive基于SQL的語法來定義名為HiveQL或HQL的查詢語言，其支持常規的索引化和基本的數據查詢，更重要的是能夠將基于SQL的查詢需求轉化為MapReduce的作業例程。除了自身具有的功能之外，用戶可以在Hive中編寫自定義函數，具體來說分為三種：用戶自定義函數（User Defined Function，UDF）、用戶自定義聚合函數（User Defined Aggregation Function，UDAF）和用戶自定義表生成函數（User Defined Table-generating Function，UDTF）。

（8）Pig

Pig^[13]是一個面向過程的高級程序設計語言，能夠分析大型數據集，并將結果表示為數據流，其內置了多種數據類型，并且支持元組（tuple）、映射（map）和包（package）等范式。Pig有兩種工作模式：Local模式和MapReduce模式。在Local模式下，Pig的運行獨立于Hadoop體系結構，全部操作均在本地進行。在MapReduce模式下，Pig使用了Hadoop集群中的分布式文件系統HDFS。作為一種程序設計語言，Pig能夠對數據進行加載、處理，并且存儲獲得的結果。Pig和Hive均能夠簡化Hadoop的常見工作任務。Hive通常應用在靜態數據上，處理例行性的分析任務。Pig比Hive在規模上更加輕量，其與SQL的結合使得用戶能夠使用比Hive更加簡潔的代碼來給出解決方案。與MapReduce相比，Pig在接口方面提供了更高層次的抽象，具有更多的數據結構類型。此外，Pig還提供了大量的數據變換操作，MapReduce在這方面比較薄弱。

（9）Cascading

Cascading^[14]是用Java語言編寫成的開源庫，能夠脫離MapReduce來完成對復雜數據工作流的處理。該開源庫提供的應用程序編程接口定義了復雜的數據流以及將這些數據流與后端系統集成的規則。此外，其還定義了將邏輯數據流映射至計算平臺并進行執行的規則。針對數據的提取、轉換和加載（Extract Transform Load，ETL），Cascading提供了6個基本操作：復制（copy）、過濾（filter）、合并（merge）、計數（count）、平均（average）和結合（join）。初級的ETL應用程序通常涉及數據和文件的復制，以及不良數據的過濾。針對多種不同數據源的輸入文件，需要對它們進行合并。計數和平均是對數據和記錄進行處理的常用操作。結合指的是將不同處理分支中的處理結果按照給定的規則進行結合。

（10）Spark

與Hadoop類似，Spark^[15]也是一個針對大數據的分布式計算框架。Spark可以用來構建大規模、低延遲的數據處理應用程序。相對于Hadoop，Spark的顯著特點是能夠在內存中進行計算，因此又稱為通用內存并行計算框架，與MapReduce兼容，其主要構件包括SparkCore、SparkSQL、SparkStreaming、MLlib、GraphX、BlinkDB和Tachyon。Hadoop存在磁盤I/O和序列化等性能瓶頸，在Spark的設計理念中，選用內存來存儲Hadoop中存儲在HDFS的中間結果。Spark兼容HDFS，能夠很好地融入Hadoop體系結構，被認為是MapReduce的替代品。根據Spark官方網站的數據，Spark的批處理速度比MapReduce提升了近10倍，內存中的數據分析速度則提升了近100倍。Spark模型所特有的彈性分布式數據集（Resilient Distributed Dataset，RDD）使得針對數據的災難恢復在內存和磁盤上都可以實現。總體來說，Spark的編程模型具有以下四個特點：速度（speed）、簡易（ease of use）、通用（generality）和兼容（runs everywhere）。在速度方面，Spark使用基于有向無環圖（Directed Acyclic Graph，DAG）的作業調度算法，采用先進的查詢優化器和物理執行器提高了數據的批處理和流式處理的性能。在簡易方面，Spark支持多種高級算法，用戶可以使用Java、Scala、Python、R和SQL等語言編寫交互式應用程序。在通用方面，Spark提供了大量的通用庫，使用這些庫可以方便地開發出針對不同應用場景的統一解決方案，極大地降低了研發與運營的成本。在兼容方面，Spark本身能夠方便地與現有的各類開源系統無縫銜接，例如已有的Hadoop體系結構中的HDFS和Hbase。

（11）Shark

作為一個面向大規模數據的數據倉庫工具，Shark^[16]最初是基于Hive的代碼進行開發的。Hive在執行交互查詢時需要在私有數據倉庫上執行非常耗時的ETL操作，為了彌補這個性能問題，Shark成了Hadoop體系結構中的首個交互式SQL軟件。Shark支持Hive包含的查詢語言、元存儲、序列化格式以及自定義函數。后來，Hadoop體系結構中MapReduce本身的結構限制了Shark的發展，研究者們中止了Shark的研發，啟動了Shark SQL這個新項目。Shark SQL是基于Spark的一個組件，提供了針對結構化數據的便捷操作，統一了結構化查詢語言與命令式語言。Shark在Spark的體系結構中提供了和Hive相同的HiveQL編程接口，因此與Hive兼容。通過Hive的HQL解析，將HQL轉換成Spark上的RDD操作。

（12）Kafka

Kafka^[17]是一個分布式流處理平臺（distributed streaming platform），最初由領英公司開發，使用的編程語言是Java和Scala。Kafka支持分區（partition）和副本（replica），針對消息隊列進行處理。消息傳送功能包含連接服務（connection service）、消息的路由（routing）、傳送（delivery）、持久性（durability）、安全性（security）和日志記錄（log）。Kafka的主要應用程序接口有如下四類：生產者（producer API）、消費者（consumer API）、流（stream API）和連接器（connector API）。Kafka對外的接口設計理念是基于話題（topic）的，消息生成后被寫入話題中，用戶從話題中讀取消息。單個的話題由多個分區構成，當系統性能下降時，通常的操作是增加分區的個數。分區之間的消息互相獨立，每個分區內的消息是有序的。新消息的寫入操作在具體實現中為相應文件內容的追加操作，該方式具有較強的性能。由于一個話題可以包含多個分區，因此Kafka具有高吞吐量、低延遲的特性。消息隊列包含兩個模型：點對點（point-to-point）和發布/訂閱（publish/subscribe）。對于點對點模型，消息生成后進入隊列，由用戶從隊列中取出消息并使用。當消息被使用后，其生命周期已經結束，即該消息無法再次被使用。雖然消息隊列支持多個用戶，但一個消息僅能夠被一個用戶所使用。對于發布/訂閱模型，消息生成后其相關信息會被發布到多個話題中，只要訂閱了相關話題的用戶就都可以使用該消息。與點對點模型不同，在發布/訂閱模型中一個消息可以被多個用戶使用。

（13）Kestrel

Kestrel是由推特（Twitter）開發的開源中間件（middleware），使用的編程語言為Scala，其前身是名為Starling的輕量級分布式隊列服務器，同樣Kestrel也具有輕量化的特點。Starling支持MemCache協議，其能夠方便地構建網絡訪問隊列。推特早期使用Starling來處理大量的隊列消息，后來推特將基于Ruby語言的Starling項目進行重構，使用Scala語言將其重新實現，得到Kestrel。在協議支持性方面，Kestrel支持三類協議：MemCache、Text和Thrift，其中MemCache協議沒有完整地實現，僅支持部分操作。Kestrel本身運行在Java虛擬機（Java Virtual Machine，JVM）上，針對Java的各類優化措施均可以使用。為了改善性能，Kestrel中的隊列存儲在內存中，針對隊列的操作日志保存在硬盤中。雖然Kestrel本身是輕量化的，但其具有豐富的配置選項，能夠很方便地組成集群，集群中的節點互相之間是透明的，針對隊列中消息獲取的GET協議支持阻塞獲取和可靠獲取。阻塞獲取是指用戶可以設置超時時間，在時間內有消息的話即刻返回，如果超時后還沒有消息就結束等待。可靠獲取是指隊列服務器只有在收到用戶明確的確認反饋后，才將相關的消息從隊列中永久刪除。如果用戶使用GET操作從隊列獲取消息后隊列服務器馬上將該消息從隊列中刪除，那么此后需要用戶來確保該消息不會異常丟失，這對網絡狀態和系統運行的特定環境要求較為苛刻。因此，用戶可以采用可靠獲取的方式來消除上述疑慮。

（14）Storm

Storm^[18]編寫而成的分布式實時處理系統，其雛形是由Nathan Marz和BackType構建的，BackType是一家社交數據分析公司。2011年，推特收購BackType，并將Storm開源。Storm的主要功能是針對持續產生的數據流進行計算，進而彌補了Hadoop體系結構對實時性支持的缺失。Storm的處理速度快，具有良好的可擴展性和容錯性，其所處理的數據位于內存中。用戶在Storm中設計的計算圖稱為拓撲（topology），拓撲中包含主節點和從節點，且以集群的形式呈現。Storm的主/從體系結構是由兩類節點實現的：控制節點（master node）和工作節點（worker node），調度相關的信息以及主從節點的重要工作數據都是由ZooKeeper集群來負責處理的。控制節點為主節點，其上運行的Nimbus進程主要負責狀態監測與資源管理，該進程維護和分析Storm的拓撲，同時收集需要執行的任務，然后將收集到的任務指派給可用的工作節點。工作節點為從節點，其上運行的Supervisor進程包含一個或多個工作進程（worker），工作進程根據所要處理的任務量來配置合理數量的執行器（executor）以便執行任務。Supervisor進程監聽本地節點的狀態，根據實際情況啟動或者結束工作進程。拓撲中的數據在噴嘴（spout）之間傳遞，噴嘴把從外部數據源獲取到的數據提供給拓撲，因此是Storm中流的來源。數據流中數據的格式稱為元組（tuple），具體來說為鍵值對（key-value pair），元組用來封裝需要處理的實際數據。針對數據流的計算邏輯都是在螺栓（bolt）中執行的，具體的處理過程中除了需要指定消息的生成、分發和連接，其余的都與傳統應用程序類似。

（15）Trident

Trident^[19]是位于Storm已有的實時處理環境之上更高層的抽象構件，提供了狀態流處理和低延遲的分布式查詢功能，其屏蔽了計算事務處理和運行狀態管理的細節。此外，還針對數據庫增加了更新操作的原語。在Trident中，數據流的處理按照批次進行，即所謂的事務。一般來說，對于不同的數據源，每個批次的數據量的規模可達數百萬個元組。一個處理批次稱為一個事務，當所有處理完成之后，認為該事務成功結束；當事務中的一個或者多個元組處理失敗時，整個事務需要回滾（rollback），然后重新提交。Trident的事務控制包含三個層次：非事務控制（non-transactional）、嚴格的事務控制（transactional）和不透明的事務控制（opaque-transactional）。對于非事務控制，單個批次內的元組處理可以出現部分處理成功的情況，處理失敗的元組可以在其他批次進行重試。對于嚴格的事務控制，單個批次內處理失敗的元組只能在該批次內進行重試，如果失敗的元組一直無法成功處理，那么進程掛起，即不包含容錯機制。對于不透明的事務控制，單個批次內處理失敗的元組可以在其他批次內重試一次，其容錯機制規定重試操作有且僅有一次。上述針對消息的可靠性保障機制使得數據的處理有且僅有一次，保證了事務數據的持久性。容錯機制使得失敗的元組在重試環節的狀態更新是冪等的，冪等性是統計學中的一個重要性能指標，其保證了即使數據被多次處理，從處理結果的角度來看和處理一次是相同的。Trident的出現顯著減少了編寫基于Storm的應用程序的代碼量，其本身具有函數、過濾器、連接、分組和聚合功能。在組件方面，它保留了Spout，將Bolt組件中實現的處理邏輯映射為一些新的具體操作，例如過濾、函數和分組統計等。數據的狀態可以保存在拓撲內部存儲當中（例如內存），也可以保存在外部存儲當中（例如磁盤），Trident的應用程序接口支持這兩種機制。

（16）S4

S4項目^[20]是由雅虎（Yahoo）提出的，作為一個分布式流處理計算引擎，其設計的初衷是與按點擊數付費的廣告結合，基于實時的計算來評估潛在用戶是否可能對廣告進行點擊。這里S4是指簡單的（Simple）、可擴展的（Scalable）、流（Streaming）以及系統（System）。在S4項目提出之前，雅虎已經擁有了Hadoop，但Hadoop的基本理念是批處理，即利用MapReduce對已經過存儲的靜態數據進行處理。盡管MapReduce的處理速度非常快，但是從本質上說，其無法處理流數據。S4項目將流數據看作事件，其具體的實現中包含五個重要構件：處理節點（processing element）、事件（event）、處理節點容器（Processing Element Container，PEC）、機器節點（node）和機器節點集群（cluster）。一個集群中包含多個機器節點，一個機器節點中包含一個處理節點容器，一個處理節點容器中包含多個處理節點。處理節點對事件進行處理，處理結果作為新的事件，其能夠被其他處理節點處理。上述的點擊付費廣告的應用場景具有很高的實時性要求，而Hadoop無法很好地應對這樣的要求。具體來說，MapReduce所處理的數據是保存在分布式文件系統上的，在執行數據處理任務之前，MapReduce有一個數據準備的過程，需要處理的數據會按照分塊依次進行運算，不同的數據分塊大小可以對所謂的實時性進行調節。當數據塊較小時，可以獲得一定的低延遲性，但是數據準備的過程就會變得很長；當數據塊較大時，數據處理的過程無法實現較低的延遲性。諸如S4的流計算系統所處理的數據是實時的流數據，即數據源源不斷地從外部數據源到達處理系統。流計算處理系統的主要目標是在保證給定的準確度和精確性的前提下以最快的速度完成數據的處理。如果流數據不能夠被及時處理，那么其潛在的價值就會大打折扣，隨著處理時間的增長，流數據的潛在價值保持遞減。軟件開發者能夠根據不同的場景和需求在S4的上層開發處理流數據的應用程序。

（17）Spark Streaming

作為Spark的組成部分，Spark Streaming^[21]主要針對流計算任務，其能夠與Spark的其他構件很好地進行協作。一般來說，大數據的處理有兩類方式：批處理和流計算。對于批處理，任務執行的對象是預先保存好的數據，其任務頻率可以是每小時一次，每十小時一次，也可以是每二十四小時一次。批處理的典型工具有Spark和MapReduce。對于流處理，任務執行的對象是實時到達的、源源不斷的數據流。換言之，只要有數據到達，那么就一直保持處理。流處理的典型工具有Kafka和Storm。作為Spark基礎應用程序接口的擴展，Spark Streaming能夠從眾多第三方應用程序獲得數據，例如Kafka、Flume和Kinesis等。在Spark Streaming中，數據的抽象表示是以離散化的形式組織的，即DStreams。DStreams可以用來表示連續的數據流。在Spark Streaming的內部，DStreams是由若干連續的彈性數據集（Resilient Distributed Dataset，RDD）構成的，每個彈性數據集中包含的數據都是來源于確定時間間隔。Spark Streaming的數據處理模式是對確定時間間隔內的數據進行批處理。由于部分中間結果需要在外存中進行存儲，因此傳統的批處理系統一般運行起來較為緩慢，但是這樣的處理模式可以具有很高的容錯性。Spark Streaming的數據處理模式是基于彈性數據集進行的，通常將絕大部分中間結果保存在內存中，可以根據彈性數據集之間的互相依賴關系進行高速運算。這樣的處理模式也被稱為微批次處理架構，具體的特點是數據處理的粒度較為粗糙，針對每個選定的彈性數據集進行處理，對于批次內包含的數據無法實現進一步的細分。

（18）Lambdoop

2013年，項目負責人Rubén Casado在巴塞羅那的NoSQL Matters大會上發布了Lambdoop框架。Lambdoop是一個結合了實時處理和批處理的大數據應用程序開發框架，其基于Java語言。Lambdoop中可供選擇的處理范式（processing paradigm）有三種：非實時批處理、實時流處理和混合計算模型。Lambdoop實現了一個基于Lambda的體系結構，該結構為軟件開發者提供了一個抽象層（abstraction layer），使用與Lambda架構類似的方式來開發大數據相關的應用程序。對于使用Lambdoop應用程序開發框架的用戶，軟件開發者在應用程序的開發過程中不需要處理不同技術、參數配置和數據格式等煩瑣的細節問題，只需要使用必需的應用程序接口。此外，Lambdoop還提供了輔助的軟件工具，例如輸入/輸出驅動、數據可視化接口、聚類管理工具以及大量人工智能算法的具體實現。大多數已有的大數據處理技術關注于海量靜態數據的管理，例如前述的Hadoop、Hive和Pig等。此外，學界和業界也對動態數據的實時處理較為關注，典型的應用軟件有前述的Storm和S4。由于針對海量靜態數據的批處理能夠考慮到更多相關信息，因此相應的處理結果具有更高的可靠性和健壯性，例如訓練出更加精確的預測模型。遺憾的是，絕大多數批處理過程耗時較長，在對響應時間要求較高的應用領域，批處理是不可行的。從理論上來說，實時處理能夠解決上述問題，但實時處理有一個重大的缺陷：由于需要保證較小的延遲，實時處理所分析的數據量是十分有限的。在實際的生產環境中，通常需要實時處理和批處理兩種方式各自具有的優點，這對軟件開發者來說是一個挑戰性的難題，同時這也是Lambdoop的設計初衷^[130]。

（19）SummingBird

SummingBird是由推特于2013年開源的數據分析工具^[132]，大數據時代的數據處理分為批處理和實時處理兩大領域，這兩種方式各有利弊，僅采用一種處理方式無法滿足各類應用日益多樣化的需求。作為能夠處理大規模數據的應用軟件，SummingBird的設計初衷是將上述兩種處理方式結合起來，最大限度地獲得批處理技術提供的容錯性和實時處理技術提供的實時性，其支持批處理模式（基于Hadoop/MapReduce）、流處理模式（基于Storm）以及混合模式。SummingBird最大的特點是無縫融合了批處理和流處理。推特通過SummingBird整合批處理和流處理來降低在處理模式之間轉換帶來的開銷，提供近乎原生Scala和Java的方式來執行MapReduce任務。SummingBird作業流程包含兩種形式的數據：流（stream）和快照（snapshot），前者記錄了數據處理的全部歷史，后者為作業系統在單個時間戳上的快照。簡單地說，SummingBird可以認為是Hadoop和Storm的結合，具體包含以下構件：Producer，即數據的抽象，傳遞給指定的平臺做MapReduce流編譯；Platform，即平臺的實例，由MapReduce庫實現，SummingBird提供了平臺對Storm和相關內存處理的支持；Source，即數據源；Store，即包含所有鍵值對的快照；Sink，即能夠生成包含Producer具體數值的非聚合流，Sink是流，不是快照；Service，即供用戶在Producer流中的當前數值上執行查找合并（lookup join）和左端合并（left join）的操作，合并的連接值可以為其他Store的快照、其他Sink的流和其他異步功能提供的快照或者流；Plan，由Platform生成，是MapReduce流的最終實現。對于Storm來說Plan是StormTopology的實例，對于Memory來說Plan是內存中的stream。文獻[133]分析了SummingBird平臺的可行性和優勢，提出了基于SummingBird的能源互聯網云計算平臺。

4.大數據生態系統

文獻[117]指出，大數據本身囊括了存儲、處理、可視化和結果表達等若干個復雜的構件。其不僅是一個數據庫或者Hadoop體系結構的問題，盡管它們構成了大規模數據處理和數據分析的核心技術和構件^[134][135]。所有互相關聯的構件共同構成了大數據生態系統（big data ecosystem），該系統涵蓋了大數據的整個生命周期中的基礎設施結構與處理模型。當前，Hadoop是大數據生態系統中的核心構件。

Hadoop的出現使得具有不同結構或者完全無結構的超大規模數據能夠被處理、管理和分析，但是該體系結構也存在一些局限性^[68]：

·生成多個數據副本：由于HDFS設計的初衷是提高效率，因此數據被存儲為多個副本。一般來說，數據是以至少一式三份的形式產生的。但是，為了通過數據本地化來保持性能，必須產生數據的六個副本。因此，數據的規模進一步增大。

·具有挑戰性的框架：當前MapReduce框架的結構比較復雜，尤其是當需要利用復雜的轉換邏輯時。學界和業界在改進MapReduce框架方面已有一些嘗試，所做的工作大多集中于研發開源模塊來對初始的框架進行簡化，但這些開源模塊使用的也是注冊語言（registered language）。

·非常有限的SQL支持：Hadoop將分布式系統領域的若干開源項目和編程框架進行聯合，進而完成大數據分析的完整周期。但是，其對SQL的支持很有限，而且缺乏基本的SQL函數，使得常規數據分析中的很多功能存在缺失，例如子查詢（subquery）操作和分組（grouping）操作。

·缺乏基本的技術：如前所述，Hadoop的體系結構是由開源項目組合而成的，Hadoop項目中包含了一些精妙的數據挖掘函數庫。但是從整體角度來看，這些函數庫或者說單個的技術之間在設計理念、數據結構和代碼實現上缺乏一致性。因此，對于MapReduce來說，需要比較成體系的、設計與實現具有一致性的算法和相應的函數庫。

·低效的執行：HDFS沒有考慮對查詢進行優化。因此，其執行操作時無法擁有較高的性價比。這樣導致的結果是Hadoop中簇的規模通常比實際所需的類似數據庫要大很多倍。

[1] https://www.sas.com/

[2] https://www.ibm.com/analytics/spss-statistics-software/

[3] https://rapidminer.com/

[4] http://www.minitab.com/en-us/

[5] https://www.r-project.org/

[6] http://www.gnu.org/software/pspp/

[7] https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

[8] https://sqoop.apache.org/

[9] https://github.com/facebookarchive/scribe/

[10] https://hbase.apache.org/

[11] https://hadoop.apache.org/docs/r1.0.4/cn/mapred_tutorial.html

[12] https://hive.apache.org/

[13] https://pig.apache.org/

[14] https://www.cascading.org/

[15] https://spark.apache.org/

[16] https://github.com/amplab/shark/wiki/Shark-User-Guide/

[17] http://kafka.apachecn.org/intro.html

[18] https://storm.apache.org/是使用Java和Clojure◣28注：https://www.clojure.org/

[19] https://storm.apache.org/releases/current/Trident-tutorial.html

[20] https://incubator.apache.org/projects/s4.html

[21] https://spark.apache.org/streaming/