傳統數倉如何轉型大資料

WindyQin發表於2020-11-25

大家好,我是一哥,前幾天建了一個資料倉儲方向的小群,收集了大家的一些問題,其中有個問題,一哥很想去談一談——現在做傳統數倉,如何快速轉到大資料資料呢?其實一哥知道的很多同事都是從傳統資料倉儲轉到大資料的,今天就結合身邊的同事經歷來一起分享一下。

一、資料倉儲

資料倉儲:資料倉儲系統的主要應用主要是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落地分析的。

最後,推薦兩本書吧,幫助你快速轉型成功——《阿里大資料之路》、《大資料日知錄》

相關文章