今日sql和git的学习复盘

2025-11-23 分类：CS

一、总述/概览

核心论题：透过现象看本质的底层掌控力。 今天的学习实际上是在打破三个领域的“黑盒”：

  1. 打破 AI 框架黑盒：通过手写 LightInfer，不再依赖 PyTorch 高层封装，而是直接用 C++ 和 Triton 控制内存映射（Mmap）、显存分页（PagedAttention）和 GPU 计算内核。
  2. 打破 Git 历史黑盒：通过 Rebase 和 Force Push 修正历史提交，理解 Git 的存储机制。
  3. 打破 SQL 执行黑盒：深刻理解“代码书写顺序”与“机器执行顺序”的矛盾，解决复杂查询问题。

二、按照内容的内在逻辑自然分段

模块核心内容提炼
1. 高性能推理引擎构建
[LightInfer 项目]		从零构建 LLM 推理底座：通过 C++ 管理内存（Mmap/PagedAttention）和调度，利用 Python/Triton 编写高性能算子（FlashAttention），解决大模型推理的显存碎片和 IO 瓶颈问题。
2. 版本控制救火实战
[Git 进阶]		Git 历史回溯与修复：解决了错误提交超大二进制文件导致无法 Push 的问题，掌握了交互式变基（Rebase）和强制推送（Force Push）的高危操作流程。
3. 数据查询逻辑内功
[SQL 核心]		SQL 执行顺序与窗口函数：厘清了 FROM -> WHERE -> GROUP BY -> HAVING -> SELECT 的底层流水线，明确了窗口函数（Rank）为何不能直接用于 Where 子句。

三、核心知识点、问题与逻辑链路

1. 核心知识点映射表

序号知识点定义/关键技术直观意义 (类比解释)功能作用
1Mmap (内存映射)mmap 系统调用，将文件映射到虚拟地址空间。传送门：不用把货物（模型权重）搬进仓库（内存），直接在仓库墙上开个门连通货船，用到哪件货直接拿。实现“零拷贝”加载大模型，OS 自动处理缺页中断，极大减少冷启动时间。
2PagedAttention将连续的 KV Cache 显存需求打散为非连续的 Block。代客泊车：以前车队（长文本）必须停在连续车位，现在可以拆散停在停车场的任意空位，通过记录本（页表）找车。彻底消除显存碎片，显存利用率从 <60% 提升至接近 100%，大幅提升 Batch Size。
3TritonOpenAI 推出的类 Python GPU 编程语言。自动挡跑车：不用像 CUDA 那样手动换挡（管理 Shared Memory/Barriers），只需踩油门（写计算逻辑），编译器自动优化。降低高性能算子（如 FlashAttention）的开发门槛，实现块级并行。
4Continuous Batching迭代级调度（Iteration-level scheduling）。流水线作业：不再等一批人全吃完才收盘子，而是谁吃完谁走，新客人立马补位。消除长短序列混合推理时的 GPU 空转（气泡），始终保持计算单元忙碌。
5SQL Window FunctionRANK() OVER (PARTITION BY ...)。透视镜：在不压缩数据行的情况下，给每个人贴上他在班级里的排名标签。用于组内排名、累计求和、环比增长，且保留原始数据明细。
6Git Rebasegit rebase -i (交互式变基)。剪辑师：把拍好的电影胶卷剪开，删掉穿帮的镜头（大文件），再重新拼接起来。修改提交历史，移除误提交的文件或合并零碎提交。

2. 核心问题 (Critical Questions)

核心问题动机 (痛点)直观意义区别与答案 (思维链路)
为什么 PyTorch 推理慢，需要 C++ 重构？Python 解释器开销大（Overhead），尤其在 For 循环解码时。指挥官太慢：士兵（GPU）动作很快，但指挥官（Python）下令太慢，导致士兵一直在等命令。答案：C++ 充当没有任何延迟的指挥官，只在极少量控制逻辑上使用 Python，让 GPU 始终满载。
FlashAttention 到底快在哪里？传统 Attention 频繁读写 HBM（高带宽内存），受限于内存带宽。厨房动线优化：传统做法是切完菜放回冰箱（HBM），炒的时候再拿；FlashAttn 是切完直接扔进锅里（SRAM），减少跑冰箱的次数。答案：通过分块 (Tiling) 和重计算 (Recomputation)，在 SRAM（缓存）中完成 QK 乘法和 Softmax，减少了对 HBM 的读写次数（IO Bound 转 Compute Bound）。
为什么不能在 WHERE 子句中直接用 RANK()？想筛选“排名前三”，写 WHERE rank <= 3 报错。时间悖论：你还没出生，怎么能参加高考？链路：SQL 执行顺序是 WHERE (筛选原始人) -> GROUP BY -> SELECT (计算排名)。WHERE 执行时，RANK 还没算出来。解法：用子查询/CTE 先把排名算成普通列，再在最外层过滤。
Git 误传大文件，为什么要用 Rebase 而不是直接 Delete？直接删除产生新提交，历史记录里大文件还在，仓库体积依然巨大。掩耳盗铃：你只是把垃圾扔到了床底下（历史记录），没扔出房间。答案：必须修改“历史”，把包含该文件的那个 Commit 彻底修改或丢弃，才能真正瘦身。操作后必须 Force Push。

3. 逻辑链路 (思维推导)

链路一：LightInfer 端到端推理流水线 (The Inference Loop) 这是一条“压榨硬件性能”的工程链路：

  1. Initialize (启动)：MmapLoader 建立文件映射 -> 瞬间获得百 GB 模型的虚拟地址指针（无 IO 等待）。
  2. Prompt Phase (预填充)：请求进入 -> BlockManager 根据 Prompt 长度预分配 N 个非连续 Block -> Triton Kernel 并行计算 Prompt 的 KV Cache 并填入显存。
  3. Decode Phase (循环解码)：
    • C++ Scheduler: 检查队列，组装当前 Batch。
    • Step: 调用 LlamaModel.forward。
    • GPU Compute:
      • Embedding/RoPE (位置编码)。
      • FlashAttention: 读取 Block Table -> 加载非连续 KV Block 到 SRAM -> 计算 Attention Score。
      • MLP (矩阵乘)。
    • Sampling: 采样出 Next Token。
    • Memory Update: BlockManager 为新 Token 分配 1 个新 Block (如果旧的满了)。
    • Loop: 回到 Step，直到生成结束符号。

链路二：SQL 查询执行的真实生命周期 这是一条“数据筛选漏斗”链路：

  1. FROM/JOIN: 拿到所有数据源，生成笛卡尔积（如果 JOIN 条件不当）。
  2. WHERE: 行级过滤。此时数据是散乱的，不能用聚合函数（如 SUM），因为组还没分；也不能用窗口函数（如 RANK），因为列还没生成。
  3. GROUP BY: 压缩阶段。将多行压缩成一行（组）。
  4. HAVING: 组级过滤。剔除不满足条件的组（如 SUM(sales) > 1000）。
  5. SELECT: 投影与计算。此时才开始计算 RANK() OVER... 等窗口函数。
  6. ORDER BY / LIMIT: 最终修饰。

链路三：Git 历史修正工作流

  1. 事故现场：git add . 把 1GB 的日志文件 commit 了。
  2. 暂停：不要 push，不要慌。
  3. 回溯：git rebase -i HEAD~N (N是回溯的步数)。
  4. 编辑：在编辑器中把那个 commit 的前缀从 pick 改为 edit 或 drop。
  5. 修正：
    • 如果是 edit: git reset HEAD^ (撤销提交但保留文件) -> rm large_file -> git add . -> git commit --amend。
    • 如果是 drop: 直接丢弃该次提交。
  6. 继续：git rebase --continue。
  7. 覆盖：git push origin branch_name --force。

四、费曼式讲解

1. 讲解 LightInfer (高性能推理引擎) 想象你要经营一家超高效率的自助餐厅（GPU）：

  • Python 是个啰嗦的领班，以前每上一道菜都要他亲自喊话，厨师（GPU核心）大部分时间都在等他说话。
  • C++ 是个冷酷的机器人领班，语速极快，毫无废话，让厨师手都不停。
  • Mmap (内存映射) 是任意门。食材（模型参数）不需要用卡车一车车拉进厨房（加载内存），而是厨房墙上开了无数个任意门，厨师手伸过去就能拿到需要的食材。
  • PagedAttention 是拼桌艺术。以前客人（KV Cache）来了，非要占一张十人长桌，哪怕只有两个人。现在我们把桌子切成小方块，两个人就给两块，分散坐在餐厅各个角落，通过领班手里的**座位表（Page Table）**来上菜。餐厅容量瞬间翻倍。
  • Triton 是智能炒菜机。以前做复杂菜式（FlashAttention）需要手写汇编级的菜谱（CUDA），现在只要设定好温度和流程，机器自动处理火候，做出来的菜又快又香。

2. 讲解 SQL 执行顺序 你想选出“每个班级的前三名”：

  • WHERE 是校门口的保安。他只拦没穿校服的人（过滤原始行），但他不知道谁考了多少分，更不知道排名。
  • GROUP BY 是分班。把学生按班级聚在一起。
  • SELECT (窗口函数) 是班主任。他在班里根据成绩给每个人贴上“第1名”、“第2名”的贴纸。
  • 外部查询 (WHERE rank <= 3) 是领奖台。只有身上贴着前3名贴纸的人，才能上台。
    • 关键点：保安（WHERE）在校门口，班主任（SELECT）在教室里。保安不可能看到教室里才贴上的排名贴纸，所以不能在 WHERE 里筛排名。

五、压缩要点 (Cheat Sheet)

  1. LightInfer 架构三支柱：
    • 脑 (C++)：MmapLoader (零拷贝加载), BlockManager (分页显存管理), Scheduler (批处理)。
    • 肉 (Triton)：FlashAttention (分块计算, SRAM > HBM), RMSNorm。
    • 魂 (OS)：利用 Linux mmap 和 page table 机制优化 IO 和内存。
  2. Git 救命指令：
    • git rebase -i：交互式修改历史（删大文件、合并提交）。
    • git push -f：强制覆盖远程（慎用）。
    • Detached HEAD：Rebase 过程中的中间状态，只做 rebase --continue/abort，别乱 commit。
  3. SQL 六字真言：
    • 顺序：FROM -> WHERE -> GROUP -> HAVING -> SELECT -> ORDER。
    • 铁律：WHERE 里不能有聚合（SUM）和窗口（RANK）；聚合必须对应 GROUP BY；窗口函数在 SELECT 阶段生成。
    • JOIN：无 ON 变笛卡尔积（行数爆炸）；Left Join 保留左表。

今日一句话总结： 无论是写 C++ 榨干 GPU 性能，还是写 SQL 筛选数据，亦或是用 Git 管理代码，高手的核心在于理解“数据在底层是如何流转和存储的”，而不是仅仅停留在语法表面。