前言
你知道华为的“天才计划”吗？这个天才计划就是用极高的年薪吸引一些顶尖人才。在这个计划中，有一位名叫姚婷的天才少女，以156万的年薪加入华为。
面对外界的赞誉和羡慕，姚婷却表现的并没有太大的兴趣。这位对百万年薪不屑一顾的姚婷究竟有什么过人之处呢？
今天我们就来了解一下一下这位90后的华为天才少女。
临近博士毕业时，我的一项工作GearDB（齿轮数据库）成为了WD公司的瓦记录磁盘最佳实践案例，另一项工作ComboTree（组合树）则通过合作项目落入了华为云100us EVS弹性卷服务的元数据索引层。将自己的学术研究应用到商用产品中，那种欣喜和成就感牵引着我加入了华为云。
2020年8月，博士阶段完美落幕，我带着对“未来要做出有价值的事情”的期待，挥别过往。我知道我将踏上一条与以往不同的路，它是陌生，是挑战，是一种新的生命体验，去打破和迎接一个不一样的自己。
博士毕业
01
从博士到工程师，打造云原生文件系统底座
初入职场，我怀着激动和兴奋开启了我的第一个项目，和团队一起构建华为云的首个高性能分布式并行文件系统SFS Turbo，将一个单节点架构的文件系统分布式化。
文件系统是一项“古老”的技术，至今已有几十年历史，但在云计算下，它是一个崭新的概念。因为以Web 2.0为推手的云计算从诞生以来，就是以对象存储和云硬盘为核心的，文件系统涉及复杂的协议，云原生文件系统绝不是复制传统并行文件系统的架构概念。SFS Turbo团队是一支非常年轻的队伍，平均年龄不过二十五六岁，我们也都是文件系统的新手。我的首要任务是，确定下一步架构演进的策略和重点发力方向，这是项目中最关键、最承重的部分。尽管在博士阶段，我已经通过合作项目对云系统架构有了初步了解，但仍缺乏产业背景。如何在短时间内构建一个云原生文件系统，要考虑的要素还有很多。
师父涛哥仿佛看出了我的担心和忧虑，鼓励道：“云原生文件是无人区，还处于起步阶段，但我们可以充分利用‘二八原则’选定场景和客户，进行迭代式的竞争力构筑，你多跟大家一起深入讨论，大胆决策。”师父的信任让我逐渐卸掉了包袱，和小伙伴一起进行业界分析、客户调研，我们决定保持战略定力，把特性优先级降低，优先解决架构扩展性，实现数据扩展。
选定了方向，怎么干？在我来之前，云存储已经构建了初代SFS Turbo，基于单节点实现了数据处理、元数据处理、协议解析等基本功能。我们这支全新成立的SFS Turbo 2.0升级团队的任务，是要对单节点文件系统进行架构升级，使其具备横向扩展，高性能并行运作的能力。视图如何管理、请求如何打散、数据如何拆分、元数据分散后的一致性、缓存的一致性、时延的稳定性、故障后用户无感知的恢复……这些都成为摆在SFS Turbo团队面前的难题。
学术研究往往是盯住一个特定的领域进行深入研究，而工业产品却需要从整体系统工程的角度来思考。我需要的是快速转变思维模式，从“单点优化”进阶到“系统工程优化”。于是，提升系统工程能力，成了我的第一个目标突破点。设计系统必先理解系统，我从啃下SFS Turbo的初始单机代码入手开始“补课”，数万行的体量、积累十数年的复杂框架，给了我入场系统工程的第一个“下马威”。作为一个骨子里有点“倔”的湘妹子，我在工位开启沉浸模式，通过走读代码、画流程图、思维导图这样的笨方法，去找拆分进程“最优雅”的位置。随着研究的深入，我和小伙伴们激荡思辨，从迷茫到坚定，从焦虑变得踏实，系统架构逐渐梳理了出来，新系统架构也仿佛一幅画卷徐徐展开。
在主管辉哥的带领和小伙伴们的高效协作下，我们在8个月内完成了SFS Turbo从初代到2.0版本的跨越式升级设计和原型开发，比原计划提前了4个月。SFS Turbo读写带宽上限由单节点2GB/S提升到无上限的性能弹性扩展，奠定了华为云并行文件系统的业界领先地位。由我设计和开发的几个核心读写流程、元数据进程和公共数据缓存组件性能表现优异。
此时，我悬着的心稍稍松了一口气，把自己的知识运用起来为云存储产业添砖加瓦，在这条新的旅途上，我初具信心。
然而，从学术研究到工程师的转身并非完全顺利，其间甚至经历了不少内心的矛盾与挣扎。商用方案的设计不仅追求高性能，同时也要简洁、复杂度低、组件化，不能为了性能损失数据的一致性和可靠性。这让一个在创新点和性能上“无所不用其极”、每篇论文都标榜“达到多少性能提升”的博士感到很不适应。我常常下意识地自问，我的设计会不会缺少创新？一个方案兼顾创新和商用的平衡点在哪里？时间和精力上的拉扯，从学术研究到职场的转身，我仿佛给自己设置了一些人为的障碍。
不过，随着一次次方案讨论和评审，我在心里反复锤炼思索，认知和行为也在悄然转变。在这期间，师父涛哥给了我很多指导和建议，使我认识到在公司做研究和高校不同，要以商业价值为首要牵引，而非盲目追求技术创新。从研究到产品，却又不愿意放弃研究，我走上了一条“痛并快乐”的路。
02
从工程师到团队负责人，解决性能“最后一公里”难题
SFS Turbo 2.0项目前期，知识的快速填充让我每天都很充实，但随着后期进入循环往复的性能调测，我开始变得慌张，我看不到自己的独特价值了。我默默告诫自己要沉下心来，腾出时间着手调研最新的研究和论文。尽管SFS Turbo 2.0已经实现了一轮架构升级，但学术界和业界还在演进着更先进的理论和技术，未来云存储产业发展的风向标是什么？我们能不能提前做好准备，迎接风口呢？
看到了问题和难点，看到了系统架构中的瓶颈，原本的忧愁迷茫消失殆尽，我又开始充满了干劲。
在SFS Turbo 2.0系统中，有一类数据叫做元数据，它记录着文件名、创建时间、权限等属性，简而言之，元数据就是描述文件数据的数据。它就像图书馆的“图书索引”，有了它，图书名称、编号、作者、主题、简介、摆放位置等信息一目了然。随着大数据、人工智能等技术在各行各业开花结果，小文件、读写密集的场景是未来云上高性能并行文件系统的一个重要角力场, 而我们现有系统还无法为高元数据性能需求的场景提供充分的性能支持。因此，我推测SFS Turbo 2.0系统中元数据的扩展性将成为未来发展最大的瓶颈。
通常业界将大小在1MB以内的文件称为“小文件”，百亿级数量及以上称为“LOSF（海量小文件）”。对于LOSF而言，IOPS/OPS（每秒操作次数）是关键性能衡量指标，虽然小文件的数据量小，但是每个文件的元数据量不变，这就导致系统的元数据量非常庞大，因此元数据性能对于小文件的访问效率至关重要。如何高效存储访问海量小文件，是各大云厂商都遇到的瓶颈。这是与友商的较量，也是和自己的赛跑。时不我待，我们必须分秒必争快速攻克关键核心技术，抢占先机，赢得优势。
经过SFS Turbo 2.0项目的历练，我已经快速转身，成长为存储团队的骨干力量，这一次我想继续挑战自己，独自带领团队完成这一特性。经过与业务主管辉哥沟通，2021年5月，我终于迎来了第一个自己独立负责的大任务——MDS Turbo（极致弹性分布式元数据管理系统）。主管还调配了一支预研小分队来支持我，我们需要从零构建起极致弹性的分布式组件MDS，实现元数据扩展，以支撑海量元数据IO（输入/输出）场景，解决海量小文件、元数据千万IOPS（每秒进行读写操作的次数）的竞争力难题。
带着SFS Turbo2.0项目中对产品化设计与开发的理解，我们启动MDS Turbo设计。在第一阶段，我先输出了公共组件：自研分布式键值存储EDB（弹性分布式数据库）和自研轻量级事务，能够服务于各种需要高性能索引的场景。在第二阶段，我着手于元数据集群按需弹性扩展，使元数据集群动态满足各种规格需求，支持百万、千万OPS的元数据服务。从EDB到MDS Turbo单节点形态，再到MDS Turbo集群形态，我没有经验可循，从零开始摸索设计开发，跟团队的小伙伴们互相鼓劲，一起梳理技术关键点、重构、产品化。
中途，由于“私有客户端”“读缓存”“容灾备份”等紧急、重大客户需求的到来，让MDS Turbo断断续续“持续难产”，团队成员也几度更迭，从设计到原型经历了近一年半的痛苦拉扯。每一次，当我负责接手其他更重要的需求，我都会给MDS Turbo打上一个小结，而每一次小结对我而言都是一次痛苦的割舍。重新回到MDS Turbo时，可能又是一个新的3人小团队，再次串讲、熟悉架构和代码。
最终，经过大家的共同努力，我们终于实现了千万级元数据IOPS，也为突破自动驾驶、EDA（电子设计自动化）等海量小文件场景储备了关键能力。我和团队的小伙伴们人均自研2万多行代码，在设计与开发之余，我用14天迅速完成了一篇专利、一篇论文的撰写和投稿，及时打结，提升华为云的业界影响力，“在攀珠峰的过程中沿途下蛋”。至此，我完成了博士到工程师再到特性团队负责人的角色转身。
03
从特性团队负责人到领域架构师，协同车BU完成自动驾驶场景业务攻关
随着MDS Turbo的交付，我具备了端到端设计和交付能力，组织任命我为SFS Turbo的领域架构师。师父告诉我，下一步SFS Turbo服务技术架构和竞争力如何构建，就要由我来指引方向了，对我来说，最大的转变是从单纯的架构设计到服务竞争力规划。
回顾来路，我对于云存储产品架构规划的理解，由浅入深，大体可分为三个阶段。第一阶段，聚焦内功。当时并行文件系统的场景林林总总，而我们的客户群体尚小，尚未看清战场，因此只能以性能和先进技术驱动架构升级。第二阶段，聚焦场景，我意识到产品不能刻意追求极致性能，纵然技术储备要看得够远，但商用的强诉求只会随着真正的核心场景到来。随着SFS Turbo在商业上的进步，越来越多的重点客户开始显现，我跟着师父涛哥一起勾勒出云存储领域的大项目画像，SFS Turbo最终明确了两个核心场景，即高效的企业NAS（网络存储）和高性能缓存加速。
这是我架构师生涯的一次巨大进阶，以核心场景为依托，在场景之上做规划，架构演进方向和团队目标都更加明确。然而，一个优秀的架构师还要精打细算，如何在有限的人力下，围绕重点场景，按照客户痛点的重要性和普适性梳理技术演进节奏？我思索着如何在逼近我们理想架构的同时，切实提升重点用户的使用体验、彻底打穿一类场景。带着这个设想，我决定深入一线，听最真实的炮火，攻关重难点项目，很快我们就争取到这样一个机会。
2023年6月，在一次与车BU ADS云与数据平台开发部的交流中，我介绍了我们开发的AI场景下读加速方案，重点突出可随负载弹性扩缩的优势。这是我第一次主导客户交流，虽然辉哥在旁坐镇，但我的心里还是紧张的，像是在谈一单“很大的生意”。车BU的业务主管和客户对SFS Turbo很感兴趣，他们提到自动驾驶训练正是海量小文件场景，后续有机会可以详细聊聊如何适配和使用，了解我们的技术优势。我脱口而出：“择日不如撞日，就现在聊聊吧！”大家先是愣了一下，接着哈哈大笑。这次讨论过后，客户最终答应给我们一个机会，将一个小业务迁到SFS Turbo进行联测。
我格外珍惜客户的信任和第一手信息，了解到他们当前的AI训练场景，每天新增几百万小文件素材，总数据集往往达到PB级别（petabyte级），需要在大压力下保持稳定的低延迟；而客户当前使用的方案，每个计算节点有大量冗余的元数据，需要缓存几千万文件，一轮训练要耗费一天以上。听到这里，我有信心我们不仅能帮助他们缩短训练时间，而且也能提供成本效益更高的方案。于是，我和团队紧锣密鼓地进行部署、对接、联测。很快，Turbo交出了第一轮测试的答卷，性能快速提升15%。
然而，这个结果并没有使车BU立刻将商用业务迁到SFS Turbo上。作为架构师，我告诉自己：不要被动等待要主动争取，场景需要打穿，不能浅尝辄止。我了解到，客户虽然认可SFS Turbo方案在AI训练中的可行性，但担心更高并发、更高强度的训练业务不会获得同样的性能提升，所以还有一些顾虑。于是我提议开展与车BU、客户的第二轮深入沟通。
这一次车BU同事带着极大诚意，不仅了解了我们的高并发能力，还提出了他们当前AI训练“上海集群”的最大痛点，即“缓存池容量不足时，部分请求下发到OBS（对象存储服务），使得读请求时延从几毫秒上升至百毫秒”，性能骤降，严重影响训练效率。
了解到客户的真实痛点，我有信心以高并发性能为杀手锏的SFS Turbo能够在更大并发下获得更显著的性能提升。随着第二轮生产环境测试结束，SFS Turbo方案减少了近24小时的训练时间，在第一轮结果基础上，性能再次提升了20%。大家喜出望外，车BU也终于放心地决定，将上海集群的GOD（通用障碍物标识）和BEV（动态感知）业务全部切换至华为云SFS Turbo服务。
从2022年8月至今，我和SFS Turbo的小伙伴们完成了自动驾驶、EDA、语音训练、大语言模型训练和推理等多场景攻关。我的技术规划终于踏上正轨，形成了商业闭环。从一个个实际的项目攻关中，我不仅加深了对行业、客户场景、业务的理解，也从攻关成功中获得了“事成人爽”的成就感。通过在云存储服务产品线上做架构和技术规划，直接参与攻关项目和深度客户交流，为我的创新和研究储备了丰富的宝藏。
入职三年来，我利用项目间歇，累计发表了6篇论文、3篇专利，组建了一支实力过硬的云存储骨干团队，这些都是我职业生涯中的宝贵财富。论架构师的自我修养，除了技术无止境，我更想成为双手沾泥的实干家，和团队一起脚踏实地，走入云存储的烟火。
04
抓住时代机遇，打破边界，AI Turbo持续进阶升级
在AI场景中，基于文件语义存取的生态，使得高性能并行文件系统再次焕发生机。SFS Turbo在2023年9月的全联接大会上，作为AI存取加速的解决方案正式地登上舞台。在AI Native Storage（人工智能原生存储）的大命题下，Turbo迎来了它的又一轮进阶升级——AI Turbo。区别于泛泛而谈的IO特征或性能需求，“确切的问题”是AI Turbo研究最好的养料。
参加华为云HC开发者大会
在大模型训练中，训练集群故障频率高、故障影响大、恢复时间长就是这样一个“确切的问题”。2023年9月27日，SFS Turbo团队收到会战任务，目标是将检查点写入时间降低到1分钟，故障恢复时间降低到2分钟。然而此时，大模型故障恢复的检查点加载实测需要N分钟！这是一个对学术界和工业界都足够新颖的难题，要知道一个千亿大模型，万卡训练的检查点读流量高达N TB，2分钟内要加载N TB的数据，意味着带宽需要X B/s。要达到TB级的带宽，利用云原生文件系统的弹性能力，扩充资源以补足性能需求，是一种自然而然的解法，但这样做无疑会带来巨大的成本开销。因此，我们的难题不仅仅是打造极致的性能，还要相较原方案不增加成本！
作为大语言模型训练加速的负责人，我陷入了巨大的质疑，不增加成本提升60倍性能，真的可能吗？攻关小组的小伙伴们聚到一起，对着这个指标连连叹气。面对TB级带宽的场景，我冷静下来，首先能想到的还是练好内功，夯实横向扩展能力。
大模型会战组EI部门、MindSpore（昇思，华为全场景AI计算框架）团队、SFS Turbo团队经过近一个月攻关，2023年10月22日，周日上午7点，我们终于迎来了第一场会战演练。大模型快恢EI团队负责人赵军，大语言模型负责人杜凡义，为大家争取到了极其珍贵的5小时时间，使用两千张卡进行大模型快恢实测！5小时，各个团队要验证各自优化点，大家都摩拳擦掌，分秒必争。尽管SFS Turbo准备充分，但当训练规模首次扩展到两千卡时，在巨大并发压力下，还是跑出了问题。我们必须迅速解决故障，重新上传代码，调整文件系统挂载方式，还要在周末协调平台部门同事配合操作，这一次我们真实体会到了作战的紧迫感。
最终，这次演练测出了13分钟的检查点加载性能。虽然性能提升了，但是距离2分钟还差得远，做到极致弹性之外，我们还能做什么？性能和成本又该如何兼顾？
解决这个难题，理解大模型训练的原理、理解大模型对云存储的读写逻辑尤为重要。通过与各部门联合实战演练，以及一个多月来与MindSpore团队、大语言模型团队、ModelArts平台的频繁交流，作为云存储的架构师，我端到端地看到了计算框架、平台和模型训练的全栈软件。到这里，我从代码层面理解了N TB读检查点数据量的真正成因，这也是华为端到端全栈解决方案的优势！作为自诩“一月速通”，存储业务中最了解大模型存取的人，我想，我找到了这个难题的解题方案。
为了不影响团队主线任务攻关，我找到业务主管汇报了我的双线计划。一方面，SFS Turbo主线人员仍在存储能力上发力，突破存储能力上限，另一方面由我带领3位实习同学启动AITurbo.CKPT（AITurbo检查点模块）的SDK快速设计与开发，我们兵分两路，火力全开。
区别于标准而传统的存储语义接口，AITurbo的目标是为存储找到AI、大模型场景中通往上层生态的入口，承担联接存储系统、上层应用、计算框架、AI平台的重要职责。AITurbo.CKPT通过与Mindspore深度配合，创新地实现了基于内存的多节点多副本检查点、提升了写入时间和故障恢复速度，同时还能为上层训练找出最近的、完整的、正确的检查点。
2023年11月16日，第二轮会战演练启动，迎接考验的时候到了，我们的AITurbo.CKPT发挥了巨大优势，达成11秒写入1TB数据，25秒加载2TB数据，每节点加载数据136GB，并且恢复时间独立于集群规模！业界的最佳方案Azure的Nebula，是5秒加载20GB数据，对比之下，我们的性能优势比Nebula足足提升了3倍以上。当日志文件打出11秒、25秒的数字时，所有人都惊呼了起来，我内心也百感交集，AITurbo成功了！好消息还不止这些，SFS Turbo 客户端在相同节点数的集群中提升了3倍带宽，我们的双线策略圆满成功！这是体现华为云全栈优势的一个优秀案例，也是云存储迈出存储协议制约的第一步，意味着未来大模型的数据加载、大模型推理、AI训练的数据预处理、推荐模型等场景中还可以孵化出AITurbo.dataloader, AITurbo.Preprocessing,AITurbo.Inference,AITurbo.Recommendation等更多独特的“华为云竞争力”。
在华为、华为云的全栈优势下，作为云上数据的底座，云存储的平台是广阔的，它区别于上层应用，虽然有存储协议的约束，但却又能最大程度的“看见”各种各样的客户和场景。从AI场景出发，从与各个业务的深度理解出发，我相信“不受限的存储边界”这个有趣的课题，会在云存储小伙伴们的共同努力下，得到更好的发挥，也期待未来更多的有识之士、新生力量加入我们的团队，百舸争流，乘云而上！
05
结语
从SFS Turbo 、SFS Turbo2.0、MDS Turbo，再到 AI Turbo，伴随着SFS Turbo服务的架构不断升级，我也在升级，变得能够理解和处理更复杂的状况、更复杂的情绪、更多线程的工作。
在此，要特别感谢支持鼓励我的师父、主管，包容我的同事们，一起攻克难关战友，一起开怀大笑的伙伴，感恩我在一个年轻而友爱的团队。我想我正朝着最初的理想“运用我的知识和能力，在增进人类智慧的领域上耕耘”稳步前进。
行路亦莫忘初心
工作之余，我会出去走走，去陌生的地理坐标上看看世界。脱离熟悉的环境，知觉变得更为敏锐，但情感又变得更为柔和，生命的维度得以延展。旅行时，我曾在寺庙中抽中了一支上上签，上面写着：“要谨记待人温和谦卑，要持心端正，要保持努力。”这句平实而朴素的话时刻提醒着我，行路莫忘初心。
