很多公司在大資料部門有這樣明確的崗位劃分，資料倉庫主要是負責公司統一的資料儲存，包括業務資料，日誌資料，作為公司統一的資料倉庫，需要到各業務部門深入瞭解業務和其原始的業務資料意義，然後做資料同步，etl，對資料建立事實維度表，為各業務部門提供基於主題的分析支援。這個崗位大約有超過一半以上的時間是在瞭解各業務部門的業務內容，剩下的就是對資料做清洗，轉換，建模。

流資料處理的話更多是針對業務需求去完成業務功能或輔助業務功能，比如，我用spark streaming等完成公司網站流量或其他監控功能，storm作為一個技術參與完成實時推薦，兩種崗位沒有優劣，看您的興趣在哪。

從就業前景的角度來講，大資料資料倉庫方向要比大資料流式處理方向更好。大資料流式處理，本質就是實時流式資料處理，既對資料進行實時加工和輸出。數倉研發同學平時在進行資料處理時，會用到大資料流式處理技術。整體來說，大資料資料倉庫包含大資料流式處理，從而大資料資料倉庫的就業選擇方向要比大資料流式處理更廣。

我之前崗位就是資料研發，本質就是結合資料倉庫模型，對業務資料進行標準化處理和資料模型構建。業務資料最開始來源線上業務使用者的行為資料，透過資料採集，儲存到分散式檔案系統上，然後使用Hive對資料進行加工。資料研發，整體可以分為離線資料研發和實時流式資料研發，這兩個方向其實都需要使用到大資料資料倉庫理論對資料建模。

我在進行實時資料研發的時候，主要使用到Flink技術來對流式資料進行處理。其實處理的同時，整體的設計思想就是參考資料倉庫設計理論。對流式資料，怎麼樣處理，才能構建出公共層流式資料，增強資料的可用性，減少資源重複計算，計算出的實時指標，能否做到指標口徑統一，如果構建流式資料應用層等。流式資料處理也要參考資料倉庫理論來進行設計。

所以，只要你學好大資料資料倉庫的理論，無論你是大資料流式處理，還是離線資料處理，你都能夠做到得心應手，你可以從事這兩個資料研發方向的工作。如果是大資料流式處理，你就只能選擇實時計算相關的崗位。大資料資料倉庫方向要比大資料流式處理的崗位選擇更廣。

你如果對大資料流式處理非常感興趣的話，個人建議你可以先對資料倉庫資料模型理論進行學習，ODS層(原始資料層)、DWD層(公共資料明細層)、DWS（公共彙總層）、ADM層(資料應用層)，你要清楚資料處理為什麼要這麼分層。怎麼設計資料維表、什麼是星形模型、雪花模型，這些概念你都要理解清楚。

學習完資料倉庫理論再去學習流式處理，會讓你以後對於流式資料處理更加的專業，同時會讓你的資料任務更加規範和通用。從事大資料研發，你一定要學會資料倉庫理論。

大資料的定義

為什麼Oracle Cloud適用於大資料？

面向大資料的Oracle雲平臺透過快速無縫地將新見解整合到所有部門的生產的各個方面，以所有可以理解的語言向所有員工提供，從而釋放資料的價值。

究竟什麼是大資料？

要真正瞭解大資料，有一些歷史背景是有幫助的。這是Gartner的定義，大約在2001年（這仍然是定義）：大資料是包含更多種類的資料，其數量越來越大，速度也越來越高。這被稱為三個Vs.

簡而言之，大資料是更大，更復雜的資料集，尤其是來自新資料來源。這些資料集非常龐大，以至於傳統的資料處理軟體無法管理它們。但是，這些海量資料可用於解決您以前無法解決的業務問題。

三大資料的大資料 1卷 2速度 3品種

解釋一下：

品種是指可用的許多型別的資料。傳統資料型別的結構和整齊地適合關係資料庫。隨著大資料的興起，資料出現在新的非結構化資料型別中。非結構化和半結構化資料型別（如文字，音訊和影片）需要額外的預處理才能獲得含義和支援元資料。

在過去幾年中又出現了兩個V：價值和準確性。

資料具有內在價值。但是在發現這個價值之前沒有用。同樣重要的是：您的資料是多麼真實 - 您可以依賴它多少？

今天，大資料已成為資本。想想世界上一些最大的科技公司。他們提供的大部分價值來自他們的資料，他們不斷分析這些資料以提高效率並開發新產品。

最近的技術突破以指數方式降低了資料儲存和計算的成本，使得儲存更多資料比以往更容易，成本更低。隨著大資料量的增加，現在更便宜，更易於訪問，您可以做出更準確，更準確的業務決策。

在大資料中尋找價值不僅僅是分析它（這是一個完整的其他好處）。這是一個完整的發現過程，需要富有洞察力的分析師，業務使用者和高管，他們會提出正確的問題，識別模式，做出明智的假設並預測行為。但是我們怎麼到這兒了？

大資料和資料分析的好處：

大資料使您可以獲得更完整的答案，因為您有更多資訊。

更完整的答案意味著對資料更有信心 - 這意味著解決問題的方法完全不同。

所以，您問的問題，我個人認為在大資料的時代，任何有關資料，都是複雜並且精密的，這有關於您或者您所在的公司，是否能快人一步，每個細節都是重要的！有關於這個時代來臨，我們是幸運的！

就目前來說，做大資料的資料倉庫，必然是要面對流式處理的。

資料倉庫的存在最主要是業務部門在資料上提供決策依據，同時資料反饋的響應時間也必然是越快越好（當然是保證質量的前提下越快越好）。怎麼才能及時反饋資料呢？首先想到的就是使用flink這種流式資料處理框架。

流式處理只是作為資料倉庫的一種資料處理方式，他們並不是同級別的，正確的來說應該是包含關係——資料倉庫的處理方式包含流式處理，另一種是離線處理。

就目前的行業現狀來說，離線處理的應用更廣泛，從功能性和穩定性上來說，流式處理框架（典型的如flink）的發展還不及離線處理框架（如hive和spark）。但是流式處理一定也是未來資料倉庫的一個發展方向，目前很多企業都準備或者已經開始建立實時數倉了。

作為學習來說，可以先從離線處理開始入手，離線處理掌握了，其實流式處理也就差不多了。