大數(shù)據(jù)操作方法

時(shí)間：2022-02-20 23:04:01 | 來(lái)源：信息時(shí)代

時(shí)間：2022-02-20 23:04:01 來(lái)源：信息時(shí)代

SOA模型

我們需要的是以數(shù)據(jù)為中心的SOA還是以SOA為中心的數(shù)據(jù)？答案取決于如何處理的SOA-數(shù)據(jù)關(guān)系的三個(gè)不同模型來(lái)管理大數(shù)據(jù)、云數(shù)據(jù)和數(shù)據(jù)層次結(jié)構(gòu)。在越來(lái)越多的虛擬資源中，將這些模型之間所有類型的數(shù)據(jù)進(jìn)行最優(yōu)擬合是SOA所面臨的巨大挑戰(zhàn)之一。本文詳細(xì)介紹了每個(gè)SOA模型管理數(shù)據(jù)的優(yōu)點(diǎn)、選擇和選項(xiàng)。

SOA的三個(gè)數(shù)據(jù)中心模型分別是數(shù)據(jù)即服務(wù)(DaaS)模型、物理層次結(jié)構(gòu)模型和架構(gòu)組件模型。DaaS數(shù)據(jù)存取的模型描述了數(shù)據(jù)是如何提供給SOA組件的。物理模型描述了數(shù)據(jù)是如何存儲(chǔ)的以及存儲(chǔ)的層次圖是如何傳送到SOA數(shù)據(jù)存儲(chǔ)器上的。最后，架構(gòu)模型描述了數(shù)據(jù)、數(shù)據(jù)管理服務(wù)和SOA組件之間的關(guān)系。

SOA和數(shù)據(jù)企業(yè)的例子

也許以極限情況為開(kāi)始是理解SOA數(shù)據(jù)問(wèn)題的最好方式：一個(gè)企業(yè)的數(shù)據(jù)需求完全可以由關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)(RDBMS)中的條款來(lái)表示。這樣一個(gè)企業(yè)可能會(huì)直接采用數(shù)據(jù)庫(kù)設(shè)備或者將專用的數(shù)據(jù)庫(kù)服務(wù)器和現(xiàn)有的查詢服務(wù)連接到SOA組件（查詢即服務(wù)，或QaaS）上。這種設(shè)計(jì)理念之前已經(jīng)被人們所接受。該設(shè)計(jì)之所以成功是因?yàn)樗胶饬松鲜鋈齻€(gè)模型之間的關(guān)系。QaaS服務(wù)模型不是機(jī)械地連接到存儲(chǔ)器上；而是通過(guò)一個(gè)單一的架構(gòu)——RDBMS（關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)）。數(shù)據(jù)去重和完整性便于管理單一的架構(gòu)。

通過(guò)大數(shù)據(jù)的例子可以更好地理解為什么這個(gè)簡(jiǎn)單的方法卻不能在更大的范圍內(nèi)處理數(shù)據(jù)。多數(shù)的大數(shù)據(jù)是非關(guān)系型的、非交易型的、非結(jié)構(gòu)化的甚至是未更新的數(shù)據(jù)。由于缺乏數(shù)據(jù)結(jié)構(gòu)因此將其抽象成一個(gè)查詢服務(wù)并非易事，由于數(shù)據(jù)有多個(gè)來(lái)源和形式因此很少按序存儲(chǔ)，并且定義基礎(chǔ)數(shù)據(jù)的完整性和去重過(guò)程是有一些規(guī)則的。當(dāng)作為大數(shù)據(jù)引入到SOA的應(yīng)用程序中時(shí)，關(guān)鍵是要定義三種模型中的最后一種模型，SOA數(shù)據(jù)關(guān)系中的架構(gòu)模型。有兩種選擇：水平方向和垂直方向。

SOA和各類數(shù)據(jù)模型

在水平集成數(shù)據(jù)模型中，數(shù)據(jù)收集隱蔽于一套抽象的數(shù)據(jù)服務(wù)器，該服務(wù)器有一個(gè)或多個(gè)接口連接到應(yīng)用程序上，也提供所有的完整性和數(shù)據(jù)管理功能。組件雖不能直接訪問(wèn)數(shù)據(jù)，但作為一種即服務(wù)形式，就像他們?cè)诤?jiǎn)單情況下的企業(yè)，其數(shù)據(jù)的要求是純粹的RDBMS模型。應(yīng)用程序組件基本上脫離了RDBMS與大數(shù)據(jù)之間數(shù)據(jù)管理的差異。盡管由于上述原因這種方法不能創(chuàng)建簡(jiǎn)單的RDBMS查詢模型，但是它至少?gòu)?fù)制了我們上面提到的簡(jiǎn)單的RDBMS模型。

垂直集成的數(shù)據(jù)模型以更多應(yīng)用程序特定的方式連接到數(shù)據(jù)服務(wù)上，該方式使得客戶關(guān)系管理、企業(yè)資源規(guī)劃或動(dòng)態(tài)數(shù)據(jù)認(rèn)證的應(yīng)用程序數(shù)據(jù)很大程度在服務(wù)水平上相互分離，這種分離直接涉及到數(shù)據(jù)基礎(chǔ)設(shè)施。在某些情況下，這些應(yīng)用程序或許有可以直接訪問(wèn)存儲(chǔ)/數(shù)據(jù)服務(wù)的SOA組件。為了提供更多統(tǒng)一的數(shù)據(jù)完整性和管理，管理服務(wù)器可以作為SOA組件來(lái)操作各種數(shù)據(jù)庫(kù)系統(tǒng)，以數(shù)據(jù)庫(kù)特定的方式執(zhí)行常見(jiàn)的任務(wù)，如去重和完整性檢查。這種方法更容易適應(yīng)于遺留應(yīng)用和數(shù)據(jù)結(jié)構(gòu),但它在問(wèn)數(shù)據(jù)何訪方式上會(huì)破壞SOA即服務(wù)原則，也可能產(chǎn)生數(shù)據(jù)管理的一致性問(wèn)題。

SOA和水平數(shù)據(jù)模型

毫無(wú)疑問(wèn)水平模型更符合SOA原則，因?yàn)樗鼜氐椎貜腟OA組件中抽象出了數(shù)據(jù)服務(wù)。不過(guò)，為了使其有效，有必要對(duì)非關(guān)系型數(shù)據(jù)庫(kù)進(jìn)行抽象定義和處理低效率與抽象有關(guān)的流程——SOA架構(gòu)師知道除非小心的避免此類事情否則這將會(huì)成為不可逾越的障礙。

水平的SOA數(shù)據(jù)策略已經(jīng)開(kāi)始應(yīng)用于適用大數(shù)據(jù)的抽象數(shù)據(jù)。解決這個(gè)問(wèn)題最常見(jiàn)的方法是MapReduce，可以應(yīng)用于Hadoop形式的云構(gòu)架。Hadoop以及類似的方法可以分發(fā)、管理和訪問(wèn)數(shù)據(jù)，然后集中查詢這一分布式信息的相關(guān)結(jié)果。實(shí)際上，SOA組件應(yīng)將MapReduce和類似數(shù)據(jù)分析功能作為一種查詢功能應(yīng)用。

效率問(wèn)題

效率問(wèn)題較為復(fù)雜。因?yàn)樗綌?shù)據(jù)庫(kù)模型可能是通過(guò)類似大多數(shù)SOA流程的信息服務(wù)總線來(lái)完成的，一個(gè)重要的步驟是要確保與該編排相關(guān)的開(kāi)銷額度保持在最低程度。這可以幫助減少與SOA相關(guān)的數(shù)據(jù)訪問(wèn)開(kāi)銷，但它不能克服存儲(chǔ)系統(tǒng)本身的問(wèn)題。因?yàn)檫@些存儲(chǔ)系統(tǒng)已經(jīng)通過(guò)水平模型脫離了SOA組件，很容易被忽略與延遲和數(shù)據(jù)傳輸量相關(guān)的問(wèn)題，特別地，如果數(shù)據(jù)庫(kù)是云分布的，那么使用他們就會(huì)產(chǎn)生可變的網(wǎng)絡(luò)延遲。

上述問(wèn)題的一個(gè)解決方案是現(xiàn)代分層存儲(chǔ)模式。數(shù)據(jù)庫(kù)不是磁盤，而是一組相互連接的高速緩存點(diǎn)，其存儲(chǔ)于本地內(nèi)存中，也可能轉(zhuǎn)向固態(tài)硬盤，然后到本地磁盤，最后到云存儲(chǔ)。緩存算法處理這些緩存點(diǎn)之間的活動(dòng)，從而來(lái)平衡存儲(chǔ)成本（同時(shí)也是平衡同步地更新成本）和性能。

對(duì)于大數(shù)據(jù)，它也是經(jīng)?？梢詣?chuàng)建適用于大多數(shù)分析的匯總數(shù)據(jù)。例如一個(gè)計(jì)算不同地點(diǎn)車輛數(shù)量的交通遙測(cè)應(yīng)用。這種方法可以產(chǎn)生大量的數(shù)據(jù)，但是如果匯總數(shù)據(jù)最后一分鐘還存儲(chǔ)在內(nèi)存中，最后一小時(shí)存儲(chǔ)在閃存中，最后一天存在磁盤上，那么控制應(yīng)用程序所需的實(shí)際時(shí)間可以通過(guò)快速訪問(wèn)資源得到滿足,然而假設(shè)分析時(shí)我們可以使用一些更便宜、更慢的應(yīng)用程序是會(huì)怎樣。

SOA都是抽象的，但當(dāng)抽象隱藏了底層影響性能和響應(yīng)時(shí)間的復(fù)雜性時(shí)，這種抽象的危險(xiǎn)程度會(huì)提高。數(shù)據(jù)訪問(wèn)也是這樣的，因此,SOA架構(gòu)師需要認(rèn)真地考慮抽象與性能之間的平衡關(guān)系，并為其特定的業(yè)務(wù)需求優(yōu)化它。

Hadoop

Hadoop旨在通過(guò)一個(gè)高度可擴(kuò)展的分布式批量處理系統(tǒng)，對(duì)大型數(shù)據(jù)集進(jìn)行掃描，以產(chǎn)生其結(jié)果。Hadoop項(xiàng)目包括三部分，分別是HadoopDistributedFileSystem（HDFS）、HadoopMapReduce編程模型，以及HadoopCommon。

Hadoop平臺(tái)對(duì)于操作非常大型的數(shù)據(jù)集而言可以說(shuō)是一個(gè)強(qiáng)大的工具。為了抽象Hadoop編程模型的一些復(fù)雜性，已經(jīng)出現(xiàn)了多個(gè)在Hadoop之上運(yùn)行的應(yīng)用開(kāi)發(fā)語(yǔ)言。Pig、Hive和Jaql是其中的代表。而除了Java外，您還能夠以其他語(yǔ)言編寫map和reduce函數(shù)，并使用稱為HadoopStreaming（簡(jiǎn)寫為Streaming）的API調(diào)用它們。與流數(shù)據(jù)分析

流定義

從技術(shù)角度而言，流是通過(guò)邊緣連接的節(jié)點(diǎn)圖。圖中的每個(gè)節(jié)點(diǎn)都是'運(yùn)算符'或'適配器'，均能夠在某種程度上處理流內(nèi)的數(shù)據(jù)。節(jié)點(diǎn)可以不包含輸入和輸出，也可以包含多個(gè)輸入和輸出。一個(gè)節(jié)點(diǎn)的輸出與另外一個(gè)或多個(gè)節(jié)點(diǎn)的輸入相互連接。圖形的邊緣將這些節(jié)點(diǎn)緊密聯(lián)系在一起，表示在運(yùn)算符之間移動(dòng)的數(shù)據(jù)流。

右圖一個(gè)簡(jiǎn)單的流圖，它可以從文件中讀取數(shù)據(jù)，將數(shù)據(jù)發(fā)送到名為Functor的運(yùn)算符（此運(yùn)算符能夠以某種編程方式轉(zhuǎn)換所傳入的數(shù)據(jù)），然后將這些數(shù)據(jù)傳入另一個(gè)運(yùn)算符。在此圖片中，流數(shù)據(jù)被傳送至Split運(yùn)算符，而后又將數(shù)據(jù)傳入文件接收器或數(shù)據(jù)庫(kù)（具體情況視Split運(yùn)算符的內(nèi)部狀況而定）。

利用ApacheHadoop等開(kāi)源項(xiàng)目，通過(guò)傳感器、RFID、社交媒體、呼叫中心記錄和其他來(lái)源提供的新型數(shù)據(jù)創(chuàng)造價(jià)值。

Streams

即，IBMInfoSphereStreams。在IBMInfoSphereStreams（簡(jiǎn)稱Streams）中，數(shù)據(jù)將會(huì)流過(guò)有能力操控?cái)?shù)據(jù)流（每秒鐘可能包含數(shù)百萬(wàn)個(gè)事件）的運(yùn)算符，然后對(duì)這些數(shù)據(jù)執(zhí)行動(dòng)態(tài)分析。這項(xiàng)分析可觸發(fā)大量事件，使企業(yè)利用即時(shí)的智能實(shí)時(shí)采取行動(dòng)，最終改善業(yè)務(wù)成果。

當(dāng)數(shù)據(jù)流過(guò)這些分析組件后，Streams將提供運(yùn)算符將數(shù)據(jù)存儲(chǔ)至各個(gè)位置，或者如果經(jīng)過(guò)動(dòng)態(tài)分析某些數(shù)據(jù)被視為毫無(wú)價(jià)值，則會(huì)丟棄這些數(shù)據(jù)。你可能會(huì)認(rèn)為Streams與復(fù)雜事件處理（CEP）系統(tǒng)非相似，不過(guò)Streams的設(shè)計(jì)可擴(kuò)展性更高，并且支持的數(shù)據(jù)流量也比其他系統(tǒng)多得多。此外，Streams還具備更高的企業(yè)級(jí)特性，包括高可用性、豐富的應(yīng)用程序開(kāi)發(fā)工具包和高級(jí)調(diào)度。

出于這樣的目的，許多組織開(kāi)始啟動(dòng)自己的大數(shù)據(jù)治理計(jì)劃。所謂大數(shù)據(jù)治理，指的是制定策略來(lái)協(xié)調(diào)多個(gè)職能部門的目標(biāo)，從而優(yōu)化、保護(hù)和利用大數(shù)據(jù)，將其作為一項(xiàng)企業(yè)資產(chǎn)。