专业书籍精读

Ch 1引论与概览 — 七步框架：难的从来不是选模型，而是把业务目标翻译成 ML 目标、再在线上证明它真有用Aminian & Xu · 2023 Ch 2视觉搜索系统 — 以图搜图的秘密不是让机器看懂图，而是把每张图变成向量、让「像不像」变成「近不近」Aminian & Xu · 2023 Ch 3Google 街景模糊化 — 漏一张脸是隐私事故、多糊一块招牌只是图丑，代价差几个数量级时就该把阈值故意调歪Aminian & Xu · 2023 Ch 4YouTube 视频搜索 — 一半的活儿根本不用模型：倒排索引与向量检索两条路并行，失败模式正好互补Aminian & Xu · 2023 Ch 5有害内容检测 — 图没问题、字也没问题，合起来才有问题：融合必须早做，而模型只出分、不下判决Aminian & Xu · 2023 Ch 6视频推荐系统 — 十亿候选配上几十毫秒预算，逼出召回 + 排序 + 重排三层漏斗Aminian & Xu · 2023 Ch 7活动推荐系统 — 活动几天就过期、上架即零交互，冷启动成了常态，力气从选模型挪到造特征Aminian & Xu · 2023 Ch 8社交平台广告点击预测 — 分数要拿去计费，于是排序对了还不够，概率本身必须说得准Aminian & Xu · 2023 Ch 9民宿相似房源 — 不定义什么叫「相似」，让会话里的共现替你定义，冷启动靠属性回退Aminian & Xu · 2023 Ch 10个性化信息流 — 六七个预测头合成一个分，模型只管概率准不准，那组权重才决定产品长成什么样Aminian & Xu · 2023 Ch 11你可能认识的人 — 难的不是模型猜得准，是先用二跳邻居把十亿人砍到一万个候选Aminian & Xu · 2023 Ch 1引论与概览 — 七步框架，以及被掀翻的三条旧规矩：没有标准答案、成本按 token 走、错得流畅Aminian et al. · 2024 Ch 2Gmail 智能撰写 — 延迟预算先动手，把模型规模、解码宽度乃至「这次要不要出声」全部钉死Aminian et al. · 2024 Ch 3Google 翻译 — 一个模型吃下上百种语言，采样配比是个零和旋钮，而 BLEU 量不出翻得好不好Aminian et al. · 2024 Ch 4ChatGPT 个人助理 — 「好」写不成损失函数时，就把人的两两比较训成一个能优化的打分器Aminian et al. · 2024 Ch 5图像描述 — 视觉那半早被现成模型解决了，难的是没人说得清「描述对了」是什么Aminian et al. · 2024 Ch 6检索增强生成 — 真正的产出不是答案，是一条能点回原文核对的证据链Aminian et al. · 2024 Ch 7真实人脸生成 — 「像不像真脸」写不成公式，那就训练另一个网络来当那把尺子Aminian et al. · 2024 Ch 8高分辨率图像合成 — 把上百步去噪整体搬进一张 64×64 的草稿纸，算力才掉一个量级Aminian et al. · 2024 Ch 9文生图 — 交叉注意力把那句话嵌进每一层，再靠「画两遍、朝差别外推」把服从度变成一个能实时拧的旋钮Aminian et al. · 2024 Ch 10个性化头像生成 — 脸是唯一写不进提示词的条件，只能拿样本去教；胜出的教法是一枚删得干净的适配器Aminian et al. · 2024 Ch 11文生视频 — 时间一致性必须写进模型结构；而暴涨的算力只能靠「低分定骨架、再补帧、再放大」摊薄Aminian et al. · 2024 Ch 1可靠·可扩展·可维护 — 先立三把尺子，用负载参数和响应时间百分位把「系统好不好」量化成可谈的东西Kleppmann · 2017 Ch 2数据模型与查询语言 — 关系 / 文档 / 图各擅长什么，声明式查询为何胜过命令式Kleppmann · 2017 Ch 3存储与检索 — 数据库底层怎么存怎么找：LSM-tree vs B-tree，行存 OLTP vs 列存分析Kleppmann · 2017 Ch 4编码与演化 — 数据怎么序列化、schema 怎么在不停机下前后兼容地演化Kleppmann · 2017 Ch 5复制 — 同一份数据放多台机器：单主 / 多主 / 无主，与复制滞后的一致性坑Kleppmann · 2017 Ch 6分区 — 一份数据太大切成片：按范围还是按哈希，热点与再平衡Kleppmann · 2017 Ch 7事务 — ACID 到底保证了什么，弱隔离放行哪些并发异常，写偏斜为何是最该记的坑Kleppmann · 2017 Ch 8分布式系统的麻烦 — 部分失效、不可靠时钟、网络停顿，为什么分布式这么难Kleppmann · 2017 Ch 9一致性与共识 — 线性一致、全序广播与共识，CAP 之后真正该知道的Kleppmann · 2017 Ch 10批处理 — MapReduce 的「分头数再汇总」，靠一次分布式排序把海量数据算成派生结果，输入不可变所以算错就重来Kleppmann · 2017 Ch 11流处理 — 把数据当永不结束的事件流来一条算一条，靠可回放的日志（Kafka）与流表二象性把数据库里外翻转，难点在事件时间与水位Kleppmann · 2017 Ch 12数据系统的未来 — 把数据库拆开、用一条有序事件流重新组装，正确性靠端到端而非底层事务Kleppmann · 2017 Ch 1软件交付的难题 — 手工部署与发布日地狱，把发布做成一条可重复的流水线Humble & Farley · 2010 Ch 2配置管理 — 一切纳入版本控制，同一份制品部署到所有环境，机器一律不许手工改Humble & Farley · 2010 Ch 3持续集成 — 每天并回主干、红了全队停线，CI 是一种实践不是一个工具Humble & Farley · 2010 Ch 4实施测试策略 — 用四象限把测试摊开：能重复的交给机器，靠好奇心的留给人Humble & Farley · 2010 Ch 5部署流水线剖析 — 从提交到生产的一条自动化关卡：只构建一次，红了就停线Humble & Farley · 2010 Ch 6构建与部署脚本化 — 所有环境共用一套脚本、跑几遍都一样：把部署脚本当生产代码管Humble & Farley · 2010 Ch 7提交阶段 — 十分钟内给出一个可信的红或绿：这条预算管的是人，不是机器Humble & Farley · 2010 Ch 8自动化验收测试 — 把「验什么」和「怎么点」分层拆开，端到端测试才养得起Humble & Farley · 2010 Ch 9非功能需求测试 — 把「够快、扛得住」写成会亮红灯的阈值；缩水的压测环境只配看趋势Humble & Farley · 2010 Ch 10部署与发布 — 蓝绿与金丝雀把上线拆成可撤回的小步；真正的墙不是代码，是数据Humble & Farley · 2010 Ch 11管理基础设施与环境 — 机器只能由自动化按版本库里的定义来建和改，手工改过一次就再也复制不出来Humble & Farley · 2010 Ch 12管理数据 — 代码能换回上一版，数据不能；靠非破坏性迁移和新旧并存的兼容窗口把发布变回可撤销Humble & Farley · 2010 Ch 13组件与依赖 — 拆组件是为了把构建拉回十分钟，代价是丢掉「一次提交、一次全量验证」，得靠钉死版本和集成流水线买回来Humble & Farley · 2010 Ch 14高级版本控制 — 分支不是在隔开风险，是在攒着风险；真正的敌人是分歧时长，不是分支本身Humble & Farley · 2010 Ch 15管理持续交付 — 挡路的不是流水线而是「谁敢放行」；想让审计满意别加签字，加自动化Humble & Farley · 2010 Ch 1引论 — 请软件工程师来设计运维团队，再用 50% 工程时间下限和错误预算把它钉住Google · 2016 Ch 2Google 的生产环境（SRE 视角） — 几万台机器被 Borg、Colossus、Jupiter、Chubby 黏成一台数据中心大小的计算机Google · 2016 Ch 3拥抱风险 — 100% 是错的目标；把 1 减去 SLO 的那截当成能花的预算，有余额就发、烧光就冻结Google · 2016 Ch 4服务质量目标 — 先挑对该量的东西再谈几个 9；一条 SLO 要写清在哪测、算哪段窗口，还得少到你敢用它拍板Google · 2016 Ch 5消除琐务 — 判据不是烦不烦，而是它会不会随规模线性长大；50% 是上限，超了要退回开发团队Google · 2016 Ch 6监控分布式系统 — 四个黄金信号是最小充分集；告警只报症状，处置机械的那种根本不该叫人Google · 2016 Ch 7Google 自动化的演进 — 省时间是最弱的理由；外挂在系统之外的自动化总会悄悄腐烂，终点是系统自己照顾自己Google · 2016 Ch 8发布工程 — 发得快只是结果，能原样重来才是地基；配置也得有自己的版本号和回滚Google · 2016 Ch 9简单性 — 可靠性的上限是你还读得懂多少；代码是负债，最理想的改动是负行数Google · 2016 Ch 10实用告警：从时序数据出发 — 告警不是给每台机器设阈值，而是在带标签时序上求一个算式：取速率、跨实例聚合、化成比率Google · 2016 Ch 12有效排障 — 排障是手艺不是天赋；先止血再破案，从中间折半，然后问「力气花在哪」Google · 2016 Ch 15事后复盘文化 — 不追人只追条件，因为你要的信息只在当事人嘴里；产出不是文档，是一串被跟到关掉的改动Google · 2016 Ch 17为可靠性做测试 — 测试改变的不是 bug 的数量，而是它在哪一道闸被抓到；位置决定修复代价Google · 2016 Ch 18SRE 中的软件工程 — 容量规划别再交「要多少台」，交「为什么要这么多」，让求解器算Google · 2016 Ch 19前端负载均衡 — DNS 只能粗、慢地指个方向；真正钉住一条连接的是机房门口那层，靠算不靠记Google · 2016 Ch 20数据中心内的负载均衡 — 「活儿最少」是被污染的信号：秒回错误的坏后端看起来永远最闲Google · 2016 Ch 21处理过载 — 容量别用 QPS 量；扛不住时主动少接一点，产出反而稳在上限上Google · 2016 Ch 22应对级联失效 — 失败会自己繁殖；修好起因也回不来，得亲手把回路掐停Google · 2016 Ch 23管理关键状态 — 心跳加超时不是绕开了共识，而是写错了的共识；这种东西请用现成的Google · 2016 Ch 24分布式周期任务调度 — 跨出一台机器，cron 就拿不到「恰好一次」；漏跑和重跑之间你必须先选一边Google · 2016 Ch 25数据处理管线 — 管线的敌人不是数据量，是「按点开工」本身：空转的谷、挤爆的峰、看不出死活的中间态Google · 2016 Ch 26数据完整性 — 你以为副本在保护数据，其实副本只是把误删同步得更快；保命的是三道防线Google · 2016 Ch 27大规模可靠的产品发布 — 检查单上每一条都是一次事故的墓志铭；而它还必须会瘦身，否则腐烂成橡皮图章Google · 2016 Ch 33从其他行业学到的教训 — SRE 那套做法几乎没一样是软件发明的；真正搬不走的是错误预算，因为核电不能预算一次熔堆Google · 2016 Ch 34结语 — 可靠性不是美德，是能测量、能预算、能自动踩刹车的工程量；要规模的只是实现层Google · 2016 合辑值班与事故响应 — 指挥的人不动手、只有一组能改系统，再加上排班养得住人、告警笔笔记账Google · 2016 合辑SRE 的组织与协作 — 把人当稀缺资源来管：挡住打断、派教练不派壮丁，终点是让生产就绪评审本身消失Google · 2016 Ch 1加速 — 快与稳不是取舍，是同一批团队的同一件事；改进别爬等级，先找自己最弱的那一环Forsgren et al. · 2018 Ch 2测量效能 — 别数「干了多少」，改数四个互相牵制的结果，让谁都没法牺牲一侧去刷另一侧Forsgren et al. · 2018 Ch 3测量并改变文化 — 别问文化怎么样，看一条坏消息能不能走到该看见它的人手里Forsgren et al. · 2018 Ch 4技术实践 — 持续交付不是买流水线，是让主干随时可发；而自动化测试谁写，比写没写更能拉开差距Forsgren et al. · 2018 Ch 5架构 — 别争单体还是微服务，只问两句：能不能独立测、能不能独立发Forsgren et al. · 2018 Ch 6把安全融入交付 — 安全不是发布前那道门，而是把路铺好：让做对的事比绕开更省事Forsgren et al. · 2018 Ch 7软件的管理实践 — 单独设在制品上限几乎没用，外部变更审批只买到延迟、买不到稳定Forsgren et al. · 2018 Ch 8产品开发 — 团队自主改规格是最锋利的一条，但缺了客户反馈就只是更快地造出没人要的东西Forsgren et al. · 2018 Ch 9让工作可持续 — 别问团队累不累，问上次上线是周几几点；倦怠是环境的输出，不是人不够强Forsgren et al. · 2018 Ch 10员工满意度、认同与投入 — 把「人过得好不好」变成三个能问出来的数，而它们主要由技术实践决定Forsgren et al. · 2018 Ch 11领导者与管理者 — 变革型领导有五个可测维度，但它造条件不造结果：领导力低几乎注定低效能，高却未必高效能Forsgren et al. · 2018 Ch 16高绩效的领导与管理 — 领导者只定方向、清障碍，改进归干活的人；而转型没有完工那一天Forsgren et al. · 2018 合辑研究方法篇 — 一个概念问好几道题、先立假设再看数据，并且只把话说到「能预测」为止Forsgren et al. · 2018 Ch 1引论与概览 — 把数据库拆成四层，再收束成三个旋钮：写前攒不攒、原地改还是只追加、要不要按键有序Petrov · 2019 Ch 2B-Tree 基础 — 省的不是比大小的次数，是跑硬盘的次数：一页塞满路标，31 层塌成 4 层Petrov · 2019 Ch 3文件格式 — 目录管顺序、正文随便摆：插一条只挪 2 字节偏移量，而不是搬几 KB 记录Petrov · 2019 Ch 4实现 B-Tree — 分裂算法是全章最容易的部分，工程量在别处：面包屑找父节点、先向兄弟借地方、顺序键别对半切Petrov · 2019 Ch 5事务处理与恢复 — 日志才是正本、数据文件只是誊清稿；崩溃后先原样重演历史，再撤销没说完的话Petrov · 2019 Ch 6B-Tree 变体 — 贵的是改不是找：四个变体拆的都是同一个假设——非得原地修改吗Petrov · 2019 Ch 7日志结构存储 — 它没让写变便宜，只是把随机改换成顺序追加，代价推迟到后台合并里付Petrov · 2019 Ch 8分布式系统引论 — 先把「链路多可靠、时钟多可信、节点会怎么坏」写死成假设，后面的算法才有地基Petrov · 2019 Ch 9故障检测 — 「死了」和「只是慢」原理上分不开，所以别输出死活，输出一个可分级的怀疑度Petrov · 2019 Ch 10领导者选举 — 选举永远保证不了「只有一个主」，唯一性要靠世代号在执行端 fencingPetrov · 2019 Ch 11复制与一致性 — 一致性不是性能旋钮而是合约，w+r>n 给的是重叠、不是线性一致Petrov · 2019 Ch 12反熵与传播 — 最终一致的「最终」是一笔运营支出：读修复只修被读到的，兜底全靠 repairPetrov · 2019 Ch 13分布式事务 — 原子提交要全体同意、共识只要多数，所以 2PC 的病不是慢，是协调者一倒就全体持锁干等Petrov · 2019 Ch 14共识 — 多数派的意义是交集而不是民意，所以已定下的值只能被接着重复、不能被改写Petrov · 2019 Ch 1从零到百万用户 — 七步扩展阶梯按性价比排开，最后一步分片几乎回不了头Alex Xu · 2020 Ch 2粗略估算 — 白板上三分钟把量级算对，产出的不是数字而是一串能被当场推翻的假设Alex Xu · 2020 Ch 3系统设计面试框架 — 四步法把一道含糊大题收敛成能做的题，考的是过程不是最后那张图Alex Xu · 2020 Ch 4设计限流器 — 五种算法的分野只在一句话：业务允不允许突发Alex Xu · 2020 Ch 5设计一致性哈希 — 它没让数据变均匀，只把扩缩容的搬家量从「几乎全部」压到 1/NAlex Xu · 2020 Ch 6设计键值存储 — 放弃主节点之后，正确性得靠 quorum、向量时钟和反熵一件件补回来Alex Xu · 2020 Ch 7设计分布式唯一 ID — 不重复很容易，难的是又短、又按时间有序、还不许机器之间打招呼Alex Xu · 2020 Ch 8设计短网址服务 — 短码取 7 位不是拍脑袋，是从十年 3650 亿条倒推出来的Alex Xu · 2020 Ch 9设计网页爬虫 — 难的不是下载，是排队：两层队列把「先抓谁」和「别把人家抓崩」分开解决Alex Xu · 2020 Ch 10设计通知系统 — 最后一公里在别人家，你能管的只有队列、幂等，和别把用户烦到关掉开关Alex Xu · 2020 Ch 11设计信息流 — 提前印好还是等人来了现拼，成本只是换了个位置；真正的分流键是发布者Alex Xu · 2020 Ch 12设计聊天系统 — 难的不是发是收：HTTP 不能由服务端开口，整套架构只好围着那一根长连接重建Alex Xu · 2020 Ch 13设计搜索自动补全 — 它其实从来不搜：每个前缀的答案早在上周夜里写好，白天只负责取Alex Xu · 2020 Ch 14设计 YouTube — 难的不是播放：一条能并行的转码流水线，和那张每天六位数的 CDN 账单Alex Xu · 2020 Ch 15设计 Google Drive — 它不是存储系统是同步系统：存储外包给了云，难的全在那本记账的元数据上Alex Xu · 2020 Ch 16学习的延续 — 题会做完，清单不会：一道练习配一篇真实系统的公开资料，才是面试之后还在长的东西Alex Xu · 2020 Ch 1设计附近服务 — 它不是搜索题是编号题：把经纬度压成一维格子号，数据库才重新用得上索引Xu & Lam · 2022 Ch 2设计附近的好友 — 它不是搜索题：候选集就那几百个好友，于是位置不必被查，只需沿关系推过去Xu & Lam · 2022 Ch 3设计 Google Maps — 它大半不是现算的：地图提前烘成瓦片交给 CDN，只有路况配得上实时计算Xu & Lam · 2022 Ch 4设计分布式消息队列 — 它不是传话筒是一本账本：改成只能追加的日志，分区、副本与重放全是顺带长出来的Xu & Lam · 2022 Ch 5设计监控告警系统 — 你以为它是个看图表的读系统，其实每秒一百万次写入不停；而它偏偏不能依赖自己盯着的那套东西Xu & Lam · 2022 Ch 6设计广告点击聚合 — 它不是计数器是账本：数字直接变成钱，于是快的那份给人看、准的那份夜里重算来结账Xu & Lam · 2022 Ch 7设计酒店预订系统 — 每秒只有三笔预订，难的从来不是流量，是两个人同时点了最后一间房Xu & Lam · 2022 Ch 8设计分布式邮箱服务 — 分区键天然写在那里：没人查别人的信箱，于是分布式里最贵的那几样整套不用买Xu & Lam · 2022 Ch 9设计对象存储 — 它的能力全是减出来的：交出「原地修改」，才换到近乎无限的扩展与 1.5 倍空间的 11 个 9Xu & Lam · 2022 Ch 10设计实时排行榜 — 先算账：500 万 DAU 算完只需一台 Redis；真要分片才发现排名是全局量、分片是局部化Xu & Lam · 2022 Ch 11设计支付系统 — 全书吞吐最低的一章：超时既不是成功也不是失败，正确性靠幂等键、复式记账与每日对账叠出来Xu & Lam · 2022 Ch 12设计数字钱包 — 全章只做一件事：把「余额」这个可变字段拆掉，换成一串谁都能重算一遍的流水Xu & Lam · 2022 Ch 13设计证券交易所 — 全书唯一答案是「别分布式」的一章：门口发号定序，里面单线程按号办事，公平与可重放都由此长出Xu & Lam · 2022 Ch 1遭遇复杂系统 — 故障不住在坏零件里，住在一堆各自正常的组件之间的接缝上；组件线性涨、接缝平方涨Rosenthal & Jones · 2020 Ch 2在复杂系统里导航 — 三条边界里只有安全不会提前喊疼，所以漂移是受力结构的必然解，不是谁的失职Rosenthal & Jones · 2020 Ch 3原则总览 — 混沌工程是实验不是测试：五条原则把「我以为它扛得住」变成一句能被当场证伪的假设Rosenthal & Jones · 2020 Ch 4Slack 的灾难剧场 — 对没为失败设计的老系统，第一步不是装工具，而是文档、预演和一个量过耗时的中止方案Rosenthal & Jones · 2020 Ch 5Google 灾难恢复演练 DiRT — 技术冗余大多是好的，真正的单点在流程、文档和人身上，所以演练要连人一起摇Rosenthal & Jones · 2020 Ch 6微软：实验的变化与优先级 — 故障空间组合爆炸而预算只有几十次，所以真功夫在排序而不在注入Rosenthal & Jones · 2020 Ch 7LinkedIn：对真实用户负责 — 爆炸半径的单位是人不是机器，所以把故障挂在一次请求上，并给每级放量配自动叫停Rosenthal & Jones · 2020 Ch 8Capital One：在强监管行业落地 — 监管要的是证据，于是从非生产起步、把混沌挂上流水线门禁，用留痕换进生产的许可Rosenthal & Jones · 2020 Ch 9创造前瞻 — 混沌实验的大半价值在动手之前：逼每个人写下预期，分歧与答不上来处就是盲区Rosenthal & Jones · 2020 Ch 10人性化的混沌 — 组织也是分布式系统：人会是单点、沟通有延迟，用小范围可喊停的演练去摇它Rosenthal & Jones · 2020 Ch 11人在回路 — 混沌实验的产出是人的理解：执行可以自动化，为什么做、何时做、结果意味着什么必须留给人Rosenthal & Jones · 2020 Ch 12实验选择问题 — 该注入什么藏在成功里：从请求的血缘图算出最小致败组合，只试这些Rosenthal & Jones · 2020 Ch 13混沌工程的投资回报 — 「什么都没发生」最难证明：事故数会被提速吃掉，改用 Kirkpatrick 四层逐级举证Rosenthal & Jones · 2020 Ch 14开放心态、开放科学与开放混沌 — 坑踩一次就够：把演练写成别人能重做的实验卡片，把发现像科学成果一样公开Rosenthal & Jones · 2020 Ch 15混沌成熟度模型 — 别只数实验次数：用精细度 × 采用度两维定位，补落后的那条腿Rosenthal & Jones · 2020 Ch 16持续验证 — 把混沌从演练日搬进流水线：自动选实验、自动分流对照、自动判定与叫停Rosenthal & Jones · 2020 Ch 17走向信息物理系统 — 故障会伤到人时：FMEA 在纸上想象故障，混沌实验在仿真与台架上证实它Rosenthal & Jones · 2020 Ch 18HOP 与混沌工程 — 人为错误是症状不是根因：改情境而非改人，混沌实验找缺口不找人Rosenthal & Jones · 2020 Ch 19在数据库上做混沌 — 数据库的错是安静的：四层注入故障，再用「转账总额守恒」这类不变量对账Rosenthal & Jones · 2020 Ch 20安全混沌工程 — 故意犯个配置小错，验防线挡不挡得住、看不看得见、接不接得住Rosenthal & Jones · 2020 Ch 21结语 — 没人装得下整个系统，可靠性只能靠受控实验不断修正大家脑中的地图Rosenthal & Jones · 2020 Ch 1何谓数据工程 — 管的是数据生命周期而不是某个工具，坐在数据科学的上游打牢金字塔下三层Reis & Housley · 2022 Ch 2数据工程生命周期 — 每一站先问清问题再选工具，批仍是默认，实时要有业务理由Reis & Housley · 2022 Ch 3设计好的数据架构 — 好架构让多数决定可逆：九条原则托底，仓、湖、湖仓与网格各有代价Reis & Housley · 2022 Ch 4全生命周期选型 — 架构是战略、工具是战术：只为竞争优势自建，算总账也算换掉的代价Reis & Housley · 2022 Ch 5源系统数据生成 — 上游不归你管：别定时翻账本，跟着数据库日志抄变更（CDC）Reis & Housley · 2022 Ch 6存储 — 三层栈层层取舍：对象存储 + 列式文件 + 按需算力，计算存储分离其实是混合Reis & Housley · 2022 Ch 7采集 — 批只是在无界的流上划的边界：能增量就别全量，至少一次 + 幂等兜住重复与迟到Reis & Housley · 2022 Ch 8查询、建模与转换 — 少扫数据、先定粒度与口径、历史用 Type 2 保留，转换写成可重跑的代码Reis & Housley · 2022 Ch 9为分析与 ML 服务数据 — 信任错一次就走，先问谁用、口径只定义一次，反向 ETL 先装刹车Reis & Housley · 2022 Ch 10安全与隐私 — 泄露多半出在人和流程：用不着的敏感数据别收，权限只给够用的，加密只是基线Reis & Housley · 2022 Ch 11数据工程的未来 — 运维苦活被云收走，生命周期不变；从批处理的现代数据栈走向与应用闭环的实时数据栈Reis & Housley · 2022 Ch 1引论：一切都是复杂度 — 真正的天花板是理解力；能消除就消除，消除不了就封装，设计永不完结Ousterhout · 2021