前幾天建了一個資料倉儲方向的小群，收集了大家的一些問題，其中有個問題，一哥很想去談一談——現在做傳統數倉，如何快速轉到大資料資料呢？其實一哥知道的很多同事都是從傳統資料倉儲轉到大資料的，今天就結合身邊的同事經歷來一起分享一下。
資料倉儲
資料倉儲：資料倉儲系統的主要應用主要是OLAP（On-Line Analytical Processing），支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。也就是說，資料倉儲彙總有可能有很多維度資料的統計分析結果，取百家之長（各個資料來源的資料），成就自己的一方天地（規劃各種業務域的模型，指標）。可以參考之前的文章《資料倉儲的前世今生》
傳統資料倉儲開發
傳統的資料倉儲用Oracle的居多，多半是單機或者一個雙機環境執行。本身硬體，系統都容易形成單點故障。慢慢發展，應該會開始通過儲存形成容災的一個環境。
我瞭解的傳統的資料開發一般分為3個崗位：資料工程師、ETL工程師、資料倉儲架構師，大多數人屬於前兩者。
資料工程師：根據業務人員提交的邏輯來編寫“儲存過程”，他們能夠很輕鬆的編寫上千行的複雜邏輯SQL。在編寫SQL多年經驗中，掌握了各種關聯查詢、聚合查詢、視窗函式，甚至還可以用SQL自己編寫一些Function，最終組合成了儲存過程。
ETL工程師：傳統資料倉儲只有在大型企業中一般才會有，比如電信、銀行、保險等行業。他們都會採購一些ETL工具，比如Informatica或者和第三方共建ETL工具，比如和華為、亞信等。這些ETL工具功能非常強大。ETL工程師可以通過在平臺上拖拉拽的形式進行資料加工處理，同時ETL平臺的元件還可以支撐一些指令碼的上傳，所以ETL工程師結合資料工程師開發的複雜儲存過程，在平臺上進行加工設計，最終形成一個個定時任務。然後他們還負責每天監控這些定時任務的狀態，對於重要部門的ETL人員還經常會熬夜值班監控。
資料倉儲架構師：資料倉儲是依靠規範來有序進行的，架構師就是來建立這些規範的，包括資料倉儲的分層、模型命名、指標命名、ETL任務命名、ETL任務編排規範、儲存過程開發規範等等，最終形成《XX資料倉儲建設規範》，然後資料工程師和ETL工程師按照規範進行任務開發。如果遇到重大業務變更，比如主資料變更，需要和資料倉儲架構師評審後修改完善。
大資料開發
現在的大資料架構多了一些東西，比如資料採集Flume、訊息對壘kafka、計算引擎MR、Spark以及實時計算框架，這些都是以前傳統資料倉儲架構下沒有的。
Flume
Flume是一種分散式、高可靠和高可用的服務，用於高效地收集、聚合和移動大量日誌資料。它有一個簡單而靈活的基於流資料流的體系結構。它具有可調的可靠性機制、故障轉移和恢復機制，具有強大的容錯能力。它使用一個簡單的可擴充套件資料模型，允許線上分析應用程式。Flume的設計宗旨是向Hadoop叢集批量匯入基於事件的海量資料。系統中最核心的角色是agent，Flume採集系統就是由一個個agent所連線起來形成。每一個agent相當於一個資料傳遞員，內部有三個元件：
source: 採集源，用於跟資料來源對接，以獲取資料
sink：傳送資料的目的地，用於往下一級agent或者最終儲存系統傳遞資料
channel：agent內部的資料傳輸通道，用於從source傳輸資料到sink
詳細配置參考：《日誌收集元件—Flume、Logstash、Filebeat對比》
kafka
Kafka是最初由Linkedin公司開發，是一個分散式、分割槽的、多副本的、多訂閱者，基於zookeeper協調的分散式日誌系統（也可以當做MQ系統），常見可以用於web/nginx日誌、訪問日誌，訊息服務等等，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源專案。
主要應用場景是：日誌收集系統和訊息系統。
Kafka主要設計目標如下：
-
提供訊息持久化能力，即使對TB級以上資料也能保證常數時間的訪問效能。
-
高吞吐率。即使在非常廉價的商用機器上也能做到單機支援每秒100K條訊息的傳輸。
-
支援Kafka Server間的訊息分割槽，及分散式消費，同時保證每個partition內的訊息順序傳輸。
-
同時支援離線資料處理和實時資料處理。
-
Scale out:支援線上水平擴充套件
大資料計算引擎
近幾年出現了很多熱門的開源社群，其中著名的有 Hadoop、Storm，以及後來的Spark、Flink，他們都有著各自專注的應用場景。Spark掀開了記憶體計算的先河，也以記憶體為賭注，贏得了記憶體計算的飛速發展。Spark的火熱或多或少的掩蓋了其他分散式計算的系統身影。不過目前Flink在阿里的力推之下，也逐漸佔領著實時處理的市場。其實大資料的計算引擎分成了三代：
-
第一代計算引擎
無疑就是Hadoop承載的 MapReduce。這裡大家應該都不會對MapReduce陌生，它將計算分為兩個階段，分別為 Map 和 Reduce。對於上層應用來說，就不得不想方設法去拆分演算法，甚至於不得不在上層應用實現多個 Job 的串聯，以完成一個完整的演算法，例如迭代計算。MR每次計算都會和HDFS互動，和磁碟互動意味著產生更多的IO，也就會更慢。由於這樣的弊端，催生了支援 DAG 框架和基於記憶體計算的產生。
-
第二代計算引擎
Spark的特點主要是 Job 內部的 DAG 支援（不跨越 Job），同時支援基於記憶體的計算。這樣的話每次計算到中間步報錯了，就不會再從頭開始計算一遍，而是接著上一個成功的狀態，同時中間計算結果資料也可以放在記憶體中，大大提高了計算速度。另外，Spark還支援了實時計算，滿足了大家維護一套叢集，既可以搞離線計算也可以搞實時計算。
-
第三代計算引擎
促進了上層應用快速發展，例如各種迭代計算的效能以及對流計算和 SQL 等的支援。Flink開始嶄露頭角。這應該主要表現在 Flink 對流計算的支援，以及更一步的實時性上面。當然 Flink 也可以支援 Batch 的任務，以及 DAG 的運算。
轉型
有了傳統資料倉儲轉型大資料是一個好的開端，但是路並不會那麼順利，也許並沒有你想想的那麼快速。
從身邊的同事來看，大家都是經歷了很多專案經驗之後，才真正轉型成功的。
首先，作為傳統的資料倉儲工程師，你已經對SQL掌握的非常熟練，這是你的優勢。可以看到，現在所有的大資料計算引擎都在支援著SQL，從最早的Hive到現在的Flink。他們大多和標準SQL語法近似，很快能夠快速掌握，現在很多離線資料倉儲還是建立在Hive之上，從這一點上，你能很快開發HiveSQL指令碼。你可以把之前資料倉儲架構的那一套方法論拿過啦借鑑，資料倉儲這東西建了幾十年，還是最初的那幾套方法，足夠了。只是你會遇到很大的資料量問題，要根據實際情況進行合理的分層，合理的使用臨時表。但是，既然你選擇了轉型，相信你並不只是滿足換個環境寫SQL吧。所以你要學習Hadoop、學習Spark，身邊曾有一個同事從傳統數倉轉大資料後，就是換個環境寫SQL，寫了兩年了還不知道HDFS常用命令，不知道Spark的計算原理，每次SQL調優的時候，都去問平臺開發的同事，怎麼修改引數。所以趁著你還在轉型的興頭上，學一下這方面的知識。如果之前沒有java開發經驗，那不建議你學習MR，直接上手Spark吧，python也很好用的，使用pyspark能夠解決很多SQL解決不了的問題。
另外，學一學kafka吧，離線數倉搞完了，不想搞實時數倉嗎？現在物聯網行業，每天有幾億資料上傳到平臺，每條訊息有幾千個欄位，我們無法選擇傳統的資料庫進行儲存。閘道器直接轉發資料到kafka，然後儲存到HDFS和HBase。其他行業也一樣，電商。搜尋，每天那麼多人訪問，訪問資料也都是訊息快取的方式傳送到HDFS落地分析的。
最後，推薦兩本書吧，幫助你快速轉型成功——《阿里大資料之路》、《大資料日知錄》。