7種最常見的Hadoop和Spark專案

2021-07-09 22:38:21 字數 2301 閱讀 2694

如果您的hadoop專案將有新的突破,那麼它必定與下邊介紹的七種常見專案很相像。

有一句古老的格言是這樣說的,如果你向某人提供你的全部支援和金融支援去做一些不同的和創新的事情,他們最終卻會做別人正在做的事情。如比較火爆的hadoop、spark和storm,每個人都認為他們正在做一些與這些新的大資料技術相關的事情,但它不需要很長的時間遇到相同的模式。具體的實施可能有所不同,但根據我的經驗,它們是最常見的七種專案。

專案一:資料整合

稱之為「企業級資料中心」或「資料湖」,這個想法是你有不同的資料來源,你想對它們進行資料分析。這類專案包括從所有**獲得資料來源(實時或批處理)並且把它們儲存在hadoop中。有時,這是成為乙個「資料驅動的公司」的第一步;有時,或許你僅僅需要乙份漂亮的報告。「企業級資料中心」通常由hdfs檔案系統和hive或impala中的表組成。未來,hbase和phoenix在大資料整合方面將大展拳腳,開啟乙個新的局面,建立出全新的資料美麗新世界。

銷售人員喜歡說「讀模式」,但事實上,要取得成功,你必須清楚的了解自己的用例將是什麼(hive模式不會看起來與你在企業資料倉儲中所做的不一樣)。真實的原因是乙個資料湖比teradata和netezza公司有更強的水平擴充套件性和低得多的成本。許多人在做前端分析時使用tabelu和excel。許多複雜的公司以「資料科學家」用zeppelin或ipython筆記本作為前端。

專案二:專業分析

許多資料整合專案實際上是從你特殊的需求和某一資料集系統的分析開始的。這些往往是令人難以置信的特定領域,如在銀行領域的流動性風險/蒙特卡羅模擬分析。在過去,這種專業的分析依賴於過時的,專有的軟體包,無法擴大資料的規模經常遭受乙個有限的功能集(大部分是因為軟體廠商不可能像專業機構那樣了解的那麼多)。

在hadoop和spark的世界,看看這些系統大致相同的資料整合系統,但往往有更多的hbase,定製非sql**,和更少的資料**(如果不是唯一的)。他們越來越多地以spark為基礎。

專案三:hadoop作為一種服務

在「專業分析」專案的任何大型組織(諷刺的是,乙個或兩個「資料整理」專案)他們會不可避免地開始感覺「快樂」(即,疼痛)管理幾個不同配置的hadoop集群,有時從不同的**商。接下來,他們會說,「也許我們應該整合這些資源池,」而不是大部分時間讓大部分節點處於資源閒置狀態。它們應該組成雲計算,但許多公司經常會因為安全的原因(內部政治和工作保護)不能或不會。這通常意味著很多docker容器包。

我沒有使用它,但最近bluedata(藍色資料國際中心)似乎有乙個解決方案,這也會吸引小企業缺乏足夠的資金來部署hadoop作為一種服務。

專案四:流分析

很多人會把這個「流」,但流分析是不同的,從裝置流。通常,流分析是乙個組織在批處理中的實時版本。以反洗錢和欺詐檢測:為什麼不在交易的基礎上,抓住它發生而不是在乙個週期結束?同樣的庫存管理或其他任何。

在某些情況下,這是一種新的型別的交易系統,分析資料位的位,因為你將它併聯到乙個分析系統中。這些系統證明自己如spark或storm與hbase作為常用的資料儲存。請注意,流分析並不能取代所有形式的分析,對某些你從未考慮過的事情而言,你仍然希望分析歷史趨勢或看過去的資料。

專案五:複雜事件處理

在這裡,我們談論的是亞秒級的實時事件處理。雖然還沒有足夠快的超低延遲(皮秒或納秒)的應用,如高階的交易系統,你可以期待毫秒響應時間。例子包括對事物或事件的網際網路電信運營商處理的呼叫資料記錄的實**價。有時,你會看到這樣的系統使用spark和hbase——但他們一般落在他們的臉上,必須轉換成storm,這是基於由lmax交易所開發的干擾模式。

在過去,這樣的系統已經基於定製的訊息或高效能,從貨架上,客戶端-伺服器訊息產品-但今天的資料量太多了。我還沒有使用它,但apex專案看起來很有前途,聲稱要比storm快。

專案六:etl流

有時你想捕捉流資料並把它們儲存起來。這些專案通常與1號或2號重合,但增加了各自的範圍和特點。(有些人認為他們是4號或5號,但他們實際上是在向磁碟傾倒和分析資料。),這些幾乎都是kafka和storm專案。spark也使用,但沒有理由,因為你不需要在記憶體分析。

專案七:更換或增加sas

sas是精細,是好的但sas也很貴,我們不需要為你的資料科學家和分析師買儲存你就可以「玩」資料。此外,除sas可以做或產生漂亮的圖形分析外,你還可以做一些不同的事情。這是你的「資料湖」。這裡是ipython筆記本(現在)和zeppelin(以後)。我們用sas儲存結果。

當我每天看到其他不同型別的hadoop,spark,或storm專案,這些都是正常的。如果你使用hadoop,你可能了解它們。幾年前我已經實施了這些專案中的部分案例,使用的是其它技術。

如果你是乙個老前輩太害怕「大」或「做」大資料hadoop,不要擔心。事情越變越多,但本質保持不變。你會發現很多相似之處的東西你用來部署和時髦的技術都是圍繞hadooposphere旋轉的。

7種最常見的Hadoop和Spark專案

如果您的hadoop專案將有新的突破,那麼它必定與下邊介紹的七種常見專案很相像。有一句古老的格言是這樣說的,如果你向某人提供你的全部支援和金融支援去做一些不同的和創新的事情,他們最終卻會做別人正在做的事情。如比較火爆的hadoop spark和storm,每個人都認為他們正在做一些與這些新的 大資料...

7種最常見的Hadoop和Spark專案

如果您的hadoop專案將有新的突破,那麼它必定與下邊介紹的七種常見專案很相像。有一句古老的格言是這樣說的,如果你向某人提供你的全部支援和金融支援去做一些不同的和創新的事情,他們最終卻會做別人正在做的事情。如比較火爆的hadoop spark和storm,每個人都認為他們正在做一些與這些新的大資料技...

最常見的7種物件導向設計原則

設計原則名稱 定義 使用頻率 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責 開閉原則 open closed principle,ocp 軟體實體應對擴充套件開放,而對修改關閉 黎克特制代換原則 liskov substi...