大資料架構師必讀:常見的七種Hadoop和Spark專案案例
如果您的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旋轉的。
要了解學習大資料的可以加群,群號: 834325294,群裡有免費的學習資料和視訊。
相關文章
- 常見的七種Hadoop和Spark專案案例HadoopSpark
- 好程式設計師大資料培訓分享常見的Hadoop和Spark專案程式設計師大資料HadoopSpark
- 如何掌握Spark和Hadoop的架構SparkHadoop架構
- Q:Spark和Hadoop的架構區別SparkHadoop架構
- [大資料] Spark架構詳解大資料Spark架構
- 常見的五種軟體架構架構
- hadoop:spark-project專案的hadoop配置HadoopSparkProject
- 大資料架構師大資料架構
- 幾種常見的Python資料結構Python資料結構
- 好程式設計師大資料培訓之Hadoop常見問題程式設計師大資料Hadoop
- 10種常見的軟體架構模式架構模式
- 好程式設計師大資料培訓簡述Hadoop常見問題程式設計師大資料Hadoop
- 阿里大資料架構師必備技能,你“佩奇”了嘛?阿里大資料架構
- 好程式設計師分享大資料入門教程:Hadoop和spark的效能比較程式設計師大資料HadoopSpark
- 【架構師成長必備】如何閱讀一個開源專案的原始碼?【石杉的架構筆記】架構原始碼筆記
- 大資料入門課程:Hadoop和spark的效能比較大資料HadoopSpark
- 大資料開發常見的9種資料分析手段大資料
- 前端架構師必備之Vue專案打包優化前端架構Vue優化
- 常見諮詢公司專案管理的七大挑戰有哪些?專案管理
- 大資料框架對比 - Hadoop、Spark、Storm、Samza、Spark、Flink大資料框架HadoopSparkORM
- 常用的幾種大資料架構剖析大資料架構
- MPP與Hadoop,兩種主流大資料系統架構有啥區別?Hadoop大資料架構
- 軟體架構師或解決方案架構師必讀的五本書 - javarevisited架構Java
- 大資料開發:剖析Hadoop和Spark的Shuffle過程差異大資料HadoopSpark
- 架構師必備:Redis的幾種叢集方案架構Redis
- 大資料平臺基礎架構hadoop安全分析大資料架構Hadoop
- java和大資料架構師,各需要什麼技能?Java大資料架構
- 年薪60萬大資料架構師教你Hadoop如何安裝!還不快來看!大資料架構Hadoop
- 七牛網CEO的架構師7種能力和學習線路圖架構
- Apache Spark常見的三大誤解ApacheSpark
- 專案管理中四種常見的階段專案管理
- 大資料開發之常見九種資料分析方法大資料
- Hazelcast IMDG和Spark 2實現大資料專案 — tomask79ASTSpark大資料
- 《大話資料結構》讀後總結(七)資料結構
- react建立專案&&常見的三大HookReactHook
- 資料整合的兩種架構:ELT和ETL架構
- 九種常見的資料分析模型模型
- React專案架構,掌握前端架構師的核心本領React架構前端