没人因Uber 800万美元账本错误被炒？

# 没人因为 Uber 800 万美元的账本事故被炒？ 来源：https://news.alvaroduran.com/p/nobody-got-fired-for-ubers-8-million [](https://substackcdn.com/image/fetch/$s_!t-tn!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F14a8fa04-8488-4534-a1a8-63158b84137a_1920x1080.png) 过去十年，Uber 把自家账本系统重写了五遍。其中至少一次——甚至可能全部——原本可以避免。 根源在于激励扭曲：每一代“管钱”的软件都始于一份“终极方案”的新提案；不久致命缺陷暴露；再被下一份新提案取代。 每一次重写，都是某人的晋升素材。 至少 DynamoDB 那次本不必发生。2017 年，Uber 在 DynamoDB 上发布新支付平台，却集体忽视了一个关键点：*DynamoDB 按量计价*。 每一次读写，都要掏钱。 一单出行产生多条账本记录，Uber 每天 1500 万单， DynamoDB 再能扛全球高并发，也架不住“笔笔扣费”。 两年不到，成本飙到离谱： > 在 Uber 的规模下，DynamoDB 太贵了。于是我们只保留最近 12 周数据（热数据）在 DynamoDB，其余冷数据放进自研对象存储 TerraBlob（类似 AWS S3）。长期方案我们打算用 LSG。——《将万亿级账本数据从 DynamoDB 迁移到 LedgerStore》 上线两年就被替换，是灾难级翻车。 可历史却把这段经历吹成了“教科书”。2024 年 ByteByteGo 还在发文章点赞。 我不接受。今天必须拆穿。 我是 Alvaro Duran，本期是《支付工程师实战手册》——**地球上唯一专为“写钱代码”的工程师写的周刊**。每周 2000+ 来自 Stripe、Coinbase、Modern Treasury 的订阅者，一起深挖“让钱流动”的软件该怎么写。不为面试，只为**把活干到极致**。 一旦涉及钱，容错为零， stakes 拉满。 本期你将看到： - 为什么 DynamoDB 能做支付，却撑不起账本 - 一张餐巾纸能算出的百万美元账单 - 以及一个更扎心的结论 废话少说，开干。 先问：DynamoDB 做财务软件就一定是坑？ 未必。我此前写过 DynamoDB 在支付场景的潜力：零停机迁移、全球低延迟、内建复制与故障转移。对全球收单的高并发场景，它很香。 DynamoDB 虽不能保证跨分区线性一致，但 Region 内单分区强一致足够用。支付天然可拆分：一笔授权与另一笔扣款无需全局排序，因果一致即可。DynamoDB 用“你其实用不到的线性一致”换来上述福利，对全球高频企业，比 PostgreSQL 更合适。 但**账本不是支付系统**。 《你根本不知道账本是干嘛的》 账本不能说“这两账户互不干扰”。它的范围是“整个世界”。无法全局线性一致的数据库，吞吐再猛也白搭。 一句话：支付可以牺牲全球一致换高可用，账本不行。 《最好的支付数据库是你没用过的那款》 DynamoDB 计费分“预置”与“按需”两种模式，还可混用。主流关注读写吞吐，存储只是发票上的奶油。可对账本这种“重存储”场景，容量费用才是大头。预置能打折 50%+，但得先算准业务量。 想在 DynamoDB 上省大钱，必须先来“餐巾纸数学”。 2017 年，Uber 日订单约 1100 万。按每单 10 条记录、每条 5 WCU 算，日写入 5.5 亿次，单价 1.25 美元/百万次，日成本 687 美元。 听着不多，**一年光写就 25 万美元**。 年增速 3 倍的话，第三年写入费 225 万美元。读、索引、全球表再算同等量级，**一个账本烧掉 500 万美元**。 到 2020 年，数据攒到 1.2 PB，按 0.25 美元/GB·月，光存储月费 30 万；三年累计 350 万美元。 读写+存储，**一张 800 万美元的账单**，就为了让本不该长在 DynamoDB 上的账本活着。 800 万美金的账单怎么办？写成案例，化腐朽为“战绩”。 2020 年起，Uber 把数据迁到自研 LSG（Ledger Store…Gateway?），底座是内部分布式数据库 DocStore： > DocStore 是多模型通用库，分区级严格可串行化，可水平扩展，支持事务、物化视图、关联、CDC，加上建模灵活、查询丰富，大幅提升开发效率并缩短业务上线时间。——《Schemaless 进化成分布式 SQL》 为啥不用开源？Uber 的基因就是自研。 你可能会说 DocStore 刚好满足需求。但**你错了**！ > 自研 DocStore 完美匹配需求，除了缺 CDC 流式能力……于是我们补了套流式框架 Flux 给 LedgerStore 做 Manifest。——《从 DynamoDB 到 Docstore 的金融数据迁移》 捋一捋：DynamoDB 贵（事先就能算出），你迁到当年已存在、却为别的业务造的 DocStore；DocStore 功能不全，再补一套流式框架。然后——**没人被问责**？ 他们优化的是晋升，不是成本。每次重写都是新提案、新设计文档、新简历条目。谁选“无聊却正确”？都挑“复杂且唬人”。 虽不是元宇宙级灾难，但在 Uber 体量下也足够刺激。 最气人的是：2019 年内部早已心知肚明 DynamoDB 是坑，AWS 邀 Uber 去 re:Invent 做分享，他们还是上台了。 我此前夸过 Uber 的测试实践，还上了 Hacker News 头条。但一码归一码：把烂决策包装成技术案例，跟在电视吹票的基金经理一样不要脸。 堪称“纵火犯写防火手册”。 第二层锅，属于那些无脑转发的媒体：ByteByteGo 文章高呼“迁移后年省 600 万美元”，我无话可说。 设计系统时，只看技术、无视成本，就是坑公司。 Uber 不是写错账本，是设错激励。 于是它花了几百万买教训。 本期《支付工程师实战手册》到此，下周见。 快把这篇文章转给那个正要犯同样昂贵错误的系统设计师。 [分享](https://news.alvaroduran.com/p/nobody-got-fired-for-ubers-8-million?utm_source=substack&utm_medium=email&utm_content=share&action=share)