Haokang Mu

任务成功，数据为什么还是旧的？从调度依赖到数据就绪

hkmu9248@gmail.com (Haokang Mu) — Sun, 14 Sep 2025 08:00:00 +0800

日汇总任务显示成功，结果里的状态却还是昨天的；上游随后补齐数据，下游也没有自动变化。排查这种问题时，如果只看任务有没有报错，很容易错过真正的原因。

任务成功说明这次执行满足了程序和调度系统定义的成功条件。它是否读到了正确日期、正确版本且完整的数据，还要另外检查。

下面用订单与结算汇总构造一个例子。表名、时间和数量均为模拟数据，重点是看清链路中的判断条件。

1. 先把时间线画出来

假设每天生成前一天的订单日汇总，需要订单明细和结算明细两份输入。9 月 14 日这次运行应处理业务日期 2025-09-13。

时间	发生了什么	当时可以读取的数据
08:50	订单明细发布完成	9 月 13 日订单数据
09:00	日汇总启动	订单已齐，9 月 13 日结算数据还没发布
09:03	日汇总执行成功	输出中的部分结算状态为空
10:00	结算明细发布完成	9 月 13 日结算数据就绪

如果日汇总使用左关联，暂时没有匹配结算记录的订单仍然可以输出。SQL 不一定报错，行数甚至可能与昨天接近。

10 点以后，源表变了，已经落盘的日汇总通常不会随之重算。此时会同时看到“所有任务都是成功的”和“下游结果仍然不对”。

这里至少有三个不同的时间概念：业务数据属于哪一天、任务实际在什么时候执行、某个输入版本什么时候发布。排查时应分别记录，不能用任务启动时间代替业务日期。Airflow 的数据区间与逻辑日期也明确区分了这些概念：逻辑日期表示数据区间的起点，并非实际执行时间。官方说明

2. 把下游需要什么写成明确条件

“等上游好了再跑”不够具体。对这个日汇总，可以先约定四件事：

条件	需要回答的问题
业务范围正确	两个来源是否都覆盖目标业务日期？时区与业务日边界是否一致？
输入版本确定	下游读的是哪个已经发布的快照或批次？
来源齐备	订单、结算这两个必需来源是否都有就绪记录？
约定校验通过	记录数、业务主键、关键字段与对账结果是否满足约定？

有了这些条件，调度依赖才有了清楚的目标。跨工作流等待也要对应到需要的数据区间，不能只挑“最近一个成功实例”。Airflow 的 ExternalTaskSensor 可以等待另一个工作流在指定逻辑日期的任务状态，但仍需要把逻辑日期映射到本业务真正需要的输入。跨工作流依赖说明

这个例子把“订单、结算都必须就绪”作为发布要求。实际链路也可以允许部分来源晚到，但必须明确输出是否为暂定结果、如何标记缺失、什么时候修正。不能让使用者从一个普通的空值猜测是哪种情况。

3. 三个看似合理、实际不够的检查

分区存在，不代表装载完成。

任务可能先创建分区，再分批写入。下游一看到分区就读取，有机会读到空表或中间状态。更明确的方式是由上游发布完成标记，标记指向已经完成校验、可稳定读取的版本；下游读取那个版本，而不是一个还在变化的位置。

最新更新时间正常，不代表数据齐套。

假设本批应有 80 条记录，目前只有 50 条写入成功，其中一条更新时间是 09:59。MAX(updated_at) 看起来很新，却不能说明另外 30 条已经到达。时间指标适合检查新鲜度，覆盖度还需要来源清单、批次记录数或业务对账来验证。

结果为零，不一定是合法空批次。

没有权限、请求超时、日期条件写错、上游没有数据，都可能让调用方拿不到有效明细。先记录查询是否成功，再解释返回内容。只有来源明确声明该批次已经完成、预期记录数就是零，实际读取也为零，才符合本文的合法空批次约定。

4. 一个可运行的三态检查

检查结果分成三种：

PASS：约定的检查都有证据支持，可以继续使用这批输入。
BLOCK：已经发现不满足约定的事实，例如业务日期错误或装载未完成。
UNKNOWN：证据不足，例如查询失败，或者没有独立的预期记录数。

只有 PASS 才允许继续。BLOCK 与 UNKNOWN 都暂停消费，但后续动作不同：前者需要处理已知问题，后者需要补齐证据。如果两种情况同时存在，示例返回 BLOCK，同时保留所有原因。

示例为每个来源保存以下字段：

字段	含义
`business_date`	该快照对应的业务日期
`publish_state`	上游是否已经发布完成
`manifest_snapshot`	就绪清单声明的版本
`observed_snapshot`	本次实际读取的版本
`expected_rows`	来源清单独立提供的预期记录数
`observed_rows`	在指定版本中实际读到的记录数
`query_ok`	读取这个版本是否成功

这里的“独立”很重要。如果 expected_rows 也是对同一个不完整目标表执行 COUNT(*) 得到的，那么两者相等只是重复检查了同一份结果。

已经成功读取的清单和随后对数据的查询是两份证据。即使后者失败，清单中已知的日期错误或未发布状态也不能被丢掉。对每个来源，核心判断可以用下面的伪代码表示；遍历来源与汇总原因的实现见完整示例脚本：

# 先检查已经成功获得的清单证据，各项独立记录。
if snapshot.business_date != target_date:
    blocked.append("错误业务日期")
if snapshot.publish_state != "COMPLETE":
    blocked.append("批次还没有发布完成")
if not snapshot.manifest_snapshot:
    unknown.append("缺少清单版本号")
expected_valid = (
    snapshot.expected_rows is not None and snapshot.expected_rows >= 0
)
if not expected_valid:
    unknown.append("预期记录数不可用")

# 再检查数据；查询失败时保留前面已发现的问题。
if not snapshot.query_ok:
    unknown.append("数据查询失败")
else:
    if not snapshot.observed_snapshot:
        unknown.append("缺少读取版本号")
    elif (snapshot.manifest_snapshot
          and snapshot.manifest_snapshot != snapshot.observed_snapshot):
        blocked.append("清单与读取版本不一致")
    observed_valid = (
        snapshot.observed_rows is not None and snapshot.observed_rows >= 0
    )
    if not observed_valid:
        unknown.append("实际记录数不可用")
    elif expected_valid and snapshot.expected_rows != snapshot.observed_rows:
        blocked.append("记录数不符合约定")

status = "BLOCK" if blocked else "UNKNOWN" if unknown else "PASS"

下载脚本后直接运行，无需安装数据库或连接任何外部服务：

python3 data_readiness.py

本次使用 Python 3.9.6 验证，脚本只依赖标准库。输出如下，每个场景都包含结果断言：

ready: PASS
stale_partition: BLOCK
partition_created: BLOCK
partial_load: BLOCK
wrong_snapshot: BLOCK
missing_source: BLOCK
query_failed: UNKNOWN
empty_without_evidence: UNKNOWN
valid_empty_batch: PASS
mixed_evidence: BLOCK (both reasons retained)
same_source_mixed_evidence: BLOCK (all known reasons retained)
All 11 scenarios passed.

missing_source 的前提是完整查询了就绪清单，确认必需来源没有记录。如果查询清单本身失败，应直接得到 UNKNOWN，不能把失败包装成空清单。valid_empty_batch 通过的原因则是清单明确声明了零条，且对应版本已经发布完成。

最后一个场景中，同一来源的清单已经显示业务日期错误、批次未发布，随后读取数据又失败。因此结果为 BLOCK，同时保留查询失败的 UNKNOWN 原因；不会因为读数据失败就覆盖掉已经确认的问题。

这只是一个最小示例。行数一致也不能证明内容正确：少一条、多一条可能恰好抵消，还可能存在金额错误、错误主键或来源间截止时点不一致。根据业务继续增加唯一性、范围覆盖、关键字段和金额对账，并保证校验和消费使用同一版本，才不会在“检查通过”之后又读到另一批数据。

5. 修复时先恢复条件，再决定补跑范围

回到最初的时间线，把日汇总固定推迟到 10:30 可能暂时有效，但如果上游某天延迟到 11 点，同样的问题还会出现。固定时间可以作为等待上限或运行窗口，数据依赖和就绪条件仍然需要表达清楚。

更稳妥的处理顺序是：

确认日汇总实际消费的业务日期、版本和来源，圈定受影响的输出。
修正依赖关系或就绪检查，确保后续运行不会再次提前消费。
等上游目标版本发布并校验通过，判断日汇总及其下游哪些结果需要重算。
明确重算是覆盖分区、按业务键合并还是追加写入，避免一次修复造成新的重复。
验证最终消费层，包括已生成的导出文件或缓存；只看重跑实例成功还不够。

能否重复执行而不改变正确结果，是补跑前需要回答的问题。如果一个任务采用直接追加写入，就不能默认重跑一次只是“刷新一下”。

数据链路的检查最终要落到一个具体问题：下游这次需要的那份数据，现在是否可以被稳定、完整地读取？ 任务状态、分区、时间戳和记录数都是证据的一部分，把它们放在同一个业务日期和版本下核对，判断才有意义。

本文为历史专题补记，按 2025-09-14 归档，于 2026-10-29 整理并验证示例。

去重不是 DISTINCT：业务主键、历史事件与最新状态

hkmu9248@gmail.com (Haokang Mu) — Sun, 16 Jun 2024 08:00:00 +0800

处理一张不断追加的事件表时，“按订单去重”听起来很明确，真正写 SQL 才会发现：重复到达的消息、同一订单的不同版本、取消后新建的订单，可能全挤在一张表里。

这些记录都能让订单号重复，但处理方式不同。把它们统一压成一行，行数可能变少，结果却未必正确。

下面用一组模拟订单说明三个问题：什么算同一件事，什么算同一个对象，以及哪条记录代表最新状态。 本文的指标是“当前有效订单数与金额”，不涉及收入确认、回款或结算。

1. 先写清楚三种粒度

假设订单状态变化时，上游会产生一条带完整状态的事件。这个案例约定：

要回答的问题	使用的键	说明
这是不是同一个订单？	`tenant_id + order_id`	订单号只在租户内部唯一
这是不是同一次事件的重放？	`tenant_id + event_id`	同一事件可能投递多次，事件编号保持不变
哪个状态更新？	订单内的 `source_version`	来源系统提供递增版本，每个版本对应一个完整状态

另有一个 request_id，表示订单来自哪个业务申请。旧订单取消后，可以在同一申请下新建订单，所以它不能直接代替订单主键。

这个区分决定了处理顺序：先识别重复投递，再保留不同状态版本，最后根据查询目的生成当前状态表。事件明细与当前状态表可以同时存在，各自服务不同的问题。

2. 准备一组会暴露问题的数据

模拟数据包含 10 条到达记录，分别覆盖下面的情况。ACTIVE 表示有效，CANCELLED 表示取消。

订单	金额	状态变化	特殊情况
T1 / O100	100	v1 有效 → v2 取消	v2 事件重复投递一次
T1 / O101	100	v1 有效	和 O100 来自同一申请 R100，是取消后新建的另一笔订单
T1 / O200	80	v1 有效 → v2 取消	v1 在 11:30 才到达，晚于 11:10 到达的 v2
T1 / O300	50	v1 有效 → v2 取消 → v3 有效	v2、v3 的业务时间都记为 12:05:00
T2 / O100	200	v1 有效	与 T1 的订单号相同，租户不同

全量到达后，预期有效订单是 T1/O101、T1/O300、T2/O100，共 3 笔，金额 350。取消的 O100 和 O200 仍然保留在状态表中，只是不参与这个指标。

完整建表、数据与断言放在可运行示例里。下载文件后可以在独立环境运行：

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install "duckdb==1.4.5"
python3 dedup_and_latest_state.py

本次使用 Python 3.9.6、DuckDB 1.4.5 验证。这是本次补记的验证环境，不代表 2024 年使用过这些版本。数据和查询都在内存中运行，不连接外部数据库。

3. 先处理事件重放

O100 的取消事件 E02 到达了两次，业务字段相同，ingested_at 不同。直接执行 SELECT DISTINCT *，仍然得到 10 行，因为到达时间也是参与比较的字段。

如果按事件幂等键处理，则应该留下 9 个逻辑事件。但在保留某一条之前，要先确认同一个事件编号没有对应不同内容：

SELECT tenant_id, event_id
FROM (
    SELECT DISTINCT tenant_id, event_id, order_id, request_id,
           source_version, status, amount, event_time
    FROM raw_events
) AS payloads
GROUP BY tenant_id, event_id
HAVING COUNT(*) > 1;

这条检查应返回空集。它刻意不比较 ingested_at，因为重复投递允许有不同的到达时间。这里列出的字段构成了示例的完整业务载荷；真实事件还有其他业务字段时，也必须纳入一致性检查。

检查通过后，再按事件编号保留第一次到达：

CREATE VIEW events AS
SELECT tenant_id, event_id, order_id, request_id,
       source_version, status, amount, event_time, ingested_at
FROM (
    SELECT *, ROW_NUMBER() OVER (
        PARTITION BY tenant_id, event_id
        ORDER BY ingested_at ASC
    ) AS replay_rank
    FROM raw_events
) AS ranked
WHERE replay_rank = 1;

这里选择第一次到达，只是为了保留一个代表记录。同一事件的业务载荷已经检查为一致，即使两次到达时间也相同，选中哪份副本都不影响业务状态。

如果一个事件编号出现两种金额或状态，应先隔离冲突并核对来源。任取一条会隐藏问题。上游没有稳定事件编号时，也不能把包含到达时间的整行哈希直接当成幂等键，否则同一事件重放后仍会变成“新事件”。

4. 再为每个订单选最新状态

事件去重后，一笔订单仍然可以有多个版本。这是应该保留的历史。

本例中，来源系统承诺每个订单的版本递增，且一个版本只代表一个逻辑事件。先检查这个约定：

SELECT tenant_id, order_id, source_version
FROM events
GROUP BY tenant_id, order_id, source_version
HAVING COUNT(*) > 1;

检查通过后，按完整订单主键分组、来源版本倒序，就能得到唯一的最新状态：

CREATE VIEW latest_state AS
SELECT tenant_id, order_id, request_id, source_version, status, amount
FROM (
    SELECT *, ROW_NUMBER() OVER (
        PARTITION BY tenant_id, order_id
        ORDER BY source_version DESC
    ) AS state_rank
    FROM events
) AS ranked
WHERE state_rank = 1;

这里的排序能够确定结果，是因为前置检查和来源约定保证了订单内的版本唯一。ROW_NUMBER() 本身不会替我们判断两个冲突版本谁更可信。它按窗口中的分组和排序规则编号，具体语义可以查阅 DuckDB 窗口函数文档。

如果同一版本对应两个不同状态，补一个 event_id DESC 虽然能让结果看起来稳定，却不能证明选中的状态正确。应先解决版本冲突；如果来源只有秒级时间，没有可靠版本或顺序，需要明确额外的排序依据，或者把这批记录标记为顺序不确定。

5. 先取最新，再过滤有效状态

得到 latest_state 后，指标计算很直接：

SELECT COUNT(*) AS active_orders, SUM(amount) AS active_amount
FROM latest_state
WHERE status = 'ACTIVE';

结果是 3 / 350.00。如果把状态条件提前放进窗口计算内部，含义就变了：

-- 错误示例：计算的是“最近一次有效”，不是“最新状态有效”。
SELECT tenant_id, order_id, source_version, amount
FROM (
    SELECT *, ROW_NUMBER() OVER (
        PARTITION BY tenant_id, order_id
        ORDER BY source_version DESC
    ) AS state_rank
    FROM events
    WHERE status = 'ACTIVE'
) AS ranked
WHERE state_rank = 1;

取消记录在排名之前就被删掉了，O100 和 O200 以前的有效版本重新排到第一名，最后错误地得到 5 笔、530.00。

两个问题都可以有业务意义：“最近一次有效时是什么状态”和“当前是否有效”。但需要先确定正在回答哪一个，不能只看 SQL 是否去重成功。

DISTINCT 的作用同样取决于投影字段。SELECT DISTINCT tenant_id, order_id, status 可以列出不同状态组合，却没有表达哪种状态更晚。关于 DISTINCT 如何比较结果行，可参考 DuckDB SELECT 文档。

6. 三个容易被样例掩盖的边界

到达晚，不等于状态新。 O200 的 v1 比 v2 晚到 20 分钟。如果按 ingested_at DESC 取最新，订单会从取消退回有效，结果变成 4 笔、430.00。event_time 表达事件发生时间，ingested_at 表达到达时间，source_version 表达本例来源系统的状态顺序，三者不能随意互换。

取消后重建，可能是新的业务对象。 O100 与 O101 共享申请号 R100，但订单号不同。是否需要在申请层再合并，是另一个统计口径，不能在订单明细层顺手按 request_id 删除一笔。本例也保留了两个租户的 O100，避免因为省略租户键而合并不同对象。

状态可以反复，不能默认取消就是最终状态。 O300 的 v2 取消后，v3 又变为有效。这里模拟的业务规则允许恢复，因此应保留 v3；其他系统可能禁止这种转移，需要按它自己的状态机检查。仅按 12:05:00 排序，无法区分本例的 v2 和 v3，可信版本才提供了先后关系。

对于增量处理，还要把新事件与已有状态比较。来源版本较旧的晚到数据不能覆盖更高版本；事件明细可以追加，当前状态也可以保持不变。跨来源合并时，如果版本只在各自来源内有效，就需要把来源范围纳入键或明确冲突规则，不能直接比较两个系统的数字大小。

7. 把结果和反例一起验证

示例脚本实际运行得到：

计算方法	结果
原始记录 / 整行 DISTINCT / 事件幂等去重	10 / 10 / 9 行
先取最新状态，再筛有效订单	3 笔 / 350.00
先筛有效，再取最新	5 笔 / 530.00
把最近到达当成最新状态	4 笔 / 430.00

脚本还验证了四个变化：再次重放同一事件不会改变指标；同一事件编号出现不同载荷会被检测出来；同一订单版本出现冲突事件会被检测出来；晚到的旧版本不会把正确状态回退。

这套方法依赖完整、可信的版本信息。本例的事件携带完整状态；如果输入是只包含变化字段的增量补丁，还需要按顺序还原状态，不能直接选最后一行。这里说的“当前”，也只是本次已收齐数据范围内的最新状态；上游尚有缺数时，应说明观测截止时间，不能把未到达当成不存在。

写去重逻辑时，先写下实体键、事件键和版本规则，再分别检查输入、历史和输出。这样行数变化才有明确含义，也更容易定位究竟是重复投递、状态变化，还是来源数据出了问题。

本文为历史专题补记，按 2024-06-16 归档，于 2026-10-29 整理并验证示例。

SQL 没有报错，金额为什么多算了？从数据粒度到 JOIN 放大

hkmu9248@gmail.com (Haokang Mu) — Sun, 12 Nov 2023 08:00:00 +0800

一条 SQL 跑完了，行数也没有大得离谱，但汇总金额就是对不上。遇到这种情况，可以先把 SUM 放到一边，回答一个问题：执行到这一步时，一行数据究竟代表什么？

订单表的一行是一笔订单，明细表的一行是一项商品，附件表的一行是一个文件。把三张表关联起来以后，结果中的一行可能已经变成“某笔订单的一项商品与一个附件的组合”。此时继续累加订单金额，就会把同一个金额算多次。

下面用一个可以直接运行的小例子，把这个过程拆开看。数据全部为模拟数据，不涉及实际业务系统。

1. 先把要统计的对象说清楚

需求是：按区域统计至少有一个附件的订单数量、订单金额，以及这些订单的商品明细金额。

这里有三个边界：

统计对象是订单，每笔订单只计一次。
“有附件”是筛选条件，不要求把每个附件展开到结果里。
商品明细金额要先按订单汇总，才能和订单金额放到同一行。

先看输入数据。orders 每笔订单一行，主键是 order_id：

order_id	region	order_amount
101	north	100.00
102	north	100.00
103	south	80.00

order_items 每个明细一行，主键是 item_id。这里的 item_amount 已经是该明细的金额，不是单价：

item_id	order_id	item_amount
11	101	60.00
12	101	40.00
21	102	100.00
31	103	80.00

attachments 每个附件一行，主键是 attachment_id：

attachment_id	order_id
1	101
2	101
3	102

全部订单金额是 280 元，但订单 103 没有附件，不在本次统计范围内。因此，正确结果应当是：north 区域有 2 笔订单，订单金额 200 元，明细金额也是 200 元。

280 和 200 的差异来自筛选范围，不能直接当成数据丢失。 对账前必须先对齐统计对象。

2. 直接关联，金额在哪一步变多了

下面这条 SQL 很容易写出来：

SELECT o.region,
       COUNT(*) AS joined_rows,
       COUNT(DISTINCT o.order_id) AS order_count,
       SUM(o.order_amount) AS order_amount,
       SUM(i.item_amount) AS item_amount
FROM orders o
JOIN order_items i ON o.order_id = i.order_id
JOIN attachments a ON o.order_id = a.order_id
GROUP BY o.region
ORDER BY o.region;

执行结果：

region	joined_rows	order_count	order_amount	item_amount
north	5	2	500.00	300.00

订单数看起来是对的，两个金额却都错了。把聚合之前的数据展开，就能看到原因：

order_id	item_id	attachment_id	order_amount	item_amount
101	11	1	100.00	60.00
101	11	2	100.00	60.00
101	12	1	100.00	40.00
101	12	2	100.00	40.00
102	21	3	100.00	100.00

订单 101 有 2 个明细和 2 个附件。两个关联都只按订单号匹配，所以它产生了 2 × 2 = 4 行。

订单金额被重复 4 次，变成 400 元；两个明细也分别被重复 2 次，合计变成 200 元。再加上订单 102，就得到了 500 和 300。

对于这种两个子表独立按同一订单键进行的内连接，一笔订单有 m 个明细和 n 个附件，就会形成 m × n 个组合。这不是子表本身一定有脏数据，而是关联后的粒度变了。如果关联条件还包含明细号，或者增加了其他过滤条件，则要按实际匹配关系重新分析，不能机械地套乘法。

COUNT(DISTINCT order_id) 只修正了订单数量，无法同时修正 SUM。这也是为什么只核对订单数不够。

3. 为什么补一个 DISTINCT 还不够

一种尝试是把金额改成：

SUM(DISTINCT o.order_amount)

结果会变成 100 元。因为订单 101 和 102 的金额恰好都为 100，DISTINCT 消除的是相同的金额值，并不知道它们来自两笔不同订单。

另一种写法是在聚合结果外加 SELECT DISTINCT。但 GROUP BY region 已经得到一行 north，金额在聚合时就算成了 500，外层去重不能把错误的总额还原。

当然，先选出唯一的 (order_id, order_amount) 再汇总，在订单号确实唯一决定金额的前提下，也可以恢复订单粒度。关键在于选出的列是否都属于同一笔订单；一旦继续携带 item_id 或 attachment_id，结果仍然会展开。

所以要先明确需要保留的记录，再决定如何去重。

4. 只判断是否存在，就使用 EXISTS

如果只要订单数和订单金额，根本不需要关联商品明细。附件只负责判断这笔订单是否进入统计范围：

SELECT o.region,
       COUNT(*) AS order_count,
       SUM(o.order_amount) AS order_amount
FROM orders o
WHERE EXISTS (
    SELECT 1 FROM attachments a
    WHERE a.order_id = o.order_id
)
GROUP BY o.region
ORDER BY o.region;

结果为 north / 2 / 200.00。同一订单有几个匹配附件，都只决定 EXISTS 是否成立，不会把左侧订单展开。

DuckDB 的 JOIN 文档说明了半连接的语义：保留左侧存在匹配的行。Spark SQL 也提供 LEFT SEMI JOIN。这里选择 EXISTS 表达筛选目的；本文实际执行环境是 DuckDB，没有据此推断其他引擎的性能。

需要注意，EXISTS 也不会替左表去重。如果订单表本身有同一订单的多个版本，必须先确定要使用哪个版本。

5. 需要右表指标，就先对齐粒度

完整需求还包含商品明细金额，可以先把商品明细聚合到订单粒度，再关联订单表：

WITH item_total AS (
    SELECT order_id, SUM(item_amount) AS item_amount
    FROM order_items
    GROUP BY order_id
)
SELECT o.region,
       COUNT(*) AS order_count,
       SUM(o.order_amount) AS order_amount,
       SUM(i.item_amount) AS item_amount,
       SUM(CASE WHEN i.order_id IS NULL THEN 1 ELSE 0 END) AS missing_item_orders
FROM orders o
LEFT JOIN item_total i ON o.order_id = i.order_id
WHERE EXISTS (
    SELECT 1 FROM attachments a
    WHERE a.order_id = o.order_id
)
GROUP BY o.region
ORDER BY o.region;

结果：

region	order_count	order_amount	item_amount	missing_item_orders
north	2	200.00	200.00	0

这次的处理顺序是：商品明细按订单聚合，每个订单最多一行；再和订单表关联；用附件筛选订单；最后按区域汇总。

missing_item_orders 是特意保留的检查项。假设再加入一笔金额为 50 元、有附件但没有商品明细的订单 104，查询会得到：

region	order_count	order_amount	item_amount	missing_item_orders
north	3	250.00	200.00	1

这个结果没有把缺明细的订单悄悄过滤掉，但也不能直接认定两个金额都完整。是否允许缺明细，需要由统计口径决定。

在完整性尚未确认时，直接把缺失明细金额填成 0，会掩盖“没有取到数据”和“金额确实为零”的区别。另外，SUM 会忽略 NULL；没有任何匹配订单时，这条带 GROUP BY 的查询返回空结果，并不自动生成一行零值。这些情况都要单独处理。

6. 换成真实数仓时，还要检查什么

这个例子省略了租户、来源系统、业务日期和币种。实际使用时，至少要补齐以下判断：

关联键是不是完整业务键。 订单号可能只在某个来源或租户内唯一，不能默认全局唯一。
两侧是否使用同一个统计范围。 明细取最新快照、主表取历史快照，会带来另一类不一致。
聚合后是否真的唯一。 如果要按 (租户, 订单号) 关联，预聚合也必须保留这组键。
过滤条件是否改变保留范围。 LEFT JOIN 后在 WHERE 中要求右侧字段等于某值，会排除右侧缺失的记录。
金额是否具有可加性。 本例使用相同币种，并约定明细金额可直接相加。折扣、税额、退款和币种换算需要另行定义。

排查时可以在每次关联后同时记录行数、唯一业务键数量、未匹配数量和关键金额。先定位是哪一步改变了粒度，再判断这个变化是否符合需求。只看最终总数，通常不容易找到问题出在哪里。

7. 运行本文示例

下载完整 Python 示例，其中包含建表、插入数据、错误写法、修复写法和结果断言。金额使用 DECIMAL(12, 2)。

在下载目录中执行：

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install duckdb==1.4.5
python3 sql_join_grain.py

本次验证使用 Python 3.9.6、DuckDB 1.4.5。脚本会检查金额 500/300 的错误结果、SUM(DISTINCT) 得到 100 的反例、修复后的 200/200，以及缺明细和无符合条件订单的情况。全部断言通过后输出 PASS。这些小数据验证用于说明计算语义，不是分布式引擎的性能测试。

继续阅读：去重与最新状态、调度与数据就绪。

本文为历史专题补记，按 2023-11-12 归档，于 2026-10-29 整理并验证示例。文中的运行环境版本对应本次验证时间。

Prometheus概述

hkmu9248@gmail.com (Haokang Mu) — Thu, 05 May 2022 00:00:00 +0800

1. Prometheus 的特点

Prometheus 是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。相比于传统监控系统，Prometheus 具有以下优点：

1.1 易于管理

Prometheus 核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。
Prometheus 基于 Pull 模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。
对于一些复杂的情况，还可以使用 Prometheus 服务发现(Service Discovery)的能力动态管理监控目标。
1.2 监控服务的内部运行状态

Pometheus 鼓励用户监控服务的内部状态，基于 Prometheus 丰富的 Client 库，用户可以轻松的在应用程序中添加对 Prometheus 的支持，从而让用户可以获取服务和应用内部真正的运行状态。

1.3 强大的数据模型

所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中 (TSDB)。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。如下所示：
```
http_request_status{code='200',content_path='/api/path',environment='produment'} => 
[value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2',environment='produment'} => 
[value1@timestamp1,value2@timestamp2...]
```
每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。
http_request_status：指标名称(Metrics Name)
{code=’200’,content_path=’/api/path’,environment=’produment’}：表示维度的标签，基于这些 Labels 我们可以方便地对监控数据进行聚合，过滤，裁剪。
[value1@timestamp1,value2@timestamp2…]：按照时间的先后顺序存储的样本值。
1.4 强大的查询语言 PromQL

Prometheus 内置了一个强大的数据查询语言 PromQL。通过 PromQL 可以实现对监控数据的查询、聚合。同时 PromQL 也被应用于数据可视化(如 Grafana)以及告警当中。通过 PromQL 可以轻松回答类似于以下问题：
在过去一段时间中 95%应用延迟时间的分布范围？
预测在 4 小时后，磁盘空间占用大致会是什么情况？
CPU 占用率前 5 位的服务有哪些？(过滤)
1.5 高效

对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而 Prometheus 可以高效地处理这些数据，对于单一 Prometheus Server 实例而言它可以处理：
数以百万的监控指标
每秒处理数十万的数据点
1.6 可扩展

可以在每个数据中心、每个团队运行独立的 Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。

1.7 易于集成

使用 Prometheus 可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持：Java，JMX，Python，Go，Ruby，.Net，Node.js 等等语言的客户端 SDK，基于这些 SDK 可以快速让应用程序纳入到 Prometheus 的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持 Prometheus，还能支持 Graphite 这些其他的监控工具。同时 Prometheus 还支持与其他的监控系统进行集成：Graphite，Statsd，Collected，Scollector， muini， Nagios 等。 Prometheus 社区还提供了大量第三方实现的监控数据采集支持：JMX，CloudWatch，EC2，MySQL，PostgresSQL，Haskell，Bash，SNMP，Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，RethinkDB，Rsyslog 等等。

1.8 可视化
Prometheus Server 中自带的 Prometheus UI，可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时 Prometheus 还提供了一个独立的基于 Ruby On Rails 的 Dashboard 解决方案 Promdash。
最新的 Grafana 可视化工具也已经提供了完整的 Prometheus 支持，基于 Grafana 可以创建更加精美的监控图标。
基于 Prometheus 提供的 API 还可以实现自己的监控可视化 UI。
1.9 开放性

通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持，因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制，对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。而对于 Prometheus 来说，使用 Prometheus 的 client library 的输出格式不止支持 Prometheus 的格式化数据，也可以输出支持其它监控系统的格式化数据，比如 Graphite。因此你甚至可以在不使用 Prometheus 的情况下，采用 Prometheus 的 client library 来让你的应用程序支持监控数据采集。

2. Prometheus 的架构

2.1 Prometheus 生态圈组件

Prometheus Server：主服务器，负责收集和存储时间序列数据
client libraies：应用程序代码插桩，将监控指标嵌入到被监控应用程序中
Pushgateway：推送网关，为支持 short-lived 作业提供一个推送网关
exporter：专门为一些应用开发的数据摄取组件—exporter，例如：HAProxy、StatsD、Graphite 等等。
Alertmanager：专门用于处理 alert 的组件
2.2 架构理解

Prometheus 既然设计为一个维度存储模型，可以把它理解为一个 OLAP 系统。

1、存储计算层
Prometheus Server，里面包含了存储引擎和计算引擎。
Retrieval 组件为取数组件，它会主动从 Pushgateway 或者 Exporter 拉取指标数据。
Service discovery，可以动态发现要监控的目标。
TSDB，数据核心存储与查询。
HTTP server，对外提供 HTTP 服务。
2、采集层

采集层分为两类，一类是生命周期较短的作业，还有一类是生命周期较长的作业。
短作业：直接通过 API，在退出时间指标推送给 Pushgateway。
长作业：Retrieval 组件直接从 Job 或者 Exporter 拉取数据。
3、应用层

应用层主要分为两种，一种是 AlertManager，另一种是数据可视化。
AlertManager

对接 Pagerduty，是一套付费的监控报警系统。可实现短信报警、5 分钟无人 ack 打电话通知、仍然无人 ack，通知值班人员 Manager… Emial，发送邮件 … …

数据可视化

Prometheus build-in WebUI Grafana 其他基于 API 开发的客户端

3. Prometheus 的安装

3.1 安装 Prometheus Server

Prometheus 基于 Golang 编写，编译后的软件包，不依赖于任何的第三方依赖。只需要下载对应平台的二进制包，解压并且添加基本的配置即可正常启动 Prometheus Server。

3.1.1 修改配置文件 prometheus.yml

scrape_configs:

  - job_name: 'prometheus'
    static_configs:
    - targets: ['hadoop202:9090']

# 添加 PushGateway 监控配置
  - job_name: 'pushgateway'
    static_configs:
    - targets: ['hadoop102:9091']
      labels:
      instance: pushgateway

# 添加 Node Exporter 监控配置
  - job_name: 'node exporter'
    static_configs:
    - targets: ['hadoop102:9100', 'hadoop103:9100', 'hadoop104:9100']

配置说明： 1、global 配置块：控制 Prometheus 服务器的全局配置

scrape_interval：配置拉取数据的时间间隔，默认为 1 分钟。
evaluation_interval：规则验证（生成 alert）的时间间隔，默认为 1 分钟。

2、rule_files 配置块：规则配置文件 3、scrape_configs 配置块：配置采集目标相关， prometheus 监视的目标。Prometheus 自身的运行信息可以通过 HTTP 访问，所以 Prometheus 可以监控自己的运行数据。

job_name：监控作业的名称
static_configs：表示静态目标配置，就是固定从某个 target 拉取数据
targets ：指定监控的目标，其实就是从哪儿拉取数据。 Prometheus 会从

http://hadoop102:9090/metrics 上拉取数据。 Prometheus 是可以在运行时自动加载配置的。启动时需要添加：–web.enable-lifecycle

3.2 安装 Pushgateway

Prometheus 在正常情况下是采用拉模式从产生 metric 的作业或者 exporter（比如专门监控主机的 NodeExporter）拉取监控数据。但是我们要监控的是 Flink on YARN 作业，想要让 Prometheus 自动发现作业的提交、结束以及自动拉取数据显然是比较困难的。 PushGateway 就是一个中转组件，通过配置 Flink on YARN 作业将 metric 推到 PushGateway，Prometheus 再从 PushGateway 拉取就可以了。

3.3 安装 Node Exporter（选择性安装）

在 Prometheus 的架构设计中，Prometheus Server 主要负责数据的收集，存储并且对外提供数据查询支持，而实际的监控样本数据的收集则是由 Exporter 完成。因此为了能够监控到某些东西，如主机的 CPU 使用率，我们需要使用到 Exporter。Prometheus 周期性的从 Exporter 暴露的 HTTP 服务地址（通常是/metrics）拉取监控样本数据。 Exporter 可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外，也可以是直接内置在监控目标中。只要能够向 Prometheus 提供标准格式的监控样本数据即可。为了能够采集到主机的运行指标如 CPU, 内存，磁盘等信息。我们可以使用 Node Exporter。Node Exporter 同样采用 Golang 编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。可以从 https://prometheus.io/download/ 获取最新的 node exporter 版本的二进制包。

启动并通过页面查看是否成功执行./node_exporter 浏览器输入：http://hadoop102:9100/metrics，可以看到当前 node exporter 获取到的当前主机的所有监控数据。

3.3.1 节点分发

将解压后的目录分发到要监控的节点

xsync node_exporter-1.2.2

修改 Prometheus 配置文件 prometheus.yml，在之前已经添加过配置

- targets: ['hadoop202:9100', 'hadoop203:9100', 'hadoop204:9100']

3.3.2 设置为开机自启

创建 service 文件

sudo vim /usr/lib/systemd/system/node_exporter.service

[Unit]
Description=node_export
Documentation=https://github.com/prometheus/node_exporter
After=network.target

[Service]
Type=simple
User=mhk
ExecStart= /opt/module/node_exporter-1.2.2/node_exporter
Restart=on-failure

[Install]
WantedBy=multi-user.target

分发文件

sudo /home/atguigu/bin/xsync /usr/lib/systemd/system/node_exporter.service

设为开机自启动（所有机器都执行）

sudo systemctl enable node_exporter.service

启动服务（所有机器都执行）

sudo systemctl start node_exporter.service

3.4 安装 Alertmanager（选择性安装）

3.4.1 上传安装包

上传 alertmanager-0.23.0.linux-amd64.tar.gz 到虚拟机的/opt/software 目录

3.4.2 解压安装包

解压到/opt/module 目录下

3.5 启动 Prometheus Server 、 Pushgateway 和 Alertmanager

3.5.1 Prometheus Server 目录下执行启动命令

[mhk@hadoop102 prometheus-2.29.1]$ nohup ./prometheus --config.file=prometheus.yml > ./prometheus.log 2>&1 &

3.5.2 Pushgateway 目录下执行启动命令

[mhk@hadoop102 pushgateway-1.4.1]$ nohup ./pushgateway --web.listen-address :9091 > ./pushgateway.log 2>&1 & 

3.5.3 在 Alertmanager 目录下启动

[mhk@hadoop102 alertmanager-0.23.0]$ nohup ./alertmanager --config.file=alertmanager.yml > ./alertmanager.log 2>&1 & 

3.5.4 打开 web 页面查看

浏览器输入：http://hadoop202:9090/
点击 Status，选中 Targets：

prometheus、pushgateway 和 node exporter 都是 up 状态，表示安装启动成功：

ClickHouse高级

hkmu9248@gmail.com (Haokang Mu) — Sat, 23 Apr 2022 00:00:00 +0800

1.Explain 查看执行计划

在 clickhouse 20.6 版本之前要查看 SQL 语句的执行计划需要设置日志级别为 trace 才能可以看到，并且只能真正执行 sql，在执行日志里面查看。在 20.6 版本引入了原生的执行计划的语法。在 20.6.3 版本成为正式版本的功能。 本文档基于目前较新稳定版 21.7.3.14。

1.1 基本语法

EXPLAIN [AST | SYNTAX | PLAN | PIPELINE] [setting = value, ...] 
SELECT ... [FORMAT ...] 

PLAN：用于查看执行计划，默认值。

◼ header 打印计划中各个步骤的 head 说明，默认关闭，默认值 0; ◼ description 打印计划中各个步骤的描述，默认开启，默认值 1； ◼ actions 打印计划中各个步骤的详细信息，默认关闭，默认值 0。

AST ：用于查看语法树;
SYNTAX：用于优化语法;
PIPELINE：用于查看 PIPELINE 计划。

◼ header 打印计划中各个步骤的 head 说明，默认关闭; ◼ graph 用 DOT 图形语言描述管道图，默认关闭，需要查看相关的图形需要配合 graphviz 查看； ◼ actions 如果开启了 graph，紧凑打印打，默认开启。 注：PLAN 和 PIPELINE 还可以进行额外的显示设置，如上参数所示。

1.2 案例实操

**1.2.1 新版本使用 EXPLAIN ** 可以再安装一个 20.6 以上版本，或者直接在官网的在线 demo，选择高版本进行测试。官网在线测试链接：https://play.clickhouse.tech/?file=welcome

1）查看 PLAIN 简单查询

EXPLAIN
SELECT arrayJoin([1, 2, 3, NULL, NULL])

Query id: 8c3ab78b-7147-439e-814e-72c583ba1c2f

Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.7.3 revision 54449.

┌─explain───────────────────────────────────────────────────────────────────┐
│ Expression ((Projection + Before ORDER BY))                               │
│   SettingQuotaAndLimits (Set limits and quota after reading from storage) │
│     ReadFromStorage (SystemOne)                                           │
└───────────────────────────────────────────────────────────────────────────┘

复杂 SQL 的执行计划

EXPLAIN
SELECT
    database,
    table,
    count(1) AS cnt
FROM system.parts
WHERE database IN ('datasets', 'system')
GROUP BY
    database,
    table
ORDER BY
    database ASC,
    cnt DESC
LIMIT 2 BY database

Query id: bd17ac72-99e6-4675-9c50-f5a5d7b2d76e

┌─explain─────────────────────────────────────────────────────────────────────────────────────┐
│ Expression (Projection)                                                                     │
│   LimitBy                                                                                   │
│     Expression (Before LIMIT BY)                                                            │
│       MergingSorted (Merge sorted streams for ORDER BY)                                     │
│         MergeSorting (Merge sorted blocks for ORDER BY)                                     │
│           PartialSorting (Sort each block for ORDER BY)                                     │
│             Expression (Before ORDER BY)                                                    │
│               Aggregating                                                                   │
│                 Expression (Before GROUP BY)                                                │
│                   Filter (WHERE)                                                            │
│                     SettingQuotaAndLimits (Set limits and quota after reading from storage) │
│                       ReadFromStorage (SystemParts)                                         │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

打开全部的参数的执行计划

EXPLAIN header = 1, actions = 1, description = 1
SELECT number
FROM system.numbers
LIMIT 10

Query id: 633e53c2-573c-450c-8137-554b79b9110b

Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.7.3 revision 54449.

┌─explain───────────────────────────────────────────────────────────────────┐
│ Expression ((Projection + Before ORDER BY))                               │
│ Header: number UInt64                                                     │
│ Actions: INPUT :: 0 -> number UInt64 : 0                                  │
│ Positions: 0                                                              │
│   SettingQuotaAndLimits (Set limits and quota after reading from storage) │
│   Header: number UInt64                                                   │
│     Limit (preliminary LIMIT)                                             │
│     Header: number UInt64                                                 │
│     Limit 10                                                              │
│     Offset 0                                                              │
│       ReadFromStorage (SystemNumbers)                                     │
│       Header: number UInt64                                               │
└───────────────────────────────────────────────────────────────────────────┘

2）AST 语法树

EXPLAIN AST
SELECT number
FROM system.numbers
LIMIT 10

Query id: af4f359b-c72e-41e7-b1f4-477d87597458

┌─explain─────────────────────────────────────┐
│ SelectWithUnionQuery (children 1)           │
│  ExpressionList (children 1)                │
│   SelectQuery (children 3)                  │
│    ExpressionList (children 1)              │
│     Identifier number                       │
│    TablesInSelectQuery (children 1)         │
│     TablesInSelectQueryElement (children 1) │
│      TableExpression (children 1)           │
│       TableIdentifier system.numbers        │
│    Literal UInt64_10                        │
└─────────────────────────────────────────────┘

3）SYNTAX 语法优化先做一次查询

SELECT if(number = 1, 'hello', if(number = 2, 'world', 'mhk'))
FROM numbers(10)

Query id: f17854b0-61ca-4d25-961a-567db0fba1e7

┌─if(equals(number, 1), 'hello', if(equals(number, 2), 'world', 'mhk'))─┐
│ mhk                                                                   │
│ hello                                                                 │
│ world                                                                 │
│ mhk                                                                   │
│ mhk                                                                   │
│ mhk                                                                   │
│ mhk                                                                   │
│ mhk                                                                   │
│ mhk                                                                   │
│ mhk                                                                   │
└───────────────────────────────────────────────────────────────────────┘

查看语法优化

EXPLAIN SYNTAX
SELECT if(number = 1, 'hello', if(number = 2, 'world', 'mhk'))
FROM numbers(10)

Query id: a706af9e-986c-48e2-8446-1ce411e5ef96

┌─explain────────────────────────────────────────────────────────┐
│ SELECT if(number = 1, 'hello', if(number = 2, 'world', 'mhk')) │
│ FROM numbers(10)                                               │
└────────────────────────────────────────────────────────────────┘

开启三元运算符优化

SET optimize_if_chain_to_multiif = 1

Query id: b9439d72-9de7-45b0-83c7-954034c897a7

Ok.

再次查看语法优化

EXPLAIN SYNTAX
SELECT if(number = 1, 'hello', if(number = 2, 'world', 'mhk'))
FROM numbers(10)

Query id: 7202a628-c87e-403a-ab67-ac0a3e6c31e3

┌─explain─────────────────────────────────────────────────────────┐
│ SELECT multiIf(number = 1, 'hello', number = 2, 'world', 'mhk') │
│ FROM numbers(10)                                                │
└─────────────────────────────────────────────────────────────────┘再次查看语法优化

4）查看 PIPELINE

EXPLAIN PIPELINE
SELECT sum(number)
FROM numbers_mt(100000)
GROUP BY number % 20

Query id: b02792e0-0555-4dce-84a8-353ededfc4cf

┌─explain─────────────────────────┐
│ (Expression)                    │
│ ExpressionTransform             │
│   (Aggregating)                 │
│   Resize 2 → 1                  │
│     AggregatingTransform × 2    │
│       (Expression)              │
│       ExpressionTransform × 2   │
│         (SettingQuotaAndLimits) │
│           (ReadFromStorage)     │
│           NumbersMt × 2 0 → 1   │
└─────────────────────────────────┘

打开其他参数

EXPLAIN PIPELINE header = 1, graph = 1
SELECT sum(number)
FROM numbers_mt(10000)
GROUP BY number % 20

Query id: b2051401-c27e-4f8c-bacf-90061e4c6539

┌─explain─────────────────────────────────────┐
│ digraph                                     │
│ {                                           │
│   rankdir="LR";                             │
│   { node [shape = box]                      │
│         n2 [label="Limit"];                 │
│         n1 [label="Numbers"];               │
│     subgraph cluster_0 {                    │
│       label ="Aggregating";                 │
│       style=filled;                         │
│       color=lightgrey;                      │
│       node [style=filled,color=white];      │
│       { rank = same;                        │
│         n4 [label="AggregatingTransform"];  │
│       }                                     │
│     }                                       │
│     subgraph cluster_1 {                    │
│       label ="Expression";                  │
│       style=filled;                         │
│       color=lightgrey;                      │
│       node [style=filled,color=white];      │
│       { rank = same;                        │
│         n5 [label="ExpressionTransform"];   │
│       }                                     │
│     }                                       │
│     subgraph cluster_2 {                    │
│       label ="Expression";                  │
│       style=filled;                         │
│       color=lightgrey;                      │
│       node [style=filled,color=white];      │
│       { rank = same;                        │
│         n3 [label="ExpressionTransform"];   │
│       }                                     │
│     }                                       │
│   }                                         │
│   n2 -> n3 [label="                         │
│ number UInt64 UInt64(size = 0)"];           │
│   n1 -> n2 [label="                         │
│ number UInt64 UInt64(size = 0)"];           │
│   n4 -> n5 [label="                         │
│ modulo(number, 20) UInt8 UInt8(size = 0)    │
│ sum(number) UInt64 UInt64(size = 0)"];      │
│   n3 -> n4 [label="                         │
│ number UInt64 UInt64(size = 0)              │
│ modulo(number, 20) UInt8 UInt8(size = 0)"]; │
│ }                                           │
└─────────────────────────────────────────────┘

2. 建表优化

2.1 数据类型

2.1.1 时间字段的类型

建表时能用数值型或日期时间型表示的字段就不要用字符串，全 String 类型在以 Hive 为中心的数仓建设中常见，但 ClickHouse 环境不应受此影响。虽然 ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型，因为 DateTime 不需要经过函数转换处理，执行效率高、可读性好。

create table t_type2(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2) ,
  create_time Int32 
) engine =ReplacingMergeTree(create_time)
  partition by toYYYYMMDD(toDate(create_time)) –-需要转换一次，否则报错
  primary key (id)
  order by (id, sku_id);

2.1.2 空值存储类型

官方已经指出 Nullable 类型几乎总是会拖累性能，因为存储 Nullable 列时需要创建一个额外的文件来存储 NULL 的标记，并且 Nullable 列无法被索引。因此除非极特殊情况，应直接使用字段默认值表示空，或者自行指定一个在业务中无意义的值（例如用-1 表示没有商品 ID）。

hadoop102 :) CREATE TABLE t_null(x Int8, y Nullable(Int8)) ENGINE TinyLog;

CREATE TABLE t_null
(
    `x` Int8,
    `y` Nullable(Int8)
)
ENGINE = TinyLog

Query id: ad870b41-0650-4fe6-8313-aabdc2693946

Ok.

0 rows in set. Elapsed: 0.045 sec. 

hadoop102 :) INSERT INTO t_null VALUES (1, NULL), (2, 3);

INSERT INTO t_null VALUES

Query id: 33e450f9-0c21-483e-99fd-a35d793f77f4

Ok.

2 rows in set. Elapsed: 0.104 sec. 

hadoop102 :) SELECT x + y FROM t_null;

SELECT x + y
FROM t_null

Query id: 99828183-9860-4c6b-bb45-065729d6df38

┌─plus(x, y)─┐
│       ᴺᵁᴸᴸ │
│          5 │
└────────────┘

2 rows in set. Elapsed: 0.014 sec. 

查看存储的文件：（没有权限就用 root 用户）

[root@hadoop102 t_null]# pwd
/var/lib/clickhouse/data/default/t_null
[root@hadoop102 t_null]# ll
总用量 16
-rw-r----- 1 clickhouse clickhouse 91 4月  22 21:03 sizes.json
-rw-r----- 1 clickhouse clickhouse 28 4月  22 21:03 x.bin
-rw-r----- 1 clickhouse clickhouse 28 4月  22 21:03 y.bin
-rw-r----- 1 clickhouse clickhouse 28 4月  22 21:03 y.null.bin

2.2 分区和索引

分区粒度根据业务特点决定，不宜过粗或过细。一般选择按天分区，也可以指定为 Tuple()，以单表一亿数据为例，分区大小控制在 10-30 个为最佳。

必须指定索引列，ClickHouse 中的索引列即排序列，通过 order by 指定，一般在查询条件中经常被用来充当筛选条件的属性被纳入进来；可以是单一维度，也可以是组合维度的索引；通常需要满足高级列在前、查询频率大的在前原则；还有基数特别大的不适合做索引列，

如用户表的 userid 字段；通常筛选后的数据满足在百万以内为最佳。

2.3 表参数

Index_granularity 是用来控制索引粒度的，默认是 8192，如非必须不建议调整。如果表中不是必须保留全量历史数据，建议指定 TTL（生存时间值），可以免去手动过期历史数据的麻烦，TTL 也可以通过 alter table 语句随时修改。

2.4 写入和删除优化

（1）尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台 Merge 任务带来巨大压力（2）不要一次写入太多分区，或数据写入太快，数据写入太快会导致 Merge 速度跟不上而报错，一般建议每秒钟发起 2-3 次写入操作，每次操作写入 2w~5w 条数据（依服务器性能而定）写入过快报错，报错信息：

1. Code: 252, e.displayText() = DB::Exception: Too many parts(304). 
Merges are processing significantly slower than inserts 
2. Code: 241, e.displayText() = DB::Exception: Memory limit (for query) 
exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888 
bytes), maximum: 9.31 GiB

处理方式： “ Too many parts 处理 ” ：使用 WAL 预写日志，提高写入性能。 in_memory_parts_enable_wal 默认为 true 在服务器内存充裕的情况下增加内存配额，一般通过 max_memory_usage 来实现在服务器内存不充裕的情况下，建议将超出部分内容分配到系统硬盘上，但会降低执行速度，一般通过 max_bytes_before_external_group_by、max_bytes_before_external_sort 参数来实现。

2.5 常见配置

配置项主要在 config.xml 或 users.xml 中，基本上都在 users.xml 里

config.xml 的配置项

https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/

users.xml 的配置项

https://clickhouse.tech/docs/en/operations/settings/settings/

2.5.1 CPU 资源

2.5.2 内存资源

| 配置 | 描述 | | — | — | | max_memory_usage | 此参数在 users.xml 中,表示单次 Query 占用内存最大值，该值可以设置的比较大，这样可以提升集群查询的上限。保留一点给 OS，比如 128G 内存的机器，设置为 100GB。 | | max_bytes_before_external_group_by | 一般按照 max_memory_usage 的一半设置内存，当 group 使用内存超过阈值后会刷新到磁盘进行。因为 clickhouse 聚合分两个阶段：查询并及建立中间数据、合并中间数据，结合上一项，建议 50GB。 | | max_bytes_before_external_sort | 当 order by 已使用 max_bytes_before_external_sort 内存就进行溢写磁盘(基于磁盘排序)，如果不设置该值，那么当内存不够时直接抛错，设置了该值 order by 可以正常完成，但是速度相对存内存来说肯定要慢点(实测慢的非常多，无法接受)。 | | max_table_size_to_drop | 此参数在 config.xml 中，应用于需要删除表或分区的情况，默认是50GB，意思是如果删除 50GB 以上的分区表会失败。建议修改为 0，这样不管多大的分区表都可以删除。 |

2.5.3 存储

ClickHouse 不支持设置多数据目录，为了提升数据 io 性能，可以挂载虚拟券组，一个券组绑定多块物理磁盘提升读写性能，多数据查询场景 SSD 会比普通机械硬盘快 2-3 倍。

3. ClickHouse 语法优化规则

ClickHouse 的 SQL 优化规则是基于 RBO(Rule Based Optimization)，下面是一些优化规则

3.1 COUNT 优化

在调用 count 函数时，如果使用的是 count() 或者 count(*)，且没有 where 条件，则会直接使用 system.tables 的 total_rows，例如:

EXPLAIN SELECT count()FROM datasets.hits_v1;

Union
  Expression (Projection)
    Expression (Before ORDER BY and SELECT)
      MergingAggregated
        ReadNothing (Optimized trivial count)

注意 Optimized trivial count ，这是对 count 的优化。如果 count 具体的列字段，则不会使用此项优化：

EXPLAIN SELECT count(CounterID) FROM datasets.hits_v1; 
  Union 
    Expression (Projection) 
      Expression (Before ORDER BY and SELECT) 
        Aggregating 
          Expression (Before GROUP BY) 
             ReadFromStorage (Read from MergeTree)

3.2 消除子查询重复字段

下面语句子查询中有两个重复的 id 字段，会被去重:

EXPLAIN SYNTAX SELECT 
  a.UserID, 
  b.VisitID, 
  a.URL, 
  b.UserID 
  FROM 
  hits_v1 AS a 
  LEFT JOIN ( 
    SELECT 
      UserID, 
      UserID as HaHa, 
      VisitID 
    FROM visits_v1) AS b 
    USING (UserID) 
    limit 3; 


//返回优化语句： 
SELECT 
  UserID, 
  VisitID, 
  URL, 
  b.UserID 
FROM hits_v1 AS a 
ALL LEFT JOIN 
(  
  SELECT 
    UserID, 
    VisitID 
  FROM visits_v1 
) AS b USING (UserID) 
LIMIT 3

3.3 谓词下推

当 group by 有 having 子句，但是没有 with cube、with rollup 或者 with totals 修饰的时候，having 过滤会下推到 where 提前过滤。例如下面的查询，HAVING name 变成了 WHERE name，在 group by 之前过滤：

EXPLAIN SYNTAX SELECT UserID FROM hits_v1 GROUP BY UserID HAVING UserID = '8585742290196126178';

//返回优化语句
SELECT UserID
FROM hits_v1
WHERE UserID = \'8585742290196126178\'
GROUP BY UserID

子查询也支持谓词下推：

EXPLAIN SYNTAX
SELECT *
FROM 
(
  SELECT UserID
  FROM visits_v1
)
WHERE UserID = '8585742290196126178'

//返回优化后的语句
SELECT UserID
FROM 
(
  SELECT UserID
  FROM visits_v1
  WHERE UserID = \'8585742290196126178\' 
)
WHERE UserID = \'8585742290196126178\'

再来一个复杂例子：

EXPLAIN SYNTAX 
SELECT * FROM (
  SELECT 
      * 
  FROM 
  (
    SELECT 
      UserID 
    FROM visits_v1
  ) 
  UNION ALL 
  SELECT 
      *
  FROM
  (
    SELECT 
      UserID 
    FROM visits_v1
  )
)
  WHERE UserID = '8585742290196126178'

//返回优化后的语句
SELECT UserID
FROM 
(
  SELECT UserID
  FROM 
  (
      SELECT UserID
      FROM visits_v1
      WHERE UserID = \'8585742290196126178\' 
  )
  WHERE UserID = \'8585742290196126178\'
  UNION ALL
  SELECT UserID
  FROM 	
  (
    SELECT UserID
    FROM visits_v1
    WHERE UserID = \'8585742290196126178\' 
  )
  WHERE UserID = \'8585742290196126178\' 
)
WHERE UserID = \'8585742290196126178\'

3.4 聚合计算外推

聚合函数内的计算，会外推，例如：

3.5 聚合函数消除

如果对聚合键，也就是 group by key 使用 min、max、any 聚合函数，则将函数消除，例如：

EXPLAIN SYNTAX
SELECT
  sum(UserID * 2),
  max(VisitID),
  max(UserID)
FROM visits_v1
GROUP BY UserID

//返回优化后的语句
SELECT 
  sum(UserID) * 2,
  max(VisitID),
  UserID
FROM visits_v1
GROUP BY UserID

3.6 删除重复的 order by key

例如下面的语句，重复的聚合键 id 字段会被去重:

EXPLAIN SYNTAX
SELECT *
FROM visits_v1
ORDER BY
  UserID ASC,
  UserID ASC,
  VisitID ASC,
  VisitID ASC

//返回优化后的语句：
select
……
FROM visits_v1
ORDER BY 
  UserID ASC,
  VisitID ASC

3.7 删除重复的 limit by key

例如下面的语句，重复声明的 name 字段会被去重：

EXPLAIN SYNTAX 
SELECT * 
FROM visits_v1 
LIMIT 3 BY 
  VisitID, 
  VisitID 
LIMIT 10 

//返回优化后的语句： 
select 
…… 
FROM visits_v1 
LIMIT 3 BY VisitID 
LIMIT 10

3.8 删除重复的 USING Key

例如下面的语句，重复的关联键 id 字段会被去重：

EXPLAIN SYNTAX
SELECT
  a.UserID,
  a.UserID,
  b.VisitID,
  a.URL,
  b.UserID
FROM hits_v1 AS a
LEFT JOIN visits_v1 AS b USING (UserID, UserID)

//返回优化后的语句：
SELECT 
  UserID,
  UserID,
  VisitID,
  URL,
  b.UserID
FROM hits_v1 AS a
ALL LEFT JOIN visits_v1 AS b USING (UserID)

3.9 标量替换

如果子查询只返回一行数据，在被引用的时候用标量替换，例如下面语句中的 total_disk_usage 字段：

EXPLAIN SYNTAX
WITH 
  (
    SELECT sum(bytes)
    FROM system.parts
    WHERE active
  ) AS total_disk_usage
SELECT
  (sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
  table
FROM system.parts
GROUP BY table
ORDER BY table_disk_usage DESC
LIMIT 10; 

//返回优化后的语句：
WITH CAST(0, \'UInt64\') AS total_disk_usage
SELECT 
  (sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
  table
FROM system.parts
GROUP BY table
ORDER BY table_disk_usage DESC
LIMIT 10

3.10 三元运算优化

如果开启了 optimize_if_chain_to_multiif 参数，三元运算符会被替换成 multiIf 函数，例如：

EXPLAIN SYNTAX 
SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : 'mhk') 
FROM numbers(10) 
settings optimize_if_chain_to_multiif = 1; 

//返回优化后的语句：
SELECT multiIf(number = 1, \'hello\', number = 2, \'world\', \'mhk\')
FROM numbers(10)
SETTINGS optimize_if_chain_to_multiif = 1

4. 查询优化

4.1 单表查询

4.1.1 Prewhere 替代 where

Prewhere 和 where 语句的作用相同，用来过滤数据。不同之处在于 prewhere 只支持 *MergeTree 族系列引擎的表，首先会读取指定的列数据，来判断数据过滤，等待数据过滤之后再读取 select 声明的列字段来补全其余属性。

当查询列明显多于筛选列时使用 Prewhere 可十倍提升查询性能，Prewhere 会自动优化执行过滤阶段的数据读取方式，降低 io 操作。

在某些场合下，prewhere 语句比 where 语句处理的数据量更少性能更高。

#关闭 where 自动转 prewhere(默认情况下， where 条件会自动优化成 prewhere)
set optimize_move_to_prewhere=0; 
# 使用 where
select WatchID, 
  JavaEnable, 
  Title, 
  GoodEvent, 
  EventTime, 
  EventDate, 
  CounterID, 
  ClientIP, 
  ClientIP6, 
  RegionID, 
  UserID, 
  CounterClass, 
  OS, 
  UserAgent, 
  URL, 
  Referer, 
  URLDomain, 
  RefererDomain, 
  Refresh, 
  IsRobot, 
  RefererCategories, 
  URLCategories, 
  URLRegions, 
  RefererRegions, 
  ResolutionWidth, 
  ResolutionHeight, 
  ResolutionDepth, 
  FlashMajor, 
  FlashMinor, 
  FlashMinor2
from datasets.hits_v1 where UserID='3198390223272470366';
# 使用 prewhere 关键字
select WatchID, 
  JavaEnable,
  Title, 
  GoodEvent, 
  EventTime, 
  EventDate, 
  CounterID, 
  ClientIP, 
  ClientIP6, 
  RegionID, 
  UserID, 
  CounterClass, 
  OS, 
  UserAgent, 
  URL, 
  Referer, 
  URLDomain, 
  RefererDomain, 
  Refresh, 
  IsRobot, 
  RefererCategories, 
  URLCategories, 
  URLRegions, 
  RefererRegions, 
  ResolutionWidth, 
  ResolutionHeight, 
  ResolutionDepth, 
  FlashMajor, 
  FlashMinor, 
  FlashMinor2
from datasets.hits_v1 prewhere UserID='3198390223272470366';

默认情况，我们肯定不会关闭 where 自动优化成 prewhere，但是某些场景即使开启优化，也不会自动转换成 prewhere，需要手动指定 prewhere：

使用常量表达式
使用默认值为 alias 类型的字段
包含了 arrayJOIN，globalIn，globalNotIn 或者 indexHint 的查询
select 查询的列字段和 where 的谓词相同

使用了主键字段

4.1.2 数据采样

通过采样运算可极大提升数据分析的性能

SELECT Title,count(*) AS PageViews 
FROM hits_v1 
SAMPLE 0.1 #代表采样 10%的数据,也可以是具体的条数 
WHERE CounterID =57 
GROUP BY Title 
ORDER BY PageViews DESC LIMIT 1000 

采样修饰符只有在 MergeTree engine 表中才有效，且在创建表时需要指定采样策略。

4.1.3 列裁剪与分区裁剪

数据量太大时应避免使用 select * 操作，查询的性能会与查询的字段大小和数量成线性表换，字段越少，消耗的 io 资源越少，性能就会越高。

反例：
select * from datasets.hits_v1;

正例：
select WatchID, 
  JavaEnable, 
  Title, 
  GoodEvent, 
  EventTime, 
  EventDate, 
  CounterID, 
  ClientIP, 
  ClientIP6, 
  RegionID, 
  UserID
from datasets.hits_v1;

分区裁剪就是只读取需要的分区，在过滤条件中指定。

select WatchID, 
  JavaEnable, 
  Title, 
  GoodEvent, 
  EventTime, 
  EventDate, 
  CounterID, 
  ClientIP, 
  ClientIP6, 
  RegionID, 
  UserID 
from datasets.hits_v1 
where EventDate='2014-03-23'; 

4.1.4 orderby 结合 where、limit

千万以上数据集进行 order by 查询时需要搭配 where 条件和 limit 语句一起使用。

#正例：
SELECT UserID,Age
FROM hits_v1 
WHERE CounterID=57
ORDER BY Age DESC LIMIT 1000

#反例：
SELECT UserID,Age
FROM hits_v1 
ORDER BY Age DESC

4.1.5 避免构建虚拟列

如非必须，不要在结果集上构建虚拟列，虚拟列非常消耗资源浪费性能，可以考虑在前端进行处理，或者在表中构造实际字段进行额外存储。

反例：
SELECT Income,Age,Income/Age as IncRate FROM datasets.hits_v1;

正例：拿到 Income 和 Age 后，考虑在前端进行处理，或者在表中构造实际字段进行额外存储
SELECT Income,Age FROM datasets.hits_v1;

4.1.6 uniqCombined 替代 distinct

性能可提升 10 倍以上，uniqCombined 底层采用类似 HyperLogLog 算法实现，能接收 2% 左右的数据误差，可直接使用这种去重方式提升查询性能。Count(distinct )会使用 uniqExact 精确去重。

不建议在千万级不同数据上执行 distinct 去重查询，改为近似去重 uniqCombined

反例：
select count(distinct rand()) from hits_v1;

正例：
SELECT uniqCombined(rand()) from datasets.hits_v1

4.1.7 其他注意事项

**（1）查询熔断 ** 为了避免因个别慢查询引起的服务雪崩的问题，除了可以为单个查询设置超时以外，还可以配置周期熔断，在一个查询周期内，如果用户频繁进行慢查询操作超出规定阈值后将无法继续进行查询操作。

**（2）关闭虚拟内存 ** 物理内存和虚拟内存的数据交换，会导致查询变慢，资源允许的情况下关闭虚拟内存。

**（3）配置 join_use_nulls ** 为每一个账户添加 join_use_nulls 配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准 SQL 中的 Null 值。

**（4）批量写入时先排序 ** 批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致 ClickHouse 无法及时对新导入的数据进行合并，从而影响查询性能。

**（5）关注 CPU ** cpu 一般在 50%左右会出现查询波动，达到 70%会出现大范围的查询超时，cpu 是最关键的指标，要非常关注。

4.2 多表关联

4.2.1 准备表和数据

#创建小表
CREATE TABLE visits_v2 
ENGINE = CollapsingMergeTree(Sign)
PARTITION BY toYYYYMM(StartDate)
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)
SAMPLE BY intHash32(UserID)
SETTINGS index_granularity = 8192
as select * from visits_v1 limit 10000;

#创建 join 结果表：避免控制台疯狂打印数据
CREATE TABLE hits_v2 
ENGINE = MergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)
SETTINGS index_granularity = 8192
as select * from hits_v1 where 1=0;

4.2.2 用 IN 代替 JOIN

当多表联查时，查询的数据仅从其中一张表出时，可考虑用 IN 操作而不是 JOIN

insert into hits_v2
select a.* from hits_v1 a where a.CounterID in (select CounterID from visits_v1);

#反例：使用 join
insert into table hits_v2
select a.* from hits_v1 a left join visits_v1 b on a.CounterID=b.CounterID;

4.2.3 大小表 JOIN

多表 join 时要满足小表在右的原则，右表关联时被加载到内存中与左表进行比较， ClickHouse 中无论是 Left join 、Right join 还是 Inner join 永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。

4.2.4 注意谓词下推（版本差异）

ClickHouse 在 join 查询时不会主动发起谓词下推的操作，需要每个子查询提前完成过滤操作，需要注意的是，是否执行谓词下推，对性能影响差别很大（新版本中已经不存在此问题，但是需要注意谓词的位置的不同依然有性能的差异）

Explain syntax
select a.* from hits_v1 a left join visits_v2 b on a.CounterID=b.CounterID
having a.EventDate = '2014-03-17';

Explain syntax
select a.* from hits_v1 a left join visits_v2 b on a.CounterID=b.CounterID
having b.StartDate = '2014-03-17';

insert into hits_v2
select a.* from hits_v1 a left join visits_v2 b on a.CounterID=b.CounterID
where a.EventDate = '2014-03-17';

insert into hits_v2
select a.* from (
    select * from 
    hits_v1 
where EventDate = '2014-03-17'
) a left join visits_v2 b on a.CounterID=b.CounterID;

4.2.5 分布式表使用 GLOBAL

两张分布式表上的 IN 和 JOIN 之前必须加上 GLOBAL 关键字，右表只会在接收查询请求的那个节点查询一次，并将其分发到其他节点上。如果不加 GLOBAL 关键字的话，每个节点都会单独发起一次对右表的查询，而右表又是分布式表，就导致右表一共会被查询 N²次（N是该分布式表的分片数量），这就是查询放大，会带来很大开销。

4.2.6 使用字典表

将一些需要关联分析的业务创建成字典表进行 join 操作，前提是字典表不宜太大，因为字典表会常驻内存

4.2.7 提前过滤

通过增加逻辑过滤可以减少数据扫描，达到提高执行速度及降低内存消耗的目的

ck的Join

原理：右表加载到内存，再去匹配
为什么join不行？因为1
非要使用join，怎么用比较好：能先过滤的过滤，特别是右表右边放小表特殊场景可以考虑使用字典表可以替换的话，尽量不要使用join，比如用 IN 实现
5. 数据一致性

数据一致性： replacingMergeTree 不能保证查询时没重复，只能保证最终一致性解决方案：
1. 手动执行：生产环境不推荐
2. 通过SQL实现去重： group by ==》高级一点的用法，加标记字段
3. 使用final： 20.5之前的版本，final是单线程 20.5之后的版本，final可以是多线程，但是读取数据是串行的
4. 重复一点无所谓： 100万日活，统计出来100万1千

6. 物化视图

ClickHouse 的物化视图是一种查询结果的持久化，它确实是给我们带来了查询效率的提升。用户查起来跟表没有区别，它就是一张表，它也像是一张时刻在预计算的表，创建的过程它是用了一个特殊引擎，加上后来 as select，就是 create 一个 table as select 的写法。

“查询结果集”的范围很宽泛，可以是基础表中部分数据的一份简单拷贝，也可以是多表 join 之后产生的结果或其子集，或者原始数据的聚合指标等等。所以，物化视图不会随着基础表的变化而变化，所以它也称为快照（snapshot）

6.1 概述

6.1.1 物化视图与普通视图的区别

普通视图不保存数据，保存的仅仅是查询语句，查询的时候还是从原表读取数据，可以将普通视图理解为是个子查询。物化视图则是把查询的结果根据相应的引擎存入到了磁盘或内存中，对数据重新进行了组织，你可以理解物化视图是完全的一张新表。

6.1.2 优缺点

优点：查询速度快，要是把物化视图这些规则全部写好，它比原数据查询快了很多，总的行数少了，因为都预计算好了。

缺点：它的本质是一个流式数据的使用场景，是累加式的技术，所以要用历史数据做去重、去核这样的分析，在物化视图里面是不太好用的。在某些场景的使用也是有限的。而且如果一张表加了好多物化视图，在写这张表的时候，就会消耗很多机器的资源，比如数据带宽占满、存储一下子增加了很多。

6.1.3 基本语法

也是 create 语法，会创建一个隐藏的目标表来保存视图数据。也可以 TO 表名，保存到一张显式的表。没有加 TO 表名，表名默认就是 .inner.物化视图名

CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]table_name [TO[db.]name] 
[ENGINE = engine] [POPULATE] AS SELECT ... 

populate：不建议添加，加上这个参数在创建视图的时候会尝试将历史所有数据重新走一遍并呈下来 **1）创建物化视图的限制 **

必须指定物化视图的 engine 用于数据存储
TO [db].[table]语法的时候，不得使用 POPULATE。
查询语句(select）可以包含下面的子句： DISTINCT, GROUP BY, ORDER BY, LIMIT…
物化视图的 alter 操作有些限制，操作起来不大方便。
若物化视图的定义使用了 TO [db.]name 子语句，则可以将目标表的视图卸载 DETACH 再装载 ATTACH

**2）物化视图的数据更新 ** （1）物化视图创建好之后，若源表被写入新数据则物化视图也会同步更新（2）POPULATE 关键字决定了物化视图的更新策略：

若有 POPULATE 则在创建视图的过程会将源表已经存在的数据一并导入，类似于 create table … as
若无 POPULATE 则物化视图在创建之后没有数据，只会在创建只有同步之后写入源表的数据
clickhouse 官方并不推荐使用 POPULATE，因为在创建物化视图的过程中同时写入

的数据不能被插入物化视图。（3）物化视图不支持同步删除，若源表的数据不存在（删除了）则物化视图的数据仍然保留（4）物化视图是一种特殊的数据表，可以用 show tables 查看（5）物化视图数据的删除：（6）物化视图的删除：

ClickHouse表引擎

hkmu9248@gmail.com (Haokang Mu) — Fri, 22 Apr 2022 00:00:00 +0800

1. 表引擎的使用

表引擎是 ClickHouse 的一大特色。可以说，表引擎决定了如何存储表的数据。包括：

数据的存储方式和位置，写到哪里以及从哪里读取数据。
支持哪些查询以及如何支持。
并发数据访问。
索引的使用（如果存在）。
是否可以执行多线程请求。
数据复制参数。

表引擎的使用方式就是必须显式在创建表时定义该表使用的引擎，以及引擎使用的相关参数。特别注意：引擎的名称大小写敏感

2. TinyLog

以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，生产环境上作用有限。可以用于平时练习测试用。如：

hadoop102 :) create table t_tinylog ( id String, name String) engine=TinyLog;

CREATE TABLE t_tinylog
(
    `id` String,
    `name` String
)
ENGINE = TinyLog

Query id: 1198d2f9-aa70-4661-a6ab-a648d467e049

Ok.

0 rows in set. Elapsed: 0.008 sec. 

3. Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现（超过 10G/s）。

一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不太大（上限大概 1 亿行）的场景。 Version:0.9 StartHTML:0000000105 EndHTML:0000002532 StartFragment:0000000141 EndFragment:0000002492

4. MergeTree

ClickHouse 中最强大的表引擎当属 MergeTree（合并树）引擎及该系列（*MergeTree）中的其他引擎，支持索引和分区，地位可以相当于 innodb 之于 Mysql。而且基于 MergeTree，还衍生除了很多小弟，也是非常有特色的引擎。 1）建表语句

create table t_order_mt(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2),
  create_time Datetime
) engine =MergeTree
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id);

2）插入数据

insert into t_order_mt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

MergeTree 其实还有很多参数(绝大多数用默认值即可)，但是三个参数是更加重要的，也涉及了关于 MergeTree 的很多概念。

4.1 partition by 分区(可选)

1）作用 学过 hive 的应该都不陌生，分区的目的主要是降低扫描的范围，优化查询速度

**2）如果不填 ** 只会使用一个分区。

**3）分区目录 ** MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。

**4）并行 ** 分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。

**5）数据写入与分区合并 ** 任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入后的某个时刻（大概 10-15 分钟后），ClickHouse 会自动执行合并操作（等不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。

optimize table xxxx final; 

**6）例如 ** 再次执行上面的插入操作

insert into t_order_mt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

查看数据并没有纳入任何分区

hadoop102 :) select * from t_order_mt;

SELECT *
FROM t_order_mt

Query id: 05f4c4a0-fce7-4bd3-8d01-14c87ebf7d79

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

手动 optimize 之后

hadoop102 :) optimize table t_order_mt final;

OPTIMIZE TABLE t_order_mt FINAL

Query id: 5c63b117-9150-4245-9bf4-b047ff37e64d

Ok.

0 rows in set. Elapsed: 0.005 sec. 

hadoop102 :) select * from t_order_mt;

SELECT *
FROM t_order_mt

Query id: 5db17a7a-fd16-4ea4-9bce-1987adc0c020

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

4.2 primary key 主键(可选)

ClickHouse 中的主键，和其他数据库不太一样，它只提供了数据的一级索引，但是却不是唯一约束。这就意味着是可以存在相同 primary key 的数据的。

主键的设定主要依据是查询语句中的 where 条件。

根据条件通过对主键进行某种形式的二分查找，能够定位到对应的 index granularity，避免了全表扫描。

index granularity：直接翻译的话就是索引粒度，指在稀疏索引中两个相邻索引对应数据的间隔。ClickHouse 中的 MergeTree 默认是 8192。官方不建议修改这个值，除非该列存在大量重复值，比如在一个分区中几万行才有一个不同数据。 稀疏索引： 稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位到索引粒度的第一行，然后再进行进行一点扫描。

4.3 order by（必选）

order by 设定了分区内的数据按照哪些字段顺序进行有序保存。 order by 是 MergeTree 中唯一一个必填项，甚至比 primary key 还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理（比如后面会讲的去重和汇总）。要求：主键必须是 order by 字段的前缀字段。比如 order by 字段是 (id,sku_id) 那么主键必须是 id 或者(id,sku_id)

4.4 二级索引

目前在 ClickHouse 的官网上二级索引的功能在 v20.1.2.4 之前是被标注为实验性的，在这个版本之后默认是开启的。

**1）老版本使用二级索引前需要增加设置 ** 是否允许使用实验性的二级索引（v20.1.2.4 开始，这个参数已被删除，默认开启）

set allow_experimental_data_skipping_indices=1;

2）创建测试表

create table t_order_mt2(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2),
  create_time Datetime,
  INDEX a total_amount TYPE minmax GRANULARITY 5
) engine =MergeTree
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id, sku_id);

其中 GRANULARITY N 是设定二级索引对于一级索引粒度的粒度。

3）插入数据

insert into t_order_mt2 values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

**4）对比效果 ** 那么在使用下面语句进行测试，可以看出二级索引能够为非主键字段的查询发挥作用。

 [mhk@hadoop102 ~]$ clickhouse-client --send_logs_level=trace <<< 'select * from t_order_mt2 where total_amount > toDecimal32(900., 2)';
[hadoop102] 2022.04.21 11:02:48.734615 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> executeQuery: (from [::1]:47482, using production parser) select * from t_order_mt2 where total_amount > toDecimal32(900., 2) 
[hadoop102] 2022.04.21 11:02:48.738641 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition "total_amount > toDecimal32(900., 2)" moved to PREWHERE
[hadoop102] 2022.04.21 11:02:48.739326 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Trace> ContextAccess (default): Access granted: SELECT(id, sku_id, total_amount, create_time) ON default.t_order_mt2
[hadoop102] 2022.04.21 11:02:48.739672 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
[hadoop102] 2022.04.21 11:02:48.740449 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> default.t_order_mt2 (d745abc9-fa2e-4e8d-9745-abc9fa2e8e8d) (SelectExecutor): Key condition: unknown
[hadoop102] 2022.04.21 11:02:48.740858 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> default.t_order_mt2 (d745abc9-fa2e-4e8d-9745-abc9fa2e8e8d) (SelectExecutor): MinMax index condition: unknown
[hadoop102] 2022.04.21 11:02:48.743255 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> default.t_order_mt2 (d745abc9-fa2e-4e8d-9745-abc9fa2e8e8d) (SelectExecutor): Index `a` has dropped 1/2 granules.
[hadoop102] 2022.04.21 11:02:48.743363 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> default.t_order_mt2 (d745abc9-fa2e-4e8d-9745-abc9fa2e8e8d) (SelectExecutor): Selected 2/2 parts by partition key, 1 parts by primary key, 2/2 marks by primary key, 1 marks to read from 1 ranges
[hadoop102] 2022.04.21 11:02:48.743492 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> MergeTreeSelectProcessor: Reading 1 ranges from part 20200601_1_1_0, approx. 5 rows starting from 0
101     sku_001 1000.00 2020-06-01 12:00:00
102     sku_002 2000.00 2020-06-01 11:00:00
102     sku_002 2000.00 2020-06-01 13:00:00
102     sku_002 12000.00        2020-06-01 13:00:00
102     sku_004 2500.00 2020-06-01 12:00:00
[hadoop102] 2022.04.21 11:02:48.750132 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Information> executeQuery: Read 5 rows, 160.00 B in 0.015278276 sec., 327 rows/sec., 10.23 KiB/sec.
[hadoop102] 2022.04.21 11:02:48.750215 [ 3080 ] {a6707ccc-7da3-4b07-80a9-15d42c6db6f6} <Debug> MemoryTracker: Peak memory usage (for query): 0.00 B.

4.5 数据 TTL

TTL 即 Time To Live，MergeTree 提供了可以管理数据表或者列的生命周期的功能。 **1）列级别 TTL ** （1）创建测试表

create table t_order_mt3(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2) TTL create_time+interval 10 SECOND,
  create_time Datetime 
) engine =MergeTree
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id, sku_id);	

（2）插入数据（注意：根据实际时间改变）

insert into t_order_mt3 values
(106,'sku_001',1000.00,'2022-04-21 18:53:30'),
(107,'sku_002',2000.00,'2022-04-21 18:53:31'),
(110,'sku_003',600.00,'2022-04-21 18:53:32');

（3）手动合并，查看效果到期后，指定的字段数据归 0 如果不成功重启ClickHouse试试

hadoop102 :) select * from t_order_mt3;

SELECT *
FROM t_order_mt3

Query id: dd37debb-0ae6-4a21-9ee8-f92659f483d7

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 110 │ sku_003 │         0.00 │ 2020-06-13 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 106 │ sku_001 │         0.00 │ 2020-06-12 22:52:30 │
│ 107 │ sku_002 │         0.00 │ 2020-06-12 22:52:30 │
└─────┴─────────┴──────────────┴─────────────────────┘

**2）表级 TTL ** 下面的这条语句是数据会在 create_time 之后 10 秒丢失

alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 10 SECOND; 

hadoop102 :) select * from t_order_mt3;

SELECT *
FROM t_order_mt3

Query id: e775e83a-02a5-4f49-87ad-23999b19026f

ok.

0 rows in set. Elapsed: 0.004 sec.

涉及判断的字段必须是 Date 或者 Datetime 类型，推荐使用分区的日期字段。能够使用的时间周期：

SECOND
MINUTE
HOUR
DAY
WEEK
MONTH
QUARTER
YEAR

5. ReplacingMergeTree

ReplacingMergeTree 是 MergeTree 的一个变种，它存储特性完全继承 MergeTree，只是多了一个去重的功能。尽管 MergeTree 可以设置主键，但是 primary key 其实没有唯一约束的功能。如果你想处理掉重复的数据，可以借助这个 ReplacingMergeTree。 **1）去重时机 ** 数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预先作出计划。有一些数据可能仍未被处理。

**2）去重范围 ** 如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。所以 ReplacingMergeTree 能力有限， ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

**3）案例演示 ** （1）创建表

create table t_order_rmt(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2) ,
  create_time Datetime 
) engine =ReplacingMergeTree(create_time)
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id, sku_id);

ReplacingMergeTree() 填入的参数为版本字段，重复数据保留版本字段值最大的。如果不填版本字段，默认按照插入顺序保留最后一条。

（2）向表中插入数据

insert into t_order_rmt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

（3）执行第一次查询

hadoop102 :) select * from t_order_rmt;

SELECT *
FROM t_order_rmt

Query id: e88b72cc-a3b7-44c3-a105-390068c2cf04

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

（4）手动合并

hadoop102 :) OPTIMIZE TABLE t_order_rmt FINAL;

OPTIMIZE TABLE t_order_rmt FINAL

Query id: cc6fe5c5-93b9-4899-af8a-c2ff2afc6a91

Ok.

0 rows in set. Elapsed: 0.005 sec.

（5）再执行一次查询

hadoop102 :) select * from t_order_rmt;

SELECT *
FROM t_order_rmt

Query id: 392da567-ad3b-43ab-8fa9-de976f59d10c

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

**4）通过测试得到结论 **

实际上是使用 order by 字段作为唯一键
去重不能跨分区
只有同一批插入（新版本）或合并分区时才会进行去重
认定重复的数据保留，版本字段值最大的
如果版本字段相同则按插入顺序保留最后一笔

6. SummingMergeTree

对于不查询明细，只关心以维度进行汇总聚合结果的场景。如果只使用普通的MergeTree的话，无论是存储空间的开销，还是查询时临时聚合的开销都比较大。 ClickHouse 为了这种场景，提供了一种能够“预聚合”的引擎 SummingMergeTree **1）案例演示 ** （1）创建表

create table t_order_smt(
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2) ,
  create_time Datetime 
) engine =SummingMergeTree(total_amount)
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id );

（2）插入数据

insert into t_order_smt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

（3）执行第一次查询

hadoop102 :) select * from t_order_smt;

SELECT *
FROM t_order_smt

Query id: a3c82de5-cc78-4bf8-aaed-96411d8caa0f

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_002 │     12000.00 │ 2020-06-01 13:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

（4）手动合并

hadoop102 :) OPTIMIZE TABLE t_order_smt FINAL;

（5）再执行一次查询

hadoop102 :) select * from t_order_smt;

SELECT *
FROM t_order_smt

Query id: a3c82de5-cc78-4bf8-aaed-96411d8caa0f

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 102 │ sku_002 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │     16000.00 │ 2020-06-01 11:00:00 │
│ 102 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

**2）通过结果可以得到以下结论 **

以 SummingMergeTree（）中指定的列作为汇总数据列
可以填写多列必须数字列，如果不填，以所有非维度列且为数字列的字段为汇总数据列
以 order by 的列为准，作为维度列
其他的列按插入顺序保留第一行
不在一个分区的数据不会被聚合
只有在同一批次插入(新版本)或分片合并时才会进行聚合

**3）开发建议 ** 设计聚合表的话，唯一键值、流水号可以去掉，所有字段全部是维度、度量或者时间戳。

**4）问题 ** 能不能直接执行以下 SQL 得到汇总值

select total_amount from XXX where province_name=’’ and create_date=’xxx’ 

不行，可能会包含一些还没来得及聚合的临时明细

如果要是获取汇总值，还是需要使用 sum 进行聚合，这样效率会有一定的提高，但本身 ClickHouse 是列式存储的，效率提升有限，不会特别明显。

select sum(total_amount) from province_name=’’ and create_date=‘xxx’

ClickHouse副本和分片集群

hkmu9248@gmail.com (Haokang Mu) — Fri, 22 Apr 2022 00:00:00 +0800

1. 副本

副本的目的主要是保障数据的高可用性，即使一台 ClickHouse 节点宕机，那么也可以从其他服务器获得相同的数据。 https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replication/

1.1 副本写入流程

1.2 配置步骤

（1）启动 zookeeper 集群（2）在 hadoop102 的/etc/clickhouse-server/config.d 目录下创建一个名为 metrika.xml 的配置文件,内容如下：注：也可以不创建外部文件，直接在 config.xml 中指定

<?xml version="1.0"?>
<yandex>
  <zookeeper-servers>
    <node index="1">
      <host>hadoop102</host>
      <port>2181</port>
    </node>
    <node index="2">
      <host>hadoop103</host>
      <port>2181</port>
    </node>
    <node index="3">
      <host>hadoop104</host>
      <port>2181</port>
    </node>
  </zookeeper-servers>
</yandex>

（3）同步到 hadoop103 和 hadoop104 上

[root@hadoop102 clickhouse-server]# xsync config.d/

（4）在 hadoop102 的/etc/clickhouse-server/config.xml 中增加

<zookeeper incl="zookeeper-servers" optional="true" />
<include_from>/etc/clickhouse-server/config.d/metrika.xml</include_from>

（5）同步到 hadoop103 和 hadoop104 上

[root@hadoop102 clickhouse-server]# xsync config.xml

分别在 hadoop102 和 hadoop103 上启动 ClickHouse 服务注意：因为修改了配置文件，如果以前启动了服务需要重启

 sudo clickhouse restart

注意：我们演示副本操作只需要在 hadoop102 和 hadoop103 两台服务器即可，上面的操作，我们 hadoop104 可以你不用同步，我们这里为了保证集群中资源的一致性，做了同步。（6）在 hadoop102 和 hadoop103 上分别建表副本只能同步数据，不能同步表结构，所以我们需要在每台机器上自己手动建表 ①hadoop102

create table t_order_rep2 (
  id UInt32,
  sku_id String,
  total_amount Decimal(16,2),
  create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')
partition by toYYYYMMDD(create_time)
primary key (id)
    order by (id,sku_id);

②hadoop103

create table t_order_rep2 (
    id UInt32,
    sku_id String,
    total_amount Decimal(16,2),
    create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_103')
    partition by toYYYYMMDD(create_time)
    primary key (id)
    order by (id,sku_id);

③参数解释 ReplicatedMergeTree 中， 第一个参数是分片的 zk_path 一般按照：/clickhouse/table/{shard}/{table_name} 的格式写，如果只有一个分片就写 01 即可。 第二个参数是副本名称，相同的分片副本名称不能相同。

（7）在 hadoop102 上执行 insert 语句

insert into t_order_rep2 values
(101,'sku_001',1000.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 12:00:00'),
(103,'sku_004',2500.00,'2020-06-01 12:00:00'),
(104,'sku_002',2000.00,'2020-06-01 12:00:00'),
(105,'sku_003',600.00,'2020-06-02 12:00:00');

（8）在 hadoop103 上执行 select，可以查询出结果，说明副本配置正确

hadoop103 :) select * from t_order_rep2;

SELECT *
FROM t_order_rep2

Query id: 4c800260-a5e1-40ff-b7b1-75a0eef9487b

┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 105 │ sku_003 │       600.00 │ 2020-06-02 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘
┌──id─┬─sku_id──┬─total_amount─┬─────────create_time─┐
│ 101 │ sku_001 │      1000.00 │ 2020-06-01 12:00:00 │
│ 102 │ sku_002 │      2000.00 │ 2020-06-01 12:00:00 │
│ 103 │ sku_004 │      2500.00 │ 2020-06-01 12:00:00 │
│ 104 │ sku_002 │      2000.00 │ 2020-06-01 12:00:00 │
└─────┴─────────┴──────────────┴─────────────────────┘

5 rows in set. Elapsed: 0.007 sec. 

2. 分片集群

副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决。要解决数据水平切分的问题，需要引入分片的概念。通过分片把一份完整的数据进行切分，不同的分片分布到不同的节点上，再通过 Distributed 表引擎把数据拼接起来一同使用。 Distributed 表引擎本身不存储数据，有点类似于 MyCat 之于 MySql，成为一种中间件，通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据。注意：ClickHouse 的集群是表级别的，实际企业中，大部分做了高可用，但是没有用分片，避免降低查询性能以及操作集群的复杂性。

2.1 集群写入流程（3 分片 2 副本共 6 个节点）

2.2 集群读取流程（3 分片 2 副本共 6 个节点）

2.3 3 分片 2 副本共 6 个节点集群配置（供参考）

配置的位置还是在之前的/etc/clickhouse-server/config.d/metrika.xml，内容如下

<yandex>
  <remote_servers>
    <gmall_cluster> <!-- 集群名称--> 
      <shard> <!--集群的第一个分片-->
        <internal_replication>true</internal_replication>
        <!--该分片的第一个副本-->
        <replica> 
          <host>hadoop101</host>
          <port>9000</port>
        </replica>
        <!--该分片的第二个副本-->
        <replica> 
          <host>hadoop102</host>
          <port>9000</port>
        </replica>
      </shard>
      <shard> <!--集群的第二个分片--> 
        <internal_replication>true</internal_replication>
        <replica> <!--该分片的第一个副本-->
          <host>hadoop103</host>
          <port>9000</port>
        </replica>
        <replica> <!--该分片的第二个副本-->
          <host>hadoop104</host>
          <port>9000</port>
        </replica>
      </shard>
      <shard> <!--集群的第三个分片-->
        <internal_replication>true</internal_replication>
        <replica> <!--该分片的第一个副本-->
          <host>hadoop105</host>
          <port>9000</port>
        </replica>
        <replica> <!--该分片的第二个副本-->
          <host>hadoop106</host>
          <port>9000</port>
        </replica>
      </shard>
    </gmall_cluster>
  </remote_servers>
</yandex>

ClickHouse数据类型

hkmu9248@gmail.com (Haokang Mu) — Thu, 21 Apr 2022 00:00:00 +0800

1. 整型

固定长度的整型，包括有符号整型或无符号整型。整型范围（-2^(n-1) ~ 2^(n-1)-1）： Int8 - [-128 : 127] Int16 - [-32768 : 32767] Int32 - [-2147483648 : 2147483647] Int64 - [-9223372036854775808 : 9223372036854775807] 无符号整型范围（0~(2^n)-1）： UInt8 - [0 : 255] UInt16 - [0 : 65535] UInt32 - [0 : 4294967295] UInt64 - [0 : 18446744073709551615] **使用场景：个数、数量、也可以存储型 id。 **

2. 浮点型

Float32 - float Float64 – double 建议尽可能以整数形式存储数据。例如，将固定精度的数字转换为整数值，如时间用毫秒为单位表示，因为浮点型进行计算时可能引起四舍五入的误差。

hadoop102 :) select 1-0.9;

SELECT 1 - 0.9

Query id: e741974d-f149-4162-9147-01c3a9981677

┌───────minus(1, 0.9)─┐
│ 0.09999999999999998 │
└─────────────────────┘

1 rows in set. Elapsed: 0.008 sec. 

**使用场景：一般数据值比较小，不涉及大量的统计计算，精度要求不高的时候。比如 ** **保存商品的重量。 **

3. 布尔型

没有单独的类型来存储布尔值。可以使用 UInt8 类型，取值限制为 0 或 1。

4. Decimal 型

有符号的浮点数，可在加、减和乘法运算过程中保持精度。对于除法，最低有效数字会被丢弃（不舍入）。有三种声明：

Decimal32(s)，相当于 Decimal(9-s,s)，有效位数为 1~9
Decimal64(s)，相当于 Decimal(18-s,s)，有效位数为 1~18
Decimal128(s)，相当于 Decimal(38-s,s)，有效位数为 1~38

s 标识小数位

123.123.123.123

decimal32(5)    ===>    整数+小数一共9位，小数部分有5位   123.12312
decimal64(5)    ===>    整数+小数一共18位，小数部分有5位   123.12312

使用场景：一般金额字段、汇率、利率等字段为了保证小数点精度，都使用 Decimal 进行存储。

5. 字符串

**1）String ** 字符串可以任意长度的。它可以包含任意的字节集，包含空字节。

**2）FixedString(N) ** 固定长度 N 的字符串，N 必须是严格的正自然数。当服务端读取长度小于 N 的字符串时候，通过在字符串末尾添加空字节来达到 N 字节长度。当服务端读取长度大于 N 的字符串时候，将返回错误消息。

与 String 相比，极少会使用 FixedString，因为使用起来不是很方便。

使用场景：名称、文字描述、字符型编码。固定长度的可以保存一些定长的内容，比如一些编码，性别等但是考虑到一定的变化风险，带来收益不够明显，所以定长字符串使用意义有限。

6. 枚举类型

包括 Enum8 和 Enum16 类型。Enum 保存 ‘string’= integer 的对应关系。 Enum8 用 ‘String’= Int8 对描述。 Enum16 用 ‘String’= Int16 对描述。

**1）用法演示 ** 创建一个带有一个枚举 Enum8(‘hello’ = 1, ‘world’ = 2) 类型的列

hadoop102 :) CREATE TABLE t_enum
:-] (
:-]     x Enum8('hello' = 1, 'world' = 2)
:-] )
:-] ENGINE = TinyLog;

CREATE TABLE t_enum
(
    `x` Enum8('hello' = 1, 'world' = 2)
)
ENGINE = TinyLog

Query id: deb02552-6fb4-4836-b210-640211e9440b

Ok.

0 rows in set. Elapsed: 0.005 sec. 

2）这个 x 列只能存储类型定义中列出的值：’hello’或’world’

hadoop102 :) select * from t_enum;

SELECT *
FROM t_enum

Query id: 5a0532b8-d186-4402-9491-8bd688693005

┌─x─────┐
│ hello │
│ world │
│ hello │
└───────┘

3 rows in set. Elapsed: 0.003 sec. 

3）如果尝试保存任何其他值，ClickHouse 抛出异常

hadoop102 :) insert into t_enum values('a');

INSERT INTO t_enum VALUES

Query id: bcbe515e-4247-4ecf-bb62-a6ca509d0aa0

Exception on client:
Code: 36. DB::Exception: Unknown element 'a' for enum: data for INSERT was parsed from query

Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.7.3 revision 54449.

4）如果需要看到对应行的数值，则必须将 Enum 值转换为整数类型

hadoop102 :) SELECT CAST(x, 'Int8') FROM t_enum;

SELECT CAST(x, 'Int8')
FROM t_enum

Query id: 68450b03-5d18-4e3d-99e3-5d42451caa25

┌─CAST(x, 'Int8')─┐
│               1 │
│               2 │
│               1 │
└─────────────────┘

3 rows in set. Elapsed: 0.005 sec. 

使用场景：对一些状态、类型的字段算是一种空间优化，也算是一种数据约束。但是实际使用中往往因为一些数据内容的变化增加一定的维护成本，甚至是数据丢失问题。所以谨慎使用。

7. 时间类型

目前 ClickHouse 有三种时间类型

Date 接受年-月-日的字符串比如 ‘2019-12-16’
Datetime 接受年-月-日时:分:秒的字符串比如 ‘2019-12-16 20:50:10’
Datetime64 接受年-月-日时:分:秒.亚秒的字符串比如‘2019-12-16 20:50:10.66’

日期类型，用两个字节存储，表示从 1970-01-01 (无符号) 到当前的日期值。还有很多数据结构，可以参考官方文档：https://clickhouse.yandex/docs/zh/data_types/

8. 数组

Array(T)：由 T 类型元素组成的数组。 T 可以是任意类型，包含数组类型。但不推荐使用多维数组，ClickHouse 对多维数组的支持有限。例如，不能在 MergeTree 表中存储多维数组。（1）创建数组方式 1，使用 array 函数

hadoop102 :) SELECT array(1, 2) AS x, toTypeName(x) ;

SELECT
    [1, 2] AS x,
    toTypeName(x)

Query id: e0b7b306-a943-454d-9ac7-3118b4823d71

┌─x─────┬─toTypeName(array(1, 2))─┐
│ [1,2] │ Array(UInt8)            │
└───────┴─────────────────────────┘

1 rows in set. Elapsed: 0.014 sec. 

（2）创建数组方式 2：使用方括号

hadoop102 :) SELECT [1, 2] AS x, toTypeName(x);

SELECT
    [1, 2] AS x,
    toTypeName(x)

Query id: cb94f85c-8946-4a36-8cdc-cc28d5c1e26d

┌─x─────┬─toTypeName([1, 2])─┐
│ [1,2] │ Array(UInt8)       │
└───────┴────────────────────┘

1 rows in set. Elapsed: 0.003 sec. 

ClickHouse安装部署

hkmu9248@gmail.com (Haokang Mu) — Thu, 21 Apr 2022 00:00:00 +0800

1 准备工作

1.1 确定防火墙处于关闭状态

1.2 CentOS 取消打开文件数限制

（1）在 hadoop102 的 /etc/security/limits.conf 文件的末尾加入以下内容

[mhk@hadoop102 ~]$ sudo vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

（2）在 hadoop102 的/etc/security/limits.d/20-nproc.conf 文件的末尾加入以下内容

[mhk@hadoop102 ~]$ sudo vim /etc/security/limits.d/20-nproc.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

（3）执行同步操作 xsync分发脚本

#!/bin/bash
#1. 判断参数个数
if [ $# -lt 1 ]
then
  echo Not Enough Arguement!
  exit;
fi
#2. 遍历集群所有机器
for host in hadoop102 hadoop103 hadoop104
do
  echo ====================  $host  ====================
  #3. 遍历所有目录，挨个发送
  for file in $@
  do
    #4. 判断文件是否存在
    if [ -e $file ]
    then
      #5. 获取父目录
      pdir=$(cd -P $(dirname $file); pwd)
      #6. 获取当前文件的名称
      fname=$(basename $file)
      ssh $host "mkdir -p $pdir"
      rsync -av $pdir/$fname $host:$pdir
    else
      echo $file does not exists!
    fi
  done
done

[mhk@hadoop102 ~]$ sudo /home/mhk/bin/xsync /etc/security/limits.conf
[mhk@hadoop102 ~]$ sudo /home/mhk/bin/xsync /etc/security/limits.d/20-nproc.conf

1.3 安装依赖

[mhk@hadoop102 ~]$ sudo yum install -y libtool
[mhk@hadoop102 ~]$ sudo yum install -y *unixODBC*

在 hadoop103、hadoop104 上执行以上操作

1.4 CentOS 取消 SELINUX

（1）修改/etc/selinux/config 中的 SELINUX=disabled

[mhk@hadoop102 ~]$ sudo vim /etc/selinux/config 
SELINUX=disabled 
注意：别改错了 

（2）执行同步操作

[mhk@hadoop102 ~]$ sudo /home/atguigu/bin/xsync /etc/selinux/config 

（3）重启三台服务器，修改内核级别的东西需要重启

2 单机安装

官网：https://clickhouse.tech/ 下载地址：http://repo.red-soft.biz/repos/clickhouse/stable/el7/

2.1 在 hadoop102 的/opt/software 下创建 clickhouse 目录

[mhk@hadoop102 software]$ mkdir clickhouse

2.2 将以下 4 个文件上传到 hadoop102 的 software/clickhouse 目录下

2.3 将安装文件同步到 hadoop103、hadoop104

[mhk@hadoop102 software]$ xsync clickhouse

2.4 分别在三台机子上安装这 4 个 rpm 文件

[mhk@hadoop103 clickhouse]$ sudo rpm -ivh *.rpm

[mhk@hadoop103 clickhouse]$ sudo rpm -qa|grep clickhouse
clickhouse-server-21.7.3.14-2.noarch
clickhouse-client-21.7.3.14-2.noarch
clickhouse-common-static-dbg-21.7.3.14-2.x86_64
clickhouse-common-static-21.7.3.14-2.x86_64

2.5 修改配置文件

[mhk@hadoop102 clickhouse]$ sudo vim /etc/clickhouse-server/config.xml

（1）把 :: 的注释打开，这样的话才能让 ClickHouse 被除本机以外的服务器访问

（2）分发配置文件

sudo /home/mhk/bin/xsync /etc/clickhouse-server/config.xml

在这个文件中，有 ClickHouse 的一些默认路径配置，比较重要的数据文件路径：/var/lib/clickhouse/ 日志文件路径：/var/log/clickhouse-server/clickhouse-server.log

2.6 启动 Server

[mhk@hadoop102 bin]$ sudo clickhouse start
 chown --recursive clickhouse '/var/run/clickhouse-server/'
Will run su -s /bin/sh 'clickhouse' -c '/usr/bin/clickhouse-server --config-file /etc/clickhouse-server/config.xml --pid-file /var/run/clickhouse-server/clickhouse-server.pid --daemon'
Waiting for server to start
Waiting for server to start
Server started

2.7 三台机器上关闭开机自启

[mhk@hadoop102 ~]$ sudo systemctl disable clickhouse-server
Removed symlink /etc/systemd/system/multi-user.target.wants/clickhouse-server.service.

2.8 使用 client 连接 server

[mhk@hadoop102 bin]$ clickhouse-client -m
ClickHouse client version 21.7.3.14 (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.7.3 revision 54449.

hadoop102 :) 


-m 表示可以换行，以分号来识别语句的结束

远程访问
clickhouse-client -h hadoop103 -p 端口   

clickhouse-client --query "查询语句"
类似于
hive -e ""
写SQL，我不进去，给我返回结果

hadoop102 :) show databases;

SHOW DATABASES

Query id: 0a19d7e7-274b-40b2-a25c-b0d173b6077c

┌─name────┐
│ default │
│ system  │
└─────────┘

2 rows in set. Elapsed: 0.006 sec. 

hadoop102 :) use system;

USE system

Query id: 2bca7a0e-f42d-4777-942a-8fcddee70e69

Ok.

0 rows in set. Elapsed: 0.004 sec. 

3. 其他

文件所在地 bin/ ====> /usr/bin/ conf/ ====> /etc/clickhouse-server/ lib/ ====> /var/lib/clickhouse/ log/ ====> /var/log/clickhouse/

Elasticsearch优化

hkmu9248@gmail.com (Haokang Mu) — Wed, 20 Apr 2022 00:00:00 +0800

1. 硬件选择

Elasticsearch 的基础是 Lucene，所有的索引和文档数据是存储在本地的磁盘中，具体的路径可在 ES 的配置文件../config/elasticsearch.yml 中配置，如下：

#----------------------------------- Paths------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /path/to/data
#
# Path to log files:
#
#path.logs: /path/to/logs
#

磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘，你的磁盘能处理的吞吐量越大，你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧：

使用 SSD。就像其他地方提过的，他们比机械磁盘优秀多了。
使用 RAID 0。原理是把连续的数据分散到多个磁盘中存取，这样每个磁盘并行读取可以大大提高效率。条带化 RAID 会提高磁盘 I/O，代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。
另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面，可以并行的读写。
不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。

2 分片策略

2.1 合理设置分片数

分片和副本的设计为 ES 提供了支持分布式和故障转移的特性，但并不意味着分片和副本是可以无限分配的。而且索引的分片完成分配后由于索引的路由机制，我们是不能重新修改分片数的。路由计算规则计算出分片的位置，如果修改了分片的数目，就很可能查不到

可能有人会说，我不知道这个索引将来会变得多大，并且过后我也不能更改索引的大小，所以为了保险起见，还是给它设为 1000 个分片吧。但是需要知道的是，一个分片并不是没有代价的。需要了解：

一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU 运转。
每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好，但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。
用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度。

一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断，横向扩展应当分阶段进行。为下一阶段准备好足够的资源。只有当你进入到下一个阶段，你才有时间思考需要作出哪些改变来达到这个阶段。一般来说，我们遵循一些原则：

控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32G，参考下文的 JVM 设置原则），因此，如果索引的总容量在 500G 左右，那分片大小在 16 个左右即可；当然，最好同时考虑原则 2。内存中是我们的操作，只有把内存的内容暂存到缓存中，用户才能查到，内存设的很大，操作系统的缓存就会变少
考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以，一般都设置分片数不超过节点数的 3 倍。
主分片，副本和节点最大数之间数量，我们分配的时候可以参考以下关系：

节点数<=主分片数*（副本数+1）

2.2 推迟分片分配

对于节点瞬时中断的问题，默认情况，集群会等待一分钟来查看节点是否会重新加入，如果这个节点在此期间重新加入，重新加入的节点会保持其现有的分片数据，不会触发新的分片分配。这样就可以减少 ES 在自动再平衡可用分片时所带来的极大开销。

通过修改参数 delayed_timeout ，可以延长再均衡的时间，可以全局设置也可以在索引级别进行修改:

PUT /_all/_settings 
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m" 
  } 
}

3. 路由选择

当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来:

shard = hash(routing) % number_of_primary_shards 

routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。

**不带 routing 查询 ** 在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤

分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
聚合: 协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。

特别慢

**带 routing 查询 ** 查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。

4. 写入速度优化

ES 的默认配置，是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时，我们需要根据公司要求，进行偏向性的优化。

针对于搜索性能要求不高，但是对写入要求较高的场景，我们需要尽可能的选择恰当写优化策略。综合来说，可以考虑以下几个方面来提升写索引的性能：

加大 Translog Flush ，目的是降低 Iops、Writeblock。
增加 Index Refresh 间隔，目的是减少 Segment Merge 的次数。
调整 Bulk 线程池和队列。
优化节点间的任务分布。
优化 Lucene 层的索引建立，目的是降低 CPU 及 IO。

4.1 批量数据提交

ES 提供了 Bulk API 支持批量操作，当我们有大量的写任务时，可以使用 Bulk 来进行批量写入。

通用的策略如下：Bulk 默认设置批量提交的数据量不能超过 100M。数据条数一般是根据文档的大小和服务器性能而定的，但是单次批处理的数据大小应从 5MB～15MB 逐渐增加，当性能没有提升时，把这个数据量作为最大值。

4.2 优化存储设备

ES 是一种密集使用磁盘的应用，在段合并的时候会频繁操作磁盘，所以对磁盘要求较高，当磁盘速度提升之后，集群的整体性能会大幅度提高。

4.3 合理使用合并

Lucene 以段的形式存储数据。当有新的数据写入索引时，Lucene 就会自动创建一个新的段。

随着数据量的变化，段的数量会越来越多，需要落盘的文件也越来越多，消耗的多文件句柄数及 CPU 等资源就越多，查询效率就会下降。

由于 Lucene 段合并的计算量庞大，会消耗大量的 I/O，所以 ES 默认采用较保守的策略，让后台定期进行段合并

4.4 减少 Refresh 的次数

Lucene 在新增数据时，采用了延迟写入的策略，默认情况下索引的 refresh_interval 为 1 秒。

Lucene 将待写入的数据先写到内存中，超过 1 秒（默认）时就会触发一次 Refresh，然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。

如果我们对搜索的实效性要求不高，可以将 Refresh 周期延长，例如 30 秒。文件缓存就不会频繁的刷新文件，落盘次数也会减少，提高写的效率。但这样就会消耗更多的内存

这样还可以有效地减少段刷新次数，但这同时意味着需要消耗更多的 Heap 内存。

4.5 加大 Flush 设置

Flush 的主要目的是把文件缓存系统中的段持久化到硬盘，当 Translog 的数据量达到 512MB 或者 30 分钟时，会触发一次 Flush。

index.translog.flush_threshold_size 参数的默认值是 512MB，我们进行修改。加大参数值可以减少落盘的次数，提高效率增加参数值意味着文件缓存系统中可能需要存储更多的数据，所以我们需要为操作系统的文件缓存系统留下足够的空间。

4.6 减少副本的数量

ES 为了保证集群的可用性，提供了 Replicas（副本）支持，然而每个副本也会执行分析、索引及可能的合并过程，所以 Replicas 的数量会严重影响写索引的效率。

当写索引时，需要把写入的数据都同步到副本节点，副本节点越多，写索引的效率就越慢。

如果我们需要大批量进行写入操作，可以先禁止 Replica 复制，设置index.number_of_replicas: 0 关闭副本。在写入完成后，Replica 修改回正常的状态。先禁用再恢复

5. 内存设置

ES 默认安装后设置的内存是 1GB，对于任何一个现实业务来说，这个设置都太小了。如果是通过解压安装的 ES，则在 ES 安装文件中包含一个 jvm.option 文件，添加如下命令来设置 ES 的堆大小，Xms 表示堆的初始大小，Xmx 表示可分配的最大内存，都是 1GB。

确保 Xmx 和 Xms 的大小是相同的，其目的是为了能够在 Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源，可以减轻伸缩堆大小带来的压力。

假设你有一个 64G 内存的机器，按照正常思维思考，你可能会认为把 64G 内存都给 ES 比较好，但现实是这样吗，越大越好？虽然内存对 ES 来说是非常重要的，但是答案是否定的！

内存中是我们的操作，只有把内存的内容暂存到缓存中，用户才能查到，内存设的很大，操作系统的缓存就会变少

因为 ES 堆内存的分配需要满足以下两个原则：

不要超过物理内存的 50%：Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。

Lucene 的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。如果我们设置的堆内存过大，Lucene 可用的内存将会减少，就会严重影响降低 Lucene 的全文本查询性能。

堆内存的大小最好不要超过 32GB：在 Java 中，所有对象都分配在堆上，然后有一个 Klass Pointer 指针指向它的类元数据。

这个指针在 64 位的操作系统上为 64 位，64 位的操作系统可以使用更多的内存（2^64）。在 32 位的系统上为 32 位，32 位的操作系统的最大寻址空间为 4GB（2^32）。但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如 LLC, L1 等）之间移动数据的时候，会占用更多的带宽。最终我们都会采用 31 G 设置 -Xms 31g -Xmx 31g

假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene

6. 重要配置

| 参数名 | 参数值 | 说明 | | — | — | — | | cluster.name | es-cluster | 配置 ES 的集群名称，默认值是 ES，建议改成与所存数据相关的名称，ES 会自动发现在同一网段下的集群名称相同的节点 | | node.name | node-1 | 集群中的节点名，在同一个集群中不能重复。节点的名称一旦设置，就不能再改变了。当然，也可以设置成服务器的主机名称，例如 node.name:${HOSTNAME}。 | | node.master | true | 指定该节点是否有资格被选举成为 Master 节点，默认是 True，如果被设置为 True，则只是有资格成为Master 节点，具体能否成为 Master 节点，需要通过选举产生。 | | node.data | true | 指定该节点是否存储索引数据，默认为 True。数据的增、删、改、查都是在 Data 节点完成的。 | | index.number_of_shards | 1 | 设置都索引分片个数，默认是 1 片。也可以在创建索引时设置该值，具体设置为多大都值要根据数据量的大小来定。如果数据量不大，则设置成 1 时xi效率最高 | | index.number_of_replicas | 1 | 设置默认的索引副本个数，默认为 1 个。副本数越多，集群的可用性越好，但是写索引时需要同步的数据越多。 | | transport.tcp.compress | true | 设置在节点间传输数据时是否压缩，默认为 False，不压缩 | | discovery.zen.minimum_master_nodes | 1 | 设置在选举 Master 节点时需要参与的最少的候选主节点数，默认为 1。如果使用默认值，则当网络不稳定时有可能会出现脑裂。合理的数值为 (master_eligible_nodes/2)+1 ，其中 master_eligible_nodes 表示集群中的候选主节点数 | | discovery.zen.ping.timeout | 3s | 设置在集群中自动发现其他节点时 Ping 连接的超时时间，默认为 3 秒。在较差的网络环境下需要设置得大一点，防止因误判该节点的存活状态而导致分片的转移 |

ClickHouse介绍

hkmu9248@gmail.com (Haokang Mu) — Wed, 20 Apr 2022 00:00:00 +0800

ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的列式存储数据库（DBMS），使用 C++ 语言编写，主要用于在线分析处理查询（OLAP），能够使用 SQL 查询实时生成分析数据报告。

1. ClickHouse的特点

1.1 列式存储

以下面的表为例

ID	Name	Age
1	张三	18
2	李四	22
3	王五	34

1）采用行式存储时，数据在磁盘上的组织结构为：

| 1 | 张三 | 18 | 2 | 李四 | 22 | 3 | 王五 | 34 | | — | — | — | — | — | — | — | — | — |

好处是想查找某个人的所有的属性的时候，可以通过一个磁盘查找加顺序读取就可以。但是想查所有人的年龄时，需要不停的查找，或者全表扫描才行，遍历的很多数据都是不需要的。

2）采用列式存储时，数据在磁盘上的组织结构为：

| 1 | 2 | 3 | 张三 | 李四 | 王五 | 18 | 22 | 34 | | — | — | — | — | — | — | — | — | — |

这时想查所有人的年龄只需把年龄那一列拿出来就可以了

**3）列式储存的好处： **

对于列的聚合，计数，求和等统计操作原因优于行式存储。
由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重。
由于数据压缩比更好，一方面节省了磁盘空间，另一方面对于 cache 也有了更大的发挥空间。

坏处就是插入一个人的数据效率不如行式存储

1.2 DBMS 的功能

几乎覆盖了标准 SQL 的大部分语法，包括 DDL 和 DML，以及配套的各种函数，用户管理及权限管理，数据的备份与恢复。

1.3 多样化引擎

ClickHouse 和 MySQL 类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类 20 多种引擎。

1.4 高吞吐写入能力

ClickHouse 采用类 LSM Tree的结构，数据写入后定期在后台 Compaction。通过类 LSM tree 的结构，ClickHouse 在数据导入时全部是顺序 append 写，写入后数据段不可更改，在后台 compaction 时也是多个段 merge sort 后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在 HDD 上也有着优异的写入性能。官方公开 benchmark 测试显示能够达到 50MB-200MB/s 的写入吞吐能力，按照每行 100Byte 估算，大约相当于 50W-200W 条/s 的写入速度。

1.5 数据分区与线程级并行

ClickHouse 将数据划分为多个 partition，每个 partition 再进一步划分为多个 index granularity(索引粒度)，然后通过多个 CPU核心分别处理其中的一部分来实现并行数据处理。

在这种设计下，单条 Query 就能利用整机所有 CPU。极致的并行处理能力，极大的降低了查询延时。

所以，ClickHouse 即使对于大量数据的查询也能够化整为零平行处理。但是有一个弊端就是对于单条查询使用多 cpu，就不利于同时并发多条查询。所以对于高 qps 的查询业务， ClickHouse 并不是强项。 ##

1.6 性能对比

某网站精华帖，中对几款数据库做了性能对比。
1）单表查询 2）关联查询 结论: ClickHouse 像很多 OLAP 数据库一样，单表查询速度由于关联查询，而且 ClickHouse 的两者差距更为明显。

Elasticsearch进阶

hkmu9248@gmail.com (Haokang Mu) — Tue, 19 Apr 2022 00:00:00 +0800

1. 核心概念

ES与Mysql对照表 通过对比加深理解

Elasticsearch

索引(Index)

类型(Type)

文档(Docments)

字段(Fields)


\|

关系数据库(MySQL)

数据库(DataBase)

表(Table)

行(Rows)

列(Columns)

1.1 索引（Index）

一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录就是索引的意思，目录可以提高查询速度。 **Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。 ** ##

1.2 类型（Type）

在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。不同的版本，类型发生了不同的变化

版本	Type
5.x	支持多种type
6.x	只能有一种type
7.x	默认不再支持自定义索引类型（默认类型为：_doc）

1.3 文档（Document）

一个文档是一个可被索引的基础信息单元，也就是一条数据比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON（Javascript Object Notation）格式来表示，而 JSON 是一个到处存在的互联网数据交互格式。在一个 index/type 里面，你可以存储任意多的文档。

1.4 字段（Field）

相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。

1.5 映射（Mapping）

mapping 是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

1.6 分片（Shards）

一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。分片很重要，主要有两方面的原因： 1）允许你水平分割 / 扩展你的内容容量。 2）允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。

至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。

**被混淆的概念是，一个 Lucene 索引我们在 Elasticsearch 称作分片。一个Elasticsearch 索引是分片的集合。当 Elasticsearch 在索引中搜索的时候，他发送查询到每一个属于索引的分片(Lucene 索引)，然后合并每个分片的结果到一个全局的结果集。 **

1.7 副本（Replicas）

在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。

复制分片之所以重要，有两个主要原因：

在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。

总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下，Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片（1 个完全拷贝），这样的话每个索引总共就有 2 个分片，我们需要根据索引需要确定分片个数。

1.8 分配（Allocation）

将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。

2. 系统架构

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

3. 分布式集群

我们在包含一个空节点的集群内创建名为 users 的索引，为了演示目的，我们将分配 3 个主分片和一份副本（每个主分片拥有一个副本分片）

{
  "settings" : {
    "number_of_shards" : 3,
    "number_of_replicas" : 1
  } 
}

通过 elasticsearch-head 插件查看集群情况集群健康值:green( 6 of 6 ) : 表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。主分片为黑框框住的

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有 6 个分片（3 个主分片和 3 个副本分片）的索引可以最大扩容到 6 个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

**但是如果我们想要扩容超过 6 个节点怎么办呢？ ** 主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够存储的最大数据量。（实际大小取决于你的数据、硬件和使用场景。）但是，读操作——搜索和返回数据——可以同时被主分片或副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2

{
    "number_of_replicas" : 2
}

users 索引现在拥有 9 个分片：3 个主分片和 6 个副本分片。这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。

当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。你需要增加更多的硬件资源来提升吞吐量。但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点的情况下不丢失任何数据。

应对故障

我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。

[2022-04-18T15:47:11,989][INFO ][o.e.n.Node               ] [node-1] stopping ...
[2022-04-18T15:47:12,110][INFO ][o.e.x.w.WatcherService   ] [node-1] stopping watch service, reason [shutdown initiated]
[2022-04-18T15:47:12,121][INFO ][o.e.x.w.WatcherLifeCycleService] [node-1] watcher has stopped and shutdown
[2022-04-18T15:47:12,674][INFO ][o.e.n.Node               ] [node-1] stopped
[2022-04-18T15:47:12,675][INFO ][o.e.n.Node               ] [node-1] closing ...
[2022-04-18T15:47:12,800][INFO ][o.e.n.Node               ] [node-1] closed
[mhk@hadoop102 elasticsearch-7.8.0]$ 

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node-2 。在我们关闭 Node-1 的同时也失去了主分片 1 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。幸运的是，在其它节点上存在着这个主分片的完整副本，所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片，此时集群的状态将会为yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node-2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为Node-3 为每一个分片都保留着一份副本。

如果我们重新启动 Node-1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。如果 Node-1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是 Master 节点切换了。

4. 路由计算

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

 shard = hash(routing) % number_of_primary_shards

hash( id ) % 主分片数量 = [ 0, 1, 2 ]

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。

5. 分片控制

我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。例如将所有的请求发送到 Node-1，我们将其称为 协调节点(coordinating node) 。如果访问的节点负载比较多，压力比较大，它会把请求抛给另外一个副本，这就是协调节点的含义

tips：当发送请求的时候，为了扩展负载，更好的做法是轮询集群中所有的节点。

5.1 写流程

新建、索引和删除请求都是写操作，必须在主分片上面完成之后才能被复制到相关的副本分片 新建，索引和删除文档所需要的步骤顺序：

客户端向 Node 1 发送新建、索引或者删除请求。
节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的主分片目前被分配在 Node 3 上。
Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调节点向客户端报告成功。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很少使用，因为 Elasticsearch 已经很快

5.2 读流程

我们可以从主分片或者从其它任意副本分片检索文档 从主分片或者副本分片检索文档的步骤顺序：

客户端向 Node 1 发送获取请求。
节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。在这种情况下，它将请求转发到 Node 2 。
Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。

在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

5.3 更新流程

部分更新一个文档结合了先前说明的读取和写入流程： 部分更新一个文档的步骤如下：

客户端向 Node 1 发送更新请求。
它将请求转发到主分片所在的 Node 3 。
Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改，它会重试步骤 3（抢占锁），超过 retry_on_conflict 次后放弃。
如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功。

当主分片把更改转发到副本分片时，它不会转发更新请求。相反，它转发完整文档的新版本。请记住，这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。如果 Elasticsearch 仅转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。

5.4 多文档操作流程

mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成每个分片的多文档请求，并且将这些请求并行转发到每个参与节点。

协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端 用单个 mget 请求取回多个文档所需的步骤顺序:

客户端向 Node 1 发送 mget 请求。
Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客户端。

可以对 docs 数组中每个文档设置 routing 参数。

bulk API，允许在单个批量请求中执行多个创建、索引、删除和更新请求。 bulk API 按如下步骤顺序执行：

客户端向 Node 1 发送 bulk 请求。
Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。

6. 分片原理

分片是 Elasticsearch 最小的工作单元。但是究竟什么是一个分片，它是如何工作的？

传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值需求的数据结构是倒排索引。

6.1 倒排索引

Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。

见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），反向索引（inverted index）更熟悉的名字是倒排索引。

所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个 ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。例如，假设我们有两个文档，每个文档的 content 域包含如下内容：

The quick brown fox jumped over the lazy dog
Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的词（我们称它为词条或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单相似性算法，那么我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。
jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。

使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。

我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：

Quick 可以小写化为 quick 。
foxes 可以词干提取 –变为词根的格式– 为 fox 。类似的， dogs 可以为提取为 dog 。
jumped 和 leap 是同义词，可以索引为相同的单词 jump 。

现在索引看上去像这样：这还远远不够。我们搜索 +Quick +fox 仍然会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox，这样两个文档都会匹配！分词和标准化的过程称为分析这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。

词条：索引中最小存储和查询单元，英文当中就是一个单词，中文当中一般就是一个词组词典：字典，是词条的集合，底层一般会用两种数据结构来实现，B+树和HashMap 倒排表：每条记录被称为一个倒排项。表示查询的词条在什么位置，出现的频率是多少。

倒排索引的搜索过程：搜索的时候查询单词的词典，看看单词在不在词典当中，如果不在搜索就结束了，如果在词典当中的话，它要看一看单词在倒排表中的指针，通过倒排表去获取文档对应的ID的列表，然后拿着ID去对应数据

6.2 文档搜索

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。倒排索引被写入磁盘后是不可改变的 : 它永远不会修改。

不变性有重要的价值：

不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。减少磁盘I/O
其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和需要被缓存到内存的索引的使用量。

当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如果你需要让一个新的文档可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。如果更新频率比较高，性能就会变差

6.3 动态更新索引

如何在保留不变性的前提下实现倒排索引的更新？

答案是: 用更多的索引。通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到，从最早的开始查询完后再对结果进行合并。

Elasticsearch 基于 Lucene, 这个 java 库引入了按段搜索的概念。每一段本身都是一个倒排索引，但索引在 Lucene 中除表示所有段的集合外，还增加了提交点的概念 —— 一个列出了所有已知段的文件

按段搜索会以如下流程执行：

新文档被收集到内存索引缓存

不时地, 缓存被提交

(1) 一个新的段—— 一个追加的倒排索引 ——被写入磁盘。 (2) 一个新的包含新段名字的提交点被写入磁盘 (3) 磁盘进行同步 —— 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件

新的段被开启，让它包含的文档可见以被搜索
内存缓存被清空，等待接收新的文档

当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以保证每个词和每个文档的关联都被准确计算。这种方式可以用相对较低的成本将新文档添加到索引。

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

6.4 近实时搜索

es并非是实时的，而是准实时的，原因在于es的数据搜索是基于分段搜索，es中的每一段其实就是一个倒排索引，最新的数据更新会体现在最新的段中，而最新的段落盘之后es软件才能进行数据的搜索，这样的话，磁盘的I/O性能就极大的影响了查询的效率。但是反过来想想，全文搜索引擎的设计的目的不就是能快速的准确的获取有效的数据吗？所以，降低数据查询处理的延迟就显得尤为重要随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索，但这样还是不够快。磁盘在这里成为了瓶颈。提交（Commiting）一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。

我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。在 Elasticsearch 和磁盘之间是文件系统缓存。像之前描述的一样，在内存索引缓冲区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存 —— 这一步代价会比较低，稍后再被刷新到磁盘 —— 这一步代价比较高。不过只要文件已经在缓存中，就可以像其它文件一样被打开和读取了。 Lucene 允许新段被写入和打开——使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新: /users/_refresh

尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候，手动刷新很有用，但是不要在生产环境下每次索引一个文档都去手动刷新。相反，你的应用需要意识到 Elasticsearch 的近实时的性质，并接受它的不足。

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件，你可能想优化索引速度而不是近实时搜索，可以通过设置 refresh_interval ，降低每个索引的刷新频率

{
  "settings": {
      "refresh_interval": "30s" 
    } 
}

refresh_interval 可以在既存索引上进行动态更新。在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来

# 关闭自动刷新
PUT /users/_settings
{ "refresh_interval": -1 } 

# 每一秒刷新
PUT /users/_settings
{ "refresh_interval": "1s" }

6.5 持久化变更

如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。在动态更新索引，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录

整个流程如下：

一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog

刷新（refresh）使分片每秒被刷新（refresh）一次：
- 这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
- 这个段被打开，使其可被搜索
- 内存缓冲区被清空

这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志

每隔一段时间—例如 translog 变得越来越大—索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行
- 所有在内存缓冲区的文档都被写入一个新的段。
- 缓冲区被清空。
- 一个提交点被写入硬盘。
- 文件系统缓存通过 fsync 被刷新（flush）。
- 老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前，首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候也会刷新

你很少需要自己手动执行 flush 操作；通常情况下，自动刷新就足够了。这就是说，在重启节点或关闭索引之前执行 flush 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引，它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。

translog 的目的是保证操作不会丢失，在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘，或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终，基本上，这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。

在每次请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。

但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。如果你决定使用异步 translog 的话，你需要保证在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。如果你不确定这个行为的后果，最好是使用默认的参数（ “index.translog.durability”: “request” ）来避免数据丢失。

6.6 段合并

由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

启动段合并不需要你做任何事。进行索引和搜索时会自动进行。

当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。
合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

一旦合并结束，老的段被删除
- 新的段被刷新（flush）到了磁盘。写入一个包含新段且排除旧的和较小的段的新提交点。
- 新的段被打开用来搜索。
- 老的段被删除

合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

7. 文档分析

分析包含下面的过程：

将一块文本分成适合于倒排索引的独立的词条
将这些词条统一化为标准格式以提高它们的“可搜索性”，或者 recall

分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里：

字符过滤器

首先，字符串按顺序通过每个字符过滤器。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉 HTML，或者将 & 转化成 and。

分词器

其次，字符串被分词器分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。

Token 过滤器

最后，词条按顺序通过每个 token 过滤器。这个过程可能会改变词条（例如，小写化 Quick ），删除词条（例如，像 a， and， the 等无用词），或者增加词条（例如，像 jump 和 leap 这种同义词）。

7.1 内置分析器

Elasticsearch 还附带了可以直接使用的预包装的分析器。接下来我们会列出最重要的分析器。为了证明它们的差异，我们看看每个分析器会从下面的字符串得到哪些词条：

"Set the shape to semi-transparent by calling set_trans(5)"

标准分析器

标准分析器是 Elasticsearch 默认使用的分析器。它是分析各种语言文本最常用的选择。它根据 Unicode 联盟定义的单词边界划分文本。删除绝大部分标点。最后，将词条小写。它会产生： set, the, shape, to, semi, transparent, by, calling, set_trans, 5

简单分析器

简单分析器在任何不是字母的地方分隔文本，将词条小写。它会产生： set, the, shape, to, semi, transparent, by, calling, set, trans

空格分析器

空格分析器在空格的地方划分文本。它会产生： Set, the, shape, to, semi-transparent, by, calling, set_trans(5)

语言分析器

特定语言分析器可用于很多语言。它们可以考虑指定语言的特点。例如，英语分析器附带了一组英语无用词（常用单词，例如 and 或者 the ，它们对相关性没有多少影响），它们会被删除。由于理解英语语法的规则，这个分词器可以提取英语单词的词干。英语分词器会产生下面的词条： set, shape, semi, transpar, call, set_tran, 5 注意看 transparent、 calling 和 set_trans 已经变为词根格式

7.2 分析器使用场景

当我们索引一个文档，它的全文域被分析成词条以用来创建倒排索引。但是，当我们在全文域搜索的时候，我们需要将查询字符串通过相同的分析过程，以保证我们搜索的词条格式与索引中的词条格式一致。

全文查询，理解每个域是如何定义的，因此它们可以做正确的事：

当你查询一个全文域时，会对查询字符串应用相同的分析器，以产生正确的搜索词条列表。
当你查询一个精确值域时，不会分析查询字符串，而是搜索你指定的精确值。

7.3 测试分析器

有些时候很难理解分词的过程和实际被存储到索引中的词条，特别是你刚接触Elasticsearch。为了理解发生了什么，你可以使用 analyze API 来看文本是如何被分析的。

在消息体里，指定分析器和要分析的文本

GET http://10.211.55.11:9200/_analyze

{
  "analyzer": "standard",
  "text": "Text to analyze"
}

结果中每个元素代表一个单独的词条：

{
    "tokens": [
        {
            "token": "text",
            "start_offset": 0,
            "end_offset": 4,
            "type": "<ALPHANUM>",
            "position": 0
        },
        {
            "token": "to",
            "start_offset": 5,
            "end_offset": 7,
            "type": "<ALPHANUM>",
            "position": 1
        },
        {
            "token": "analyze",
            "start_offset": 8,
            "end_offset": 15,
            "type": "<ALPHANUM>",
            "position": 2
        }
    ]
}

token 是实际存储到索引中的词条。 position 指明词条在原始文本中出现的位置。 start_offset 和 end_offset 指明字符在原始字符串中的位置。

7.4 指定分析器

当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文字符串域，使用标准分析器对它进行分析。你不希望总是这样。可能你想使用一个不同的分析器，适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域——不使用分析，直接索引你传入的精确值，例如用户 ID 或者一个内部的状态域或标签。要做到这一点，我们必须手动指定这些域的映射。

7.5 IK 分词器

首先我们通过 Postman 发送 **GET **请求查询分词效果

{
  "text":"测试单词" 
}

ES 的默认分词器无法识别中文中测试、单词这样的词汇，而是简单的将每个字拆完分为一个词

{
    "tokens": [
        {
            "token": "测",
            "start_offset": 0,
            "end_offset": 1,
            "type": "<IDEOGRAPHIC>",
            "position": 0
        },
        {
            "token": "试",
            "start_offset": 1,
            "end_offset": 2,
            "type": "<IDEOGRAPHIC>",
            "position": 1
        },
        {
            "token": "单",
            "start_offset": 2,
            "end_offset": 3,
            "type": "<IDEOGRAPHIC>",
            "position": 2
        },
        {
            "token": "词",
            "start_offset": 3,
            "end_offset": 4,
            "type": "<IDEOGRAPHIC>",
            "position": 3
        }
    ]
}

这样的结果显然不符合我们的使用要求，所以我们需要下载 ES 对应版本的中文分词器。

我们这里采用 IK 中文分词器，下载地址为: https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.8.0 将解压后的后的文件夹放入 ES 根目录下的 plugins 目录下，重启 ES 即可使用。我们这次加入新的查询参数”analyzer”:”ik_max_word”

{
  "text":"中国人",
  "analyzer":"ik_max_word"
}

ik_max_word：会将文本做最细粒度的拆分
ik_smart：会将文本做最粗粒度的拆分

使用中文分词后的结果为：

{
    "tokens": [
        {
            "token": "中国人",
            "start_offset": 0,
            "end_offset": 3,
            "type": "CN_WORD",
            "position": 0
        },
        {
            "token": "中国",
            "start_offset": 0,
            "end_offset": 2,
            "type": "CN_WORD",
            "position": 1
        },
        {
            "token": "国人",
            "start_offset": 1,
            "end_offset": 3,
            "type": "CN_WORD",
            "position": 2
        }
    ]
}

{
  "text":"中国人",
  "analyzer":"ik_smart"
}

{
    "tokens": [
        {
            "token": "中国人",
            "start_offset": 0,
            "end_offset": 3,
            "type": "CN_WORD",
            "position": 0
        }
    ]
}

ES 中也可以进行扩展词汇，首先查询

{
  "text":"弗雷尔卓德",
  "analyzer":"ik_max_word"
}

{
    "tokens": [
        {
            "token": "弗",
            "start_offset": 0,
            "end_offset": 1,
            "type": "CN_CHAR",
            "position": 0
        },
        {
            "token": "雷",
            "start_offset": 1,
            "end_offset": 2,
            "type": "CN_CHAR",
            "position": 1
        },
        {
            "token": "尔",
            "start_offset": 2,
            "end_offset": 3,
            "type": "CN_CHAR",
            "position": 2
        },
        {
            "token": "卓",
            "start_offset": 3,
            "end_offset": 4,
            "type": "CN_CHAR",
            "position": 3
        },
        {
            "token": "德",
            "start_offset": 4,
            "end_offset": 5,
            "type": "CN_CHAR",
            "position": 4
        }
    ]
}

仅仅可以得到每个字的分词结果，我们需要做的就是使分词器识别到弗雷尔卓德也是一个词语

首先进入 ES 根目录中的 plugins 文件夹下的 ik 文件夹，进入 config 目录，创建 custom.dic 文件，写入弗雷尔卓德。同时打开 IKAnalyzer.cfg.xml 文件，将新建的 custom.dic 配置其中，重启 ES 服务器。

7.6 自定义分析器

虽然 Elasticsearch 带有一些现成的分析器，然而在分析器上 Elasticsearch 真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单元过滤器来创建自定义的分析器。在分析与分析器我们说过，一个分析器就是在一个包里面组合了三种函数的一个包装器，三种函数按照顺序被执行:

**字符过滤器 **

字符过滤器用来整理一个尚未被分词的字符串。例如，如果我们的文本是 HTML 格式的，它会包含像 <p> 或者 <div> 这样的 HTML 标签，这些标签是我们不想索引的。我们可以使用 html 清除字符过滤器来移除掉所有的 HTML 标签，并且像把 Á 转换为相对应的 Unicode 字符 Á 这样，转换 HTML 实体。一个分析器可能有 0 个或者多个字符过滤器。

**分词器 **

一个分析器必须有一个唯一的分词器。分词器把字符串分解成单个词条或者词汇单元。标准分析器里使用的标准分词器把一个字符串根据单词边界分解成单个词条，并且移除掉大部分的标点符号，然而还有其他不同行为的分词器存在。例如，关键词分词器完整地输出接收到的同样的字符串，并不做任何分词。空格分词器只根据空格分割文本。正则分词器根据匹配正则表达式来分割文本。

**词单元过滤器 **

经过分词，作为结果的词单元流会按照指定的顺序通过指定的词单元过滤器。词单元过滤器可以修改、添加或者移除词单元。我们已经提到过 lowercase 和 stop 词过滤器，但是在 Elasticsearch 里面还有很多可供选择的词单元过滤器。词干过滤器把单词遏制为词干。 ascii_folding 过滤器移除变音符，把一个像 “très” 这样的词转换为 “tres” 。ngram 和 edge_ngram 词单元过滤器可以产生适合用于部分匹配或者自动补全的词单元。

接下来，我们看看如何创建自定义的分析器：

# PUT http://10.211.55.11:9200/my_index
{
  "settings": {
    "analysis": {
      "char_filter": {
        "&_to_and": {
          "type": "mapping",
          "mappings": [ "&=> and "]
      }},
      "filter": {
        "my_stopwords": {
          "type": "stop",
          "stopwords": [ "the", "a" ]
      }},
      "analyzer": {
        "my_analyzer": {
          "type": "custom",
          "char_filter": [ "html_strip", "&_to_and" ],
          "tokenizer": "standard",
          "filter": [ "lowercase", "my_stopwords" ]
      }}
}}}

索引被创建以后，使用 analyze API 来测试这个新的分析器

{
  "text":"The quick & brown fox",
  "analyzer": "my_analyzer"
}

{
    "tokens": [
        {
            "token": "quick",
            "start_offset": 4,
            "end_offset": 9,
            "type": "<ALPHANUM>",
            "position": 1
        },
        {
            "token": "and",
            "start_offset": 10,
            "end_offset": 11,
            "type": "<ALPHANUM>",
            "position": 2
        },
        {
            "token": "brown",
            "start_offset": 12,
            "end_offset": 17,
            "type": "<ALPHANUM>",
            "position": 3
        },
        {
            "token": "fox",
            "start_offset": 18,
            "end_offset": 21,
            "type": "<ALPHANUM>",
            "position": 4
        }
    ]
}

8 文档处理

8.1 文档冲突

当我们使用 index API 更新文档，可以一次性读取原始文档，做我们的修改，然后重新索引整个文档。最近的索引请求将获胜：无论最后哪一个文档被索引，都将被唯一存储在 Elasticsearch 中。如果其他人同时更改这个文档，他们的更改将丢失。全量更新还好，如果是局部更新，你把别人这个数据改了，别人把你那个数据改了，这就会有冲突

很多时候这是没有问题的。也许我们的主数据存储是一个关系型数据库，我们只是将数据复制到Elasticsearch 中并使其可被搜索。也许两个人同时更改相同的文档的几率很小。或者对于我们的业务来说偶尔丢失更改并不是很严重的问题。

但有时丢失了一个变更就是非常严重的。试想我们使用 Elasticsearch 存储我们网上商城商品库存的数量，每次我们卖一个商品的时候，我们在 Elasticsearch 中将库存数量减少。有一天，管理层决定做一次促销。突然地，我们一秒要卖好几个商品。假设有两个 web 程序并行运行，每一个都同时处理所有商品的销售 web_1 对 stock_count 所做的更改已经丢失，因为 web_2 不知道它的 stock_count 的拷贝已经过期。结果我们会认为有超过商品的实际数量的库存，因为卖给顾客的库存商品并不存在，我们将让他们非常失望。变更越频繁，读数据和更新数据的间隙越长，也就越可能丢失变更。

在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：

**悲观并发控制 **

这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。性能比较低，加锁阻塞其他用户的访问

**乐观并发控制 **

Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。

8.2 乐观并发控制

Elasticsearch 是分布式的。当文档创建、更新或删除时，新版本的文档必须复制到集群中的其他节点。Elasticsearch 也是异步和并发的，这意味着这些复制请求被并行发送，并且到达目的地时也许顺序是乱的。 Elasticsearch 需要一种方法确保文档的旧版本不会覆盖新的版本。

当我们之前讨论 index ，GET 和 delete 请求时，我们指出每个文档都有一个 _version（版本）号，当文档被修改时版本号递增。 Elasticsearch 使用这个 version 号来确保变更以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。

我们可以利用 version 号来确保应用中相互冲突的变更不会导致数据丢失。我们通过指定想要修改文档的 version 号来达到这个目的。如果该版本不是当前版本号，我们的请求将会失败。

老的版本 es 使用 version，但是新版本不支持了，会报下面的错误，提示我们用 if_seq_no 和 if_primary_term

{
  "error": {
    "root_cause": [
      {
        "type": "action_request_validation_exception",
        "reason": "Validation Failed: 1: internal versioning can not be used for optimistic concurrency control. Please use `if_seq_no` and `if_primary_term` instead;"
      }
    ],
    "type": "action_request_validation_exception",
    "reason": "Validation Failed: 1: internal versioning can not be used for optimistic concurrency control. Please use `if_seq_no` and `if_primary_term` instead;"
   },
   "status": 400
}

8.3 外部系统版本控制

一个常见的设置是使用其它数据库作为主要的数据存储，使用 Elasticsearch 做数据检索，这意味着主数据库的所有更改发生时都需要被复制到 Elasticsearch ，如果多个进程负责这一数据同步，你可能遇到类似于之前描述的并发问题。

如果你的主数据库已经有了版本号 —— 或一个能作为版本号的字段值比如 timestamp —— 那么你就可以在 Elasticsearch 中通过增加 version_type=external 到查询字符串的方式重用这些相同的版本号，版本号必须是大于零的整数，且小于 9.2E+18 — 一个 Java 中 long 类型的正值。

外部版本号的处理方式和我们之前讨论的内部版本号的处理方式有些不同，Elasticsearch 不是检查当前 _version 和请求中指定的版本号是否相同，而是检查当前 _version 是否小于指定的版本号。如果请求成功，外部的版本号作为文档的新 _version 进行存储。

当前版本为5

使用version=1去查找就会报错外部版本号不仅在索引和删除请求是可以指定，而且在创建新文档时也可以指定。

Elasticsearch集群部署

hkmu9248@gmail.com (Haokang Mu) — Mon, 18 Apr 2022 00:00:00 +0800

1. 事先提醒

首先准备安装包，然后重新解压万万不可将hadoop102节点上的 elasticsearch-7.8.0/ 分发到其他节点，这样会导致集群中只有hadoop102这一个节点，因为我们本来部署单点模式的时候用了es做了好多次案例，es会存储data

2. 解压压缩包

[mhk@hadoop102 software]$ tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz -C /opt/module/

分发

[mhk@hadoop102 module]$ xsync elasticsearch-7.8.0/

3. 修改配置文件

修改/opt/module/es/config/elasticsearch.yml 文件，分发文件

#集群名称
cluster.name: cluster-es

#节点名称，每个节点的名称不能重复
node.name: node-1

#ip 地址，每个节点的地址不能重复
network.host: hadoop102

#是不是有资格主节点
node.master: true
node.data: true
http.port: 9200

# head 插件需要这打开这两个配置
http.cors.allow-origin: "*"
http.cors.enabled: true
http.max_content_length: 200mb

#es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举 master
cluster.initial_master_nodes: ["node-1"]

#es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["hadoop102:9300","hadoop103:9300","hadoop104:9300"]
gateway.recover_after_nodes: 2
network.tcp.keep_alive: true
network.tcp.no_delay: true
transport.tcp.compress: true

#集群内同时启动的数据任务个数，默认是 2 个
cluster.routing.allocation.cluster_concurrent_rebalance: 16

#添加或删除节点及负载均衡时并发恢复的线程个数，默认 4 个
cluster.routing.allocation.node_concurrent_recoveries: 16

#初始化数据恢复时，并发恢复线程的个数，默认 4 个
cluster.routing.allocation.node_initial_primaries_recoveries: 16

分发后，hadoop102，hadoop103两台节点修改名称和地址

修改/etc/security/limits.conf ，分发文件

* 	 soft 		nofile 		65536
*		 hard 		nofile 		65536

修改/etc/security/limits.d/20-nproc.conf，分发文件

# 在文件末尾中增加下面内容
* 		soft 		nofile 		65536
* 		hard 		nofile 		65536
* 		hard 		nproc 		4096
# 注：* 带表 Linux 所有用户名称

修改/etc/sysctl.conf

vm.max_map_count=655360

重新加载

sysctl -p

4. 启动软件

分别在不同节点上启动 ES 软件

cd /opt/module/elasticsearch-7.8.0
#启动
bin/elasticsearch
#后台启动
bin/elasticsearch -d

5. 测试集群

Elasticsearch JavaAPI操作

hkmu9248@gmail.com (Haokang Mu) — Mon, 18 Apr 2022 00:00:00 +0800

1. 创建Maven项目，添加依赖

<dependencies>
  <dependency>
    <groupId>org.elasticsearch</groupId>
    <artifactId>elasticsearch</artifactId>
    <version>7.8.0</version>
  </dependency>
  <!-- elasticsearch 的客户端 -->
  <dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
    <version>7.8.0</version>
  </dependency>
  <!-- elasticsearch 依赖 2.x 的 log4j -->
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.8.2</version>
  </dependency>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.8.2</version>
  </dependency>
  <dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.9.9</version>
  </dependency>
  <!-- junit 单元测试 -->
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
  </dependency>
    </dependencies>

2. 创建客户端对象

public class ESTest_Client {
    public static void main(String[] args) throws IOException {
        
        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
            RestClient.builder(new HttpHost("hadoop102",9200))
        );
        
        //关闭ES客户端
        esClient.close();
    }
}

3. 索引操作

3.1 创建索引

public class ESTest_Index_Create {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //创建索引
        CreateIndexRequest request = new CreateIndexRequest("users");
        CreateIndexResponse response = esClient.indices().create(request, RequestOptions.DEFAULT);

        //响应状态
        boolean acknowledged = response.isAcknowledged();
        System.out.println("索引操作：" + acknowledged);

        //关闭ES客户端
        esClient.close();
    }
}

前往postman查看有没有创建成功

3.2 查看索引

public class ESTest_Index_Search {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //查询索引
        GetIndexRequest request = new GetIndexRequest("users");
        GetIndexResponse response = esClient.indices().get(request, RequestOptions.DEFAULT);

        //响应状态
        System.out.println(response.getAliases());
        System.out.println(response.getMappings());
        System.out.println(response.getSettings());

        //关闭ES客户端
        esClient.close();
    }
}

3.3 删除索引

public class ESTest_Index_Delete {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //查询索引
        DeleteIndexRequest request = new DeleteIndexRequest("users");
        AcknowledgedResponse response = esClient.indices().delete(request, RequestOptions.DEFAULT);

        //响应状态
        System.out.println(response.isAcknowledged());

        //关闭ES客户端
        esClient.close();
    }
}

前往postman确认已经被删除

4. 文档操作

4.1 新增文档

创建数据模型

public class Users {
    private String name;
    private String sex;
    private Integer age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getSex() {
        return sex;
    }

    public void setSex(String sex) {
        this.sex = sex;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }
}

public class ESTest_Doc_Insert {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //插入数据
        IndexRequest request = new IndexRequest();
        request.index("users").id("1001");

        Users users = new Users();
        users.setName("zhangsan");
        users.setAge(22);
        users.setSex("男");

        //向ES插入数据，必须将数据转换成JSON格式
        ObjectMapper mapper = new ObjectMapper();
        String usersJson = mapper.writeValueAsString(users);
        request.source(usersJson, XContentType.JSON);

        IndexResponse response = esClient.index(request, RequestOptions.DEFAULT);
        System.out.println(response.getResult());

        //关闭ES客户端
        esClient.close();
    }
}

4.2 修改文档

public class ESTest_Doc_Update {
    public static void main(String[] args) throws IOException {
        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //修改数据
        UpdateRequest request = new UpdateRequest();
        request.index("users").id("1001");
        request.doc(XContentType.JSON,"name","李四");

        UpdateResponse response = esClient.update(request, RequestOptions.DEFAULT);
        
        System.out.println(response.getResult());

        //关闭ES客户端
        esClient.close();
    }
}

4.3 查询文档

public class ESTest_Doc_Get {
    public static void main(String[] args) throws IOException {
        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //查询数据
        GetRequest request = new GetRequest();
        request.index("users").id("1001");

        GetResponse response = esClient.get(request, RequestOptions.DEFAULT);

        System.out.println(response.getSourceAsString());

        //关闭ES客户端
        esClient.close();
    }
}

4.4 删除文档

public class ESTest_Doc_Delete {
    public static void main(String[] args) throws IOException {
        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        DeleteRequest request = new DeleteRequest();
        request.index("users").id("1001");

        DeleteResponse response = esClient.delete(request, RequestOptions.DEFAULT);

        System.out.println(response.toString());

        //关闭ES客户端
        esClient.close();
    }
}

4.5 批量新增

public class ESTest_Doc_Insert_Batch {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //批量插入数据
        BulkRequest request = new BulkRequest();
        request.add(new IndexRequest().index("users").id("1001").source(XContentType.JSON,"name","张三"));
        request.add(new IndexRequest().index("users").id("1002").source(XContentType.JSON,"name","李四"));
        request.add(new IndexRequest().index("users").id("1003").source(XContentType.JSON,"name","王五"));

        BulkResponse response = esClient.bulk(request, RequestOptions.DEFAULT);
        System.out.println(response.getTook());
        System.out.println(response.getItems());

        //关闭ES客户端
        esClient.close();
    }
}

4.6 批量删除

public class ESTest_Doc_Delete_Batch {
    public static void main(String[] args) throws IOException {

        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //批量删除数据
        BulkRequest request = new BulkRequest();

        request.add(new DeleteRequest().index("user").id("1001"));
        request.add(new DeleteRequest().index("user").id("1002"));
        request.add(new DeleteRequest().index("user").id("1003"));
        BulkResponse response = esClient.bulk(request, RequestOptions.DEFAULT);
        System.out.println(response.getTook());
        System.out.println(response.getItems());

        //关闭ES客户端
        esClient.close();
    }
}

4.7 全量查询

public class ESTest_Doc_Query {
    public static void main(String[] args) throws IOException {
        //创建ES客户端
        RestHighLevelClient esClient = new RestHighLevelClient(
                RestClient.builder(new HttpHost("hadoop102",9200))
        );

        //全量查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        request.source(new SearchSourceBuilder().query(QueryBuilders.matchAllQuery()));

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

        //关闭ES客户端
        esClient.close();
    }
}

4.8 条件查询

        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件termQuery
        request.source(new SearchSourceBuilder().query(QueryBuilders.termQuery("age",30)));

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.9 分页查询

        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder().query(QueryBuilders.matchAllQuery());
        //（当前页码-1）* 每页显示的条数
        builder.from(0);
        builder.size(2);    //每页两条数据
        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.10 查询排序

        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder().query(QueryBuilders.matchAllQuery());
        builder.sort("age", SortOrder.DESC);
        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.11 过滤字段

        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder().query(QueryBuilders.matchAllQuery());

        String[] excludes = {};
        String[] includes = {"name"};
        builder.fetchSource(includes,excludes);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.11 组合查询

        //6. 组合查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        BoolQueryBuilder boolQueryBuilder = QueryBuilders.boolQuery();
//        boolQueryBuilder.must(QueryBuilders.matchQuery("age",30));
//        boolQueryBuilder.must(QueryBuilders.matchQuery("sex","男"));
//        boolQueryBuilder.mustNot(QueryBuilders.matchQuery("sex","男"));
        boolQueryBuilder.should(QueryBuilders.matchQuery("age",30));
        boolQueryBuilder.should(QueryBuilders.matchQuery("age",40));

        builder.query(boolQueryBuilder);
        
        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.12 范围查询

        //7. 范围查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        RangeQueryBuilder rangeQuery = QueryBuilders.rangeQuery("age");

        rangeQuery.gte(30);
        rangeQuery.lte(40);

        builder.query(rangeQuery);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.13 模糊查询

        //7. 模糊查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        FuzzyQueryBuilder fuzziness = QueryBuilders.fuzzyQuery("name", "王五").fuzziness(Fuzziness.ONE);//差一个字符

        builder.query(fuzziness);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.14 高亮查询

       //8. 高亮查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        TermQueryBuilder termQueryBuilder = QueryBuilders.termQuery("name", "张三");

        HighlightBuilder highlightBuilder = new HighlightBuilder();
        highlightBuilder.preTags("<font color ='red'>");
        highlightBuilder.postTags("</font>");
        highlightBuilder.field("name");

        builder.highlighter(highlightBuilder);
        builder.query(termQueryBuilder);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.15 聚合查询

        //9. 聚合查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        AggregationBuilder aggregationBuilder = AggregationBuilders.max("maxAge").field("age");

        builder.aggregation(aggregationBuilder);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

4.16 分组查询

        //10. 分组查询
        SearchRequest request = new SearchRequest();
        request.indices("users");

        //构造查询条件
        SearchSourceBuilder builder = new SearchSourceBuilder();
        AggregationBuilder aggregationBuilder = AggregationBuilders.terms("ageGroup").field("age");

        builder.aggregation(aggregationBuilder);

        request.source(builder);

        SearchResponse response = esClient.search(request, RequestOptions.DEFAULT);

        SearchHits hits = response.getHits();

        System.out.println(response.getTook());
        System.out.println(hits.getTotalHits());

        for (SearchHit hit : hits) {
            System.out.println(hit.getSourceAsString());
        }

Elasticsearch安装部署

hkmu9248@gmail.com (Haokang Mu) — Sun, 17 Apr 2022 00:00:00 +0800

1. 下载软件

Elasticsearch 的官方地址：https://www.elastic.co/cn/
我选择 7.8.0 版本

2. 安装软件

2.1 将软件从本地上传到Linux

[mhk@hadoop102 software]$ ll

-rw-rw-r--. 1 mhk  mhk  319112561 3月  16 16:22 elasticsearch-7.8.0-linux-x86_64.tar.gz

2.2 解压缩到指定路径

[mhk@hadoop102 software]$ tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz -C /opt/module/

2.3 运行bin目录下的启动脚本

[mhk@hadoop102 elasticsearch-7.8.0]$ bin/elasticsearch
...
[2022-04-16T16:36:09,824][INFO ][o.e.h.AbstractHttpServerTransport] [hadoop102] publish_address {127.0.0.1:9200}, bound_addresses {[::1]:9200}, {127.0.0.1:9200}
[2022-04-16T16:36:09,826][INFO ][o.e.n.Node               ] [hadoop102] started
[2022-04-16T16:36:11,078][INFO ][o.e.l.LicenseService     ] [hadoop102] license [7ee9cff5-bb62-4949-b1b9-86535854a73e] mode [basic] - valid
[2022-04-16T16:36:11,081][INFO ][o.e.x.s.s.SecurityStatusChangeListener] [hadoop102] Active license is now [BASIC]; Security is disabled
[2022-04-16T16:36:11,391][INFO ][o.e.g.GatewayService     ] [hadoop102] recovered [0] indices into cluster_state

2.4 配置远程访问

打开 config/ 目录下的 elasticsearch.yml，修改配置

[mhk@hadoop102 elasticsearch-7.8.0]$ cd config/
[mhk@hadoop102 config]$ ll
总用量 40
-rw-rw----. 1 mhk mhk   199 4月  16 16:24 elasticsearch.keystore
-rw-rw----. 1 mhk mhk  2813 4月  16 17:16 elasticsearch.yml
-rw-rw----. 1 mhk mhk  2301 6月  15 2020 jvm.options
drwxr-x---. 2 mhk mhk     6 6月  15 2020 jvm.options.d
-rw-rw----. 1 mhk mhk 17419 6月  15 2020 log4j2.properties
-rw-rw----. 1 mhk mhk   473 6月  15 2020 role_mapping.yml
-rw-rw----. 1 mhk mhk   197 6月  15 2020 roles.yml
-rw-rw----. 1 mhk mhk     0 6月  15 2020 users
-rw-rw----. 1 mhk mhk     0 6月  15 2020 users_roles

[mhk@hadoop102 config]$ vim elasticsearch.yml

network.host: 0.0.0.0

再次运行启动脚本，发现报错

ERROR: [2] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[3]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
ERROR: Elasticsearch did not exit normally - check the logs at /opt/module/elasticsearch-7.8.0/logs/elasticsearch.log

针对这三点，逐个击破 1、Linux系统的soft、hard值配置过低，至少65535

vim /etc/security/limits.conf
#*               soft    core            0
#*               hard    rss             10000
*               soft    nofile           65535
*               hard    nofile           65535

建议重启虚拟机

2、Linux系统vm.max_map_count值配置过低，至少262144

vim /etc/sysctl.conf
vm.max_map_count=262144
#sysctl -p   生效
[mhk@hadoop102 etc]$ sysctl -p
vm.max_map_count = 262144

3、缺少默认配置 至少需要配置 discovery.seed_hosts、discovery.seed_providers、cluster.initial_master_nodes 中的一个参数.

discovery.seed_hosts: 集群主机列表
discovery.seed_providers: 基于配置文件配置集群主机列表
cluster.initial_master_nodes: 启动时初始化的参与选主的node，生产环境必填 ```shell vim config/elasticsearch.yml

#添加配置 discovery.seed_hosts: [“hadoop102”]

cluster.initial_master_nodes: [“hadoop102”]

## 2.5 重启软件，访问web界面
[http://10.211.55.11:9200/](http://10.211.55.11:9200/)
```shell
[mhk@hadoop102 elasticsearch-7.8.0]$ bin/elasticsearch
...
[2022-04-16T17:46:23,701][INFO ][o.e.h.AbstractHttpServerTransport] [hadoop102] publish_address {10.211.55.11:9200}, bound_addresses {[::]:9200}
[2022-04-16T17:46:23,725][INFO ][o.e.n.Node               ] [hadoop102] started
[2022-04-16T17:46:25,348][INFO ][o.e.l.LicenseService     ] [hadoop102] license [7ee9cff5-bb62-4949-b1b9-86535854a73e] mode [basic] - valid
[2022-04-16T17:46:25,352][INFO ][o.e.x.s.s.SecurityStatusChangeListener] [hadoop102] Active license is now [BASIC]; Security is disabled
[2022-04-16T17:46:25,496][INFO ][o.e.g.GatewayService     ] [hadoop102] recovered [0] indices into cluster_state

Elasticsearch基本操作

hkmu9248@gmail.com (Haokang Mu) — Sun, 17 Apr 2022 00:00:00 +0800

1.RESTful

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。

在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEAD 和 OPTIONS。简单的理解就是，如果想要访问互联网上的资源，就必须向资源所在的服务器发出请求，请求体中必须包含资源的网络路径，以及对资源进行的操作(增删改查)。

2. 客户端安装

如果直接通过浏览器向 Elasticsearch 服务器发请求，那么需要在发送的请求中包含HTTP 标准的方法，而 HTTP 的大部分特性且仅支持 GET 和 POST 方法。所以为了能方便地进行客户端的访问，可以使用 Postman 软件

Postman 是一款强大的网页调试工具，提供功能强大的 Web API 和 HTTP 请求调试。软件功能强大，界面简洁明晰、操作方便快捷，设计得很人性化。Postman 中文版能够发送任何类型的 HTTP 请求 (GET, HEAD, POST, PUT..)，不仅能够表单提交，且可以附带任意类型请求体。

Postman 官网：https://www.getpostman.com Postman 下载：https://www.getpostman.com/apps

3. 数据格式

Elasticsearch 是面向文档型数据库，一条数据在这里就是一个文档。为了方便大家理解，我们将 Elasticsearch 里存储文档数据和关系型数据库 MySQL 存储数据的概念进行一个类比 ES 里的 Index 可以看做一个库，而 Types 相当于表，Documents 则相当于表的行。这里 Types 的概念已经被逐渐弱化，Elasticsearch 6.X 中，一个 index 下已经只能包含一个 type，Elasticsearch 7.X 中, Type 的概念已经被删除了。 6 用 JSON 作为文档序列化的格式，比如一条用户信息：

{
  "name" : "John",
  "sex" : "Male",
  "age" : 25,
  "birthDate": "1990/05/01",
  "about" : "I love to go rock climbing",
  "interests": [ "sports", "music" ]
}

4. HTTP 操作

4.1 索引操作

1) 创建索引

对比关系型数据库，创建索引就等同于创建数据库在 Postman 中，向 ES 服务器发 **PUT **请求：http://10.211.55.11:9200/shopping

{
    "acknowledged"【响应结果】: true, # true 操作成功
    "shards_acknowledged"【分片结果】: true, # 分片操作成功
    "index"【索引名称】: "shopping"
}
# 注意：创建索引库的分片数默认 1 片，在 7.0.0 之前的 Elasticsearch 版本中，默认 5 片

如果重复添加索引，会返回错误信息

2) 查看所有索引

在 Postman 中，向 ES 服务器发 **GET **请求：http://10.211.55.11:9200/_cat/indices?v

这里请求路径中的_cat 表示查看的意思，indices 表示索引，所以整体含义就是查看当前 ES 服务器中的所有索引，就好像 MySQL 中的 show tables 的感觉，服务器响应结果如下

health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   shopping ohQY_Mb0Rm2UG-Z9J0ZhMg   1   1          0            0       208b           208b

3) 查看单个索引

在 Postman 中，向 ES 服务器发 **GET **请求 : http://10.211.55.11:9200/shopping

查看索引向 ES 服务器发送的请求路径和创建索引是一致的。但是 HTTP 方法不一致。这里可以体会一下 RESTful 的意义，请求后，服务器响应结果如下：

{
  "shopping"【索引名】: {
    "aliases"【别名】: {},
    "mappings"【映射】: {},
    "settings"【设置】: {
      "index"【设置 - 索引】: {
        "creation_date"【设置 - 索引 - 创建时间】: "1650108007285",
        "number_of_shards"【设置 - 索引 - 主分片数量】: "1",
        "number_of_replicas"【设置 - 索引 - 副分片数量】: "1",
        "uuid"【设置 - 索引 - 唯一标识】: "ohQY_Mb0Rm2UG-Z9J0ZhMg",
        "version"【设置 - 索引 - 版本】: {
          "created": "7080099"
        },
        "provided_name"【设置 - 索引 - 名称】: "shopping"
      }
    }
  }
}

4) 删除索引

在 Postman 中，向 ES 服务器发 DELETE **请求：http://10.211.55.11:9200/shopping 重新访问索引时，服务器返回响应：索引不存在**

4.2 文档操作

1) 创建文档

索引已经创建好了，接下来我们来创建文档，并添加数据。这里的文档可以类比为关系型数据库中的表数据，添加的数据格式为 JSON 格式在 Postman 中，向 ES 服务器发 POST **请求：http://10.211.55.11:9200/shopping/_doc ** 请求体内容为：

{ 
  "title":"小米手机",
  "category":"小米",
  "images":"http://www.gulixueyuan.com/xm.jpg",
  "price":3999.00
}

此处发送请求的方式必须为 POST，不能是 PUT，否则会发生错误 PUT请求是幂等性的，POST请求不是幂等性的，每一次POST都返回不同的ID

服务器响应结果如下：

{
    "_index"【索引】: "shopping",
    "_type"【类型-文档】: "_doc",
    "_id"【唯一标识】: "1ZOPMoABrqtNwT9MR10m", #可以类比为 MySQL 中的主键，随机生成
    "_version"【版本】: 1,
    "result"【结果】: "created", #这里的 create 表示创建成功
    "_shards"【分片】: {
        "total"【分片 - 总数】: 2,
        "successful"【分片 - 成功】: 1,
        "failed"【分片 - 失败】: 0
    },
    "_seq_no": 0,
    "_primary_term": 1
}

上面的数据创建后，由于没有指定数据唯一性标识（ID），默认情况下，ES 服务器会随机生成一个。如果想要自定义唯一性标识，需要在创建时指定：http://10.211.55.11:9200/shopping/_doc/1001 此处需要注意：如果增加数据时明确数据主键，那么请求方式也可以为 PUT

2) 查看文档

查看文档时，需要指明文档的唯一性标识，类似于 MySQL 中数据的主键查询在 Postman 中，向 ES 服务器发 GET **请求：http://10.211.55.11:9200/shopping/_doc/1001**

{
    "_index"【索引】: "shopping",
    "_type"【文档类型】: "_doc",
    "_id": "1001",
    "_version": 1,
    "_seq_no": 1,
    "_primary_term": 1,
    "found"【查询结果】: true, # true 表示查找到，false 表示未查找到
    "_source"【文档源信息】: {
        "title": "小米手机",
        "category": "小米",
        "images": "http://www.gulixueyuan.com/xm.jpg",
        "price": 3999.00
    }
}

全部查询：向 ES 服务器发 GET **请求：http://10.211.55.11:9200/shopping/_search**

3) 修改文档

和新增文档一样，输入相同的 URL 地址请求，如果请求体变化，会将原有的数据内容覆盖在 Postman 中，向 ES 服务器发 POST **请求：http://10.211.55.11:9200/shopping/_doc/1001 ** 请求体内容为:

{
  "title":"华为手机",
  "category":"华为",
  "images":"http://www.gulixueyuan.com/hw.jpg",
  "price":4999.00
}

{
    "_index": "shopping",
    "_type": "_doc",
    "_id": "1001",
    "_version"【版本】: 2,
    "result"【结果】: "updated", # updated 表示数据被更新
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 2,
    "_primary_term": 1
}

4) 修改字段

局部修改：非幂等性，每次修改的内容都不一样，使用POST请求 http://10.211.55.11:9200/shopping/_update/1001 根据唯一性标识，查询文档数据，文档数据已经更新

5) 删除文档

删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）。在 Postman 中，向 ES 服务器发 DELETE **请求：http://10.211.55.11:9200/shopping/_doc/1001**

{
    "_index": "shopping",
    "_type": "_doc",
    "_id": "1001",
    "_version"【版本】: 4, #对数据的操作，都会更新版本
    "result"【结果】: "deleted", # deleted 表示数据被标记为删除
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 4,
    "_primary_term": 1
}

如果删除一个并不存在的文档 not_found 表示未查找到

6) 条件删除文档

一般删除数据都是根据文档的唯一性标识进行删除，实际操作时，也可以根据条件对多条数据进行删除首先分别增加多条数据:

{
  "title":"小米手机",
  "category":"小米",
  "images":"http://www.gulixueyuan.com/xm.jpg",
  "price":4000.00
}

{
  "title":"华为手机",
  "category":"华为",
  "images":"http://www.gulixueyuan.com/hw.jpg",
  "price":4000.00
}

向 ES 服务器发 POST **请求：http://10.211.55.11:9200/shopping/_delete_by_query** 请求的内容为

{
  "query":{
    "match":{
      "price":4000.00
    } 
  }
}

{
    "took"【耗时】: 821,
    "timed_out"【是否超时】: false,
    "total"【总数】: 3,
    "deleted"【删除数量】: 3,
    "batches": 1,
    "version_conflicts": 0,
    "noops": 0,
    "retries": {
        "bulk": 0,
        "search": 0
    },
    "throttled_millis": 0,
    "requests_per_second": -1.0,
    "throttled_until_millis": 0,
    "failures": []
}

7) 条件查询

查询种类是小米的请求 GET操作(请求路径)：http://10.211.55.11:9200/shopping/_search?q=catagory:小米

请求体

8) 多条件查询

同时成立：must

{
	"query":{
		"bool":{
			"must":[
				{
					"match":{
						"cateaory":"小米"
					}
				},
				{
					"match":{
						"price":"2999.00"
					}
				}
			]
		}
	}
}

任何一个都满足条件：should

{
	"query":{
		"bool":{
			"should":[
				{
					"match":{
						"cateaory":"小米"
					}
				},
				{
					"match":{
						"cateaory":"苹果"
					}
				}
			]
		}
	}
}

范围操作：filter range

{
	"query":{
		"bool":{
			"should":[
				{
					"match":{
						"cateaory":"小米"
					}
				},
				{
					"match":{
						"cateaory":"苹果"
					}
				}
			],
			"filter":{
				"range":{
					"price":{
						"gt":2000
					}
				}
			}
		}
	}
}

###

9) 全文检索

当保存文档数据时，es会将数据文字进行分词拆解操作，并将拆解后的数据保存到倒排索引当中，那么即使使用文字的一部分，仍可以查询到数据，这种检索的方式称之为全文检索。es会将查询内容进行分词，在倒排索引中进行匹配

{
    "query":{
        "match":{
            "category":"米"
        }
    }
}

完全匹配：match_phrase

{
    "query":{
        "match_phrase":{
            "category":"米华"
        }
    }
}

高亮查询

{
    "query":{
        "match_phrase":{
            "category":"小米"
        }
    },
    "highlight":{
        "fields":{
            "category":{}
        }
    }
}

10) 聚合操作

{
    "aggs":{    //聚合操作
        "price_group":{     //统计结果的名称，任意取
            "terms":{       //分组
                "field":"price" //分组字段
            }
        }
    }
}

不显示原始数据

{
    "aggs":{    //聚合操作
        "price_group":{     //统计结果的名称，任意取
            "terms":{       //分组
                "field":"price" //分组字段
            }
        }
    },
    "size":0   //不用显示原始数据
}

求平均值

{
    "aggs":{    //聚合操作
        "price_avg":{     //统计结果的名称，任意取
            "avg":{       //平均值
                "field":"price" //分组字段
            }
        }
    },
    "size":0   //不用显示原始数据
}

4.3 映射关系

有了索引库，等于有了数据库中的 database。

接下来就需要建索引库(index)中的映射了，类似于数据库(database)中的表结构(table)。

创建数据库表需要设置字段名称，类型，长度，约束等；索引库也一样，需要知道这个类型下有哪些字段，每个字段有哪些约束信息，这就叫做映射(mapping)。

1) 创建映射

在 Postman 中，向 ES 服务器发 PUT **请求：http://10.211.55.11:9200/user/_mapping ** 请求体内容为：

{
  "properties": {
    "name":{
      "type": "text",
      "index": true
    },
    "sex":{
      "type": "keyword",	//不能够被分词
      "index": true
    },
    "tel":{
      "type": "keyword",
      "index": false	//不能够被索引	
    }
  } 
}

映射数据说明：

字段名：任意填写，下面指定许多属性，例如：title、subtitle、images、price
type：类型，Elasticsearch 中支持的数据类型非常丰富，说几个关键的：

String 类型，又分两种： text：可分词 keyword：不可分词，数据会作为完整字段进行匹配
Numerical：数值类型，分两类基本数据类型：long、integer、short、byte、double、float、half_float 浮点数的高精度类型：scaled_float Date：日期类型 Array：数组类型 Object：对象

index：是否索引，默认为 true，也就是说你不进行任何配置，所有字段都会被索引。

true：字段会被索引，则可以用来进行搜索 false：字段不会被索引，不能用来搜索

store：是否将数据进行独立存储，默认为 false

原始的文本会存储在_source 里面，默认情况下其他提取出来的字段都不是独立存储的，是从_source 里面提取出来的。当然你也可以独立的存储某个字段，只要设置 “store”: true 即可，获取独立存储的字段要比从_source 中解析快得多，但是也会占用更多的空间，所以要根据实际业务需求来设置。

analyzer：分词器

2) 查看映射

在 Postman 中，向 ES 服务器发 **GET **请求:http://10.211.55.11:9200/user/_mapping

3) 查询数据

{
    "query":{
        "match":{
            "name":"小"
        }
    }
}

HBase优化

hkmu9248@gmail.com (Haokang Mu) — Sat, 16 Apr 2022 00:00:00 +0800

1. 高可用

在 HBase 中 HMaster 负责监控 HRegionServer 的生命周期，均衡 RegionServer 的负载，如果 HMaster 挂掉了，那么整个 HBase 集群将陷入不健康的状态，并且此时的工作状态并不会维持太久。所以 HBase 支持对 HMaster 的高可用配置。

HBase自带高可用，比如可以在hadoop102和hadoop103上同时单点启动master，此时hadoop103上的master就是backup master

[mhk@hadoop102 hbase-1.3.1]$ bin/hbase-daemon.sh start master
[mhk@hadoop103 hbase-1.3.1]$ bin/hbase-daemon.sh start master

配置自动高可用 1．关闭 HBase 集群（如果没有开启则跳过此步）

[mhk@hadoop102 hbase-1.3.1]$ bin/stop-hbase.sh

2．在 conf 目录下创建 backup-masters 文件

[mhk@hadoop102 hbase-1.3.1]$ touch conf/backup-masters

3．在 backup-masters 文件中配置高可用 HMaster 节点

[mhk@hadoop102 conf]$ cat backup-masters 
hadoop103
hadoop104

4．将整个 conf 目录 scp 到其他节点

[mhk@hadoop102 hbase-1.3.1]$ xsync conf/

5．启动集群

[mhk@hadoop102 hbase-1.3.1]$ bin/start-hbase.sh 
starting master, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-master-hadoop102.out
hadoop103: starting regionserver, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-regionserver-hadoop103.out
hadoop104: starting regionserver, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-regionserver-hadoop104.out
hadoop102: starting regionserver, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-regionserver-hadoop102.out
hadoop104: starting master, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-master-hadoop104.out
hadoop103: starting master, logging to /opt/module/hbase-1.3.1/bin/../logs/hbase-mhk-master-hadoop103.out

6．打开页面测试查看 http://hadooo102:16010

2. 预分区

每一个 region 维护着 StartRow 与 EndRow，如果加入的数据符合某个 Region 维护的RowKey 范围，则该数据交给这个 Region 维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高 HBase 性能。预分区和什么有关？未来发展的数据量+机器规模一般生产环境中，一台机器放2~3个region

1．手动设定预分区

hbase(main):001:0> create 'staff1','info','partition1',SPLITS => ['1000','2000','3000','4000']

2．生成 16 进制序列预分区

hbase(main):002:0> create 'staff2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

3．按照文件中设置的规则预分区创建 splits.txt 文件内容如下： aaaa bbbb cccc dddd 然后执行：

hbase(main):005:0> create 'staff3','partition3',SPLITS_FILE => 'spilts.txt'

4．使用 JavaAPI 创建预分区

//自定义算法，产生一系列 hash 散列值存储在二维数组中 
byte[][] splitKeys = 某个散列值函数 
//创建 HbaseAdmin 实例 
HBaseAdmin hAdmin = new HBaseAdmin(HbaseConfiguration.create()); 
//创建 HTableDescriptor 实例 
HTableDescriptor tableDesc = new HTableDescriptor(tableName); 
//通过 HTableDescriptor 实例和散列值二维数组创建带有预分区的 Hbase 表 
hAdmin.createTable(tableDesc, splitKeys);

3. RowKey 设计

散列性唯一性长度原则一条数据的唯一标识就是 RowKey，那么这条数据存储于哪个分区，取决于 RowKey 处于哪个一个预分区的区间内，设计 RowKey 的主要目的，就是让数据均匀的分布于所有的region 中，在一定程度上防止数据倾斜。接下来我们就谈一谈 RowKey 常用的设计方案。

1．生成随机数、hash、散列值比如：原本 rowKey 为 1001 的， SHA1 后变成： dd01903921ea24941c26a48f2cec24e0bb0e8cc7 原本 rowKey 为 3001 的， SHA1 后变成： 49042c54de64a1e9bf0b33e00245660ef92dc7bd 原本 rowKey 为 5001 的， SHA1 后变成： 7b61dec07e02c188790670af43e717f0f46e8913 在做此操作之前，一般我们会选择从数据集中抽取样本，来决定什么样的 rowKey 来 Hash 后作为每个分区的临界值。

2．字符串反转 20170524000001 转成 10000042507102 20170524000002 转成 20000042507102 这样也可以在一定程度上散列逐步 put 进来的数据。

3．字符串拼接 20170524000001_a12e 20170524000001_93i7

Rowkey设计时需要遵循三大原则： 1） 唯一性原则 rowkey在设计上保证其唯一性。rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

2）长度原则 rowkey是一个二进制码流，可以是任意字符串，最大长度 64kb ，实际应用中一般为10-100bytes，以byte[] 形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。

3）散列原则 如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息，所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率

加盐：这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点

哈希：哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据

反转：第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。反转rowkey的例子以手机号为rowkey，可以将手机号反转后的字符串作为rowkey，这样的就避免了以手机号那样比较固定开头导致热点问题

时间戳反转：一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp 追加到key的末尾，例如[key][reverse_timestamp] ,[key] 的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据。比如需要保存一个用户的操作记录，按照操作时间倒序排序，在设计rowkey的时候，可以这样设计[userId反转][Long.Max_Value - timestamp]，在查询用户的所有操作记录数据的时候，直接指定反转后的userId，startRow是[userId反转][000000000000],stopRow是[userId反转][Long.Max_Value - timestamp]如果需要查询某段时间的操作记录，startRow是[user反转][Long.Max_Value - 起始时间]，stopRow是[userId反转][Long.Max_Value - 结束时间]

4. 内存优化

HBase 操作过程中需要大量的内存开销，毕竟 Table 是可以缓存在内存中的，一般会分配整个可用内存的 70%给 HBase 的 Java 堆。但是不建议分配非常大的堆内存，因为 GC 过程持续太久会导致 RegionServer 处于长期不可用状态，一般 16~48G 内存就可以了，如果因为框架占用内存过高导致系统内存不足，框架一样会被系统服务拖死。

5. 基础优化

1．允许在 HDFS 的文件中追加内容 hdfs-site.xml、hbase-site.xml

属性：dfs.support.append 
解释：开启 HDFS 追加同步，可以优秀的配合 HBase 的数据同步和持久化。默认值为 true。

2．优化 DataNode 允许的最大文件打开数 hdfs-site.xml

属性：dfs.datanode.max.transfer.threads 
解释：HBase 一般都会同一时间操作大量的文件，根据集群的数量和规模以及数据动作， 
设置为 4096 或者更高。默认值：4096 

3．优化延迟高的数据操作的等待时间 hdfs-site.xml

属性：dfs.image.transfer.timeout 
解释：如果对于某一次数据操作来讲，延迟非常高，socket 需要等待更长的时间，建议把 
该值设置为更大的值（默认 60000 毫秒），以确保 socket 不会被 timeout 掉。

4．优化数据的写入效率 mapred-site.xml

属性：
mapreduce.map.output.compress 
mapreduce.map.output.compress.codec 
解释：开启这两个数据可以大大提高文件的写入效率，减少写入时间。
第一个属性值修改为true，
第二个属性值修改为：org.apache.hadoop.io.compress.GzipCodec 或者其他压缩方式。 

5．设置 RPC 监听数量 hbase-site.xml

属性：Hbase.regionserver.handler.count 
解释：默认值为 30，用于指定 RPC 监听的数量，可以根据客户端的请求数进行调整，读写 
请求较多时，增加此值。 

6．优化 HStore 文件大小 hbase-site.xml

属性：hbase.hregion.max.filesize 
解释：默认值 10737418240（10GB），如果需要运行 HBase 的 MR 任务，可以减小此值， 
因为一个 region 对应一个 map 任务，如果单个 region 过大，会导致 map 任务执行时间 
过长。该值的意思就是，如果 HFile 的大小达到这个数值，则这个 region 会被切分为两个 Hfile。 

7．优化 HBase 客户端缓存 hbase-site.xml

属性：hbase.client.write.buffer 
解释：用于指定 Hbase 客户端缓存，增大该值可以减少 RPC 调用次数，但是会消耗更多内存，
反之则反之。一般我们需要设定一定的缓存大小，以达到减少 RPC 次数的目的。

8．指定 scan.next 扫描 HBase 所获取的行数 hbase-site.xml

属性：hbase.client.scanner.caching 
解释：用于指定 scan.next 方法获取的默认行数，值越大，消耗内存越大。 

9．flush、compact、split 机制当 MemStore 达到阈值，将 Memstore 中的数据 Flush 进 Storefile；compact 机制则是把 flush 出来的小文件合并成大的 Storefile 文件。split 则是当 Region 达到阈值，会把过大的 Region 一分为二。

涉及属性： 
即：128M 就是 Memstore 的默认阈值 
hbase.hregion.memstore.flush.size：134217728 
即：这个参数的作用是当单个 HRegion 内所有的 Memstore 大小总和超过指定值时，flush 
该 HRegion 的所有 memstore。RegionServer 的 flush 是通过将请求添加一个队列，模拟生 
产消费模型来异步处理的。那这里就有一个问题，当队列来不及消费，产生大量积压请求 
时，可能会导致内存陡增，最坏的情况是触发 OOM。 

hbase.regionserver.global.memstore.upperLimit：0.4 
hbase.regionserver.global.memstore.lowerLimit：0.38 
即：当 MemStore 使用内存总量达到hbase.regionserver.global.memstore.upperLimit 指定值时，
将会有多个 MemStores flush 到文件中，MemStore flush 顺序是按照大小降序执行的，直到 
刷新到 MemStore 使用内存略小于 lowerLimit

HBase进阶

hkmu9248@gmail.com (Haokang Mu) — Thu, 14 Apr 2022 00:00:00 +0800

1、架构原理

**1）StoreFile ** 保存实际数据的物理文件，StoreFile 以 HFile 的形式存储在 HDFS 上。每个 Store 会有一个或多个 StoreFile（HFile），数据在每个 StoreFile 中都是有序的。

**2）MemStore ** 写缓存，由于 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore 中，排好序后，等到达刷写时机才会刷写到 HFile，每次刷写都会形成一个新的 HFile。

**3）WAL ** 由于数据要经 MemStore 排序后才能刷写到 HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件中，然后再写入 MemStore 中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

2、写流程

写流程： 1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。

[zk: localhost:2181(CONNECTED) 1] ls /
[admin, brokers, cluster, config, consumers, controller_epoch, hbase, isr_change_notification, latest_producer_id_block, locks, servers, spark, zookeeper]
[zk: localhost:2181(CONNECTED) 2] ls /hbase
[backup-masters, draining, flush-table-proc, hbaseid, master, meta-region-server, namespace, online-snapshot, recovering-regions, region-in-transition, replication, rs, running, splitWAL, switch, table, table-lock]
[zk: localhost:2181(CONNECTED) 3] get /hbase/meta-region-server
�regionserver:16020�}6��PBUF

        hadoop104�}���ˁ0

2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。扫描hbase:meta这张表，发现student表是由hadoop102这台机器上的Region Server维护的

3）与目标 Region Server 进行通讯；

4）将数据顺序写入（追加）到 WAL；

5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；

6）向客户端发送 ack；

7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。

3、MemStore Flush

MemStore 刷写时机： ** 1、当某个 memstroe 的大小达到了 **hbase.hregion.memstore.flush.size（默认值 128M），其所在 region 的所有 memstore 都会刷写。当 memstore 的大小达到了 *hbase.hregion.memstore.flush.size（默认值 128M） hbase.hregion.memstore.block.multiplier（默认值 4） **时，会阻止继续往该 memstore 写数据。

2、当 region server 中 memstore 的总大小达到 java_heapsize hbase.regionserver.global.memstore.size（默认值 0.4）hbase.regionserver.global.memstore.size.lower.limit（默认值 0.95）， region 会按照其所有 memstore 的大小顺序（由大到小）依次进行刷写。直到 region server 中所有 memstore 的总大小减小到上述值以下。

当 region server 中 memstore 的总大小达到 *java_heapsizehbase.regionserver.global.memstore.size（默认值 0.4） ** 时，会阻止继续往所有的 memstore 写数据。

3、到达自动刷写的时间，也会触发 memstore flush。自动刷新的时间间隔由该属性进行配置 hbase.regionserver.optionalcacheflushinterval（默认 1 小时）。

4、当 WAL 文件的数量超过 hbase.regionserver.max.logs，region 会按照时间顺序依次进行刷写，直到 WAL 文件数量减小到 **hbase.regionserver.max.log **以下（该属性名已经废弃，现无需手动设置，最大值为 32）。

4、读流程

**读流程 ** 1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。

3）与目标 Region Server 进行通讯；

4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。

5）将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到 Block Cache。

6）将合并后的最终结果返回给客户端。

5、StoreFile Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的 HFile 中，因此查询时需要遍历所有的 HFile。为了减少 HFile 的个数，以及清理掉过期和删除的数据，会进行 StoreFile Compaction。

Compaction 分为两种，分别是 Minor Compaction 和 Major Compaction。Minor Compaction 会将临近的若干个较小的 HFile 合并成一个较大的 HFile，但不会清理过期和删除的数据。 Major Compaction 会将一个 Store 下的所有的 HFile 合并成一个大 HFile，并且会清理掉过期和删除的数据。

6、Region Split

默认情况下，每个 Table 起初只有一个 Region，随着数据的不断写入，Region 会自动进行拆分。刚拆分时，两个子 Region 都位于当前的 Region Server，但处于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的 Region Server。

Region Split 时机： 1、当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize，该 Region 就会进行拆分（0.94 版本之前）。

2、当 1 个 region 中的某个 Store 下所有 StoreFile 的总大小超过 Min(R^2 * “hbase.hregion.memstore.flush.size”,hbase.hregion.max.filesize”)，该 Region 就会进行拆分，其中 R 为当前 Region Server 中属于该 Table 的个数（0.94 版本之后）。

HBase Shell操作

hkmu9248@gmail.com (Haokang Mu) — Wed, 13 Apr 2022 00:00:00 +0800

1. 基本操作

**1．进入 HBase 客户端命令行 **

[mhk@hadoop102 hbase-1.3.1]$ bin/hbase shell

**2．查看帮助命令 **

hbase(main):001:0> help
HBase Shell, version 1.3.1, r930b9a55528fe45d8edce7af42fef2d35e77677a, Thu Apr  6 19:36:54 PDT 2017
Type 'help "COMMAND"', (e.g. 'help "get"' -- the quotes are necessary) for help on a specific command.
Commands are grouped. Type 'help "COMMAND_GROUP"', (e.g. 'help "general"') for help on a command group.

COMMAND GROUPS:
  Group name: general
  Commands: status, table_help, version, whoami

  Group name: ddl
  Commands: alter, alter_async, alter_status, create, describe, disable, disable_all, drop, drop_all, enable, enable_all, exists, get_table, is_disabled, is_enabled, list, locate_region, show_filters

  Group name: namespace
  Commands: alter_namespace, create_namespace, describe_namespace, drop_namespace, list_namespace, list_namespace_tables

  Group name: dml
  Commands: append, count, delete, deleteall, get, get_counter, get_splits, incr, put, scan, truncate, truncate_preserve

  Group name: tools
  Commands: assign, balance_switch, balancer, balancer_enabled, catalogjanitor_enabled, catalogjanitor_run, catalogjanitor_switch, close_region, compact, compact_rs, flush, major_compact, merge_region, move, normalize, normalizer_enabled, normalizer_switch, split, splitormerge_enabled, splitormerge_switch, trace, unassign, wal_roll, zk_dump

  Group name: replication
  Commands: add_peer, append_peer_tableCFs, disable_peer, disable_table_replication, enable_peer, enable_table_replication, get_peer_config, list_peer_configs, list_peers, list_replicated_tables, remove_peer, remove_peer_tableCFs, set_peer_tableCFs, show_peer_tableCFs

  Group name: snapshots
  Commands: clone_snapshot, delete_all_snapshot, delete_snapshot, delete_table_snapshots, list_snapshots, list_table_snapshots, restore_snapshot, snapshot

  Group name: configuration
  Commands: update_all_config, update_config

  Group name: quotas
  Commands: list_quotas, set_quota

  Group name: security
  Commands: grant, list_security_capabilities, revoke, user_permission

  Group name: procedures
  Commands: abort_procedure, list_procedures

  Group name: visibility labels
  Commands: add_labels, clear_auths, get_auths, list_labels, set_auths, set_visibility

SHELL USAGE:
Quote all names in HBase Shell such as table and column names.  Commas delimit
command parameters.  Type <RETURN> after entering a command to run it.
Dictionaries of configuration used in the creation and alteration of tables are
Ruby Hashes. They look like this:

  {'key1' => 'value1', 'key2' => 'value2', ...}

and are opened and closed with curley-braces.  Key/values are delimited by the
'=>' character combination.  Usually keys are predefined constants such as
NAME, VERSIONS, COMPRESSION, etc.  Constants do not need to be quoted.  Type
'Object.constants' to see a (messy) list of all constants in the environment.

If you are using binary keys or values and need to enter them in the shell, use
double-quote'd hexadecimal representation. For example:

  hbase> get 't1', "key\x03\x3f\xcd"
  hbase> get 't1', "key\003\023\011"
  hbase> put 't1', "test\xef\xff", 'f1:', "\x01\x33\x40"

The HBase shell is the (J)Ruby IRB with the above HBase-specific commands added.
For more on the HBase Shell, see http://hbase.apache.org/book.html

**3．查看当前数据库中有哪些表 **

hbase(main):002:0> list
TABLE                                                                                                  
0 row(s) in 0.6870 seconds

=> []

2. 表的操作

**1．创建表 **

hbase(main):003:0> create 'student','info'
0 row(s) in 2.6380 seconds

=> Hbase::Table - student

hbase(main):005:0> create 'stu','info1','info2'
0 row(s) in 2.3180 seconds

=> Hbase::Table - stu

hbase(main):006:0> list
TABLE                                                                                                  
stu                                                                                                    
student                                                                                                
2 row(s) in 0.0240 seconds

=> ["stu", "student"]

hbase(main):011:0> create_namespace 'mhk'
0 row(s) in 1.2260 seconds

hbase(main):012:0> list_namespace
NAMESPACE                                                                                              
default                                                                                                
hbase                                                                                                  
mhk                                                                                                    
3 row(s) in 0.1410 seconds

hbase(main):013:0> create 'mhk:stu','info'
0 row(s) in 2.2640 seconds

=> Hbase::Table - mhk:stu
hbase(main):014:0> list
TABLE                                                                                                  
mhk:stu                                                                                                
stu                                                                                                    
student                                                                                                
3 row(s) in 0.0250 seconds

=> ["mhk:stu", "stu", "student"]

**2．插入数据到表 **

hbase(main):003:0> put 'student','1001','info:sex','male' 
hbase(main):004:0> put 'student','1001','info:age','18' 
hbase(main):005:0> put 'student','1002','info:name','Janna' 
hbase(main):006:0> put 'student','1002','info:sex','female' 
hbase(main):007:0> put 'student','1002','info:age','20' 

**3．扫描查看表数据 **

hbase(main):019:0> scan 'student'
ROW                        COLUMN+CELL                                                                 
 1001                      column=info:age, timestamp=1649732463800, value=18                          
 1001                      column=info:sex, timestamp=1649729775042, value=male                        
 1002                      column=info:age, timestamp=1649732716233, value=20                          
 1002                      column=info:name, timestamp=1649732473758, value=Janna                      
 1002                      column=info:sex, timestamp=1649732706857, value=female                      
2 row(s) in 0.1560 seconds

hbase(main):020:0> scan 'student',{STARTROW => '1001', STOPROW => '1001'}
ROW                        COLUMN+CELL                                                                 
 1001                      column=info:age, timestamp=1649732463800, value=18                          
 1001                      column=info:sex, timestamp=1649729775042, value=male                        
1 row(s) in 0.0550 seconds

左闭右开
hbase(main):008:0> scan 'student',{STARTROW => '1001',STOPROW =>'1002'}
ROW                        COLUMN+CELL                                                                 
 1001                      column=info:age, timestamp=1649738076812, value=18                          
 1001                      column=info:sex, timestamp=1649738063585, value=male                        
1 row(s) in 0.2100 seconds


hbase(main):021:0> scan 'student',{STARTROW => '1001'}
ROW                        COLUMN+CELL                                                                 
 1001                      column=info:age, timestamp=1649732463800, value=18                          
 1001                      column=info:sex, timestamp=1649729775042, value=male                        
 1002                      column=info:age, timestamp=1649732716233, value=20                          
 1002                      column=info:name, timestamp=1649732473758, value=Janna                      
 1002                      column=info:sex, timestamp=1649732706857, value=female                      
2 row(s) in 0.2290 seconds

**4．查看表结构 **

hbase(main):001:0> describe 'student'
Table student is ENABLED                                                                               
student                                                                                                
COLUMN FAMILIES DESCRIPTION                                                                            
{NAME => 'info', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FA
LSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}                                      
1 row(s) in 1.0330 seconds

**5．更新指定字段的数据 **

hbase(main):022:0> put 'student','1001','info:name','Nick'
0 row(s) in 0.0470 seconds

hbase(main):023:0> put 'student','1001','info:age','100'
0 row(s) in 0.0330 seconds

**6．查看“指定行”或“指定列族:列”的数据 **

hbase(main):002:0> get 'student','1001'
COLUMN                     CELL                                                                        
 info:age                  timestamp=1649733079650, value=100                                          
 info:name                 timestamp=1649733071082, value=Nick                                         
 info:sex                  timestamp=1649729775042, value=male                                         
1 row(s) in 0.3120 seconds

hbase(main):003:0> get 'student','1001','info:name'
COLUMN                     CELL                                                                        
 info:name                 timestamp=1649733071082, value=Nick                                         
1 row(s) in 0.0660 seconds

**7．统计表数据行数 **

hbase(main):004:0> count 'student'
2 row(s) in 0.0860 seconds

=> 2

**8．删除数据 ** 删除某 rowkey 的全部数据：

 deleteall 'student','1001'

删除某 rowkey 的某一列数据：

hbase(main):006:0> delete 'student','1002','info:sex'
0 row(s) in 0.0570 seconds

**9．清空表数据 **

hbase(main):007:0> truncate 'student'
Truncating 'student' table (it may take a while):
 - Disabling table...
 - Truncating table...
0 row(s) in 4.7150 seconds

提示：清空表的操作顺序为先 disable，然后再 truncate。

**10．删除表 ** 首先需要先让该表为 disable 状态：

hbase(main):008:0> disable 'student'
0 row(s) in 2.3030 seconds

然后才能 drop 这个表：

hbase(main):009:0> drop 'student'
0 row(s) in 1.3620 seconds

提示：如果直接 drop 表，会报错：ERROR: Table student is enabled. Disable it first.

**11．变更表信息 ** 将 info 列族中的数据存放 3 个版本：

hbase(main):001:0> describe 'student'
Table student is ENABLED                                                                               
student                                                                                                
COLUMN FAMILIES DESCRIPTION                                                                            
{NAME => 'info', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FA
LSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}                                      
1 row(s) in 1.1010 seconds

hbase(main):002:0> alter 'student',{NAME=>'info',VERSIONS=>3}
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 3.4050 seconds

hbase(main):003:0> describe 'student'
Table student is ENABLED                                                                               
student                                                                                                
COLUMN FAMILIES DESCRIPTION                                                                            
{NAME => 'info', BLOOMFILTER => 'ROW', VERSIONS => '3', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FA
LSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}                                      
1 row(s) in 0.0530 seconds

hbase(main):004:0> get 'student','1001',{COLUMN=>'info:name',VERSIONS=>3}
COLUMN                     CELL                                                                        
0 row(s) in 0.3190 seconds

HBase简介

hkmu9248@gmail.com (Haokang Mu) — Tue, 12 Apr 2022 00:00:00 +0800

1. HBase定义

HBase 是一种分布式、可扩展、支持海量数据存储的 NoSQL 数据库。

2. HBase数据模型

逻辑上，HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。但从 HBase 的底层物理存储结构（K-V）来看，HBase 更像是一个 multi-dimensional map。

2.1 HBase逻辑结构

2.2 HBase 物理存储结构

2.3 数据模型

**1）Name Space ** 命名空间，类似于关系型数据库的 DatabBase 概念，每个命名空间下有多个表。HBase 有两个自带的命名空间，分别是 hbase 和 default，hbase 中存放的是 HBase 内置的表， default 表是用户默认使用的命名空间。

**2）Region ** 类似于关系型数据库的表概念。不同的是，HBase 定义表时只需要声明列族即可，不需要声明具体的列。这意味着，往 HBase 写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，HBase 能够轻松应对字段变更的场景。

3）Row ** HBase 表中的每行数据都由一个 **RowKey **和多个 **Column（列）组成，数据是按照 RowKey 的字典顺序存储的，并且查询数据时只能根据 RowKey 进行检索，所以 RowKey 的设计十分重要。

**4）Column ** HBase 中的每个列都由 Column Family(列族)和 Column Qualifier（列限定符）进行限定，例如 info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。

**5）Time Stamp ** 用于标识数据的不同版本（version），每条数据写入时，如果不指定时间戳，系统会自动为其加上该字段，其值为写入 HBase 的时间。

**6）Cell ** 由{rowkey, column Family：column Qualifier, time Stamp} 唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存贮。

3. HBase基本架构

**架构角色： ** **1）Region Server ** Region Server 为 Region 的管理者，其实现类为 HRegionServer，主要作用如下: 对于数据的操作：get, put, delete；对于 Region 的操作：splitRegion、compactRegion。

**2）Master ** Master 是所有 Region Server 的管理者，其实现类为 HMaster，主要作用如下：对于表的操作：create, delete, alter 对于 RegionServer的操作：分配 regions到每个RegionServer，监控每个 RegionServer的状态，负载均衡和故障转移。

**3）Zookeeper ** HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作。

**4）HDFS ** HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的支持。