单行的强一致性的实现方式
- HBase 的操作粒度是 行（RowKey），一行的数据一定存放在同一个 RegionServer 上。
- 写入时先写 WAL 再写 MemStore，保证数据的持久性和一致性。
- 行级操作（Put/Delete/CheckAndPut/Increment）都是 原子性的。
- 内部通过 行锁（Row Lock） 避免并发冲突，从而实现单行的强一致性。
HBase 和 HDFS 的关系是什么？
可以这样理解：HBase 是建在 HDFS 之上的数据库，HDFS 是 HBase 的存储基础。
-
HDFS 提供分布式存储能力
- 把大文件切分成块（默认 128MB/256MB），分布在多个节点上，具备容错和高可用。
- 只支持 顺序读写、批处理，不支持随机读写。
-
HBase 基于 HDFS 实现数据库功能
- 把表数据存储为 HFile 文件放在 HDFS 上。
- 借助 HDFS 的分布式能力，实现水平扩展和海量数据存储。
- 在 HDFS 的顺序读写之上，HBase 提供了 随机、实时读写。
-
写入流程依赖 HDFS
- 数据先写 WAL（预写日志，存放在 HDFS），再写内存 MemStore。
- MemStore 刷写成 HFile，落盘到 HDFS，最终形成持久化存储。
-
容错与恢复
- HBase 不自己实现副本机制，而是依赖 HDFS 的副本机制（默认 3 副本）。
- 一旦 RegionServer 崩溃，可以从 HDFS 上的 WAL 和 HFile 恢复数据。
🔑 典型适用场景
-
海量数据存储
- 适合存储 TB~PB 级别的结构化或半结构化数据。
- 例如：电信行业的通话记录（CDR）、用户行为日志、广告点击流。
-
时序数据 / 监控数据
- RowKey 可设计为 时间戳+业务ID，支持按时间顺序快速写入与查询。
- 例如：物联网传感器数据、金融行情、应用监控指标（如 Prometheus 的长期存储）。
-
用户画像与推荐系统
- 存储大规模用户特征、行为数据，结合推荐算法进行实时查询。
- 例如：电商的商品点击/购买历史、视频平台的观影行为。
-
消息和日志存储
- 写多读少，要求写入高吞吐、持久化和按需检索。
- 例如：系统日志、访问日志、运维监控日志。
-
大数据平台底层存储
- 与 Hadoop、Spark、Hive、Phoenix 集成，作为大数据分析和实时查询的存储引擎。
- 例如：实时+离线混合的数仓架构。
hbase 不适用场景
- 强事务需求（如银行转账、电商订单支付） → 更适合用关系型数据库。
- 复杂 SQL 关联查询 → HBase 本身不支持 JOIN，需借助 Hive/Phoenix。
- 小规模数据场景 → 用 MySQL、PostgreSQL 更简单。
一句话总结：
HBase 适合 大数据量、高并发、实时读写 的场景，常用于 日志、时序数据、用户画像、IoT、推荐系统 等，而不适合 强事务、复杂关系查询 的传统 OLTP 业务。
好问题 👌，我来分步骤解释一下 HBase 的数据存储在 HDFS 上的过程和组织结构：
hbase 是如何存储在hdfs 上的
🔑 1. 存储单元划分
-
表（Table）：用户逻辑上的数据表。
-
Region：表按 RowKey 范围水平切分为多个 Region，每个 Region 存放在一个 RegionServer 上。
-
Store：一个 Region 按列族（Column Family）再划分为多个 Store。
-
HFile：每个 Store 最终存储为多个 HFile 文件，保存在 HDFS 上。
👉 层级关系：
Table → Region → Store(列族) → HFile
🔑 2. 写入流程
-
写 WAL（HLog，存在 HDFS 上）
- 先把写请求记录到预写日志，保证宕机时可恢复。
-
写入 MemStore（内存）
- 数据写到内存的 MemStore 中。
-
Flush 成 HFile（HDFS）
- 当 MemStore 达到阈值，会被刷写（flush）成一个 不可变的 HFile 存放到 HDFS。
🔑 3. HFile 文件组织
-
底层存储格式：HFile（类似 SSTable）
-
内容：
- Data Block：存放实际的 KeyValue（RowKey + ColumnFamily + Qualifier + Timestamp + Value）
- Index Block：加速查找
- Meta Block：存放元数据
- Trailer：存放文件整体信息
🔑 4. Compaction（合并机制）
-
随着不断写入，Region 下会产生很多小的 HFile。
-
HBase 会自动执行 Compaction（合并）：
- Minor Compaction：合并小文件 → 减少文件数量
- Major Compaction：合并所有文件，清理过期数据、删除标记
🔑 5. HDFS 的角色
- 数据存储：所有 WAL、HFile 文件最终存放在 HDFS 上。
- 容错机制：HDFS 提供多副本存储（默认 3 副本），保证数据安全。
- 分布式能力：数据分布在不同 DataNode 上，支持水平扩展。
✅ 一句话总结：
HBase 把表切分成 Region，Region 按列族存为多个 Store，每个 Store 最终由多个 HFile 文件保存在 HDFS，写入时先经过 WAL+MemStore，再刷写到 HDFS，依赖 HDFS 的副本和分布式存储实现可靠性和扩展性。
HBase 的写放大和读放大是什么意思？
🔑 1. 写放大（Write Amplification）
-
定义：一次用户写入操作，最终会导致 多次磁盘写入。
-
原因：
- 写入时，数据先写 WAL（HDFS 上），再写 MemStore（内存）。
- 当 MemStore 满了，会 Flush 成 HFile，落盘到 HDFS。
- 随着 HFile 越来越多，系统会执行 Compaction（文件合并），把多个小文件合并成大文件。
-
结果：
一条数据可能被写到磁盘 多次（Flush + 多轮 Compaction）。 -
影响：
- 增加了磁盘 IO 和存储压力。
- 但换来的是高写入吞吐量和有序存储。
🔑 2. 读放大（Read Amplification）
-
定义：一次用户读请求，可能需要访问 多个文件/存储位置 才能得到结果。
-
原因：
- 数据可能分布在 MemStore（内存）、多个 HFile（磁盘）、BlockCache（缓存） 中。
- 由于 HFile 按时间生成，最新数据可能在 MemStore，老数据在多个 HFile 中。
- 读操作需要同时查多个存储位置，并合并结果。
-
结果：
一次查询可能触发 多次 IO，增加查询延迟。 -
优化方式：
- 利用 BlockCache 缓存热点数据。
- 通过 Compaction 合并文件，减少 HFile 数量。
✅ 一句话总结
- 写放大：写一次数据，实际落盘多次（WAL、Flush、Compaction）。
- 读放大：读一次数据，可能查多个文件（MemStore + 多个 HFile + BlockCache）。
HBase 的数据删除流程是怎样的？
好问题 👍，HBase 的 删除并不是立刻物理删除，而是一个带有延迟清理的流程。
🔑 HBase 删除流程（Delete 操作）
1. 写入 Delete 标记（Tombstone）
- 当执行
Delete操作时，HBase 不会立刻删除数据。 - 它会写入一个特殊的 Tombstone 标记，表示某个单元格（Cell）或某行数据在逻辑上已被删除。
- Tombstone 也会像普通数据一样，先写入 WAL，再进入 MemStore，最后刷成 HFile。
2. 读取时的删除生效
- 当客户端读取数据时，RegionServer 会检查是否存在 Tombstone。
- 如果 Tombstone 覆盖了目标数据，则该数据不会返回给客户端（对外表现为已删除）。
3. Compaction 时物理删除
- Tombstone 本身和被删除的数据，依然存放在 HFile 中。
- 只有在 Major Compaction（主要合并）时，系统会真正把被 Tombstone 标记覆盖的数据清理掉，并删除对应的 Tombstone。
- 因此，真正的物理删除是 延迟发生 的。
4. 删除粒度
-
HBase 支持多种级别的删除：
- Delete Row：删除整行数据（所有列、所有版本）。
- Delete Column Family：删除某一列族的所有数据。
- Delete Column：删除某一列的所有版本。
- Delete Version：删除某一列的指定版本（时间戳）。
✅ 一句话总结
HBase 删除流程是：
先写入 Tombstone（逻辑删除） → 读时过滤掉数据 → Major Compaction 时真正物理清理。
