大資料時代，資料倉儲究竟是幹嘛的？

JAVA旭陽發表於2022-12-12
大資料

前言

無論你是否專門從事大資料開發，作為一個開發人員，應該都聽說過資料倉儲的概念，那你知道為什麼會出現資料倉儲？資料倉儲究竟是幹嘛的嗎？有什麼價值和意義呢？那麼本文就帶到入門，揭開資料倉儲的面紗。

資料倉儲的由來

資料倉儲為何而來，主要解決什麼問題的？

先下結論：為了分析資料而來，分析結果為企業決策提供支撐。舉個簡單的例子，比如你們公司要要判斷明年是否要進入生產口罩，那麼就需要資料支撐，比如口罩市場的需求、飽和率、利潤等等，然後藉由分析結果，去做判斷決策，而不是拍腦袋，不然大機率就是虧本的。

下面再以一箇中國人壽保險公司發展為例，詳細闡述資料倉儲為何而來？

（1）OLTP系統處理業務資料

中國人壽保險（集團）公司下轄多條業務線，包括：人壽險、財險、車險，養老險等。各業務線的業務正常運營需要記錄維護包括客戶、保單、收付費、核保、理賠等資訊。這麼多業務資料儲存在哪裡呢？

這些通用的業務行為一般是發在聯機事務處理系統（OLTP）, 其主要任務是執行聯機事務處理，前臺接收的使用者資料可以立即傳送到後臺進行處理，並在很短的時間內給出處理結果。

通常來說，這些業務資料最終都是落在關係型資料庫中的，關係型資料庫（RDBMS）是OLTP典型應用，比如：Oracle、MySQL、SQL Server等

這只是最基礎的業務，但是隨著業務規模的不斷髮展，衍生出了更多的資料分析型需求，用OLTP可行嗎？

（2）分析型決策需求衍生

隨著集團業務的持續運營，業務資料將會越來越多。由此也產生出許多運營相關的需求問題：

  • 能夠確定哪些險種正在惡化或已成為不良險種？
  • 能夠用有效的方式制定新增和續保的政策嗎？
  • 理賠過程有欺詐的可能嗎？
  • 現在得到的報表是否只是某條業務線的？集團整體層面資料如何？

......

為了能夠正確認識這些問題，制定相關的解決措施，瞎拍桌子是肯定不行的。最穩妥辦法就是：基於業務資料開展資料分析，基於分析的結果給決策提供支撐。也就是所謂的資料驅動決策的制定。

OLTP環境開展分析可行嗎？

可以，但是沒必要。OLTP系統的核心是面向業務，支援業務，支援事務。所有的業務操作可以分為讀、寫兩種操作，一般來說讀的壓力明顯大於寫的壓力。如果在OLTP環境直接開展各種分析，有以下問題需要考慮：

  • 資料分析也是對資料進行讀取操作，會讓讀取壓力倍增；
  • OLTP僅儲存數週或數月的資料；
  • 資料分散在不同系統不同表中，欄位型別屬性不統一；

（3）資料倉儲面世

當分析所涉及資料規模較小的時候，在業務低峰期時可以在OLTP系統上開展直接分析。但為了更好的進行各種規模的資料分析，同時也不影響OLTP系統執行，此時需要構建一個整合統一的資料分析平臺。該平臺的目的很簡單：面向分析，支援分析，並且和OLTP系統解耦合。基於這種需求，資料倉儲的雛形開始在企業中出現了。

資料倉儲是一個用於儲存、分析、報告的資料系統，目的是構建面向分析的整合化資料環境。我們把這種面向分析、支援分析的系統稱之為OLAP（聯機分析處理）系統。當然，資料倉儲是OLAP系統的一種實現。

  • 中國人壽保險公司就可以基於分析決策需求，構建數倉平臺。

資料倉儲介紹

資料倉儲（英語：Data Warehouse，簡稱數倉、DW）,是一個用於儲存、分析、報告的資料系統，主要目的是構建面向分析的整合化資料環境，分析結果為企業提供決策支援（Decision Support）。

  • 資料倉儲本身並不“生產”任何資料，其資料來源於不同外部系統；
  • 同時資料倉儲自身也不需要“消費”任何的資料，其結果開放給各個外部應用使用；
  • 這也是為什麼叫“倉庫”，而不叫“工廠”的原因。

數倉四大特徵

那麼資料倉儲都有什麼特點呢？

  1. 面向主題性（Subject-Oriented）
  • 主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析物件。
  • 傳統OLTP系統對資料的劃分並不適用於決策分析。而基於主題組織的資料則不同，它們被劃分為各自獨立的領域，每個領域有各自的邏輯內涵但互不交叉，在抽象層次上對資料進行完整、一致和準確的描述。

  1. 整合性

主題相關的資料通常會分佈在多個操作型系統中，彼此分散、獨立、異構。

  • 因此在資料進入資料倉儲之前，必然要經過統一與綜合，對資料進行抽取、清理、轉換和彙總，這一步是資料倉儲建設中最關鍵、最複雜的一步，所要完成的工作有：
    • 要統一源資料中所有矛盾之處。如欄位的同名異義、異名同義、單位不統一、字長不一致等等。
    • 進行資料綜合和計算。資料倉儲中的資料綜合工作可以在從原有資料庫抽取資料時生成，但許多是在資料倉儲內部生成的，即進入資料倉儲以後進行綜合生成的。

下圖說明了保險公司綜合資料的簡單處理過程，其中資料倉儲中與“承保”主題有關的資料來自於多個不同的操作型系統。

  1. 非易失性、非異變性
  • 資料倉儲是分析資料的平臺，而不是創造資料的平臺。我們是透過數倉去分析資料中的規律，而不是去創造修改其中的規律。因此資料進入資料倉儲後，它便穩定且不會改變。
  • 資料倉儲的資料反映的是一段相當長的時間內歷史資料的內容，資料倉儲的使用者對資料的操作大多是資料查詢或比較複雜的挖掘，一旦資料進入資料倉儲以後，一般情況下被較長時間保留。
  • 資料倉儲中一般有大量的查詢操作，但修改和刪除操作很少。
  1. 時變性
  • 資料倉儲包含各種粒度的歷史資料，資料可能與某個特定日期、星期、月份、季度或者年份有關。
  • 當業務變化後會失去時效性。因此資料倉儲的資料需要隨著時間更新，以適應決策的需要。
  • 從這個角度講，資料倉儲建設是一個專案，更是一個過程 。

資料倉儲架構

通常情況下，為了把一個複雜的工作拆成了多個簡單的工作，一般將資料倉儲架構分為三層，即資料操作層、資料倉儲層和應用資料層（資料集市層）。

  1. ODS（Operation Data Store 資料準備區）

資料倉儲源頭系統的資料表通常會原封不動的儲存一份，這稱為ODS層，也稱為準備區。它們是後續資料倉儲層加工資料的來源。ODS層資料的主要來源是業務資料庫、埋點日誌、其他資料來源。

  • 業務資料庫：可使用DataX、Sqoop等工具來抽取，每天定時抽取一次；在實時應用中，可用Canal監聽MySQL的 Binlog，實時接入變更的資料。
  • 埋點日誌：線上系統會打入各種日誌，這些日誌一般以檔案的形式儲存，可以用 Flume 定時抽取。
  • 其他資料來源：從第三方購買的資料、或是網路爬蟲抓取的資料。
  1. DW（Data Warehouse 資料倉儲層）

該層包含DWD、DWS、DIM層，由ODS層資料加工而成，主要是完成資料加工與整合，建立一致性的維度，構建可複用的面向分析和統計的明細事實表，以及彙總公共粒度的指標。

  • DWD（Data Warehouse Detail 細節資料層），是業務層與資料倉儲的隔離層。以業務過程作為建模驅動，基於每個具體的業務過程特點，構建細粒度的明細層事實表。可以結合企業的資料使用特點，將明細事實表的某些重要維度屬性欄位做適當冗餘，也即寬表化處理。
  • DWS（Data Warehouse Service 服務資料層），基於DWD的基礎資料，整合彙總成分析某一個主題域的服務資料。以分析的主題為建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表。
  • DIM（公共維度層 ），基於維度建模理念思想，建立一致性維度。
  • TMP層 ：臨時層，存放計算過程中臨時產生的資料。
  1. ADS（Application Data Store 應用資料層）

該層是基於DW層的資料，整合彙總成主題域的服務資料，用於提供後續的業務查詢等。

資料倉儲開發語言

數倉作為面向分析的資料平臺，其主職工作就是對儲存在其中的資料開展分析，那麼如何讀取資料分析呢？

理論上來說，任何一款程式語言只要具備讀寫資料、處理資料的能力，都可以用於數倉的開發。比如大家耳熟能詳的C、java、Python等。但是這些程式設計一員的學習成本和開發效率都不是十分友好，在資料分析領域中，SQL語言功能很強，十分簡潔，使用者也容易學習和使用，是主流的語言。比如比較常用的資料倉儲工具Hive就是支援SQL的語法。

總結

本文透過例子講清楚了資料倉儲的來源，以及在企業應用中的必要性，主要是為了構建一個面向分析的整合化資料環境，分析結果可以為企業提供決策支援，真正實現資料驅動決策的目的。實際上資料倉儲的建設遠比上面提到的複雜，需要花費很大的成本，因此需要考慮清楚。

如果本文對你有幫助的話，請留下一個贊吧
歡迎關注個人公眾號——JAVA旭陽
更多學習資料請移步：程式設計師成神之路

相關文章