Big Data 與 NoSQL：從資料特性到水平擴充與 CAP
本頁為依教材與考古題整理的原創摘要；考古題答案經技術覆核，但不是官方答案。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
大數據 5V
也會看到：Big Data、volume、velocity、variety、veracity、value用資料量、速度、種類、可信度與價值等面向描述超出一般處理方式的資料問題。
- 生活例子：
- 外送平台同時收到大量、快速、格式不同且品質不一的訂單與定位資料。
- 別搞混：
- 資料很多只是其中一個面向；Big Data 不是任何大型檔案的同義詞。
NoSQL 與 CAP
也會看到：NoSQL、CAP theorem、consistency、availability、partition toleranceNoSQL 是多種非關聯式資料模型；CAP 說網路分割時，分散式系統無法同時保證強一致與每次都有回應。
- 生活例子：
- 多家分店斷線時，要選擇暫停部分服務或先接受可能不同步的訂單。
- 別搞混：
- CAP 不是平常任選兩項的產品標籤，也不是 ACID 的直接反義詞。
NoSQL 資料模型
也會看到：document store、key-value、wide-column、graph database依資料形狀與查詢方式，選擇文件、鍵值、寬欄或圖等非關聯式模型。
- 生活例子：
- 通訊錄像文件、置物櫃像鍵值、好友關係網則像圖資料庫。
- 別搞混：
- NoSQL 不是完全不能有結構，也不是永遠比關聯式資料庫快。
分片與複寫
也會看到：sharding、replication、horizontal scaling分片把不同資料分到多台機器；複寫則把同一份資料保留多個副本。
- 生活例子：
- 分片像把不同區域訂單交給不同分店，複寫像每間分店都有同一份備用菜單。
- 別搞混：
- 分片主要分散容量與負載；複寫主要增加讀取能力或可用性，兩者不是同一件事。
由 volume、velocity、variety、veracity 與分析用途判斷 Big Data 問題，再依資料存取形狀選擇 document、key-value、wide-column 或 graph model，最後區分 sharding、replication、horizontal scaling 與 CAP 取捨。對應考古題答案均為非官方技術覆核；disputed 或 OCR 破損題不列入 refs。
先抓住這幾件事
- 解釋 Big Data 的 volume、velocity、variety、veracity 與可行分析用途。
- 依資料形狀與查詢需求比較四類常見 NoSQL data models。
- 區分 vertical/horizontal scaling、sharding 與 replication。
- 正確解釋 CAP 的 consistency、availability、partition tolerance 與 network partition 下的取捨。
先想像這個場景
連鎖超商的即時營運平台
一間連鎖超商每秒收到大量門市交易、感測器 readings、JSON 商品資料與顧客回饋。團隊既想預測補貨，也要把不同資料模型分散到多台 servers；如果分店網路中斷，還得決定要暫停部分操作維持一致，或先持續服務、稍後再協調。這個平台把 Big Data 的資料特性、NoSQL 選型、sharding 與 CAP 放在同一條營運流程中。
先別急著往下看，花十秒想一想：
兩個資料副本因 network partition 無法互通：方案甲暫停其中一側寫入以避免分歧，方案乙讓兩側繼續接受寫入、之後再合併。哪個偏 CP，哪個偏 AP？
把故事換成電腦語言
| 生活中的角色 | 對應到 | 技術概念 |
|---|---|---|
| 大量資料持續高速湧入，格式包含交易表、JSON、文字與感測 readings，部分資料還缺校正資訊 | Volume、velocity、variety、veracity 分別描述資料量、流速、多樣性與可信度；V framework 版本須依題目限定 | |
| 團隊用資料做補貨決策、需求預測、異常偵測與公共服務分析 | Big-data analytics 可支援 decision making、forecast、vulnerability assessment 與 governance，但資料量不保證結論正確 | |
| Session 依唯一 key 取值、商品資料有彈性欄位、社交關係要走訪、設備 metrics 欄位稀疏 | 依 access pattern 對應 key-value、document、graph、wide-column；NoSQL 不等於完全沒有 schema、index 或 transaction | |
| 不同顧客資料依 userId 分到不同 servers，同一份重要資料再保存副本 | Sharding 分散不同資料以水平擴充；replication 保存相同資料的 copies 以支援 availability、讀取或復原 | |
| 網路分區時，一側拒絕部分請求避免資料分歧，或兩側都回應並容許暫時不一致 | Partition 下拒絕部分請求偏 CP；持續回應並稍後 reconciliation 偏 AP，CAP 不是平時任意三選二的效能口號 |
題目出現這些字，先想到
- 看到 Big Data 的 V：volume 是量、velocity 是速度、variety 是格式來源、veracity 是可信度；先確認題目採 3V、4V 或 5V。
- 看到 NoSQL model：直接 key lookup 想 key-value，彈性巢狀資料想 document，關係走訪想 graph，稀疏欄位想 wide-column。
- 看到 scale out、shard key、replica：增加 nodes 是 horizontal scaling；切不同資料是 sharding；保存副本是 replication。
- 看到 CAP：C/A/P 是 consistency、availability、partition tolerance；真正的 C/A 取捨發生在 partition 情境。
1.Big Data 的 V 是問題特性，不是固定產品清單
Big Data 指的是傳統資料處理工具難以有效處理的大規模、高速度、多樣性資料集。Laney（2001）提出的 3V 模型是最被廣泛接受的框架： • Volume（量）：資料量大到超出單機處理能力，需要分散式系統。從 TB 到 PB 甚至 EB 等級。 • Velocity（速度）：資料產生和需要處理的速度極快。例如社群媒體每秒產生的貼文、IoT 感測器的即時串流資料。 • Variety（多樣性）：資料格式不統一。結構化資料（關聯式表格）、半結構化資料（JSON、XML）、非結構化資料（文字、影像、影片）混合存在。 後來有人擴充到 5V（加上 Veracity 資料品質可信度、Value 商業價值），但 Laudon MIS 教科書和多數考試以 3V 為主。考古題曾問「Big Data 特性是否包含 Value」— 答案取決於採用的版本，但嚴格來說 Laney 原始模型只有 3V。 【重要澄清】Big Data 不是一個產品名稱或特定技術，而是描述資料問題特性的框架。Hadoop、Spark、Kafka 等是處理 Big Data 的工具，但它們本身不是 Big Data。同樣地，「有很多資料」不自動等於 Big Data — 還要看處理速度和多樣性是否超出傳統工具的能力。 【考試連結】選擇題常要你從描述中辨識是哪個 V。例如「即時分析來自全球感測器的串流資料」→ Velocity；「同時處理交易紀錄、客服錄音和社群評論」→ Variety。
- Volume 大不只指檔案數量，也涉及儲存與平行處理需求。
- Velocity 會影響 batch 或 stream processing 的選擇。
- Variety 可包含 structured、semi-structured 與 unstructured data。
- Veracity 不代表資料必須完美，而是分析時需處理 noise、missing values 與可信度。
2.分析用途跨領域，但仍需可驗證的問題與資料
Big Data 分析的應用橫跨商業、醫療、交通、金融、教育等領域，但有效的分析必須從明確的問題開始，而不是「有資料就分析」。典型的分析流程：(1) 定義商業問題（要預測什麼？要優化什麼？）→ (2) 蒐集並清理相關資料 → (3) 選擇適當的分析方法 → (4) 建立模型或進行分析 → (5) 驗證結果並轉化為可行動的洞見。 常見的分析類型： • Descriptive analytics（描述性分析）：回答「發生了什麼」。例如銷售報表、網站流量統計。 • Diagnostic analytics（診斷性分析）：回答「為什麼發生」。例如找出銷售下降的原因。 • Predictive analytics（預測性分析）：回答「可能會發生什麼」。使用統計模型或 ML 預測未來趨勢。 • Prescriptive analytics（處方性分析）：回答「應該怎麼做」。結合預測結果和優化方法給出行動建議。 【資料品質的重要性】Garbage in, garbage out — 再好的演算法也無法從低品質的資料中產生可靠的結論。常見的資料品質問題包括：遺漏值（missing values）、重複記錄、格式不一致、標籤錯誤、取樣偏差。在分析之前，資料清理（data cleaning）和探索性資料分析（EDA）是不可省略的步驟。 【考試連結】題目常給一個商業情境，要你判斷屬於哪種分析類型。關鍵是看問題是「回顧過去」（descriptive）、「解釋原因」（diagnostic）、「預測未來」（predictive）還是「建議行動」（prescriptive）。
- Decision making 把分析結果連結到可選行動。
- Forecast 使用過去與目前資料估計未來，但需評估 distribution shift。
- Vulnerability assessment 可從大量 logs/events 找異常或風險訊號。
- Government governance 可分析公共服務需求，但需同時處理 privacy、bias 與 accountability。
3.NoSQL 依資料模型與 access pattern 選擇
NoSQL（Not Only SQL）是一類非關聯式資料庫的統稱，設計目的是處理關聯式資料庫不擅長的場景：極大量資料、高併發讀寫、靈活的 schema、或特殊的資料結構需求。NoSQL 不是一種單一技術，而是依資料模型分為四大類： (1) Key-Value Store：最簡單的模型，每筆資料是一個 key-value pair。查詢只能透過 key 取值，不支援複雜查詢。適合 session 管理、快取。代表：Redis、DynamoDB。 (2) Document Store：value 是結構化文件（通常是 JSON），可以對文件內容建立索引和查詢。適合內容管理、商品目錄等 schema 不固定的場景。代表：MongoDB、CouchDB。 (3) Column-Family Store：資料按 column family 分組儲存，而非按 row。適合大規模寫入和分析型查詢。代表：Cassandra、HBase。 (4) Graph Database：以 node（節點）和 edge（邊）為基本單位，擅長表達和查詢複雜的關係。適合社交網路、推薦系統、知識圖譜。代表：Neo4j。 選擇 NoSQL 類型的關鍵是 access pattern（存取模式）：主要靠 key 查詢 → key-value；需要查詢文件內容 → document；大量寫入和列導向分析 → column-family；關係查詢為主 → graph。 【考試連結】題目常描述一個應用場景，要你選擇最適合的 NoSQL 類型。例如「社交網路中找出兩個用戶之間的最短路徑」→ Graph Database，不是 Document Store。
- Document store 以 JSON-like documents 保存欄位、陣列與巢狀結構。
- Key-value store 以 unique key 找 value，適合 session、cache 等直接 lookup。
- Wide-column store 允許 rows 有不同或稀疏 columns，適合大規模分散資料。
- Graph database 以 nodes 與 edges 表示高度連結關係，適合 traversal 與 relationship queries。
4.Horizontal scaling、sharding 與 replication 不同
擴展資料庫容量和效能有兩種方向： • Vertical scaling（垂直擴展/scale up）：升級單台機器的硬體 — 加 CPU、加記憶體、換更快的 SSD。優點是簡單，不需要改程式架構。缺點是有物理上限（單機能裝的硬體有限），且高階硬體價格非線性增長。 • Horizontal scaling（水平擴展/scale out）：增加更多機器，把資料和負載分散到多台機器上。這是 NoSQL 和現代分散式系統的主要擴展方式。 水平擴展的兩個關鍵機制： Sharding（分片）：把一個大的資料集切割成多個 shard，每個 shard 存放在不同的機器上。切割的依據稱為 shard key — 例如按用戶 ID 範圍（user 1-1000 在 shard A，1001-2000 在 shard B）或按 hash 值分配。Sharding 的目的是把讀寫負載分散到多台機器，每台機器只處理一部分資料。 Replication（複製）：同一份資料維持多個副本（replica），存放在不同機器上。目的有二：(1) 容錯 — 一台機器壞了，其他副本仍可提供服務。(2) 讀取效能 — 讀取可以分散到多個 replica。但寫入時需要同步所有 replica，會引入一致性問題。 【Sharding ≠ Replication】Sharding 是把「不同的資料」放到不同機器（每台機器有資料的一部分）；Replication 是把「相同的資料」放到多台機器（每台機器有完整或部分副本）。兩者可以同時使用：先 shard 把資料分片，再對每個 shard 做 replication 以確保容錯。 【考試連結】題目常混淆 sharding 和 replication，問「以下哪個是增加資料可用性的方法」→ Replication；「以下哪個是提升寫入吞吐量的方法」→ Sharding。
- 好的 shard key 應避免所有 writes 集中到單一 hot shard。
- 不含 shard key 的查詢可能需要 scatter/gather 到多個 shards。
- Replication 會帶來 replica lag、failover 與一致性選擇。
- Horizontal scaling 增加協調與維運複雜度，不是免費的無限擴充。
5.CAP 描述 network partition 發生時的保證取捨
CAP theorem（Brewer's theorem）指出，在分散式系統中，以下三個保證不可能同時完全滿足： • Consistency（一致性）：所有節點在同一時間看到的資料相同。任何讀取都能取得最新的寫入結果。 • Availability（可用性）：每個請求都能收到（非錯誤的）回應，即使部分節點故障。系統不會拒絕服務。 • Partition tolerance（分區容忍）：即使網路分區（部分節點之間無法通訊）發生，系統仍能繼續運作。 在實際的分散式系統中，網路分區是不可避免的（網線可能斷、路由器可能故障），因此 P 幾乎是必須的。這意味著當 partition 發生時，系統必須在 C 和 A 之間取捨： • CP 系統：選擇一致性，犧牲可用性。Partition 發生時，可能暫時拒絕服務直到一致性恢復。例如 HBase、MongoDB（在某些配置下）。 • AP 系統：選擇可用性，犧牲強一致性。Partition 發生時，仍提供服務但可能回傳舊資料（eventual consistency）。例如 Cassandra、DynamoDB。 【重要澄清】CAP 不是說「任何時候只能選兩個」— 在沒有 partition 的正常情況下，系統可以同時提供 C 和 A。CAP 描述的是「當 partition 發生時」的取捨。另外，Consistency 在 CAP 中指的是 linearizability（線性一致性），和 ACID 中的 Consistency（資料完整性約束）是不同概念。 【考試連結】題目常給一個系統描述，問它是 CP 還是 AP。關鍵看「partition 發生時，系統會暫停服務（CP）還是繼續服務但可能資料不一致（AP）」。也常考 CAP 和 ACID 中 Consistency 的差異。
- 選 CP 表示 partition 時可能犧牲部分 availability 以避免不一致結果。
- 選 AP 表示 partition 時持續回應，但必須容許暫時不一致並在之後協調。
- Partition tolerance 是分散式部署必須面對的故障條件，不等於資料分區 sharding。
- CAP 不直接宣稱所有 NoSQL 都是 eventual consistency；具體保證依系統與設定而異。
一起拆題目
範例 1：某系統每秒接收 50,000 筆 IoT readings，來源包含數字、JSON 與影像 metadata，其中 3% readings 缺少校正資訊。分別指出最直接對應的 volume、velocity、variety、veracity 證據。
- 大量累積 readings 對應 volume。
- 每秒 50,000 筆的流入速率對應 velocity。
- 數字、JSON、影像 metadata 等不同格式對應 variety。
- 缺少校正資訊會影響可信度與品質，對應 veracity。
所以答案是：Volume＝大量累積資料；velocity＝50,000 筆/秒；variety＝多種格式；veracity＝3% 缺校正資訊所造成的品質疑慮。
範例 2：為四個需求選 data model：①sessionId→session；②每位使用者有不同 optional profile fields；③查詢朋友的朋友；④每台設備每天產生稀疏且不同的 metrics columns。
- ① 是以唯一 key 直接取 value，選 key-value。
- ② 是欄位可變且含巢狀結構的實體，選 document。
- ③ 重點是 entities 間的 edges 與 traversal，選 graph。
- ④ 各 rows 的 columns 稀疏且可能不同，選 wide-column。
所以答案是：① key-value；② document；③ graph；④ wide-column。這是依 access pattern 的配對，不代表其他模型絕對做不到。
範例 3：以 hash(userId) mod 3 分配 shard。userId 10、11、14 各落在哪個 shard？新增每筆資料的第二份副本後，這個動作是 sharding 還是 replication？
- 10 mod 3=1，因此 userId 10 到 shard 1。
- 11 mod 3=2，因此 userId 11 到 shard 2。
- 14 mod 3=2，因此 userId 14 也到 shard 2。
- 依 key 分散不同 records 是 sharding；保存第二份相同資料是 replication。
所以答案是：10→shard 1，11→shard 2，14→shard 2；第二份副本屬 replication。
範例 4：兩個 replicas 因 network partition 無法互通。方案 X 暫停其中一側寫入，直到能確認最新版本；方案 Y 兩側都繼續接受 writes，稍後合併。CAP 下 X、Y 各偏向哪種取捨？
- Partition 已發生，P 是必須處理的故障條件。
- X 拒絕部分請求以避免兩側同時產生無法排序的更新，偏向維持 consistency。
- X 因此犧牲 partition 期間部分 availability，屬 CP 取向。
- Y 持續回應但容許暫時分歧，偏向 availability，屬 AP 取向。
所以答案是：X 偏 CP；Y 偏 AP。AP 不代表永遠不一致，而是 partition 期間允許暫時分歧並需後續 reconciliation。
這裡最容易選錯
- 把不同 Big Data V frameworks 混成唯一不變定義，忽略題目是否指定版本。
- 認為資料量夠大就自然能產生正確決策，忽略品質、偏差與驗證。
- 把 NoSQL 解讀成完全沒有 schema、indexes 或 transactions。
- 看到 JSON 就一定選 document store，不先看實際 access pattern。
- 混淆 sharding 與 replication，或認為 horizontal scaling 沒有協調成本。
- 把 CAP 簡化為任何時候都能自由三選二，忽略 network partition 情境。
- 宣稱所有 NoSQL 都犧牲 consistency；實際保證取決於產品與設定。
換你快速判斷
先在心中作答，再展開答案。答不出來時，回頭找本課的對照關係。
1Big Data 的 volume、velocity、variety、veracity 分別描述什麼？
資料量、資料流入/處理速度、資料格式與來源多樣性、資料準確性與可信度。
教材另可能加入 value；題目必須說明採用哪個 V framework，不能把版本差異硬當唯一答案。
2Big-data analytics 可支援哪些類型的應用？
可支援 decision making、forecast/prediction、vulnerability assessment 與 government governance 等，但需驗證資料與方法。
『可應用』不表示任何大型資料都能產生可靠結論；品質、代表性、privacy 與 evaluation 仍不可省略。
3四類常見 NoSQL data models 是什麼？
Document、key-value、wide-column 與 graph。
應依 data shape 與 access pattern 選擇；NoSQL 不表示完全沒有 schema、indexes、queries 或 transactions。
4Horizontal scaling 與 vertical scaling 有何差異？
Horizontal scaling 增加 nodes 並分散資料/負載；vertical scaling 提升單一 server 的 CPU、RAM 或 storage。
NoSQL 常針對水平擴充設計，但新增 nodes 會增加 routing、coordination 與 operations 複雜度。
5Sharding 與 replication 的目的有何差異？
Sharding 把不同資料分散到 shards 以擴充容量/吞吐；replication 保存副本以支援 availability、讀取或復原。
兩者可並用；資料分區不自動產生備援，建立副本也不等於把 dataset 切開。
6CAP 的 C、A、P 是什麼？真正的取捨情境為何？
Consistency、availability、partition tolerance；network partition 發生時，無法同時保證 C 與 A。
CP 可能拒絕部分請求以維持一致性；AP 持續回應但容許暫時分歧。CAP 不是所有時候任意『三選二』。
最後用考古題驗證
本課連結的題目都已通過可重現的技術覆核，可逐題練習與判分。
開始本課考古題練習參考來源
- What is big data? — IBM Think
- What is NoSQL? — MongoDB
- Sharding — MongoDB Documentation
- What is the CAP theorem? — IBM Think