1. HBase

1.1 概念

HBase是構建在Hadoop HDFS之上的分布式NoSQL數據庫，采用列式存儲模型，支持海量數據的實時讀寫和隨機訪問。適用于高吞吐、低延遲的場景，如實時日志處理、在線交易等。

RowKey（行鍵）
定義：表中每行數據的唯一標識，類似于關系數據庫的主鍵。
特點：數據按 RowKey 的字典序全局排序。
所有查詢必須基于 RowKey 或范圍掃描（Scan）。
示例：user_123_order_1001（用戶ID + 訂單ID）。

Region（區域）
定義：HBase 表的水平分片，每個 Region 存儲一段連續的 RowKey 范圍。
特點：一個表初始只有一個 Region，隨著數據增長自動分裂（如達到 10GB 閾值）。
每個 Region 由一個 RegionServer 管理。
示例：Region 1 存儲 [A-M] 的 RowKey，Region 2 存儲 [N-Z]

Column Family（列族）
定義：列的邏輯分組，每個列族對應獨立的物理存儲單元（HFile）。
特點：列族需預先定義，但列（Qualifier）可動態添加。
同一列族的數據存儲在一起，優化讀取效率。
示例：定義 OrderInfo 和 ProductDetails 兩個列族。

1.2 組件

HMaster
角色：集群的管理者，負責元數據操作和協調。
職責：管理表的創建、刪除、修改（如列族定義）。
分配 Region 到 RegionServer，并在節點故障時重新分配。
監控所有 RegionServer 的狀態（通過 ZooKeeper）。
注意：HMaster 本身不直接處理讀寫請求，因此 HBase 的高可用性依賴多 HMaster 實例。

RegionServer
角色：數據存儲和讀寫請求的實際處理者。
職責：管理多個 Region（每個 Region 對應表的一部分數據）。
處理客戶端的讀寫請求（如 Put、Get、Scan）。
管理 MemStore（內存緩存）和 HFile（磁盤文件）。
定期執行數據刷寫（Flush）和合并（Compaction）。

ZooKeeper
角色：分布式協調服務，維護集群狀態和元數據。
職責：管理 HMaster 的選舉（避免單點故障）。
監控 RegionServer 的存活狀態（通過心跳機制）。
存儲 HBase 的元數據（如 hbase:meta 表的位置）。

HDFS
角色：HBase 的底層存儲系統。
職責：持久化存儲 HFile 數據（每個 HFile 對應一個列族）。
通過多副本機制保障數據可靠性。

1.3 計算流程

寫入流程

讀取流程

1.4 列族存儲與行鍵的協同關系

物理分離，邏輯聚合：每個列族對應獨立的 HFile 文件，但同一行鍵下的不同列族數據通過行鍵關聯。
假設表結構如下：

RowKey	列族：Info	列族：Order
user_123	name: Alice	order_2023: 手機
user_456	name: Bob	order_2023: 電腦

列族 Info 和 Order 的數據存儲在不同的 HFile 中。
當查詢 user_123 的 Info.name 和 Order.order_2023 時，HBase 會通過行鍵 user_123 定位到對應的 Region，再分別從 Info 和 Order 的 HFile 中讀取數據。

1.5 行鍵設計的核心原則

將高頻查詢條件作為前綴
示例：若按用戶查詢為主，行鍵設計為 用戶ID_時間戳。
若按時間范圍查詢為主，行鍵設計為 反轉時間戳_用戶ID（避免熱點）。

避免熱點問題
錯誤設計：單調遞增的行鍵（如 timestamp），導致新數據集中寫入單個 Region。
改進方案：添加哈希前綴（如 MD5(userID)[0:4]_userID）。
反轉時間戳（如 Long.MAX_VALUE - timestamp）。

控制行鍵長度
行鍵會冗余存儲在每個單元格（Cell）中，過長會浪費存儲和內存。

場景1：高效讀取（合理行鍵設計）
需求：查詢用戶 user_123 的姓名（列族 Info，列 name）。
行鍵設計：用戶ID（如 user_123）。
流程：通過行鍵 user_123 直接定位到對應的 Region。
在該 Region 的 Info 列族 HFile 中讀取 name 列的值。
耗時：毫秒級。

場景2：低效讀取（無行鍵條件）
需求：查詢所有用戶的 name 列。
問題：未指定行鍵，需全表掃描。
流程：掃描所有 Region。
遍歷每個 Region 的 Info 列族 HFile。
耗時：分鐘級到小時級。

1.6 HBase適合實時的原因

寫得快：LSM 樹（Log-Structured Merge Tree）架構
寫入優化：數據先寫入內存（MemStore），再異步刷寫到磁盤（HFile），避免傳統數據庫的直接磁盤隨機寫入。
內存寫入速度極快（微秒級），適合高吞吐的實時寫入（如每秒百萬級寫入）。
合并機制：定期將多個小 HFile 合并為大文件（Compaction），平衡讀寫性能，避免碎片化導致的讀取延遲。
寫方面，與HIVE對比

數據庫	寫入機制	速度特點
HBase	- 數據先寫入內存（MemStore），異步刷寫到磁盤（HFile）。- 基于LSM樹優化寫入。	高速寫入：支持高吞吐（每秒百萬級寫入），延遲在毫秒級，適合實時寫入場景。
Hive	- 數據寫入本質是向HDFS追加文件（如TextFile、ORC、Parquet）。- 需要格式轉換。	低速寫入：涉及文件格式轉換和分布式寫入，延遲在分鐘級，適合批量加載。

讀得快：基于 RowKey 的快速隨機訪問
行鍵索引：所有數據按 RowKey 全局排序，配合 Bloom Filter 快速判斷數據是否存在，減少磁盤掃描。
直接定位 Region：通過 RowKey 快速定位數據所在的 Region，避免全表掃描（例如 Get 操作時間復雜度接近 O(1)）。
讀方面，與HIVE對比

數據庫	寫入機制	速度特點
HBase	- 通過RowKey直接定位Region，利用MemStore和Block Cache加速讀取。- 支持隨機讀。	低延遲讀取：單行查詢為毫秒級，范圍掃描（Scan）性能取決于數據量和RowKey設計。
Hive	- 通過MapReduce/Tez/Spark執行全表掃描或復雜查詢。- 需解析文件格式（如ORC）。	高延遲讀取：復雜查詢通常需要分鐘到小時級，適合離線批處理分析。

2. ClickHouse

2.1 概念

ClickHouse 是一款開源的列式聯機分析處理（OLAP）數據庫，專為大規模數據分析和高速查詢設計。

2.2 特點

列式存儲與數據壓縮
列式存儲：數據按列存儲，相同數據類型連續存放，大幅提升壓縮率（如數值列壓縮率可達90%以上）。
高效壓縮算法：支持LZ4、ZSTD等算法，減少磁盤I/O和存儲成本。

向量化查詢執行引擎
利用CPU SIMD指令（單指令多數據），一次處理多行數據，提升批量計算效率。
例如：計算1億行數據的SUM，傳統逐行處理需1億次操作，向量化引擎可能僅需數百萬次操作。

分布式架構與并行計算
分片（Sharding）：數據水平拆分到多臺節點，支持橫向擴展。
副本（Replication）：通過ZooKeeper實現多副本容災（最終一致性）。

分布式查詢：查詢自動路由到相關分片，結果聚合后返回。
實時數據插入與批量導入
高吞吐寫入：支持每秒百萬級數據插入（適合日志、事件流）。
批量導入：通過INSERT SELECT、文件導入（如Parquet）快速加載數據。

2.3 橫向對比

維度	ClickHouse	HBase	Hive
存儲模型	列式存儲（針對分析優化）	列族存儲（半結構化數據）	行式/列式（依賴文件格式，如ORC）
查詢延遲	毫秒到秒級（OLAP場景）	毫秒級（單行查詢）	分鐘到小時級（批處理）
寫入吞吐	高吞吐批量寫入（適合日志流）	高吞吐實時寫入（適合事務日志）	低吞吐批量加載（ETL流程）
數據更新	支持批量更新（異步合并）	支持單行實時更新	僅支持覆蓋或分區更新
典型場景	實時分析、寬表聚合、時序數據	實時讀寫、在線查詢	離線數據倉庫、復雜ETL
SQL支持	完整SQL語法（兼容ANSI SQL）	無原生SQL，需API或Phoenix擴展	類SQL（HiveQL），支持復雜查詢

與 HBase 和 Hive 的協作模式：
HBase：作為實時數據接入層，處理高并發寫入和單行查詢。
ClickHouse：作為實時分析層，承載復雜聚合和即席查詢。
Hive：作為離線數據倉庫，處理歷史數據批量計算。