CH4.2 數據儲存與管理
數據儲存與管理
三種資料型態對應儲存方式 → 分散式儲存架構與資料湖/資料倉儲（Data Lakehouse 融合趨勢）→ 儲存效能優化（分區、壓縮、分層、欄位裁剪）與查詢加速 → 資料一致性（ACID／強一致性／最終一致性）與版本控制 → 資料治理與存取控制模型（RBAC/ABAC/PBAC/DAC）→ Zero Trust 架構。
1. 三種資料型態的儲存方式
| 資料型態 | 定義特性 | 儲存方式 | 優勢 | 限制 |
|---|---|---|---|---|
| 結構化數據 | 明確欄位定義、固定資料型別 | 關聯式資料庫（RDBMS，如 MySQL、PostgreSQL、Oracle） | 支援 SQL 查詢、具完整性約束與交易一致性（ACID） | 欄位結構固定，不適合頻繁變更結構的情境 |
| 半結構化數據 | 無固定欄位但具層次與標記格式（JSON、XML、YAML） | 文件型 NoSQL（如 MongoDB）、全文搜尋系統（ElasticSearch）、資料湖 | 格式彈性高，適合異質資料整合 | 缺乏結構約束，查詢與驗證邏輯需自定 |
| 非結構化數據 | 無明確格式（文字、圖片、音訊、影片） | 物件儲存（Amazon S3、MinIO）、分散式檔案系統（HDFS） | 可儲存任意型態的原始檔案 | 難以直接搜尋與比對，需依賴 metadata 管理系統 |
企業常需同時處理多種資料型態（如電商訂單為結構化、商品描述為半結構化、商品圖片為非結構化），需具備異質資料整合能力，搭配分層儲存架構與資料湖設計統一管理。
2. 分散式儲存與資料湖架構
(1) 分散式儲存（Distributed Storage）
將資料切分為多個區塊，分散儲存在多台節點上，由中央控制系統統一調度管理，具備副本機制、冗餘設計與故障轉移策略。
| 技術特性 | 說明 |
|---|---|
| 橫向擴充（Scalability） | 增加節點數量即可擴充容量與效能，無需重構架構 |
| 容錯容災能力 | 多副本儲存、分佈式一致性協議（Paxos、Raft），提升可用性 |
| 高並行性與分散存取 | 支援多使用者同時讀寫，資料分區處理並行查詢 |
| 資料本地性（Data Locality） | 資料存放與計算節點相近（如 Hadoop MapReduce 設計），降低傳輸成本 |
常見平台：HDFS（最早的大規模分散式檔案系統，支援 MapReduce）、Amazon S3、Google Cloud Storage、Ceph/GlusterFS（開源，常用於私有雲）。
(2) 資料湖架構（Data Lake）
以原始格式儲存各類資料（結構化、半結構化、非結構化）的架構，主要特性：
- 原始資料保留：允許儲存尚未轉換、未清洗的原始資料。
- 支援多種格式：CSV、JSON、Avro、Parquet、影像、影片等。
- Schema-on-Read：資料儲存時不強制定義結構，待使用時才套用結構（相對於傳統資料庫的 Schema-on-Write）。
- 資料湖倉（Data Lakehouse）：結合資料湖的彈性儲存與成本效益，以及資料倉儲的結構化查詢與資料治理能力，是兩者融合的現代化架構。
常見工具：Hadoop + HDFS + Hive；Delta Lake、Apache Iceberg、Apache Hudi（支援 ACID 操作、版本控制、即時查詢）；雲端方案（AWS Lake Formation、Azure Data Lake、Google Cloud BigLake）。
資料湖與傳統資料倉儲最大的差異在於：資料湖支援多樣資料型態且不需預先定義結構（Schema-on-Read），資料倉儲則需先定義嚴格的 Schema（Schema-on-Write）才能寫入資料。
3. 儲存效能優化與查詢加速
(1) 儲存效能優化策略
| 策略 | 說明 | 適用情境 |
|---|---|---|
| 分區儲存（Partitioning） | 依時間、地區、用戶類型等欄位水平切分資料 | 時間序列資料、週期性報表 |
| 壓縮技術（Compression） | 列式儲存格式（Parquet、ORC）+ 壓縮演算法（Snappy、ZSTD） | 讀取頻率高但更新頻率低的分析型情境 |
| 儲存分層（Storage Tiering） | 依資料熱度分為熱資料（SSD）與冷資料（HDD/雲端） | 兼顧查詢效能與儲存成本 |
| 欄位裁剪與投影（Column Pruning） | 查詢時僅載入必要欄位 | 列式儲存格式，減少讀取量 |
(2) 查詢管理與加速技術
- 預計算與物化檢視（Materialized View）：預先計算並快取重複性查詢結果，適合 BI 報表、儀表板。
- 索引建構（Indexing）：NoSQL 或文件型資料庫建置倒排索引、文字索引加快條件查詢。
- 查詢引擎優化（Query Optimization）：如 Spark 的 Catalyst Optimizer、Presto 的 CBO（Cost-Based Optimizer）。
- 資源管控與查詢隔離（Query Throttling）：透過查詢優先順序與資源限制，避免個別查詢消耗過多資源。
4. 資料一致性機制與版本控制
(1) 一致性策略比較
| 一致性模型 | 定義 | 適用情境 | 代表技術 |
|---|---|---|---|
| 強一致性（Strong Consistency） | 寫入後所有讀取請求都能即時取得最新狀態 | 交易型應用（金融交易、帳務處理） | Delta Lake、Apache Iceberg（結合 ACID） |
| 最終一致性（Eventual Consistency） | 允許短時間非同步，最終趨於一致 | 高可用性、大規模擴展應用 | Amazon S3、HDFS |
(2) ACID 四大特性
資料庫交易設計的四大關鍵特性，確保資料一致性與可靠性：
| 特性 | 意義 |
|---|---|
| Atomicity（原子性） | 一筆交易的所有操作「全做完」或「全不做」 |
| Consistency（一致性） | 交易前後資料保持邏輯一致，符合預先定義的規則 |
| Isolation（隔離性） | 多筆交易並行執行時彼此不互相干擾 |
| Durability（持久性） | 交易成功提交後，變更永久保存，即使系統當機也不遺失 |
ACID 廣泛應用於傳統關聯式資料庫（PostgreSQL、MySQL），現代資料湖倉技術（Delta Lake、Apache Iceberg）也透過元資料版本管理與寫入日誌模擬並支援 ACID 操作，是資料湖倉能媲美傳統資料庫可靠性的關鍵。
(3) 資料版本控制
透過版本標記（v1、v2）建立資料歷史記錄與追溯能力：Delta Lake 的 Time Travel 功能與 Apache Hudi 的 Incremental Query 機制，能支援查詢過往任一版本狀態，並支援誤寫復原、資料還原及模型再訓練，對 AI 應用的可複製性（reproducibility）尤其關鍵。
5. 資料治理與存取控管
(1) 元資料管理（Metadata Management）
元資料是「描述資料本身的資料」（來源、格式、欄位定義、建立時間等）。透過建立資料目錄（Data Catalog），可達成資料血緣追蹤（Data Lineage）（瞭解資料從來源到使用的流向）、自動化資料探索、跨部門欄位定義對齊。
(2) 存取控制模型比較
| 模型 | 全名 | 控管依據 | 優點 | 適用情境 |
|---|---|---|---|---|
| RBAC | Role-Based Access Control | 使用者所屬角色（工程師/分析師/主管） | 邏輯清楚、實作簡單 | 中小企業、部門制組織 |
| ABAC | Attribute-Based Access Control | 使用者屬性、資料屬性、環境條件（地點/時間/裝置） | 控管彈性高、支援細緻動態授權 | 大型企業、高安全性情境 |
| PBAC | Policy-Based Access Control | 預先定義的複合策略規則（如 OPA、Rego） | 可統一控管多系統資源、支援複雜條件語法 | 雲端平台、跨部門跨系統整合 |
| DAC | Discretionary Access Control | 資料擁有者自行決定誰可存取 | 彈性高，適合小規模團隊 | 研發團隊、開發環境、小型專案 |
「角色定 RBAC、屬性定 ABAC、政策定 PBAC、擁有者自己定 DAC」——四種模型的核心差異就在「誰／什麼條件」決定授權。
(3) Zero Trust 架構
主張「不預設信任任何人與裝置」，即便是內部使用者也需持續驗證：
- 最小權限原則（Least Privilege）：僅能存取完成任務所需的最小資料範圍。
- 動態授權管理（Just-In-Time Access）：依使用者行為、時間、裝置等條件動態調整權限。
- 持續驗證（Continuous Authentication）：配合多因子驗證與行為分析。
- 資源導向防護（Microsegmentation）：資料資源分區，避免單一節點被入侵後橫向擴散。
📝 章節考題自測（先作答，再點開解答）
Q1. 下列何者是資料湖（Data Lake）與傳統資料倉儲最主要的差異？
(A) 資料湖僅支援結構化資料 (B) 資料湖支援多樣資料型態，且採用 Schema-on-Read 不需預先定義結構 (C) 資料倉儲無法被查詢 (D) 資料湖適用於即時交易處理
解答與解析
參考 Ans: (B) 資料湖可儲存原始格式的結構化、半結構化與非結構化資料，採用 Schema-on-Read（使用時才套用結構），支援彈性探索；傳統資料倉儲則需先定義嚴格 Schema（Schema-on-Write）。
Q2. 關於 ACID 特性中的「隔離性（Isolation）」，下列描述何者正確？
(A) 交易一旦提交，資料變更永久保存 (B) 交易的所有操作全做完或全不做 (C) 多筆交易並行執行時彼此不互相干擾，如同單獨執行 (D) 交易前後資料須保持邏輯一致
解答與解析
參考 Ans: (C) 隔離性（Isolation）強調多筆交易並行時彼此互不干擾，每筆交易的執行結果應如同單獨運行一樣；(A) 為持久性（Durability）、(B) 為原子性（Atomicity）、(D) 為一致性（Consistency）。
Q3. 某跨國企業希望依「使用者的部門、存取時間與所在地點」動態決定資料存取權限，最適合採用下列哪一種存取控制模型？
(A) RBAC (B) ABAC (C) DAC (D) 不需要任何存取控制
解答與解析
參考 Ans: (B) ABAC（Attribute-Based Access Control）依使用者屬性、資料屬性與環境條件（如地點、時間、裝置）動態授權，控管彈性最高，適合大型企業或高安全性、多變化的情境，優於僅依角色分類的 RBAC。
Q4. 下列何種一致性模型最適合金融交易系統？
(A) 最終一致性（Eventual Consistency） (B) 強一致性（Strong Consistency） (C) 無一致性要求 (D) 依使用者喜好決定
解答與解析
參考 Ans: (B) 金融交易、帳務處理等交易型應用需要強一致性，確保寫入後所有讀取請求都能即時取得最新狀態，通常結合 ACID 特性實現。
Q5. 半結構化資料（如 JSON、XML）最適合儲存於下列哪一種系統？
(A) 傳統關聯式資料庫（RDBMS） (B) 文件型 NoSQL 資料庫（如 MongoDB） (C) 僅限本地端硬碟 (D) 純文字檔案系統，無需任何資料庫
解答與解析
參考 Ans: (B) 半結構化資料具層次結構但欄位可能動態變動，文件型 NoSQL 資料庫（如 MongoDB）可有效儲存並支援彈性查詢，優於需要固定欄位的關聯式資料庫。
Q6. 關於「儲存分層（Storage Tiering）」的敘述，下列何者正確？
(A) 將所有資料統一存放在同一種硬體媒介 (B) 依資料熱度分類為熱資料與冷資料，分別存於不同媒介以兼顧效能與成本 (C) 只適用於結構化資料 (D) 與查詢效能無關
解答與解析
參考 Ans: (B) 儲存分層依照資料熱度將資料分類存放於 SSD、HDD 或雲端儲存等不同媒介，透過動態調整儲存層級，在查詢效能與儲存成本間取得平衡。
Q7. 若一個組織的資料存取權限完全由「資料擁有者自行決定授予對象」，這屬於下列哪一種存取控制模型？
(A) RBAC (B) ABAC (C) PBAC (D) DAC
解答與解析
參考 Ans: (D) DAC（Discretionary Access Control，自主存取控制）由資料擁有者自行決定誰可存取其資源，彈性高，適合小規模團隊或快速開發環境。