IT瘾工具推荐

让 Claude Code 在你睡觉时持续运行：完整实战指南

Wed, 15 Apr 2026 13:44:00 CST

让 Claude Code 在你睡觉时持续运行：完整实战指南

Claude Code 可以通过 -p 标志、权限绕过、循环模式和终端持久化的组合，实现数小时甚至整夜的无人值守运行。 开发者社区已经形成了一套可靠的操作手册：容器化运行环境、使用 “Ralph Wiggum” 循环模式、安装四个关键 Hook 防止卡死、保持 CLAUDE.md 精简。有开发者记录了 27 小时连续自主会话完成 84 个任务；另一位在睡觉时让 Claude 构建了一个 15,000 行的游戏。但社区也反馈，大约 25% 的过夜产出会被丢弃，而且如果没有适当的防护措施，Claude 曾在至少一位开发者的机器上执行过 rm -rf /。以下是你今晚就能用上的完整设置方案。

一、消除人工干预的三种模式

Claude Code 提供三个级别的自主运行模式，每个级别都在安全性和速度之间做取舍。理解它们是所有过夜方案的基础。

模式 1： -p（print/pipe）标志 —— 所有自动化的核心。 这是非交互式运行模式。接收 prompt，执行到完成，输出到 stdout，然后退出。无需 TTY，512MB 内存的服务器也能跑。

1	claude -p "查找并修复 auth.py 中的 bug" --allowedTools "Read,Edit,Bash"

模式 2： --permission-mode auto —— 更安全的折中方案。 2026 年初推出，使用 Sonnet 4.6 分类器自动批准安全操作，同时阻止高风险操作。分类器分两阶段运作：快速判定（8.5% 误报率），对标记项目进行思维链推理（0.4% 误报率）。如果连续 3 次操作被拒绝或单次会话累计 20 次被拒，系统会升级到人工介入——或者在 headless 模式下直接终止。

1	claude --permission-mode auto -p "重构认证模块"

模式 3： --dangerously-skip-permissions —— 完全绕过权限。 所有操作无需确认直接执行。Anthropic 自己的安全研究员 Nicholas Carlini 也使用这个模式，但有一个关键前提：*”在容器里跑，不要在你的真实机器上。”* 一项调查发现 32% 的开发者使用这个标志时遭遇了意外的文件修改， 9% 报告了数据丢失。

1 2	# 仅限 Docker/VM —— 绝对不要在宿主机上运行 claude --dangerously-skip-permissions -p "构建这个功能"

推荐的过夜运行方式是将 -p 与细粒度工具白名单 --allowedTools 结合使用，允许特定命令而非授予全面访问权限：

claude -p "修复所有 lint 错误并运行测试" \     
 --allowedTools "Read" "Edit" "Bash(npm run lint:*)" "Bash(npm test)" "Bash(git *)" \     
 --max-turns 50 \     
 --max-budget-usd 10.00

--max-turns 和 --max-budget-usd 是无人值守会话的必备成本控制手段。没有它们，一个失控的循环可以在几分钟内烧光你的 API 预算。

二、Ralph Wiggum 循环：开发者的实际过夜方案

最经过实战验证的长时间自主工作模式是 Ralph Wiggum 循环——以《辛普森一家》中的角色命名，现已成为 Anthropic 官方插件。概念非常简单：一个 bash while 循环持续向 Claude 喂相同的 prompt。每次迭代中，Claude 查看当前文件状态和 git 历史，选择下一个未完成的任务，实现它，然后提交。

while true; do     
 claude --dangerously-skip-permissions \     
 -p "$(cat PROMPT.md)"      
 sleep 1     
done

那位记录了 27 小时会话 的开发者使用了这个模式，配合一个详细的 prompt 文件，包含架构说明、目标、约束条件和明确的”完成”标准。他的核心发现：*”一句话 prompt 在一两个小时后就没劲了。27 小时的会话能持续下去，是因为 prompt 文件有足够多的上下文。”*

Prompt 文件比循环本身更重要。 一个有效的过夜 PROMPT.md 示例：

# 任务：测试并加固认证系统     
     
## 上下文     
- 后端：Express + TypeScript，位于 src/api/     
- 数据库：PostgreSQL，schema 在 prisma/schema.prisma     
- 认证流程：JWT 中间件在 src/middleware/auth.ts     
     
## 目标     
- 查看 docs/plan.md，选择下一个未完成的任务     
- 实现它，包含完善的错误处理     
- 运行测试，修复失败，确认没有回归     
- 做通用修复，不要打临时补丁     
- 每完成一个任务后用描述性消息提交     
     
## 成功标准     
- 每次修改后所有测试通过     
- 不会引入之前修复的回归     
- 当 plan.md 中所有任务完成后输出 DONE

社区有几个工具扩展了这个基础循环。 Ralph CLI 增加了速率限制（100次调用/小时）、熔断器、会话过期（默认24小时）和实时监控仪表板。 Nonstop 增加了飞行前风险评估和阻塞决策框架——走之前输入 /nonstop 即可。 Continuous-claude 自动化完整 PR 生命周期：创建分支、推送、创建 PR、等待 CI、合并。

三、防止过夜灾难的四个 Hook

开发者 yurukusa 记录了 108 小时无人值守运行，识别出七类过夜事故——包括 Claude 执行 rm -rf ./src/、进入无限错误循环、直接推送到 main 分支，以及产生每小时 8 美元的 API 费用。解决方案： 四个关键 Hook，共同预防最常见的故障模式。

10 秒快速安装：

1	npx cc-safe-setup

Hook 1：No-Ask-Human 阻止 AskUserQuestion 工具调用，强制 Claude 自主做出决定，而不是坐在那里等几小时等人回复。这个 Hook 决定了 Claude 是整夜工作还是在晚上 11:15 卡住。在你坐在电脑前时，用 CC_ALLOW_QUESTIONS=1 覆盖。

Hook 2：Context Monitor 将工具调用次数作为上下文使用量的代理指标，在四个阈值（剩余 40%、25%、20%、15%）发出分级警告。在临界水平时，配套的空闲推送脚本会自动向终端注入 /compact 命令——两个进程， 共 472 行代码，零人工干预。

Hook 3：Syntax Check 在任何文件编辑后立即运行 python -m py_compile、 node --check 或 bash -n，在错误级联成 50 次调试之前就捕获它们。

Hook 4：Decision Warn 在执行前标记破坏性命令（ rm -rf、 git reset --hard、 DROP TABLE、 git push --force）。通过 CC_PROTECT_BRANCHES="main:master:production" 配置受保护分支。

在 .claude/settings.json 中配置：

{     
 "permissions": {     
 "allow": ["Bash(npm run lint:*)", "WebSearch", "Read"],     
 "deny": ["Read(.env)", "Bash(rm -rf *)", "Bash(git push * main)"]     
 }     
}

四、tmux 设置与保持机器不休眠

Claude Code 的交互模式需要 TTY —— 不能用 nohup 或将其作为 systemd 服务运行（大约 15-20 秒后会因 stdin 错误崩溃）。 tmux 是会话持久化的必备工具。

# 启动命名会话     
tmux new -s claude-work     
     
# 在其中启动 Claude     
claude --permission-mode auto     
     
# 分离（Claude 继续运行）：Ctrl+B，然后按 D     
     
# 从任何地方重新连接（SSH、手机 Termius 等）     
tmux attach -t claude-work     
     
# 不连接就查看进度     
tmux capture-pane -t claude-work -p -S -50

对于真正的 7×24 运行，社区推荐 VPS + Tailscale + tmux 方案：便宜的 VPS（Hetzner、Vultr、DigitalOcean）提供永不关机的算力，Tailscale 提供私有网络，mosh 在不稳定网络上保持连接持久性。给 Claude 一个任务，分离，合上笔记本，明天再回来。

macOS 防止休眠：

# 绑定到 Claude 进程     
caffeinate -i -w $(pgrep -f claude) &     
     
# 或者在接通电源时全局禁用休眠     
sudo pmset -c sleep 0

管理多个并行会话方面， Amux 是一个约 12,000 行的 Python 文件，提供 Web 仪表板、手机 PWA 监控、自愈看门狗（自动重启崩溃会话）、按会话 token 追踪和 git 冲突检测。 Codeman 提供类似的 Web UI，带 xterm.js 终端，支持最多 20 个并行会话。

一个强大的过夜 agent tmux 配置：

#!/bin/bash     
tmux new-session -d -s claude-dev     
tmux rename-window -t claude-dev:0 'Claude'     
tmux new-window -t claude-dev:1 -n 'Tests'     
tmux new-window -t claude-dev:2 -n 'Logs'     
tmux send-keys -t claude-dev:0 'claude --permission-mode auto' Enter     
tmux send-keys -t claude-dev:1 'npm run test:watch' Enter     
tmux send-keys -t claude-dev:2 'tail -f logs/app.log' Enter     
tmux attach-session -t claude-dev

五、CLAUDE.md 与长时间运行的上下文管理

过夜失败的最大原因是 上下文窗口耗尽。Claude Code 的上下文窗口大约 200K token，使用率超过 70% 时性能开始下降。自动压缩在接近阈值时触发，但会丢失信息——仅保留 20-30% 的细节。有开发者报告 Claude 压缩后遗忘了所有内容，重新开始同一个任务，浪费了三个小时。

解决方案是 检查点/交接模式，能够在上下文重置后存活：

# 在 CLAUDE.md 中     
当上下文变大时，将当前状态写入 tasks/mission.md。     
包括：已完成的、下一步的、被阻塞的、未解决的问题。     
错误处理：最多重试 3 次。如果没有进展，记录到     
pending_for_human.md 然后转到下一个任务。     
压缩前，务必保存完整的已修改文件列表。

将 CLAUDE.md 控制在 200 行以内——每个词在每个会话中都消耗 token。从 800 行切换到 100 行的开发者达成社区共识：更短的配置实际上表现更好，因为 Claude 不会忽略被噪音淹没的指令。使用”仅在不可逆时才提问”规则，将提问频率降低约 80%：

# 自主运行的决策规则     
- 技术方案不确定 → 选择传统方案     
- 两种可行实现 → 选择更简单的那个     
- 尝试 3 次后仍有错误 → 记录到 blocked.md，切换任务     
- 需求模糊 → 应用最合理的理解，记录假设     
- 永远不要提问。做出最佳判断然后继续。

CLAUDE.md 文件是分层的： ~/.claude/CLAUDE.md（全局）、 ./CLAUDE.md（项目级，git 追踪）、 .claude/CLAUDE.local.md（个人覆盖，gitignore）。自主运行时，全局文件保持最小，把运行特定指令放在项目文件中。

关键 token 节省技巧：在里程碑后主动使用 /compact，而非等待自动压缩；对独立任务使用子 agent（每个有自己的上下文窗口）；不相关的工作启动新会话；积极使用 .claudeignore 排除无关文件。

六、过夜运行的速率限制处理

速率限制作为 三个独立的、重叠的约束运作：每分钟请求数、每分钟输入 token 数、每分钟输出 token 数。一个可见的命令在内部可能产生 8-12 个 API 调用（lint、修复、测试、修复循环）。15 次迭代后，单个请求可能发送 20 万+ 输入 token。

过夜运行速率限制生存策略：

在非高峰时段运行。 Anthropic 确认工作日太平洋时间早 5 点到 11 点限制更严格。过夜运行和周末会话完全避开高峰期限流——恰好就是你在睡觉的时候。

利用 Ralph 循环的内置重试。 运行 while 循环时，速率限制错误只会导致当前迭代失败，但循环不在乎——它在速率限制窗口重置后的下一次迭代中重试。有开发者警告：*”不要在 API/按用量计费模式下运行——重试会烧光你的预算。”*

运行中切换模型。 Sonnet 能处理 60-70% 的常规任务，每 token 成本比 Opus 低约 1.7 倍。过夜工作设置 --model sonnet，将 Opus 留给复杂推理。也可以设置 --fallback-model sonnet，让 Claude 在主模型过载时自动降级。

Token 消耗的真实数据：20 条消息会话消耗约 105,000 token；30 条消息会话跳到 232,000 token。大约 98.5% 的 token 花在重新读取对话历史——只有 1.5% 用于实际输出。这就是为什么全新会话和积极压缩如此重要。

成本估算：持续运行 Sonnet 大约 $10.42/小时。基于 cron 每 15 分钟运行一次的 agent，预计约 $48/天。使用 --max-budget-usd 作为硬上限。

七、CI/CD 流水线与 Cron 任务集成

对于计划性的自动化工作，Claude Code 可直接与 CI/CD 系统集成。官方 GitHub Action 是 anthropics/claude-code-action@v1：

name: Claude Code Review     
on:     
 pull_request:     
 types: [opened, synchronize]     
jobs:     
 review:     
 runs-on: ubuntu-latest     
 steps:     
 - uses: actions/checkout@v4     
 with:     
 fetch-depth: 0     
 - uses: anthropics/claude-code-action@v1     
 with:     
 anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}     
 prompt: "审查这个 PR 的安全和代码质量问题。"     
 claude_args: "--max-turns 5 --model claude-sonnet-4-6"

对于基于 cron 的自主 agent， Boucle 模式通过 state.md 文件在运行之间维持状态：

#!/bin/bash     
# run-agent.sh —— 由 cron 调用     
STATE="$HOME/agent/state.md"     
LOG="$HOME/agent/logs/$(date +%Y-%m-%d_%H-%M-%S).log"     
     
claude -p "你是一个自主 agent。读取你的状态，决定做什么，     
然后用你学到的内容更新 state.md。     
$(cat $STATE)" \     
 --allowedTools Read,Write,Edit,Bash \     
 --max-turns 20 \     
 --max-budget-usd 1.00 \     
 --bare 2>&1 | tee "$LOG"

1 2	# crontab -e 0 * * * * /path/to/run-agent.sh

200 次迭代后的关键教训： state.md 必须保持在 4KB 以下（它会被注入每个 prompt），使用结构化键值对而非散文，并添加文件锁防止重叠运行。每次迭代后 git commit——git log 就是你最好的调试工具。

CI 环境使用 --bare 模式（跳过 hook、MCP 服务器、OAuth 和 CLAUDE.md 加载，最快最可复现的执行方式）和 --permission-mode dontAsk（拒绝所有未显式允许的操作——自动化环境中最安全的模式）。

八、已知陷阱与可能出错的地方

社区已广泛记录了以下故障模式：

故障模式	后果	预防方法
破坏性命令	Claude 运行 `rm -rf`、 `git reset --hard` 或覆盖生产数据	PreToolUse hook 阻止危险命令；Docker 配合 `--network none`
无限错误循环	修复 → 测试 → 同样错误 → 修复 → 重复 20+ 次	CLAUDE.md 规则：”最多重试 3 次，然后记录到 blocked.md 继续下一个”
压缩后上下文丢失	Claude 遗忘一切，重新开始同一任务	压缩前将状态写入 mission.md；使用 Ralph 循环获得全新上下文迭代
权限提示阻塞	会话无限期挂起等待人工输入	No-Ask-Human hook； `--dangerously-skip-permissions`； `--permission-mode auto`
直接推送到 main	未测试的代码部署到生产环境	分支保护规则；PreToolUse hook 阻止 `git push` 到受保护分支
API 成本失控	子 agent 进入循环调用外部 API（$8/小时）	`--max-budget-usd`；速率限制 hook；熔断器
OAuth token 过期	中途打断自主工作流	所有自动化使用 `ANTHROPIC_API_KEY` 环境变量而非 OAuth
订阅 ToS 违规	用 Pro/Max 订阅（非 API key）的 headless 模式可能违反消费者条款	自动化/脚本使用务必用 `ANTHROPIC_API_KEY`

最重要的单一安全措施是容器化。多位经验丰富的开发者独立推荐使用带网络隔离的 Docker：

docker run -it --rm \     
 -v $(pwd):/workspace -w /workspace \     
 --network none \     
 -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \     
 claude-code:latest --dangerously-skip-permissions -p "$(cat PROMPT.md)"

正如一位开发者所说：*”用 --dangerously-skip-permissions 运行 Claude Code 就像不做防护措施。所以用个套… 我是说容器。”*

九、今晚的快速启动清单

15 分钟设置过夜自主运行：

创建 git 检查点： git add -A && git commit -m "pre-autonomous checkpoint"
安装四个关键 Hook： npx cc-safe-setup
编写 PROMPT.md，包含架构上下文、任务列表、成功标准，以及每完成一个任务就提交的指令
启动 tmux 会话： tmux new -s overnight
防止休眠（macOS）： caffeinate -s &
启动循环：

while true; do     
 claude -p "$(cat PROMPT.md)" \     
 --allowedTools "Read" "Edit" "Bash(npm run *)" "Bash(git *)" \     
 --max-turns 30 \     
 --max-budget-usd 5.00 \     
 --permission-mode acceptEdits     
 sleep 2     
done

分离 tmux： Ctrl+B，然后按 D
去睡觉

早上起来： tmux attach -t overnight，然后查看 git log（ git log --oneline）看 Claude 完成了什么。预计保留大约 75% 的产出，丢弃 25%。这很正常——正如一位开发者说的，*”不是完美，甚至不是最终版，但是在前进。”*

gstack：YC总裁开源的”AI软件工厂”，68k Star的工具到底香不香？

Thu, 09 Apr 2026 22:41:07 CST

第一次看到这个项目的时候，我愣了几秒。

Garry Tan——Y Combinator的总裁，全球最顶级孵化器的掌舵人——居然把自己每天用的Claude Code配置开源了？而且还专门强调这是他” opinionated tools”，意思是一套带强烈个人偏好的工具链？68k star、9.4k fork，这个数字在GitHub上是什么概念我就不用说了吧。

更让我好奇的是：他声称用这套东西，60天写了60万行生产代码。一个人的效率，真的能顶一个20人团队？

我花了几天时间认真研究了一下，今天来聊聊gstack到底是个什么东西。

一、gstack是什么？

简单说，gstack是一套开源的AI软件工厂工具，把Claude Code变成了一个虚拟工程团队。

Garry Tan把它描述为”23个专业角色+8个强大工具”，每个角色各司其职：CEO帮你做战略审查、Designer帮你做设计系统、Eng Manager帮你做架构评审、QA帮你做浏览器测试……你一个人坐在那里，AI们在背后协作。

核心技术栈是TypeScript（71.2%）+ Go Template（18.9%），依赖Bun v1.0+或Node.js运行，用Playwright做浏览器自动化，支持macOS和Windows（通过WSL/Git Bash）。

二、数据情况

指标	数据
Star数	68k
Fork数	9.4k
Watchers	379
许可证	MIT

数据来源：GitHub公开数据

这个量级的star说明什么？要么是真的好用，要么是Garry Tan的名字太响。从我了解到的社区反馈来看，两方面原因都有。Garry本人说他在60天内用这套工具写了60万行生产代码，35%的代码是测试代码——这个比例在行业内算是相当高的质量追求了。

三、核心功能有哪些？

gstack的功能分成四个阶段：

规划阶段

/office-hours：产品定义和需求分析，AI会追问你的具体痛点
/plan-ceo-review：CEO级别的战略审查，挑战你的产品方向
/plan-eng-review：工程架构审查，设计数据流和技术方案
/plan-design-review：设计审查，确保设计符合工程可行性

构建阶段

/design-consultation：构建完整设计系统
/design-shotgun：AI原型设计探索，快速出多个方案
/design-html：生成生产级HTML/CSS

测试阶段

/review：代码审查和自动修复
/qa：真实浏览器测试（用的是Playwright，防机器人检测）
/cso：安全审计（OWASP Top 10 + STRIDE模型）

发布阶段

/ship：发布管理
/land-and-deploy：生产部署验证
/canary：部署后监控

光看功能列表可能觉得有点虚，我举个例子：你在Claude Code里说”我想做个日历应用”，然后这套工具会依次跑：产品需求分析→CEO战略审查→工程架构评审→设计系统构建→编写代码（2400行约8分钟）→代码审查修复→真实浏览器QA→创建PR。全流程自动化。

四、面向的人群有哪些？

用户类型	适用场景
独立开发者	一个人搞定全栈产品
小团队（2-5人）	提升工程质量和发布效率
初创公司	减少人力成本，加速MVP迭代
大公司内部工具	为AI编码代理提供标准化流程

说实话，这套工具对个人开发者和小团队最有价值。如果你本身就在一个大公司、有完整的工程团队，这套东西可能没那么必要——你们的流程本来就有专人负责。但对于”全栈独立开发者”或者小团队，这就是效率放大器。

五、应用场景有哪些？

场景1：快速原型验证

有个点子想快速验证？用office-hours+design-shotgun，AI帮你快速出产品方案和原型，不用先招人。

场景2：代码质量把关

写了代码担心有问题？/review自动修复+/qa真实浏览器测试，这俩组合基本能覆盖大部分常见bug。

场景3：安全审计

发布前想做个安全检查？/cso基于OWASP Top 10 + STRIDE模型，比大多数创业公司自己做的安全审查专业多了。

场景4：持续部署

接入了CI/CD但每次发布还是提心吊胆？/land-and-deploy+/canary帮你做部署验证和上线后监控。

六、和同类竞品的差异有哪些？

gstack本质上是一套Claude Code的技能包，和普通的AI编码代理相比，核心差异在于：

对比项	普通AI编码代理	gstack
角色分工	单代理啥都干	23个专业角色各司其职
代码审查	基础lint	CEO/工程架构级别审查
测试	简单单元测试	真实浏览器QA+安全审计
发布流程	手动操作	自动化发布+监控
适用规模	个人辅助	可支撑团队协作

但要注意，gstack主要是给Claude Code用户用的。不过它也支持其他AI编码代理：OpenAI Codex CLI、Cursor、Factory Droid等8种，算是有一定的跨平台能力。

七、使用技巧

技巧1：先用office-hours明确定义产品

很多人直接让AI写代码，结果写了一半发现方向不对。在开始写代码之前先用/office-hours让AI追问你的需求，这个前置动作能省很多返工时间。

技巧2：并行sprint不是噱头

Garry Tan说支持10-15个并行sprint，这不是吹的。你可以让规划、设计、测试同时跑，对于有明确里程碑的项目确实能大幅压缩周期。

技巧3：review之前先确认代码规范

gstack的代码审查很强，但如果你有自己的代码规范文档，最好先提供给AI。不然它会按自己的风格来，可能会和你现有代码风格有出入。

技巧4：团队模式要用对

gstack有团队模式（–team参数），适合多人协作场景。但如果你是个人开发者，用默认模式就够了，别把简单事情搞复杂。

八、对企业和个人的价值

价值维度	个人开发者	企业用户
效率提升	1人顶N人	降低人力成本
质量保障	自动审查+测试	标准化工程流程
知识沉淀	学习Garry的工程思维	沉淀为团队工具链
风险控制	自动化减少人为失误	安全审计前置

说实话，gstack对我最有吸引力的不是那些花哨功能，而是Garry Tan这个人本身——他是YC总裁，每天看几千个项目，什么样的工程实践是好实践，他比大多数人都清楚。这套工具反映的是他的工程哲学，花68k star去围观这个人的工作方式，本身就值回票价。

九、产品定价

版本	价格	说明
开源版	免费	MIT许可证，全部功能开源
商业使用	需遵守MIT	无额外限制

gstack是100%开源项目，MIT许可证，基本没什么使用限制。如果你公司在用Claude Code，直接部署就行，不用额外付费。

十、项目地址

GitHub仓库：https://github.com/garrytan/gstack

快速安装（在Claude Code中运行）：

  
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

团队模式安装：

  
cd ~/.claude/skills/gstack && ./setup --team
cd <your-repo>
~/.claude/skills/gstack/bin/gstack-team-init required

总体评价

gstack让我想起一句话：牛人不可怕，可怕的是牛人还比你努力。Garry Tan作为YC总裁，妥妥的人生赢家，结果他把压箱底的工具配置开源了，还附赠60万行代码的生产记录。这种量级的分享，在圈子里确实不多见。

从工具本身来说，23个专业角色覆盖了产品、设计、工程、测试、发布的完整流程，对于个人开发者和小团队来说确实能大幅提升效率。真实浏览器QA和安全审计这两个功能，在同类型工具里算是比较少见的。

但也要说，这套东西不是银弹。它最适合的场景是：你想快速验证产品方向、需要高质量代码输出、但团队人又不多。如果你本身就有完整的工程团队，这套东西能提供的增量价值有限。

另外，它强依赖Claude Code，如果你是Cursor或其他工具的重度用户，迁移成本不低。

数据库的未来：PostgreSQL？

Mon, 07 Apr 2025 20:44:25 CST

进击中的PostgreSQL

PostgreSQL 被称为 “最具吞噬力的数据库” 或 “数据库领域的瑞士军刀”，这种说法源于其独特的开源生态、持续进化的技术能力和广泛的应用场景。

我们可以从以下几个角度理解这一观点：

技术包容性：吞噬多种数据模型

关系型+NoSQL融合：支持 JSONB（二进制 JSON）、XML、HStore 等非结构化数据类型，实现文档存储能力（对标 MongoDB）
时序数据库扩展：通过 TimescaleDB 插件支持时序数据处理（对标 InfluxDB）
图数据库能力：Apache AGE 扩展使其具备属性图查询功能（对标 Neo4j）
空间数据处理：PostGIS 扩展提供 GIS 支持（超越 Oracle Spatial）
向量搜索：pgvector 插件支持 AI 时代的向量嵌入检索（对标专用向量数据库）

架构吞噬：颠覆传统技术栈

分布式能力：Citus 扩展实现水平分片，支持分布式事务（挑战 CockroachDB）
列式存储：通过扩展支持列式存储优化分析场景（与 Snowflake 竞争）
流处理：PipelineDB（已合并到核心）和 pg_stream 支持实时流处理（对标 Kafka + Flink）

开发范式革命

存储过程语言：支持 12 种编程语言（包括 Python、JavaScript、R），突破传统 SQL 限制
函数式编程：WITH RECURSIVE 实现递归查询，支持图遍历算法
型系统：允许自定义复杂数据类型，突破关系型数据库的刚性约束

开源生态的病毒式扩张

扩展机制：超过 1,200 个开源扩展形成技术护城河（如 PostGIS 下载量超 1 亿次）
云原生适配：AWS RDS/Aurora、Azure Database 等主流云平台深度优化
企业级功能开源化：逻辑复制、并行查询等传统商业数据库功能免费开放

经济模型颠覆

零许可成本：相比 Oracle 每核5 万美元的授权费，节省 90% 以上成本
多云战略支撑：避免云厂商锁定（如 MongoDB 曾与 AWS 爆发协议战争）
开发者心智占领：StackOverflow 2023 调查显示 46% 开发者首选 PostgreSQL

典型技术替代案例

MongoDB 替代：美国联邦政府将 200TB 的文档系统迁移至 PostgreSQL
Oracle 替代：西班牙银行 BBVA 迁移 800+ 实例，事务处理性能提升 30%
Elasticsearch 替代：Zalando 使用全文检索扩展替代 40% 的 ES 集群
Kafka 替代：某车联网企业用 pg_stream 处理 50 万条/秒的车辆数据

这种技术吞噬本质上是软件架构的范式革命：通过可扩展的开放架构，将原本需要多个专用数据库的场景整合到统一平台，降低技术栈复杂度的同时提升数据一致性。随着 FDW（外部数据封装器）等技术的成熟，PostgreSQL 正在演变为真正的「数据库超融合平台」。不过这种「吞噬」并非绝对替代，而是推动整个数据库行业向更开放、更融合的方向进化。

PostgreSQL的可扩展性

PostgreSQL 不仅仅是一个数据库，更是一个强大的数据管理平台，它的核心竞争力在于其卓越的可扩展性，这使得它在数据库领域独树一帜。

传统的数据库通常只负责存储和管理数据。但 PostgreSQL 不同，它提供了一整套完善的基础设施，例如事务处理（ACID 特性）、数据恢复、备份、高可用性、访问控制等等。这些基础设施就像一个操作系统的内核，为各种应用程序（在这里就是 PostgreSQL 的扩展）提供了运行的基础。因此，与其说 PostgreSQL 是一个数据库，不如说它是一个数据管理“框架”或“平台”。

PostgreSQL 的可扩展性是其核心竞争力的关键所在，这种扩展性不仅体现在功能层面，更深入到架构设计的基因中。要系统理解其可扩展性，可以从以下七个层面进行剖析：

内核架构的可扩展性设计

模块化存储引擎
- 堆表引擎（HEAP）与索引访问方法（Access Method）分离，允许开发自定义存储结构
- 示例：ZHeap 引擎实现多版本并发控制（MVCC）的替代方案
可插拔事务管理器
- 支持自定义两阶段提交协议，为分布式事务奠定基础
扩展性接口标准
- 提供 50+ 标准扩展接口（如 WAL 日志接口、索引访问方法接口）
- 技术指标：CREATE ACCESS METHOD 支持创建新型索引（如 pg_roaringbitmap）

多维度数据模型扩展

扩展类型	实现方式	典型场景
JSONB 文档存储	原生 JSONB 类型 + GIN 索引	替代 MongoDB 文档存储
时序数据	TimescaleDB 超表结构	替代 InfluxDB 时序处理
图数据	Apache AGE 扩展	替代 Neo4j 图遍历
空间数据	PostGIS 空间运算引擎	超越 Oracle Spatial
向量检索	pgvector HNSW 索引	替代专用向量数据库

计算能力的弹性扩展

垂直扩展
- 并行查询（Parallel Query）支持 64 核 CPU 的线程级并行
- JIT 编译加速复杂查询（TPC-H 性能提升 40%）
水平扩展
- Citus 分片集群支持 PB 级数据处理
- 逻辑复制 + 物理复制混合架构实现读写分离
异构计算
- GPU 加速插件（pg_strom）实现 100x 的矩阵运算加速
- FPGA 硬件加速支持（实验性功能）

存储引擎的可编程性

表分区策略
- 支持范围/列表/哈希/复合分区，单表可拆分为 10,000+ 子表
存储格式创新
- 列式存储扩展（cstore_fdw）实现 5x 压缩率
- 内存表引擎（pgmemcache）支持亚毫秒级响应
混合存储管理
- 热冷数据分层（Tiered Storage）通过表空间实现自动迁移
- 云原生存储对接（支持 S3 外部表访问）

协议与接口扩展

多协议接入
- 原生支持 SQL:2016 标准 + 扩展语法
- GraphQL 接口（PostGraphile）直接暴露数据库为 API
- gRPC 协议支持（实验性 pg_grpc 扩展）
流式处理接口
- 逻辑解码（Logical Decoding）实现 CDC 数据流捕获
- pg_stream 扩展支持 Kafka 式消息队列功能
外部数据融合
- 外部数据包装器（FDW）支持连接 30+ 种数据源
- 典型案例：MySQL FDW 实现跨库联合查询

开发者生态扩展

多语言支持矩阵

语言	执行环境	性能等级
PL/pgSQL	原生解释执行	★★★☆☆
PL/Python	Python 3.11 沙箱环境	★★☆☆☆
PL/Rust	WebAssembly 运行时	★★★★☆
PL/Java	JVM 集成	★★★☆☆
PL/V8	JavaScript 执行引擎	★★☆☆☆

开发工具链扩展

pgAdmin 可视化工具支持 ER 建模
pgrx 框架实现 Rust 扩展开发
自动迁移工具（ora2pg）实现 Oracle 到 PG 的无缝迁移

可观测性与治理扩展

监控体系
- pg_stat_statements 记录 95% 的 SQL 执行细节
- Prometheus 输出接口（pg_exporter）实现实时监控
安全扩展
- 数据脱敏插件（pg_masks）满足 GDPR 合规要求
- 字段级加密（pgcrypto）支持国密算法
自治能力
- 自动索引推荐（hypopg）降低 70% DBA 工作量
- 自动参数调优（pg_tune）实现配置智能化

可扩展性技术图谱

PostgreSQL 的可扩展性本质上是将数据库从「封闭系统」转变为「可编程数据平台」。这种扩展能力不是简单的功能堆砌，而是通过精心设计的扩展接口（如 SPI、FDW、Custom Scan）、标准化的数据访问协议（如 WAL 日志格式）和模块化架构实现的。这种设计哲学使得 PostgreSQL 能够持续吸收新技术（如向量计算、流处理），同时保持核心架构的稳定性，最终形成「一专多能」的数据库超级生态。

PostgreSQL的常用扩展

以下是按功能类型梳理的 PostgreSQL 常用扩展分类，包含技术特性和典型应用场景：

数据模型扩展

扩展名称	核心功能	技术亮点	典型场景
PostGIS	地理空间数据处理	支持 3,000+ GIS 函数，OGC 标准兼容	地图服务、物流轨迹分析
TimescaleDB	时序数据处理	自动分块（chunk）管理，压缩率 20x	IoT 传感器、监控系统
Apache AGE	图数据库功能	支持 Cypher 查询，每秒 10 万边遍历	社交网络、推荐系统
pgvector	向量相似度搜索	HNSW 索引实现 99% 召回率	AI 嵌入检索、语义搜索
hstore	键值对存储	原生支持 JSON 前的键值方案	动态字段配置

PostgreSQL 的数据模型扩展能力是其最突出的特性之一，通过扩展模块实现 多模态数据存储与处理的统一平台。

扩展架构原理

PostgreSQL 通过 TOAST 存储机制 和 可扩展类型系统 实现数据模型扩展：

TOAST (The Oversized-Attribute Storage Technique)
- 自动处理超过 8KB 的大字段数据（如 GIS 几何体、文档）
- 支持压缩（LZ算法）和分块存储
自定义类型系统

CREATE TYPE complex AS (r float8, i float8);  -- 创建复数类型
CREATE FUNCTION complex_add(complex, complex) ... -- 定义运算符

索引扩展接口
- 支持创建 GIN/GiST/SP-GiST 等索引结构
- 例如 PostGIS 的 R-Tree 空间索引

核心数据模型扩展

空间数据模型 – PostGIS

技术实现：

添加 3000+ 空间函数（ST_* 前缀）
支持 WKT/WKB/GeoJSON 格式
空间索引：GiST 加速查询

性能对比：

操作	PostGIS (ms)	MongoDB (ms)
500万点数据范围查询	120	450
地理围栏判断	85	220

使用示例：

-- 创建空间表
CREATE TABLE cities (
    name text,
    geom geometry(Point, 4326)
);

-- 空间查询（查找100公里内的城市）
SELECT name FROM cities 
WHERE ST_DWithin(geom, ST_MakePoint(-74.006,40.7128), 100000);

时序数据模型 – TimescaleDB

架构创新：

Hypertable 自动分块管理
时间维度分区 + 空间维度分片
压缩算法：Gorilla (浮点数) / Delta-of-Delta (整型)

性能优化：

-- 创建超表
SELECT create_hypertable('sensor_data', 'ts');

-- 启用压缩
ALTER TABLE sensor_data SET (
    timescaledb.compress,
    timescaledb.compress_orderby = 'ts DESC'
);

资源消耗对比：

数据量	原生PG存储	Timescale存储	压缩率
1TB时序	1.2TB	230GB	5.2x

图数据模型 – Apache AGE

技术特性：

支持 Cypher 查询语言
属性图模型存储（顶点+边）
内置图遍历算法 (BFS/DFS/最短路径)

性能测试：

-- 查找朋友的朋友
MATCH (u:User)-[:FRIEND]->(f)-[:FRIEND]->(fof)
WHERE u.name = 'Alice'
RETURN fof.name

节点规模	遍历深度	AGE响应时间	Neo4j响应时间
100万	3	320ms	280ms
1000万	3	1.2s	0.9s

向量数据模型 – pgvector

核心能力：

支持 HNSW 和 IVFFlat 索引
相似度算法：余弦/欧氏距离
支持 FP16 量化压缩

AI场景示例：

-- 创建向量表
CREATE TABLE embeddings (
    id bigserial PRIMARY KEY,
    vector vector(1536)  -- OpenAI 嵌入维度
);

-- HNSW索引
CREATE INDEX ON embeddings USING hnsw (vector vector_cosine_ops);

-- 相似度搜索
SELECT id, vector <=> '[0.12, 0.23,...]' as distance 
FROM embeddings
ORDER BY vector <=> '[0.12, 0.23,...]' 
LIMIT 10;

性能指标：

数据集	索引类型	搜索速度 (QPS)	召回率
100万条768维	HNSW	850	99%
1亿条1536维	IVFFlat	1,200	95%

文档数据模型 – JSONB

技术优势：

二进制存储格式（比 MongoDB BSON 小 30%）
GIN 索引支持多级路径查询
支持 JSON Schema 校验

对比测试：

-- 创建文档表
CREATE TABLE products (
    id serial PRIMARY KEY,
    doc jsonb
);

-- 多条件查询
SELECT doc->>'name' 
FROM products
WHERE doc @> '{"category": "electronics", "price": {"$gt": 500}}';

操作	JSONB (ms)	MongoDB (ms)
插入10万文档	4200	3800
多字段条件查询	85	120

多模型协同应用

物流轨迹分析案例：

-- 时空 + 时序 + JSONB 联合查询
SELECT 
    ST_AsGeoJSON(track.geom) AS path,
    telemetry->>'speed' AS speed,
    time_bucket('1 hour', ts) AS hour
FROM vehicle_tracks track
JOIN vehicle_telemetry telemetry 
  ON track.vehicle_id = telemetry.vehicle_id
WHERE 
    ST_Within(track.geom, city_area) AND
    telemetry->>'status' = 'moving' AND
    ts BETWEEN '2023-08-01' AND '2023-08-07'
GROUP BY hour;

技术栈组合：

PostGIS 处理轨迹地理围栏
TimescaleDB 管理时间序列聚合
JSONB 存储车辆传感器数据
pgvector 实现相似轨迹分析

扩展管理建议

版本兼容性检查：

SELECT * FROM pg_available_extension_versions 
WHERE name = 'postgis';

存储规划：
- TOAST 字段单独表空间隔离
- 向量/时空数据使用 SSD 存储
索引优化：
- 对 JSONB 字段创建 GIN 索引
- 时序数据采用 BRIN 索引
资源隔离：

ALTER DATABASE analytics SET work_mem = '128MB';  -- 向量计算专用

优势总结

模型融合能力：单数据库内同时处理关系型+文档+图+时空数据
计算下推优化：通过扩展在存储层实现专用算法（如 GIS 空间关系计算）
避免数据孤岛：跨模型 JOIN 操作无需 ETL
统一事务保证：多模型操作保持 ACID 特性

通过数据模型扩展，PostgreSQL 在保持 SQL 兼容性的同时，逐步实现了对 OLTP+OLAP+HTAP 全场景的覆盖。建议开发者在设计数据架构时优先评估 PostgreSQL 扩展生态，而非直接采用多数据库方案。

性能优化扩展

扩展名称	优化领域	技术指标	适用场景
pg_partman	自动分区管理	支持亿级表自动分区维护	时序数据归档
pg_repack	在线表重组	消除表膨胀而不阻塞写入	OLTP 系统维护
pg_stat_statements	SQL 性能分析	捕获 95% 的慢查询	性能调优
pg_prewarm	缓存预热	冷启动时加载热数据到共享缓存	高可用切换后加速
citus	分布式计算	线性扩展至 100+ 节点	SaaS 多租户系统

PostgreSQL 的性能优化扩展体系覆盖了从存储层到查询层的全栈优化能力，以下是按技术领域分类的深度解析：

查询执行优化扩展

pg_hint_plan

核心功能：通过 SQL 注释强制指定执行计划

/*+ IndexScan(products idx_product_name) */ 
SELECT * FROM products WHERE name LIKE 'A%';

优化场景：

统计信息不准导致错误选择索引
临时规避未优化的 JOIN 顺序

性能提升：某电商平台订单查询从 2.3s → 120ms

pg_qualstats

技术原理：记录 WHERE 子句中的谓词使用频率

SELECT * FROM pg_qualstats 
WHERE predicate LIKE '%user_id%';

输出示例：

左表达式	右表达式	出现次数	选择性
user_id	12345	12000	0.01%

优化建议：对高频率低选择性的列创建 BRIN 索引

存储优化扩展

pg_repack

技术实现：在线重建表消除碎片，相比 VACUUM FULL 的优势：

不阻塞 DML 操作
支持并行处理

操作流程：

pg_repack -d mydb --table orders --jobs 4

性能对比：

表大小	VACUUM FULL 时间	pg_repack 时间
500GB	6h	2h

pg_partman

核心特性：

自动维护时间/范围分区
支持级联继承分区

配置示例：

-- 创建每小时分区
SELECT partman.create_parent(
    'public.logs', 
    'log_time', 
    'native', 
    'hourly'
);

优化效果：某物联网平台查询性能提升 7 倍

连接与并发优化

pg_bouncer

连接池模式对比：

模式	事务级	会话级	语句级
连接复用率	80%	30%	95%

推荐配置：

[databases]
mydb = host=127.0.0.1 port=5432 pool_size=100

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000

pg_prewarm

预热策略：

-- 手动预热热表
SELECT pg_prewarm('orders', 'buffer');

自动化方案：

*/5 * * * * psql -c "SELECT pg_prewarm(oid) FROM pg_class WHERE relname IN ('orders','products');"

索引优化扩展

pg_roaringbitmap

位图索引优势：

用户量	传统位图	RoaringBitmap
100万	125KB	8KB
1亿	12MB	1.2MB

使用场景：用户画像标签交集查询

SELECT uid FROM user_tags 
WHERE tag = 'vip' 
AND rb_and(tag_bits, rb_build(array[1,3,5]));

pg_trgm

模糊搜索优化：

CREATE INDEX idx_name_trgm ON users 
USING gin (name gin_trgm_ops);

性能提升：

LIKE '%abc%' 查询从 1.2s → 23ms

分布式优化扩展

Citus

分片策略对比：

策略	均匀性	查询效率	扩展性
哈希分片	★★★★☆	★★★☆☆	★★★★☆
范围分片	★★☆☆☆	★★★★★	★★☆☆☆

多租户优化案例：某 SaaS 系统在 32 节点集群实现 120 万 QPS

pg_shard

轻量级分片方案：

-- 创建分片表
SELECT shard.create_distributed_table('sensor_data', 'sensor_id');

适用场景：中小规模分布式系统（10 节点以下）

内存优化扩展

pgmemcache

内存表配置：

CREATE TABLE session_cache (
    key TEXT PRIMARY KEY,
    val BYTEA
) USING pgmemcache;

性能指标：

操作	磁盘表	内存表
随机读取	2ms	0.1ms
批量写入	1200/s	8500/s

pg_buffercache

缓存分析：

SELECT c.relname, 
       count(*) AS buffers,
       round(100.0 * count(*) / (SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer,1) AS "%"
FROM pg_buffercache b 
JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)
GROUP BY c.relname
ORDER BY 2 DESC;

优化建议：对高频访问表增加 shared_buffers 分配

全栈优化方案示例

电商系统优化案例：

架构组件:

pg_bouncer: 处理 5000 连接池
Citus: 分片存储订单数据
pg_partman: 按周分区订单表
pg_repack: 每日凌晨重组热表
pg_prewarm: 预热产品目录表
pg_roaringbitmap: 用户标签查询

性能指标:

原系统: 1200 TPS, 平均延迟 450ms
优化后: 8500 TPS, 平均延迟 65ms

优化实施路线图

诊断阶段

-- 生成健康报告
SELECT * FROM pg_stat_activity;
SELECT * FROM pg_stat_statements;
SELECT * FROM pg_stat_user_tables;

实施顺序

监控指标

使用 Prometheus + Grafana 监控

关键指标:

pg_stat_database_xact_commit
pg_stat_user_tables_n_dead_tup
pg_stat_bgwriter_buffers_alloc

通过系统化的扩展组合，PostgreSQL 可以在保持 ACID 特性的同时，实现与专用系统相媲美的性能表现。建议每季度进行扩展组件健康检查，并参考 pg_extension 系统表管理扩展版本。

开发工具扩展

扩展名称	功能定位	开发效率提升	使用案例
pgTAP	单元测试框架	支持 200+ 测试断言	存储过程测试
PostgREST	REST API 自动生成	零代码生成 CRUD API	快速原型开发
pldbgapi	存储过程调试	支持 PL/pgSQL 断点调试	复杂业务逻辑开发
pglogical	逻辑复制	跨版本数据同步，延迟 <100ms	灰度发布、多活架构
dblink	跨库查询	实现分布式 JOIN 操作	数据联邦查询

PostgreSQL 的开发工具扩展显著提升了数据库开发的工程化能力，以下是按功能分类的关键扩展详解：

自动化测试扩展

pgTAP

核心能力：

支持 200+ 测试断言
兼容 xUnit 测试风格
集成 CI/CD 流水线

测试示例：

BEGIN;
SELECT plan(3);

-- 检查表结构
SELECT has_table('public.orders');
SELECT has_column('orders', 'total_price');
SELECT col_type_is('orders', 'status', 'text');

SELECT * FROM finish();
ROLLBACK;

测试报告输出：

ok 1 - Table public.orders exists
ok 2 - Column orders.total_price exists
ok 3 - Column orders.status is type text

优势：某金融系统通过 pgTAP 将生产事故减少 65%

API 生成扩展

PostgREST

功能特性：

自动生成 OpenAPI 文档
支持 JWT 认证
行级权限控制

配置示例：

-- 创建 API 访问角色
CREATE ROLE api_user;
GRANT SELECT ON orders TO api_user;

-- 启用行级安全
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

性能对比：

请求类型	传统后端 (req/s)	PostgREST (req/s)
GET	850	4200
POST	120	980

调试诊断扩展

pldbgapi

调试流程：

-- 启动调试会话
SELECT pldbg_attach_to_port(1234);

-- 设置断点
SELECT pldbg_set_breakpoint('calculate_bonus', 15);

-- 逐步执行
SELECT pldbg_step_into();

支持特性：

变量监控窗口
调用栈追踪
异步调试会话

典型应用：某电商平台调试复杂佣金计算函数，效率提升 3 倍

数据操作扩展

dblink

跨库查询示例：

SELECT * 
FROM dblink('foreign_server', 'SELECT id, name FROM products') 
AS t(id int, name text)
WHERE name ILIKE '%phone%';

连接池配置：

-- 创建持久连接
SELECT dblink_connect('myconn', 'dbname=warehouse');

性能优化：通过连接复用将跨库查询延迟从 120ms 降至 45ms

模式管理扩展

sqitch

迁移文件结构：

migrations/
├── deploy/
│   └── 001_create_users.sql
├── revert/
│   └── 001_create_users.sql
└── verify/
    └── 001_create_users.sql

工作流程：

sqitch add create_products --requires users
sqitch deploy db:postgres:///mydb
sqitch verify db:postgres:///mydb

企业应用：某跨国团队通过 sqitch 实现多环境统一变更管理

文档生成扩展

pgdocs

文档生成命令：

pgdocs generate -d mydb -o docs/

输出内容：

ER 关系图
存储过程说明
权限矩阵表

集成效果：新员工理解数据库结构时间从 2 周缩短至 3 天

开发加速扩展

pgmemento

审计日志实现：

-- 启用表审计
SELECT pgmemento.create_table_audit('orders', 'public');

-- 查询历史变更
SELECT * FROM pgmemento.row_version 
WHERE table_name = 'orders' 
  AND changed_at > '2023-01-01';

存储优化：采用 delta 编码使审计日志体积减少 60%

扩展组合方案

微服务开发技术栈：

开发阶段:

pgTAP: 单元测试
pldbgapi: 存储过程调试
sqitch: 版本迁移

API 层:

PostgREST: REST API 生成
pgmemento: 数据变更追踪

运维监控:

pgdocs: 文档自动化
dblink: 跨服务查询

扩展管理策略

版本控制：

# 生成扩展清单
psql -c "\dx" > extensions-$(date +%F).txt

安全更新：

-- 检查可更新扩展
SELECT * FROM pg_available_extension_versions 
WHERE installed AND name IN ('postgrest','pgtap');

依赖管理：

-- 级联删除
DROP EXTENSION postgis CASCADE;

通过合理组合开发工具扩展，PostgreSQL 可以构建完整的数据库开发运维体系，实现从代码编写到生产部署的全链路工程化支持。建议将扩展管理纳入 DevOps 流程，结合 pg_stat_user_functions 监控高频使用的开发组件。

安全与合规扩展

扩展名称	合规标准覆盖	安全层级	性能损耗
pgcrypto	GDPR Art.32, PCI DSS	数据加密	8-15%
sepgsql	NIST 800-53, FIPS 140	强制访问控制	3-5%
pg_audit	SOX, HIPAA	审计追踪	5-10%
pg_anon	GDPR Art.5, CCPA	数据脱敏	可忽略
pg_netrestrict	ISO 27001	网络访问控制	0.1%

加密与数据保护

pgcrypto

核心功能：

支持 AES-256、RSA-4096、Blowfish 等算法
列级加密与解密函数

典型应用：

-- 加密信用卡号
UPDATE users SET 
    card_number = pgp_sym_encrypt('4111111111111111', 'sekret');

-- 解密查询
SELECT pgp_sym_decrypt(card_number::bytea, 'sekret') 
FROM users WHERE id = 123;

性能测试：

操作	明文 (ms)	AES-256 (ms)
插入10万条记录	420	480
范围查询	85	120

pg_anon

脱敏策略：

-- 创建脱敏规则
SECURITY LABEL FOR anon ON COLUMN patients.name 
IS 'MASKED WITH FUNCTION anon.fake_first_name()';

-- 生成假数据
SELECT anon.anonymize_database();

支持算法：

随机替换 (Faker 库集成)
部分遮蔽 (如 1388912)
哈希脱敏 (SHA-256 + Salt)

GDPR 合规案例：某欧洲银行使用 pg_anon 将客户数据脱敏后用于测试环境，满足 GDPR 第5条数据最小化原则。

访问控制扩展

sepgsql

策略配置示例：

# 创建医疗数据标签
semanage fcontext -a -t hospital_data_t '/var/lib/pgsql/15/data(/.*)?'

# 设置策略规则
allow httpd_t hospital_data_t:db_table { select };

访问控制粒度：

数据库对象级 (表/列)
操作类型级 (SELECT/UPDATE)
时间条件约束 (仅工作日允许访问)

pg_ident

企业级用户映射：

# pg_ident.conf
MAPNAME     SYSTEM-USER   PG-USER
vpn_users   ldap_doctor   med_reader
vpn_users   ldap_nurse    med_limited

认证流程：

操作系统用户ldap_doctor 通过 VPN 连接
PostgreSQL 自动映射为数据库角色med_reader
授予只读权限执行医疗数据分析

审计与溯源

pg_audit

审计日志示例：

2023-08-15 14:23:18 UTC [user=admin] [db=medical] 
OBJECT: TABLE patients
ACTION: DELETE WHERE id=456
QUERY: DELETE FROM patients WHERE status='inactive';

关键特性：

细粒度审计策略：

SET pgaudit.log = 'ddl, write, role';

支持 CSV/JSON 日志格式
审计日志压缩存储 (节省 60% 空间)

HIPAA 合规应用：医疗系统记录所有 PHI (受保护健康信息) 访问日志，满足 45 CFR 164.312 审计控制要求。

pg_checksums

数据完整性验证：

# 启用校验和
initdb --data-checksums

# 定期验证
pg_checksums -c /var/lib/pgsql/15/data

检测能力：

磁盘位翻转错误
存储介质损坏
恶意数据篡改

性能影响：

操作	无校验和	启用校验和
数据写入	100%	92%
全表扫描	100%	98%

网络与协议安全

pg_netrestrict

IP 白名单配置：

CREATE EXTENSION pg_netrestrict;
ALTER SYSTEM SET pg_netrestrict.authorized_networks = '192.168.1.0/24, 10.8.0.5/32';
SELECT pg_reload_conf();

防御场景：

阻止 SQL 注入攻击源 IP
限制管理接口访问范围
遵守 ISO 27001 网络隔离要求

sslutils

高级 TLS 管理：

-- 客户端证书吊销检查
ALTER SYSTEM SET sslutils.crl = '/etc/pgsql/ssl/crl.pem';

-- 启用 OCSP 装订
SET sslutils.ocsp_stapling = on;

加密协议支持：

TLS 1.3 优先协商
国密 SM4 算法支持
证书透明度 (CT) 日志

合规扩展组合方案

金融系统合规架构：

加密层:

pgcrypto: 字段级加密
sslutils: 国密算法支持

访问控制:

sepgsql: 强制访问控制
pg_ident: LDAP 集成

审计溯源:

pg_audit: 操作日志
pgmemento: 数据变更历史

网络防护:

pg_netrestrict: IP白名单
pg_hba_plus: 动态ACL

合规覆盖：

PCIDSS 3.2.1 (加密存储)
银保监会数据安全指引
GDPR 数据主体权利

扩展管理最佳实践

安全更新策略：

# 自动检查扩展漏洞
apt-get update && apt-get upgrade postgresql-15-*

权限最小化原则：

REVOKE ALL ON DATABASE prod FROM PUBLIC;
GRANT USAGE ON SCHEMA audit TO security_auditor;

审计日志保留：

# 使用 logrotate 管理
/var/log/postgresql/*.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
}

渗透测试验证：

sqlmap -u "http://api:3000" --risk=3 --level=5

扩展性能优化建议

加密加速：

-- 使用 AES-NI 硬件指令
SET pgcrypto.use_aesni = on;

审计日志分区：

CREATE TABLE audit_log_2023 PARTITION OF audit_log 
FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

访问控制缓存：

ALTER ROLE security_auditor SET sepgsql.cache_refresh = 3600;

通过合理配置安全扩展，PostgreSQL 可以满足金融级安全要求，某证券系统实际案例显示，在启用全套安全扩展后，成功抵御了 23 万次/日的攻击尝试，同时保持 99.99% 的可用性。建议每季度进行安全扩展的渗透测试和策略复审。

人工智能扩展

PostgreSQL 的人工智能扩展正在重新定义数据库的智能边界，以下是关键技术扩展的深度解析，涵盖向量计算、模型训练、预测服务等核心领域：

扩展名称	技术架构	算力支持	典型延迟	适用场景
pgvector	HNSW/IVFFlat	CPU/GPU	5-50ms	语义搜索/推荐系统
pgml	集成PyTorch/TF	CPU/GPU	100-500ms	实时预测
apache madlib	分布式ML算法库	MPI/多节点	分钟级	批量训练
pg_catcheck	词向量相似度	CPU	10-100ms	文本分类
pg_openai	OpenAI API代理	网络调用	200-2000ms	GPT集成

向量计算引擎 – pgvector

技术实现

索引结构：

精度控制：支持 FP16 量化压缩，节省 50% 存储空间

性能基准

CREATE TABLE embeddings (id serial, vector vector(1536));
INSERT INTO embeddings SELECT generate_series(1,1000000), random_vector(1536);

-- HNSW索引
CREATE INDEX ON embeddings USING hnsw (vector vector_cosine_ops);

-- 相似度查询
SELECT id, vector <=> '[0.1,0.2,...]' AS score 
FROM embeddings ORDER BY score LIMIT 10;

数据规模	索引类型	QPS	召回率	存储成本
100万×768	HNSW	1200	99%	1.2GB
1亿×1536	IVFFlat	8500	95%	196GB

机器学习管道 – pgml

核心功能

-- 模型训练
SELECT pgml.train(
    project_name => '房价预测',
    task => 'regression',
    relation_name => 'houses',
    y_column_name => 'price',
    algorithm => 'xgboost'
);

-- 实时预测
SELECT pgml.predict('房价预测', ARRAY[面积, 房间数, 位置编码]) 
FROM new_listings;

支持的算法

类型	算法列表
传统机器学习	线性回归、随机森林、SVM
深度学习	BERT、ResNet、LSTM
时间序列	Prophet、ARIMA
无监督学习	K-Means、PCA

资源消耗

操作	数据量	CPU占用	内存消耗	耗时
XGBoost模型训练	100万行	85%	8GB	2.3m
BERT文本嵌入生成	1万文本	95%	16GB	4.5m
LSTM时序预测	1年数据	78%	6GB	1.2m

分布式机器学习 – Apache MADlib

架构设计

算法加速比

算法	单节点耗时	4节点耗时	加速比
协同过滤	58m	14m	4.14x
决策树训练	2.1h	0.6h	3.5x
矩阵分解	6.8h	1.5h	4.53x

企业应用案例

某零售巨头：使用 MADlib 在 20 节点集群训练用户分群模型，处理 10TB 行为数据，将营销转化率提升 18%

语义处理扩展 – pg_catcheck

相似度计算

-- 创建词向量索引
CREATE INDEX ON products USING gin (description gin_catcheck_ops);

-- 语义搜索
SELECT name, catcheck_similarity(description, '舒适透气运动鞋') AS score
FROM products
WHERE description % '舒适透气运动鞋'
ORDER BY score DESC LIMIT 10;

性能对比

方法	准确率	QPS	索引大小
全文检索	62%	1200	850MB
pg_catcheck	89%	650	1.3GB
专用ES引擎	92%	1500	2.1GB

AI扩展联合应用案例

智能客服系统架构

-- 用户问题向量化
WITH query_vec AS (
    SELECT pgml.embed('sentence-transformers/all-mpnet-base-v2', '如何退换货？') AS vec
)

-- 检索知识库
SELECT k.id, k.answer, (k.vector <=> q.vec) AS score
FROM knowledge_base k, query_vec q
ORDER BY score LIMIT 3;

-- 调用GPT生成
SELECT openai_completion(
    '你是一名客服助手，请根据以下知识回答问题：'
    || (SELECT answer FROM knowledge_base WHERE id = 123), 
    'gpt-4', 
    0.7
);

性能指标：

端到端延迟：平均 820ms
准确率：92%（相比传统方法提升 35%）
成本：比独立AI服务降低 60%（减少数据传输开销）

扩展部署最佳实践

硬件资源配置：

vector_db:
  cpu: 16 cores (AVX512)
  memory: 64GB 
  storage: NVMe SSD RAID
  gpu: 1×A10（可选）

ml_serving:
  cpu: 8 cores
  memory: 32GB
  network: 10Gbps

版本兼容性矩阵：

扩展	PG 13	PG 14	PG 15	PG 16
pgvector	✓	✓	✓	✓
pgml	✓	✓	✓	Beta
madlib	✓	✓	✓	✓

监控指标：

# 关键性能计数器
pg_stat_ai_queries_total
pg_ml_model_inference_duration_seconds
pg_vector_cache_hit_rate

与传统方案的对比优势

维度	传统AI架构	PostgreSQL AI扩展方案
数据移动	ETL管道，高延迟	库内计算，零数据迁移
事务一致	最终一致性	ACID保证
开发成本	多系统集成，高维护成本	单一技术栈
实时性	批处理为主	亚秒级实时推理
安全合规	多系统暴露面大	统一权限控制

某电商平台采用 PostgreSQL AI 扩展后，推荐系统更新频率从小时级提升到秒级，CTR（点击率）提升 22%，同时基础设施成本降低 40%。

通过深度集成AI能力，PostgreSQL 正在演变为 智能化数据计算平台，建议在以下场景优先考虑：

需要实时更新的推荐系统
隐私敏感的本地化AI推理
事务型AI应用（如实时反欺诈）

存储引擎扩展

扩展名称	存储架构	性能表现	适用场景
zheap	堆表引擎优化	减少 70% 表膨胀	高频更新系统
cstore_fdw	列式存储	压缩率 5x，扫描速度提升 10x	分析型工作负载
roaringbitmap	位图索引	支持 10 亿级用户分群	用户画像系统
pg_rational	分数类型存储	精确避免浮点误差	金融计费系统
pgmemcache	内存表引擎	亚毫秒级响应	实时竞价系统

PostgreSQL 的存储引擎扩展体系突破了传统关系型数据库的存储限制，通过模块化架构实现存储层的灵活扩展。

存储引擎扩展架构

PostgreSQL 通过 Table Access Method API 和 TOAST 机制 实现存储引擎的可扩展性：

核心存储引擎扩展

zheap（事务优化引擎）

技术特性：

替代传统 Heap 表的事务管理
使用 UNDO 日志替代多版本存储
减少 70% 的表膨胀

性能测试：

场景	Heap表写入TPS	zheap写入TPS
高频UPDATE	12,000	38,000
批量DELETE	8,500	24,000

适用场景：

频繁更新的订单状态表
实时竞价系统

cstore_fdw（列式存储）

技术实现：

列式数据压缩（ORC格式）
向量化执行引擎
支持 Parquet 外部表

压缩效率：

-- 创建列式表
CREATE FOREIGN TABLE sales (
    id integer,
    date date,
    amount numeric
) SERVER cstore_server;

-- 压缩比对比
SELECT pg_size_pretty(pg_total_relation_size('sales_heap')) AS heap_size,
       pg_size_pretty(pg_total_relation_size('sales_cstore')) AS cstore_size;

数据量	HEAP大小	cstore大小	压缩率
1TB	1.2TB	230GB	5.2x

适用场景：

数据仓库聚合查询
时序数据分析

pgmemcache（内存引擎）

架构设计：

性能指标：

操作	磁盘表延迟	内存表延迟
随机读取	2.3ms	0.12ms
批量写入	1200 TPS	8500 TPS

使用示例：

CREATE TABLE session_cache (
    key TEXT PRIMARY KEY,
    val BYTEA
) USING pgmemcache;

roaringbitmap（位图引擎）

技术优势：

压缩位图存储（比传统BITMAP小10x）
支持快速集合运算（AND/OR/XOR）

用户分群案例：

-- 创建位图表
CREATE TABLE user_tags (
    tag_id int PRIMARY KEY,
    users roaringbitmap
);

-- 查找同时满足标签A和B的用户
SELECT rb_cardinality(rb_and(a.users, b.users))
FROM user_tags a, user_tags b
WHERE a.tag_id = 1 AND b.tag_id = 2;

存储效率：

用户量	传统位图	roaringbitmap
100万	125KB	8KB
1亿	12MB	1.2MB

存储引擎对比矩阵

引擎类型	写性能	读性能	压缩率	事务支持	适用负载
Heap	★★★★☆	★★★☆☆	1x	ACID	OLTP
zheap	★★★★★	★★★★☆	0.3x	ACID	高频更新
cstore	★★☆☆☆	★★★★★	5x	无	OLAP
pgmemcache	★★★★★	★★★★★	无	部分	实时缓存
roaringbitmap	★★★★☆	★★★★★	10x	无	用户分群

企业级应用方案

金融交易系统存储架构

核心交易表:

引擎: zheap
特性: 高频UPDATE/DELETE抗膨胀
配置: undo_log_segment_size=1GB

历史数据分析:

引擎: cstore_fdw
特性: 列式压缩存储
配置: compression=zstd

实时风控缓存:

引擎: pgmemcache
特性: 亚毫秒级响应
配置: max_size=64GB

用户画像存储:

引擎: roaringbitmap
特性: 快速集合运算
配置: rb_threshold=1000000

性能收益：

交易处理吞吐量提升2x
风控决策延迟降低至8ms
存储成本减少 60%

扩展管理实践

多引擎混合部署

-- 跨引擎查询示例
SELECT o.order_id, c.amount 
FROM orders_heap o 
JOIN order_cache_pgmemcache c ON o.id = c.order_id;

生命周期管理

-- 数据分层自动化
CREATE TABLE logs (
    ...
) PARTITION BY RANGE (log_time) 
PARTITION logs_2023 USING cstore_fdw,
PARTITION logs_current USING heap;

监控指标

# 关键监控项
pg_stat_user_tables_n_dead_tup   # zheap表膨胀监控
cstore_total_blocks               # 列式存储块使用
pgmemcache_hit_rate               # 内存表命中率

未来演进方向

多模事务引擎

跨存储引擎的 ACID 事务支持（如内存表与列式表的事务一致性）

硬件加速集成

GPU 加速列式扫描
持久化内存（PMEM）优化引擎

智能存储决策

-- AI驱动的存储选择建议
SELECT pg_ai_advise_storage('orders', access_pattern='update_heavy');
-- 建议输出: zheap

PostgreSQL 的存储引擎扩展体系正在重塑数据库技术栈，使单一数据库能够同时承载交易、分析、缓存等多种负载。建议根据访问模式设计混合存储方案，并通过 pg_stat_statements 持续监控各引擎的效能表现。

监控诊断扩展

扩展名称	监控维度	数据粒度	存储方式	采样精度
pg_stat_statements	SQL执行统计	语句级	内存+持久化	100%
pg_qualstats	谓词条件分析	列值分布	内存	0.1%采样
pg_wait_sampling	等待事件	进程级	内存	100Hz采样
pg_stat_monitor	全链路追踪	事务级	共享内存	全量
pg_activity	实时会话	连接级	实时查询	秒级刷新

SQL级监控 – pg_stat_statements

核心功能

-- 查看TOP 10 慢查询
SELECT queryid, total_time, calls, mean_time,
       rows, query 
FROM pg_stat_statements 
ORDER BY total_time DESC 
LIMIT 10;

关键指标：

shared_blks_hit/shared_blks_read：缓存命中率
wal_bytes：写入负载
temp_blks_written：临时数据量

性能优化案例

某电商平台通过分析 pg_stat_statements 发现：

高频调用但低效的购物车查询（平均 120ms → 优化至 15ms）
缺失索引的订单搜索（添加复合索引后 QPS 提升 5x）

等待事件分析 – pg_wait_sampling

等待事件分类

瓶颈诊断流程

-- 查看当前等待事件
SELECT pg_stat_get_activity(pid)->wait_event_type,
       pg_stat_get_activity(pid)->wait_event
FROM pg_stat_activity 
WHERE state = 'active';

-- 历史分析
SELECT event_type, event, sum(samples)
FROM pg_wait_sampling_history
GROUP BY 1,2 
ORDER BY 3 DESC;

优化建议：

IO-DataFileRead过高 → 增加 shared_buffers 或使用 SSD
LWLock竞争 → 优化热点表索引

全链路追踪 – pg_stat_monitor

架构设计

关键特性

事务溯源：跟踪单个事务内的多语句执行
执行计划存储：保留最近100个查询计划
错误上下文：记录错误发生的具体SQL和参数

配置示例：

# postgresql.conf
pg_stat_monitor.pgsm_enable = on
pg_stat_monitor.pgsm_max_buckets = 10
pg_stat_monitor.pgsm_track_utility = on

存储健康诊断 – pg_checksums

数据完整性验证

# 启用校验和
initdb --data-checksums

# 离线验证
pg_checksums -c /var/lib/pgsql/15/data

# 输出示例
WARNING:  checksum verification failed in block 42 of relation base/16384/16895
Checksum scan completed
Data checksum version: 1
Files scanned:   892
Blocks scanned:  123456
Bad checksums:  1

修复策略

从备份恢复损坏数据页
使用pg_rewind 同步副本
启用 ZFS/Btrfs 文件系统自带校验

日志分析扩展 – pgBadger

报告生成

pgbadger /var/log/postgresql/postgresql-15-*.log -o report.html

# 关键分析维度：
# - 每小时请求量波动
# - 慢查询TOP 50
# - 错误类型分布
# - 连接池利用率

自动化监控

# 每日报告生成
0 3 * * * /usr/bin/pgbadger -q /var/log/postgresql/postgresql-15-*.log -O /reports

# 异常检测脚本
ALERT_SLOW=1000  # 超过1秒的查询
grep 'duration: [0-9]\{4\}\.' postgresql.log | mail -s "慢查询警报" dba@example.com

监控体系集成方案

Prometheus + Grafana 监控栈

exporter:
  - pg_exporter: 采集基础指标
  - pg_stat_monitor_exporter: 事务级指标
dashboard:
  - 关键指标:
    * 查询吞吐量: sum(rate(pg_stat_statements_calls[5m])) 
    * 缓存命中率: pg_stat_database_blks_hit / (pg_stat_database_blks_hit + pg_stat_database_blks_read)
    * 连接池利用率: pg_stat_activity_count{state="active"} / max_connections
alert:
  - 规则示例:
    - alert: HighCPUWait
      expr: rate(pg_wait_sampling_samples_total{event="CPU"}[5m]) < 0.1
      for: 10m

企业级监控架构

诊断优化最佳实践

三级诊断流程：

自动化优化建议：

-- 使用hypopg创建虚拟索引
SELECT * FROM hypopg_create_index('CREATE INDEX ON orders (user_id)');

-- 验证索引效果
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123;

-- 正式创建
CREATE INDEX CONCURRENTLY orders_user_id_idx ON orders(user_id);

容量规划公式：

所需内存 = shared_buffers + (work_mem * max_connections) +

(maintenance_work_mem * 并行维护任务数) +

temp_buffers

建议比例: shared_buffers = 25% 总内存

通过组合使用监控诊断扩展，某金融系统实现了：

故障平均恢复时间（MTTR）从 4 小时降至 15 分钟
查询性能瓶颈定位效率提升 6 倍
存储异常检测准确率达到9%

建议每周生成《数据库健康报告》，包含关键指标趋势、TOP 资源消耗语句、容量预测等内容，并结合 pg_qualstats 和 pg_wait_sampling 进行预防性优化。

PostgreSQL的FDW

PostgreSQL 的外部数据包装器（Foreign Data Wrapper, FDW）是一项强大的功能，允许用户将外部数据源（如其他数据库、文件或 API）集成到本地数据库中，实现跨数据源的联邦查询。

PostgreSQL 的 FDW 打破了数据孤岛，使其成为数据联邦的核心枢纽。通过合理使用查询下推、物化缓存和并行处理，可有效提升跨数据源查询效率。企业实践中，FDW 常用于混合云数据集成、实时分析平台构建及遗留系统迁移等场景。建议结合 EXPLAIN 分析执行计划，持续优化外部查询性能。

FDW 核心架构

SQL/MED 标准实现

FDW 基于 SQL 管理外部数据（SQL/MED）标准，通过以下组件实现数据联邦：

Foreign Server：定义外部数据源的连接信息（如 IP、端口）。
User Mapping：配置访问外部数据源的认证信息。
Foreign Table：映射外部数据的元数据（表结构）。
Wrapper 扩展：实现与特定数据源的通信协议。

执行流程

常用 FDW 扩展

扩展名称	数据源类型	关键特性
postgres_fdw	PostgreSQL	支持查询下推、JOIN 优化
mysql_fdw	MySQL	兼容 5.6+，支持批量插入
file_fdw	CSV/文本文件	无依赖，轻量级文件访问
mongo_fdw	MongoDB	支持 BSON 到 JSONB 转换
clickhousedb_fdw	ClickHouse	列式存储优化，高性能分析
multicorn	Python 扩展	可自定义包装器（如 REST API 访问）

FDW 使用详解

安装与配置

以 postgres_fdw（连接其他 PostgreSQL 实例）为例：

-- 启用扩展
CREATE EXTENSION postgres_fdw;

-- 定义外部服务器
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host '192.168.1.100', port '5432', dbname 'remote_db');

-- 创建用户映射
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'remote_user', password 'secret');

-- 创建外部表
CREATE FOREIGN TABLE remote_orders (
    order_id INT,
    product TEXT,
    amount NUMERIC
) SERVER foreign_server
OPTIONS (schema_name 'public', table_name 'orders');

查询外部数据

-- 直接查询
SELECT * FROM remote_orders WHERE amount > 1000;

-- 联邦查询（跨本地与外部表）
SELECT l.customer_name, r.product 
FROM local_customers l
JOIN remote_orders r ON l.id = r.customer_id;

监控与管理

系统视图

-- 查看外部表信息
SELECT * FROM pg_foreign_table;

-- 监控外部查询
SELECT * FROM pg_stat_user_tables 
WHERE schemaname = 'public' 
AND relname LIKE 'foreign_%';

日志分析

# postgresql.conf
log_statement = 'ddl'
log_foreign_server = on

性能优化策略

减少数据传输

投影下推：仅 SELECT 必要字段。
谓词下推：确保 WHERE 条件在远程执行。
聚合下推：使用远程聚合减少数据量。

缓存策略

物化视图：定期刷新外部数据快照。

CREATE MATERIALIZED VIEW cached_orders AS 
SELECT * FROM remote_orders;
REFRESH MATERIALIZED VIEW CONCURRENTLY cached_orders;

连接池：使用pgbouncer 管理外部连接。

并行查询

-- 启用并行扫描
ALTER FOREIGN TABLE remote_orders
OPTIONS (ADD parallel_workers '4');

-- 设置并行度
SET max_parallel_workers_per_gather = 4;

FDW 核心特性

查询下推（Pushdown）

条件过滤：将 WHERE 子句发送至远程执行。
聚合操作：远程执行 COUNT、SUM 等聚合。
排序分页：ORDER BY 和 LIMIT 下推。

示例（查看下推效果）：

EXPLAIN VERBOSE 
SELECT * FROM remote_orders 
WHERE amount > 1000 
ORDER BY order_date 
LIMIT 10;
-- 输出中显示 remote SQL: SELECT ... WHERE (amount > 1000) ORDER BY order_date LIMIT 10

事务支持

默认行为：多数 FDW 不支持分布式事务（如postgres_fdw 支持单语句事务）。
跨库事务：需外部数据源支持两阶段提交。

数据类型映射

自动转换：匹配同名数据类型（如 INTEGER、TEXT）。
手动映射：通过ALTER FOREIGN TABLE 调整类型。

FDW 的限制与应对

限制项	应对策略
事务支持有限	使用最终一致性设计，避免跨库事务
复杂查询性能低	下推优化 + 本地物化缓存
数据类型不兼容	自定义类型转换函数
连接稳定性	超时重试机制 + 连接池

FDW 使用案例

跨国零售集团实时库存联邦查询

技术架构：

实现方案：

创建跨区域商品视图：

CREATE VIEW global_inventory AS
SELECT 'asia' region, * FROM asia_items
UNION ALL 
SELECT 'europe', * FROM europe_items
UNION ALL
SELECT 'america', * FROM oracle_items;
实时库存调配查询：
SELECT sku, sum(stock) 
FROM global_inventory 
WHERE warehouse IN ('hk','london','nyc')
GROUP BY sku
HAVING sum(stock) < 100;

效果：

查询响应时间：从 ETL 小时级 → 实时2s
库存周转率提升 23%

金融风控系统多源数据关联

数据整合：

数据源	FDW 类型	数据量	更新频率
客户基本信息	Oracle FDW	5000万	实时
交易记录	Kafka FDW	1亿/日	流式
外部征信数据	REST FDW	API调用	按需

风控规则示例：

SELECT 
    o.customer_id,
    COUNT(t.*) FILTER (WHERE t.amount > 100000) AS big_txns,
    r.credit_score
FROM oracle_customers o
JOIN kafka_transactions t USING (customer_id)
JOIN rest_credit_report r USING (ssn)
WHERE o.country = 'US' 
  AND t.tx_time > NOW() - INTERVAL '7 days'
GROUP BY 1,3
HAVING COUNT(t.*) > 5 OR r.credit_score < 600;

成果：

欺诈检测准确率提升 18%
每秒处理 8500 条实时交易

物联网平台多协议数据汇聚

架构实现：

# 使用 Multicorn 自定义 FDW
class IoTFDW(ForeignDataWrapper):
    def execute(self, quals, columns):
        # 同时从 MQTT、CoAP、LoRaWAN 获取数据
        yield from mqtt_client.query(quals)
        yield from coap_server.fetch(columns)
        yield from lora_gateway.scan()

设备数据查询：

-- 查询温度异常的工业设备
SELECT device_id, MAX(temp) 
FROM iot_sensors 
WHERE protocol = 'lora' 
  AND ts BETWEEN '2023-08-01' AND '2023-08-07'
GROUP BY device_id
HAVING MAX(temp) > 90;

性能指标：

支持 120 万台设备并发接入
数据延迟 < 800ms (P95)

媒体内容推荐系统

数据源整合：

用户画像：MongoDB → 通过mongo_fdw 映射
行为日志：ClickHouse → clickhousedb_fdw
内容元数据：本地 PostgreSQL 表

混合推荐算法：

WITH user_embedding AS (
    SELECT vector 
    FROM mongo_profiles 
    WHERE user_id = 123
),
content_features AS (
    SELECT id, title_embedding 
    FROM local_contents
)
SELECT 
    c.id,
    c.title,
    (c.title_embedding <-> u.vector) AS similarity
FROM content_features c
CROSS JOIN user_embedding u
ORDER BY 3 ASC
LIMIT 10;

业务提升：

CTR（点击率）提升 34%
推荐计算耗时从 6s → 920ms

航空运营分析平台

多模态数据联邦：

-- 联邦查询示例
SELECT 
    f.flight_no,
    w.wind_speed,
    m.maintenance->'last_check' AS last_maint,
    AVG(passenger_count) OVER (
        PARTITION BY route 
        ORDER BY dep_time 
        ROWS 7 PRECEDING
    ) AS avg_passengers
FROM postgres_fdw_flights f
JOIN s3_fdw_weather w 
  ON f.dep_airport = w.station_id 
 AND f.dep_time BETWEEN w.start AND w.end
JOIN mongo_fdw_maintenance m 
  ON f.aircraft_id = m.aircraft->>'id'
WHERE f.status = 'completed';

数据规模：

实时处理 4000+ 航班/天
关联 10TB 历史气象数据
查询性能：复杂分析2s (vs 原 ETL 方案 25 分钟)

游戏玩家跨服对战系统

技术方案：

每个游戏分区使用独立 PostgreSQL 实例
通过postgres_fdw 建立跨服视图：

CREATE FOREIGN TABLE jp_players (...) SERVER jp_node;
CREATE FOREIGN TABLE na_players (...) SERVER na_node;

-- 全服玩家排行榜
SELECT region, player_id, score 
FROM jp_players 
UNION ALL
SELECT region, player_id, score
FROM na_players
ORDER BY score DESC 
LIMIT 100;

实时跨服匹配：

SELECT 
    a.player_id AS p1,
    b.player_id AS p2,
    ABS(a.skill_level - b.skill_level) AS diff 
FROM global_players a
JOIN global_players b 
  ON a.region <> b.region 
 AND a.game_mode = b.game_mode
WHERE a.status = 'waiting' 
  AND b.status = 'waiting'
ORDER BY diff
LIMIT 100;

成果：

匹配延迟从 6s → 320ms
跨服对战参与率提升 41%

政府政务数据开放平台

安全架构：

行级安全控制：

-- 创建安全视图
CREATE VIEW citizen_data AS
SELECT * FROM fdw_census 
WHERE city = current_setting('user.city');

-- 列级脱敏
CREATE FOREIGN TABLE fdw_tax (
    ssn TEXT,
    income NUMERIC,
    mask_ssn TEXT OPTIONS (mask 'partial(0,4,''XXXX'')')
) SERVER tax_server;

-- 查询示例
SELECT mask_ssn, income 
FROM fdw_tax 
WHERE income > 100000;

成效：

数据开放种类从 15 类 → 127 类
跨部门查询响应速度提升 18 倍

关键成功要素

查询下推优化：通过EXPLAIN VERBOSE 验证 80% 以上条件过滤在源端执行
混合存储策略：热数据缓存（物化视图）+ 冷数据直连
连接池管理：使用pgbouncer 控制外部连接数在 50 以内
类型转换优化：为 JSONB 字段创建 GIN 索引加速查询
安全隔离：为每个 FDW 创建单独角色和权限

性能对比数据

场景	传统ETL方案	FDW联邦查询	提升倍数
跨库JOIN(千万级)	12min	8.5s	85x
实时数据更新	小时级延迟	亚秒级	3600x
开发维护成本	15人月/年	3人月/年	5x

这些案例展现了 FDW 在构建现代数据架构中的核心价值：消除数据孤岛，释放数据流动性，同时保持查询的实时性与一致性。建议在实施时结合 pg_stat_activity 监控外部查询，并通过 pg_statio_user_tables 分析 IO 瓶颈，持续优化联邦查询性能。

参考链接：

相关文章:

在 Mac 用 LM studio 部署本地大模型（DeepSeek/Qwen） + 翻译

Tue, 11 Feb 2025 23:18:29 CST

得益于 Mac 的 CPU 和 GPU 共享内存，以及大的内存带宽，使得使用 macBook 运行本地大模型成为可能，借着最近 DeepSeek 大火的东风，我也尝试在本地构建了一套 AI 翻译的系统。本文将会介绍如何在 Mac 电脑上正确的配置这套系统。设置完成后，你将可以

在 Mac 上免费使用大语言模型进行对话
无需等待服务器响应，提高效率
快速翻译任何文档，截图，网页等

本文以 macBook 为例，理论上 windows 电脑也可以获得同样的效果，仅供参考

本文下载工具在中国大陆可能会遇到网络问题，请自行解决

模型管理工具

所谓模型管理工具，就是可以本地运行管理大模型的工具，并且可以提供服务器功能，这样可以省去一些没有必要的麻烦。此外，模型管理工具还可以提供本地聊天的功能，这样在网络不畅的情况下，也可以使用到最近最火的 DeepSeek。

比较流行的模型管理工具有 Ollama 和 LM Studio. 这两个工具比起来， LM Studio 有一个 GUI 页面，下载模型也更方便，对新手比较友好。所以本文将使用 LM Studio。

安装模型

如何找到合适的模型是一切开始的关键，当下比较流行的开源大模型有 deepseek-r1， Qwen， LLama 等，根据需要选择你喜欢的。作者需要使用到中文 - 英文翻译，所以选择了中文更友好的 deepseek 和 Qwen（千问）。

然后是根据自己 Mac 的配置选择合适的模型大小。 LM Studio 会把当前配置无法下载的模型禁止掉，当然即使可以使用，这和使用的舒服也有一定的区别。

作者的配置是 MacBook Pro M3 Max 36G 内存，测试过程中，32B 大小的 DeepSeek R1 是可以正常使用的，但是运行速度会比较慢，简单对话没有问题，但是翻译场景，尤其是比较大型的 PDF 就很让人着急，再加上 DeepSeek R1 还有大量推理过程，32B 模型的速度就更慢了。当然如果拥有更好配置的机器，尤其是大内存，肯定是越大的模型效果越好，这一点丰俭由人。

关于 DeepSeek R1 还有一点要说，DeepSeek R1 会展示出一个长的思维链，这一点固然很棒，但是在翻译的场景下，思维链其实并不是必须的，甚至是累赘，拖慢翻译速度，相比而言 Qwen 模型在这个场景下就是更好的那个选择，后文会给出一个解决思维链的方案。

总结一下，模型很多，各有利弊。根据自己的需求，配置选择合适的模型即可。我使用了 qwen2.5-7b-instruct-1m 用来翻译（14B 应该也没什么问题）。

可以参考下图进行下载安装。

启动服务

接下来就是加载模型，启动服务，按照下图即可。

一旦加载成功，就可以使用这个大模型了。左边栏最上方一个是对话功能，在这里可以和你加载的大模型对话。

同时还可以复制代码到命令行检查模型是否正常运行以及服务是否正常启动。到这里，大模型相关的配置就结束了，恭喜你，已经获得了一个可以运行在本地，不受服务器影响，快速响应的，专属于你的大模型了。

如果你把这个服务开放在局域网上，乃至公网你，你就可以在其他设备上访问到你的大模型了，这就是另一个故事了。

翻译 - Easydict

本文使用了一个开源的本地翻译工具 Easydict , 当然如果有你发现了其他工具也可以使用。本文仅以此为例。

安装

你可以使用下面两种方式之一安装。

Easydict 最新版本支持系统 macOS 13.0+，如果系统版本为 macOS 11.0+，请使用 2.7.2。

1. 手动下载安装

下载最新版本的 Easydict。

2. Homebrew 安装

Copy

   brew install --cask easydict

配置

安装成功后，点击按钮，选择配置，进入配置页面。
然后点击服务，配置我们自己的服务器地址，这里其实选择 ollama 翻译和自定义 OpenAI 翻译理论上都可以。

输入自己的服务器地址端口和模型名称即可，这些在 LM Studio 页面都能找到。

使用

配置会之后，就可以正常使用了。关于 Easydict 的具体使用方法，请参考对应的官方文档 .

另外要说明的是， EasyDict 也支持其他形式的 API ，也内置了翻译，不需要前面本地大模型那一套，本身也是一个很好用的应用。

翻译 - 沉浸式翻译

沉浸式翻译几乎是 OpenAI 横空出世之后最火的一个浏览器翻译插件了。它也支持使用自定义 API 接口来进行翻译，且同时支持网页翻译和 PDF 翻译，且翻译的展示效果非常优秀。

可以支持一个 pro 会员，这样就无需折腾，开箱即用。如果愿意继续折腾本地大模型，就往后看吧。

这是官网链接

下载完插件之后，进入配置页面，还是一样输入 API 地址和模型名称，就可以使用本地大模型进行沉浸式翻译了。

服务器转发

走到这一步，几乎可是使用了，但是你会遇到一下问题

deepseek R1 的翻译结果会带上思维链，影响翻译体验
沉浸式翻译的 API 格式和 LM Studio 的 API 格式不能无缝对接，所以即使 API 通了，沉浸式翻译也无法显示翻译结果

所以，不得已，我用 Python web.py 写了一个最简单的本地服务器，用来转发请求，并在中间做一些微小的工作，解决上述两个小问题，使得翻译体验更好。这里附上代码，仅供参考。web.py 的默认端口是 8080，也可以按需修改成你需要的

记得要安装 Python 并使用 pip install webpy
这里不再赘述

Copy

   import web
import json
import requests
import re
import time

# 配置URLs路由
urls = (
    '/v1/chat/completions', 'ChatCompletions',
    '/v1/models', 'Models'
)

def add_cors_headers():
    # 添加CORS相关的响应头
    web.header('Access-Control-Allow-Origin', '*')
    web.header('Access-Control-Allow-Credentials', 'true')
    web.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')
    web.header('Access-Control-Allow-Headers', 'Content-Type, Authorization')

def remove_think_tags(text):
    # 移除<think>标签及其内容
    return re.sub(r'<think>.*?</think>', '', text, flags=re.DOTALL)

class ChatCompletions:
    def OPTIONS(self):
        # 处理预检请求
        add_cors_headers()
        return ''
        
    def POST(self):
        web.header('Content-Type', 'application/json')
        add_cors_headers()
        
        try:
            data = json.loads(web.data())
            lm_studio_url = "http://localhost:1234/v1/chat/completions"
            
            # 检查是否为流式请求
            is_stream = data.get('stream', False)
            
            # 转发请求到LM Studio
            response = requests.post(
                lm_studio_url,
                json=data,
                headers={'Content-Type': 'application/json'},
                stream=is_stream  # 设置stream参数
            )
            
            if is_stream:
                # 对于流式请求，先收集完整内容
                full_content = ""
                current_id = None
                
                def generate_stream():
                    nonlocal full_content, current_id
                    
                    for line in response.iter_lines():
                        if line:
                            line = line.decode('utf-8')
                            if line.startswith('data: '):
                                line = line[6:]
                            if line == '[DONE]':
                                # 处理完整内容并发送最后一个块
                                cleaned_content = remove_think_tags(full_content)
                                # 发送清理后的完整内容
                                final_chunk = {
                                    "id": current_id,
                                    "object": "chat.completion.chunk",
                                    "created": int(time.time()),
                                    "model": "local-model",
                                    "choices": [{
                                        "index": 0,
                                        "delta": {
                                            "content": cleaned_content
                                        },
                                        "finish_reason": "stop"
                                    }]
                                }
                                yield f'data: {json.dumps(final_chunk)}\n\n'
                                yield 'data: [DONE]\n\n'
                                continue
                                
                            try:
                                chunk_data = json.loads(line)
                                current_id = chunk_data.get('id', current_id)
                                
                                if 'choices' in chunk_data:
                                    for choice in chunk_data['choices']:
                                        if 'delta' in choice:
                                            if 'content' in choice['delta']:
                                                # 累积内容而不是直接发送
                                                full_content += choice['delta']['content']
                                
                                # 发送空的进度更新
                                progress_chunk = {
                                    "id": current_id,
                                    "object": "chat.completion.chunk",
                                    "created": int(time.time()),
                                    "model": "local-model",
                                    "choices": [{
                                        "index": 0,
                                        "delta": {},
                                        "finish_reason": None
                                    }]
                                }
                                yield f'data: {json.dumps(progress_chunk)}\n\n'
                                
                            except json.JSONDecodeError:
                                continue
                
                web.header('Content-Type', 'text/event-stream')
                web.header('Cache-Control', 'no-cache')
                web.header('Connection', 'keep-alive')
                return generate_stream()

            else:
                # 非流式请求的处理
                response_data = json.loads(response.text)
            
                if 'choices' in response_data:
                    for choice in response_data['choices']:
                        if 'message' in choice and 'content' in choice['message']:
                            choice['message']['content'] = remove_think_tags(
                                choice['message']['content']
                            )
                return json.dumps(response_data)
            
        except Exception as e:
            print(e)
            return json.dumps({
                "error": {
                    "message": str(e),
                    "type": "proxy_error"
                }
            })

class Models:
    def OPTIONS(self):
        # 处理预检请求
        add_cors_headers()
        return ''
        
    def GET(self):
        web.header('Content-Type', 'application/json')
        add_cors_headers()
        # 返回一个模拟的模型列表
        return json.dumps({
            "data": [
                {
                    "id": "local-model",
                    "object": "model",
                    "owned_by": "local"
                }
            ]
        })

if __name__ == "__main__":
    app = web.application(urls, globals())
    app.run()

到这里，一个在 Mac 上运行本地部署的大模型，再加上网页、PDF 文档、文字翻译的工具链就完成了。这其中可以替代的选项还有很多。
模型部署还有 ollama 等，大模型还可以用 Phi、llama 等，转发服务器也可以用其他方案，或者可能还有不用转发的选项可以研究，翻译工具也可以用 Bob 来代替。总而言之，技术选择有很多，本文只是提供一个参考。时间还是要花在更重要的事上，已经有了利器，赶快去善其事吧。

开源实时数据同步工具NiFi

Sat, 09 Nov 2024 21:04:10 CST

Apache NiFi简介

Apache NiFi 是一个强大的数据流管理和自动化工具，旨在简化数据的采集、传输、处理和分发。它特别适合于构建和管理复杂的数据流管道，支持从各种数据源到不同目标系统的数据传输。

Apache NiFi主要功能

Apache NiFi 是一个用于自动化数据流的强大工具，具有广泛的功能集，旨在支持从各种数据源到不同目标的复杂数据流管道。以下是 Apache NiFi 的主要功能：

数据采集与传输：
- 支持从多种数据源采集数据，包括文件系统、数据库、HTTP 服务、消息队列（如 Kafka）、传感器设备等。
- 支持将数据传输到多种目标系统，如 HDFS、数据库、云存储服务、REST API 等。
数据流可视化：
- 提供直观的 Web 用户界面，用户可以通过拖拽和配置处理器来设计和管理数据流。
- 实时显示数据流的状态和性能指标，便于监控和调试。
数据处理与转换：
- 提供丰富的内置处理器，支持数据的解析、转换、清洗、聚合和格式化等操作。
- 支持复杂的数据处理逻辑，如条件路由、数据分片、合并和拆分。
动态路由与优先级控制：
- 支持根据数据内容或属性动态路由数据到不同的处理器或目标。
- 允许为数据流设置优先级，以控制数据处理的顺序和速度。
实时流处理：
- 支持实时数据流处理，能够在数据到达时立即执行处理操作。
- 事件驱动架构，处理器在接收到数据或触发条件时自动执行。
分布式架构与扩展性：
- 支持多节点集群部署，可以水平扩展以处理大规模数据流。
- 集群中的节点通过 Apache ZooKeeper 进行协调和管理。
数据安全与合规：
- 支持数据加密、访问控制和用户身份验证，确保数据的安全性。
- 提供数据审计功能，记录数据流的处理历史和用户操作。
错误处理与重试机制：
- 自动处理数据传输和处理过程中出现的错误，支持重试和故障转移。
- 提供数据回退和恢复功能，确保数据的可靠性和完整性。
可扩展性与集成性：
- 支持自定义处理器和控制器服务的开发，用户可以根据需要扩展 NiFi 的功能。
- 与其他大数据工具和框架（如 Apache Kafka、Hadoop、Spark）紧密集成，支持复杂的数据处理和分析工作流。
监控与管理：
- 提供详细的日志记录和监控功能，帮助用户了解数据流的执行状态和性能指标。
- 支持告警和通知机制，用户可以根据特定条件设置告警，及时响应异常情况。

Apache NiFi 的设计目标是提供一个灵活、高效且易于管理的数据流管理平台，适用于各种数据集成和处理场景。其丰富的功能集使其成为企业数据管道构建和管理的理想选择。

Apache NiFi的优势

灵活性：通过丰富的处理器和自定义开发能力，NiFi 可以适应各种复杂的数据处理需求。
可扩展性：支持多节点集群部署，可以水平扩展以处理大规模数据流。
可视化管理：提供直观的 Web UI，用户可以轻松设计和管理数据流，无需编写复杂的代码。
高可用性：通过故障转移和数据重试机制，确保数据流的高可用性和可靠性。
安全性：支持数据加密、访问控制和审计，确保数据的安全性和隐私保护。

Apache NiFi的架构

Apache NiFi 的架构设计旨在提供一个灵活、高效且可扩展的数据流管理平台。它采用模块化设计，支持分布式部署，能够处理各种规模和复杂度的数据流任务。

核心组件

Web UI（用户界面）：NiFi 提供了一个直观的 Web 用户界面，用于设计、监控和管理数据流。用户可以通过拖拽和配置组件来构建数据流，并实时查看数据流的状态和性能指标。
FlowFile：FlowFile 是 NiFi 中的数据单元，包含数据内容和属性。每个 FlowFile 都有唯一标识符和元数据，支持数据的高效传输和处理。
处理器（Processor）：处理器是执行特定数据处理任务的基本单元。NiFi 提供了丰富的内置处理器，用于数据采集、转换、路由和传输。用户还可以开发自定义处理器以满足特定需求。
连接（Connection）：连接用于在处理器之间传递 FlowFile。连接可以配置为使用不同的队列策略，以控制数据的流动速度和优先级。
流程组（Process Group）：流程组用于组织和管理多个处理器和连接，形成逻辑上的子流程。这有助于复杂数据流的模块化设计和维护。
控制器服务（Controller Service）：控制器服务提供共享的配置和服务，例如数据库连接池、分布式缓存等。它们可以在多个处理器之间复用，提高资源利用率。
报告任务（Reporting Task）：报告任务用于生成和发送 NiFi 系统的运行状态和指标数据，通常用于监控和告警系统。

工作流和数据流

数据采集与处理：
- 数据流从输入处理器开始，输入处理器从外部数据源（如文件系统、HTTP、Kafka）获取数据并生成 FlowFile。
- 中间处理器对 FlowFile 进行处理，包括数据解析、转换、过滤和聚合等操作。
数据路由与分发：
- 根据业务规则和条件，NiFi 可以将 FlowFile 路由到不同的处理器或流程组。
- 输出处理器将处理后的 FlowFile 发送到目标系统（如 HDFS、数据库、云存储）。
实时监控与管理：
- Web UI 提供实时数据流监控功能，用户可以查看处理器的性能指标、队列长度、处理速率等。
- 用户可以动态调整数据流的配置和参数，以优化性能和处理逻辑。

分布式架构

多节点集群：
- NiFi 支持多节点集群部署，可以通过增加节点来扩展处理能力。集群中的每个节点都可以执行数据流任务。
- 集群节点通过 Apache ZooKeeper 进行协调和管理，以确保任务的负载均衡和高可用性。
高可用性与故障转移：
- NiFi 采用主从架构，集群中一个节点为主节点（Primary Node），负责调度任务和管理集群配置。
- 在主节点故障时，集群会自动选举新的主节点，确保数据流的持续性和可靠性。

安全性

用户认证与授权：
- 支持多种认证机制（如 LDAP、Kerberos），确保只有授权用户才能访问和管理 NiFi 系统。
- 提供细粒度的权限控制，用户可以对不同的数据流组件和操作进行授权。
数据加密：
- 支持数据传输加密和存储加密，确保数据在传输和存储过程中的安全性。
审计与日志：
- 提供详细的审计日志记录，记录用户操作和数据流处理历史，便于合规性检查和故障排查。

Apache NiFi 的架构设计使其成为一个灵活、可扩展和安全的数据流管理平台，适用于各种规模和复杂度的数据集成和处理任务。其模块化设计和丰富的功能集使得用户能够高效地构建和管理复杂的数据流管道。

Airflow、Kafka的对比

Apache NiFi、Apache Airflow 和 Apache Kafka 都是现代数据处理和管理生态系统中的重要工具，但它们各自的设计目的和应用场景有所不同。以下是它们的详细对比：

特性	Apache NiFi	Apache Airflow	Apache Kafka
主要用途	实时数据流管理和自动化	工作流调度和管理	消息队列和流处理
架构特点	可视化界面，事件驱动架构	编程接口定义工作流（DAGs），基于调度器和执行器	发布/订阅模型，分布式架构
数据处理	实时数据采集、转换和路由	批处理任务调度，不直接处理数据流	高吞吐量的消息传输，支持实时流处理
扩展性与部署	多节点集群，水平扩展	分布式调度和执行，支持多种执行器	水平扩展，通过分区和副本实现容错
安全性	细粒度权限控制和数据加密	用户认证和授权（RBAC）	SSL 加密、SASL 认证和 ACL 授权
应用场景	实时数据集成、物联网数据采集、日志管理和监控	定时数据处理任务、复杂的 ETL 管道、机器学习工作流	实时数据传输、日志收集和分析、事件驱动架构

对比总结

实时 vs 批处理：
- NiFi：适合实时数据流处理和自动化。
- Airflow：适合批处理任务调度和复杂的工作流管理。
- Kafka：适合高吞吐量的消息传输和实时流处理。
用户界面 vs 编程接口：
- NiFi：提供可视化界面，适合需要快速构建和管理数据流的场景。
- Airflow：提供编程接口，适合需要灵活定义复杂工作流的场景。
- Kafka：主要通过编程接口和命令行工具进行管理和配置。
数据流管理 vs 工作流调度 vs 消息队列：
- NiFi：专注于数据流的管理和处理。
- Airflow：专注于任务调度和工作流管理。
- Kafka：专注于消息队列和流处理。

根据具体的需求和场景，企业可以选择合适的工具或组合使用这些工具来构建复杂的数据处理和管理生态系统。例如，可以使用 NiFi 进行数据采集和预处理，使用 Kafka 进行高吞吐量的消息传输，使用 Airflow 进行批处理任务的调度和管理。

数据湖存储系统Paimon

Wed, 06 Nov 2024 21:53:23 CST

Paimon简介

Apache Paimon 是一个面向大数据生态系统的高性能数据湖存储系统。它最初是由 Flink 社区开发的，旨在为大数据处理提供高效的存储解决方案。

Apache Paimon（以前称为 Flink Table Store）是一个专为流处理和批处理而设计的数据湖存储系统。它解决了现代数据处理中的一些关键问题，以下是一些主要的方面：

统一的批处理和流处理：传统的数据处理系统通常将批处理和流处理分开，导致架构复杂性增加。Apache Paimon 提供了一种统一的存储格式，支持高效的批处理和流处理，简化了数据管道的构建和维护。
高效的数据更新和删除：许多数据湖解决方案在处理更新和删除操作时效率较低。Paimon 通过支持高效的增量更新和删除操作，提升了数据处理的灵活性，适合需要频繁更新的数据场景。
事务一致性：在数据湖中实现事务一致性是一个挑战。Paimon 提供了 ACID 事务支持，确保数据操作的原子性、一致性、隔离性和持久性，增强了数据的可靠性和一致性。
优化的存储格式：Paimon 使用了优化的存储格式，支持列式存储和高效的数据压缩，这不仅提高了查询性能，还降低了存储成本。
与 Apache Flink 的深度集成：Paimon 与 Apache Flink 深度集成，使得在 Flink 上构建实时数据应用变得更加容易。这种集成使得开发者可以利用 Flink 强大的流处理能力，直接在 Paimon 上执行复杂的实时分析任务。
元数据管理：Paimon 提供了强大的元数据管理功能，支持对大规模数据集的高效管理和操作，简化了数据治理和合规性管理。

通过解决这些问题，Apache Paimon 为需要处理大规模数据的企业提供了一种高效、灵活且一致的数据存储和处理解决方案。

设计目标

实时性：Apache Paimon 旨在支持实时数据处理和分析，使得用户可以对不断变化的数据进行快速查询和处理。
高吞吐和低延迟：系统设计考虑了高吞吐量和低延迟的需求，能够处理大规模数据的同时，保持较低的响应时间。
事务支持：支持 ACID 事务，以确保数据的一致性和可靠性，即使在高并发环境下也能保证数据的正确性。
易于集成：Paimon 可以与多种大数据处理框架无缝集成，如 Apache Flink、Apache Spark 等，提供灵活的数据处理能力。

核心特性

数据湖架构：采用数据湖架构，允许用户在存储中保存大规模的结构化和非结构化数据，并对其进行管理和分析。
Schema 演化：支持动态的 Schema 演化，允许在不影响现有数据和查询的情况下进行 Schema 的更改。
高效的存储格式：使用高效的列式存储格式（如 Parquet 或 ORC），以减少存储空间和提高查询性能。
数据版本管理：提供数据版本管理功能，支持时间旅行查询（Time Travel Query），用户可以查询历史数据快照。
高可用性和扩展性：设计为分布式系统，能够在多节点环境中运行，提供高可用性和良好的扩展性。

目前Apache Paimon提供以下核心能力：

基于HDFS或者对象存储构建低成本的轻量级数据湖存储服务。
支持在流模式与批模式下读写大规模数据集。
支持分钟级到秒级数据新鲜度的批查询和OLAP查询。
支持消费与产生增量数据，可作为传统数仓与流式数仓的各级存储。
支持预聚合数据，降低存储成本与下游计算压力。
支持历史版本回溯。
支持高效的数据过滤。
支持表结构变更。

应用场景

实时数据分析：适用于需要对流数据进行实时分析的场景，如金融交易分析、实时用户行为分析等。
大规模数据处理：适合需要处理和存储大规模数据的企业，提供高效的数据存储和查询能力。
数据湖和数据仓库集成：可以作为数据湖的一部分，与传统数据仓库系统集成，为数据分析提供灵活的解决方案。

社区和发展

Apache Paimon 是 Apache 软件基金会下的一个开源项目，受益于活跃的开发者社区和用户群体。其持续的发展和更新，使其不断适应大数据领域的新需求和新挑战。

paimon的生态系统

Apache Paimon 的生态系统设计旨在与现有的大数据处理框架和工具无缝集成，从而提供灵活性和易用性。以下是关于 Paimon 在兼容性和集成方面的一些细节：

兼容性

与 Hadoop 的兼容性：

存储兼容性：Paimon 可以部署在 Hadoop 兼容的存储系统上，比如 HDFS。这使得用户可以利用现有的 Hadoop 基础设施来存储和管理数据。
生态系统工具支持：Paimon 可以与 Hadoop 生态系统中的其他工具（如 Hive）集成，支持在这些工具中查询和处理 Paimon 存储的数据。

与 Spark 的兼容性：

数据源和数据接收器：Paimon 提供了与 Apache Spark 的集成，允许 Spark 任务将数据写入 Paimon 或从 Paimon 读取数据。通过 Spark 的 DataFrame API，用户可以方便地对 Paimon 数据进行复杂的批处理分析。
流处理支持：Paimon 的流数据更新能力可以与 Spark Streaming 集成，实现实时数据处理。

与 Flink 的兼容性：

深度集成：Paimon 与 Apache Flink 的深度集成是其一大特色。Flink 用户可以使用 Paimon 作为流式和批处理作业的存储层，利用 Flink 强大的流处理能力直接对 Paimon 数据进行操作。
统一 API 支持：通过 Flink 的 Table API 和 SQL，用户可以在 Paimon 数据上执行统一的批处理和流处理任务。

集成

与大数据处理框架的集成：

Paimon 提供了与多种大数据处理框架的连接器和 API，使得这些框架可以轻松地将数据读写到 Paimon。开发者可以通过标准的 API 和连接器将 Paimon 纳入现有的数据处理管道。

与数据湖和数据仓库的集成：

Paimon 可以作为数据湖的一部分，与其他数据湖技术（如 Delta Lake 或 Apache Iceberg）共同使用，提供统一的存储和管理能力。
通过与数据仓库系统的集成，Paimon 可以支持更复杂的分析和查询需求。

可扩展的插件体系：

Paimon 支持插件机制，允许用户和开发者根据具体需求扩展其功能。这种灵活性使得 Paimon 能够适应多种应用场景和技术栈。

通过与这些大数据生态系统的兼容性和集成能力，Apache Paimon 提供了一种灵活而强大的解决方案，能够在不改变现有基础设施的情况下提升数据处理能力。

Paimon的核心概念

Apache Paimon 是一种专为流处理和批处理设计的数据湖存储系统，其数据存储设计旨在提供高效的数据读写、更新和删除操作。

数据存储格式

列式存储：

Paimon 采用列式存储格式，类似于 Apache Parquet 或 ORC。这种格式有助于提高查询性能，特别是在需要扫描大量数据但只访问部分列的情况下。
列式存储也支持更高效的数据压缩，从而降低存储成本。

分区和分桶：

数据可以按特定的字段进行分区和分桶。这种方式有助于提高数据的访问速度，因为查询可以更快地定位到相关的数据分区或分桶。
分区和分桶策略可以根据数据访问模式进行配置，以优化性能。

数据更新和删除

增量更新：

Paimon 支持高效的增量更新，这意味着可以在不重写整个数据集的情况下对数据进行更新。这对于需要频繁更新的数据集（如实时数据）非常重要。
通过维护数据的增量变化，Paimon 可以快速地应用更新而不影响整体性能。

删除操作：

支持基于条件的删除操作，允许用户删除符合特定条件的数据。
Paimon 通过维护有效数据的快照来管理删除操作，这样可以在不影响读取性能的情况下安全地删除数据。

事务一致性

ACID 事务：

Paimon 提供了 ACID 事务支持，确保数据操作的原子性、一致性、隔离性和持久性。
事务支持使得用户可以安全地进行并发数据操作，而无需担心数据不一致的问题。

快照机制：

Paimon 使用快照机制来管理数据版本和事务。这种机制允许用户查看和回滚到特定时间点的数据状态。
快照机制也有助于实现数据的时间旅行查询（Time Travel Query），用户可以查询历史数据状态。

元数据管理

元数据存储：

Paimon 的元数据可以存储在多种后端，包括文件系统和数据库。元数据存储用于管理表结构、分区信息和快照等。
高效的元数据管理使得 Paimon 可以在大规模数据集上提供快速的查询和更新。

Schema 演变：

Paimon 支持 Schema 演变，允许用户在不影响现有数据的情况下修改表结构。这种灵活性对于需要不断调整数据模型的应用非常有用。

数据读写性能

高效的读取：

Paimon 的列式存储和分区策略使得读取操作非常高效，特别是在只需访问部分列或特定分区时。
支持向量化查询处理，进一步提高读取性能。

写入优化：

通过批量写入和增量更新机制，Paimon 优化了写入性能，减少了 I/O 开销。
支持流式数据写入，使其适合实时数据处理场景。

索引

索引是提高数据查询性能的有效工具。在 Paimon 中，虽然具体的索引机制可能依赖于底层的存储和计算引擎，但一般支持以下几种常见的索引类型：

主键索引：

主键索引用于快速定位特定的记录。对于需要频繁进行更新和删除操作的表，主键索引是非常有用的。
使用场景：主键索引适用于需要快速检索单条记录的场景，如根据订单 ID 查询订单详情。

二级索引：

二级索引用于加速非主键列的查询。它允许在非主键列上进行高效的查找操作。
使用场景：在频繁按某个非主键字段进行过滤查询时，二级索引可以显著提高性能。

分区索引：

分区本身可以视作一种粗粒度的索引，通过将数据按某个字段分区，可以快速定位到相关的数据块。
使用场景：按时间或地理位置等字段进行查询时，分区索引可以减少扫描的数据量。

缓存机制

缓存机制通过在内存中存储数据的部分或全部，提高数据访问速度，减少对磁盘的 I/O 操作。

查询结果缓存：

查询结果缓存是指将经常访问的查询结果存储在内存中，以便在重复查询时可以直接返回缓存结果，而无需重新计算。
使用场景：适用于经常重复执行相同查询的场景，如报表生成或仪表盘展示。

数据块缓存：

数据块缓存涉及将常用的数据块（如列块或行块）缓存到内存中，以加快读取速度。
使用场景：对于那些访问频率高的数据集，数据块缓存可以显著减少磁盘 I/O。

元数据缓存：

元数据缓存用于存储表结构、分区信息等元数据，以减少查询时的元数据加载时间。
使用场景：在大规模数据环境中，元数据缓存可以加快查询计划的生成。

Paimon的使用

Paimon表的创建

创建 Apache Paimon 表通常需要通过 SQL 语句来完成。Paimon 支持标准的 SQL 语法，可以使用各种计算框架（如 Apache Flink 或 Apache Spark）来执行这些 SQL 语句。

使用 Apache Flink 创建 Paimon 表

步骤：

设置 Flink 环境：确保 Flink 已正确安装并配置好。确保 Flink 可以访问 Paimon 存储路径。
编写 Flink 作业：使用 Flink 的 Table API 或 SQL API 来创建 Paimon 表。

示例代码：

import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;

public class CreatePaimonTable {
    public static void main(String[] args) throws Exception {
        // 设置 Flink 执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        // 创建 Paimon 表
        tableEnv.executeSql(
            "CREATE TABLE paimon_table (" +
            "  id INT, " +
            "  name STRING, " +
            "  age INT, " +
            "  PRIMARY KEY (id) NOT ENFORCED" +
            ") WITH (" +
            "  'connector' = 'paimon'," +
            "  'path' = 'path/to/paimon/table'" +
            ")"
        );

        // 打印表信息
        tableEnv.executeSql("DESCRIBE paimon_table").print();

        // 执行作业
        env.execute("Create Paimon Table");
    }
}

使用 Apache Spark 创建 Paimon 表

步骤：

设置 Spark 环境：确保 Spark 已正确安装并配置好。确保 Spark 可以访问 Paimon 存储路径。
编写 PySpark 脚本：使用 PySpark 的 DataFrame API 或 SQL API 来创建 Paimon 表。

示例代码：

from pyspark.sql import SparkSession

# 创建 SparkSession
spark = SparkSession.builder \
    .appName("Create Paimon Table") \
    .config("spark.jars.packages", "<paimon-connector-package>") \
    .getOrCreate()

# 创建 Paimon 表
spark.sql("""
    CREATE TABLE paimon_table (
        id INT,
        name STRING,
        age INT,
        PRIMARY KEY (id) NOT ENFORCED
    ) USING paimon
    OPTIONS (
        path 'path/to/paimon/table'
    )
""")

# 打印表信息
spark.sql("DESCRIBE paimon_table").show()

# 停止 SparkSession
spark.stop()

注意事项

路径配置：path参数指定了 Paimon 表在文件系统中的存储路径。确保该路径是可写的，并且 Flink 或 Spark 有权限访问。
主键约束：PRIMARY KEY (id) NOT ENFORCED表示定义了一个主键，但不强制执行。Paimon 支持主键约束，但不强制执行可以提高写入性能。
连接器包：如果使用 Spark，确保在SparkSession 配置中指定了 Paimon 连接器包（<paimon-connector-package>）。这个包通常是通过 Maven 仓库提供的，需要查找并替换为实际的包名和版本。
Schema 设计：确保表的 Schema 设计合理，字段类型和名称符合业务需求。

合理的分区

在 Apache Paimon 中，对数据进行分区是一种有效的策略，可以提高查询性能和管理大规模数据集。分区允许将数据划分为更小的部分，使得查询可以更快地定位到相关的数据集，从而减少扫描的数据量。

分区是一种将数据集根据某些字段的值划分为多个逻辑部分的方式。每个分区包含特定字段值范围内的数据。常见的分区字段包括日期、地理位置或其他业务相关字段。

如何设置分区

选择分区字段：

选择合适的分区字段是分区策略的关键。通常选择那些在查询条件中经常使用的字段。
例如，对于时间序列数据，可以选择时间戳或日期字段进行分区。

定义分区策略：

在创建表时定义分区策略。Paimon 支持在表创建时指定分区字段。
例如，在 SQL 中创建一个分区表的语法如下：

CREATE TABLE orders (
    order_id STRING,
    customer_id STRING,
    order_date DATE,
    amount DOUBLE
) PARTITIONED BY (order_date);

在这个例子中，order_date 字段被用作分区字段。

数据写入和管理：

当数据写入 Paimon 时，系统会根据定义的分区策略将数据分配到相应的分区中。
Paimon 自动管理分区的创建和维护，用户不需要手动管理分区文件或目录。

分区的优点

提高查询性能：
- 通过限制查询扫描的分区数量，可以显著提高查询性能。例如，当查询条件包含分区字段时，系统只需扫描相关的分区。
- 这种优化特别适用于大规模数据集。
简化数据管理：
- 分区使得数据管理更加简化。用户可以对单个分区执行操作（如删除或归档），而不影响其他分区的数据。
- 这在数据生命周期管理和存储优化方面非常有用。
支持增量处理：
- 分区策略还可以帮助实现增量数据处理。例如，可以通过处理新的或特定的分区来实现增量更新或批量操作。

分区的注意事项

分区数量：过多的分区可能导致元数据管理开销增加。因此，选择合适的分区粒度非常重要。
动态分区：对于某些场景，动态分区（即基于数据内容自动创建分区）可能是有用的，但也需要小心管理以避免过多的分区。

数据导入Paimon

将数据导入到 Apache Paimon 中，通常需要通过与大数据处理框架（如 Apache Flink 或 Apache Spark）的集成来实现。这是因为 Paimon 本身是一个数据湖存储系统，通常需要借助计算框架来进行数据的读写操作。以下是几种常见的方法：

使用 Apache Flink 导入数据

Apache Flink 是与 Paimon 集成最紧密的流处理框架。你可以通过 Flink 作业将数据导入到 Paimon。

步骤：

设置 Flink 环境：确保 Flink 已正确安装并配置好。
配置 Paimon 表：在 Paimon 中创建一个目标表，定义表的 Schema（字段名称、类型等）。
编写 Flink 作业：编写一个 Flink 作业，使用 Paimon 提供的连接器来读取源数据（例如从 Kafka、文件系统、数据库等），并将其写入 Paimon 表。在 Flink 作业中，指定 Paimon 表的路径和配置。
运行 Flink 作业：提交并运行 Flink 作业，将数据流式写入 Paimon。

使用 Apache Spark 导入数据

Apache Spark 也是一个常用的数据处理框架，可以用于将批处理数据导入到 Paimon。

步骤：

设置 Spark 环境：确保 Spark 已正确安装并配置好。
配置 Paimon 表：在 Paimon 中创建一个目标表。
编写 Spark 作业：使用 Spark 的 DataFrame API 读取源数据。使用 Paimon 的 Spark 连接器，将 DataFrame 写入到 Paimon 表。
运行 Spark 作业：提交并运行 Spark 作业，完成数据导入。

使用命令行工具

如果 Paimon 提供了命令行工具，你也可以直接使用这些工具将数据导入到 Paimon。

步骤：

准备数据文件：准备好需要导入的数据文件，通常是 CSV、JSON 等格式。
使用命令行工具：使用 Paimon 提供的命令行工具，指定数据文件路径和目标表路径，将数据导入。

使用 API

如果需要更高的灵活性或集成到自定义应用程序中，你可以使用 Paimon 的 Java API 或其他语言支持的 API。

步骤：

编写代码：使用 Paimon 提供的 API，编写代码来读取源数据并写入 Paimon 表。
运行程序：编译并运行你的程序，将数据导入到 Paimon。

注意事项

Schema 设计：确保 Paimon 表的 Schema 与源数据的结构匹配。
数据格式：确认源数据格式与 Paimon 支持的格式兼容。
性能优化：根据数据量和集群配置，适当调整作业的并行度和资源分配，以提高导入性能。

MySQL数据同步paimon示例

要将 MySQL 的 binlog 数据导入到 Apache Paimon 中，你可以使用 Apache Flink 作为数据处理引擎，因为 Flink 提供了对 MySQL binlog 的良好支持。

配置 MySQL binlog

启用 binlog：在 MySQL 配置文件中启用 binlog。

[mysqld]
log-bin=mysql-bin
server-id=1
binlog-format=ROW

创建用户：为 Flink 创建一个用户，具有读取 binlog 的权限。

CREATE USER 'flink'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'flink'@'%';
FLUSH PRIVILEGES;

编写 Flink 作业

使用 Flink 的 MySQL CDC（Change Data Capture）连接器来读取 MySQL binlog 数据，并将其写入 Paimon。

Flink 作业示例：

依赖配置：确保在 Flink 项目中添加 MySQL CDC 连接器和 Paimon 连接器的依赖。

作业代码：

import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
import org.apache.flink.table.api.Table;
import org.apache.flink.connector.mysql.cdc.MySQLSource;
import org.apache.flink.connector.mysql.cdc.config.MySQLSourceConfigFactory;
import org.apache.flink.types.Row;

public class MySQLToPaimon {
    public static void main(String[] args) throws Exception {
        // 设置 Flink 执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        // 配置 MySQL Source
        MySQLSourceConfigFactory configFactory = MySQLSourceConfigFactory.newBuilder()
                .hostname("your-mysql-host")
                .port(3306)
                .databaseList("your-database")
                .tableList("your-database.your-table")
                .username("flink")
                .password("password")
                .build();

        MySQLSource<String> mySQLSource = MySQLSource.<String>builder()
                .hostname("your-mysql-host")
                .port(3306)
                .databaseList("your-database")
                .tableList("your-database.your-table")
                .username("flink")
                .password("password")
                .deserializer(new StringDebeziumDeserializationSchema())
                .build();

        // 读取 binlog 数据
        DataStream<String> mySQLStream = env.addSource(mySQLSource);

        // 将数据转换为表
        Table mySQLTable = tableEnv.fromDataStream(mySQLStream);

        // 写入 Paimon
        tableEnv.executeSql(
            "CREATE TABLE paimon_table (...) WITH (...)"
        );

        mySQLTable.executeInsert("paimon_table");

        // 执行作业
        env.execute("MySQL Binlog to Paimon");
    }
}

运行 Flink 作业

编译和打包：将 Flink 作业代码编译并打包成 JAR 文件。
提交作业：使用 Flink 提供的命令行工具或 Web UI 将作业提交到 Flink 集群。

验证数据导入

检查 Paimon 表：在 Paimon 中检查数据是否正确导入。
监控作业：使用 Flink 的监控工具，确保作业正常运行，没有报错。

注意事项

数据格式和 Schema：确保 MySQL 表的 Schema 与 Paimon 表的 Schema 一致。
错误处理：考虑添加错误处理机制，以便在读取 binlog 或写入 Paimon 过程中出现问题时能及时响应。
性能优化：根据数据量和集群配置，调整 Flink 作业的并行度和资源分配，以提高性能。

Paimon数据查询

查询 Apache Paimon 中的数据通常需要借助与之集成的计算框架，如 Apache Flink 或 Apache Spark。这些框架提供了灵活的查询能力，可以对存储在 Paimon 中的数据进行分析和处理。

使用 Apache Flink 查询 Paimon 数据

Flink 提供了流处理和批处理的能力，可以通过 SQL 或 Table API 来查询 Paimon 中的数据。

步骤：

设置 Flink 环境：确保 Flink 已正确安装并配置好，并且可以访问 Paimon 存储。
编写 Flink SQL 查询：使用 Flink 的 Table API 或 SQL API 来查询 Paimon 中的数据。

示例代码：

import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
import org.apache.flink.table.api.Table;

public class PaimonQuery {
    public static void main(String[] args) throws Exception {
        // 设置 Flink 执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        // 注册 Paimon 表
        tableEnv.executeSql(
            "CREATE TABLE paimon_table (" +
            "  id INT, " +
            "  name STRING, " +
            "  age INT" +
            ") WITH (" +
            "  'connector' = 'paimon'," +
            "  'path' = 'path/to/paimon/table'" +
            ")"
        );

        // 执行查询
        Table result = tableEnv.sqlQuery("SELECT * FROM paimon_table WHERE age > 30");

        // 输出查询结果
        tableEnv.toChangelogStream(result).print();

        // 执行作业
        env.execute("Paimon Query");
    }
}

使用 Apache Spark 查询 Paimon 数据

Spark 也可以通过 DataFrame API 或 SQL 来查询 Paimon 中的数据。

步骤：

设置 Spark 环境：确保 Spark 已正确安装并配置好，并且可以访问 Paimon 存储。
编写 Spark SQL 查询：使用 Spark 的 DataFrame API 或 SQL API 来查询 Paimon 中的数据。

示例代码：

import org.apache.spark.sql.SparkSession

object PaimonQuery {
  def main(args: Array[String]): Unit = {
    val spark = SparkSession.builder()
      .appName("Paimon Query")
      .getOrCreate()

    // 读取 Paimon 表
    val paimonDF = spark.read
      .format("paimon")
      .load("path/to/paimon/table")

    // 执行查询
    val result = paimonDF.filter("age > 30")

    // 显示查询结果
    result.show()

    spark.stop()
  }
}

注意事项

Schema 一致性：确保查询中使用的 Schema 与 Paimon 表的 Schema 一致。
性能优化：根据查询的复杂度和数据量，调整 Flink 或 Spark 的资源配置以优化查询性能。
集成配置：在使用 Flink 或 Spark 进行查询时，确保正确配置了与 Paimon 的连接器。

PySpark查询Paimon表示例

要使用 PySpark 查询 Apache Paimon 中的数据，你需要确保 Paimon 和 Spark 环境已正确配置，并且可以通过 Spark SQL 或 DataFrame API 来访问和查询 Paimon 中的数据。以下是一个详细的指南，帮助你在 PySpark 中查询 Paimon 数据：

环境准备

Spark 安装：确保已经安装并配置好 Apache Spark，并且可以使用 PySpark。
Paimon 连接器：确保 Spark 能够访问 Paimon 的数据存储路径，并配置好必要的连接器（如果需要）。

启动 PySpark Shell 或编写 PySpark 脚本

你可以选择在 PySpark Shell 中直接运行命令，或者编写一个独立的 PySpark 脚本。

使用 PySpark Shell

pyspark --packages <paimon-connector-package>

编写 PySpark 脚本

from pyspark.sql import SparkSession

# 创建 SparkSession
spark = SparkSession.builder \
    .appName("Paimon Query") \
    .config("spark.jars.packages", "<paimon-connector-package>") \
    .getOrCreate()

# 读取 Paimon 表
paimon_df = spark.read \
    .format("paimon") \
    .load("path/to/paimon/table")

# 执行查询
result_df = paimon_df.filter(paimon_df.age > 30)

# 显示查询结果
result_df.show()

# 停止 SparkSession
spark.stop()

运行脚本或命令

如果使用的是 PySpark Shell，直接在 Shell 中输入相应的命令。
如果是独立的 PySpark 脚本，使用 Spark 提供的命令行工具运行脚本：spark-submit –packages <paimon-connector-package> your_script.py

注意事项

Paimon 连接器：在启动 PySpark Shell 或运行 PySpark 脚本时，需要指定 Paimon 的连接器包。这个包可能是通过 Maven 仓库提供的，你需要查找并替换 <paimon-connector-package> 为实际的包名和版本。
数据路径：确保 load(“path/to/paimon/table”) 中的路径正确指向 Paimon 中存储数据的实际路径。
Schema 一致性：在编写查询时，确保使用的字段名和类型与 Paimon 表的 Schema 保持一致。
性能优化：根据数据量和查询复杂度，调整 Spark 的资源配置（如执行器数量和内存）以提高查询性能。

Paimon数据版本管理

Apache Paimon 提供了强大的数据版本管理和时间旅行功能，这些功能对于数据分析和管理非常有用，特别是在需要审计、调试或回溯历史数据时。以下是对 Paimon 数据版本控制和时间旅行功能的详细介绍：

数据版本控制

版本化数据存储：

Paimon 采用版本化的数据存储机制，每次对数据的更改（如插入、更新或删除）都会生成一个新的版本。
这些版本通过快照（Snapshot）进行管理，每个快照代表数据在某一时间点的状态。

快照管理：

快照是 Paimon 版本控制的核心。每个快照都有一个唯一的标识符和时间戳，记录了自上一个快照以来的数据变化。
快照可以用于回滚数据到某个历史状态，或用于审计和分析。

增量更新：

通过维护数据的增量变化，Paimon 可以高效地管理版本。只需存储和处理自上一个版本以来的变化，而不必复制整个数据集。

时间旅行功能

时间旅行查询：

时间旅行功能允许用户查询数据在过去某一时间点的状态。通过指定快照 ID 或时间戳，用户可以检索历史数据。
这对于需要调试数据问题、执行回溯分析或验证数据变化的场景非常有用。

SQL 支持：

Paimon 支持通过 SQL 语句执行时间旅行查询。用户可以使用特定的语法指定要查询的快照或时间。

示例查询语法：

SELECT * FROM table_name FOR SYSTEM_TIME AS OF ‘2023-01-01 10:00:00’;

在这个例子中，查询将返回数据在指定时间点的状态。

快照导航：

用户可以列出所有可用的快照，并选择特定的快照进行查询。这种导航能力使得用户可以方便地找到需要的历史版本。

实践中的应用

数据审计：可以使用时间旅行功能查看数据在某个历史时间点的状态，以满足审计和合规性要求。
错误回溯：在发现数据错误时，通过时间旅行功能回溯到错误发生之前的版本，从而帮助定位和修复问题。
变化分析：分析数据在不同时间点的变化趋势，以支持业务决策。

管理和优化

存储优化：虽然版本控制和时间旅行功能提供了极大的便利，但也会增加存储需求。可以通过配置保留策略，定期清理不再需要的历史版本来优化存储。
性能考虑：在执行时间旅行查询时，考虑到数据规模和查询复杂度，以确保查询性能符合要求。

参考链接：

Python地理数据分析工具MovingPandas

Wed, 09 Oct 2024 19:54:20 CST

MovingPandas 是一个用于分析轨迹数据的 Python 库。它在处理和分析移动对象的时空数据方面非常强大，适用于地理信息系统（GIS）、时空数据分析和可视化等领域。它是在热门的地理数据处理库 GeoPandas 的基础上构建的，GeoPandas 本身是建立在Pandas数据处理库之上的。MovingPandas 旨在提供高效、易于使用的工具，以便分析和处理包含位置信息的时间序列数据。MovingPandas使得研究移动模式、路径分析、时空聚类等任务变得更加高效和直观。

核心功能：

轨迹数据表示。MovingPandas 使用 GeoPandas GeoDataFrames 来表示轨迹数据。每条轨迹由一系列带有时间戳的点组成，形成一条时空路径。
轨迹分割。可以根据时间间隔、距离阈值等条件将轨迹分割成多个子轨迹。这对于处理长轨迹或者在某些关键事件发生前后进行分析非常有用。
轨迹特征提取。提供了多种方法来计算轨迹的特征，比如速度、加速度、方向变化等。这些特征在进行模式识别和行为分析时非常有用。
轨迹聚类。支持基于轨迹的聚类分析，可以识别出类似移动模式的轨迹群体。常用的聚类方法包括基于密度的聚类（DBSCAN）、分层聚类等。
轨迹可视化。通过与 Matplotlib 和 Folium 等库的集成，MovingPandas 能够提供强大的轨迹数据可视化功能，包括静态和交互式地图。
时空聚合。支持时空聚合分析，比如计算某个区域在特定时间段内的平均速度、轨迹数量等。

MovingPandas的使用

MovingPandas的安装

MovingPandas作者推荐在Python 3.7及以上环境下安装。请确保你的Python版本符合这一要求。如果你已经安装了Anaconda，可以使用conda命令来安装MovingPandas及其依赖包。

conda install -c conda-forge movingpandas

MovingPandas同样可以使用pip进行安装，但是不推荐，主要原因是其依赖环境较为复杂，使用pip安装可能会出现依赖项缺失或版本冲突的问题。因此，推荐使用conda进行安装。

MovingPandas接口详解

MovingPandas.Trajectory对象

在 MovingPandas 中，Trajectory 类是核心组件之一，主要用于表示和处理单个轨迹。Trajectory 对象是一个时间序列的集合，其中每个数据点代表轨迹上的一个位置，包含了位置信息（经纬度或其他地理空间参考）、时间戳和其他可能的属性（如速度、方向等）。因此，一个 Trajectory 对象是连续移动的点组成的线，这些点按照时间顺序排列。

Trajectory 对象的主要特性：

时间索引：Trajectory 对象的索引通常是时间戳，这使得基于时间的查询和操作变得直观和高效。
空间位置：每个时间点对应一个空间位置，这通常是通过经纬度坐标表示的。
其他属性：除了时间和位置，还可以包含其他相关的数据列，如速度、加速度、方向等，这些信息对于分析移动行为至关重要。

创建 Trajectory 对象通常涉及几个步骤，首先你可能需要有一个包含时空数据的pandas DataFrame。这个DataFrame应该至少包含三列：表示时间戳的列（通常会被设置为索引）、表示X坐标的列（如经度）、表示Y坐标的列（如纬度）。然后，你可以使用 MovingPandas 提供的函数或方法（如TrajectoryCollection.from_geodataframe()）来创建一个或多个 Trajectory 对象。

class movingpandas.Trajectory(df, traj_id, traj_id_col=None, obj_id=None, t=None, x=None, y=None, crs=’epsg:4326′, parent=None)

参数说明：

df：具有GeoPandas的geometry坐标列和时间戳索引的GeoDataFrame，或Pandas的DataFrame。必填参数。
traj_id：任意类型，表示轨迹的唯一标识符。必填参数。
obj_id：任意类型，表示移动物体的唯一标识符。默认为 None。
t：表示包含时间戳的列名，默认为 None。
x：表示包含x坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
y：表示包含y坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
crs：表示 x/y 坐标的坐标参考系统。默认为 “epsg:4326″，即 WGS84。
parent：一个Trajectory 对象，表示父轨迹。默认为 None。

基本信息与操作

copy(): 返回轨迹对象的一个副本。
drop(**kwargs) 方法用于从数据集中删除满足特定条件的行或列。
plot(self, *args, **kwargs): 绘制轨迹。
explore(*args, **kwargs) 方法用于以交互方式可视化和分析数据，支持多种参数和选项以定制显示。
is_latlon() 方法用于判断轨迹数据是否采用经纬度坐标系。
is_valid() 方法用于检查轨迹数据是否有效，例如是否包含必要的字段和合理的坐标。
size() 方法用于返回轨迹中包含的定位点数量。
get_crs() 方法用于获取当前地理数据集的坐标参考系统（CRS），返回一个描述该坐标系的对象或信息。
to_crs(self, crs): 转换轨迹的坐标参考系统。
get_column_names() 方法用于获取数据集中的所有列名，返回一个包含列名的列表。这个方法通常用于快速查看数据集的结构或在进行数据处理时动态获取列名。
get_direction_col() 方法用于获取表示方向数据的列，这些数据通常以角度或方位形式存储。
get_distance_col() 方法用于获取表示距离数据的列，这些数据通常用于计算或分析两点之间的距离。
get_speed_col() 方法用于获取表示对象速度的列名。
get_timedelta_col() 方法用于获取表示时间增量的列名。
get_traj_id_col() 方法用于获取表示轨迹标识符的列名。
get_geom_col() 方法用于获取表示几何数据的列，该列通常包含地理空间信息，如点、线或多边形。
get_angular_difference_col() 方法用于获取包含角度差异的列，这些差异通常用于分析方向或角度变化。
to_point_gdf(self): 返回包含轨迹点的GeoDataFrame。
to_line_gdf(columns=None) 方法用于将轨迹数据转换为 GeoDataFrame 格式的线条几何数据，可以选择包含特定的列。
to_linestring() 方法用于将轨迹数据转换为 LineString 对象，表示轨迹的线条几何形状。
to_linestringm_wkt() 方法用于将轨迹数据转换为包含 ZM（高程和度量）信息的 WKT（Well-Known Text）格式的 LineStringM 字符串。
to_mf_json(datetime_to_str=True, temporal_columns=None) 方法用于将轨迹数据转换为 Moving Features JSON 格式，可以选择将日期时间转换为字符串，并指定时间相关的列。
to_point_gdf(return_orig_tz=False) 方法将轨迹数据转换为 GeoDataFrame 格式的点几何数据，可以选择返回原始时区的时间。
to_traj_gdf(wkt=False, agg=False) 方法将轨迹数据转换为 GeoDataFrame 格式，可以选择生成 WKT 格式的几何数据或进行聚合处理。

轨迹分析与聚合统计

get_bbox(self): 返回轨迹的范围 (bounding box)。
get_start_location(self): 返回轨迹的起始位置。
get_end_location(self): 返回轨迹的结束位置。
get_start_time() 方法用于获取时间序列数据或对象轨迹的起始时间。
get_end_time() 方法用于获取某个事件或过程的结束时间，通常返回一个时间戳或日期时间对象。
get_max(column) 方法用于获取指定列 column 中的最大值。
get_min(column) 方法用于获取指定列 column 中的最小值。
get_position_at(t, method=’interpolated’) 方法用于获取在时间点 t 处的对象位置，默认使用插值方法来计算位置。
get_row_at(t, method=’nearest’) 方法用于获取在时间点 t 附近的对象所在的行，默认使用最近邻方法来选择行。
get_length(units=(None, None, None, None)) 方法用于计算并获取几何对象的长度，可以接受多个单位参数来指定长度的测量单位。
get_mcp() 方法用于获取某个对象的最小凸包 (Minimum Convex Polygon, MCP)，通常用于地理空间分析中确定一组点的最小包围区域。
add_direction(self, overwrite=False): 计算并添加方向信息到轨迹数据中。
get_direction() 方法用于计算和获取两个地理点之间的方向或方位角，通常以度数表示。
get_duration(self): 返回轨迹的总时长。
add_distance(overwrite=False, name=’distance’, units=None)：计算并添加轨迹数据中相邻点之间的距离信息。
add_acceleration(self, overwrite=False, name=’acceleration’): 计算并添加加速度信息到轨迹数据中。
add_speed(self, overwrite=False): 计算并添加速度信息到轨迹数据中。
add_angular_difference(overwrite=False, name=’angular_difference’)：计算并添加轨迹中相邻点之间的角度差异信息到轨迹数据中。
add_timedelta(overwrite=False, name=’timedelta’) ：计算并添加轨迹数据中相邻点之间的时间差信息。
add_traj_id(overwrite=False) 方法用于为轨迹数据添加或覆盖轨迹ID列，以标识相同轨迹中的所有点。
get_segment_between(t1, t2) 方法用于获取在时间点 t1 和 t2 之间的对象轨迹或数据段。
get_linestring_between(t1, t2, method=’interpolated’) 方法用于生成并获取在时间点 t1 和 t2 之间的一条线串，默认使用插值方法。
get_sampling_interval() 方法用于获取时间序列数据中的采样时间间隔。
hausdorff_distance(other, units=(None, None, None, None)) 方法用于计算当前轨迹与另一个轨迹之间的Hausdorff距离，并允许指定单位。
hvplot(*args, **kwargs) 方法用于使用hvPlot库创建高度可定制的图形和可视化。
hvplot_pts(*args, **kwargs) 方法用于使用hvPlot库对地理点数据进行可视化并创建交互式图形。
interpolate_position_at(t) 方法用于在给定时间 t 处插值并返回轨迹的位置。
intersection(feature, point_based=False) 方法用于计算轨迹与给定地理特征的交集，并可以选择基于点的方式进行计算。
intersects(polygon) 方法用于判断轨迹是否与指定的多边形区域相交。
clip(self, polygon): 按多边形裁剪轨迹。
apply_offset_minutes(column, offset) 方法用于将指定列的时间值按给定的分钟数进行偏移调整。
apply_offset_seconds(column, offset) 方法用于将指定列的时间值按给定的秒数进行偏移调整。

MovingPandas.TrajectoryCollection对象

TrajectoryCollection 类是 MovingPandas 中用于表示多条轨迹的集合。它允许用户以集合的形式操作多条轨迹，支持对这些轨迹的批量处理和分析。

可以通过传递一系列 Trajectory 对象来创建一个 TrajectoryCollection。每个 Trajectory 对象代表一条轨迹，包含了时间和位置的信息。

class movingpandas.TrajectoryCollection(data, traj_id_col=None, obj_id_col=None, t=None, x=None, y=None, crs=’epsg:4326′, min_length=0, min_duration=None)

参数说明：

data (list[Trajectory] 或 GeoDataFrame 或 DataFrame) – 包含 Trajectory 对象的列表，或一个包含轨迹 ID、点几何列和时间戳索引的 GeoDataFrame。
traj_id_col (string) – 包含轨迹 ID 的 GeoDataFrame 列名。
obj_id_col (string) – 包含移动对象 ID 的 GeoDataFrame 列名。
t (string) – 包含时间戳的 DataFrame 列名。
x (string) – 包含 x 坐标的 DataFrame 列名。
y (string) – 包含 y 坐标的 DataFrame 列名。
crs (string) – x/y 坐标的坐标参考系 (CRS)。
min_length (numeric) – 期望的轨迹最小长度。长度使用 CRS 单位计算，若 CRS 是地理坐标系（例如 EPSG:4326 WGS84），则长度以米为单位计算。（较短的轨迹将被丢弃。）
min_duration (timedelta) – 期望的轨迹最短持续时间。（较短的轨迹将被丢弃。）

相比MovingPandas.Trajectory多了一些方法：

filter(predicate): 根据给定条件过滤轨迹集合。

MovingPandas.TrajectoryCollectionAggregator对象

MovingPandas.TrajectoryCollectionAggregator 是 MovingPandas 库中的一个类，主要用于对轨迹集合进行聚合操作。通过对轨迹数据进行空间和时间上的聚合，可以帮助用户有效地分析和总结移动模式。

class movingpandas.TrajectoryCollectionAggregator(traj_collection, max_distance, min_distance, min_stop_duration, min_angle=45)

参数说明

traj_collection (TrajectoryCollection) – 要进行聚合的 TrajectoryCollection 对象。
max_distance (float) – 重要点之间的最大距离（距离使用 CRS 单位计算，若 CRS 是地理坐标系，例如 EPSG:4326 WGS84，则距离以米为单位计算）。
min_distance (float) – 重要点之间的最小距离。
min_stop_duration (datetime.timedelta) – 停止检测所需的最短持续时间。
min_angle (float) – 提取重要点的最小角度。

MovingPandas.TrajectoryCleaner对象

MovingPandas.TrajectoryCleaner 是 MovingPandas 库中的一个类，专门用于清理轨迹数据。清理操作可以帮助去除数据中的噪声、填补缺失值以及进行其他预处理步骤，确保轨迹数据的质量和一致性。

IqrCleaner(traj) 是一个类，用于基于四分位数范围 (IQR) 方法来清理轨迹数据中的异常值。
OutlierCleaner(traj) 是一个类，用于通过多种方法识别和清理轨迹数据中的离群点（异常值）。

MovingPandas.TrajectoryGeneralizer对象

MovingPandas.TrajectoryGeneralizer 是 MovingPandas 库中的一个类，用于对轨迹数据进行简化和概括。通过轨迹数据的概括，可以减少数据量，提高处理效率，并且在某些应用场景下有助于更清晰地展示轨迹特征。

TrajectoryGeneralizer(traj) 是一个类，用于通过多种算法对轨迹数据进行简化和概括，以减少数据量并提高处理效率。
DouglasPeuckerGeneralizer(traj) 是一个类，专门使用 Douglas-Peucker 算法对轨迹数据进行简化，保留主要特征点以减少数据量。
MinDistanceGeneralizer(traj) 是一个类，用于根据最小距离间隔对轨迹数据进行简化，移除距离变化小于指定阈值的点。
MinTimeDeltaGeneralizer(traj) 是一个类，用于根据最小时间间隔对轨迹数据进行简化，移除时间间隔小于指定阈值的点。
TopDownTimeRatioGeneralizer(traj) 是一个类，用于通过时间比率算法对轨迹数据进行简化，保留关键时间点以减少数据量。

MovingPandas.TrajectorySmoother对象

MovingPandas.TrajectorySmoother 是一个类，用于对轨迹数据进行平滑处理。轨迹平滑通常是为了减少由于数据采集误差和噪声导致的轨迹抖动和异常点，从而得到更加平滑和准确的轨迹线条。

KalmanSmootherCV(traj) 是一个类，用于使用常速模型（Constant Velocity Model）的卡尔曼滤波算法对轨迹数据进行平滑处理，以减少噪声和抖动。

MovingPandas.TrajectorySplitter对象

MovingPandas.TrajectorySplitter 是一个类，用于将轨迹数据根据特定条件进行分割。这在处理长时间、多段的轨迹数据时特别有用，比如在分析车辆行驶路径、运动员运动轨迹或动物迁徙路径时，可以根据特定的规则将连续的轨迹分割成多个部分，以便进行更细致的分析。

TrajectorySplitter(traj) 是一个类，用于根据指定的条件（如距离、时间或速度）对轨迹数据进行分割，生成多个段以便更细致的分析。
TemporalSplitter(traj) 是一个类，用于根据时间间隔对轨迹数据进行分割，将轨迹分成多个时间段以便更细致的时间序列分析。
ObservationGapSplitter(traj) 是一个类，用于根据观测数据中的时间间隙对轨迹进行分割，当连续观测点之间的时间间隔超过指定阈值时，将轨迹分割成多个部分。
SpeedSplitter(traj) 是一个类，用于根据速度阈值对轨迹数据进行分割，当轨迹点的速度超过指定阈值时，将轨迹分割成多个部分。
StopSplitter(traj) 是一个类，用于根据停留点（长时间停留的点）对轨迹数据进行分割，将轨迹分成移动段和停留段以便更细致的分析。

MovingPandas.TrajectoryStopDetector对象

TrajectoryStopDetector 通过分析轨迹点的时空属性来识别停留点。它会检查一个轨迹对象中的每个点，并根据设定的阈值参数（如最小速度、最小停留时间和最小停留距离等）来鉴定轨迹中是否存在停留段。

class movingpandas.TrajectoryStopDetector(traj, n_threads=1)

方法介绍：

get_stop_points(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹数据中的停留点，并返回包含这些停留点的 GeoDataFrame。
get_stop_segments(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹中的停留段，并返回包含这些停留段的列表。
get_stop_time_ranges(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别停留时间范围，并返回停留时间段的列表。

MovingPandas使用实例

准备工作

加载需要的库

import pandas as pd
import geopandas as gpd
import movingpandas as mpd
from datetime import datetime, timedelta
import matplotlib.pyplot as plt
import folium
import bokeh.io
bokeh.io.output_notebook()
from holoviews import opts
opts.defaults(opts.Overlay(active_tools=["wheel_zoom"], frame_width=500, frame_height=400))

加载数据

df = pd.read_excel("driver_log.xlsx")

# 将DataFrame 转换为 GeoDataFrame
gdf = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat), crs='EPSG:4326')

# 将GeoDataFrame转化为TrajectoryCollection对象
tc = mpd.TrajectoryCollection(gdf, traj_id_col='session_id', obj_id_col = 'driver_no', t='log_time')
# 过滤某个司机的轨迹
df['driver_no'].value_counts()
df['driver_no'].value_counts().plot(kind='bar', figsize=(15,3))
driver_tc = tc.filter('driver_no', 'DR202407021504081000000')

# 展示司机轨迹
driver_tc.plot()

# 获取单个轨迹
my_traj = driver_tc.trajectories[0]

# 展示单个轨迹
traj_plot = my_traj.hvplot(title="Trajectory {}".format(my_traj.id),line_width=7.0, tiles="CartoLight", color="slategray")
traj_plot

停留点检测

针对单轨迹停留点检测

detector = mpd.TrajectoryStopDetector(my_traj)
## 检测停留的时间（这里检测5分钟位移100米以内）
stop_time_ranges = detector.get_stop_time_ranges(min_duration=timedelta(seconds=300), max_diameter=100)
## 检测停留的时间
for stop_time in stop_time_ranges:
    print(stop_time)
## 检测停留点
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 展示停留点
stop_point_plot = traj_plot * stop_points.hvplot(geo=True, size="duration_s", color="deeppink")
stop_point_plot

## 停留点信息
stop_points_gdf = gpd.GeoDataFrame(stop_points, geometry="geometry", crs="EPSG:4326")
stop_points_gdf
## 使用folium展示停留点
# m = my_traj.explore(color="blue",style_kwds={"weight": 4},name="Trajectory")
# stop_points_gdf.explore(m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["duration_s"] / 10 }},name="Stop points")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m
## 停留轨迹
stop_segments = detector.get_stop_segments(min_duration=timedelta(seconds=60), max_diameter=100)
stop_segments.to_traj_gdf()
## 停留轨迹
stop_segment_plot = stop_point_plot * stop_segments.hvplot(line_width=7.0, tiles=None, color="orange")
stop_segment_plot

## 使用folium绘图
# m = my_traj.explore(
#     color="blue",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectory",
# )

# stop_segments.explore(
#     m=m,
#     color="orange",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Stop segments",
# )

# stop_points_gdf.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 3},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

## 行驶线路
split = mpd.StopSplitter(my_traj).split(min_duration=timedelta(seconds=300), max_diameter=100)
split.to_traj_gdf()
## 可视化行驶线路
split.explore(column="session_id", tiles="CartoDB positron", style_kwds={"weight": 4})

## 整体可视化
stop_segment_plot + split.hvplot(title="Trajectory {} split at stops".format(my_traj.id),line_width=7.0,tiles="CartoLight")

轨迹合集的经停点检测

## 停留点检测
detector = mpd.TrajectoryStopDetector(driver_tc)
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 停留点可视化
ax = driver_tc.plot(figsize=(7, 7))
stop_points.plot(ax=ax, color="red")

## 使用folium可视化
## 使用方folium可视化
# m = driver_tc.explore(
#     column="session_id",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectories",
# )

# stop_points.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 5},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

速度计算

## 单轨迹增加速度
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.df.head()

## 展示速度
my_traj.plot(column="speed", linewidth=5, capstyle='round', legend=True)
# my_traj.hvplot(c='speed', clim=(0,20), line_width=7.0, tiles='CartoLight', cmap='Viridis', colorbar=True)

## 添加方向
my_traj.add_direction(overwrite=True)
my_traj.df.head()

## 添加时差
my_traj.add_timedelta(overwrite=True)
my_traj.df.head()

## 添加距离
my_traj.add_distance(overwrite=True, name="distance (km)", units="m")
my_traj.df.head()

## 添加加速度
my_traj.add_acceleration(overwrite=True, name="acceleration (mph/s)", units=("mi", "h", "s"))
my_traj.df.head()

## 轨迹集增加速度
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.plot(column='speed', linewidth=5, capstyle='round', legend=True, vmax=20)

提取位置

## 获取起点与终点
ax = my_traj.plot()
gpd.GeoSeries(my_traj.get_start_location()).plot(ax=ax, color='blue')
gpd.GeoSeries(my_traj.get_end_location()).plot(ax=ax, color='red')

## 获取特定时间点的位置
t = datetime(2024,7,3,9,30,0)
print(my_traj.get_position_at(t, method="nearest"))
print(my_traj.get_position_at(t, method="interpolated"))
print(my_traj.get_position_at(t, method="ffill")) # from the previous row
print(my_traj.get_position_at(t, method="bfill")) # from the following row

point = my_traj.get_position_at(t, method="interpolated")
ax = my_traj.plot()
gpd.GeoSeries(point).plot(ax=ax, color='red', markersize=100)

## 获取特定时间区间的位置
segment = my_traj.get_segment_between(datetime(2024,7,3,9,10,0), datetime(2024,7,3,9,30,0))
print(segment)
ax = my_traj.plot()
segment.plot(ax=ax, color='red', linewidth=5)

## 获取特定区域内的轨迹
from shapely.geometry import Polygon

xmin, xmax, ymin, ymax = 104.135, 104.137, 30.642, 30.643
polygon = Polygon([(xmin, ymin), (xmin, ymax), (xmax, ymax), (xmax, ymin), (xmin, ymin)])
intersections = my_traj.clip(polygon)
ax = my_traj.plot()
gpd.GeoSeries(polygon).plot(ax=ax, color='lightgray')
intersections.plot(ax=ax, color='red', linewidth=5, capstyle='round')

导出轨迹

## 返回 GeoDataFrame
driver_tc.to_point_gdf()
driver_tc.to_line_gdf()
driver_tc.to_traj_gdf(wkt=True) # 生成wkt格式的聚合

# 聚合数据
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})

# 导出数据
export_gdf = driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})
export_gdf.to_file("temp.gpkg", layer='trajectories', driver="GPKG")
gpd.read_file('temp.gpkg').plot()

轨迹分割

## 数据准备
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, linewidth=5, capstyle='round', figsize=(9,3), legend=True )

## 根据观测数据中的时间间隙对轨迹进行分割
split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据停留点（长时间停留的点）对轨迹数据进行分割
split = mpd.StopSplitter(my_traj).split(max_diameter=10, min_duration=timedelta(minutes=1), min_length=20)
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据速度阈值对轨迹数据进行分割
split = mpd.SpeedSplitter(my_traj).split(speed=0, duration=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

轨迹抽稀

## 展示原始轨迹
plot_defaults = {'linewidth':5, 'capstyle':'round', 'figsize':(9,3), 'legend':True}
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, **plot_defaults)

## 使用 Douglas-Peucker 算法对轨迹数据进行简化
dp_generalized  = mpd.DouglasPeuckerGeneralizer(my_traj).generalize(tolerance=0.0001)
dp_generalized.plot(column='speed', vmax=20, **plot_defaults)

print('Original length: %s'%(my_traj.get_length()))
print('Generalized length: %s'%(dp_generalized.get_length()))

## 根据最小时间间隔对轨迹数据进行简化
time_generalized = mpd.MinTimeDeltaGeneralizer(my_traj).generalize(tolerance=timedelta(minutes=3))
time_generalized.plot(column='speed', vmax=20, **plot_defaults)

## 通过时间比率算法对轨迹数据进行简化
tdtr_generalized = mpd.TopDownTimeRatioGeneralizer(my_traj).generalize(tolerance=0.001)
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
dp_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
time_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

平滑轨迹

split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
smooth = mpd.KalmanSmootherCV(split).smooth(process_noise_std=0.1, measurement_noise_std=10)
hvplot_defaults = {'tiles':'CartoLight', 'frame_height':320, 'frame_width':320, 'cmap':'Viridis', 'colorbar':True}
kwargs = {**hvplot_defaults, 'line_width':4}
(split.hvplot(title='Original Trajectories', **kwargs) +  smooth.hvplot(title='Smooth Trajectories', **kwargs))

kwargs = {**hvplot_defaults, 'c':'speed', 'line_width':7, 'clim':(0,20)}
(split.trajectories[1].hvplot(title='Original Trajectory', **kwargs) + smooth.trajectories[1].hvplot(title='Smooth Trajectory', **kwargs))

traj = split.trajectories[1]

cleaned = traj.copy()
cleaned = mpd.OutlierCleaner(cleaned).clean(alpha=2)

smoothed = mpd.KalmanSmootherCV(cleaned).smooth(process_noise_std=0.1, measurement_noise_std=10)
    
(traj.hvplot(title='Original Trajectory', **kwargs) + 
 cleaned.hvplot(title='Cleaned Trajectory', **kwargs) + 
 smoothed.hvplot(title='Cleaned & Smoothed Trajectory', **kwargs))

轨迹聚类和分类

## 查看数据
driver_tc.explore(column="session_id", cmap="plasma", style_kwds={"weight": 4})
## 根据最小距离间隔对轨迹数据进行简化
generalized = mpd.MinDistanceGeneralizer(driver_tc).generalize(tolerance=100)
generalized.to_traj_gdf()

## 对轨迹进行聚合操作
aggregator = mpd.TrajectoryCollectionAggregator(
    generalized,
    max_distance=1000,
    min_distance=100,
    min_stop_duration=timedelta(minutes=10),
)

## 提取显著点
pts = aggregator.get_significant_points_gdf()
pts.hvplot(geo=True, tiles="OSM")

## 获取聚合轨迹的簇
clusters = aggregator.get_clusters_gdf()
(pts.hvplot(geo=True, tiles="OSM") * clusters.hvplot(geo=True, color="red"))

## 使用folium绘制
# m = pts.explore(marker_kwds={"radius": 3}, name="Significant points")
# clusters.explore(m=m, color="red", marker_kwds={"radius": 3}, name="Cluster centroids")
# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)
# m

## 获取聚合后的轨迹数据的流动
flows = aggregator.get_flows_gdf()
(flows.hvplot(geo=True, hover_cols=["weight"], line_width=dim("weight") * 7, color="#1f77b3",tiles="CartoLight") * clusters.hvplot(geo=True, color="red", size=dim("n")))

## 使用Folium绘制
# m = flows.explore(style_kwds={"weight": 5},name="Flows")
# clusters.explore( m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["n"]}}, name="Clusters")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m

距离计算

## 选择2个轨迹
my_traj = driver_tc.trajectories[3]
toy_traj = driver_tc.trajectories[1]
## 呈现数据
ax = my_traj.plot()
toy_traj.plot(ax=ax, color='red')

## 计算记录
print(f'Distance: {toy_traj.distance(my_traj)} meters') # 返回最短距离
print(f'Hausdorff distance: {toy_traj.hausdorff_distance(my_traj):.2f} meters') # 返回Hausdorff距离

Hausdorff距离可以理解为：对于集合A 中的每个点，计算它到集合B的最近距离，然后在这些距离中找到最大值；反过来对于集合 B 中的每个点，计算它到集合A 的最近距离，然后在这些距离中找到最大值。Hausdorff距离是这两个最大值中的较大者。

参考链接：

开源可视化报表工具：Superset

Thu, 04 Jan 2024 12:54:55 CST

Superset简介

Superset 是一个开源的数据可视化和数据探索平台，最初由 Airbnb 开发，后来成为了 Apache 软件基金会的顶级项目。它支持各种类型的数据源，如数据库和 SQL 引擎，并提供了一个易于使用的界面来创建和共享仪表板和图表。

主要特点包括：

数据可视化: Superset 提供了丰富的图表库，支持从简单的折线图和条形图到更复杂的地理信息系统 (GIS) 可视化等。
数据探索: 用户可以通过 Superset 的 SQL 编辑器执行查询，探索数据，并将结果可视化。
仪表板: 可以将多个图表组合成仪表板，为数据分析提供全面视图。
安全性和权限管理: Superset 支持细粒度的访问控制，允许管理员定义用户和角色，控制对数据和功能的访问。
易于集成: 作为一个开源工具，Superset 可以与多种数据源和其他数据工具集成。
自定义和扩展: 用户可以根据需要自定义图表和界面，并且可以开发新的可视化插件。

Superset 适用于数据分析师和开发人员，帮助他们快速有效地探索和可视化数据，从而做出更好的数据驱动决策。

看板示例：

拖拽式看板编辑器：

SQL编辑器：

Superset架构

Apache Superset 是一款开源的数据可视化和数据探索平台，它的架构设计允许用户轻松地进行数据分析并创建交互式的仪表板。Superset的架构主要由以下几个核心组件构成：

Web服务器

Flask：Superset使用Flask作为其Web框架，处理HTTP请求和渲染界面。
Gunicorn：在生产环境中，通常使用Gunicorn作为WSGI HTTP服务器来运行Flask应用。

SQL查询引擎

SQLAlchemy：Superset通过SQLAlchemy与数据源进行交互，它支持多种数据库。
Pandas：在某些情况下，Superset会使用Pandas库来处理数据。

数据库

元数据数据库：存储Superset的配置信息、仪表板定义、数据源定义等。
缓存数据库：用于缓存数据，提高查询性能。Redis和Memcached是常用的选项。

前端

React & JavaScript：Superset的前端主要使用React框架结合JavaScript开发，用于实现用户界面的交互和动态展示。
js：图表的渲染利用了D3.js库，提供丰富的可视化选项。

安全性

认证与授权：Superset提供灵活的认证选项（如LDAP、OAuth、数据库等）和基于角色的访问控制（RBAC）。
数据安全：支持数据级别的安全控制，确保用户只能访问授权的数据。

扩展性

插件系统：Superset支持自定义插件，允许用户扩展新的可视化类型或其他功能。
API：提供REST API，支持与其他系统的集成。

任务调度器

Celery：用于执行后台任务，如异步查询和发送报告。

Superset功能扩展

拓展Apache Superset主要涉及添加新的可视化类型、增强现有功能、集成更多数据源等方面。

开发自定义可视化插件

Superset支持通过插件机制添加新的图表和可视化类型。
可以使用React和JavaScript开发新的可视化组件。
开发完成后，将插件包含在Superset的配置中，使其成为可用的可视化类型。

集成更多数据源

Superset通过SQLAlchemy与数据源进行交互，可以添加对新数据库的支持。
通过添加相应的数据库驱动和SQLAlchemy方言，可以实现新的数据库支持。

增强现有功能

对Superset的源代码进行修改，可以增强或改变现有功能。
包括改进用户界面、增加新的数据处理功能、优化性能等。

使用API进行集成

Superset提供了REST API，可以用来与其他系统集成。
例如，可以通过API自动化仪表板的创建、更新数据源等。

安全性和认证的定制

可以定制Superset的安全性和认证机制，如集成企业的单点登录（SSO）系统。
修改认证流程以支持LDAP、OAuth等。

使用和配置Celery任务调度器

使用Celery来优化和管理后台任务，如数据刷新、报告发送等。
可以定制Celery的配置以满足特定的性能和规模需求。

参考链接：

文字语义纠错技术探索与实践-张健

Wed, 21 Dec 2022 15:10:41 CST

背景

文本语义纠错的使用场景非常广泛，基本上只要涉及到写作就有文本纠错的需求。书籍面市前就有独立的校对的环节来保障出版之后不出现明显的问题。在新闻中我们也时不时看到因为文字审核没到位造成大乌龙的情况，包括上市公司在公开文书上把“临时大会”写成为“临死大会”，政府文件把“报效国家”写成了“报销国家”。有关文本纠错的辅助工具能给文字工作人员带来较大的便利，对审核方面的风险也大幅降低。

除了不同的写作场景，文本纠错还会用在其他一些智能处理系统中，具体的情况包括：音频通话记录经过自动语音识别（ASR）转写成文本之后，存在一些转译错误；光学字符识别（OCR）系统识别图片中的文字并进行提取，会存在字符识别错误；在搜索引擎或自动问答系统里面，用户在查询过程中的输入错误，往往会导致系统无法理解用户的真实意图，需要进行查询纠正改写。这些情况都需要通过文本纠错技术来进行修正，使产品整体的用户体验更加友好。

文本语义纠错在学术领域有三个子任务，分别是拼写检查（Spelling Check）、语法检错（Grammatical Error Detection）和语法纠错（Grammatical Error Correction）。其中语法检错是对文本中的语法错误进行检测，拼写检查是对文本中的错别字进行修正，语法纠错是纠正文本中的语法错误。拼写检查在英文场景表现为单词拼写错误，在中文场景表现为音近形近错别字。而语法纠错除此之外，还包括字词缺失、字词冗余、字词使用不当、语序不当等错误类型。语法纠错区别于拼写检查的一个显著特点是，语法纠错纠正后的文本和原始文本的长度不一定相等，而拼写检查纠正前后的文本长度都是保持一致的，这也决定了两者的算法支持存在差异。一般来说，拼写检查可以看作为语法纠错的一个任务子集。

我们对语法纠错的问题作一下形式化定义，输入的原始文本定义为X={x1,x2,...,xn};原始文本正确的纠正结果文本序列定义为Y={y1,y2,...,ym}，算法预测输出的文本，定义为P={p1,p2,...,pk}。

评估指标

在开始我们的文本语义纠错算法探索之旅之前，我们先思考一个问题，究竟怎么样的模型表现才是公认更有效的，这个好坏应该从何种方式、如何量化地评估出来。这也是我们在解决其他所有类型的NLP任务都需要先考虑的问题，这个问题就是如何定义我们的评测指标。下面罗列了纠错算法常用的一些评测指标：

01 M2（MaxMatch）

M2指标主要是通过计算输出文本和原始文本之间的编辑集合G，然后与人工标注的编辑集合E结合，计算准确率、召回率、F0.5值（采用F0.5表示对准确率更加关注）。这里的编辑理解为一个转换动作，经过一组转换动作，可以完成原始文本到纠正文本的转换，M2指标定义形如：

F0.5=1.25*RP/(R+0.25P)

下表罗列了一组示例和计算过程：

表 1 纠错文本示例

其中编辑集合G={孜→自，书→书写}，人工标注编辑集合E={孜→自,俱→具,读书→读}

可以计算出来:

P=1/2=0.5

R=1/3=0.33

F0.5=1.25*0.33*0.5/(0.33+0.25*0.5)=0.45

02 ERRANT

ERRANT[1]是升级版的M2。M2的局限性也比较明显，依靠前置的人工标注，有比较大的工作量，而且人工标注编辑集合产生的方式可能不太一致，导致匹配不准。ERRANT在生成标准答案的编辑集合和生成预测的编辑集合都采用了自动判别的方式，同时支持了25种的错误类型，输出了更丰富维度的错误报告信息。缺点是该工具面向英文，中文需要做较大改造。

03 面向标注形态的其他指标

上述两者在处理纠错任务评测时存在一些缺点，包括M2不支持检错性能评估，编辑不能正确反映合理纠错动作等等。

我们会在一些学术评测上看到，根据对待纠文本进行的错误标注类型来制定的评测指标。下面举了NLPCC2022语法纠错评测指标为例，它对应的错误类型总共有赘余(Redundant Words，R)、遗漏(Missing Words，M)、误用(Word Selection，S)、错序(Word Ordering Errors，W)四类，评估的维度包含以下方面：

假阳性（False Positive）：正确句子被判包含错误的比例。
侦测层（Detective-level）：对句子是否包含错误做二分判断。从句子是否有错，判断p/r/f1
识别层（Identification-level）：给出错误点的错误类型。按一个句子的错误种类计算p/r/f1
定位层（Position-level）：对错误点的位置和覆盖范围进行判断，以字符偏移量计。错误位置是否对计算p/r/f1
修正层（Correction-level）：提交针对字符串误用（S）和缺失（M）两种错误类型的修正词语。修正词语可以是一个词，也可以是一个词组。M/S的修正词语角度

由于纠错任务本身的特殊性（同一个错误的文本可以有多种正确的纠正答案，或者同一个位置可以采用不同的错误类型进行标注），目前现存的评测指标大都有其局限性，如何定义主客观、统一、合理的语法纠错评测指标仍然在不断探讨。

公开数据集

在确定了评估指标之后，我们已经确定了评判算法好坏的一个标准。锅已经端好，就等米下锅了,数据对于算法研发人员来说是必需品，一方面它是验证效果的信息来源,另一方面它是进行模型构建的训练语料。比较好的方式是从公开的渠道获取比较优质的标注数据。目前公开的中文语义纠错数据集包括NLPCC2018[2]、NLPTEA2020[3]、SIGHAN2015[4]等,较多是非母语学生学习汉语收集得来的语料集，训练和验证的数据标注形式如图所示:

图1 公开数据集（NLPTEA2020、NLPCC2020和SIGHAN2015）

无监督方法

文本语义纠错的算法整体可以分成无监督和有监督的两种方式，我们先从无监督的方法开始看。无监督方法的核心是如何构建一个好用的语言模型，并且用在纠错的任务上。对于NLPer来说，我们经历了太多的预训练语言模型，像BERT、XLNet、GPT3等等，其本质还是语言模型或者说经典语言模型的一些变种。语言模型实际上是对文本序列的概率分布进行建模，通俗地来表达，语言模型是判断一句话是不是符合常理，或者说话应该怎么说才合理（符合概率分布）。这个正好就对应上了纠错任务的本质需求，我们从最经典的N元语言模型开始来介绍一下语法纠错的处理逻辑。

01 n元语言模型

一个语言模型构建字符串的概率分布p(W)，假设p(W)是字符串作为句子的概率，则概率由下边的公式计算：

但是这样去计算句子概率会导致庞大的计算量，导致根据马尔科夫假设，一个词只和他前面n-1个词相关性最高，这就是n元语法模型，简化后的计算公式为：

在得到这个结论之后，我们尝试使用N元语言模型来解决拼写检查的问题。

假设我们采用的是5元语言模型，训练阶段使用大量的语料来进行统计所有的p(w5|w1w2w3w4)并存储起来。在预测阶段，设定待纠正的文本序列为W={w1,w2,...,wn}，针对每个位置的wk，我们通过预先构建好的混淆集获得w的音近形近字wk'。

然后通过上述公式分别计算原始文本和修改文本的句子概率P(w1...wk...wn)、P(w1...wk'...wn)。如果P(w1...wk’...wn)>P(w1...wk...wn)，则说明修改后文本的通顺度提升（概率升高），可以接受该纠正修改（wk替换为wk'）。

从而我们的纠错执行过程则包含如下：

计算输入句子的归一化对数概率，并且为句子的每个字构建一个混淆集合；
对句子每个字针对其不同混淆字重新打分，应用单个最佳进行校正，将概率提高到当前最高值以上；
重复上面过程直至概率没变化。

图2 N元语言模型纠错执行计算过程

上述过程比较好理解，同时可以明显看出来一些硬伤，包括会OOV（未登录词）问题导致语言模型计算出来的概率为0；模型会过分优待高频短串，或者忽视低频短串。这时候需要通过平滑技术来改善概率算法，典型平滑方法包含Add-one、Interpolation和Modified Kneser-ney等。此外，仍有些难以通过技术手段解决的问题，包括上下文范围局限较大（n 的增加会导致计算和资源消耗成倍增加）和缺少泛化（缺乏实际予以的理解），此时需要引入基于神经网络的语言模型。

02 基于神经网络的语言模型

比较经典的基于神经网络的语言模型，数学表达式可以写为：

以k元文法为例，把前k-1个词作为特征，用softmax预测最后一个词。

一般基于神经网络的语言模型设计得更加复杂，会把上下文的信息形成特征，来预测当中的每一个词。定义基于上下文context下wi的预测概率为P(wi|context_i),句子的概率可以表示为：

方法[5]就是采用了BERT和GPT作为基础的语言模型来计算句子的概率。

有监督方法

无监督的纠错算法在处理文本时存在以下弱点：容易受局部高频或低频的序列影响，效果不够稳定；在需要对准确率和召回率进行平衡调整时，不太好通过阈值的方式进行控制；可以较好应用在拼写检查的任务上，但是对于句子长度有变化的语法纠错任务支持就比较弱。此时需要使用有监督算法来作为实现手段。

01 NMT/Seq2Seq

解决字词冗余/缺失这类纠错前后句子长度有变化的任务，我们第一感觉就想起可以通过文本生成的方式来训练对应的模型实现该功能。而且语法纠错任务和文本生成任务的形态基本上是一致的，也导致了文本生成模型很自然地被研究者注意，引入到语法纠错的任务领域。

NMT-based GEC[6]是第一篇通过使用神经网络机器翻译来实现语法纠错的文章。2014年seq2seq模型一提出即引发了较大反响，后续seq2seq成为了文本生成的主流结构。seq2seq将一个作为输入的序列映射为一个作为输出的序列，这一过程由编码（Encoder）输入与解码（Decoder）输出两个环节组成, 前者负责把序列编码成一个固定长度的向量，这个向量作为输入传给后者，输出可变长度的向量。下图展现了一个基础的seq2seq结构。

图3 seq2seq结构

方法[7]使用了经典的Encoder-Decoder模型结构来解决中文语法纠错问题，嵌入层使用了特殊的嵌入表示，同时在编码层使用了卷积神经网络强化了纠错的局部性，具体的模型结构如下：

图4 Encoder-Decoder结构纠错模型

02 LaserTagger

由于书写错误的出现概率普遍不高，纠错任务本身的输入输出存在大量重叠（基本不用改），所以大多数文本可以保持不变。但是我们在通过seq2seq的方式进行实现时，对于正常的字符也要全部进行预测，造成效率非常低下。因此谷歌在EMNLP 2019提出了LaserTagger，在使用Encoder-Decoder的模型结构条件下，把预测的内容从文字变成了编辑操作类型。lasertagger其模型结构（采用BERT作为编码层、自回归Transformer作为解码层）如下所示：

图5 LaserTagger纠错模型

编辑操作类型包含Keep（将单词复制到输出中），Delete（删除单词）和Add（在之前添加短语X），其中被添加的短语来自一个受限的词汇表。
通过结构的改造，lasertagger体现了推理速度快和样本训练效率高的有点。因为预测的类型只有三种，相对于seq2seq而言，解码的空间大幅降低，推理性能提升明显，相对于BERT+seq2seq的模型结构，larserTagger的性能提升接近100倍。同时因为预测的内容求解空间也大幅降低，所以对样本的需求量也大幅减少，在1000份的样本下也能取得不错的效果。

03 PIE

与LaserTagger同年提出来的PIE（Parallel Iterative Edit Models）[8]同样是针对seq2seq 生成文本的可控性较差，推理速度也比较慢的问题进行来改进。与LarserTagger类似，PIE构造模型来对编辑操作进行预测，不过编辑操作的类型稍有区别，多了一个替换（replace)和词性变换（面向英文）。在处理替换和添加操作时，PIE将BERT编码层进行了扩展来支持替换和添加的信息输入，采用了一个双层的双向transformer，结构如下所示：

图6 PIE纠错模型

上图表示了一个长度为3的文本输入（x1,x2,x3)。在最底层的输入层，M表示mask标识符的嵌入向量，p表示位置嵌入，x表示词嵌入。在中间层和输出层，r表示对应位置的替换信息，h表示对应位置的的原始信息，a表示对应位置的插入信息。之后利用三类信息来分别计算不同操作的概率，并归一化，CARDT 分别代表复制、插入、替换、删除、词形变换，计算公式如下：

纠错过程中，PIE模型输出概率最高的编辑操作，完成修改后再迭代地进行预测，直至句子不发生改变后停止。

PIE定义的结构可以实现在并行解码的同时保持较高的准确率，它在这篇文章第一次提出了seq2edit的概念。

04 GECToR

GECToR[9]提出了一种序列标注模型，编码层由预训练的 BERT 型 transformer 组成，上面堆叠两个线性层，顶部有 softmax 层。模型输出的标签包含了基本变换和g-变换两种类型。其中基本变换包含保留（KEEP）、删除（DELETE）、添加（APPEND）和替换（REPLACE)。g-变换主要面向英文，针对了英语的语法变化总结出了5大类（大小写、单词合并、单词拆分、单复数和时态）29个小类的状态变换。

GECToR另外两个亮点是引入了不同的预训练Transformer解码器（包括XLNet、RoBERTa、ALBERT、BERT和GPT-2）并进行了比较，以及采用了三阶段的训练方式。第一阶段使用了大量（九百万）实验合成的包含语法错误+语法正确的句子对进行预训练，第二阶段使用了少量的公开纠错数据集的句子对进行Fine-tuning，第三阶段使用了语法错误+正确和语法正确+正确的句子对来进行Fine-tuning，实验证明第三阶段的Fine-tuning有效果提升。

在预测阶段，GECToR也是采用了多轮预测的方案。

05 PLOME

PLOME[10]在2021ACL发表，是针对中文文本纠错任务构建的预训练语言模型，结构和BERT比较类似（12层Transformer）。PLOME的创新点主要在于采用了基于混淆集的掩码策略、把拼音和字形信息作为模型输入以及把字符和拼音的预测任务作为了模型的训练和微调目标。

PLOME的掩码策略主要是基于以下4种：字音混淆词替换(Phonic Masking)、字形混淆词替换(Shape Masking)、随机替换（Random Masking）、原词不变（Unchanging）。PLOME的掩码策略同样仅遮盖15%的token，且4种MASK策略占比分别为: 60% 、15%、10%、15%。

词嵌入模块方面，PLOME采用了字符嵌入(character embedding)、位置嵌入( position embedding)、语音嵌入(phonic embedding)和形状嵌入(shape embedding)。其中，字符嵌入和位置嵌入与BERT的输入一致。其中构建语音嵌入时，使用Unihan数据库得到字符-拼音的映射表(不考虑音调)，然后将每一个字的多个拼音字母序列输入到GRU网络中，得到该字的拼音嵌入向量。同样，构建字形嵌入时，使用Chaizi数据库得到字形的笔画顺序，然后将字形的笔画顺序序列输入到GRU网络中，得到该字的字形嵌入向量。

在训练任务方面，PLOME训练了2个任务，字符预测和BERT一样，增加了拼音的预测，预测被替换词的正确发音，更够更好解决同音和音近错误。

PLOME预训练语言模型的下游任务主要是文本纠错任务。该任务的输入是字符序列 ,输出是预测的字符序列。该论文仅在拼写检查任务上做了验证。

06 其他策略

（1）COPY机制

COPY机制同样是利用目标文本和源文本有大量重复这个特点。研究[11]提出了Copy-Augment的GEC模型，其主要思想是：在生成序列过程中，考虑两个生成分布：分别是复制输入序列中的词语（0/1表示是否复制)的概率分布和从候选词典中的词语生成的概率分布。将两者的概率分布加权求和作为最终生成的概率分布，进而预测每一个时刻生成的词语。基本架构如下：

图7 COPY机制

该模型将简单的词语复制任务交给了Copy机制，将模型结构中的Attention等结构更多地用来学习比较难的新词生成，对训练更加可控。

（2）数据增强

数据增强可以通过基于规则和基于生成的方式实现。

基于规则这个比较简单，我们可以按照错误的类型（字词冗余、缺失、词序错误等）针对性地制定策略构造包含语法错误的样本，然后扔到模型来进行训练。不过基于规则的方式有点过于粗暴，很可能规则生成的错误与实际产生的错误差距比较大，或者比较不符合常规认知。

第二种方式就是基于生成。最早基于生成的数据增强方式应该是回译法，就是将文本从一个语种翻译到另外一个语种，然后再翻译回来，从而构造了句子对，这种数据增强形式针对正常的编辑写作可能不太有效，更加符合跨语言学习的用户的错误特点。另外有研究[12]结合了分类器和自编码器来联合训练，达到生成固定类型错误样本的目的。而研究[13]通过对GEC模型进行对抗攻击，可以生成有价值的带有语法错误的句子，可以利用生成的句子训练GEC模型，提升性能的同时提升鲁棒性。

处理难点与技术挑战

01 语料收集

目前公开的中文语义纠错数据集主要是不同母语的人学习汉语作为第二语言收集得来的语料集，目前大部分关于语法纠错的算法模型都是基于这些数据集来做效果验证的，不过我们实际中要处理的数据通常并不是同样的形式诞生，更多是掌握汉语作为母语的人由于失误导致的语法错误，这种情况和公开预料的情况差别比较大，错误的分布差距也比较大，从而通过公开语料集训练得来的模型在上线到正常的业务流程里面，效果通常都会比较一般。

02 长依赖

长距离包括跨语句依赖在论文等文本中很常见，一旦出现错误，很难察觉并纠正。当前语法研究大多集中在单个语句的语法检查和纠错，很少涉及长距离语法问题，相关数据集和模型方法缺失，是语法纠错的难题之一。

03 模型的泛化能力与鲁棒性

一般来说，不同行业、不同领域的文本在措辞运用、表达习惯和专有名词等方面都存在较大的差异。譬如说政务机关红头文件非常严谨的语言表达和自媒体新闻相对较自由的文风就有明显的差别，又譬如金融行研报告和医学论文在基本内容和专业术语上也截然不同。在一个领域性能出色的纠错模型在切换到另外一个领域，往往效果下降明显。如何提升模型的泛化能力和鲁棒性，面临着巨大的技术挑战。

04 效果指标与体验的平衡

SOTA的指标可以刷到，但是这些模型一旦介入实际场景的数据，效果会差得一塌糊涂，这个一方面是由于模型和场景紧密相关，另外一方面是，通常公开数据集的错误分布是呈高密度，但是实际场景是低密度，会容易导致非常高的误判。譬如说SOTA里面准确率的指标是80%，对于在低密度错误的样本中，很可能准确率会下降到20~30%左右。纠错系统的体验会比较差。

05 效果指标与纠错性能的平衡

工业界往往会采用pipeline的方式，先对文本进行检错，如果检测出来有错误，再对文本进行纠错处理。但是这个检错阶段的错误会传递到纠错阶段，导致效果下降。如果直接走seq2seq或seq2edit的纠错模型，或者需要融合多种模型策略来生成最终纠错结果，纠错的性能会下降非常快，部分实验3000字的纠错可能需要长达40~60秒，这个无法处理大量并发的文本纠错需求。我们需要再效果和性能上取得平衡，或者有更好的方法在保障效果指标的前提下提升纠错性能。

达观在语义纠错方面的产品实践

达观数据在语义纠错方面有比较深入的产品实践，开发出的投行质控系统和公文智能处理系统均处理了相关场景。

达观投行质控系统基于深度学习、NLP（自然语言处理）算法，帮助用户解决几大文书审核场景，包括:文书格式纠错，文字纠错和完整性审核；文档目录智能识别，一键定位：文档条款内容智能提取，方便业务人员对条款内容进行预审；支持文档多版本的内容比对等。

达观智能公文处理系统，严格遵循《党政机关公文处理工作条例》和《党政机关公文格式》规定，通过公文智能分析、公文知识库引用、公文审校、公文排版、公文格式纠错、公文内容语义纠错、公文在线比对修改等一体化的功能，实现基础字词校对准确率超90%、法律引用校验和公务文书完整性校对准确率超95%，有力提升政府机关整体公文质量，避免公文“带病”发布情况，确保政府机关公信度。

参考文献：

[1] Korre K, Pavlopoulos J. Errant: Assessing and improving grammatical error type classification[C]//Proceedings of the The 4th Joint SIGHUM Workshop on Computational Linguistics for Cultural Heritage, Social Sciences, Humanities and Literature. 2020: 85-89.

[2] Zhao Y, Jiang N, Sun W, et al. Overview of the nlpcc 2018 shared task: Grammatical error correction[C]//CCF International Conference on Natural Language Processing and Chinese Computing. Springer, Cham, 2018: 439-445.

[3] Rao G, Yang E, Zhang B. Overview of NLPTEA-2020 shared task for Chinese grammatical error diagnosis[C]//Proceedings of the 6th Workshop on Natural Language Processing Techniques for Educational Applications. 2020: 25-35.

[4] Tseng Y H, Lee L H, Chang L P, et al. Introduction to SIGHAN 2015 bake-off for Chinese spelling check[C]//Proceedings of the Eighth SIGHAN Workshop on Chinese Language Processing. 2015: 32-37.

[5] Alikaniotis D, Raheja V. The unreasonable effectiveness of transformer language models in grammatical error correction[J]. arXiv preprint arXiv:1906.01733, 2019.

[6] Yuan Z, Briscoe T. Grammatical error correction using neural machine translation[C]//Proceedings of the 2016 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies. 2016: 380-386.

[7] Ren H, Yang L, Xun E. A sequence to sequence learning for Chinese grammatical error correction[C]//CCF International Conference on Natural Language Processing and Chinese Computing. Springer, Cham, 2018: 401-410.

[8] Awasthi A, Sarawagi S, Goyal R, et al. Parallel iterative edit models for local sequence transduction[J]. arXiv preprint arXiv:1910.02893, 2019.

[9] Omelianchuk K, Atrasevych V, Chernodub A, et al. GECToR--grammatical error correction: tag, not rewrite[J]. arXiv preprint arXiv:2005.12592, 2020.

[10] Liu S, Yang T, Yue T, et al. PLOME: Pre-training with misspelled knowledge for Chinese spelling correction[C]//Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers). 2021: 2991-3000.

[11] Zhao W, Wang L, Shen K, et al. Improving grammatical error correction via pre-training a copy-augmented architecture with unlabeled data[J]. arXiv preprint arXiv:1903.00138, 2019.

[12] Wan Z, Wan X, Wang W. Improving grammatical error correction with data augmentation by editing latent representation[C]//Proceedings of the 28th International Conference on Computational Linguistics. 2020: 2202-2212.

[13] Wang L, Zheng X. Improving grammatical error correction models with purpose-built adversarial examples[C]//Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP). 2020: 2858-2869.

作者简介

张健，达观数据联合创始人，复旦大学计算机软件与理论硕士，曾就职于盛大集团和腾讯文学，担任人工智能和大数据技术专家职位。目前担任达观数据文本应用部总负责人，对于机器学习算法和自然语言处理领域的研发有丰富的实践经验和技术积累，负责客户意见洞察系统、智能客服工单分析系统、文本语义纠错系统、事件分析平台、文本智能审核系统等多个文本应用产品的开发和落地。荣获上海市浦东新区科学技奖、“2021上海科技青年35人引领计划”、上海市青年科技启明星等多个奖项。

使用Excel搭建推荐系统

Sun, 13 Nov 2022 23:06:06 CST

在上一篇重新认识Excel的文章中，提到了Excel无所不能，然后就想到了曾经看到的这篇关于如何使用Excel搭建推荐引擎的文章。于是找了出来做了下简单的翻译（只翻译了重点部分）。

在互联网上有无限的货架空间，找到你想看的东西可能会让人筋疲力尽。幸运的是，与决策疲劳作斗争是 Netflix 的工作……而且他们很擅长。太擅长了。他们神奇地向您推荐完美的电影，这样您的眼睛就会一直盯着管子，他们会把您的拖延变成周末沙发上的狂欢。该死的，Netflix。你的秘诀是什么？你怎么这么了解我们？“魔法”非常简单，本教程使用分步电子表格揭示了其中的秘密。

尽管自Netflix Prize 竞赛以来有大量关于推荐系统的论文或视频，但大多数要么 (A) 技术太高，初学者无法使用，要么 (B) 水平太高，不实用。

在这篇文章中，我们将从头开始构建一个电影推荐系统，其中包含简单的英语解释和可以在 Excel 中遵循的分步公式。所有梯度下降推导都是手工计算的，您可以使用 Excel 下拉过滤器来微调模型的超参数并增强您的理解。

学习内容

构建帮助赢得 100 万美元 Netflix 奖金的算法版本 SVD++ 背后的确切步骤。
机器如何实际学习（梯度下降）。即使您从未告诉过 Netflix，也可以观看 Netflix 了解您的电影品味。
超参数调优。了解如何调整模型输入（学习率、L2 正则化、# of epochs、权重初始化）以获得更好的预测。
模型评估和可视化。了解训练数据和测试数据之间的区别，如何防止过度拟合，并了解如何可视化模型的特征。

在简要介绍了推荐系统之后，我将通过以下 4 个部分来构建一个模型来预测少数好莱坞明星的电影评分。

第一部分：模型概览
第二部分：观看魔法秀（权重初始化和训练）
第三部分：魔法揭秘（梯度下降、导数）。我将逐步讲解机器学习魔法背后的数学，我将使用实数作为例子代入批量梯度下降的公式（不会使用“宏”或者Excel求解器之类的东西隐藏细节）。
第四部分：模型评估和可视化

第一部分：模型概览

数据

博客文章模型使用 30 个虚构评分（5 个用户 x 6 部电影）来简化教程。要在我们进行过程中跟随并试验模型，您可以在此处下载电子表格（Excel 或 Google 表格）。

拆分数据——训练集和测试集

我们将使用25项评价来训练模型，剩下5项评价测试模型的精确度。

我们的目标是创建一个在25项已知评价（训练数据）上表现良好的系统，并希望它在5项隐藏（但已知）评价（测试数据）上做出良好的预测。

如果我们有更多数据，我们本可以将数据分为3组——训练集（约70%）、验证集（约20%）、测试集（约10%）。

评价预测公式

评价预测是用户/电影特征的矩阵乘法（“点积”）加上用户偏置，再加上电影偏置。

公式为：

$$\hat{r}_{i,j}=((u_1 m_1)+(u_2 m_2)+(u_3 m_3)+u_{bias}+m_{bias})$$

其中：

$\hat{r}_{i,j}$表示用户i对电影j的预测评价
$u_1$、$u_2$、$u_3$为用户潜因子
$m_1$、$m_2$、$m_3$为电影潜因子
$u_{bias}$为用户偏置
$m_{bias}$为电影偏置

用户/电影特征

直觉上说，这些特征表示类型、演员、片长、导演、年代等因素。尽管我们并不清楚每项特征代表什么，但是当我们将其可视化后（见第四部分）我们可以凭直觉猜测它们可能代表什么。
出于简单性，我使用了3项特征，但实际的模型可能有50、100乃至更多特征。特征过多时，模型将“过拟合/记忆”你的训练数据，难以很好地推广到测试数据的预测上。
如果用户的第1项特征（让我们假定它表示“喜剧”）值较高，同时电影的“喜剧”特征的值也很高，那么电影的评价会比较高。

用户/电影偏置

用户偏置取决于评价标准的宽严程度。如果Netflix上所有的平均评分是3.5，而你的所有评分的均值是4.0，那么你的偏置是0.5. 电影偏置同理。如果《泰坦尼克号》的所有用户的评分均值为4.25，那么它的偏置是0.75（= 4.25 – 3.50）。

RMSE —— 评估预测精确度

RMSE = Root Mean Squared Error （均方根误差）

RMSE是一个数字，尝试回答以下问题“平均而言，预测评价和实际平均差了几颗星（1-5）？”

RMSE越低，意味着预测越准……

观察：

我们只在意绝对值差异。相比实际评分高估了1分的预测，和相比实际评分低估了1分的预测，误差相等，均为1。
RMSE是误差同数量级的平均，而不是误差绝对值的平均。在我们上面的例子中，误差绝对值的平均是75（1 + 1 + 0.25 = 2.25，2.25 / 3 = 0.75），但RMSE是0.8292. RMSE给较大的误差更高的权重，这很有用，因为我们更不希望有较大的误差。

超参数调整

通过电子表格的下拉过滤器，可以调整模型的3个超参数。你应该测试下每种超参数，看看它们对误差的影响。

训练epoch数—— 1个epoch意味着整个训练集都过了一遍
学习率—— 控制调整权重/偏置的速度
L2（lambda）惩罚因子—— 帮助模型预防过拟合训练数据，以更好地概括未见测试数据。

现在，让我们看一场魔法秀，看看模型是如何从随机权重开始，学习最优权重的。

第二部分：观看魔法秀（权重初始化和训练）

观看梯度下降的实际操作感觉就像您在观看 David Blaine 的魔术。

他到底是怎么知道我会在52张牌中选这张的呢？
等等，他刚刚是不是浮空了？

最后你深感敬畏，想要知道魔术是如何变的。我会分两步演示，接着揭露魔法背后的数学。

抽一张卡，随便抽一张（权重初始化）

在训练开始，用户/电影特征的权重是随机分配的，接着算法在训练中学习最佳的权重。

为了揭示这看起来有多么“疯狂”，我们可以随机猜测数字，然后让计算机学习最佳数字。下面是两种权重初始化方案的比较：

简单—— 用户特征我随机选择了1、0.2、0.3，剩下的特征都分配0.1.
Kaiming He—— 更正式、更好的初始化方法，从高斯分布（“钟形曲线”）中随机抽样作为权重，高斯分布的均值为零，标准差由特征个数决定（细节见后）。

观赏魔术（查看训练误差）

看看使用以上两种方案学习权重最佳值的效果，从开始（epoch 0）到结束（epoch 50），RMSE训练误差是如何变化的：

如你所见，两种权重初始化方法在训练结束时都会收敛到类似的“误差”（0.12 与 0.17），但“ Kaiming He”方法更快地收敛到较低的误差。

关键要点：无论我们从哪个权重开始，机器都会随着时间的推移学习到好的值！

注意：如果你想要试验其他初始化权重，可以在电子表格的“hyperparameters_and_initial_wts”表的G3-J7、N3-Q8单元格中输入你自己的值。权重取值范围为-1到1.

想要了解更多关于Kaiming He初始化的内容，请接着读下去；否则，可以直接跳到第3部分学习算法的数学。

Kaiming He权重初始化

权重 = 正态分布随机抽样，分布均值为0，标准差为 (=SquareRoot(2/# of features))

电子表格中的值由以下公式得到：=NORMINV(RAND(),0,SQRT(2/3))

$$W_l \sim \mathcal{N}(0, \sqrt{\frac{2}{n_l}}) \text{and} \mathbf{b}=0$$

第三部分：魔法揭秘

现在，是时候书呆一点，一步一步地了解梯度下降的数学了。如果你不是真想知道魔法是如何起效的，那么可以跳过这一部分，直接看第4部分。

梯度下降是在训练时使用的迭代算法，通过梯度下降更新电影特征、用户偏好的权重和偏置，以做出更好的预测。

梯度下降的一般周期为：

第 1 步 – 定义成本/损失函数以最小化和初始化权重
第 2 步 — 计算预测
第 3 步 – 计算梯度（相对于每个权重的成本变化）
第 4 步——在最小化成本的方向上更新每个权重“一点点地”（学习率）
第 5 步 — 重复第 2-4 步

你可以访问电子表格的“training”（训练）表，其中第11-16行是更新Tina Fey的第一项用户特征的过程。

由于数据集很小，我们将使用批量梯度下降。这意味着我们在训练时将使用整个数据集（在我们的例子中，一个用户的所有电影），而不是像随机梯度下降之类的算法一样每次迭代一个样本（在我们的例子中，一个用户的一部电影），当数据集较大时，随机梯度下降更快。

定义最小化的代价函数

我们将使用下面的公式，我们的目标是找到合适的潜因子（矩阵U、M）的值，以最小化SSE（平方误差之和）加上一个帮助模型提升概括性的L2权重惩罚项。

下面是Excel中的代价函数计算。计算过程忽略了1/2系数，因为它们仅用于梯度下降以简化计算。

L2正则化和过拟合

我们加入了权重惩罚（L2正则化或“岭回归”）以防止潜因子值过高。这确保模型没有“过拟合”（也就是记忆）训练数据，否则模型在未见的测试电影上表现不会好。

之前，我们没有使用L2正则化惩罚（系数为0）的情况下训练模型，50个epoch后，RMSE训练误差为0.12.

但是模型在测试数据上的表现如何呢？

如果我们将 L2 惩罚因子从 0.000 更改为 0.300，我们的模型应该可以更好地概括未见过的测试数据：

计算预测

我们将计算Tina的电影预测。我们将忽略《泰坦尼克号》，因为它在测试数据集中，不在训练数据集中。

计算梯度

目标是找到误差对应于将更新的权重的梯度（“坡度”）。

得出梯度之后，稍微将权重“移动一点点”，沿着梯度的反方向“下降”，在对每个权重进行这一操作后，下一epoch的代价应该会低一些。

“移动一点点”具体移动多少，取决于学习率。在得到梯度（3.3）之后，会用到学习率。

梯度下降法则：将权重往梯度的反方向移动，以减少误差

第1步：计算Tina Fey的第一个潜因子的代价梯度（$u_1$）

1.1整理代价目标函数，取代价在Tina Fey的第一个潜因子（$u_1$）上的偏导数。

$$\frac{\partial J(cost)}{\partial u_1}=\frac{1}{2} \sum_{(i, j): r(i,)=1}(\hat{r}_{i, j}-r_{i, j})^2+\frac{1}{2} \lambda(\sum_i\left\|u_i\right\|^2+\sum_j\left\|m_j\right\|^2)$$

1.2整理预测评价函数，改写为用户潜因子的平方和加上电影潜因子的平方和

$$\frac{\partial J}{\partial u_1}=\frac{1}{2} \sum(((u_1 m_1)+(u_2 m_2)+(u_3 m_3)+u_{bias }+m_{bias})-r_{i, j})^2+ \frac{1}{2} \lambda \sum(u_1^2+u_2^2+u_3^2)+\frac{1}{2} \lambda \sum (m_1^2+m_2^2+m_3^2)$$

1.3将公式每部分中的$u_1$视为常数，取$u_1$在公式每部分的代价上的偏导数。

1.3.1（Part 1 of 3）应用“链式法则”以得到偏导数。链式法则意味着我们将((外层函数的导数)*内层函数)* (内部函数的导数)

外层函数的导数：

$$\begin{gathered}=\frac{1}{2} \sum(((u_1 m_1)+(u_2 m_2)+(u_3 m_3)+u_{bias}+m_{bias})-r_{i, j})^2 \leftarrow \text { power rule} \\=2 \times \frac{1}{2}(((u_1 m_1)+(u_2 m_2)+(u_3 m_3)+u_{bias}+m_{bias})-r_{i, j})^1 \\=\text { (predicted rating }-\text { actual rating }) \\=(\text { error })\end{gathered}$$

内层函数的导数：

$$\begin{gathered}=\frac{1}{2} \sum((u_1 m_1)+(u_2 m_2)+(u_3 m_3)+u_{bias}+m_{bias})-r_{i, j} \leftarrow \text {constant rule} \\ ((u_1 m_1)+(0)+(0)+0+0)-0 \\ =m_1 \\ 1.3.1=(\text{error} x m_1)\end{gathered}$$

1.3.1（Part 2 of 3）应用“幂法则”以得到偏导数。根据幂法则，指数为2，所以将指数降1，并乘上系数1/2. $u_2$和$u_3$视作常数，变为0.

$$\begin{gathered}=\frac{1}{2} \lambda \sum(u_1^2+u_2^2+u_3^2) \\=2 \times \frac{1}{2} \times \lambda(u_1^1+0+0) \\=\lambda \times u_1 \\1.3 .2= (\lambda \times u_1)\end{gathered}$$

1.3.3 (Part 3 of 3 ) 应用“常数法则”以得到偏导数。

$$\begin{gathered}=\frac{1}{2} \lambda \sum(m_1^2+m_2^2+m_3^2) \\=0\end{gathered}$$

由于$u_1$对这些项毫无影响，结果是0。

$$1.3.3 =0$$

1.4 结合1.3.1、1.3.2、1.3.3得到代价在$u_1$上的偏导数。

$$\begin{aligned} \quad \text { Part } 1+\text { Part } 2+\text { Part } 3 \\ \frac{\partial J}{\partial u_1} &=(\text { error } x m_1)+(\lambda \times u_1)+0 \\ &=(\text { error } x m_1)+(\lambda \times u_1)\end{aligned}$$

第2步：对训练集中Tina看过的每部电影，利用前面的公式计算梯度，接着计算Tina看过的所有电影的平均梯度。

更新权重

学习Tina的旧$u_1$，学习率($\alpha$)，以及上面计算的平均梯度，更新$u_1$。我们将使用的学习率为0.3。

Gradient descent formula:

$$New \ u_1= old \ u_1-\alpha (average \ gradient)$$

$$New \ u_1=(0.66)-0.3(1.92)$$

$$New \ u_1=(0.66)+0.58$$

$$New \ u_1=(0.08)$$

“training”（训练）表的X11-X16单元格对应上面的计算过程。

你可以看到，电影特征和用户/电影偏置以类似的方式更新。

每一个训练epoch更新所有的电影/用户特征及偏置。

第四部分：模型评估和可视化

现在我们已经训练好了模型，让我们可视化电影的2个潜因子。

如果我们的模型更复杂，包括10、20、50+潜因子，我们可以使用一种称为“ 主成分分析（PCA）”的技术提取出最重要的特征，接着将其可视化。

相反，我们的模型仅仅包括3项特征，所以我们将可视化其中的2项特征，基于学习到的特征将每部电影绘制在图像上。绘制图像之后，我们可以解释每项特征“可能代表什么”。

从直觉出发，电影特征1可能解释为悲剧与喜剧，而电影特征3可能解释为男性向与女性向。

这不是完美的解释，但还算一种合理的解释。《勇士》（warrior）一般归为剧情片，而不是喜剧片。不过其他电影基本符合以上解释。

总结

电影评价由一个电影向量和一个用户向量组成。在你评价了一些电影之后（显式或隐式），推荐系统将利用群体的智慧和你的评价预测你可能喜欢的其他电影。向量（或“潜因子”）的维度取决于数据集的大小，可以通过试错法确定。

我鼓励你实际操作下电子表格，看看改变模型的超参数会带来什么改变。

参考链接：

Netflix and Chill: Building a Recommendation System in Excel

Linux文件系统inode详解

Sat, 13 Aug 2022 09:50:00 CST

文件系统

文件系统是操作系统中负责管理持久数据的子系统，说简单点，就是负责把用户的文件存到磁盘硬件中，因为即使计算机断电了，磁盘里的数据并不会丢失，所以可以持久化的保存文件。

文件系统的基本数据单位是文件，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同，就会形成不同的文件系统。

Linux 最经典的一句话是：「一切皆文件」，不仅普通的文件和目录，就连块设备、管道、socket 等，也都是统一交给文件系统管理的。

Linux 文件系统会为每个文件分配两个数据结构：索引节点（index node）和目录项（directory entry），它们主要用来记录文件的元信息和目录层次结构。

索引节点，也就是inode，用来记录文件的元信息，比如 inode 编号、文件大小、访问权限、创建时间、修改时间、数据在磁盘的位置等等。索引节点是文件的唯一标识，它们之间一一对应，也同样都会被存储在硬盘中，所以索引节点同样占用磁盘空间。
目录项，也就是dentry，用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，就会形成目录结构，但它与索引节点不同的是，目录项是由内核维护的一个数据结构，不存放于磁盘，而是缓存在内存。

由于索引节点唯一标识一个文件，而目录项记录着文件的名，所以目录项和索引节点的关系是多对一，也就是说，一个文件可以有多个目录。比如，硬链接的实现就是多个目录项中的索引节点指向同一个文件。

注意，目录也是文件，也是用索引节点唯一标识，和普通文件不同的是，普通文件在磁盘里面保存的是文件数据，而目录文件在磁盘里面保存子目录或文件。

虽然名字很相近，但是它们不是一个东西，目录是个文件，持久化存储在磁盘，而目录项是内核一个数据结构，缓存在内存。

如果查询目录频繁从磁盘读，效率会很低，所以内核会把已经读过的目录用目录项这个数据结构缓存在内存，下次再次读到相同的目录时，只需从内存读就可以，大大提高了文件系统的效率。

注意，目录项这个数据结构不只是表示目录，也是可以表示文件的。

文件数据是如何存储在磁盘的呢？

磁盘读写的最小单位是扇区，扇区的大小只有 512字节，那么如果数据大于512字节时候，磁盘需要不停地移动磁头来查找数据，我们知道一般的文件很容易超过512字节那么如果把多个扇区合并为一个块，那么磁盘就可以提高效率了。那么磁头一次读取多个扇区就为一个块“block”（Linux上称为块，Windows上称为簇）。所以，文件系统把多个扇区组成了一个逻辑块，每次读写的最小单位就是逻辑块（数据块），Linux 中的逻辑块大小为 4KB，也就是一次性读写 8 个扇区，这将大大提高了磁盘的读写的效率。

文件系统记录的数据，除了其自身外，还有数据的权限信息，所有者等属性，这些信息都保存在inode中，那么谁来记录inode信息和文件系统本身的信息呢，比如说文件系统的格式，inode与data的数量呢？那么就有一个超级区块（supper block）来记录这些信息了。

superblock：记录此 filesystem 的整体信息，包括inode/block的总量、使用量、剩余量，以及文件系统的格式与相关信息等
inode：记录文件的属性信息，可以使用stat命令查看inode信息。
block：实际文件的内容，如果一个文件大于一个块时候，那么将占用多个block，但是一个块只能存放一个文件。（因为数据是由inode指向的，如果有两个文件的数据存放在同一个块中，就会乱套了）

node用来指向数据block，那么只要找到inode，再由inode找到block编号，那么实际数据就能找出来了。

索引节点是存储在硬盘上的数据，为了加速文件的访问，通常会把索引节点加载到内存中。我们不可能把超级块和索引节点区全部加载到内存，这样内存肯定撑不住，所以只有当需要使用的时候，才将其加载进内存，它们加载进内存的时机是不同的：

超级块：当文件系统挂载时进入内存；
索引节点区：当文件被访问时进入内存；

虚拟文件系统

文件系统的种类众多，而操作系统希望对用户提供一个统一的接口，于是在用户层与文件系统层引入了中间层，这个中间层就称为虚拟文件系统（Virtual File System，VFS）。VFS 定义了一组所有文件系统都支持的数据结构和标准接口，这样程序员不需要了解文件系统的工作原理，只需要了解 VFS 提供的统一接口即可。在 Linux 文件系统中，用户空间、系统调用、虚拟机文件系统、缓存、文件系统以及存储之间的关系如下图：

Linux 支持的文件系统也不少，根据存储位置的不同，可以把文件系统分为三类：

磁盘的文件系统，它是直接把数据存储在磁盘中，比如 Ext 2/3/4、XFS 等都是这类文件系统。
内存的文件系统，这类文件系统的数据不是存储在硬盘的，而是占用内存空间，我们经常用到的/proc 和 /sys 文件系统都属于这一类，读写这类文件，实际上是读写内核中相关的数据。
网络的文件系统，用来访问其他计算机主机数据的文件系统，比如 NFS、SMB 等等。

文件系统首先要先挂载到某个目录才可以正常使用，比如 Linux 系统在启动时，会把文件系统挂载到根目录。

Linux 采用为分层的体系结构，将用户接口层、文件系统实现和存储设备的驱动程序分隔开，进而兼容不同的文件系统。虚拟文件系统（Virtual File System, VFS）是 Linux 内核中的软件层，它在内核中提供了一组标准的、抽象的文件操作，允许不同的文件系统实现共存，并向用户空间程序提供统一的文件系统接口。下面这张图展示了 Linux 虚拟文件系统的整体结构：

从上图可以看出，用户空间的应用程序直接、或是通过编程语言提供的库函数间接调用内核提供的 System Call 接口（如open()、write()等）执行文件操作。System Call 接口再将应用程序的参数传递给虚拟文件系统进行处理。

每个文件系统都为 VFS 实现了一组通用接口，具体的文件系统根据自己对磁盘上数据的组织方式操作相应的数据。当应用程序操作某个文件时，VFS 会根据文件路径找到相应的挂载点，得到具体的文件系统信息，然后调用该文件系统的对应操作函数。

VFS 提供了两个针对文件系统对象的缓存 INode Cache 和 DEntry Cache，它们缓存最近使用过的文件系统对象，用来加快对 INode 和 DEntry 的访问。Linux 内核还提供了 Buffer Cache 缓冲区，用来缓存文件系统和相关块设备之间的请求，减少访问物理设备的次数，加快访问速度。Buffer Cache 以 LRU 列表的形式管理缓冲区。

VFS 的好处是实现了应用程序的文件操作与具体的文件系统的解耦，使得编程更加容易：

应用层程序只要使用 VFS 对外提供的read()、write()等接口就可以执行文件操作，不需要关心底层文件系统的实现细节；
文件系统只需要实现 VFS 接口就可以兼容 Linux，方便移植与维护；
无需关注具体的实现细节，就实现跨文件系统的文件操作。

了解 Linux 文件系统的整体结构后，下面主要分析 Linux VFS 的技术原理。由于文件系统与设备驱动的实现非常复杂，笔者也未接触过这方面的内容，因此文中不会涉及具体文件系统的实现。

VFS 结构

Linux 以一组通用对象的角度看待所有文件系统，每一级对象之间的关系如下图所示：

fd 与 file

每个进程都持有一个fd[]数组，数组里面存放的是指向file结构体的指针，同一进程的不同fd可以指向同一个file对象；

file是内核中的数据结构，表示一个被进程打开的文件，和进程相关联。当应用程序调用open()函数的时候，VFS 就会创建相应的file对象。它会保存打开文件的状态，例如文件权限、路径、偏移量等等。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L936 结构体已删减
struct file {
    struct path                   f_path;
    struct inode                  *f_inode;
    const struct file_operations  *f_op;
    unsigned int                  f_flags;
    fmode_t                       f_mode;
    loff_t                        f_pos;
    struct fown_struct            f_owner;
}

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/path.h#L8
struct path {
    struct vfsmount  *mnt;
    struct dentry    *dentry;
}

从上面的代码可以看出，文件的路径实际上是一个指向 DEntry 结构体的指针，VFS 通过 DEntry 索引到文件的位置。

除了文件偏移量f_pos是进程私有的数据外，其他的数据都来自于 INode 和 DEntry，和所有进程共享。不同进程的file对象可以指向同一个 DEntry 和 Inode，从而实现文件的共享。

DEntry 与 INode

Linux文件系统会为每个文件都分配两个数据结构，目录项（DEntry, Directory Entry）和索引节点（INode, Index Node）。

DEntry 用来保存文件路径和 INode 之间的映射，从而支持在文件系统中移动。DEntry 由 VFS 维护，所有文件系统共享，不和具体的进程关联。dentry对象从根目录“/”开始，每个dentry对象都会持有自己的子目录和文件，这样就形成了文件树。举例来说，如果要访问”/home/beihai/a.txt”文件并对他操作，系统会解析文件路径，首先从“/”根目录的dentry对象开始访问，然后找到”home/“目录，其次是“beihai/”，最后找到“a.txt”的dentry结构体，该结构体里面d_inode字段就对应着该文件。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/dcache.h#L89 结构体已删减
struct dentry {
    struct dentry *d_parent;     // 父目录
    struct qstr d_name;          // 文件名称
    struct inode *d_inode;       // 关联的 inode
    struct list_head d_child;    // 父目录中的子目录和文件
    struct list_head d_subdirs;  // 当前目录中的子目录和文件
}

每一个dentry对象都持有一个对应的inode对象，表示 Linux 中一个具体的目录项或文件。INode 包含管理文件系统中的对象所需的所有元数据，以及可以在该文件对象上执行的操作。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L628 结构体已删减
struct inode {
    umode_t                 i_mode;          // 文件权限及类型
    kuid_t                  i_uid;           // user id
    kgid_t                  i_gid;           // group id

    const struct inode_operations    *i_op;  // inode 操作函数，如 create，mkdir，lookup，rename 等
    struct super_block      *i_sb;           // 所属的 SuperBlock

    loff_t                  i_size;          // 文件大小
    struct timespec         i_atime;         // 文件最后访问时间
    struct timespec         i_mtime;         // 文件最后修改时间
    struct timespec         i_ctime;         // 文件元数据最后修改时间（包括文件名称）
    const struct file_operations    *i_fop;  // 文件操作函数，open、write 等
    void                    *i_private;      // 文件系统的私有数据
}

虚拟文件系统维护了一个 DEntry Cache 缓存，用来保存最近使用的 DEntry，加速查询操作。当调用open()函数打开一个文件时，内核会第一时间根据文件路径到 DEntry Cache 里面寻找相应的 DEntry，找到了就直接构造一个file对象并返回。如果该文件不在缓存中，那么 VFS 会根据找到的最近目录一级一级地向下加载，直到找到相应的文件。期间 VFS 会缓存所有被加载生成的dentry。

INode 存储的数据存放在磁盘上，由具体的文件系统进行组织，当需要访问一个 INode 时，会由文件系统从磁盘上加载相应的数据并构造 INode。一个 INode 可能被多个 DEntry 所关联，即相当于为某一文件创建了多个文件路径（通常是为文件建立硬链接）。

SuperBlock

SuperBlock 表示特定加载的文件系统，用于描述和维护文件系统的状态，由 VFS 定义，但里面的数据根据具体的文件系统填充。每个 SuperBlock 代表了一个具体的磁盘分区，里面包含了当前磁盘分区的信息，如文件系统类型、剩余空间等。SuperBlock 的一个重要成员是链表s_list，包含所有修改过的 INode，使用该链表很容易区分出来哪个文件被修改过，并配合内核线程将数据写回磁盘。SuperBlock 的另一个重要成员是s_op，定义了针对其 INode 的所有操作方法，例如标记、释放索引节点等一系列操作。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L1425 结构体已删减
struct super_block {
    struct list_head    s_list;               // 指向链表的指针
    dev_t               s_dev;                // 设备标识符
    unsigned long       s_blocksize;          // 以字节为单位的块大小
    loff_t              s_maxbytes;           // 文件大小上限
    struct file_system_type    *s_type;       // 文件系统类型
    const struct super_operations    *s_op;   // SuperBlock 操作函数，write_inode、put_inode 等
    const struct dquot_operations    *dq_op;  // 磁盘限额函数
    struct dentry        *s_root;             // 根目录
}

SuperBlock 是一个非常复杂的结构，通过 SuperBlock 我们可以将一个实体文件系统挂载到 Linux 上，或者对 INode 进行增删改查操作。所以一般文件系统都会在磁盘上存储多份 SuperBlock，防止数据意外损坏导致整个分区无法读取。

inode 内容

inode包含很多的文件元信息，但不包含文件名，例如：字节数、属主UserID、属组GroupID、读写执行权限、时间戳等。而文件名存放在目录当中，但Linux系统内部不使用文件名，而是使用inode号码识别文件。对于系统来说文件名只是inode号码便于识别的别称。

stat

查看inode信息

[root@localhost ~]# mkdir test
[root@localhost ~]# echo "this is test file" > test.txt
[root@localhost ~]# stat test.txt
  File: ‘test.txt’
  Size: 18              Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 33574994    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2019-08-28 19:55:05.920240744 +0800
Modify: 2019-08-28 19:55:05.920240744 +0800
Change: 2019-08-28 19:55:05.920240744 +0800
 Birth: -

三个主要的时间属性：

ctime：change time是最后一次改变文件或目录（属性）的时间，例如执行chmod，chown等命令。
atime：access time是最后一次访问文件或目录的时间。
mtime：modify time是最后一次修改文件或目录（内容）的时间。

file

查看文件类型

[root@localhost ~]# file test
test: directory
[root@localhost ~]# file test.txt
test.txt: ASCII text

inode 号码

表面上，用户通过文件名打开文件，实际上，系统内部将这个过程分为三步：

系统找到这个文件名对应的inode号码；
通过inode号码，获取inode信息；
根据inode信息，找到文件数据所在的block，并读出数据。

其实系统还要根据inode信息，看用户是否具有访问的权限，有就指向对应的数据block，没有就返回权限拒绝。

ls -i

直接查看文件i节点号，也可以通过stat查看文件inode信息查看i节点号。

[root@localhost ~]# ls -i
33574991 anaconda-ks.cfg      2086 test  33574994 test.txt

inode 大小

inode也会消耗硬盘空间，所以格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区，存放inode所包含的信息。每个inode的大小，一般是128字节或256字节。通常情况下不需要关注单个inode的大小，而是需要重点关注inode总数。inode总数在格式化的时候就确定了。

df -i

查看硬盘分区的inode总数和已使用情况

[root@localhost ~]# df -i
Filesystem               Inodes IUsed   IFree IUse% Mounted on
/dev/mapper/centos-root 8910848 26029 8884819    1% /
devtmpfs                 230602   384  230218    1% /dev
tmpfs                    233378     1  233377    1% /dev/shm
tmpfs                    233378   487  232891    1% /run
tmpfs                    233378    16  233362    1% /sys/fs/cgroup
/dev/sda1                524288   328  523960    1% /boot
tmpfs                    233378     1  233377    1% /run/user/0

文件的读写

文件系统在打开一个文件时，要做的有：

系统找到这个文件名对应的inode：在目录表中查找该文件名对应的项，由此得到该文件相对应的 inode 号
通过inode号，获取到磁盘中的inode信息，其中最重要的内容是磁盘地址表
通过inode信息中的磁盘地址表，文件系统把分散存放的文件物理块连接成文件的逻辑结构。在磁盘地址表中有 13 个块号，文件将以块号在磁盘地址表中出现的顺序依次读取相应的块。找到文件数据所在的block，读出数据。

根据以上流程，我们可以发现，inode应该是有一个专门的存储区域的，以方便系统快速查找。事实上，一块磁盘创建的时候，操作系统自动将硬盘分成两个区域：存放文件数据的数据区，与存放inode信息的inode区（inode table）。

每个inode的大小一般是128B或者256B。inode节点的总数，在格式化时就给定，一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中，每个inode节点的大小为128字节，每1KB就设置一个inode，那么inode table的大小就会达到128MB，占整块硬盘的12.8%。

也就是说，每个分区的inode总数从格式化之后就固定了，因此有可能会出现存储空间没有占满，但因为小文件太多而耗尽了inode的情况。这个时候就只能清除inode占用高的文件或者目录或修改inode数量了，当然，inode的调整需要重新格式化磁盘，需要确保数据已经得到有效备份后，再进行此操作。

这时候又产生了新的问题：文件创建时要为文件分配哪一个inode号呢？即如何保证分配的inode号没有被占用？
既然是”是否被占用”的问题，使用位图是最佳方案，像bmap记录block的占用情况一样。标识inode号是否被分配的位图称为inodemap简称为imap。这时要为一个文件分配inode号只需扫描imap即可知道哪一个inode号是空闲的。

(位图法就是bitmap的缩写。所谓bitmap，就是用每一位来存放某种状态，适用于大规模数据，但数据状态又不是很多的情况。)
类似bmap块位图一样，inode号是预先规划好的。inode号分配后，文件删除也会释放inode号。分配和释放的inode号，像是在一个地图上挖掉一块，用完再补回来一样。
imap存在着和bmap和inode table一样需要解决的问题：如果文件系统比较大，imap本身就会很大，每次存储文件都要进行扫描，会导致效率不够高。同样，优化的方式是将文件系统占用的block划分成块组，每个块组有自己的imap范围，以减少检索时间。

利用df -i命令可以查看inode数量方面的信息

文件的操作

系统对文件的操作会可能影响inode：

复制：创建一个包含全部数据与新inode号的新文件
移动：在同一磁盘下移动时，所在目录改变，node号与实际数据存储的块的位置都不会变化。跨磁盘移动当然会删除本磁盘的数据并创建一条新的数据在另一块磁盘中。
硬链接：同一个inode号代表的文件有多个文件名，即可以用不同的文件名访问同一份数据，但是它们指向的inode编号是相同的，并且文件元数据中链接数会增加。不可以对目录创建硬链接。
软链接：软链接的本质是一个链接文件，其中存储的了对另一个文件的指针。所以对一个文件创建软链接，inode号不相同，创建软链接文件的链接数不会增加。可以对目录创建软链接。
删除：当删除文件时，会先检查inode中的链接数。如果链接数大于1，就只会删掉一个硬链接，不影响数据。如果链接数等于1，那么这个inode就会被释放掉，对应的inode指向的块也会被标记为空闲的（数据不会被置零，所以硬盘数据被误删除后，若没有新数据写入可恢复）。如果是软链接，原文件被删除后链接文件就变成了悬挂链接（dangling link），无法正常访问了。

利用inode还可以删除一些文件名中有转义字符或控制字符的文件，最典型的就是开头为减号-的文件。这种无法直接用rm命令来搞，就可以先查出它们的inode编号再删除： find ./ -inum 10086 -exec rm {} \

特有现象

由于inode号码与文件名分离，导致一些Unix/Linux系统具备以下几种特有的现象。

文件名包含特殊字符，可能无法正常删除。这时直接删除inode，能够起到删除文件的作用； find ./* -inum 节点号 -delete
移动文件或重命名文件，只是改变文件名，不影响inode号码；
打开一个文件以后，系统就以inode号码来识别这个文件，不再考虑文件名。

这种情况使得软件更新变得简单，可以在不关闭软件的情况下进行更新，不需要重启。因为系统通过inode号码，识别运行中的文件，不通过文件名。更新的时候，新版文件以同样的文件名，生成一个新的inode，不会影响到运行中的文件。等到下一次运行这个软件的时候，文件名就自动指向新版文件，旧版文件的inode则被回收。

inode 耗尽故障

由于硬盘分区的inode总数在格式化后就已经固定，而每个文件必须有一个inode，因此就有可能发生inode节点用光，但硬盘空间还剩不少，却无法创建新文件。同时这也是一种攻击的方式，所以一些公用的文件系统就要做磁盘限额，以防止影响到系统的正常运行。至于修复，很简单，只要找出哪些大量占用i节点的文件删除就可以了。

硬链接与软连接

Linux系统中有一种比较特殊的文件称之为链接（link）。通俗地说，链接就是从一个文件指向另外一个文件的路径。linux中链接分为俩种，硬链接和软链接。简单来说，硬链接相当于源文件和链接文件在磁盘和内存中共享一个inode，因此，链接文件和源文件有不同的dentry，因此，这个特性决定了硬链接无法跨越文件系统，而且我们无法为目录创建硬链接。软链接和硬链接不同，首先软链接可以跨越文件系统，其次，链接文件和源文件有着不同的inode和dentry，因此，两个文件的属性和内容也截然不同，软链接文件的文件内容是源文件的文件名。

硬链接是多个目录项中的「索引节点」指向一个文件，也就是指向同一个 inode，但是 inode 是不可能跨越文件系统的，每个文件系统都有各自的 inode 数据结构和列表，所以硬链接是不可用于跨文件系统的。由于多个目录项都是指向一个 inode，那么只有删除文件的所有硬链接以及源文件时，系统才会彻底删除该文件。

软链接相当于重新创建一个文件，这个文件有独立的 inode，但是这个文件的内容是另外一个文件的路径，所以访问软链接的时候，实际上相当于访问到了另外一个文件，所以软链接是可以跨文件系统的，甚至目标文件被删除了，链接文件还是在的，只不过指向的文件找不到了而已。

软硬链接实现的原理不同
- 硬链接是建立一个目录项，包含文件名和文件的inode，但inode是原来文件的inode号，并不建立其所对应得数据。所以硬链接并不占用inode。
- 软连接也创建一个目录项，也包含文件名和文件的inode，但它的inode指向的并不是原来文件名所指向的数据的inode，而是新建一个inode，并建立数据，数据指向的是原来文件名，所以原来文件名的字符数，即为软连接所占字节数
软硬链接所能创建的目标有区别
- 因为每个分区各有一套不同的inode表，所以硬链接不能跨分区创建而软连接可以,因为软连接指向的书文件名。
硬链接不能指向目录
- 如果说目录有硬链接那么可能引入死循环，但是你可能会疑问软连接也会陷入循环啊，答案当然不是，因为软连接是存在自己的数据的，可以查看自己的文件属性，既然可以判断出来软连接，那么自然不会陷入循环，并且系统在连续遇到8个符号连接后就停止遍历。但是硬链接可就不行了，因为他的inode号一致，所以就判断不出是硬链接，所以就会陷入死循环了。

参考链接：

排查 K8S Pod 被 OOM 的思路及建议

Fri, 21 Jan 2022 22:15:48 CST

K8S + 容器的云原生生态，改变了服务的交付方式，自愈能力和自动扩缩等功能简直不要太好用。

有好的地方咱要夸，不好的地方咱也要说，真正的业务是部署于容器内部，而容器之外，又有一逻辑层 Pod 。

对于容器和 K8S 不怎么熟悉的人，一旦程序发生了问题，排查问题就是个头疼的问题。

这两天一直在排查一个 Pod OOM 的问题，花了不少的时间，感觉有必要写下来，帮助自己梳理的同时，也能给其他人一些思路。

1. 问题描述

事情的主角是 kubevirt 的一个开源项目叫 cdi，它的用途是在虚拟机启动之前将虚拟机的镜像导入到系统盘中。

在使用过程中，我们发现 cdi 在导入数据时会占用大量的内存空间。

而 cdi-controller 在创建 cdi-importer 的 pod 时，默认限定其最高只能使用 600M 的内存，到最后呢，pod 就发生了 OOMKilled。

  [root@master01 ~]# kubectl get po
NAME                               READY   STATUS      RESTARTS   AGE
importer-wbm-vda          0/1     OOMKilled   1          76s

经过测试，cdi-importer 的 limits.memory 要设置 6 个 G 才比较保险。

我们一致都对 cdi-importer 要占用 6G 内存表示费解，想找下原因，看看有没有优化的空间。

2. 思路一：内存泄露

我第一时间想到的是，有没有可能是代码问题导致发生了内存泄露？

当即使用 ps aux 和 top -p [pid] 工具去查看进程的 rss，发现程序本身的内存占用并不高，最多才 50M。

和 limits.memory=600M 相比，差得有点大，按道理是不可能出现 OOM 的，怎么回事呢？难道 top 和 ps 的数据不准？

正常检查 Go 程序的内在泄露，会使用 pprof 工具，不如我再用 pprof 去分析一下内存吧，做个双向验证吧

在程序入口处加一如下代码后

  import _  "net/http/pprof"

func main() {
    go func() {
        log.Println(http.ListenAndServe("localhost:35526", nil))
    }()
    // more code...
}

再次使用 bazel 进行编译，制作镜像，创建 pod

然后通过 kubectl top pod xxx 观察内存的变化，在将到达最大值的时候，调用如下命令开启一个 pprof 的交互式界面

  go tool pprof  http://ip:port/debug/pprof/heap

输入 top 就可以看到占用内存前 10 的函数调用，可以看到程序占用的总内存也才8M 而已，占用最高的函数也才 4M

到这边，已经基本可以确定程序本身没有发生所猜想的内存泄漏。

3. 思路二：查看 OOM 日志

发生了 oom ，不如看看 oom 的日志，看看能不能发现点什么？

通过 dmesg 打印出 oom 的相关日志

  [580237.375615] memory: usage 585936kB, limit 585936kB, failcnt 75129
[580237.375616] memory+swap: usage 585936kB, limit 9007199254740988kB, failcnt 0
[580237.375618] kmem: usage 24148kB, limit 9007199254740988kB, failcnt 0
[580237.375618] Memory cgroup stats for /kubepods/burstable/pod6b212546-f5dd-4fdf-bcc7-72a686638102:

[580237.375639] [ pid ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[580237.375949] [17998]     0 17998      242        1    28672        0          -998 pause
[580237.375955] [18524]     0 18524   675338     5758   499712        0           999 cdi-importer
[580237.375963] [ 3422]     0  3422   191966     4380   327680        0           999 qemu-img
[580237.375966] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ea887b1c9c5c8e734ac798fedd2bf5d39c0b7ce5ad961027dfc1ca138a23a2e8,mems_allowed=0-1,oom_memcg=/kubepods/burstable/pod6b212546-f5dd-4fdf-bcc7-72a686638102,task_memcg=/kubepods/burstable/pod6b212546-f5dd-4fdf-bcc7-72a686638102/ea887b1c9c5c8e734ac798fedd2bf5d39c0b7ce5ad961027dfc1ca138a23a2e8,task=cdi-importer,pid=18524,uid=0
[580237.376066] Memory cgroup out of memory: Killed process 18524 (cdi-importer) total-vm:2701352kB, anon-rss:23032kB, file-rss:0kB, shmem-rss:0kB, UID:0
[580237.466313] oom_reaper: reaped process 18524 (cdi-importer), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

日志的最开始处，打印了内存的限制为 585936 kb，而当前已使用 585936kb，这么看确实是不够了。

但到底哪里不够用了呢？

从后面的日志 cdi-importer 的 rss 才 23032kB，23 M 而已，应该还剩 500 多 M 啊，怎么就说我不够了？

这下真的麻了，一个问号还没有解决，脑子里又蹦出来新的问号。

4. 思路三：缓存做崇

通过不断的 Google 搜索，我查到了 kubectl top 得到的内存使用数据原来是这么计算的

  memory.usage_in_bytes-total_inactive_file

从这个公式可以看出， kubectl top 得到的内存使用数据原来是包含 cache 的。

到这里，我相信很多人会认为 k8s 这样的计算是不准确的，rss 才是进程真正使用的内存吧。

起初，我也是这么觉得的，直到我翻看了 k8s 关于这块的 issue 已经存在很多年了，一直到至今还没有解决，出于对 k8s 开发团队的信任，我选择相信这种计算方式是“正确的”，全球顶尖的开发团队会放任一个 bug 存在如此之久？

可就算是正确的又怎样呢？问题仍然摆在这里，并没有一丝一毫的进展。

就在我一筹莫展的时候，前面的 cache 让我有一点灵感。

在 OOM 后，我特地去查看了该容器的 cgroup 文件，发现在 memory.meminfo 里的 free 已经小于 1M 了，而相反的 cached 的值却几乎等于容器的最高内存限制。

突然之间，我感觉到曙光就在眼前，有可能还真的是 cache 占用了内存才导致的 OOM

回想一下，正常的 cache 可以提高磁盘数据的读写数据，在读的时候，会拷贝一份文件数据放到内存中，这部分是可回收的，一旦程序内存不足了，会回收部分 cache 的空间，保证程序的正常运行。

可见读文件的缓存，不会影响内存的申请，更别说 OOM，但在写的时候，情况就不一样了

在写的时候，由于进程处理数据的速度，可能会远大于数据落盘的速度，所以为提高格式转化和数据导入的速度，一般会先将转化好的数据存入缓存中，存入缓存后，进程可以立马 return 回去继续下一堆数据的处理，不用傻傻地等待数据全写入磁盘。

而存在于缓存之中的数据，则由操作系统同步写入磁盘，这样一来，数据落盘就变成了一个异步的过程，大大提高了写入的速度。

大腿一拍，这不就有可能会出问题吗？

如果 qemu-img 处理数据的速度远大于 cache 存入磁盘的速度，就会出现内存不足啦。

问题好像发现了，可该如何验证呢？

去查看了一下 qemu-img 的参数，发现有一个 -t 的参数可以指定 cache mode，有如下 5 种选择：

writeback/unsafe：app —-qemu write—-> host page cache — os flush —> disk cache — hw flush —> disk
none: app — qemu write—-> disk write cache —- hw flush —> disk
writethrough: app — qemu write—-> host page cache, disk
directsync: app — qemu write —> disk

通过阅读 cdi-importer 代码，可以看到它使用的是 writeback，即先将转化好的数据写入缓存中，提高速度。

然后我也发现了 directsync 这个选项，就是不使用缓存，直接将数据写入磁盘，这正是我想要的啊。

重新改了下 cdi 的代码，编译，制作镜像，创建 pod，还真的是再也没有出现 OOM ，到现在问题全部解决了，真的爽啊~

5. 总结一下

由于是第一次处理 OOM，因此这个排查的过程，花了不少的时间，不过归根结底还是我对基础的不牢固导致的。

在此之前，我潜意识里以为只有进程实际占用的内存才是 oom 的依据，没有想到缓存分为两种：读缓存和写缓存，读缓存是可随时回收的内存空间，不会引起内存问题，但写缓存，是不能随时回收的内存空间，只有将数据存入磁盘后，内在才能回收，这部分是有可能会引起内存问题的。

对标 VS Code，JetBrains 的下一代 IDE ：Fleet

Mon, 29 Nov 2021 23:00:08 CST

昨天（11月29日）， JetBrains 网站上出现了一个全新的 IDE — Fleet

它是谁呢？这软件的风格，怎么看都不像 JB 的亲儿子。。

不过，我很负责任地告诉，这就是 JetBrains 的下一代 IDE ，妥妥的亲儿子。

目前 Fleet 还处于开发阶段，还没有开放下载使用，如果你想尝鲜，可以通过这个链接（https://www.jetbrains.com/fleet/preview/）填写一下表格申请。

看到这个消息，我就赶紧去申请了，但何时会通过，官方表示也不清楚。

虽然还无法使用，不过可以从官网上已经能 get 到一些关于 Fleet 的信息。

Fleet 声称是从头开始构建的，拥有全新的架构和用户界面。但我不得不说，你的界面真的很像 VS Code（这口锅你是背定了），虽然比 VS Code 会好看一点。

虽然 Fleet 定位轻量级编辑器，但该有的东西，它一样也没落下：

智能补全
重构
导航
调试

以及 IDE 中一直存在的所有功能它都有，更重要的是，一键即可使用所有这些功能。

过去使用 JetBrains 的产品，通常是会多少种语言，就安装多少个 JetBrains IDE，如今你再也不用为你的内存和硬盘担心了，Fleet 和 VS Code 一样，适用于多种流行的编程语言。

除了一些常规的功能和需求之外，Fleet 也给我们带来了一些惊喜。

第一个惊喜

Fleet 是分布式的，它支持如下场景

协作开发：多个客户在同一个开发环境中工作并相互交互。
远程/云 IDE：托管在其他地方的开发环境，例如远程机器、集群或云。
多目标文件系统：开发和运行一个涉及多台机器或容器的项目，例如，一个基于微服务的应用程序。

第二个惊喜

Space 提供了编排支持，可从源仓库轻松启动远程服务器实例，支持使用 Dockerfile 进行自定义。

第三个惊喜

Fleet 全方位支持团队协作，同团队的人可以同时开发同一个项目，编辑同一个文件或者不同文件，运行测试、访问终端以及执行协作 IDE 所期望的其他功能。

JetBrains 是一家伟大的公司，做为一位开发者，可以没用过它的产品，但不可能没听过它的大名。

它们家的产品（比如 PyCharm，Goland ），经常拿来和 VS Code 做比较。

他们两者的关系有点像 Django 和 Flask，JetBrains 开箱即用，不用太多的配置就可以直接上手，这就导致了 PyCharm 非常重，一些配置不太给力的电脑，可能会内存不够用，而相反， VS Code 则非常轻量，需要你自行安装一些插件才能用得顺手。

JetBrains 做为 IDE 专业户，对开发工具的理解非常到位，做出来的产品做了比较重之外，很少有其他槽点，因此我可以完全相信 JetBrains 的产品能力和开发能力。

希望，我可以同时卸载 PyCharm Goland Clion 的这一天，能早一点到来…

Draw.io 15.8.4 - 免费开源的绘图软件

Wed, 24 Nov 2021 22:15:39 CST

简介

draw.io desktop是一款非常好用的在线流程图绘制工具，允许用户能够快速、自由的创建简单的图标、流程图、网页模版构架图、框架图等，并可通过浏览器Chrome插件就可以快速创建想要的效果图，适用于商务、工程、电气、网络设计、软件设计等诸多领域的专业绘图。

截图

下载

博客下载

使用zimg搭建图片服务器

Sat, 20 Nov 2021 08:30:23 CST

一般的大型网站都会将图片存放在专门的服务器，这样可以很好的提升网站的性能。比较简单的方式是采用云厂商提供的服务，比如七牛云、又拍云等。今天要介绍的是一款开源的实现方案zing。

zimg简介

zimg是一套国人针对图片处理服务器而设计开发的开源程序，目的是解决图片服务中如下三个问题：

大流量：对于一些中小型网站来说，流量问题就是成本问题，图片相对于文本来说流量增加了一个数量级，省下的每一个字节都是白花花的银子。所以凡是涉及到图片的互联网应用，都应该统筹规划，降低流量节约开支。
高并发：高并发的问题在用户量较低时几乎不会出现，但是一旦用户攀升，或者遇到热点事件，比如网站被人上传了一张爆炸性的新闻图片，短时间内将会涌入大量的浏览请求，如果架构设计得不好，又没有紧急应对方案，很可能导致大量的等待、更多的页面刷新和更多请求的死循环。总的来说，就是要把图片服务的性能做得足够好。
海量存储：Facebook用户上传图片上亿张，总容量超过了nPB，这样的数量级是一般企业无法承受的。虽然很难做出一个可以跟Facebook比肩的应用，但是从架构设计的角度来说，良好的拓展方案还是要有的。需要提前设计出最合适的海量图片数据存储方案和操作方便的拓容方案，以应对将来不断增长的业务需求。

以上三个问题，其实也是相互制约和钳制的，比如要想降低流量，就需要大量的计算，导致请求处理时间延长，系统单位时间内的处理能力下降；再比如为了存储更多的图片，必然要在查找上消耗资源，同样也会降低处理能力。所以，图片服务虽然看起来业务简单，实际做起来也不是一件小事。

zimg的定位：

zimg是图像存储和处理服务器。您可以使用URL参数从zimg获得压缩和缩放的图像。
zimg的并发I/O，分布式存储和及时处理能力非常出色。您不再需要在图像服务器中使用nginx。在基准测试中，zimg可以在高并发级别上每秒处理3000个以上的图像下载任务和每秒90000个以上的HTTP回显请求。性能高于PHP或其他图像处理服务器。
用于中小型的图床服务

以下是zimg支持的功能：

所有图片默认返回质量为75%，JPEG格式的压缩图片，这样肉眼无法识辨，但是体积减小
获取宽度为x，被等比例缩放的图片
获取旋转后的图片
获取指定区域固定大小的图片
获取特定尺寸的图片，由于与原图比例不同，尽可能展示最多的图片内容，缩放之后多余的部分需要裁掉
获取特定尺寸的图片，要展示图片所有内容，因此图片会被拉伸到新的比例而变形
获取特定尺寸的图片，但是不需要缩放，只用展示图片核心内容即可
获取按指定百分比缩放的图片
获取指定压缩比的图片
获取去除颜色的图片
获取指定格式的图片
获取图片信息
删除指定图片
以上这些功能的提供，仅需要一个url+特定的参数，通过get方式就可以完成。

zimg的设计思路

想要在展现图片这件事情上有最好的表现，首先需要从整体业务中将图片服务部分分离出来。使用单独的域名和建立独立的图片服务器有很多好处，比如：

CDN分流。如果你有注意的话，热门网站的图片地址都有特殊的域名，比如微博的是sinaimg.cn，人人的是fmn.xnpic.com等等，域名不同可以在CDN解析的层面就做到非常明显的优化效果。
浏览器并发连接数限制。一般来说，浏览器加载HTML资源时会建立很多的连接，并行地下载资源。不同的浏览器对同一主机的并发连接数限制是不同的。如果把图片服务器独立出来，就不会占用掉对主站连接数的名额，一定程度上提升了网站的性能。
浏览器缓存。现在的浏览器都具有缓存功能，但是由于cookie的存在，大部分浏览器不会缓存带有cookie的请求，导致的结果是大量的图片请求无法命中，只能重新下载。独立域名的图片服务器，可以很大程度上缓解此问题。

图片服务器被独立出来之后，会面临两个选择，主流的方案是前端采用Nginx，中间是PHP或者自己开发的模块，后端是物理存储；比较特别一些的，比如Facebook，他们把图片的请求处理和存储合并成一体，叫做haystack，这样做的好处是，haystack只会处理与图片相关的请求，剥离了普通http服务器繁杂的功能，更加轻量高效，同时也使部署和运维难度降低。zimg采用的是与Facebook相似的策略，将图片处理的大权收归自己所有，绝大部分事情都由自己处理，除非特别必要，最小程度地引入第三方模块。

zimg的架构设计

为了极致的性能表现，zimg全部采用C语言开发，总体上分为三个层次，前端http处理层，中间图片处理层和后端的存储层。下图为zimg架构设计图：

http处理层引入基于libevent的libevhtp库，专门处理基本http请求。
图片处理层采用imagemagick库。
存储层采用memcached缓存加直接读写硬盘的方案，后期可能会引入TFS4等。

为了避免数据库带来的性能瓶颈，zimg不引入结构化数据库，图片的查找全部采用哈希来解决。事实上图片服务器的设计，是一个在I/O与CPU运算之间的博弈过程，最好的策略当然是继续拆：CPU敏感的http和图片处理层部署于运算能力更强的机器上，内存敏感的cache层部署于内存更大的机器上，I/O敏感的物理存储层则放在配备SSD的机器上，但并不是所有人都能负担得起这么奢侈的配置。zimg折中成本和业务需求，目前只需要部署在一台服务器上。由于不同服务器硬件不同，I/O和CPU运算速度差异很大，很难一棒子定死。zimg所选择的思路是，尽量减少I/O，将压力放在CPU上，事实证明这样的思路基本没错，在硬盘性能很差的机器上效果更加明显；即使以后SSD全面普及，CPU的运算能力也会相应提升，总体来说zimg的方案也不会太失衡。

zimg的代码实现

虽然zimg在二进制实体上没有分模块，上面已经提到了原因，现阶段面向中小型的服务，单机部署即可，但是代码上是分离的。

main.c

main.c是程序的入口，主要功能是处理启动参数，部分参数功能如下：

-p [port] 监听端口号，默认4869
-t [thread_num] 线程数，默认4，请调整为具体服务器的CPU核心数
-k [max_keepalive_num] 最高保持连接数，默认1，不启用长连接，0为启用
-l 启用log，会带来很大的性能损失，自行斟酌是否开启
-M [memcached_ip] 启用缓存的连接IP
-m [memcached_port] 启用缓存的连接端口
-b [backlog_num] 每个线程的最大连接数，默认1024，酌情设置

zhttpd.c

zhttpd.c是解析http请求的部分，分为GET和POST两大部分，GET请求会根据请求的URL参数去寻找图片并转给图片处理层处理，最后将结果返回给用户；POST接收上传请求然后将图片存入计算好的路径中。为了实现zimg的总体设计愿景，zhttpd承担了很大部分的工作，也有一些关键点，下面捡重点的说一下：

在zimg中图片的唯一Key值就是该图片的MD5，这样既可以隐藏路径，又能减少前端（指zimg前面的部分，可能是你的应用服务器）和zimg本身的存储压力，是避免引入结构化存储部分的关键，所以所有GET请求都是基于MD5拼接而成的。假如你的网站某个地方需要展示一张图片，这个图片原图的大小是1000*1000，但是你想要展示的地方只有300*300，你会怎么做呢？一般还是依靠CSS来进行控制，但是这样的话就会造成很多流量的浪费。为此，zimg提供了图片裁剪功能，你所需要做的就是在图片URL后面加上w=300&h=300（width和height）即可。
在图片上传部分，如果我们的图片服务器前端采用Nginx，上传功能用PHP实现，需要写的代码很少，但是性能很差。首先PHP接收到Nginx传过来的请求后，会根据http协议（RFC1867）分离出其中的二进制文件，存储在一个临时目录里，等我们在PHP代码里使用$_FILES[“upfile”][tmp_name]获取到文件后计算MD5再存储到指定目录，在这个过程中有一次读文件一次写文件是多余的，其实最好的情况是我们拿到http请求中的二进制文件（最好在内存里），直接计算MD5然后存储。于是自己去阅读了PHP的源代码，自己实现了POST文件的解析，让http层直接和存储层连在了一起，提高了上传图片的性能。除了POST请求这个例子，zimg代码中有多处都体现了这种“减少磁盘I/O，尽量在内存中读写”和“避免内存复制”的思想，一点点的积累，最终将会带来优秀的表现。

zimg.c

zimg.c是调用imagemagick处理图片的部分，现阶段zimg服务于存储量在TB级别的单机图片服务器，所以存储路径采用2级子目录的方案。由于Linux同目录下的子目录数最好不要超过2000个，再加上MD5的值本身就是32位十六进制数，zimg就采取了一种非常取巧的方式：根据MD5的前六位进行哈希，1-3位转换为十六进制数后除以4，范围正好落在1024以内，以这个数作为第一级子目录；4-6位同样处理，作为第二级子目录；二级子目录下是以MD5命名的文件夹，每个MD5文件夹内存储图片的原图和其他根据需要存储的版本，假设一个图片平均占用空间200KB，一台zimg服务器支持的总容量就可以计算出来了：1024 * 1024 * 1024 * 200KB = 200TB

除了路径规划，zimg另一大功能就是压缩图片。从用户角度来说，zimg返回来的图片只要看起来跟原图差不多就行了，如果确实需要原图，也可以通过将所有参数置空的方式来获得。基于这样的条件，zimg.c对于所有转换的图片都进行了压缩，压缩之后肉眼几乎无法分辨，但是体积将减少67.05%。具体的处理方式为：

图片裁剪时使用LanczosFilter滤镜；
以75%的压缩率进行压缩；
去除图片的Exif信息；
转换为JPEG格式。

经过这样的处理之后可以很大程度的减少流量，实现设计目标。

zcache.c

zcache.c是引入memcached缓存的部分，引入缓存是很重要的，尤其是图片量级上升之后。在zimg中缓存被作为一个很重要的功能，几乎所有zimg.c中的查找部分都会先去检查缓存是否存在。比如：我想要a（代表某MD5）图片裁剪为100*100之后再灰白化的版本，那么过程是先去找a&w=100&h=100&g=1的缓存是否存在，不存在的话去找这个文件是否存在（这个请求所对应的文件名为 a/100*100pg），还不存在就去找这个分辨率的彩色图缓存是否存在，若依然不存在就去找彩色图文件是否存在（对应的文件名为 a/100*100p），若还是没有，那就去查询原图的缓，原图缓存依然未命中的话，只能打开原图文件了，然后开始裁剪，灰白化，然后返回给用户并存入缓存中。

可以看出，上面过程中如果某个环节命中缓存，就会相应地减少I/O或图片处理的运算次数。众所周知内存和硬盘的读写速度差距是巨大的，那么这样的设计对于热点图片抗压将会十分重要。

除了上述核心代码以外就是一些支持性的代码了，比如log部分，md5计算部分，util部分等。

zimg的部署安装（centos 7）

安装依赖库:

sudo yum install -y  wget openssl-devel cmake libevent-devel libjpeg-devel giflib-devel libpng-devel libwebp-devel ImageMagick-devel libmemcached-devel 
sudo yum install -y glibc-headers gcc-c++
sudo yum install -y build-essential nasm

安装依赖：

# openssl
mkdir /usr/local/zimg/openssl
cd /usr/local/zimg/openssl
wget http://www.openssl.org/source/openssl-1.0.1i.tar.gz
tar zxvf openssl-1.0.1i.tar.gz
cd openssl-1.0.1i
./config shared --prefix=/usr/local --openssldir=/usr/ssl
make && make install

# cmake
mkdir /usr/local/zimg/cmake
cd /usr/local/zimg/cmake
wget http://www.cmake.org/files/v3.0/cmake-3.0.1.tar.gz
tar xzvf cmake-3.0.1.tar.gz 
cd cmake-3.0.1
./bootstrap --prefix=/usr/local 
make && make install

# libevent
mkdir /usr/local/zimg/libevent
cd /usr/local/zimg/libevent
wget http://cloud.github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz
tar zxvf libevent-2.0.21-stable.tar.gz
cd libevent-2.0.21-stable
./configure --prefix=/usr/local 
make && make install

# libjpeg-turbo
mkdir /usr/local/zimg/libjpeg-turbo
cd /usr/local/zimg/libjpeg-turbo
wget https://downloads.sourceforge.net/project/libjpeg-turbo/1.3.1/libjpeg-turbo-1.3.1.tar.gz
tar zxvf libjpeg-turbo-1.3.1.tar.gz
cd libjpeg-turbo-1.3.1
./configure --prefix=/usr/local --with-jpeg8
make && make install

# webp
mkdir /usr/local/zimg/webp
cd /usr/local/zimg/
wget http://downloads.webmproject.org/releases/webp/libwebp-0.4.1.tar.gz
tar zxvf libwebp-0.4.1.tar.gz
cd libwebp-0.4.1
./configure
make
sudo make install

# jpegsrc
mkdir /usr/local/zimg/jpegsrc
cd /usr/local/zimg/
wget http://www.ijg.org/files/jpegsrc.v8b.tar.gz
tar -xf  jpegsrc.v8b.tar.gz
cd jpeg-8b
./configure --prefix=/usr/local --enable-shared --enable-static
make && make install

# imageMagic
mkdir /usr/local/zimg/imageMagick
cd /usr/local/zimg/
wget http://www.imagemagick.org/download/ImageMagick.tar.gz
tar zxvf ImageMagick.tar.gz
cd ImageMagick-6.9.1-10
./configure  --prefix=/usr/local 
make && make install

# libmemcached
wget https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz
tar zxvf libmemcached-1.0.18.tar.gz
cd libmemcached-1.0.18
./configure -prefix=/usr/local 
make &&　make install

可选的插件：

# memcached
wget http://www.memcached.org/files/memcached-1.4.19.tar.gz
tar zxvf memcached-1.4.19.tar.gz
cd memcached-1.4.19
./configure --prefix=/usr/local
make
make install

# beansdb
git clone https://github.com/douban/beansdb
cd beansdb
./configure --prefix=/usr/local
make

# benseye
git clone git@github.com:douban/beanseye.git
cd beanseye
make

# SSDB
wget --no-check-certificate https://github.com/ideawu/ssdb/archive/master.zip
unzip master
cd ssdb-master
make

# twemproxy
git clone git@github.com:twitter/twemproxy.git
cd twemproxy
autoreconf -fvi
./configure --enable-debug=log
make
src/nutcracker -h

构建zimg

cd /usr/local
#git clone https://github.com/buaazp/zimg -b master --depth=1
cd zimg   
make

安装成功后：

cd /usr/local/zimg/bin
./zimg conf/zimg.lua

打开http://localhost:4869看是否安装成功。

如果嫌手动安装太麻烦,就直接使用docker镜像

# 拉取zimg镜像
$ docker pull iknow0612/zimg
# 启动zimg容器
$ docker run -it -d -p 4869:4869 -v /data/zimg/:/zimg/bin/img --name my_zimg iknow0612/zimg sh app.sh

可以自己基于zimg再封装图片服务。

参考链接：

如何用 Python 发送告警通知到微信？

Sat, 06 Nov 2021 22:54:11 CST

大家好，我是明哥。

最近当上了阿里云的推广大使，带了 200 名读者一起免费领取了阿里云的服务器，每个人都说『真香』。

组织第一期活动，其实还是有不少的问题，主要流程上的问题。

为了让整个流程更加自动化，操作更加流畅，我利用公众号的开发能力，将整个过程集成到公众号消息的自助查询。

其中有一步就是确认用户的购买资格，只要在我的公众号后台回复对应的阿里云ID 我这边就会去查询阿里云后台的关联数据，但阿里云的 cookie 数个小时就会失效，这样一来就有点尴尬，后台的爬虫失效了参与的读者还在一直查，一直查，查到的都是未关联的数据。

这时候实时告警就显得非常重要，常见的告警方式有：邮件，电话，短信，微信。

短信和电话，通常是收费的（有不收费的，可以分享一下），而邮件又不是那么及时，因此最后我选择微信通知。

这里说的微信，是企业微信，而我之前用注册过个体户的执照，因此可以很轻松就可以注册自己的企业微信。

1. 新建应用

登陆网页版企业微信 (https://work.weixin.qq.com/)，点击 应用管理 -> 应用 -> 创建应用

上传应用的 logo，输入应用名称，再选择可见范围，成功创建一个告警应用

2. 获取Secret

使用 Python 发送告警请求，其实就只使用到两个接口

获取 Token ： https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid={corpid}&corpsecret={secret}
发送请求： https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token={token}

可以看到，最重要的是 corpid 和 secret:

corpid：唯一标识你的企业
secret：应用级的密钥，有了程序才知道你要发送该企业的哪个应用

corpid 可以通过 我的企业 -> 企业信息 获取

而 secret 获取相对麻烦一点，点击前面创建应用，点击查看 secret

然后再点击发送就会发送到你的企业微信上

最后将 corpid 和 secret 填入下面的常量中。

  import json
import datetime
import requests

CORP_ID = ""
SECRET = ""

class WeChatPub:
    s = requests.session()

    def __init__(self):
        self.token = self.get_token()

    def get_token(self):
        url = f"https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid={CORP_ID}&corpsecret={SECRET}"
        rep = self.s.get(url)
        if rep.status_code != 200:
            print("request failed.")
            return
        return json.loads(rep.content)['access_token']


    def send_msg(self, content):
        url = "https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=" + self.token
        header = {
            "Content-Type": "application/json"
        }
        form_data = {
            "touser": "@all",
            "toparty": " PartyID1 | PartyID2 ",
            "totag": " TagID1 | TagID2 ",
            "msgtype": "textcard",
            "agentid": 1000002,
            "textcard": {
                "title": "服务异常告警",
                "description": content,
                "url": "URL",
                "btntxt": "更多"
            },
            "safe": 0
        }
        rep = self.s.post(url, data=json.dumps(form_data).encode('utf-8'), headers=header)
        if rep.status_code != 200:
            print("request failed.")
            return
        return json.loads(rep.content)

然后就可以通过 send_msg 函数发送消息了。

  wechat = WeChatPub()
now = datetime.datetime.now()
timenow = now.strftime('%Y年%m月%d日 %H:%M:%S')
wechat.send_msg(f"<div class=\"gray\">{timenow}</div> <div class=\"normal\">阿里云 cookie 已失效</div><div class=\"highlight\">请尽快更换新的 cookie</div>")

只要你的企业微信没有关闭通知的权限，那你的手机立马就会弹出这个告警信息。

简单几步就对接了企业微信，实现了手机的实时告警功能，推荐有企业微信的同学使用。

当然一定有更多，更好用的实现方法，我只是我选择了其中一种，大家有不错的思路也可以分享在评论区。

HTTP抓包工具之Charles

Tue, 02 Nov 2021 09:20:20 CST

Charles简介

Charles是一个HTTP代理服务器，当浏览器连接Charles的代理访问互联网时，Charles可以监控浏览器发送和接收的所有数据。它允许一个开发者查看所有连接互联网的HTTP通信，这些包括request, response和HTTP headers （包含cookies与caching信息）。

Charles主要功能：

支持SSL代理。可以截取分析SSL的请求。
支持流量控制。可以模拟慢速网络以及等待时间（latency）较长的请求。
支持AJAX调试。可以自动将json或xml数据格式化，方便查看。
支持AMF调试。可以将Flash Remoting 或 Flex Remoting信息格式化，方便查看。
支持重发网络请求，方便后端调试。
支持修改网络请求参数。
支持网络请求的截获并动态修改。
检查HTML，CSS和RSS内容是否符合W3C标准。

以上介绍了Charles的主要功能，个人在使用过程中主要用的是抓取HTTP和HTTPS请求。特别是HTTPS的请求，抓取起来还是有一些麻烦，特此记录。

Charles 抓包原理

市面上绝大多数的抓包软件，背后的原理都是中间人攻击（Man-in-the-middle attack，缩写：MITM）。

维基百科是这样定义 MITM 的：中间人攻击在密码学和计算机安全领域中是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

上面的定义写的很清晰，下图中结合箭头方向就能看懂 HTTP Packets 的流向：

Charles的使用

Charles的安装过程是比较简单，只需到官网下载安装即可。比较困难的是HTTPS请求的配置。

Windows下HTTPS请求抓包

1、配置SSL支持。点击【Proxy】–>【SSL Proxying Settings…】，在弹出选项卡中，勾选【Enable SSL Proxying】点击【add】，在Host输入【*】表示接收任何主机，在Prot输入【*】表示任何端口，最后点击【ok】保存。

2、安装证书。点击【Help】–>【SSL Proxying】–>【Install Charles Root Certificate】，按照引导流程安装证书。

完成后打开IE进行测试：出现证书错误！

打开Chrome测试：

打开Edge测试：

都被安全拦截了，装了证书都不起作用。

解决方案：安装Firefox！

安装完毕后在开启Charles时，使用Firefox打开，http://chls.pro/ssl，弹出如下页面：

选择保存文件后按确定。文件默认保存到下载文件夹。

打开Firefox【设置】–>【隐私与安全】–>【证书】–>【查看证书】

使用【证书管理器】–>【证书办法机构】–>【导入】进行导入操作。

iOS下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机自带浏览器Safari中输入chls.pro，完成后需要进入【设置】安装描述文件。安装完毕后，如果是iOS 10 以后需要进入【设置】–>【通用】–>【关于本机】–>【证书信任设置】，开启证书。

Android下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机默认浏览器中输入chls.pro，下载downloadfile.crt文件，然后在【我的下载】中进行打开，按引导进行安装。

[译]strace的10个命令

Fri, 30 Apr 2021 18:34:01 CST

strace是一个在类Unix操作系统如Linux上做debugging和trouble shooting的超级好用的工具。它可以捕获和记录进程的所有系统调用，以及这个进程接收的所有信号。

原文: 10 Strace Commands for Troubleshooting and Debugging Linux Processes

如果你的操作系统还没有安装strace，你可以运行下面的命令进行安装：

     1
     2
     3

     $ sudo apt install strace	#Debian/Ubuntu 
     # yum install strace		#RHEL/CentOS
     # dnf install strace		#Fedora 22+

如果一个程序崩溃或以一种出乎意料的方式运行，您可以通过它的系统调用来获得在执行过程中到底发生了什么的线索。我们将在后面看到，系统调用可以分为不同的事件：与进程管理相关的事件、以文件为参数的事件、涉及网络、内存映射、信号、IPC以及与文件描述符相关的系统调用。

可以使用strace运行程序/命令，也可以使用 -p选项将PID传递给它，如下面示例所示。

追踪Linux系统调用

你可以通过运行下面的命令，追踪 df命令的系统调用。

     $ strace df -h
     execve("/bin/df", ["df", "-h"], [/* 50 vars */]) = 0
     brk(NULL)                               = 0x136e000
     access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
     mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82f78fd000
     access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
     open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     fstat(3, {st_mode=S_IFREG|0644, st_size=147662, ...}) = 0
     mmap(NULL, 147662, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f82f78d8000
     close(3)                                = 0
     access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
     open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
     read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
     fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
     mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f82f7310000
     ...

从上面的输出结果，我们可以看到几种类型的系统调用，比如

1	open("/etc/ld.so.cache", O_RDONLY\|O_CLOEXEC) = 3

其中

open: 系统调用的类型
(“/etc/ld.so.cache”, O_RDONLY|O_CLOEXEC) : 系统调用的参数
3: 系统调用的返回结果

下面是df命令执行的时候write系统调用信息:

     mmap(NULL, 26258, PROT_READ, MAP_SHARED, 3, 0) = 0x7f82f78f5000
     close(3)                                = 0
     fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
     write(1, "Filesystem      Size  Used Avail"..., 49Filesystem      Size  Used Avail Use% Mounted on
     ) = 49
     write(1, "udev            3.9G     0  3.9G"..., 43udev            3.9G     0  3.9G   0% /dev
     ) = 43
     write(1, "tmpfs           788M  9.6M  779M"..., 43tmpfs           788M  9.6M  779M   2% /run
     ) = 43
     write(1, "/dev/sda10      324G  252G   56G"..., 40/dev/sda10      324G  252G   56G  82% /
     ) = 40
     write(1, "tmpfs           3.9G  104M  3.8G"..., 47tmpfs           3.9G  104M  3.8G   3% /dev/shm
     ) = 47
     write(1, "tmpfs           5.0M  4.0K  5.0M"..., 48tmpfs           5.0M  4.0K  5.0M   1% /run/lock
     ) = 48
     write(1, "tmpfs           3.9G     0  3.9G"..., 53tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
     ) = 53
     write(1, "cgmfs           100K     0  100K"..., 56cgmfs           100K     0  100K   0% /run/cgmanager/fs
     ) = 56
     write(1, "tmpfs           788M   36K  788M"..., 53tmpfs           788M   36K  788M   1% /run/user/1000
     ) = 53
     close(1)                                = 0
     close(2)                                = 0
     exit_group(0)                           = ?
     +++ exited with 0 +++

根据进程PID进行追踪

如果一个进程已经在运行，你可以通过它的pid进行追踪，它会显示追踪后这个进程的系统调用，使用 CTRL+C退出。

     $ sudo strace -p 3569
     strace: Process 3569 attached
     restart_syscall(<... resuming interrupted poll ...>) = 1
     recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"U\2\24\300!\247\330\0\3\24\4\0\20\0\0\0\0\0\0\24\24\24\24\24\0\0\3\37%\2\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
     recvmsg(4, 0x7ffee4dbf870, 0)           = -1 EAGAIN (Resource temporarily unavailable)
     recvmsg(4, 0x7ffee4dbf850, 0)           = -1 EAGAIN (Resource temporarily unavailable)
     poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, -1) = 1 ([{fd=31, revents=POLLIN}])
     read(31, "\372", 1)                     = 1
     recvmsg(4, 0x7ffee4dbf850, 0)           = -1 EAGAIN (Resource temporarily unavailable)
     poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, 0) = 1 ([{fd=31, revents=POLLIN}])
     read(31, "\372", 1)                     = 1
     recvmsg(4, 0x7ffee4dbf850, 0)           = -1 EAGAIN (Resource temporarily unavailable)
     poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, 0) = 0 (Timeout)
     mprotect(0x207faa20000, 8192, PROT_READ|PROT_WRITE) = 0
     mprotect(0x207faa20000, 8192, PROT_READ|PROT_EXEC) = 0
     mprotect(0x207faa21000, 4096, PROT_READ|PROT_WRITE) = 0
     mprotect(0x207faa21000, 4096, PROT_READ|PROT_EXEC) = 0
     ...

得到进程的汇总信息

使用 -c参数，可以得到追踪的每一种系统调用的耗时、次数和失败数，如下所示：

     $ sudo strace -c -p 3569
     
     strace: Process 3569 attached
     
     ^Cstrace: Process 3569 detached
     % time     seconds  usecs/call     calls    errors syscall
     ------ ----------- ----------- --------- --------- ----------------
      99.73    0.016000           8      1971           poll
       0.16    0.000025           0       509        75 futex
       0.06    0.000010           0      1985      1966 recvmsg
       0.06    0.000009           0      2336           mprotect
       0.00    0.000000           0       478           read
       0.00    0.000000           0        13           write
       0.00    0.000000           0        29           mmap
       0.00    0.000000           0         9           munmap
       0.00    0.000000           0        18           writev
       0.00    0.000000           0       351           madvise
       0.00    0.000000           0         1           restart_syscall
     ------ ----------- ----------- --------- --------- ----------------
     100.00    0.016044                  7700      2041 total

打印指令指针

-i可以显示每一次系统调用的时候的指令指针。

     $ sudo strace -i df -h
     [00007f0d7534c777] execve("/bin/df", ["df", "-h"], [/* 17 vars */]) = 0
     [00007faf9cafa4b9] brk(NULL)            = 0x12f0000
     [00007faf9cafb387] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
     [00007faf9cafb47a] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7faf9cd03000
     [00007faf9cafb387] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
     [00007faf9cafb327] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     [00007faf9cafb2b4] fstat(3, {st_mode=S_IFREG|0644, st_size=147662, ...}) = 0
     [00007faf9cafb47a] mmap(NULL, 147662, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7faf9ccde000
     [00007faf9cafb427] close(3)             = 0
     [00007faf9cafb387] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
     [00007faf9cafb327] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
     [00007faf9cafb347] read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
     [00007faf9cafb2b4] fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
     [00007faf9cafb47a] mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7faf9c716000
     [00007faf9cafb517] mprotect(0x7faf9c8d6000, 2097152, PROT_NONE) = 0
     ...

显示每一次调用的时间

-t参数可以显示时间戳。

     $ sudo strace -t df -h
     15:19:25 execve("/bin/df", ["df", "-h"], [/* 17 vars */]) = 0
     15:19:25 brk(NULL)                      = 0x234c000
     15:19:25 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
     15:19:25 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8c7f1d9000
     15:19:25 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
     15:19:25 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     15:19:25 fstat(3, {st_mode=S_IFREG|0644, st_size=147662, ...}) = 0
     15:19:25 mmap(NULL, 147662, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8c7f1b4000
     15:19:25 close(3)                       = 0
     15:19:25 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
     15:19:25 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
     15:19:25 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
     15:19:25 fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
     15:19:25 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8c7ebec000
     15:19:25 mprotect(0x7f8c7edac000, 2097152, PROT_NONE) = 0
     ...

显示系统调用的耗时

-T参数可以显示系统调用的耗时时间。

     $ sudo strace -T df -h
     
     execve("/bin/df", ["df", "-h"], [/* 17 vars */]) = 0 <0.000287>
     brk(NULL)                               = 0xeca000 <0.000035>
     access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000028>
     mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9aff2b1000 <0.000020>
     access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory) <0.000019>
     open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 <0.000022>
     fstat(3, {st_mode=S_IFREG|0644, st_size=147662, ...}) = 0 <0.000015>
     mmap(NULL, 147662, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9aff28c000 <0.000019>
     close(3)                                = 0 <0.000014>
     ...

只追踪特定的系统调用

下面的命令中, trace=write是使用一个特定的表达式做筛选，只追踪特定的系统调用。表达式可以是signal, abbrev, verbose, raw, read 和 write等几种类型。

     $ sudo strace -e trace=write df -h
     
     write(1, "Filesystem      Size  Used Avail"..., 49Filesystem      Size  Used Avail Use% Mounted on
     ) = 49
     write(1, "udev            3.9G     0  3.9G"..., 43udev            3.9G     0  3.9G   0% /dev
     ) = 43
     write(1, "tmpfs           788M  9.6M  779M"..., 43tmpfs           788M  9.6M  779M   2% /run
     ) = 43
     write(1, "/dev/sda10      324G  252G   56G"..., 40/dev/sda10      324G  252G   56G  82% /
     ) = 40
     write(1, "tmpfs           3.9G  104M  3.8G"..., 47tmpfs           3.9G  104M  3.8G   3% /dev/shm
     ) = 47
     write(1, "tmpfs           5.0M  4.0K  5.0M"..., 48tmpfs           5.0M  4.0K  5.0M   1% /run/lock
     ) = 48
     write(1, "tmpfs           3.9G     0  3.9G"..., 53tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
     ) = 53
     write(1, "cgmfs           100K     0  100K"..., 56cgmfs           100K     0  100K   0% /run/cgmanager/fs
     ) = 56
     write(1, "tmpfs           788M   28K  788M"..., 53tmpfs           788M   28K  788M   1% /run/user/1000
     ) = 53
     +++ exited with 0 +++

又比如

     1
     2
     3

     $ sudo strace -e trace=open,close df -h
     $ sudo strace -e trace=open,close,read,write df -h
     $ sudo strace -e trace=all df -h

基于特定条件的系统调用

可以针对特定类型进行追踪(process、file、memory、network、signal)等等。

针对进行管理的追踪:

     $ sudo strace -q -e trace=process df -h	
     
     execve("/bin/df", ["df", "-h"], [/* 17 vars */]) = 0
     arch_prctl(ARCH_SET_FS, 0x7fe2222ff700) = 0
     Filesystem      Size  Used Avail Use% Mounted on
     udev            3.9G     0  3.9G   0% /dev
     tmpfs           788M  9.6M  779M   2% /run
     /dev/sda10      324G  252G   56G  82% /
     tmpfs           3.9G  104M  3.8G   3% /dev/shm
     tmpfs           5.0M  4.0K  5.0M   1% /run/lock
     tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
     cgmfs           100K     0  100K   0% /run/cgmanager/fs
     tmpfs           788M   28K  788M   1% /run/user/1000
     exit_group(0)                           = ?
     +++ exited with 0 +++

针对文件系统调用的追踪：

     $ sudo strace -q  -e trace=file df -h
     
     execve("/bin/df", ["df", "-h"], [/* 17 vars */]) = 0
     access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
     access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
     open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
     open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
     open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
     open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
     ...

针对内存的追踪:

     $ sudo strace -q -e trace=memory df -h	
     
     brk(NULL)                               = 0x77a000
     mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe8f4658000
     mmap(NULL, 147662, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe8f4633000
     mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe8f406b000
     mprotect(0x7fe8f422b000, 2097152, PROT_NONE) = 0
     mmap(0x7fe8f442b000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7fe8f442b000
     mmap(0x7fe8f4431000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe8f4431000
     mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe8f4632000
     mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe8f4631000
     mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe8f4630000
     mprotect(0x7fe8f442b000, 16384, PROT_READ) = 0
     mprotect(0x616000, 4096, PROT_READ)     = 0
     mprotect(0x7fe8f465a000, 4096, PROT_READ) = 0
     munmap(0x7fe8f4633000, 147662)          = 0
     mmap(NULL, 2981280, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe8f3d93000
     brk(NULL)                               = 0x77a000
     brk(0x79b000)                           = 0x79b000
     mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe8f4657000
     mmap(NULL, 26258, PROT_READ, MAP_SHARED, 3, 0) = 0x7fe8f4650000
     Filesystem      Size  Used Avail Use% Mounted on
     udev            3.9G     0  3.9G   0% /dev
     tmpfs           788M  9.6M  779M   2% /run
     /dev/sda10      324G  252G   56G  82% /
     tmpfs           3.9G  104M  3.8G   3% /dev/shm
     tmpfs           5.0M  4.0K  5.0M   1% /run/lock
     tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
     cgmfs           100K     0  100K   0% /run/cgmanager/fs
     tmpfs           788M   28K  788M   1% /run/user/1000
     +++ exited with 0 +++

以及针对网络和信号的追踪:

1 2	$ sudo strace -e trace=network df -h $ sudo strace -e trace=signal df -h

将追踪结果写入到文件

-o参数将标准输出写入到文件:

     $ sudo strace -o df_debug.txt df -h
     
     Filesystem      Size  Used Avail Use% Mounted on
     udev            3.9G     0  3.9G   0% /dev
     tmpfs           788M  9.6M  779M   2% /run
     /dev/sda10      324G  252G   56G  82% /
     tmpfs           3.9G  104M  3.8G   3% /dev/shm
     tmpfs           5.0M  4.0K  5.0M   1% /run/lock
     tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
     cgmfs           100K     0  100K   0% /run/cgmanager/fs
     tmpfs           788M   28K  788M   1% /run/user/1000

显示strace的debug信息

-d可以显示strace的debug信息。

更多的信息参考 man strace。

其它一些参考资料:

URL Disabler 1.0 免安裝版 - 禁止瀏覽指定網站

Fri, 16 Apr 2021 00:54:00 CST

禁止瀏覽指定網站 - URL Disabler，可以輸入指定的網址讓瀏覽器無法瀏覽該網站，支援Chrome、Firefox、Edge瀏覽器，匯出匯入網址清單、設定軟體開啟密碼、讓瀏覽器無法下載檔案、指定只套用於某個瀏覽器，它不使用修改hosts檔的老方法，所以比較不容易被破解。（阿榮）（下載）官方網站：Sordum.org 軟體性質：免費軟體介面語言：英文系統需求：Windows 10/8.x/7/Vista/XP（32及64位元）關鍵字：URLDisabler, URLDisablerPortable URL Disabler is a Portable (it requires no installation) and freeware to simplify the URL blocking process for Google Chrome , Firefox

风险控制：信用评分卡模型

Wed, 27 Jan 2021 20:13:13 CST

什么是信用评分卡模型？

评分卡模型又叫做信用评分卡模型，最早由美国信用评分巨头FICO公司于20世纪60年代推出，在信用风险评估以及金融风险控制领域中广泛使用。银行利用评分卡模型对客户的信用历史数据的多个特征进行打分，得到不同等级的信用评分，从而判断客户的优质程度，据此决定是否准予授信以及授信的额度和利率。相较资深从业人员依靠自身的经验设置的专家规则，评分卡模型的使用具有很明显的优点：

判断快速：系统只需要按照评分卡逐项打分，最后通过相应的公式计算出总分，即可准确判断出是否为客户授信以及额度和利率。
客观透明：评分卡模型的标准是统一的，无论是客户还是风险审核人员，都可以通过评分卡一眼看出评分结果和评判依据。
应用范围广：由于评分卡的评分项是客观计算，其得出的分数具有广泛的参考性和适用性。例如，生活中常见的支付宝芝麻信用分，就是依据评分卡模型计算得出。

评分卡模型在银行不同的业务阶段体现的方式和功能也不一样。按照借贷用户的借贷时间，评分卡模型可以划分为以下三种：

贷前：申请评分卡（Application score card），又称为A卡
- 更准确地评估申请人的未来表现(违约率)，降低坏帐率
- 加快(自动化)审批流程, 降低营运成本
- 增加审批决策的客观性和一致性，提高客户满意度
贷中：行为评分卡（Behavior score card），又称为B卡
- 更好的客户管理策略, 提高赢利
- 减少好客户的流失
- 对可能拖欠的客户，提早预警
贷后：催收评分卡（Collection score card），又称为C卡
- 优化催收策略，提高欠帐的回收率
- 减少不必要的催收行为，降低营运成本

评分卡模型示例：

一个用户总的评分等于基准分加上对客户各个属性的评分。举个例子某客户年龄为27岁，性别为男，婚姻状况为已婚，学历为本科，月收入为10000，那么他的评分为：223+8+4+8+8+13=264

如何搭信用评分卡模型？

有了上面的评分卡示例，接下来需要考虑的是如何生成类似上面的表格：

变量特征是如何选取的？
特征的变量范围是如何进行划分的？
每个字段的分值是如何设定的？

变量选择

变量筛选的主要目的：

剔除跟目标变量不太相关的特征
消除由于线性相关的变量，避免特征冗余
减轻后期验证、部署、监控的负担
保证变量的可解释性

单变量筛选

单变量的筛选基于变量预测能力，常用方法：

基于IV值的变量筛选

WOE的取值范围是[-∞,+∞]，当分箱中好坏客户比例等于整体好坏客户比例时，WOE为0。
对于变量的一个分箱，这个分组的好坏客户比例与整体好坏客户比例相差越大，IV值越大，否则，IV值越小。
IV值的取值范围是[0,+∞)，当分箱中只包含好客户或坏客户时，IV = +∞，当分箱中好坏客户比例等于整体好坏客户比例时，IV为0。

在评分卡建模流程中，WOE（Weight of Evidence）常用于特征变换，IV（Information Value）则用来衡量特征的预测能力。

WOE（Weight of Evidence）叫做证据权重，WOE在业务中常有哪些应用呢？

处理缺失值：当数据源没有100%覆盖时，那就会存在缺失值，此时可以把null单独作为一个分箱。这点在分数据源建模时非常有用，可以有效将覆盖率哪怕只有20%的数据源利用起来。
处理异常值：当数据中存在离群点时，可以把其通过分箱离散化处理，从而提高变量的鲁棒性（抗干扰能力）。例如，age若出现200这种异常值，可分入“age > 60”这个分箱里，排除影响。
业务解释性：我们习惯于线性判断变量的作用，当x越来越大，y就越来越大。但实际x与y之间经常存在着非线性关系，此时可经过WOE变换。

$$WOE_i = ln(\frac{Bad_i}{Bad_T}/\frac{Good_i}{Good_T}) = ln(\frac{Bad_i}{Bad_T})-ln(\frac{Good_i}{Good_T})$$

IV（Information Value）是与WOE密切相关的一个指标，常用来评估变量的预测能力。因而可用来快速筛选变量。在应用实践中，其评价标准如下：

而IV的计算公式定义如下，其可认为是WOE的加权和：

$$IV_i = (\frac{Bad_i}{Bad_T}-\frac{Good_i}{Good_T}) * WOE_i$$

$$IV = \sum_{i=1}^{n}IV_i$$

基于stepwise的变量筛选

基于stepwise的变量筛选方法也是评分卡中变量筛选最常用的方法之一。具体包括三种筛选变量的方式：

前向选择forward：逐步将变量一个一个放入模型，并计算相应的指标，如果指标值符合条件，则保留，然后再放入下一个变量，直到没有符合条件的变量纳入或者所有的变量都可纳入模型。
后向选择backward：一开始将所有变量纳入模型，然后挨个移除不符合条件的变量，持续此过程，直到留下所有最优的变量为止。
逐步选择stepwise：该算法是向前选择和向后选择的结合，逐步放入最优的变量、移除最差的变量。

基于特征重要度的变量筛选

基于特征重要度的变量筛选方法是目前机器学习最热门的方法之一，其原理主要是通过随机森林和GBDT等集成模型选取特征的重要度。

基于LASSO正则化的变量筛选

L1正则化通常称为Lasso正则化，它是在代价函数上增加了一个L1范数。

随着机器学习的发展，变量选择的方法也在增加。信用风险模型中典型的变量选择方法：

更多方法请参考：机器学习之特征选择方法

变量相关性分析

常用分析方法：

变量两两相关性分析
变量的多重共线性分析

为什么要进行相关性分析？

设想建立一个具有两变量$X_1$和$X_2$的线性模型，真实模型是$Y=X_1+X_2$。如果$X_1$和$X_2$线性相关（比如说$X_1\approx 2X_2$），那么拟合模型$Y=3X_2$, $Y=2X_1-X_2$或$Y=51X_1-99X_2$的效果都一样好，理想状态下，系数权重会有无数种取法，使系数权重变得无法解释，导致变量的每个分段的得分也有无数种取法（后面我们会发现变量中不同分段的评分会用到变量的系数）。

当两个变量具有高相关性时，保留IV值大。

变量分箱

评分卡模型通过对变量进行分箱来实现变量的分段。那么什么是分箱呢？以下为分箱的定义：

对连续变量进行分段离散化
将多状态的离散变量进行合并，减少离散变量的状态数

常见的分箱类型有以下几种：

无监督分箱

等频分箱：把自变量按从小到大的顺序排列，根据自变量的个数等分为k部分，每部分作为一个分箱。
等距分箱：把自变量按从小到大的顺序排列，将自变量的取值范围分为k个等距的区间，每个区间作为一个分箱。
聚类分箱：用k-means聚类法将自变量聚为k类，但在聚类过程中需要保证分箱的有序性。

由于无监督分箱仅仅考虑了各个变量自身的数据结构，并没有考虑自变量与目标变量之间的关系，因此无监督分箱不一定会带来模型性能的提升。

有监督分箱

包括 Split 分箱和 Merge 分箱

Split 分箱是一种自上而下(即基于分裂)的数据分段方法。Split 分箱和决策树比较相似，切分点的选择指标主要有 Entropy，Gini 指数和 IV 值等。
Merge 分箱，是一种自底向上(即基于合并)的数据离散化方法。Merge 分箱常见的类型为Chimerge分箱。

ChiMerge 分箱

ChiMerge 分箱是目前最流行的分箱方式之一，其基本思想是如果两个相邻的区间具有类似的类分布，则这两个区间合并；否则，它们应保持分开。Chimerge通常采用卡方值来衡量两相邻区间的类分布情况。

ChiMerge的具体算法如下：

输入：分箱的最大区间数n
初始化

连续值按升序排列，离散值先转化为坏客户的比率，然后再按升序排列
为了减少计算量，对于状态数大于某一阈值 (建议为100) 的变量，利用等频分箱进行粗分箱
若有缺失值，则缺失值单独作为一个分箱

合并区间

计算每一对相邻区间的卡方值
将卡方值最小的一对区间合并
重复以上两个步骤，直到分箱数量不大于n

分箱后处理

对于坏客户比例为 0 或 1 的分箱进行合并 (一个分箱内不能全为好客户或者全为坏客户)。
对于分箱后某一箱样本占比超过 95% 的箱子进行删除。
检查缺失分箱的坏客户比例是否和非缺失分箱相等，如果相等，进行合并。

输出：分箱后的数据和分箱区间。

总结一下特征分箱的优势：

特征分箱可以有效处理特征中的缺失值和异常值。
特征分箱后，数据和模型会更稳定。
特征分箱可以简化逻辑回归模型，降低模型过拟合的风险，提高模型的泛化能力。
将所有特征统一变换为类别型变量。
分箱后变量才可以使用标准的评分卡格式，即对不同的分段进行评分。

为了创建一个对过度拟合具有弹性的健壮模型，每个箱应该包含来自总账户的足够数量的观察结果（大多数从业者建议的最小值为5%），如果最大箱占据了总样本量的90%以上，那么弃用该变量。

WOE编码

在风控用到的数据里，我们会用到两种变量：

Numerical Variable，数值变量。例如逾期金额，天数
Categorical Variable，类别变量。例如客户职业

在制作评分卡过程中，我们还需要把数值变量变成类别变量，例如客户年龄段，我们可以划分为[20及以下],[21-30],[31-40],[41-50],[51-60],[61-70],[70以上]七个类别，这时候我们就把数值变成了类别。这种把数值变成类别的技巧叫做分箱（binning）。

但是当把所有变量都变成类别后，这时候你也许有这个疑惑：怎么去训练一个模型呢？例如逻辑回归，只能用数值作为特征输入。怎么把类别变成数值呢？

你这时候想到的可能是one-hot encoding，但还是有问题，对于逻辑回归来说，one-hot encoding输出的矩阵太稀疏了，很难让逻辑回归有很好的效果。这时候，我们可以试试把类别或者分箱转化成响应的数值。这个分数必须和必须有这个特性：分数越大，代表这个变量给bad label的贡献度越大，这个贡献度，视运算符号不同，可以是正向，也可以是负向，但我们期望它们之间有个线性关系。这时候我们需要引入WOE编码。

在变量筛选中对WOE已经有了简单的介绍。这里以实例进行介绍：

我们观察Bad Rate 和WOE的关系，可以看到WOE越大，Bad Rate越高，也就是说，通过WOE变换，特征值不仅仅代表一个分类，还代表了这个分类的权重。

对于类别变量进行WOE编码很好理解，为什么数值变量需要在分箱以后再进行WOE编码？分箱+WOE编码主要要解决的问题是把非线性的特征转化为线性。

例如在风控场景里，我们可能用到客户的年龄做特征。我们知道肯定不是年龄越大风险越高，或者年龄越大风险越低，一定是有个年龄段的风险是比其他年龄段高些。

总结下WOE编码的优势：

可提升模型的预测效果
将自变量规范到同一尺度上
WOE能反映自变量取值的贡献情况
有利于对变量的每个分箱进行评分
转化为连续变量之后，便于分析变量与变量之间的相关性
与独热向量编码相比，可以保证变量的完整性，同时避免稀疏矩阵和维度灾难

模型训练

Logistic回归是信用评分中用于解决二元分类问题的常用技术。逻辑回归通过sigmoid函数$ y = \frac{1}{1+e^{-z}}$ 将线性回归模型$z=\boldsymbol{w}^T\boldsymbol{x}+b$产生的预测值转换为一个接近0或1的拟合值：

$$h(x)=\frac{1}{1+e^{-z}}=\frac{1}{1+e^{-(\boldsymbol{w}^T\boldsymbol{x}+b)}}$$

上式的$h(x)$可视为事件发生的概率$p(y=1|\boldsymbol{x})$，变换后得到：$\ln\frac{p}{1-p}=z=\boldsymbol{w}^T\boldsymbol{x}+b$

其中，$p/(1-p)$为比率(odds)，即违约概率与正常概率的比值。$\ln{p/(1-p)}$为logit函数，即比率的自然对数。因此，逻辑回归实际上是用比率的自然对数作为因变量的线性回归模型。

在模型拟合之前，变量选择的再一次迭代对于检查新的WOE变换变量是否仍然是良好的模型候选变量是有价值的。优选的候选变量是具有较高信息值（通常在0.1和0.5之间）的变量，与因变量具有线性关系，在所有类别中具有良好的覆盖率，具有正态分布，包含显著的总体贡献，并且与业务相关。

由逻辑回归的基本原理，我们将客户违约的概率表示为p，则正常的概率为1-p。因此，可以得到：

$$Odds = \frac{p}{1-p}$$

此时，客户违约的概率p可表示为：

$$p = \frac{Odds}{1+Odds}$$

评分卡设定的分值刻度可以通过将分值表示为比率对数的线性表达式来定义，即可表示为下式：

$$Score = A – B\log(Odds)$$

其中，A和B是常数。式中的负号可以使得违约概率越低，得分越高。通常情况下，这是分值的理想变动方向，即高分值代表低风险，低分值代表高风险。逻辑回归模型计算比率如下所示：

$$ log(Odds)=\beta _0 + \beta _1x_1+…+\beta _nx_n$$

其中，用建模参数拟合模型可以得到模型参数$\beta _0,\beta _1,…,\beta _n$。式中的常数A、B的值可以通过将两个已知或假设的分值带入计算得到。通常情况下，需要设定两个假设：

给某个特定的比率设定特定的预期分值
确定比率翻番的分数（PDO）根据以上的分析，我们首先假设比率为x的特定点的分值为P。则比率为2x的点的分值应该为P+PDO。

代入式中，可以得到如下两个等式：

$$P = A – B\log(x)$$

$$P – PDO = A – B\log(2x)$$

假设设定评分卡刻度使得比率为1:20（违约正常比）时的分值为50分，PDO为10分，代入式中求得：B=14.43，A=6.78 则分值的计算公式可表示为：

$$Score = 6.78 -14.43\log(Odds)$$

评分卡刻度参数A和B确定以后，就可以计算比率和违约概率，以及对应的分值了。通常将常数A称为补偿，常数B称为刻度。则评分卡的分值可表达为：

$$Score = A – B\{\beta _0+\beta _1x_1+…+\beta _nx_n\}$$

式中：变量$x_1,…,x_n$是出现在最终模型中的自变量，即为入模指标。由于此时所有变量都用WOE转换进行了转换，可以将这些自变量中的每一个都写$(\beta _i\omega _{ij})\delta _{ij}$的形式：

$$Score = A-B\{\beta _0+(\beta _1\omega _{11})\delta _{11}+(\beta _1\omega _{12})\delta _{12}+…+(\beta _2\omega _{21})\delta _{21}+…\}$$

式中：

$\omega _{ij}$为第i行第j个变量的WOE，为已知变量
$\beta _i$为逻辑回归方程中的系数，为已知变量
$\delta _{ij}$为二元变量，表示变量i是否取第j个值。

上式可重新表示为：

$$Score = (A-B\beta _0)-(B\beta _1\omega _{11})\delta _{11}-(B\beta _1\omega _12)\delta _{12}-…-(B\beta _x\omega _{x1}-…$$

此式即为最终评分卡公式。如果$x_1…x_n$变量取不同行并计算其WOE值，式中表示的标准评分卡格式，如表3.20所示：$(A-B\beta _0)$；由于分值分配公式中的负号，模型参数$\beta _0,\beta _1,…,\beta _n$也应该是负值；变量$x_i$的第j行的分值取决于以下三个数值：

拒绝推断

申请评分卡的模型开发过程中使用的数据实际上并不是从申请总体样本中随机选择的，而仅仅是从过去已经被接受的客户样本中选择的。因此，开发申请评分卡时将对被拒绝客户的状态进行推断并纳入模型开发数据集中，即拒绝推断过程。拒绝推断的常用方法包括：

简单赋值法：人为指定被拒绝账户的标签
- 忽略被拒绝申请
- 所有被拒申请赋值为违约标签
- 按比例赋值，使得其坏客户率是通过样本的2~5倍以上
强化法：通过外推法确定拒绝账户的标签
- 简单强化法：使用通过客户开发的模型对被拒绝客户评分，将其中低分段赋予违约标签。使得拒绝客户的坏客户率为通过的2~5倍以上
- 模糊强化法：通过模型计算得到正常和违约概率。
- 打包强化法：先用开发的评分卡对被拒客户评分，然后指定每个分值区间的违约客户数量。

模型表现

模型评估是模型构建过程的最后一步。它由三个不同的阶段组成：评估，验证和接受。

评估准确性 – 我是否构建了正确的模型？ – 是第一个要求测试模型的问题。评估的关键指标是统计测量，包括模型准确性，复杂性，错误率，模型拟合统计，变量统计，显著性值和优势比。

验证稳健性 – 我是否构建了正确的模型？ – 从分类准确性和统计评估转向排名能力和业务评估时，是下一个要问的问题。

验证度量的选择取决于模型分类器的类型。二元分类问题最常见的指标是增益图，提升图，ROC曲线和Kolmogorov-Smirnov图。ROC曲线是可视化模型性能的最常用工具。它是一个多用途工具，用于：

冠军挑战者选择最佳表现模式的方法
在看不见的数据上测试模型性能并将其与训练数据进行比较
选择最佳阈值，最大化真阳性率，同时最小化假阳性率

通过绘制灵敏度与不同阈值的误报概率（误报率）来创建ROC曲线。评估不同阈值下的性能指标是ROC曲线的理想特征。根据业务策略，不同类型的业务问题将具有不同的阈值。

ROC曲线下面积（AUC）是指示分类器预测能力的有用度量。在信用风险中，0.75或更高的AUC是行业认可的标准和模型验收的先决条件。

接受有用性 – 模型是否会被接受？ – 是最后一个问题，以便测试该模型是否对商业前景有价值。这是数据科学家必须将模型结果回放给业务并“捍卫”其模型的关键阶段。关键评估标准是模型的商业利益，因此，效益分析是呈现结果的核心部分。数据科学家应该尽一切努力以简洁的方式呈现结果，因此结果和发现很容易理解。如果不能实现这一点，可能会导致模型拒绝，从而导致项目失败。

模型一旦对齐，下一步就是将模型调整到业务所需的比例。这称为缩放。缩放作为一种测量工具，可以在不同的评分卡中提供分数的一致性和标准化。最低和最高分数值以及分数范围有助于风险解释，并应向业务部门报告。通常，业务要求是对多个评分卡使用相同的分数范围，因此它们都具有相同的风险解释。

信用风控策略

模型开发之后需要基于建模样本确定风控策略。一个好的风控策略应具备：

增加客户数量
减少风险损失
最大化利润

基于开发的评分卡，我们可以获得建模样本的审批决策表。结合审批决策表与损失或者利润目标，制定常用风控策略：

评分临界值：实现通过率、坏客户率、或利润损失率等业务目标
通过交叉决策矩阵实现风险定价，实现差异化的利率、额度等：
- 风险评分与利润损失比
- 风险评分与债务收入比
- 风险评分与流失倾向评分

一个好的模型一般应具有以下特征：

在进行数据描述时变量应该有意义。通常，某些变在特定客群的不同风险模型中重复出现。例如，信用卡行为评分卡模型中，授信使用率经常出现；申请评分卡模型中收入水平、职业和历史信贷产品拥有情况比人口统计变量重要。
变量的预测力或贡献度，应该在模型的变量之间分布。
模型中不应该包含太多变量。通常，包含的变量不超过9~20个(最优10~12个)。变量太多可能导致过拟合，变量太少往往区分度不够。
最终模型的变量应该能够确保包含稳健一致的数据，并在后续实施阶段能够准确获取。

评分卡模型搭建实战

数据来源： Give Me Some Credit比赛

数据字段说明：

列名	字段说明
SeriousDlqin2yrs	两年内是否有严重违约（好坏用户判断）
RevolvingUtilizationOfUnsecuredLines	可用信贷额度比例，信用卡和个人信用额度（不动产和汽车贷款等分期付款债务除外）的总余额除以信用额度之和
age	借款人年龄
NumberOfTime30-59DaysPastDueNotWorse	两年内35-59天逾期次数
DebtRatio	借款人负债比率（每月债务支付、赡养费、生活费之和除以月收入）
MonthlyIncome	借款人月收入
NumberOfOpenCreditLinesAndLoans	开放式信贷和贷款数量
NumberOfTimes90DaysLate	两年内90天或高于90天逾期的次数
NumberRealEstateLoansOrLines	不动产贷款或额度数量
NumberOfTime60-89DaysPastDueNotWorse	两年内60-89天逾期次数
NumberOfDependents	借款人家属数量（不包括本人在内）

探索数据

import pandas as pd
from dataprep.eda import plot
import warnings
warnings.filterwarnings('ignore')

train_data = pd.read_csv('cs-training.csv', index_col=0)
train_data.columns = ['严重违约', '可用额度比例','年龄', '35-69天逾期次数', '负债比例','月收入','普通贷款数量','高于90天逾期次数','不动产贷款数量','60-89天逾期次数','家属数量']
train_data = train_data[['年龄','家属数量','月收入','负债比例','可用额度比例','普通贷款数量','不动产贷款数量','35-69天逾期次数','60-89天逾期次数','高于90天逾期次数','严重违约']]


# 手工探索数据
print(train_data.shape)
print(train_data.info())
print(train_data.isnull().sum())
print(train_data.describe().T)
print(train_data['严重违约'].value_counts())
print(train_data['严重违约'].sum()/train_data['严重违约'].count())

# 使用EDA工具探索数据
plot(train_data)

数据预处理

1）缺失值处理

常见方法：

直接删除含有缺失值的样本
根据样本之间的相似性填补缺失值
根据变量之间的相关关系填补缺失值

存在缺失的特征：月收入、家属人数

这里假设一个人的月收入和家属人数和自身的其他个人特征有关联，这里根据变量之间的相关关系采用随机森林法填补。

from sklearn.ensemble import RandomForestRegressor

def fill_income_missing(data, to_fill):
    df = data.copy()
    columns = [*df.columns]
    columns.remove(to_fill)
    
    # 移除有缺失值的列
    columns.remove('家属数量')
    X = df.loc[:, columns]
    y = df.loc[:, to_fill]
    X_train = X.loc[df[to_fill].notnull()]
    y_train = y.loc[df[to_fill].notnull()]
    X_pred = X.loc[df[to_fill].isnull()]
    rfr = RandomForestRegressor(random_state=22, n_estimators=200, max_depth=3, n_jobs=-1)
    rfr.fit(X_train, y_train)
    y_pred = rfr.predict(X_pred).round()
    df.loc[df[to_fill].isnull(), to_fill] = y_pred
    return df

def fill_dependents_missing(data, to_fill):
    df = data.copy()
    columns = [*df.columns]
    columns.remove(to_fill)
    
    X = df.loc[:, columns]
    y = df.loc[:, to_fill]
    X_train = X.loc[df[to_fill].notnull()]
    y_train = y.loc[df[to_fill].notnull()]
    X_pred = X.loc[df[to_fill].isnull()]
    rfr = RandomForestRegressor(random_state=22, n_estimators=200, max_depth=3, n_jobs=-1)
    rfr.fit(X_train, y_train)
    y_pred = rfr.predict(X_pred).round()
    df.loc[df[to_fill].isnull(), to_fill] = y_pred
return df

train_data = fill_income_missing(train_data, '月收入')
train_data = fill_dependents_missing(train_data, '家属数量')
print(train_data.isnull().sum())

2) 异常值处理

a. 删除年龄为0的数据

train_data = train_data.loc[train_data['年龄'] > 0]

b. 去除逾期次数中的异常数据

import matplotlib.pyplot as plt

columns = ['35-69天逾期次数','60-89天逾期次数','高于90天逾期次数']
train_data.loc[:, columns].plot.box(vert=False)

train_data = train_data[(train_data['35-69天逾期次数'] < 90) & (train_data['60-89天逾期次数'] < 90)  & (train_data['高于90天逾期次数'] < 90)]

信用卡模型训练

这里直接使用 Scorecard-Bundle这个Python包进行训练。Scorecard-Bundle是一个基于Python的高级评分卡建模API，实施方便且符合Scikit-Learn的调用习惯，包含的类均遵守Scikit-Learn的fit-transform-predict习惯。Scorecard-Bundle包括基于ChiMerge的特征离散化、WOE编码、基于信息值（IV）和共线性的特征评估、基于逻辑回归的评分卡模型、以及针对二元分类任务的模型评估。

1）特征离散化（ChiMerge）

from scorecardbundle.feature_discretization import ChiMerge as cm
from scorecardbundle.feature_discretization import FeatureIntervalAdjustment as fia
from scorecardbundle.feature_encoding import WOE as woe
from scorecardbundle.feature_selection import FeatureSelection as fs
from scorecardbundle.model_training import LogisticRegressionScoreCard as lrsc
from scorecardbundle.model_evaluation import ModelEvaluation as me

X = train_data.iloc[:, :-1]
y = train_data.iloc[:, -1]

from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=0, test_size=0.25)

trans_cm = cm.ChiMerge(max_intervals=10, min_intervals=5, output_dataframe=True)
result_cm = trans_cm.fit_transform(X_train, y_train) 
print(trans_cm.boundaries_) # 每个特征的区间切分

2）特征编码（WOE）和评估（IV）

trans_woe = woe.WOE_Encoder(output_dataframe=True)
result_woe = trans_woe.fit_transform(result_cm, y_train)
print(trans_woe.iv_) # 每个特征的信息值 (iv)
print(trans_woe.result_dict_) # 每个特征的WOE字典和信息值 (iv)

3) 手动调整分箱

观察每一个特征的分布和响应率，确定分箱是否合理，如果不合理就需要人工设置边界。

col = '年龄'
fia.plot_event_dist(result_cm[col],y_train,x_rotation=60)
new_x = cm.assign_interval_str(X_train[col].values,[22, 33, 43, 53, 62, 67, 74]) # apply new interval boundaries to the feature
woe.woe_vector(new_x, y_train.values) # check the information value of the resulted feature that applied the new intervals
fia.plot_event_dist(new_x,y_train, x_label=col,x_rotation=60)

feature_list = []
result_cm[col] = new_x # great explainability and predictability. Select.
feature_list.append(col)
print(feature_list)

4) WOE编码

完成全部特征的分组检查后，再次将分组特征进行WOE编码

trans_woe = woe.WOE_Encoder(output_dataframe=True)
result_woe = trans_woe.fit_transform(result_cm[feature_list], y_train) 
print(result_woe.head())
print(trans_woe.iv_)

5) 特征选择

剔除预测力过低（通常用IV不足0.02筛选）、以及相关性过高引起共线性问题的特征。(相关性过高的阈值默认为皮尔森相关性系数大于0.6，可通过threshold_corr参数调整)

fs.selection_with_iv_corr(trans_woe, result_woe) # corr_with 列示了与该特征相关性过高的特征和相关系数

6) 模型训练

model = lrsc.LogisticRegressionScoreCard(trans_woe, PDO=-20, basePoints=100, verbose=True)
model.fit(result_woe, y_train)
print(model.woe_df_) # 从woe_df_属性中可得评分卡规则

7) 模型校验

sc_table = model.woe_df_.copy()
result = model.predict(X_train[feature_list], load_scorecard=sc_table) # Scorecard should be applied on the original feature values
result_test = model.predict(X_test[feature_list], load_scorecard=sc_table) # Scorecard should be applied on the original feature values
result.head() # if model object's verbose parameter is set to False, predict will only return Total scores

# Train
evaluation = me.BinaryTargets(y_train, result['TotalScore'])
evaluation.plot_all()
  
# Validation
evaluation = me.BinaryTargets(y_test, result_test['TotalScore'])
evaluation.plot_all()

模型相关数据：

KS指标: 用以评估模型对好、坏客户的判别区分能力，计算累计坏客户与累计好客户百分比的最大差距。KS值范围在0%-100%，判别标准如下：

KS: <20% : 差
KS: 20%-40% : 一般
KS: 41%-50% : 好
KS: 51%-75% : 非常好
KS: >75% : 过高，需要谨慎的验证模型

ROC曲线就越往左上方靠拢，它下面的面积(AUC)也就越大：

如果AUC的值达到80，那说明分类器分类非常准确
如果AUC值在60～0.80之间，那分类器有优化空间，可以通过调节参数得到更好的性能
如果AUC值小于60，那说明分类器模型效果比较差

参考链接：

快速搭建准专业直播间（含直播设备介绍）

Tue, 04 Aug 2020 18:42:27 CST

前言：相信大部分人做直播就是在自己的电脑旁边，弄个麦克风+摄像头，简单直接。但有没有想过做更专业一点的直播间呢？但又不会，而且怕太复杂成本高？本文是自ISUX团队在分享设计直播时，搭建直播间的一些心得，并没有想像中的复杂，成本也不会太高，做直播的你可以尝试一下哦。

一、直播间搭建

目标直播间的搭建设计，以及设备的选型和配置方案需要满足I♡UX AIR的节目直播以及录制需求，包括但不限于：分享类、访谈类、圆桌类等形式。 直播方式 开始直播间搭建前，先要明确以何种方式直播。目前直播方式有两种：手机直播与推流直播。手机直播操作门槛低，实时互动性强；推流直播采用摄像机直播，画面清晰稳定，虽然对设备与技术有更高的要求，但功能多样，可以切换画面，以大特写突出重点，也可以在直播过程中贴图、贴文字。 I♡UX AIR属于授课型直播，嘉宾结合PPT对用户进行内容授课，重点在于PPT也就是内容的展示，同时嘉宾的出镜不可或缺，运营上，也有在直播中贴二维码推广社群以及用户调研等需求，综合以上因素，最后我们决定采用推流直播。

搭建步骤

搭建一个直播间，需要三个方面的准备工作：摄像设备（直播系统），场地&背景布置，灯光布置。搭建周期上，建议提前两周搭建，在正式开播前至少完整测试两次流程，寻找问题，不断优化。 01 摄像设备（直播系统） 硬软件互通的信号转换本质上也是一个小型网络，本次直播包含以下几部分： 软件支持：推流软件OBS、美颜软件YY开播、直播平台看点直播。 摄像：本次直播长达两小时，对画面的清晰度也有要求。我们采用双机位进行直播制作，其中主摄：索尼HXR-NX200 支持长时间录制，副摄：索尼A7R4 镜头清晰度高，作为副机位拍摄特写。将摄像机的视频信号输出到电脑需要采集卡，我们使用了两种采集卡，分别是ACASIS hdmi高清视频采集卡，以及elgato HD60 S+，越贵的采集卡输出的视频质量以及色彩还原度越高。 导播：考虑到视频源的切换需求，同时满足多路视频源的输入，我们配备了导播电脑与多路数字导播设备。 收音：收音使用RODE 罗德wireless go无线麦克风，方便携带，使用简单。 信号系统设计思路&流程： 02 场地&背景布置 场地：我们使用的场地是南山影棚，面积约为15平方米。由于影棚日常需求排期紧张，在搭建上需要尽可能地方便快捷。在预案中我们将影棚区分为：摄制区与器材区 摄制区：嘉宾、电视、背景、装饰 器材区：摄像机、屏反、主播端电脑、导播电脑、灯光 背景：首次试播集我们主要采用静态的布景方式。由于成本较低且对场地的要求较少，操作也便捷，我们选择绒布作为布景材料。与带货直播不同，我们的直播核心在主播和PPT的展示上，为了更好地呈现主播在镜头前的效果与PPT切换的顺畅衔接，背景设置我们采用的是深色系。此外人物的阴影会印在白色背景上，但不会印在吸光的黑色绒布上，这也是我们选择深色系的原因（tips：解决阴影的办法还有一种就是背景与主体的距离要足够远，灯光尽量选择较柔和的光线）。直播过程若出现屏幕反光，对用户对主播都是不好的体验。解决屏幕反光有以下几种办法：将灯光的位置移出屏幕；选择磨砂材质的屏幕；给摄像机安装偏振镜。 直播中：为了嘉宾直播的流畅，我们会提前对好台本，控制时间。可以购买一个提词器装在镜头上，确保嘉宾大多数时间是看着镜头，又能看见台本的内容。 推流流程：首先在直播平台上获取推流地址以及密码，将其输入到推流软件中（obs），确认视频音频信号一切正常后在推流软件上点击开始推流，其次在直播平台上点击开始直播。（tips：网络建议100m以上） 03 灯光系统 主光：爱图仕300d2代 副光：爱图仕120d 轮廓光：爱图仕mini20 原因：该品牌的灯具颜色标准，没有色差，能使直播画面的观感达到最佳效果。 布光方法：三点式布光。三点式布光，又称为区域照明，有三盏灯即可，分别为主体光、辅助光与轮廓光。一般用于较小范围的场景照明，因为直播间的面积有限，三点式布光是最简单且有效的布光方式。其中爱图仕300d2代为主光，与主播呈45度角，爱图仕 120d为副光，将主播脸上的暗部打亮，主副光的光比为2：1。爱图仕mini20为轮廓光，光线打在主播的脑袋后方，为的是使黑色的头发与黑色背景分离开，从而使画面更有层次。灯光尽量使用带柔光的设备，如柔光纸、柔光箱，目的是使主体上的阴影看起来不要太重，达到美观的效果。打光切忌主光方向与摄像机的拍摄方向相同，因为这样会使画面看起来太平而没有层次。 直播间 直播画面

二、直播回顾

I♡UX AIR 是由腾讯ISUX用户体验设计部旗下原创馆举办的，面向广大设计师群体的在线直播论坛活动。I♡UX AIR采用线上直播的方式，邀请资深设计师畅谈有关设计及艺术的话题，用专业案例和系统实践，启迪设计师们的设计思维。本次我们邀请腾讯两位高级设计师为大家分享的是动画与交互设计的经验。前期准备完毕，下午7点20我们的直播正式开始。 7:20PM - 第一位分享嘉宾是腾讯ISUX高级多媒体设计师阿乐。平时我们看到的一则动画只有短短几分钟，背后却经过许多考量，耗费的时间与心血也不少。她先以PUPU蓝莓之夜和MOUSE Q宣传动画为例，详细讲解动画的制作流程。阿乐认为，一个结构清晰的分镜和故事版有助于设计师和设计师的团队迅速把握整个动画的风格/基调/节奏/时长和工作周期。在项目时间充足的情况下，许多人对排期并不是很重视，阿乐强调恰恰这一部分很重要，它能让团队明白你的策划流程。一般来说前期的文案脚本策划会用到至少一周的时间商定，这个部分商定好，进入到动画中期就不能修改了；动画中期要分阶段去总结已完成的内容，提交给项目方看；输出阶段则需要预留一些时间做好音效和各尺寸的适配。好的工具能事半功倍。针对动画制作流程、UI动效设计和团队协作，阿乐还为大家分享了许多高效实用的插件工具，既分析每款工具的优点，也讲述具体的操作方法。这一part的干货太多，屏幕外的观众笔记记到停不下来。 8:10PM - 第二位分享嘉宾是ISUX高级交互设计师歆婉。歆婉从轻聊APP出发，用长达100多页的PPT，倾囊相授自己以及团队设计这款全新社交产品的思路与方法。一般来讲，线上交友会遇到四种连接，一种是连不上的人，一种是坏的连接，一种是虚假的“好连接”，还有一种是真正的连接，而轻聊的目的是让用户找到真正的连接。如何帮助用户找到真正的连接呢？歆婉先简要介绍陌生人引力社交公式，给大家对比男女交友或恋爱的心理差异后，再讲述如何围绕公式去做平衡需求以及解决核心关键点的设计。歆婉指出，人是由两种价值组成的，生物价值和社会价值。陌生人社交男性会更关注生物价值，女性则可能比较关注社会价值。所以在设计用户的个人主页时，在生物价值和社会价值的呈现上做了一个平衡，上层用视频和照片去展示生物价值，下层则展示社会价值，包括公司学校和职位等。用户是有惰性的，在如何激励用户完善资料方面，歆婉也为大家总结了一套方法。本次的分享主题是陌生人社交，设计方法之外，歆婉的讲解里还包含和夹杂了大量的脱单小技巧，不少单身粉丝听完笑称“脱单有望”了。本文分享到这里，感谢阅读！文章来自公众号: 腾讯ISUX(https://isux.tencent.com/articles/i-love-ux-air）

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

Cloudflare 註冊最便宜網域不加價，整合免費 CDN 和 SSL 憑證

Wed, 08 Jul 2020 10:00:56 CST

Cloudflare 在 2018 年推出 Cloudflare Registrar 網域名稱註冊服務，直接加入域名註冊商，主打成本價也就是只收取向上層註冊中心、ICANN 支付的費用，沒有加價也不會有額外支出，相較於一般註冊商來說 Cloudflare 可能是市場上最便宜、最實惠的價格（畢竟它不是靠這個服務營利）。另一方面，很多註冊商會在第一年使用超便宜價格吸引使用者註冊，後續加入附加服務、隱藏價格都成為註冊網址時容易誤入的陷阱。

在此之前 Cloudflare Registrar 僅允許使用者以網域移轉（Transfer）方式將網域名稱轉入，近期注意到 Cloudflare 已經開放網域註冊功能！不過還沒有對所有帳戶開放，如果你看到如下圖網域測試版功能，點選後就能開啟註冊頁面（另一個值得一提的是 Cloudflare 終於推出繁體中文介面，當然也還在測試版）。

Cloudflare Registrar 註冊功能就和轉入網址一樣簡單，不同的是 第一年終於不用再去其他註冊商註冊、轉入，而是可以直接註冊網域並使用 Cloudflare 提供的網域名稱伺服器（DNS），享有網站加速及安全防護等功能。Cloudflare Registrar 支援非常多種網域名稱後綴（TLD），不過很可惜的是國家和地區頂級域名（ccTLD）像是 .com.tw 或 .tw 暫時還無法註冊。

接下來我就簡單示範如何在 Cloudflare Registrar 註冊網域名稱，其他我推薦的註冊商還有：

Cloudflare Registrar
https://www.cloudflare.com/zh-tw/products/registrar/

使用教學

STEP 1

登入 Cloudflare 控制台點選「網域」功能，在這裡可以管理你移轉到 Cloudflare Registrar 的所有網域名稱，像是開啟自動續費（Auto-renew）、查詢過期時間或管理 WHOIS 資訊等等。如果在側邊選單有出現「 Register」就能使用 Cloudflare 註冊網址功能，我寫這篇文章時仍在測試階段。

STEP 2

下圖就是 Cloudflare Registrar 註冊網址功能，和其他註冊商一樣只要輸入關鍵字或是想要註冊的網址後就會在搜尋結果給出相關建議。

Cloudflare Registrar 支援許多網域名稱後綴，像是近年比較新的 TLD 都能註冊，前面介紹有說到它目前缺點是 還不支援國家和地區頂級域名（ccTLD），如果你想註冊 .com.tw 之類的網址可能就要透過其他註冊商。

搜尋結果會列出可以註冊的網域名稱、價格，這個價格就是註冊時需要支付的最終價格，不會有其他額外費用。點選後方「 Purchase」就能購買特定網址，如果無法註冊會跳出錯誤訊息，回到上一個步驟重新開始。

STEP 3

在註冊時遇到的第一個畫面會顯示註冊摘要，包括要註冊的網址、時間、自動續費功能和每年註冊價格，如果你已經有在使用 Cloudflare 付費功能，會以你設定在帳戶的信用卡進行付款，在註冊時也可選擇其他付款方式。

可一次註冊多個年份就不用持續付款， 不過在 Cloudflare 註冊較長時間不會獲得優惠，建議有類似需求的朋友可以尋找看看其他註冊商的優惠券或優惠方案，可能換算下來會比 Cloudflare Registrar 更便宜划算。

STEP 4

點選右下角「繼續」到下一個頁面，需要填入註冊者相關資料，Cloudflare 提供免費的 WHOIS 隱私保護功能，預設情況下會開啟，避免其他人在 WHOIS 查到你的真實資料，在註冊時記得填寫正確的資訊，包括你的姓名、公司名稱、地址、電話和 Email，這是用來證明網域名稱擁有者的方式。

最終再次的確認註冊者資料，包括註冊網址的時間、自動續費、應付金額和付款方式，沒問題的話點選右下角「送出」就能遞送這次的網域名稱註冊申請。 要注意的是因為 Cloudflare Registrar 屬於海外刷卡、會以美元計算，信用卡部分可能會產生手續費。

STEP 5

提交註冊後會需要幾秒鐘時間進行註冊、設定網域名稱。

STEP 6

完成後網址會自動放入 Cloudflare 控制台，可以在域名設定裡調整自動續訂、DNSSEC、WHOIS 資訊變更等選項，預設情況下建議將自動續訂打開，Cloudflare 會在網址到期前一個月自動續費，以免因為過期而造成網站無法連線。

另一個好處是在 Cloudflare Registrar 註冊網址後會自動使用 Cloudflare 的 DNS 伺服器（當然使用者也可以修改為其他的伺服器），獲得 Cloudflare 各種特色功能，像是可防範惡意攻擊、網站加速或是分流等等。

值得一試的三個理由：

Cloudflare Registrar 已開放網域名稱註冊功能，目前在測試階段
支援大部分常見的網域名稱後綴（TLD），但還不支援 ccTLD
可直接整合 Cloudflare 原生 DNS、CDN 和 SSL 服務

喜歡 Cloudflare 註冊最便宜網域不加價，整合免費 CDN 和 SSL 憑證嗎？歡迎將免費資源網路社群加入書籤，以 Facebook、Twitter 或 LinkedIn 追蹤更新，獲取更多科技新知及免費資源相關介紹教學。

建议收藏！2020 年必备的几个 DevOps 工具

Thu, 11 Jun 2020 20:59:14 CST

提到 DevOps 这个词，我相信很多人一定不会陌生。作为一个热门的概念，DevOps近年来频频出现在各大技术社区和媒体的文章中。到了 2020 年，DevOps 的革命也终于成为了一个主流，DevOps 相关工具的受欢迎程度也在激增。根据 Google 趋势，「DevOps 工具」的搜索量一直在稳定增长，并且这种趋势还在持续。

DevOps 工具越来越多，了解它们以及知道在什么时候使用他们越来越重要。由于 DevOps 涵盖了整个软件开发生命周期，因此有很多工具可供选择。让我们将其大致分为以下几类：

开发和构建工具
自动化测试工具
部署工具
运行时 DevOps 工具
协作 DevOps 工具

成功且成熟地采用 DevOps 做法将始终拥有完整的渠道，其中包括适用于这五个类别的工具。确保评估您当前的工具堆栈，以确保您没有丢失 CI/CD 管道的关键部分。

开发和构建工具

这是 CI/CD 管道堆栈的基础。一切都从这里开始。该类别中最好的工具可以协调多个事件流，并可以轻松地与外部工具集成。

软件开发生命周期的这一部分中的工具分为三个子类别：

源代码控制管理（SCM）
持续集成（CI）
数据管理

2020年，推荐的SCM技术是GIT，因此我们的SCM工具必须具有出色的GIT支持。对于CI，绝对需要在临时容器化环境中运行和执行构建的能力。对于数据管理，我们需要能够对数据库架构进行更改并使它与应用程序版本保持一致。

2020年排名第一的SCM + CI工具：Gitlab和Gitlab-CI

Gitlab无疑是2020年最伟大的DevOps Lifecycle工具，它将在可预见的未来成为创新的领导者。

Gitlab的核心功能提供了一个完美的GIT存储库管理工具。它基于Web的用户界面是最冗长且易于使用的。Gitlab的免费套餐可提供您所需的一切，并且具有SaaS和On-Prem尺寸。

市场上有很多SCM工具，但是没有一种工具像Gitlab多年来所做的那样将“持续集成”直接集成到您的存储库中。称为Gitlab-CI，将.gitlab-ci.yml文件粘贴到代码库的根目录中，任何GIT事件都会根据您在此处定义的内容触发操作。他们确实是按代码进行持续集成的领导者。

主要优势：

成熟度 - 该产品自2013年以来一直投放市场，并且非常稳定并且得到了很好的支持。
开源 - Gitlab的免费版没有削减开发团队所需的核心功能。每个付费层都提供了附加功能，这些附加功能可根据组织的规模和需求带来极高的价值。
易用的 CI — 市场上没有其他工具可以像Gitlab-CI一样直接将持续集成直接嵌入到您的SCM中。使用Docker构建进行临时构建的能力提供了无忧的构建作业，并且内置的报告使调试构建失败变得容易。无需复杂的集成和业务流程就可以对多种工具进行编排。
无限集成 - Gitlab提供了每个核心DevOps类别中所需工具的轻松集成。这使开发人员和操作人员在任何环境中都可以使用一个真实的来源来获取与其应用程序相关的信息。

竞争对手:

还有其他工具在此领域也很流行，但是它们不如Gitlab。原因如下：

GitHub - GitHub一直是小型和早期开发商店的出色SaaS源代码管理系统。但是，对于需要在网络中保留其IP的大型企业，GitHub的唯一选择是.OVA不支持高可用性的虚拟机。这使其难以维护on-prem，并且只能在中型组织中运行，然后服务器本身才开始崩溃。它缺少GitHub Actions（直到最近，但仍不在本地版本中）或CI-as-Code，这意味着您始终需要带上自己的CI工具并管理该集成。最后，它比任何Gitlab定价都昂贵。
Jenkins — 尽管Jenkins已经成为持续集成工具的默认标准，但它始终缺少源代码控制元素。意味着，您将始终使用Jenkins 和 SCM工具。当像GitLab这样的工具同时提供这两种功能时，这简直是不必要的复杂。它可怕的UX使得现代Web应用程序有很多不足之处。
BitBucket/Bamboo — 我不得不说，这是一个自动失败者，考虑到您需要两种工具来完成Gitlab的一项工作。尽管BitBucket云支持Gitlab-CI / GitHub Action功能，但没有一家公司（规模超过一家初创公司）可以轻易采用它。用于本地的 BitBucket服务器甚至不支持BitBucket管道！

2020年排名第一的数据管理工具：FlywayDB

Web应用程序开发中最容易被忽视的方面是数据库的自动化需求。在应用程序的新版本中部署数据库架构更改通常是事后的想法。模式更改通常会添加或重命名列或表。如果应用程序版本与架构版本不匹配，则该应用程序可能会完全损坏。由于存在两个不同的系统，因此通过应用程序升级来协调数据库更改也可能很困难。FlyWayDB解决了所有这些问题。

主要优势：

数据库版本控制 - FlyWay允许您简单地创建数据库版本，跟踪数据库迁移以及轻松地前滚或后退架构更改，而无需某些定制解决方案。
二进制或内置 - 您可以选择在应用程序启动时或作为二进制可执行文件运行Flyway。在代码中使用此工具，以便它在启动时检查版本功能并运行适当的迁移，从而使数据库和应用程序版本保持同步。您也可以临时运行cmd行，从而在不重建整个应用程序的情况下为现有数据库提供了灵活性。

竞争对手：

这个空间中没有太多工具。但是，让我们来看几个：

LiquiBase — Liquibase是相似的，实际上，如果有人在我的组织中工作过，那么我很乐意通过FlyWay对该工具进行标准化。
Flocker - 这可能仅适用于容器化的应用程序-在容器中运行数据库非常困难，必须精心计划才能成功执行。我建议将RDS之类的服务用于数据库，而不要尝试运行存储在容器中的关键数据。

自动化测试工具

我们必须首先将自动化工具安装到测试金字塔中，从而开始对自动测试工具进行评估。测试金字塔有4层：

单元测试 - 这是所有自动化测试的基础。就数量而言，与其他类型相比，您应该拥有最多的单元测试。这些测试应由软件开发人员编写和运行，以确保应用程序的一部分（称为“单元”）符合其设计并按预期运行。
组件测试 — 组件测试的主要目的是验证测试对象的输入/输出行为。这样可以确保测试对象的功能按照所需规范正确运行。
集成测试 — 这是测试阶段，在此阶段中，各个软件模块被组合在一起并作为一个整体进行测试。
端到端测试 - 此层是不言自明的。我们正在研究从头到尾的应用程序流程，并使其表现出预期的效果。

由于单元和组件层测试仅由应用程序开发人员驱动，并且通常是特定于编程语言的，因此我们不会在DevOps空间中评估这些工具。

2020年排名第一的集成测试工具：Cucumber

Cucumber将规范和测试文档合并为一个有凝聚力的有效文档。由于它们是由Cucumber自动测试的，因此您的规格始终是最新的。如果您想开始构建Web自动化测试框架并在Web应用程序上模拟用户行为，那么带有Java和Cucumber BDD的Selenium WebDriver是在项目中学习和实现Cucumber的好方法。

主要优势：

行为驱动的开发 — Cucumber用于BDD测试，它已成为一种入门测试框架（与传统的测试驱动开发相比）。
动态文档 - 记录您所做的事情总是很痛苦。由于您的测试被定义为代码，因此Cucumber测试会自动生成文档以进行匹配以确保它们始终保持同步。
支持 - 这里有很多工具可供选择，但是当情况变得严重时，您需要工具维护者的认真支持。黄瓜拥有足够的资金和支持结构来维持该工具的未来几年。

竞争对手：

在这个领域中有许多框架和特定于技术的工具，但是只有Cucumber接近于“一刀切”的解决方案。

端到端测试工具

进行端到端测试时，有两个重点领域需要关注：

功能测试
负载测试

功能测试显然是在测试我们想要发生的事情是否实际发生。当我单击SPA上的某些页面，填写表格并单击Submit时，数据将显示在数据库中，并且屏幕显示成功！

我们还需要能够测试在相同场景下工作的x数量的用户是否可以正确处理。

如果您在这两个方面都没有进行测试，则CI / CD管道中的差距将很大。

2020年排名第一的端到端测试工具 — 功能：SoapUI Pro

由于SOAP Web服务是默认的，因此SoapUI进入API测试领域已有很长时间了。尽管我们不再构建新的SOAP服务，并且该工具的名称没有更改，但这并不意味着它没有发展。SoapUI为构建后端Web服务的自动化功能测试提供了一种出色的结构。这些可以轻松地与持续集成工具集成，并且可以作为我们的CI / CD管道的一部分运行。

主要优势：

广泛的文档 - 此工具已经存在了一段时间，因此有许多在线资源可帮助您确定如何配置负载测试。
易于使用 — 尽管有多种API测试工具可用，但拥有一个用于多种服务的接口可以使构建测试变得简单。

竞争对手：

Selenium - Selenium是该领域的另一个出色工具。如果您正在构建和运行基于Java的应用程序，则建议使用它。但是，如果您要使用多种技术来处理一个完整的Web应用程序，那么对于非Java语言的用户来说可能会有些笨拙。

2020年排名第一的端到端测试工具 — 负载测试：LoadRunner

说明：在对应用程序的各个方面进行负载测试时，只有LoadRunner才能完成。是的，这很昂贵而且入门有点困难，但是它是唯一可以执行测试的工具，可以使我作为技术架构师相信新代码将在极端压力下执行。另外，我认为现在是时候让负载运行技巧从SQA资源转移到开发团队了。

主要优势：

广泛的文档 - 该工具已经存在了一段时间，因此有许多在线资源可以帮助您确定如何配置负载测试。
协议支持 - 从ODBC到AJAX，再到HTTPS以及您的应用程序可能在某处使用的其他晦涩协议，LoadRunner支持该协议。我们要避免串接多个负载测试工具-这只会增加复杂性。

击败竞争对手：

再说一次，在这个领域中没有太多的“一刀切”的工具，因此简单的解决方案是可以在任何环境中使用任何技术将其丢弃。

部署工具

部署工具可能是应用程序开发中鲜为人知的方面。对于操作人员来说，如果不深入了解应用程序代码和功能，就很难使用部署工具。对于开发人员来说，管理代码部署是一项新的职责，因此他们对许多部署工具的经验很少。

首先，让我们将部署工具分为三个子类别：

构件管理
配置管理
部署方式

2020年排名第一的工件管理工具：Nexus

Nexus工件存储库支持几乎所有主要技术，从Java到NPM再到Docker。我们可以使用这一工具来存储我们所有可部署的工件。通过使软件包更接近构建过程，代理远程软件包管理器的能力还大大提高了我们CI配置的速度。这样做的另一个好处是，我们可以全局查看跨多个软件项目使用的所有软件包，从而锁定不安全的开源软件包，这些软件包可能是我们代码中的攻击媒介。

主要优势：

技术支持 - 该产品自2013年以来一直投放市场，并且非常稳定且得到了很好的支持。
开源 - Gitlab的免费版本没有削减开发团队需要的核心功能。每个付费层均提供附加功能，这些附加功能可带来最大价值，具体取决于组织的规模和需求。

2020年排名第一的配置管理工具：Ansible

Ansible是这个领域的领导者，原因很简单：无国籍。较早的现场配置管理工具着重于管理配置状态。如果它与所需的配置脱离同步，它将自行修复。在新的应用程序中，我们只有无状态组件。新版本的代码是新的构件，并已部署以替换现有的构件。我们拥有短暂的短暂环境。

主要优势：

无状态 - Ansible剧本是从操作员机器上运行的，并命中服务器目标。我不在乎远程对象的状态，这使得使用Packer之类的工具来构建可部署对象变得更加容易。
开源 - 和CentOS一样，Ansible也由RedHat维护。该企业及其高级支持人员可以帮助维护社区，并确保高质量，易于使用的模块。
分子测试 — 因为配置管理和其他任何东西一样都是代码，所以如果不对其进行测试，我们将无所不能。用于测试Ansible角色的分子框架可以无缝地工作，以确保我们的按代码配置质量一样高，并遵循与应用程序代码相同的CI / CD管道。
YAML — 与其他工具相比，YAML更加容易使您头脑清醒。由于配置管理对于采用DevOps的任何人来说通常都是新事物，因此这使其成为关键卖点。

竞争对手：

OpsCode Chef - 我以厨师食谱开发人员的身份开始了DevOps生涯。露比和厨师很亲密，我的心。但是，它们根本无法解决当今无状态，云原生应用程序的问题。对于更传统的遗留应用程序来说，这是一个很好的工具，但是本文将重点放在未来。
Puppet — Puppet从未成长为一个庞大的社区，特别是与Chef and Ansible相比。它非常适合配置和裸机，但不支持Web应用程序类型的配置管理。

2020年排名第一的部署工具：Terraform

Terraform解决了从网络组件到实际服务器映像定义基础架构即代码的问题。自最初发布以来，它已经走了很长一段路，并建立了庞大的插件社区和支持社区，以帮助您解决可能遇到的几乎所有部署场景。支持本地，云中或其他任何类型的环境的能力是首屈一指的。最后，最新版本在HCL中提供了许多与其他任何传统编程语言相同的逻辑功能和类，从而使开发人员可以轻松学习和学习。

主要优势：

不受云/环境影响 - Terraform利用提供的资源作为Terraform代码与与基础架构提供商进行通信所需的所有API和后端逻辑之间的接口。这意味着我可以学习一种工具，并且能够在任何地方工作。

开源 — 同样，很难敲响免费工具。社区支持是一流的。

竞争对手：

AWS CloudFormation — 即使您仅在AWS云环境中工作，您也可能会在职业生涯中继续前进，而不是去那里。将您的技能和知识整合到一个平台中可能会有风险。此外，许多新的AWS服务通常在CloudFormation中可用之前作为Terraform模块提供。

运行时DevOps工具

任何开发项目的最终目标都是在生产中运行我们的应用程序。在DevOps世界中，我们希望确保我们对环境中的任何潜在问题具有可见性，并且还希望将人工干预降至最低。选择正确的运行时工具集对于实现开发必不可少的条件至关重要。

运行时工具子类别为：

X 即服务
编排
监控方式
日志记录

2020年排名第一的X-as-a-Service工具：Amazon Web Services

亚马逊一直是云计算领域的领导者。他们也不仅止步于此-他们为开发人员提供了许多新服务，以利用它可以使您旋转。将任何技术和任何模式带到AWS上，就可以构建和运行它。与在自己的数据中心中构建，管理和维护传统硬件相比，它们的成本极其合理。免费服务层使任何人都有机会在必须做出购买决定之前进行尝试，这对于尝试以正确的方式构建应用程序而不必因成本而造成损害非常有用。

主要好处：

行业标准 - 如果您有在AWS中构建应用程序的经验，那么您基本上可以在任何地方找到工作。企业喜欢AWS，而创业公司喜欢AWS的低成本。
Free-Tier — 与其他所有功能相比，AWS的业务确实如此。让我使用该服务并查看其工作原理，然后再决定将数千美元投入可能有巨大陷阱的事物中。我从未为POC构建的任何产品都超过免费套餐限制。

竞争对手：

Azure – 自最初发布以来，Azure已经走了很长一段路，值得称赞。但是，区分自身的需求已导致其对服务的名称进行了怪异的命名，而这些服务要难一点了-到底什么是“ blob存储”？尽管.NET代码在Microsoft生态系统中效果更好，但不太可能仅将.NET用于应用程序的各个方面。
Heroku — 简而言之，除了在Heroku上的个人项目外，我什么都不会运行。透明度不高，企业没有理由将其用作平台。这对于在博客中演示某些内容非常有用，但对于实际应用程序来说，非常感谢！

2020年排名第一的编排工具：OpenShift

您可能在应用程序堆栈中的某处使用了Docker或容器。无服务器应用程序很棒，但它们不能适合所有的架构模式。在没有业务流程平台的情况下运行容器根本行不通。从安全性和工具角度来看，Core Kubernetes带来了很多需求。OpenShift是唯一拥有Kubernetes平台的平台，它具有Source2Image构建，pod中的部署自动化以及甚至可追溯性和监视功能。它可以在本地，云中或同时在两者中运行。

主要优势：

内置的安全性 - 管理K8安全性几乎需要博士学位。必须仔细考虑并考虑所有细节。默认情况下，OpenShift所采用的安全机制减少了开发人员的工作量，并为他们的应用程序提供了更安全的平台。
多合一解决方案 – 与默认不包含负载平衡工具的香草K8不同，OpenShift拥有一切。我可以使用它来托管我的容器，构建容器，运行CI / CD工具，协调外部流程，管理机密等等。尽管GUI仍然需要做更多的工作，但API优先的方法意味着一切都可以编写脚本，并且与K8的其他GUI不同，它使学习Kubernetes的基础知识变得更加简单，而无需首先获得该学位！

竞争对手：

Docker Swarm - Docker swarm尝试通过删除大量内容来简化K8。这对于较小的应用程序非常有用，但对于企业应用程序则根本不起作用。此外，AWS ECS之类的服务采用了类似的方法，但是使我可能正在与之交互的其他服务（Lambda，IAM等）的使用变得更容易。

2020年排名第一的监控工具：New Relic

New Relic的早期发行版确实做得非常好-APM监视。现在，它是一套完整的监视工具，使我可以监视服务器性能，容器性能，数据库性能，最终用户体验监视，当然还有APM监视。

主要优势：

易用性 - 我在担任系统工程师时曾使用过许多监视工具，但从未遇到过像New Relic这样易于使用的监视工具。这是一个SaaS，因此不必设置服务器组件也很不错。
端到端可见性 - 其他工具尝试监视应用程序的一个特定方面。无论是CPU利用率还是网络流量，所有这些层都可以协同工作，以使您的应用正常运行。New Relic使您能够组合所有数据以真实了解正在发生的事情。

竞争对手：

Zabbix — Zabbix是我最喜欢的监视系统，但是由于缺乏向云原生环境和APM空间发展的能力，因此使其滞后。它仍然可以很好地监视传统的服务器基础结构，仅此而已。
DataDog - 此工具过于侧重于管理生产应用程序的过程视角，而对代码本身的关注不足。在真正的DevOps团队中，有开发人员参与生产，我们无需依靠繁琐的工具来提供世界一流的支持。

2020年排名第一的测井工具：Splunk

很难反对Splunk。他们很久以来一直是日志聚合的领导者，并且他们继续做得最好。借助本地和SaaS产品，您可以在任何地方使用它。主要的缺点是，它仍然很难运行！

主要优势：

行业标准 —企业喜欢Splunk，他们也有钱为此付出代价。虽然初创企业可能难以证明其成本合理，但许多概念和技能可以转移到开源替代方案中。
可支持性 -简单地说，它可以正常工作。它具有许多默认值和即用型功能，因此您不必花费大量时间阅读文档并尝试使一些没有明确说明的内容能够正常工作。

竞争对手：

ELK Stack - ElasticSearch，LogStash和Kibana，虽然似乎总是很酷，因为它们不向您收取使用费用，但随着日志集的增长和机上越来越多的应用程序的维护，它的确变得更加困难您的工具。与使用Splunk相比，我在构建任何类型的仪表板之前花了更多的时间来设置工具。

协作DevOps工具

DevOps首先是组织内部的文化变革。虽然购买工具不会一夜之间改变文化，但无疑可以帮助培养与同事合作的新方法。

协作工具子类别为：

问题跟踪
聊天操作
文献资料

2020年排名第一的问题跟踪工具：Jira

吉拉（Jira）继续保持头把交椅，尽管在这个领域竞争日益激烈。但是，Jira内置的强大灵活性使开发团队和运营团队可以管理其项目工作和冲刺任务。使用敏捷术语的内置标准有助于缓解从传统工作方法到更精益流程的文化转变。

主要优势:

行业标准 — 同样，就像许多工具一样，Jira到处都有使用。小型团队可以使用便宜的许可证并获得所需的一切，而企业可以为任何人负担得起许可证。
集成 - 在这个领域处于领先地位并且快速增长意味着第三方工具会选择您首先构建本机集成，而它们只会增加您工具的价值，而Jira就是这种情况。我们可以与现成的列表中的所有其他工具集成，而无需进行任何定制。

竞争对手:

Trello — Trello成为免费使用的看板工具，因此迅速流行。但是，一旦事情开始扩展，并且您从数十个问题扩展到数千个问题，Trello将变得难以导航，搜索和报告。
Pivotal Tracker - 在初创公司工作期间，我非常喜欢该工具。但是，他们更多地关注产品管理，而不是技术任务。尽管从Jira进行产品管理比较困难，但是仍然可以完成此过程，而不必获取完全独立的工具。

2020年排名第一的ChatOps工具：MatterMost

说明：这可能是2020年这份清单上最大的惊喜，这是一件好事！MatterMost通过使用以前最好的工具，但引入了本地部署而获得了普及。对于企业来说，这是巨大的，因为它可以控制数据，还可以帮助与本地工具集成-我们不再需要为了新的事物而走出防火墙。

主要优势:

开源 - MatterMost的开源版本非常适合小型或大型团队。与Slack的免费层会丢失历史记录不同，您自己运行服务器意味着您拥有数据。
集成 - 因为API几乎100％基于Slack API，所以几乎所有Slacks集成都可以直接与MatterMost一起使用。

竞争对手:

Slack - 松弛很棒，但是它们已经变得如此庞大，需要开始获利。他们业务的付费阶段即将到来，并且剥夺了Slack用来免费提供的许多价值，最关键的是聊天记录。
Microsoft Teams - 尝试将Microsoft产品与非Microsoft本地产品集成-祝您好运。这就是我要说的！

2020年排名第一的文档工具：Confluence

无论使用哪种工具，都很难创建和维护高质量的技术文档。尽管最近有许多SaaS文档工具进入市场，但我很难接受将有关关键应用程序的敏感技术文档存储给第三方。我需要将数据和文档保留在本地，这就是Confluence为我所做的。

主要优势：

易于管理 - 大多数自托管工具的启动和运行可能有些复杂，并且大规模维护它们需要一些特定知识。开箱即用的Confluence服务器非常适合10个用户或10,000个用户。
插件－尽管创建具有默认融合功能的漂亮且易于浏览的文档已经很不错了，但是拥有用于几乎所有内容的插件的能力释放了Wiki的潜力。

竞争对手：

Read the docs — 非常适合开源公共代码，但永远不会考虑在这里存储关键的应用程序知识。
MarkDown — 尽管非常适合于记录有关我的代码的内容，但很难将体系结构，过程或其他类型的文档直接放入MarkDown格式中。
Jekyll — 在记录技术知识时，我并不想简单地构建一个新的静态站点，以便在每次更改时进行部署。简单的Confluence版本管理系统使内部文档的处理变得更加容易。

总结 2020 年最佳

市场上实际上有数百种DevOps工具。试图浏览应使用哪些以及何时实施它们可能会令人不知所措。遵循此简单指南，为完整的CI / CD管道选择DevOps工具堆栈。

将工具分为以下五个关键领域：

开发和构建工具
自动化测试工具
部署工具
运行时工具
协作工具

最后希望大家切记：自动化所有能自动化的事情！

部分参考链接：
1. 《Must Learn DevOps Tools for 2020》
2. 《How to create a DevOps roadmap & Treebo’s 9 month DevOps Journey》
3. 《DevOps with AWS》
4. 《 Using this Time to Optimize Your Dev Team’s Workflow》

流量分析的瑞士军刀：Zeek

Fri, 08 May 2020 16:00:18 CST

Zeek (Bro) 是一款大名鼎鼎的开源网络安全分析工具。通过 Zeek 可以监测网络流量中的可疑活动，通过 Zeek 的脚本可以实现灵活的分析功能，可是实现多种协议的开相机用的分析。本文主要是将 Zeek 结合被动扫描器的一些实践的介绍，以及 Zeek 部署的踩过的一些坑。

安装

Zeek 的安装还是比较简单的，笔者主要是在 Mac 上以及 Linux 上安装。这两个操作系统的安装方式还是比较类似的。对于 Linux 而言，需要安装一些依赖包：

  sudo yum install cmake make gcc gcc-c++ flex bison libpcap-devel openssl-devel python-devel swig zlib-devel

这里我有遇到一个问题就是可能你的 Redhat 镜像源里面没有包含 libpcap-devel，因为这个包在可选的范围内，而内网的服务器又没有互联网连接。可以通过手工下载相应版本的 libpcap 以及 libpcap-devel 即可。

Mac 上需要的依赖更少一点，首先需要确保安装了 xcode-select，如果没有安装，可以通过 xcode-select –install 来进行安装。Mac 上只需要安装依赖 cmake, swig, openssl, bison 即可，可以通过 Homebrew 来进行安装。

依赖包安装完毕之后就可以安装 Zeek，其实是可以通过包管理工具来进行安装的，不过这里我推荐使用基于源码的安装方式，安装比较简单而且还容易排查问题。从 Zeek 的 Github Release 即可下载源码包，目前我安装的是 3.0.0 版本，注意一点是，如果使用最新的版本，可能需要 7.0 以上版本的 cmake，因为需要 C++17 的语言特性。而一般镜像源默认的 cmake 版本是4+版本，所以如果你的服务器也无法上互联网，建议可以安装 3.0.0 版本。

  ./configure & make & make install

安装使用上面的命令就可以了，不过 make 的时间还是比较长的，这个取决于你机器的性能，不过一般安装还是需要半个小时到一个小时，这也是因为 C++ 编译速度比较慢的原因。

集群安装

集群安装的方式和单机的方式不太一样。之前在测试环境使用的都是单机模式，集群则可以管理多个实例，后来我也尝试了通过集群的方式来进行安装。如果需要配置集群的话，建议安装 PF_RING，PF_RING 可以加速网络包的速度。对于 Zeek 集群上的每个 worker 都是需要安装 PF_RING，但只需要在 manager 上安装 Zeek 就可以了，可以通过 zeekctl 在其它 worker 上安装 Zeek。不过需要确保可以通过 ssh 到其它 woker 机器上，可以通过公钥的形式来实现，将 manager 的公钥放到其它 worker 的 authorized_keys 中。

PF_RING 的安装步骤相对来说多了一些，但也是按照说明安装即可。和上面的单机安装方式不同的是集群安装的方式的时候，安装 Zeek 需要配置前缀。

安装 PF_RING

  tar xvzf PF_RING-5.6.2.tar.gz
cd PF_RING-5.6.2/userland/lib
./configure --prefix=/opt/pfring
make install
cd ../libpcap
./configure --prefix=/opt/pfring
make install
cd ../tcpdump-4.1.1
./configure --prefix=/opt/pfring
make install
cd ../../kernel
make
make install
modprobe pf_ring enable_tx_capture=0 min_num_slots=32768

安装 Zeek

  ./configure --with-pcap=/opt/pfring
make 
make install

确保 Zeek 正确关联到了 PF_RING 中的 libpcap 库中

  ldd /usr/local/zeek/bin/zeek | grep pcap
      libpcap.so.1 => /opt/pfring/lib/libpcap.so.1 (0x00007fa6d7d24000)

接着就是通过 PF_RING 来进行 Zeekctl 的配置，Zeek 的安装路径一般都在 /usr/local/zeek。通过 /usr/local/zeek/etc/node.cfg 来进行集群结点的配置，在集群配置中，manager, proxy 以及 worker 是必须的，如果不设置 logger，默认将 manager 作为 logger。

  [worker-1]
type=worker
host=10.0.0.50
interface=eth0
lb_method=pf_ring
lb_procs=10
pin_cpus=2,3,4,5,6,7,8,9,10,11

接下来只需要通过 zeekctl install 就会在其它实例上来进行安装了。如果安装过程中出现了问题，可以通过 zeekctl diag woker-1 来排查具体的原因。

Zeek 结合被动扫描器的玩法

上面讲的都是 Zeek 的安装，下面聊一下 Zeek 和被动扫描器的结合。被动扫描器的效果往往取决于流量的质量和数量，在我们的实际实践中，发现通过 Zeek 获取的流量占我们被动扫描器测试流量的绝大一部分。Zeek 对于 http 解析的日志都会存储在 /usr/local/zeek/logs 中。如果 Zeek 是启动状态，那么 http.log 的路径会在 /usr/local/zeel/logs/current 中，而历史日志则会被打包。如果使用 Zeek 去捕获流量的时候，日志往往会占很大的存储，所以要记得修改 Zeek 日志的存储路径，否则很容易就把系统盘塞满。

通过脚本自定义 http.log

http.log 中其实已经包含了丰富的字段，常见的一些字段如下：

  # ts          uid          orig_h        orig_p  resp_h         resp_p
1311627961.8  HSH4uV8KVJg  192.168.1.100 52303   192.150.187.43 80

不过里面还有一些信息是缺失的，比如一些 http 请求头以及 POST 请求的请求体，为了添加这些字段，可以通过自定义 Zeek 脚本来实现，Zeek 脚本的能力真的非常强大，通过脚本其实有很多更高级的玩法。

添加请求头

  @load base/protocols/http/main
module HTTP;
export {
    redef record Info += {
            header_host:    string  &log    &optional;
            header_accept:  string  &log    &optional;
            header_accept_charset:  string  &log    &optional;
            header_accept_encoding:  string  &log    &optional;
            header_accept_language:  string  &log    &optional;
            header_accept_ranges:  string  &log    &optional;
            header_authorization:  string  &log    &optional;
            header_connection:  string  &log    &optional;
            header_cookie:  string  &log    &optional;
            header_content_length:  string  &log    &optional;
            header_content_type:  string  &log    &optional;
    };
}
event http_header(c: connection, is_orig: bool, name: string, value: string) &priority=3
        {
        if ( ! c?$http )
                return;
        if ( is_orig )
                {
                if ( log_client_header_names )
                        {
                switch ( name ) {
                                case "HOST":
                                    c$http$header_host = value;
                                    break;
                                case "ACCEPT":
                                    c$http$header_accept = value;
                                    break;
                                case "ACCEPT-CHARSET":
                                    c$http$header_accept_charset = value;
                                    break;
                                case "ACCEPT-ENCODING":
                                    c$http$header_accept_encoding = value;
                                    break;
                                case "ACCEPT-LANGUAGE":
                                    c$http$header_accept_language = value;
                                    break;
                                case "ACCEPT-RANGES":
                                    c$http$header_accept_ranges = value;
                                    break;
                                case "AUTHORIZATION":
                                    c$http$header_authorization = value;
                                    break;
                                case "CONNECTION":
                                    c$http$header_connection = value;
                                    break;
                                case "COOKIE":
                                    c$http$header_cookie = value;
                                    break;
                                case "CONTENT-LENGTH":
                                    c$http$header_content_length = value;
                                    break;
                                case "CONTENT-TYPE":
                                    c$http$header_content_type = value;
                                    break;
                                }
            }
                }
        }

添加 POST 请求体

  export {
    ## The length of POST bodies to extract.
    const http_post_body_length = 200 &redef;
}
redef record HTTP::Info += {
    postdata: string &log &optional;
};
event log_post_bodies(f: fa_file, data: string)
    {
    for ( cid in f$conns )
        {
        local c: connection = f$conns[cid];
        if ( ! c$http?$postdata )
            c$http$postdata = "";
        # If we are already above the captured size here, just return.
        if ( |c$http$postdata| > http_post_body_length )
            return;
        c$http$postdata = c$http$postdata + data;
        if ( |c$http$postdata| > http_post_body_length )
            {
            c$http$postdata = c$http$postdata[0:http_post_body_length] + "...";
            }
        }
    }
event file_over_new_connection(f: fa_file, c: connection, is_orig: bool)
    {
    if ( is_orig && c?$http && c$http?$method && c$http$method == "POST" )
        {
        Files::add_analyzer(f, Files::ANALYZER_DATA_EVENT, [$stream_event=log_post_bodies]);
        }
    }

通过上述的脚本就可以添加一些请求头以及 POST 请求的请求体，完整的脚本可以参考 http-custom。脚本编写完毕，需要通过 zeekctl 部署才能生效，步骤也非常简单。

  mv http-custom /usr/local/bro/share/bro/base/protocols
echo '@load base/protocols/http-custom' >> /usr/local/bro/share/bro/site/local.bro
zeekctl deploy

对于被动扫描器，我们目前的方案是通过 Filebeat 去采集日志然后输出给 Logstash 做处理，处理完毕之后再输出到 Kafka。

Filebeat 加 Logstash 适用于多种场景，在日常的各种日志采集场景都能派上用场。通过 Logstash 可以完成日志灵活的处理，因为 Logstash 里面包含了各种丰富的插件，几乎可以完成对于日志的任何操作。比如为了保证 POST 请求体保证传输的正确性，可以通过 base64 来进行编码。通过 logstash-filter-base64 可以遍历地实现字段的编码或者解码。通过 filter 中的 mutate 插件可以增加字段或者删除字段。

  base64 {
     field => "postdata"
     action => "encode"
   }

通过这种方案还有一个优势就是我们还可以将我们的日志输出到别的地方，比如 es，这个也可以方便后续排查日志问题。

不过我在后面又发现了一种新的方案，可以通过 Zeek 的插件，将 http.log 直接输出到 Kafka，这个方案的优点主要是更高效，同时也节省了一些成本，毕竟 Logstash 需要的机器性能还是比较大的。对于这个方案主要是两个问题，第一个问题是首先需要处理好日志的格式，这样保证后续处理地便利性；第二个问题是如何将日志直接从 Zeek 输出到 Kafka。其实我是先解决了第一个问题再解决第二个问题的，因为第二个问题的处理的方式更灵活，得益于 Zeek 脚本的便利性，肯定是可以实现的。

metron-bro-plugin-kafka 是 Apache 官方的一个 Bro 的插件，不过因为 Zeek3.0.0 是可以兼容的，所以这个插件是可以使用的。这个插件有两种安装方式，一种是通过 bro-pkg (Bro 的官方包管理工具)来进行安装，另外一种则是通过手工安装。由于网络的原因，我更推荐使用手工安装的方式，我尝试通过 bro-pkg 的方式来进行安装，速度特别慢。

安装 librdkafka

  curl -L https://github.com/edenhill/librdkafka/archive/v0.11.5.tar.gz | tar xvz   
cd librdkafka-0.11.5/
./configure --enable-sasl
make
sudo make install

安装插件

  ./configure --bro-dist=$BRO_SRC
make
sudo make install

这里有一个坑就是安装文档根本就没有说 $BRO_SRC 是哪个路径，所以安装的时候总是报错，后来才弄清楚这个路径其实就是当初 Zeek 解压后的路径，即 Zeek 安装包的路径。

验证结果

  zeek -N Apache::Kafka
Apache::Kafka - Writes logs to Kafka (dynamic, version 0.3)

接着就是将 http 的日志进行处理，因为在原始的 http.log 中有还多字段是我们并不需要的。在研究了官方文档之后，可以通过 Filters 可以定义一个新的日志文件，可以拷贝其它的日志输出到新的文件，可以自定义字段，方式比较灵活。另外还可以通过 Writer 可以将日志写入到 sqlite 数据库中。不过，这里我们主要是通过插件将日志写入到 Kafka。

总结

其实 Zeek 有很多高级玩法，你完全可以将 Zeek 改造成一个 IDS 产品。Zeek 脚本的强大能力赋予其无限的可能性，比如在流量中发现 sql 注入。本文主要就是就 Zeek 的安装部署以及结合被动扫描器的一些用法的介绍。后续如果更进一步地探索，会做更多的分享。

*本文作者：madneal@平安银行应用安全团队，转载请注明来自FreeBuf.COM

XSSFORK：新一代XSS自动扫描测试工具

Thu, 26 Dec 2019 15:00:05 CST

什么是XSS漏洞呢？

XSS（Cross-site scripting）译为跨站脚本攻击，在日常的web渗透测试当中，是最常见的攻击方法之一，并占有很高的地位。它是通过对网页注入可执行代码且成功地被浏览器执行，达到攻击的目的，形成了一次有效XSS攻击，一旦攻击成功，它可以获取用户的联系人列表，然后向联系人发送虚假诈骗信息，可以删除用户的日志等等，有时候还和其他攻击方式同时实施比如SQL注入攻击服务器和数据库、Click劫持、相对链接劫持等实施钓鱼，它带来的危害是巨大的，是web安全的头号大敌。

传统的 xss 探测工具：

一般都是采用 payload in response 的方式，即在发送一次带有 payload 的 http 请求后，通过检测响应包中 payload 的完整性来判断，这种方式缺陷，很多。

0×001 前言

xssfork是一款新一代xss漏洞探测工具，其开发的目的是帮助安全从业者高效率的检测xss安全漏洞。与传统检测工具相比xssfork使用的是 webkit内核的浏览器phantomjs，其可以很好的模拟浏览器。工具分为两个部分，xssfork和xssforkapi，其中xssfork在对网站fuzz xss的时候会调用比较多的payload。话不多说，一起来研究下这款工具吧？

github地址： https://github.com/bsmali4/xssfork

0×002 环境依赖

Python 2.x

相关python库（存在于项目requestments.txt中）

0×003安装教程

git clone https://github.com/bsmali4/xssfork

python2 -m pip install -rrequestments.txt

python2 xssfork.py -h

出现以下显示，代表安装成功

0×004内置Payload

工具的开发者收集了目前流行的xss payload，丰富的一批欧（目前内置存在的payload数量为70个），payload文件存在于xssfork\thirdparty\fuzz_dic\payloads.dic文件里面

并且会添加上各种闭合的情况

0×005内置编码方式

为了进行更加智能的进行测试，作者在测试时同时加入了绕过方式，提供了四种编码方式，供大家进行使用

现阶段提供了10进制，16进制，随机大小写，关键字叠加四个脚本

[0]10hex_encode 10进制

[1]16hex_encode 16进制

[2]addkeywords 关键字叠加

[3]uppercase 随机大小写

查看命令为：python xssfork.py –list

使用编码命令为：-t 脚本名称即可

0×006 使用场景

场景1 反射型xss

操作命令如下：

  python2 xssfork.py -u "http://xssfork.codersec.net/xssdemo.php?id=23"

场景2 带大小写绕过

操作命令如下：

  python2 xssfork.py -u "http://xssfork.codersec.net/xssdemo.php?id=23" -t uppercase

场景3 dom型xss

操作命令如下：

  python2 xssfork.py -u "http://xssfork.codersec.net/xssdemo.php?id=23"

场景4 post型xss

操作命令如下：

  python2 -u "http://xssfork.codersec.net/xssdemo.php" -d "name=123"

场景5 验证cookie型xss

操作命令如下：

  python2 xssfork.py -u "http://xssfork.codersec.net/xssdemo.php?id=23" -c "user=fdsfds;pass=123"

总结

xssfork感觉还是很不错的工具，希望能够在工作中给你一些帮助，最后感谢工具作者！谢谢

*本文作者：fuckerbox，转载请注明来自FreeBuf.COM

Pfsense：免费开源的应用层防火墙

Sat, 12 Oct 2019 15:00:20 CST

前言

一个公司的安全建设需要大量的物力、人力，由于网络安全在企业没有实际利益产出，常常在企业网络安全建设中，没有足够的投入（废话，投入没有经济效益回报，为什么要投入），但是企业网络安全建设不只是针对经济效益，它更像是一种保险（等出了事情，数据丢失，被网安抓典型处理），它更是一种对主业务的辅助（信息化辅助生产，甚至代替生产），但巧妇难为无米之炊，要对企业内网形成一套完整的纵深防御体系需要许多的商业化解决方案，无奈呼信息安全部门在一些企业中就是一个背锅的角色，为了能把锅抗好。。嗯，还是最好没锅吧！毕竟真的扛不动

闲话少说，纵深防护体系的第一道就是下一代防火墙，下面是下一代防火墙的简单配置介绍：

一、说明

1.1 pfSense是什么

pfSense是基于FreeBSD的、开源中最为可靠（World’s Most Trusted Open Source Firewall）的、可与商业级防火墙一战（It has successfully replaced every big name commercial firewall youcan imagine in numerous installations around the world）的防火墙。

简单点说pfSense就是一个操作系统形式的防火墙。更多介绍见： https://www.pfsense.org/getting-started/

二、pfSense安装

整个安装过程也不是很复杂，官方安装文档见： https://www.netgate.com/docs/pfsense/install/installing-pfsense.html

在虚拟机中安装使用（操作系统）freedbs 11 进行安装

2.1下载

下载地址： https://www.pfsense.org/download/

下载镜像iso即可

2.2安装

首选创建一个虚拟机，其他的都无所谓但是系统一定要FreeBSD。

到这步后所有的选项都是直接点击下一步，虚拟机创建完成后点击编辑虚拟机配置，添加网卡

因为防火墙至少需要两块网卡，所以需要创建至少2块网卡，一个网卡作为lan口，一个网卡作为wan口（也可以多个网卡），我们留一个网卡作为wan口（NAT模式），一个作为lan口（主机模式或者自定义），登录界面配置在lan口上，网卡只要启动两块就好了。

将ISO文件配置到虚拟光驱中，开启电源

回车确认安装

选择键盘格式，默认是美国标准键盘，直接回车

选择文件系统，回车选择UFS，此步之后正式安装操作系统

直接回车选择重启完成安装

三、pfSense配置

3.1 设置pfsense接口

重启完成后会进入以下界面

不设置vlan（透明传输使用），设置wan口网卡，设置lan口网卡，最后输入Y进入系统

查看自己设置的网卡的网段le0 口因为使用dhcp直接通过即可，le1口作为lan口，必须使用le1口网卡的网段地址（主机模式下的DHCP分配期间地址）

设置接口地址，设置wan和lan的地址（只需要设置一个就可以，设置完成后需要将web界面到底是使用哪一个地址进行登录），在控制界面按 2 进入地址设置界面，设置一个lan口地址（设置为192.168.192.0/24 网段的地址），关闭dhcp（避免IP地址冲突），设置lan口为web管理口地址

设置完成后就可以登录了，通过上边14启动sshd后使用admin/pfsense也可以ssh登录操作系统

SSH账户名密码：admin/pfsense

3.2 web管理界面

访问设置为web登录的网卡地址，进行登录，默认用户名密码admin/pfsense

第一次登录后有有几步主机名、dns、时区等相关初始化向导，看着填不会就直接next

最后finish

点击finish大约30秒后进入该界面

设置完成后设置中文显示，依次点击SystemGeneral>Setup>Language，在下拉框中找到Simplified,china，选择之后点击该页面最下方的save

接下来就可以按照正常防火墙进行配置了

最后：在非常苛刻的条件下，可以使用三层路由的方式，使用各种开源的系统级防护系统，通过多个不同的主机网络将所有的设备串联起来，放置于网络的出口，以便进行内网安全防护，嗯，就是这样（说多了都是泪，都是被逼的。）

最后送上一些基础软件

vmware 15

链接： https://pan.baidu.com/s/1q0janMOCtIFbiApRfEgrfA

提取码：hqou

pfsense

链接： https://pan.baidu.com/s/10Va4z6f69FkCjpY29X0JNA

提取码：7o1w

*本文作者：寂静尘埃，转载请注明来自FreeBuf.COM

分布式向量搜索系统 Vearch

Thu, 10 Oct 2019 16:04:26 CST

Vearch 是一个分布式向量搜索系统，可以用来计算向量相似度，或用于机器学习领域，如：图像识别、视频识别或自然语言处理等各个领域。本系统基于 Faiss 实现，提供了快速的向量检索功能。提供类似 Elasticsearch 的 Restful API 可以方便地对数据及表结构进行管理查询等工作。架构

ModSecurity：一款优秀的开源WAF

Tue, 10 Sep 2019 15:00:36 CST

一、ModSecurity3.0介绍

ModSecurity是一个开源的跨平台Web应用程序防火墙（WAF）引擎，用于Apache，IIS和Nginx，由Trustwave的SpiderLabs开发。作为WAF产品，ModSecurity专门关注HTTP流量，当发出HTTP请求时，ModSecurity检查请求的所有部分，如果请求是恶意的，它会被阻止和记录。

优势：

完美兼容nginx，是nginx官方推荐的WAF

支持OWASP规则

3.0版本比老版本更新更快，更加稳定，并且得到了nginx、Inc和Trustwave等团队的积极支持

免费

ModSecurity的功能：

SQL Injection (SQLi)：阻止SQL注入

Cross Site Scripting (XSS)：阻止跨站脚本攻击

Local File Inclusion (LFI)：阻止利用本地文件包含漏洞进行攻击

Remote File Inclusione(RFI)：阻止利用远程文件包含漏洞进行攻击

Remote Code Execution (RCE)：阻止利用远程命令执行漏洞进行攻击

PHP Code Injectiod：阻止PHP代码注入

HTTP Protocol Violations：阻止违反HTTP协议的恶意访问

HTTPoxy：阻止利用远程代理感染漏洞进行攻击

Shellshock：阻止利用Shellshock漏洞进行攻击

Session Fixation：阻止利用Session会话ID不变的漏洞进行攻击

Scanner Detection：阻止黑客扫描网站

Metadata/Error Leakages：阻止源代码/错误信息泄露

Project Honey Pot Blacklist：蜜罐项目黑名单

GeoIP Country Blocking：根据判断IP地址归属地来进行IP阻断

劣势：

不支持检查响应体的规则，如果配置中包含这些规则，则会被忽略，nginx的的sub_filter指令可以用来检查状语从句：重写响应数据，OWASP中相关规则是95X。

不支持OWASP核心规则集DDoS规则REQUEST-912-DOS- PROTECTION.conf,nginx本身支持配置DDoS限制

不支持在审计日志中包含请求和响应主体

二、安装部署

测试环境：centOS7.6阿里云镜像

升级软件和内核

  yum update

安装nginx： http://nginx.org/en/linux_packages.html#mainline

     yum install yum-utils
   vim /etc/yum.repos.d/nginx.repo
   [nginx-stable]
   name=nginx stable repo
   baseurl=    http://nginx.org/packages/centos/$releasever/$basearch/
   gpgcheck=1
   enabled=1
   gpgkey=    https://nginx.org/keys/nginx_signing.key
   [nginx-mainline]
   name=nginx mainline repo
   baseurl=    http://nginx.org/packages/mainline/centos/$releasever/$basearch/
   gpgcheck=1
   enabled=0
   gpgkey=    https://nginx.org/keys/nginx_signing.key
   yum install nginx
   yum install epel-release
   yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre pcre-devel libxml2 libxml2-devel autoconf automake lmdb-devel ssdeep-devel ssdeep-libs lua-devel libmaxminddb-devel git apt-utils autoconf automake build-essential git libcurl4-openssl-dev libgeoip-dev liblmdb-dev ibpcre++-dev libtool libxml2-dev libyajl-dev pkgconf wget zlib1g-dev

报错解决：Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again

解决办法：一句话：把/etc/yum.repos.d/epel.repo，文件第3行注释去掉，把第四行注释掉，修改为

1. [epel]

2. name=Extra Packages for Enterprise Linux 6 – $basearch

3. baseurl= http://download.fedoraproject.org/pub/epel/6/$basearch

4. #mirrorlist= https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

克隆GitHub存储库:

  git clone --depth 1 -b v3/master --single-branch    https://github.com/SpiderLabs/ModSecurity

编译源代码：

     $ cd ModSecurity
   $ git submodule init
   $ git submodule update
   $ ./build.sh
   $ ./configure
   $ make
   $ make install

注意：安装中有报错fatal: No names found, cannot describe anything.是正常现象

下载用于ModSecurity的NGINX连接器：

  git clone --depth 1    https://github.com/SpiderLabs/ModSecurity-nginx.git

确定哪个版本的NGINX是运行在主机上的ModSecurity模块将加载:

     [root@guigu ModSecurity]# nginx -v
   nginx version: nginx/1.17.3

下载与安装版本对应的源代码：

     wget     http://nginx.org/download/nginx-1.17.3.tar.gz
   tar zxvf nginx-1.17.3.tar.gz

编译动态模块，复制到模块标准目录:

     cd nginx-1.17.3
   #./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
   $ make modules
   cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/
   将以下load_module指令添加到/etc/nginx/nginx.conf的main中：
   load_module modules/ngx_http_modsecurity_module.so;

确定nginx模块加载成功：

  nginx -t

三、防护效果测试

ModSecurity 3简单示例

创建Demo web应用vim /etc/nginx/nginx.conf

     server {
   listen 8085;    

location / {

    default_type text/plain;

    return 200 "Thank you for requesting ${request_uri}\n";

    }
   }

重新加载nginx:nginx -s reload

确认nginx正常工作:curl -D – http://localhost

保护Demo web应用

创建/etc/nginx/modsec文件夹：mkdir /etc/nginx/modsec

下载推荐的ModSecurity配置文件

     wget     https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
   mv modsecurity.conf-recommended modsecurity.conf

vim modsecurity.conf #在些文件中编辑以下配置

SecRuleEngine DetectionOnly

SecRuleEngine On

创建ModSecurity的主配置文件

  vim /etc/nginx/modsec/main.conf

Include the recommended configuration

  Include /etc/nginx/modsec/modsecurity.conf

A test rule

  SecRule ARGS:testparam "@contains test" "id:1234,deny,log,status:403"

报错解决：[emerg] “modsecurity_rules_file” directive Rules error.

     vim /etc/nginx/modsec/modsecurity.conf
   #SecUnicodeMapFile unicode.mapping 20127

配置nginx反向代理，vim /etc/nginx/conf.d/proxy.conf

#include /etc/nginx/conf.d/*.conf; #把这一行注释掉，不然80端口会有冲突

     server {
       listen 80;    
    
    modsecurity on;

    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {

    proxy_pass [http://0.0.0.0:8085;](http://0.0.0.0:8085/)

    proxy_set_header Host $host;

    }

     nginx -s reload    #重新加载nginx
   curl -D -     http://localhost/foo?testparam=123    #能正常返回“Thank you for requesting /foo?testparam=123”
   
   
   curl -D -     http://localhost/foo?testparam=test    #则返回"403 Forbidden"，说明前面配置的那条modsecuriy规则生效了，并阻拦了testparam参数中带test的请求

在/var/log/nginx/error.log中可以看到拦截的详细日志

部署OWASP规则–CRS（Core Rule Set）

安装运行nikto漏洞扫描工具，用于测试CRS的防御效果

     
   git clone     https://github.com/sullo/nikto    #下载nikto
   cd nikto 
   perl program/nikto.pl -h localhost    #用nikto扫描nginx搭建的web系统（反向代理）
   扫描结果是+ 7687 requests: 0 error(s) and 308 item(s) reported on remote host    #扫描出308个问题

启用OWASP CRS

     cd /etc/nginx/modsec/
   wget     https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.2.tar.gz    #下载OWASP CRS
   cd owasp-modsecurity-crs-3.0.2/
   cp crs-setup.conf.example crs-setup.conf

在modsecurity主配置文件中include CRS的配置和规则

  vim /etc/nginx/modsec/main.conf

Include the recommended configuration

  Include /etc/nginx/modsec/modsecurity.conf

OWASP CRS v3 rules

     Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
   Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/*.conf

测试CRS

     nginx -s reload    #重新加载nginx配置
   curl     http://localhost    #返回Thank you for requesting /
   curl -H "User-Agent: Nikto"     http://localhost    #返回403 Forbidden，说明WAF防护已经生效，此处匹配的规则是user-agent中不能包含漏洞扫描器名字
   perl nikto/program/nikto.pl -h localhost    #再次用nikto扫描nginx搭建的web系统
   扫描结果是+ 7687 requests: 0 error(s) and 83 item(s) reported on remote host    #扫描出83个问题，比308个少了很多

在安装ModSecurity时，我们将演示应用程序配置为为每个请求返回状态代码200,但实际上并没有返回这些文件,Nikto将这200个状态码解释为它请求的文件确实存在,所以报告出83个问题，为了优化nikto，去除误报，我们做如下配置

  cp nikto/program/nikto.conf.default nikto/program/nikto.conf

vim nikto/program/nikto.conf #在第76行最后加上;-sitefiles，如下所示

  @@DEFAULT=@@ALL;-@@EXTRAS;tests(report:500);-sitefiles

之后再次用nikto扫描

  perl program/nikto.pl -h localhost

扫描结果是+ 7583 requests: 0 error(s) and 7 item(s) reported on remote host

可以看出问题只有7个问题，由于ModSecurity不支持响应（response）的检查，所以涉及此类的漏洞无法防御。但总体还是抵御了绝大部分的nikto的漏洞扫描。

参考链接：

https://www.nginx.com/resources/library/modsecurity-3-nginx-quick-start-guide/

https://github.com/SpiderLabs/ModSecurity

https://github.com/SpiderLabs/ModSecurity/tree/v3/master

*本文作者：owensky，转载请注明来自FreeBuf.COM

用于监控USB设备连接事件的取证工具

Mon, 26 Aug 2019 15:00:09 CST

*本工具仅供技术分享、交流讨论，严禁用于非法用途

usbrip（是“USB Ripper”的简写，而不是“USB R.I.P.”）是一个带有CLI接口的开源取证工具，可用于跟踪/监控Linux机器上的USB设备连接事件（即USB事件历史记录，“已连接”和“已断开连接”事件）。

描述

usbrip是纯Python 3编写的一个小软件（使用一些外部模块，参见 Dependencies/PIP），它会通过解析Linux的日志文件（/var/log/syslog*or/var/log/messages*取决于发行版本）来构建USB事件历史表格，其中可能包含的内容有：“已连接”（日期和时间），“User”，“VID”（供应商ID），“PID”（产品ID），“Product”，“制造商”，“序列号”， “端口”和“断开连接”（日期和时间）。

此外，它还可以：

将收集到的信息导出为JSON转储文件；

生成一个授权（可信）USB设备列表作为JSON（称之为auth.json）;

基于auth.json搜索“违规事件”：显示（或生成另一个JSON）USB设备，这些设备出现在历史记录中但不会出现在auth.json中；

*当使用-s标志安装时*创建加密存储（7zip存档）以在crontab调度程序的帮助下自动备份和积累USB事件；

根据特定USB设备的VID和/或PID搜索其他详细信息。

快速开始

usbrip可在 PyPI下载和安装：

  $ pip3 install usbrip

截图

Git Clone

为简单起见，让我们同意所有出现~/usbrip$前缀的命令都在~/usbrip目录中执行，该目录是由git clone创建的：

  ~$ git clone https://github.com/snovvcrash/usbrip.git usbrip && cd usbrip
~/usbrip$

依赖

usbrip仅适用于未修改的系统日志文件结构。因此，如果更改syslogs的格式（如，使用syslog-ng或rsyslog），它将无法解析USB历史记录。这就是为什么“Connected”和“Disconnected”字段的时间戳没有年份的原因。

deb 包

python3.6 (或更新) interpreter

python3-venv

p7zip-full（由storages模块使用）

  ~$ sudo apt install python3-venv p7zip-full -y

PIP 包

usbrip使用以下外部模块：

terminaltables

termcolor

手动

手动解析Python依赖关系（实际上并不需要pip或setup.py，可以自动化该过程，请参阅安装部分）创建虚拟环境（可选）并从内部运行pip：

  ~/usbrip$ python3 -m venv venv && source venv/bin/activate
(venv) ~/usbrip$ pip install -r requirements.txt

或者你可以通过下面的 pipenv单行命令为你完成所有的工作：

  ~/usbrip$ pipenv install && pipenv shell

之后你就可以非常轻松的运行usbrip了：

  (venv) ~/usbrip$ python -m usbrip -h
Or
(venv) ~/usbrip$ python __main__.py -h

安装

有两种方法可以将usbrip安装到你的系统中：pip或setup.py。

pip 或 setup.py

首先，usbrip是pip可安装的。这意味着在git cloning了repo之后，你可以简单地启动pip安装过程，然后在终端的任何地方运行usbrip，如下所示：

  ~/usbrip$ python3 -m venv venv && source venv/bin/activate
(venv) ~/usbrip$ pip install .

(venv) ~/usbrip$ usbrip -h

或者，如果你想在本地解析Python依赖关系，请使用setup.py：

  ~/usbrip$ python3 -m venv venv && source venv/bin/activate
(venv) ~/usbrip$ python setup.py install

(venv) ~/usbrip$ usbrip -h

注意：你可能希望在Python虚拟环境处于活动状态时运行安装过程（如上所示）。

install.sh

其次，usbrip也可以使用./installers/install.sh脚本安装到系统中。

当使用./installers/install.sh时，可以使用一些额外的功能：

自动创建虚拟环境；

存储模块变为可用：你可以设置crontab job，按计划备份USB事件（你可以在usbrip/cron/usbrip.cron中找到crontab job的示例）。

警告：如果你使用的是crontab计划任务，则需要使用sudo crontab -e配置cron job，以强制storage update子模块以root用户身份运行，并保护USB事件存储的密码。存储密码保存在/var/opt/usbrip/usbrip.ini中。

./installers/uninstall.sh脚本会从系统中删除所有安装项。

要安装usbrip命令如下：

  ~/usbrip$ chmod +x ./installers/install.sh
~/usbrip$ sudo -H ./installers/install.sh [-l/--local] [-s/--storages]
~/usbrip$ cd

~$ usbrip -h

启用-l开关后，将从本地.tar包（./3rdPartyTools/）而不是PyPI解析Python依赖项。

启用-s开关后，不仅会安装usbrip项目，还会创建受信任的USB设备，历史记录和违规存储列表。

注意：在安装期间使用-s选项时，请确保系统日志至少包含一个外部USB设备条目。这是usbrip成功创建受信任设备列表（并因此成功创建违规存储）的必要条件。

安装完成后，你可以删除usbrip文件夹。

路径

安装后，usbrip的文件存放分布路径如下：

/opt/usbrip/— 项目的主目录；

/var/opt/usbrip/usbrip.ini—usbrip配置文件：保存7zip存储的密码；

/var/opt/usbrip/storage/—USB事件存储：history.7z和violation.7z（在安装过程中创建）；

/var/opt/usbrip/log/— usbrip日志（建议在使用crontab时记录usbrip活动，参见usbrip/cron/usbrip.cron）；

/var/opt/usbrip/trusted/— 受信任USB设备列表（在安装过程中创建）；

/usr/local/bin/usbrip— 符号链接（symlink）到/opt/usbrip/venv/bin/usbrip脚本。

cron

Cron jobs可以设置如下：

  ~/usbrip$ sudo crontab -l > tmpcron && echo "" >> tmpcron
~/usbrip$ cat usbrip/cron/usbrip.cron | tee -a tmpcron
~/usbrip$ sudo crontab tmpcron
~/usbrip$ rm tmpcron

uninstall.sh

卸载usbrip：

  ~/usbrip$ chmod +x ./installers/uninstall.sh
~/usbrip$ sudo ./installers/uninstall.sh [-a/--all]

启用-a开关后，不仅会删除usbrip项目目录，还会删除所有存储和usbrip日志。

还有就是不要忘记删除cron job。

使用

  # ---------- BANNER ----------

$ usbrip banner
Get usbrip banner.

# ---------- EVENTS ----------

$ usbrip events history [-t | -l] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [-c <COLUMN> [<COLUMN> ...]] [-f <FILE> [<FILE> ...]] [-q] [--debug]
Get USB event history.

$ usbrip events open <DUMP.JSON> [-t | -l] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [-c <COLUMN> [<COLUMN> ...]] [-f <FILE> [<FILE> ...]] [-q] [--debug]
Open USB event dump.

$ usbrip events gen_auth <OUT_AUTH.JSON> [-a <ATTRIBUTE> [<ATTRIBUTE> ...]] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [-f <FILE> [<FILE> ...]] [-q] [--debug]
Generate a list of trusted (authorized) USB devices.

$ usbrip events violations <IN_AUTH.JSON> [-a <ATTRIBUTE> [<ATTRIBUTE> ...]] [-t | -l] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [-c <COLUMN> [<COLUMN> ...]] [-f <FILE> [<FILE> ...]] [-q] [--debug]
Get USB violation events based on the list of trusted devices.

# ---------- STORAGE ----------

$ usbrip storage list <STORAGE_TYPE> [-q] [--debug]
List contents of the selected storage (7zip archive). STORAGE_TYPE is "history" or "violations".

$ usbrip storage open <STORAGE_TYPE> [-t | -l] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [-c <COLUMN> [<COLUMN> ...]] [-q] [--debug]
Open selected storage (7zip archive). Behaves similary to the EVENTS OPEN submodule.

$ usbrip storage update <STORAGE_TYPE> [-a <ATTRIBUTE> [<ATTRIBUTE> ...]] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [--lvl <COMPRESSION_LEVEL>] [-q] [--debug]
Update storage — add USB events to the existing storage (7zip archive). COMPRESSION_LEVEL is a number in [0..9].

$ usbrip storage create <STORAGE_TYPE> [-a <ATTRIBUTE> [<ATTRIBUTE> ...]] [-e] [-n <NUMBER_OF_EVENTS>] [-d <DATE> [<DATE> ...]] [--user <USER> [<USER> ...]] [--vid <VID> [<VID> ...]] [--pid <PID> [<PID> ...]] [--prod <PROD> [<PROD> ...]] [--manufact <MANUFACT> [<MANUFACT> ...]] [--serial <SERIAL> [<SERIAL> ...]] [--port <PORT> [<PORT> ...]] [--lvl <COMPRESSION_LEVEL>] [-q] [--debug]
Create storage — create 7zip archive and add USB events to it according to the selected options.

$ usbrip storage passwd <STORAGE_TYPE> [--lvl <COMPRESSION_LEVEL>] [-q] [--debug]
Change password of the existing storage.

# ---------- IDs ----------

$ usbrip ids search [--vid <VID>] [--pid <PID>] [--offline] [-q] [--debug]
Get extra details about a specific USB device by its <VID> and/or <PID> from the USB ID database.

$ usbrip ids download [-q] [--debug]
Update (download) the USB ID database.

Help

获取模块名称列表：

  $ usbrip -h

获取特定模块的子模块名称列表：

  $ usbrip <module> -h

获取特定子模块的所有开关列表：

  $ usbrip <module> <submodule> -h

示例

显示所有USB设备的事件历史记录，banner输出，信息消息和用户交互（-q，–quiet），（-l,–list）表示为列表包含最新的100个条目（ -n NUMBER，–number NUMBER）：

  $ usbrip events history -ql -n 100

显示外部USB设备的事件历史记录（-e，–external，实际上已断开连接），表示为包含“Connected”，“VID”，“PID”，“Disconnected”的表（-t，–table）和“序列号”列（-c COLUMN [COLUMN],–column COLUMN [COLUMN]）按日期过滤从外部文件中获取的日志（-f FILE [FILE ...],–file FILE [FILE ...]）：

  $ usbrip events history -et -c conn vid pid disconn serial -d "Dec  9" "Dec 10" -f /var/log/syslog.1 /var/log/syslog.2.gz

构建所有USB设备的事件历史记录，并将输出重定向到文件以进一步的分析。当输出流不是终端stdout（如 | 或 >）时，输出中将没有ANSI转义字符，因此可以随意使用它。另外需要注意的是，usbrip使用了一些UNICODE符号，因此将生成的文件转换为UTF-8编码（如使用encov），以及将换行符更改为Windows样式会更方便（如使用awk）。

  usbrip history events -t | awk '{ sub("$", "\r"); print }' > usbrip.out && enconv -x UTF8 usbrip.out

备注：即使已经将输出发送到stdout，也可以自己去掉转义字符。你只需将输出数据复制到usbrip.out并添加一条awk指令：

  awk '{ sub("$", "\r"); gsub("\\x1B\\[[0-?]*[ -/]*[@-~]", ""); print }' usbrip.out && enconv -x UTF8 usbrip.out

将受信任的USB设备列表生成为json文件（trusted/auth.json），其中包含9月26日连接的前三个设备的“VID”和“PID”属性：

  $ usbrip events gen_auth trusted/auth.json -a vid pid -n 3 -d "Sep 26"

警告：有时不同的USB闪存驱动器可能具有相同的序列号。到目前为止，usbrip还没有办法处理这种情况，也就是说它将把一对具有相同SN（如果存在）的设备视为与可信设备列表和gen_auth模块相同的设备。

根据“PID”属性的可信USB设备列表（trusted/auth.json）搜索外部USB设备的事件历史记录，并将结果事件限定为“Bob”作为用户，“EvilUSBManufacturer”为制造商，“1234567890”为序列号，并将输出表示为具有“Connected”，“VID”和“PID”列的表：

  $ usbrip events violations trusted/auth.json -a pid -et --user Bob --manufact EvilUSBManufacturer --serial 1234567890 -c conn vid pid

通过VID（–vid VID）和PID（–pid PID）搜索特定USB设备的详细信息：

  $ usbrip ids search --vid 0781 --pid 5580

下载最新版本的usb_ids/usb.ids数据库（源码可在此处查看）：

  $ usbrip ids download

参考文献

Linux-форензика в лице трекинга истории подключений USB-устройств / Хабр

usbrip: USB-форензика для Линуксов, или Как Алиса стала Евой

*参考来源： GitHub，FB小编secist编译，转载请注明来自FreeBuf.COM

基于MySQL binlog的数据同步中间件 mbinlogmq

Wed, 24 Jul 2019 09:52:29 CST

mbinlogmq 一个基于MySQL binlog协议的数据同步中间件什么是mbinlogmq? mbinlogmq 是一个使用C语言开发的基于 MySQL binlog 协议的一个中间件，通过模拟Slave 来实时获取 MySQL binlog日志，并将数据变更信息以及 DB 语句发送到 RabbitMQ，中间通过监听机制与校验机制来确保不宕机的情况下的100%抵达 RMQ 设计架构安装&编译 mbinlog依赖于一些第三方库：请先安装依赖软件： cURL 、mysql、rabbitmq，安装完成后记住其安装的路...