1、資料倉儲的概念
資料倉儲（英語：Data Warehouse，簡稱數倉、DW）,是一個用於儲存、分析、報告的資料系統。資料倉儲的目的是構建面向分析的整合化資料環境，為企業提供決策支援（Decision Support）。
資料倉儲本身並不“生產”任何資料，其資料來源於不同外部系統；同時資料倉儲自身也不需要“消費”任何的資料，其結果開放給各個外部應用使用，這也是為什麼叫“倉庫”，而不叫“工廠”的原因。
2、場景案例：資料倉儲為何而來？
先下結論：為了分析資料而來，分析結果給企業決策提供支撐。
資訊總是用作兩個目的：操作型記錄的儲存和分析型決策的制定。資料倉儲是資訊科技長期發展的產物。
下面以中國人壽保險公司（chinalife）發展為例，闡述資料倉儲為何而來？
2、1操作型記錄的儲存
中國人壽保險（集團）公司下轄多條業務線，包括：人壽險、財險、車險，養老險等。各業務線的業務正常運營需要記錄維護包括客戶、保單、收付費、核保、理賠等資訊。
聯機事務處理系統（OLTP）正好可以滿足上述業務需求開展, 其主要任務是執行聯機事務和查詢處理。其基本特徵是前臺接收的使用者資料可以立即傳送到後臺進行處理，並在很短的時間內給出處理結果。關係型資料庫是OLTP典型應用，比如：Oracle、Mysql、SQL Server等。
2、2分析型決策的制定
隨著集團業務的持續運營，業務資料將會越來越多。由此也產生出許多運營相關的困惑：
能夠確定哪些險種正在惡化或已成為不良險種？
能夠用有效的方式制定新增和續保的政策嗎？
理賠過程有欺詐的可能嗎？
現在得到的報表是否只是某條業務線的？集團整體層面資料如何？
為了能夠正確認識這些問題，制定相關的解決措施，瞎拍桌子是肯定不行的。最穩妥辦法就是：基於業務資料開展資料分析，基於分析的結果給決策提供支撐。也就是所謂的資料驅動決策的制定。
然後，面臨下一個問題：在哪裡進行資料分析？資料庫可以嗎？
2、3 OLTP環境開展分析可行嗎？
結論：可以，但是沒必要。
OLTP的核心是面向業務，支援業務，支援事務。所有的業務操作可以分為讀、寫兩種操作，一般來說讀的壓力明顯大於寫的壓力。如果在OLTP環境直接開展各種分析，有以下問題需要考慮：
資料分析也是對資料進行讀取操作，會讓讀取壓力倍增；
OLTP僅儲存數週或數月的資料；
資料分散在不同系統不同表中，欄位型別屬性不統一；
當分析所涉及資料規模較小的時候，在業務低峰期時可以在OLTP系統上開展直接分析。但是為了更好的進行各種規模的資料分析，同時也不影響OLTP系統執行，此時需要構建一個整合統一的資料分析平臺。
該平臺的目的很簡單：面向分析，支援分析。並且和OLTP系統解耦合。
基於這種需求，資料倉儲的雛形開始在企業中出現了。
2、4 資料倉儲的構建
如數倉定義所說,數倉是一個用於儲存、分析、報告的資料系統，目的是構建面向分析的整合化資料環境。我們把這種面向分析、支援分析的系統稱之為OLAP（聯機分析處理）系統。資料倉儲是OLAP一種。
中國人壽保險公司就可以基於分析決策需求，構建數倉平臺。
3、資料倉儲的主要特徵
資料倉儲是面向主題性（Subject-Oriented ）、整合性（Integrated）、非易失性（Non-Volatile）和時變性（Time-Variant ）資料集合，用以支援管理決策 。
3、1 面向主題性
資料庫中，最大的特點是面向應用進行資料的組織，各個業務系統可能是相互分離的。而資料倉儲則是面向主題的。主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析物件。
操作型處理（傳統資料）對資料的劃分並不適用於決策分析。而基於主題組織的資料則不同，它們被劃分為各自獨立的領域，每個領域有各自的邏輯內涵但互不交叉，在抽象層次上對資料進行完整、一致和準確的描述。
3、2 整合性
確定主題之後，就需要獲取和主題相關的資料。當下企業中主題相關的資料通常會分佈在多個操作型系統中，彼此分散、獨立、異構。因此在資料進入資料倉儲之前，必然要經過統一與綜合，對資料進行抽取、清理、轉換和彙總，這一步是資料倉儲建設中最關鍵、最複雜的一步，所要完成的工作有：
（1）要統一源資料中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等。
（2）進行資料綜合和計算。資料倉儲中的資料綜合工作可以在從原有資料庫抽取資料時生成，但許多是在資料倉儲內部生成的，即進入資料倉儲以後進行綜合生成的。
下圖說明了保險公司綜合資料的簡單處理過程，其中資料倉儲中與“承保”主題有關的資料來自於多個不同的操作型系統。這些系統內部資料的命名可能不同，資料格式也可能不同。把不同來源的資料儲存到資料倉儲之前，需要去除這些不一致。
3、3 非易失性
資料倉儲是分析資料的平臺，而不是創造資料的平臺。我們是透過數倉去分析資料中的規律，而不是去創造修改其中的規律。因此資料進入資料倉儲後，它便穩定且不會改變。
操作型資料庫主要服務於日常的業務操作，使得資料庫需要不斷地對資料實時更新，以便迅速獲得當前最新資料，不至於影響正常的業務運作。在資料倉儲中只要儲存過去的業務資料，不需要每一筆業務都實時更新資料倉儲，而是根據商業需要每隔一段時間把一批較新的資料匯入資料倉儲。
資料倉儲的資料反映的是一段相當長的時間內歷史資料的內容，是不同時點的資料庫快照的集合，以及基於這些快照進行統計、綜合和重組的匯出資料。
資料倉儲的使用者對資料的操作大多是資料查詢或比較複雜的挖掘，一旦資料進入資料倉儲以後，一般情況下被較長時間保留。資料倉儲中一般有大量的查詢操作，但修改和刪除操作很少。
3、4 時變性
資料倉儲包含各種粒度的歷史資料，資料可能與某個特定日期、星期、月份、季度或者年份有關。
雖然資料倉儲的使用者不能修改資料，但並不是說資料倉儲的資料是永遠不變的。分析的結果只能反映過去的情況，當業務變化後，挖掘出的模式會失去時效性。因此資料倉儲的資料需要隨著時間更新，以適應決策的需要。從這個角度講，資料倉儲建設是一個專案，更是一個過程 。
資料倉儲的資料隨時間的變化表現在以下幾個方面。
（1）資料倉儲的資料時限一般要遠遠長於操作型資料的資料時限。
（2）操作型系統儲存的是當前資料，而資料倉儲中的資料是歷史資料。
（3）資料倉儲中的資料是按照時間順序追加的，它們都帶有時間屬性。
4、資料倉儲、資料庫、資料集市
4、1 OLTP、OLAP
操作型處理，叫聯機事務處理OLTP（On-Line Transaction Processing），主要目標是做資料處理，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。使用者較為關心操作的響應時間、資料的安全性、完整性和併發支援的使用者數等問題。傳統的關係型資料庫系統作為資料管理的主要手段，主要用於操作型處理。
分析型處理，叫聯機分析處理OLAP（On-Line Analytical Processing），主要目標是做資料分析。一般針對某些主題的歷史資料進行復雜的多維分析，支援管理決策。資料倉儲是OLAP系統的一個典型示例，主要用於資料分析
4、2 資料倉儲、資料庫
資料庫與資料倉儲的區別實際講的是OLTP與OLAP的區別。
OLTP系統的典型應用就是RDBMS,也就是我們俗稱的資料庫，當然這裡要特別強調此資料庫表示的是關係型資料庫，Nosql資料庫並不在討論範圍內。
OLAP系統的典型應用就是DW,也就是我們俗稱的資料倉儲。
因此資料倉儲和資料庫的區別就很好掌握了。但是有幾點需要著重強調：
資料倉儲不是大型的資料庫，雖然資料倉儲儲存資料規模大。
資料倉儲的出現，並不是要取代資料庫。
資料庫是面向事務的設計，資料倉儲是面向主題設計的。
資料庫一般儲存業務資料，資料倉儲儲存的一般是歷史資料。
資料庫是為捕獲資料而設計，資料倉儲是為分析資料而設計。
4、3 資料倉儲、資料集市
資料倉儲是面向整個集團組織的資料，資料集市是面向單個部門使用的。可以認為資料集市是資料倉儲的子集，也有人把資料集市叫做小型資料倉儲。資料集市通常只涉及一個主題領域，例如市場營銷或銷售。因為它們較小且更具體，所以它們通常更易於管理和維護，並具有更靈活的結構。
比如上圖所示：
各種操作型系統資料和包括檔案在內的等其他資料作為資料來源，經過ETL(抽取轉換載入)填充到資料倉儲中；
資料倉儲中有不同主題資料，資料集市則根據部門特點面向指定主題，比如Purchasing（採購）、Sales（銷售）、Inventory（庫存）；
使用者可以基於主題資料開展各種應用：資料分析、資料包表、資料探勘。
5、資料倉儲分層架構
5、1 數倉分層思想和標準
資料倉儲的特點是本身不生產資料，也不最終消費資料。按照資料流入流出數倉的過程進行分層就顯得水到渠成。
資料分層每個企業根據自己的業務需求可以分成不同的層次，但是最基礎的分層思想，理論上資料分為三個層，操作型資料層（ODS）、資料倉儲層(DW)和資料應用層(DA)。
企業在實際運用中可以基於這個基礎分層之上新增新的層次，來滿足不同的業務需求
5、2 阿里巴巴數倉三層架構
1、ODS層（Operation Data Store）
直譯：操作型資料層。也稱之為源資料層、資料引入層、資料暫存層、臨時快取層。此層存放未經過處理的原始資料至資料倉儲系統，結構上與源系統保持一致，是資料倉儲的資料準備區。主要完成基礎資料引入到數倉的職責，和資料來源系統進行解耦合，同時記錄基礎資料的歷史變化。
2、DW層（Data Warehouse）
資料倉儲層。內部具體包括DIM維度表、DWD和DWS，由ODS層資料加工而成。主要完成資料加工與整合，建立一致性的維度，構建可複用的面向分析和統計的明細事實表，以及彙總公共粒度的指標。
公共維度層（DIM）：基於維度建模理念思想，建立整個企業一致性維度。
公共彙總粒度事實層（DWS、DWB）：以分析的主題物件作為建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表，以寬表化手段物理化模型
明細粒度事實層（DWD）: 將明細事實表的某些重要維度屬性欄位做適當冗餘，即寬表化處理。
3、資料應用層（DA或ADS）
面向終端使用者，面向業務定製提供給產品和資料分析使用的資料。包括前端報表、分析圖表、KPI、儀表盤、OLAP專題、資料探勘等分析。
5、3 ETL 和 ELT
資料倉儲從各資料來源獲取資料及在資料倉儲內的資料轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程。但是在實際操作中將資料載入到倉庫卻產生了兩種不同做法：ETL和ELT。Extract，Transform，Load，ETL
首先從資料來源池中提取資料，這些資料來源通常是事務性資料庫。資料儲存在臨時暫存資料庫中。然後執行轉換操作，將資料結構化並轉換為適合目標資料倉儲系統的形式。然後將結構化資料載入到倉庫中，以備分析。
Extract，Load，Transform ，ELT
使用ELT，資料在從源資料池中提取後立即載入。沒有臨時資料庫，這意味著資料會立即載入到單一的集中儲存庫中。資料在資料倉儲系統中進行轉換，以便與商業智慧工具和分析一起使用。大資料時代的數倉這個特點很明顯。
5、4 為什麼要分層
分層的主要原因是在管理資料的時候，能對資料有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：
1、清晰資料結構
每一個資料分層都有它的作用域，在使用表的時候能更方便地定位和理解。
2、資料血緣追蹤
簡單來說，我們最終給業務呈現的是一個能直接使用業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。
3、減少重複開發
規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。
4、把複雜問題簡單化
將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。
5、遮蔽原始資料的異常
遮蔽業務的影響，不必改一次業務就需要重新接入資料
6、案列：美團點評酒旅資料倉儲建設實踐
下面透過一線網際網路企業真實的數倉建設實踐案例，來從宏觀層面感受
數倉面向主題分析的特點
在企業中數倉是一個不斷維護的工程。
數倉分層並不侷限於經典3層，可以根據自身需求進行調整
沒有好的架構，只有適合自己業務需求的架構
6、1 美團數倉技術架構：架構變遷
在美團點評酒旅事業群內，業務由傳統的團購形式轉向預訂、直連等更加豐富的產品形式，業務系統也在迅速的迭代變化，這些都對資料倉儲的擴充套件性、穩定性、易用性提出了更高要求。基於此，美團採取了分層次、分主題的方式不斷最佳化並調整層次結構，下圖展示了技術架構的變遷。
第一代數倉模型層次中，由於當時美團整體的業務系統所支援的產品形式比較單一（團購），業務系統中包含了所有業務品類的資料，所以由平臺的角色來加工資料倉儲基礎層是非常合適的，平臺統一建設，支援各個業務線使用，所以在本階段中酒旅只是建立了一個相對比較簡單的資料集市。
第二代數倉模型層次的建設，由建設資料集市的形式轉變成了直接建設酒旅資料倉儲，成為了酒旅自身業務系統資料的唯一加工者。
隨著美團和點評融合，同時酒旅自身的業務系統重構的頻率也相對較高，對第二代數倉模型穩定性造成了非常大的影響，原本的維度模型非常難適配這麼迅速的變化。核心問題是在用業務系統和業務線關係錯綜複雜，業務系統之間差異性明顯且變更頻繁。
於是在ODS與多維明細層中間加入了資料整合層，參照Bill Inmon所提出的企業資訊工廠建設的模式，基本按照三正規化的原則來進行資料整合，由業務驅動調整成了由技術驅動的方式來建設資料倉儲基礎層。
使用本基礎層的最根本出發點還是在於美團的供應鏈、業務、資料它們本身的多樣性，如果業務、資料相對比較單一、簡單，本層次的架構方案很可能將不再適用。
6、2 美團數倉業務架構：主題建設
實際上在傳統的一些如銀行、製造業、電信、零售等行業裡，都有一些比較成熟的模型，如耳熟能詳的BDWM模型，它們都是經過一些具有相類似行業的企業在二三十年資料倉儲建設中所積累的行業經驗，不斷的最佳化並通用化。
但美團所處的O2O行業本身就沒有可借鑑的成熟的資料倉儲主題以及模型，所以，在摸索建設兩年的時間裡，美團總結了下面比較適合現狀的七大主題（後續可能還會新增）
6、3 美團數倉整體架構
確定好技術和業務主題之後，數倉的整體架構就比較清晰了。美團酒旅數倉七個主題基本上都採用6層結構的方式來建設，劃分主題更多是從業務的角度出發，而層次劃分則是基於技術，實質上就是基於業務與技術的結合完成了整體的資料倉儲架構。
比如，以訂單主題為例。在訂單主題的建設過程中，美團是按照由分到總的結構思路來進行建設，首先分供應鏈建設訂單相關實體（資料整合中間層3NF），然後再進行適度抽象把分供應鏈的相關訂單實體進行合併後生成訂單實體（資料整合層3NF），後續在資料整合層的訂單實體基礎上再擴充套件部分維度資訊來完成後續層次的建設。
7、總結
1、什麼是資料倉儲？
儲存資料的倉庫, 主要是用於儲存過去既定發生的歷史資料, 對這些資料進行資料分析的操作, 從而對未來提供決策支援
2、資料倉儲最大的特點：
既不生產資料, 也不消耗資料, 資料來源於各個資料來源
3、資料倉儲的四大特徵：
1) 面向於主題的: 面向於分析, 分析的內容是什麼 什麼就是我們的主題
2) 整合性: 資料是來源於各個資料來源, 將各個資料來源資料彙總在一起
3) 非易失性(穩定性): 儲存在資料倉儲中資料都是過去既定發生資料, 這些資料都是相對比較穩定的資料, 不會發生改變
4) 時變性: 隨著的推移, 原有的分析手段以及原有資料可能都會出現變化(分析手動更換, 以及資料新增)。
4、ETL
ETL: 抽取 轉換 載入
指的: 資料從資料來源將資料灌入到ODS層, 以及從ODS層將資料抽取出來, 對資料進行轉換處理工作, 最終將資料載入到DW層, 然後DW層對資料進行統計分析, 將統計分析後的資料灌入到DA層, 整個全過程都是屬於ETL範疇
狹義上ETL: 從ODS層到DW層過程
5、資料倉儲和 資料庫的區別
資料庫(OLTP): 面向於事務(業務)的 , 主要是用於捕獲資料 , 主要是儲存的最近一段時間的業務資料, 互動性強 一般不允許出現資料冗餘
資料倉儲(OLAP): 面向於分析(主題)的 , 主要是用於分析資料, 主要是儲存的過去歷史資料 , 互動性較弱 可以允許出現一定的冗餘。
6、資料倉儲和資料集市：
資料倉儲其實指的集團資料中心: 主要是將公司中所有的資料全部都聚集在一起進行相關的處理操作 (ODS層)
此操作一般和主題基本沒有什麼太大的關係
資料的集市(小型資料倉儲): 在資料倉儲基礎之上, 基於主題對資料進行抽取處理分析工作, 形成最終分析的結果
一個資料倉儲下, 可以有多個資料集市
7、維度分析
維度一般指的分析的角度, 看待一個問題的時候, 可以多個角度來看待, 而這些角度指的就是維度
比如: 有一份2020年訂單資料, 請嘗試分析
可以從時間, 地域 , 商品, 來源 , 使用者....
維度的分類:
定性維度: 指的計算每天 每月 各個的維度 , 一般來說定性維度的欄位都是放置在group by 中
定量維度: 指的統計某一個具體的維度或者某一個範圍下資訊, 比如說: 2020年度訂單額, 統計20~30歲區間人群的人數 ,一般來說這種維度的欄位都是放置在where中
維度的分層和分級: 本質上對維度進行細分的過程
比如按年統計:
按季度
按照月份
按照天
按照每個小時
比如: 按省份統計:
按市
按縣
從實際分析中, 統計的層級越多, 意味統計的越細化 設定維度內容越多
維度的下鑽和上卷: 以某一個維度為基準, 往細化統計的過程稱為下鑽, 往粗粒度稱為上卷
比如: 按照 天統計, 如果需要統計出 小時, 指的就是下鑽, 如果需要統計 季度 月 年, 稱為上卷統計
從實際分析中, 下鑽和上卷, 意味統計的維度變得更多了
8、指標
指標指的衡量事務發展的標準, 就是度量值
常見的度量值: count() sum() max() min() avg() 還有一些 比例指標(轉化率, 流失率, 同比..)
指標的分類:
絕對指標: 計算具體的值指標
count() sum() max() min() avg()
相對指標: 計算比率問題的指標
轉化率, 流失率, 同比
案列：
需求: 請求出在2020年度, 女性 未婚 年齡在18~25歲區間的使用者每一天的訂單量?
維度: 時間維度 , 性別, 婚姻狀態, 年齡
定性維度: 每一天
定量維度: 2020年度,18~25歲,女性,未婚
指標: 訂單量(絕對指標) --> count()
select day,count(1) from 表 where year ='2020' and age between 18 and 25 and 婚姻='未婚' and sex = '女性' group by day;
9、數倉建模
數倉建模指的規定如何在hive中構建表, 數倉建模中主要提供兩種理論來進行數倉建模操作: 三正規化建模和維度建模理論
三正規化建模: 主要是存在關係型資料庫建模方案上, 主要規定了比如建表的每一個表都應該有一個主鍵, 資料要經歷的避免冗餘發生等等
維度建模: 主要是存在分析性資料庫建模方案上, 主要一切以分析為目標, 只要是利於分析的建模, 都是OK的, 允許出現一定的冗餘, 表也可以沒有主鍵
維度建模的兩個核心概念：事實表和維度表
10、事實表
事實表: 事實表一般指的就是分析主題所對應的表,每一條資料用於描述一個具體的事實資訊, 這些表一般都是一坨主鍵(外來鍵)和描述事實欄位的聚集
例如: 比如說統計2020年度訂單銷售情況
主題: 訂單
相關表: 訂單表(事實表)
思考: 在訂單表, 一條資料, 是不是描述一個具體的訂單資訊呢? 是的
思考: 在訂單表, 一般有那些欄位呢?
訂單的ID, 商品id,單價,購買的數量,下單時間, 使用者id,商家id, 省份id, 市區id, 縣id 商品價格...
進行統計分析的時候, 可以結合 商品維度, 使用者維度, 商家維度, 地區維度 進行統計分析, 在進行統計分析的時候, 可能需要關聯到其他的表(維度表)
注意:
一般需要計算的指標欄位所在表, 都是事實表
事實表的分類：
1) 事務事實表:
儲存的是最原子的資料，也稱“原子事實表”或“交易事實表”。溝通中常說的事實表，大多指的是事務事實表。
2) 週期快照事實表:
週期快照事實表以具有規律性的、可預見的時間間隔來記錄事實，時間間隔如每天、每月、每年等等
週期表由事務表加工產生
3) 累計快照事實表:
完全覆蓋一個事務或產品的生命週期的時間跨度，它通常具有多個日期欄位，用來記錄整個生命週期中的關鍵時間點
11、維度表
維度表: 指的在對事實表進行統計分析的時候, 基於某一個維度, 二這個維度資訊可能其他表中, 而這些表就是維度表
維度表並不一定存在, 但是維度是一定存在:
比如: 根據使用者維度進行統計, 如果在事實表只儲存了使用者id, 此時需要關聯使用者表, 這個時候就是維度表
比如: 根據使用者維度進行統計, 如果在事實表不僅僅儲存了使用者id,還儲存使用者名稱稱, 這個時候有使用者維度, 但是不需要使用者表的參與, 意味著沒有這個維度表
維度表的分類：
高基數維度表: 指的表中的資料量是比較龐大的, 而且資料也在傳送的變化
例如: 商品表, 使用者表
低基數維度表: 指的表中的資料量不是特別多, 一般在幾十條到幾千條左右,而且資料相對比較穩定
例如: 日期表,配置表,區域表
12、維度建模的三種模型：
第一種: 星型模型
特點: 只有一個事實表, 那麼也就意味著只有一個分析的主題, 在事實表的周圍圍繞了多個維度表, 維度表與維度表之間沒有任何的依賴
反映數倉發展初期最容易產生模型
第二種: 雪花模型
特點: 只有一個事實表, 那麼也就意味著只有一個分析的主題, 在事實表的周圍圍繞了多個維度表, 維度表可以接著關聯其他的維度表
反映數倉發展出現了畸形產生模型, 這種模型一旦大量出現, 對後期維護是非常繁瑣, 同時如果依賴層次越多, SQL分析的難度也會加大
此種模型在實際生產中,建議儘量減少這種模型產生
第三種: 星座模型
特點: 有多個事實表, 那麼也就意味著有了多個分析的主題, 在事實表的周圍圍繞了多個維度表, 多個事實表在條件符合的情況下, 可以共享維度表
反映數倉發展中後期最容易產生模型
13、緩慢漸變維
解決問題: 解決歷史變更資料是否需要維護的情況
SCD1: 直接覆蓋, 不維護歷史變化資料
主要適用於: 對錯誤資料處理
SCD2:不刪除、不修改已存在的資料, 當資料發生變更後, 會新增一條新的版本記錄的資料, 在建表的時候, 會多加兩個欄位(起始時間, 截止時間), 透過這兩個欄位來標記每條資料的起止時間 , 一般稱為拉鍊表
好處: 適用於儲存多個歷史版本, 方便維護實現
弊端: 會造成資料冗餘情況, 導致磁碟佔用率提升
SCD3: 透過在增加列的方式來維護歷史變化資料
好處: 減少資料的冗餘, 適用於少量歷史版本的記錄以及磁碟空間不是特別充足情況
弊端: 無法記錄更多的歷史版本, 以及維護比較繁瑣
————————————————
版權宣告：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本宣告。
原文連結：https://blog.csdn.net/Remix_xy/article/details/125710888