菜鸟智慧新物流核心技术全解析
阅读数：63192018 年 12 月 14 日 16:00
2018 年天猫双 11 全球狂欢节已正式落下帷幕，最终成交额定格在 2135 亿元，物流订单总数飙升至 10.42 亿单，再次刷新历史记录。与往年的双 11 不同的是，为解决庞大的包裹量，数字化和精细化成为行业关键词，第十个双 11，是在智能物流骨干网协同下，全行业资源优化的一次大考，和依托 IoT 技术的一场新物流大练兵。
正如菜鸟网络 CTO 谷雪梅在 ArchSummit 2018 全球架构师峰会“菜鸟智慧新物流专场”致辞时所说，如何把平台、架构、算法、数据和业务场景融合在一起，为物流行业降本提效，同时促进行业技术不断向前发展，这是菜鸟技术人，也是整个智慧物流行业人最重要的使命。
那么，如何让无处不在 AI 技术在传统物流领域发挥必要的价值？柔性自动化这个新兴的技术方向将为电商物流带来怎样的变革？自动化仓储系统的技术和应用的算法又是什么？如何依靠数据、技术来进行统筹安排，打造敏捷供应链？带着对这些问题的解答，菜鸟网络研究员徐盈辉、资深技术专家朱礼君、裘民民、许俊开始了这场布道。
如何思考物流行业中人工智能的落地？
只有当物流资源变得可视、可预测、可控制，并能得到有效反馈，这时的物流体系才能真正实现降本提效。其中，资源共享是关键。菜鸟通过建立协同化 IT 技术平台，共享资源，并在物流网络中优化节点与连接，最终促进物流行业共同发展。
降本提效需要减少包括生产过多、生产过快、生产过晚等无谓资源浪费。菜鸟网络研究员徐盈辉在演讲中提到，对于双 11 所需求的大量商品，菜鸟会对消费者进行理解，并做到库存合理分布，在合适地方存放适当货量来避免一定的资源浪费。
值得注意的是，包裹从网点由快递员送到消费者的过程，是一个高频动态环节。为此，菜鸟围绕仓储物流智能化，优化了包括销量预测、实效预测、智能交互、机器视觉等技术。但由于数据量庞大，需要通过机器学习算法让消费者感知包裹位置，根据快递员的配送情况做合理的预测。此外，快递包裹的配送会根据目的区域做包裹再组织，进行合理 ETA 预测，并通过快递员的派送习惯，预测包裹时空特征，使得预测模型训练达到预期效果。
现如今，所有行业都需要让消费者知情。当快递员与消费者联系沟通时，这在无形中增加了快递员的工作负荷。包裹放置地点、包裹配送时间等问题都是需与消费者互动才能获得的时空特征，为此菜鸟围绕 POI 体系建立了 AOI 层次性地址知识图谱，通过智能交互机器人与消费者互动解决了这个问题。
对于物流在线决策的内容，徐盈辉讲解道，以前仓库大量拣选作业单都是人工完成，这样大大限制了算法在海量空间里做组合的效果。菜鸟打破了这个边界，让所有订单在仓库里更合理的组合并预测未来订单。同时，对订单的商品选择最合理的包材打包以此来降低成本。比方说，有 N 个商品，已知这些商品的三维尺寸，包材优化要做的事情就是根据这些商品的三维尺寸信息，计算一个最优装箱顺序、合理的朝向、正确的位置，找到一个包材，最终它的成本最小。
而在运输优化中经常考虑的一个问题是：货物如何以最短距离，最合理线路运到目的地。这是一个复杂的带有时间窗约束的多商品流优化问题，制定合理的优化目标就是希望使用较少车辆，包裹走最短的距离，最小的空载率，这是一个超大规模且不可追溯的混合整数规划问题。通过合理的问题拆解使得问题能被有效求解且可解释。
全流程优化的终极梦想——柔性自动化
中国劳动力总人口减少、电商仓库大、存储商品多、时效要求高等挑战推动着物流行业自动化的发展。对此，菜鸟网络资深算法专家朱礼君解释道：
- 电商订单变化快，业务变化也非常快。菜鸟通过人工智能技术，使得更多机器人解决物流自动化问题；
- 柔性自动化仓库的机器人灵活，容易扩张及改造；
- 柔性自动化控制逻辑非常复杂，这是一个缺点也是优点，这样可以把所有智能移到云端，即可进行性复制。从某种意义上来说，这也把难问题统一解决掉了。
在自动化仓库里面的做长距离搬运基本作业单元 AGV，可以从仓库里面任意两点之间进行搬运工作。在仓库相对可控一个环境，其导航定位方式可以设置多种：贴二维码、激光导航、视觉导航等。而比较成熟的自动化 AGV 系统，机器小车只需顶起货架，移动到工人处，工人再根据系统指示拣选对应的商品，单个拣选站故障也不会影响其余拣选站。
值得注意的是，在电商仓库中货架可以动态分布，并实行多区并行方案，同一个订单的所有商品到达合流区域才可出库，所有过程均自动化完成。菜鸟自动化仓储系统架构的最核心的调度引擎是调度算法，包括订单生成、拣选任务生成、合流区调度、多区协同调度等等都是由调度引擎完成。
如何为同时在同一仓库的机器人规划行驶路径？假设两个机器人都从 A1 到 A2，若都走最短路径时则会相撞，这时只能其一避让才可避免，为实现这个过程菜鸟对传统 AI 算法做了改造，在考虑机器人的加速度、减速度的基础下进行智能路径规划。
在演讲中，朱礼君还为大家分享了 AGV 网络掉线的例子：在很窄的通道中堆满机器人的“堵车”情景，其学术名词为死锁。那么提前避免死锁，或迅速恢复异常情况，这可能比在正常情况的算法还要重要。
对此，菜鸟总结了一套准则：所有模型都是理想化的模型。起初物流行业的目标就是优化总体吞吐量，调度模型也最简单，但这跟实际情况并不相符，并需要不断的自我质疑和假设。所以在最终的模型中，还需考虑目标各区域作业的均衡，从实践出真知，才是真正的物流优化。
双 11 物流能力应当如何沉淀？
双 11 是一个系统工程，需要极多人力物力的准备，而在双 11 大促之前，大数据最重要的使命就是帮助双 11 做一个确定性预计和预测。
菜鸟网络资深数据技术专家裘民民进一步分析：首先针对双 11 大促，菜鸟需要预测物流单量来决定后续社会化运力与仓储面积的筹备情况。但单量预测影响因素非常之多，除了每年的历史数据之外，更多的是日常变化的一些趋势。此外，预售工作的启动也同样可以帮助迭代优化单量的预估。
其次，整个订单的产生都需要经过商家的 ERP 系统进行处理，这条交易链致使整个信息的交互流过程变得十分复杂，这就涉及到商家行为分析。不仅如此，由于包裹量巨大，单量的实际仓库面积、网络流速、订单出库时间等等都会涉及预测与决策。为此，菜鸟从预测模型到优化模型，确定每个环节物流资源，把它工序化，并根据预测评估可以承受的行业物流成本，决定物流资源的整体布局。
一旦双 11 开始，菜鸟的首要任务就转变为，从技术角度监控包裹和物流订单以及实际作业的具体情况，因此菜鸟对实时计算和实时监控都有着非常高的需求。
双 11 当天菜鸟希望基于实时计算数据估计出总的订单量。但由于历史数据的有限性，致使去年订单量乘以比例的预估方式不切实际。因此菜鸟借鉴在机器学习里的特殊工程概念，把实际发生曲线和历史数据曲线相互做一些交叉和拼接，并进行动态调整，将这两步叠加起来才能预测一个比较好的结果。
对于比较抽象的数据分析，第一步为定位步骤，对应一个 top 指标，找到影响指标波动的细粒度维度。当确定定位以后，就可以开始第二步——推理，比如定位到某地，其为何发生如此变化，诸如此类为一个推理过程。
那么这些步骤可以通过技术解决吗？可以。对于定位来说，本质上就是找最关键组合，并计算出它对整个指标的贡献度。推理层面则需要找到指标与事件之间的关系，然后把历史事件与数据变化通过学习的方式找到，形成知识图谱，未来发生变化时就可较快找到数据变化对应的背后原因，并在很大程度上提高分析效率。
10 亿包裹背后的技术定义者——菜鸟智慧新物流
菜鸟智慧新物流到底是什么样？菜鸟网络资深技术专家许俊在演讲中从整体平台架构和工程技术角度进行了阐述。
汗水物流时代向智能物流新时代的演进，变化背后承载着这样的技术演变：信息化阶段与数字化阶段。早年大型物流园区里，单个机房需要上百人来运维，现在几万台服务器仅需一人管理。智慧新物流的体系结构到底是什么？首先要有一个智能化基础设施。其次，需要在很多核心的作业环节，实现柔性自动化的技术体系。最后，面向物流技术的前沿储备作为体系结构的基础服务层。
对于信息化架构，菜鸟的技术站和整体运维，在过去很长时间与阿里共享一个机房，并与淘宝、天猫很多技术一脉相承。这会带来一些新问题，第一，对于物流系统，资源的弹性会面临挑战；第二，物流系统搭建在在单机房中，这就演变为一个单点问题，但这并不具备多地容灾的能力；第三，全球化购买背景中，海外部署的基础架构也会发生大变化。
在这样背景下，菜鸟从 2017 年开始研发混合云架构，通过研发和运维系统线上线下一体化，保证研发体系的一致性。通过高速专线的方式，让云上 VPC 和 IDC 实现网络高速通信，实现一套代码多套部署，实现应用系统编程过程。
针对数字化架构，许俊基于技术角度阐述了关于物流领域借助数字化待需解决的问题：第一个维度，无论是物品还是装备，其数字化为主动性还是被动性的问题；第二个维度，物流领域的核心要素所存在的运动环境问题；第三个维度，物品是运动还是静止，比如某位置种 AGV 不断运动的情况是遇到网络问题，还是掉线。而其数字化思路就是基于数字化技术模型影射到中间技术架构，从感知层、连接层再到应用层，最终数据与上层物流、供应链业务系统进行数据回环，这与物流领域的 IOT 技术架构比较类似。
在演讲的最后，许俊分享了在安防方面菜鸟所做的尝试——“天眼”。当包裹经过商家发货流动到揽收网点，中间需要经历复杂的流转过程。为此，菜鸟在揽收网点、分布中心、驿站等中转环节架设大量摄像头，以保障整个物流的全程实时监控及反馈。
由于摄像头数量庞大，“天眼”系统面临的包括摄像头管理、在线率、视觉计算网络传输的稳定性等技术挑战被菜鸟统一归纳为大规模弱中心集成管理技术问题。把摄像头与云端对接，经过编解码体系为这个技术问题的解决方案，但若视频 24 小时不断上传，那么一家快递公司仅仅支付网络费用就已高达每年几千万。为此，菜鸟通过引入边缘网关和边缘计算体系，并对数据进行预处理，以此来降低成本。
未来，天眼上会集成越来越多视觉识别模式，所有都会通过菜鸟算法容器进行高效率算法迭代和新算法引入。而菜鸟天眼系统也将进一步与实时调度系统产生联动，通过云和端实现包裹全链路可视化，实现基于大数据之外的全新视觉管理体系。
英特尔发布 CPU 新架构，突破性采用 3D 堆栈法
- 陈思
阅读数：13622018 年 12 月 13 日 15:01
当地时间 12 月 12 日，英特尔在“架构日”活动中公布了下一代 CPU 微架构—Sunny Cove，这个微架构采用 10 纳米工艺制造，会成为英特尔下一代酷睿和至强处理器的基础。一同发布的还有全新的 GPU 核芯显卡。
据了解，新架构“Sunny Cove”有如下性能方面的提升：
1、单线程性能（仅此一点架构变化肯定就不小）
2、降低功耗（笔记本的续航时间有可能大幅增加）
3、 改进扩展性、可并行执行更多操作（或许是支持更多核心）
4、 可加速 AI、加密等专用计算任务的新功能
这一架构不同于过去，众所周知，传统的芯片结构为 2D 平面，但英特尔突破性地使用了 3D 堆栈结构，名为：Foveros。按照英特尔的说法：这样的结构就像乐高积木一样，甚至可能改变芯片结构的发展。
Moor Insights＆Strategy 首席执行官 Patrick Moorhead 表示，2D 方法可以实现多种多样，同时也会牺牲性能并消耗更多功率。而英特尔的 3D 堆栈结构似乎已经避开了这些问题。Moorhead 说：“当你把这些小芯片放在一起时，几乎没有功率损失，也没有性能损失。”不过，英特尔仍然需要证明这一结构可以在同样的投入中产生相同的结果。
英特尔采用的 3D 堆栈结构
电力传输也是英特尔认为已经解决的问题之一。几十年来，人们一直在寻求一种成功的 3D 包装技术，但由于电力、热量和价格等因素，这项技术一直未能实现。如果底层变热，热量就会上升，在 3D 堆栈的方法中，如果在组装完所有东西后意识到其中一层是坏的硅，那就只能扔掉所有东西。这样的代价是非常非常昂贵的。
英特尔从 AMD 挖走的芯片架构专家 Raja Koduri 对英特尔如何破解这些问题的细节守口如口。但他表示，结合严格的测试、新的供电流程，以及一种全新的隔热材料来散热，英特尔已经学会避免了典型的缺陷。
此外，英特尔还宣布将推出一个新的微架构，2020 年的新架构是“Willow Cove”（柳树海湾），主要是重新设计缓存，对晶体管进行新的优化，并有新的安全特性。2021 年的新架构是“Golden Cove”（金色海湾），继续提升单线程性能，并强化 AI、5G、网络、性能，同时继续强化安全。
除了发布新的架构，英特尔还发布了第 11 代核心显卡，独立显卡会在 2020 年发布。这意味着除了 AMD 或英伟达外，未来的 MacBook Pro、iMac、iMac Pro 和 Mac Pro 也可以选择英特尔的独立显卡。
据了解，第 11 代核显将在明年集成于 10nm 工艺的 Ice Lake 处理器，下半年发布，官方称会在性能、能效、3D 和媒体技术、游戏体验方面都有飞跃。Intel 宣称，新核显的每时钟计算性能会提高一倍，浮点运算性能突破每秒一万亿次 (1TFlops)。
此外，11 代核显 (GT2 级别) 会集成多达 64 个执行单元 (EU)，比现在的 24 个多了将近 1.7 倍。它们分为四个区块 (slice)，各有两个媒体取样器、一个 PixelFE、载入 / 存储单元，然后每个区块又细分为两个子区块 (sub-slice)，都有自己的指令缓存、3D 取样器。
EU 内的 FPU 浮点单元进行了重新设计，但是 FP16 单精度浮点性能不变，同时每个 EU 继续支持七个线程，暗示还是 512 个并发流水线，同时重新设计了内存界面，三级缓存增大至 3MB。
Intel 还披露了一些具体的细节，比如 D 流水线方面支持基于区块的渲染 (TBR)，重新设计了内存子系统等。
参考内容：
https://www.cnbeta.com/articles/tech/797865.htm
https://www.wired.com/story/intel-foveros-chips-breakthrough/
百度研究院今日再升级，迎来 9 位世界级科学家
阅读数：9502018 年 11 月 14 日 15:43
美国时间 11 月 13 日，百度研究院在美国硅谷召开会议，宣布百度研究院顾问委员会正式成立，并宣布在 2018 年陆续迎来 9 位世界级科学家加盟。当天，百度研究院院长王海峰领衔的百度研究院顾问委员会和核心科学家亮相百度美国办公室。
新成立的百度研究院顾问委员会共包含 5 名成员，包括 AT&T 和贝尔实验室前副总裁及首席科学家 David Belanger，伊利诺伊大学厄巴纳 - 香槟分校终身教授、计算机视觉领域顶级科学家 David Forsyth，著名的计算语言学专家 Mark Liberman，卡耐基梅隆大学终身教授、机器人技术领域专家 Martial Hebert，明尼苏达大学终身教授、知识发现与数据挖掘（KDD）领域的最高技术荣誉 ACM SIGKDD 创新奖得主 Vipin Kumar 等，均是国际上享有盛誉的知名科学家。
这些科学家的研究领域包括信息挖掘、计算机视觉、语音技术、机器人、大数据挖掘、商业智能等，几乎囊括了 AI 领域从底层基础到认知、感知技术的全领域范畴。他们将成为百度研究院的「智囊」，带来最顶尖的研究经验，推动产出更多拥有世界级影响力的研究成果。此外，顾问委员会也将基于对百度 AI 技术的了解，为百度提供 AI 发展趋势的判断和未来研究方向的建议。
百度高级副总裁、AI 技术平台体系（AIG）总负责人、百度研究院院长王海峰在现场发言中对各位顾问委员的加入表示热烈欢迎。他提到，学术研究一直是产业间 AI 核心竞争力的重要组成部分。此次新成立的顾问委员会将为百度研究院的 AI 研究注入学术端的血液，让百度研究院在前瞻性的研究方向上，更具深远布局。未来我们将与这些科学家一起，继续去突破解决 AI 问题，用 AI 更好的服务社会和普通人的生活。
发展数年来，百度研究院不仅汇聚了 Kenneth Ward Church、吴华、李平、熊辉、杨睿刚、浣军、马艳军等国内外 AI 领域世界级专家, 还在 2018 年陆续引入了自然语言理解、机器翻译领域专家黄亮，计算机视觉和生物特征领域专家郭国栋，悉尼科技大学教授、计算机视觉和人工智能专家杨易，马里兰大学终身教授、马里兰大学帕克分校计算机科学系及电气与计算机工程系主任、自动驾驶和机器人领域领军人物 Dinesh Manocha 等科学家及顾问。
百度研究院顾问委员会成立大会上，新加入的顾问委员分别就当下最热门的 AI 研究领域进行了分享，并发表了自己的观点。
目前，百度研究院旗下共有深度学习实验室（IDL）、大数据实验室（BDL）、硅谷人工智能实验室（SVAIL）、商业智能实验室（BIL）和机器人与自动驾驶实验室（RAL）5 个实验室，覆盖了包括自然语言处理、计算机视觉、语音技术、大数据、自动驾驶和机器人以及通用人工智能技术等全领域，重点聚焦前瞻基础技术探索，布局 AI 未来方向。
会上，百度研究院还公布了近期在自然语言处理、语音、高性能计算、深度学习等 9 个领域的重要成果。
-
在自然语言处理（NLP）领域，百度构建了最大的中文异构知识图谱，研发基于多文档校验的阅读理解技术、基于交互式学习的对话理解技术等，在 AI for Prosthetics Challenge 等国际知名赛事中屡获冠军。目前百度 NLP 技术几乎支持百度所有应用，每天被调用超过 3000 亿次，并通过百度 AI 开放平台对外开放。
-
基于自然语言处理技术和语音技术，百度建立了世界上第一个具有集成预期和可控延迟的语音实时翻译系统，这一技术已被成功应用于百度同传产品中，并在 11 月 1 日的百度世界大会上进行了展示。
-
在语音合成领域，百度提出了第一个完全端到端的深度神经网络模型，可合成出接近于真人声音的语音。
-
在 AI 医疗领域，百度发布了拥有强大的肿瘤病理切片检测能力的「神经条件随机场」算法，可为癌症诊断和治疗提供重要助力，其检测准确率已经突破此前最高记录，甚至超过专业病理医生。
-
在机器人领域，百度开发了世界首个基于视觉的低成本建筑机械传感控制系统。基于该技术打造的无人挖掘机，可减少 40％人力成本，同时工程收益可以提升 50%。
-
在商业智能领域，百度致力于区域画像、POI 知识图谱和用户画像等基础能力的研发，生成了数以千万条 POI 属性和数以亿条关系数据，完成了多尺度百万级区域的百余项指标的计算，并将这些能力成功应用于数读城市和百度地图的智能出行等产品中。
-
在高性能计算领域，百度作为主要创始机构发布了国际业界公认的开源深度学习性能基准平台 MLPerf 并产生巨大影响力，目前已吸引了 50 多家公司，和哈佛等 7 所顶级大学加入。
-
在深度学习平台方面，作为国内唯一开源开放的深度学习框架，PaddlePaddle 近期正式发布了 1.x 的稳定版本，并在官方支持模型的完备性、超大规模深度学习并行技术和高速推理引擎等技术领域取得了领先优势。同时，PaddlePaddle 持续降低深度学习门槛，深度赋能各行各业，助力实体经济发展。
-
基于开放普惠 AI 理念，百度还开发了自动深度学习技术 AutoDL，支持深度学习的自动设计、迁移和边缘计算适配。AutoDL 的设计能力已经通过百度平台 EasyDL、AI Studio 免费向开发者开放，广大中小初创企业和个人无需特殊软硬件和工程团队，也能建立强大 AI 模型，加速 AI 应用落地。
-
在大数据方向上，百度快速检索算法处于世界领先地位，同时专注开发实用机器学习算法平台，该算法在搜索、信息流、知识图谱等百度关键产品和技术上发挥着重要价值。
围绕核心 AI 技术，百度已构建起完整的 AI 技术布局，包括算法、算力、大数据等底层基础，语音、视觉等感知技术和知识图谱、自然语言处理等认知技术，深度支持百度搜索、信息流、百度地图等内部业务，并通过百度 AI 开放平台对外开放 130 多项 AI 核心能力。王海峰表示：“我们对人工智能的探索将不断前行，未来无止境。”
解秘：百度 PaddlePaddle 深度学习框架和搜索引擎基础架构
阅读数：68092016 年 10 月 24 日 08:00
前不久在百度世界大会上，百度首席科学家吴恩达首次宣布对外开放百度深度学习平台，以推动人工智能技术的快速普及，把在搜索、图像识别、语音识别、自然语言处理、用户画像及情感分析等人工智能领域的优势整合升级，为程序开发者提供了一个功能更全、效果更好的深度学习框架。
其实，百度很重视对于开源软件的使用，也愿意把内部的技术以开源的形式贡献出来，正如在 10 月 22 号由百度开发者中心、百度开源委员会联合举办的第 67 期“百度开源专场”技术沙龙上，来自百度的工程师于洋和颜世光，分别分享了百度开源的两个最新项目：PaddlePaddle 百度深度学习框架和百度搜索架构开源产品线（例如 Tera、BFS、Galaxy 等），并结合具体的产品案例，分享百度开源技术最新实践经验。目前这些项目都已经在 github/baidu 上开源。
什么是 PaddlePaddle 深度学习平台？
首先做个简单的介绍，PaddlePaddle 是百度自主研发的性能优先、灵活易用的深度学习平台，是一个已经解决和将要解决一些实际问题的平台。目前百度有超过 30 个主要产品都在使用 PaddlePaddle。关于机器学习、深度学习和浅层学习的内容就不详细介绍了，接下来重点讲述一下 PaddlePaddle 的整体架构。
关于 PaddlePaddle 整体架构（ PPT 下载）
说到 PaddlePaddle 的整体架构，主要从这几个方面入手：多机并行架构、多 GPU 并行架构、Sequence 序列模型和大规模稀疏训练。多机的并行架构和序列模型的实现都是实现神经网络最复杂的东西，那么具体怎么实现全连接？
PaddlePaddle 是 2013 年启动时比较流行的架构是 Pserver 和 Trainer 的架构。在多机并行架构中数据分配到不同节点，下图里灰色部分表示机器，方框里表示一个进程，Pserver 和 Trainer 是分布在两个进程里，中间的部分是网络通讯连接。
下面来介绍一下什么是大规模稀疏模型训练。稀疏模型训练是说输入数据是稀疏的，由于稀疏输入，那么灰色的神经元和连接在训练中都没有作用，灰色神经元的输出是 0，灰色连接的梯度是 0，梯度是 0 的话，简单的 SGD 不更新权重。所以只有蓝色的连接有价值，需要从 PServer 服务器获得最新参数，需要计算梯度，并将梯度传送回参数服务器。（如下图）
除了上面所提到的，还有两外两种情况下的稀疏模型：
- 大规模稀疏模型（多机器）——每个 Trainer Prefetch 出自身需要的参数和服务器通信。
- 大规模稀疏模型（正则化）——简单的 SGD 确实在梯度为 0 的时候，不去更新参数，但是加上正则化就不一定了；比如 L2 正则化，就要求参数的 2 范数持续减小。
PaddlePaddle 实现时的一些思考
基于 OP（操作）还是基于 Layer（层）？
- 基于 OP——从矩阵乘法配起，一步一步对应一个一个数学运算。
- 基于层——直接写一个全连接层，LSTM 层。
- 基于 OP 的优势 Tensorflow——更灵活，更可以让研究人员构造新的东西
- 基于 Layer 的优势 Caffe——更易用，让细节暴露的更少；更容易优化。
基于 OP 还是基于 Layer？——支持大部分 Layer，但是也支持从 OP 开始配网络（矩阵乘发，加法，激活等等）；对于成型的 Layer（LSTM）使用 C++ 重新优化。原因在于，PaddlePaddle 是企业解决现有问题的框架，不是纯粹的科研框架；企业需要性能，也需要灵活性。
多机通信基于 MPI 还是 Spark 还是 K8s + Docker？PaddlePaddle 底层通信不依赖于任何网络框架，PaddlePaddle 的网络任务需求相对简单，根源在于任务周期短（连续运行几周）；任务可以失败（多存 checkpoint）。同时，PaddlePaddle 的网络需要高性能，从头手写网络库更方便性能调优，RDMA 可以更好的支持。同理，PaddlePaddle 底层不依赖任何 GPU 通信框架。
百度搜索开源基础架构（ PPT 下载）
颜世光是百度搜索基础架构负责人，在这次沙龙上介绍了百度当前的这套搜索引擎，以及搜索引擎背后的事件。重点部分是百度这套开源的基础架构软件站，它包括分布式数据库、文件系统、管理系统、分布式协调服务、网络通信框架。下面来一一介绍。
当前，用户通过互联网搜索引擎的期望在不断的变化，整个搜索引擎的期望从之前的几周变成现在的几分钟，之前几周之内可以处理几百亿的数据，现在要在几分钟之内处理几万亿的数据，这是个鲜明的矛盾。其实解决方案就是构建一个大数据处理平台，也称之为“基础架构系统”。这个基础架构系统目标首先是海量的目标数据。其次就是在于集群利用率的保证，这个利用率可能是 CPU 利用率，它会为你节省成本。
这里可以简单介绍一下百度内从事开发的平台——baidu stack（如上图）。这个平台分三层，最的底层是网络通讯，是一个高性能的 RPC 框架，它会把所有的网络问题屏蔽掉，让上层的系统在开发中不需要考虑网络拓扑。中间一层是基础服务，包括分布式文件系统，它解决了数据处理。第二就是集群管理系统，它管理的数据可以让程序部署变得代价很小。第三是分布式的协调服务，一方面用做服务发现，另外就是分布式。最上层是核心数据库和数据处理系统。在理解上可以将这套系统和 Hadoop 相关的系统类比。从中间这层说起，Hadoop 有 HDPS，Hadoop 在分布式服务这块使用 Cukaber，比如也有 Storm、Spark 这些。整个基础架构系统的设计思想有两个，第一是分层。无论是 Hadoop 系还是谷歌，他们都使用类似的思想，这个思想主要是分工和借用，让不同分工解决不同问题。另外一个思想就是高效，解决用户对处理速度的期望。百度主要使用 SSD、万兆网卡，这套分布式基础架构完全是用 C++ 实现的。首先是核心的数据库 Tera，这里列了 Tera 数据库的核心功能，包括全局有序、自动分裂、合并、支持快照。
Tera 的架构可以看（如上简图），从图上我们可以看到它有核心就是绿色两部分，是 Master 和 TableServer，提供整个数据节点都是 TableServer，所有的访问经过 Master，让它扩展到几千台服务器中。灰色的底层数据都是在分布式文件系统上，自身没有任何数据，被设计成无状态，当一个 TableServer 宕机后，会从另外一个机器拉取数据，不会有任何损失。同样底层的分布式文件系统可以提供很大的帮助，它是通过 Nexus 做的。
这里简单介绍一下 Tera 的核心技术。⽔水平扩展方面能做到无单点；在线分裂、合并；⾃自动负载均衡；通过 LSM-Tree 做到实时同步，并且 Tera 还具有多语言支持的特点。Tera 在百度内部有非常广泛的应用，例如百度的网页库, 百度将万亿量级的网页存储在 Tera 中。
这里再介绍一下如上图的百度文件处理系统（BFS），不仅在百度，BFS 在外部的使用价值也是很高的。那么 BFS 具有哪些特点呢？首先是持续可⽤：分布式 Master，多机房数据冗余。其次就是实时高吞吐：慢节点处理，元数据管理。
因为篇幅有限的原因，这里就介绍这么多，更多详细的内容，大家可以下载两位讲师的演讲 PPT，也可以观看后期整理出来的演讲视频。
百度万亿量级数据库 Tera 架构应用、设计与实践全攻略
阅读数：24402017 年 5 月 25 日 19:00
信息技术发展突飞猛进，网络数据呈现爆炸之势，搜索引擎的实时性面临巨大挑战。百度搜索引擎每天处理着数万亿次的链接分析和数百亿次的互联网资源采集。作为百度搜索引擎的核心数据库 Tera，是如何支撑万亿量级的实时数据处理呢？
在 5 月 20 日百度开发者中心主办、极客邦科技承办的 71 期百度技术沙龙上，百度网页搜索基础架构技术经理齐志宏和资深工程师郑然，为大家免费放送了大型分布式表格系统 Tera 在百度搜索引擎中的应用、以及 Tera 架构设计与实践的全攻略。
Tera 在百度搜索引擎中的应用（讲义PPT ）
在讲解 Tera 的应用之前，百度网页搜索基础架构技术经理齐志宏首先介绍了百度搜索架构，百度搜索引擎的作用是连接人与信息、连接人与服务，信息抓取、索引构建、检索系统构成了搜索引擎最经典的三大板块。
互联网上的信息是如何通过搜索引擎最终展示给用户的？首先，网页被搜索引擎发现，通过抓取进入搜索引擎；然后，有价值的网页经过筛选，进行正排计算和倒排计算，完成索引构建；最后，通过检索系统将最终的结果呈现给用户。
伴随互联网信息爆发式的增长，百度搜索架构也在逐渐向实时化方向演进，在介绍完搜索架构之后，齐志宏从链接存储、索引筛选、用户行为分析三个场景切入，详细讲解了 Tera 在实时搜索架构中的应用。
齐志宏先为大家解释什么是 Tera：一种大型分布式表格存储系统，具有高性能、可伸缩等存储特点，最初的设计是为了管理万亿量级的超链和网页信息。Tera 在架构演进中到底扮演了怎样的核心角色呢？
首先来看存储链接。百度推出的 Spider 3.0 系统是基于 Tera 的实时架构，以 Tera 为核心，承载了链接库、网页库的存储，将原有基于 MapReduce 的批量计算转变为基于 Tera 的实时计算，实现每秒亿级的数据随机读写、每天处理万亿量级的链接操作，信息抓取模块（即 Spider）进入了实时处理时代。
第二个是索引筛选。索引筛选的核心作用是让有价值的信息进入索引。Tera 架构作为数据存储中心，存储了包含网页库、去重库、结果库在内的所有中间数据和最终结果，通过流式计算的方式完成页面特征拼接、页面价值计算、网页去重以及索引排序等核心操作的实时化改造。网页从抓取到筛选完成的整个过程，实现了从天级变到分钟级甚至秒级的飞跃。
最后一个是用户行为分析。用户行为分析在搜索效果改进和搜索引擎的评价等方面，都具有重要价值。基于 Tera 的实时用户行为数据流，将用户数据的时效性推向新高度。实时数据产出的延迟可降至秒级，突发时效性识别、用户意图分析、产品迭代评估等多个维度均可实时获取用户数据，进行实时分析，对时效性和用户体验有很大的提升。
总体上，Tera 支撑了着搜索引擎大规模的实时数据读写，将批量、全量计算转变为增量、实时的数据计算，极大的提升了搜索引擎的实时数据处理能力，Tera 是百度搜索引擎从批量处理迈向实时计算的架构基础。
Tera 大型分布式表格系统的设计与实践（讲义PPT ）
Tera 完成了百度搜索向万亿级数据实时搜索的跃进，成为炙手可热的数据库系统，那么，如何做好 Tera 架构的设计与实践成为开发者最为关心的问题。百度网页搜索基础架构资深工程师郑然在演讲过程中，围绕背景、数据模型、架构与设计、高可用实践以及性能优化等方面，详细讲解了 Tera 设计和实践过程。
郑然表示，百度搜索引擎面临三大业务特点，（1）数据量大，PB 到百 PB 这样的量级；（2）离线处理过程中，以站点等前缀方式访问数据是普遍的需求；（3）数据类型不固定。这样的业务特点决定着 Tera 设计和实践的过程。
Tera 设计的数据模型
Tera 的数据模型有以下几个特点，首先它是 Key-Value 模型，再深入一层，它是典型的 BigTable 模型，同时，一个非常重要的特点就是全局有序。这几个特点结合在一起，就是 Tera 数据模型的设计目标。
Tera 设计的系统架构
Tera 系统主要由 Tabletserver、Master 和 ClientSDK 三部分构成, 数据持久化到底层的分布式文件系统中。其中 Tabletserver 是核心服务器，承载着所有的数据管理与访问；Master 是系统的仲裁者，负责表格的创建、Schema 更新与负载均衡；ClientSDK 包含供管理员使用的命令行工具 Teracli 和给用户使用的 SDK。
表格被按 RowKey 全局排序，并横向切分成多个 Tablet，每个 Tablet 负责服务 RowKey 的一个区间，表格又被纵向且分为多个 LocalityGroup，一个 Tablet 的多个 LocalityGroup 在物理上单独存储，可以选择不同的存储介质，用以优化访问效率。
Tera 的高可用实践
Tera 的高可用性比较关键，直接影响整个系统的服务质量，其实现方式包括两个方面：Tablet Server 可用性以及负载均衡。
- Tablet Server 的可用性：1）Tablet Server 向 ZooKeeper 注册，利用 ZooKeeper 检测 Tablet Server 的存活；2）Tablet Server 挂掉之后，Master 收到 ZooKeeper 通知，进行 Tablet 迁移。具体迁移过程，会把挂掉的 Tablet Server 节点迁移到 Kick 节点上，当 Tablet Server 发现自己出现在 Kick 节点下面，自行退出。
- 负载均衡：负载均衡会直接影响整个集群的可用性，所以负载均衡更本质上来说是实现高可用的技术手段。影响 Tera 负载均衡的因素相对较少，主要在 SSD 容量、随机读和随机写这三个方面。针对上述影响因素, Tera 从两个层面来进行负载均衡策略的设计。首先平衡各个 Tablet Server 读请求 Pending 的数据量, 同时利用历史值来平滑负载短时间内抖动的影响 ; 其次根据 SSD 容量平衡各个 Tablet 的数据大小。
Tera 设计的性能优化
郑然表示，Tera 设计的性能优化，是百度在做设计过程中总结出来的，实用性较强。
第一个经验是需要考虑对分布式文件系统友好。Tera 的数据持久化在分布式文件系统上，必须考虑对其友好的使用。根据 LevelDb 的特点，数据首先要持久化在 WAL 上，确保异常情况下不丢数据，所以写 WAL 的延迟和吞吐直接决定了用户写请求的延迟和吞吐。然而分布式文件系统需要写多个数据副本，在某些副本异常情况下，如果依赖分布式文件系统层面去自动恢复的话，可能大幅增加延迟。Tera 针对写 WAL 异常情况，采用关闭旧文件创建新文件的方法，规避分布式文件系统的短板。同时 WAL 持久化成功才能保证用户数据不丢，所以 WAL 写完之后必须 sync 强制数据落盘，而 sst 文件不强制要求每次写请求落盘，从而减少对分布式文件系统的压力。
第二个经验是关于 SSD 的运用。SATA 的随机读能力很差，虽然 LevelDb 做了很多优化，但是仍然无法突破硬件瓶颈，SSD 的价格现在是越来越便宜，但成本依然比 SATA 高。Tera 的数据全部持久化在 SATA 上，仅把 SSD 作为 Cache 使用，这是平衡性能和成本的一种途径。
第三个经验是异步逻辑设计。Tera 里面所有可能阻塞的逻辑都是异步的，异步逻辑可以很好提高性能，另外客户端缓存 Tablet 位置信息，因为 tablet 位置信息通常情况下变化的也不频繁，同时扩展了 LevelDb 的 BloomFilter 机制，可以提升 20% 左右的读性能。
百度万亿量级数据库Tera架构应用、设计与实践全攻略
独家揭秘腾讯千亿级参数分布式机器学习系统无量-InfoQ
蚂蚁金服黑科技:SOFA DTX分布式事务,保障亿级资金操作一致性-InfoQ
我所经历的大数据平台发展史(四):互联网时代 • 下篇-InfoQ
专访RocketMQ联合创始人:项目思路、技术细节和未来规划-InfoQ
百度万亿量级数据库Tera架构应用、设计与实践全攻略-InfoQ
百度第三代 Spider 背后的万亿量级实时数据处理系统
信息技术发展突飞猛进，网络数据呈现爆炸之势，线性扩展面临高昂成本。Spider系统是百度搜索引擎的主要数据来源，每天处理着数万亿次的链接分析和数百亿次的互联网资源采集。那么，第三代Spider是怎样“化繁就简”实现增量式流式处理的呢？
本文整理自今年12月颜世光在全球架构师峰会2016北京站的演讲。回复关键词「百度」，下载完整版PPT。
在过去，百度搜索引擎的数据处理的多数工作是由MapReduce系统完成的，处理延时达到天级。从2014年开始，Spider系统进行了大规模重构，以搜索结果更新延迟从周级缩短到分钟级为目标，设计实现了海量实时数据库Tera。在此基础上，构建了每天实时处理几万亿链接与网页更新的百度第三代Spider系统。
区别于上一代系统，新系统的核心流程全部实时化，从互联网上出现一篇新网页，到基于历史分析与机器学习快速发现链接，到基于链接价值的抓取调度，再到对网页进行分类、筛选每个步骤都在几秒钟内完成，以保证新网页能以分钟级更新到搜索结果中。
也就是说，当互联网上产生一个新的网页时，Spider 2.0把它下载回来的时间大概是2-3天，而Spider 3.0却只需要5分钟，相当于大概是3个量级的提升。
我从一加入百度，就开始构想第三代Spider了，后面的五年几乎都在开发百度Spider第三代系统。因为它是一个非常庞大的业务系统，所以底层需要各种各样的基础架构系统支持，包括分布式文件系统、集群管理系统和数据库系统等等。当前，这些底层系统都已经开源，如果有兴趣可以一起参与进来。
首先故事从互联网和搜索引擎开始，大家平时经常接触到的互联网以及百度搜索引擎，很多人也思考过互联网上的网页怎么转化成百度搜索引擎里面这十条结果的。这里面的工作分为很多阶段，如下图所示。最开始，由Spider去做信息采集。
后面的Pagerank其实代表了一系列的计算，包含了反作弊、去重和基于页面质量的筛选等等。此阶段之后会对网页进行切词，计算网页的正排，再做转置变成倒排。最后进入检索系统供网民直接检索。Spider是该系统的起点，它的主要目的就是快速、全面地采集全网数据。那么，全网数据到底是什么概念呢？
大家设想一下，当前中文互联网到底有多少网页？不知道有多少人尝试算过或者估算过，其实我们也不知道具体的数字，但是我们通过搜索引擎估算，结果大概有100万亿的网页。其中高质量的部分大概有10万亿，这10万亿就是百度Spider所要采集网页的核心任务。
但是，光采集回来还不够，还要知道它到底有没有价值。中文互联网每天新增多少网页？100亿，也就是说互联网每天就会产生100亿的新网页。那么会产生多少条超级链接呢？每个网页上会有多少条链接？百度统计的大概结果是，平均一张网页上有120条链接，这不是指特定某个网页上有120条，而是平均值。从这一点就看到整个百度Spider每天要处理的数据量，大概每天要处理1万多亿的链接。
怎么去处理这么大规模的数据，其实在过去有个比较通用的解决方案：Hadoop。基于Hadoop的第二代Spider主要流程如下图所示，所有持久化数据存储在HDFS中，通过MapReduce任务进行选取、挖掘、回灌和抓取结果入库。
Hadoop时代的百度Spider
但这个Spider有什么问题吗？其实它的首要问题就是线性扩展的问题。很多时候大家接触到的线性扩展或者水平扩展都是一个褒义词，即用10倍的机器就能处理10倍的数据，线性增长，处理能力没有明显的下降。
但是，在这里它却变成了一个严重的问题：举个例子，在过去Spider系统每天处理1000亿链接的时候需要500台服务器，而今天互联网上的链接呈爆炸性的增长，系统每天要处理10万亿级的链接，就需要5万台服务器，这肯定是一个不可承受的代价或者成本，所以这时候我们必须得有新的解决方案，不能再做全量的处理，必须有一种增量的，只处理新链接的方式。
我们期望的处理过程如图所示。
很多人看到后可能有些失望，百度Spider就这么点东西吗？其实大家仔细去想，简单代表了更更大的灵活性和更强的扩展性。它其实就是一个流式计算系统，然后系统中的每一个策略也好，或者过程也好，都是流式系统上的一个算子，比如调度、抓取、页面解析、页面打分、链接权值打分。
整套系统的核心在于数据。一方面，我们做实时数据处理，表面上完成工作的是这些算子和计算流程，而每个算子的计算都依赖与数据的输入和输出，算子的计算延迟很大程度上决定于输入数据的获取延迟，输出数据的写出延迟。算子计算的稳定性又依赖与数据的不重不丢，这些数据必须有一个持久存储，又能随时、随地获取的方式，这样才能更好的去做实时的流式的处理。
另一方面，区别于普通的流式处理，如果仅去对单个链接或网页做流式处理，常规的Strom、Flink这些框架都是可以做到的。那么，它的真正的难点是什么？其实整个搜索引擎的计算，数据之间是有依赖性的，一张网页的价值谁说了算，一部分是由所在站点的权值和路径深度决定，更多的是由指向它的链接（前链）来投票决定。
也就是说处理一张网页时其实要同时处理整个数据集里面上百处位置的状态，一张网页价值变化了，要同时更新网页上包含的所有链接对应网页的权值，同样，在判断一个链接的价值时，也可能要依赖它的成百上千个前链上的实时数据。这就要求前面提到的那个可以随时、随地访问的数据集不是一个局部数据集，而是涵盖互联网全网数据的全集。
--> 算法上可以启发式地优化？对于非 top 的，不需要精确的rank 值，启发式地去除大量的链接计算？
hierarchically 地计算？
百度的第三代Spider系统，它的核心在于实时的数据处理，这些实时的数据处理的主要挑战：
-
第一个挑战就是全量数据的数据集比较大，大概10万亿条，百PB量级。如果是冷数据，把它放在冷备存储上可以很低价的维护，但是在Spider中不可能做到这样，因为每时每刻这个数据集中的每一条都有可能被改变，要保证它被改变时随时被更新，也就是在10万亿条数据级上随时去读写。
-
第二个挑战就是每天新抓网页100亿，触发1万亿条链接更新，每秒属性更新近亿次，这带来的是一个量级的提升，会对底层数据库造成每秒上亿次的随机读写访问。另外搜索引擎有一个特点，就是需要做调度，底层数据访问既可以随机访问也可以顺序访问，要求底层存储里的这些数据有序，这样就可以很好的统计一个站点上到底抓了多少，我们知道我们现在控制的一个站点压力不要把这个站点压跨，所以说需要很多维度的调度。
面对这些挑战，我们给出来的解决方案就是分布式的数据库 Tera ，首先容量自不必多说，必须要达到万亿量级百P的容量，再就是它要多维度的调度，支持区间访问，方便统计，就必须是一个有序表，它最核心的点是要支持自动的负载均衡，自动扩容，自动缩容。
因为众所周知的一种情况是互联网上热点频发，经常有一些站点成为爆发状态，还有一些站点突然就消失了。还有一种情况就是业务迭代非常快，可能有些业务刚创建了表，只需要10台机器进行服务，可一旦快速扩张，可能就需要几百台机器了，你应该很快地实现这种扩容，同样当它的峰值过去后也能很快地实现缩容。
除此之外，这个系统还要有一个多版本特点。有这么一种情况，上线一种新的策略或者新的活动时，因为有些地方逻辑出了个BUG，把数据库写坏了，这时候需快速恢复或者止损，就只有一个办法，就是将整个数据库状态回滚。此外，这个数据库还有一个特性，比如列存储、分布式事务，都是一些比较扩展性的特征。
该数据库的核心数据模型是三维的，除了行和列还有时间的维度，通过这个维度我们可以存储网页或普通的历史数据，这样一方面方便我们去做历史行为的挖掘，另一方面它也实现了刚才我说的回滚，可回滚到昨天前天或者某个时间的特殊状态。
第二点就是说这个数据库它的分片（sharding）方式，是一个全顺序按行去切分的，也就是说行与行之间绝对有序，然后在中间把它切开以后分到不同的区间上去，区间与区间之间也是有顺序的。
按行切分成多区间（Tablet）
在这里大家可以看到它的一个简化的架构图，我们把整个数据表按行去切分层多个Tablet，或者切分为一个子区间，每一个子区间都可以在TabletServer上服务，这张图其实还有一个核心点，我想让大家注意一下就是它的一个核心设计的思想在于它把所有的数据全部放在底层的分布式文件系统，这里面提到的BFS上，这样整个数据库都是无状态的，它的所有的数据全部是落在分布式文件系统上的，这就为了后面的很多特征的实现提供了可能。
Tera架构
这个具体做的事就是一件事，就是把随机写转换成顺序写，让我们对整个海量的顺序这种随机读写的访问成为了可能，它把随机写转换成顺序写的算法也很简单，他通过先写Log再写内存，等内存写到一定量的时候，把内存成为一种静态文件，这种方式去实现了支持顺序写，还能够保证最后下去的数据有序，然后再去后台，进行垃圾收集，保证整体的数据量有限的膨胀。
以上就是它的架构了，那么它给为我们带来什么呢？首先，它实现了在流式的处理系统中做到海量数据随时随处可用，上层的计算系统有很大的空间，有PB级的内存，统一的地址空间，几乎你在任何一台机器上想存的数据都是可以存下。再下面就是百PB级存储，不用担心持久化，你不用担心数据丢失，它做到了数据写下去以后，任何其他机器实时可读，写入立即可读。
很多人都用过Hbase，下面列一下它和HBase的一些相同点和不同点。
-
Bigtable数据模型
-
开源
-
一是可用性，这个系统最核心的一点就是说我们通过提升可用性，来解决了在我们上层实时业务中能够真正去支持实时业务。这一点怎么去做到的，后面会详细介绍。它主要解决了区间热点的问题，不会因为某些区间热点导致区间不可服务。
-
二是吞吐和延迟，Tera是C++实现，效率更高的同时，没有内存GC，不存在延迟不稳定的问题。
-
三是扩展性，HBase可以做到数百台，而它可以做到数千台。
以上这些我们怎么做到的？首先就是快速负载均衡，其实更核心的一个点在于热点区间的分裂，就是说我们如果由于业务的变化，或者说上层用户行为的变化，导致一个区间变成了一个热点区间，那么我们会在很快的时间内把它分裂开，一个区间分裂成多个区间，然后把其中的一部分迁移到比较空闲的机器上，通过这种方式实现了快速的负载均衡。这个快速负载均衡是通过文件引用的方式去实现的，也就是说不论是区间的分裂还是区间的迁移都是没有任何数据拷贝的，因为数据全部分布在底层的分布式系统上的。
在此大家也会想到其实HBase也是有这个功能，它热点区间也是可以提供这种在线的分裂，但是这里往往会引入这么一个问题，就是原来0这个区间是个热点的时候把它分为1和2，很快2这个区间又成为热点了，你把2再分成3和4，如果现在4这个区间又成为热点又怎么办？
在HBase上敢这么分吗？你刚开始初期创建了一个表，有一千个分片，那么可能两天三天以后就变成一千万个分片，因为不停分裂下去，分片数就完全不可控了，所以这里负载均衡核心问题不在于快速分裂，而在于很好的处理分裂后的碎片问题，能做到一旦一个区间不再是热点区间了，能瞬间合并。
所以在此要强调一点，能快速合并才能做到敢分裂，这才是一个真正的解决热点问题的方式。在这一点上TabletServer系统就是区间快速迁移，区间快速合并，仅有元数据变更，代价小，时间短，全自动，无人工干预。
表面上我们解决热点问题的方式是用快速的区间分裂和迁移去做的，实际上这个问题本质上是通过什么方式解决的呢？这里通过一张图去展示这一点，即连续区间本身是存在一台机器上服务的，但是这一个区间内部可能会有很多这种SST这种静态文件，这种静态文件实际上在底层分布式文件系统上是散在几百台甚至上千台机器上的，这种非常强的随机读能力去解决的热点问题，也就是说虽然你看到了一个区间是在一台机器上服务，实际上它的所有数据文件，所有你读它产生的IO都会被打散到底层的几百台机器上去。
这里有一个背后的英雄，就是百度文件系统BFS，这套文件系统的设计非常复杂，但是它核心是解决了HDFS的扩展性以及延迟的问题，可以真正面向实时应用，做到持续可用、低延迟。这个文件系统当前也已经开源。
下面介绍一些在构建上层业务系统、底层分布式系统中积累的一些经验。
第一个经验，是采用分层设计的原则，如下图所示。
工业实践-分层设计
从图中可以看到当前百度网页搜索的软件栈，最底层的网络框架包含了分布式文件系统、集群调度系统和分布式协调服务；再上层是数据库；再上层才是实际的业务。
这些技术系统都是一层一层堆上去的，比如说最底层的网络通信框架，所有的网络问题，包含Socket编程的封装，网络的流量控制，跨地域的链接优化，全部会封装在这一层。上层用它开发分布式文件系统时，就完全不需要考虑网络问题、流量控制问题了，只需要关注分布式文件系统的逻辑就可以了。
然后，把所有数据持久化甚至IO相关的一些工作全部放在分布式文件系统这一层。在构建上层的分布式数据库、分布式数据处理框架，乃至上层业务系统的时候，都不再需要考虑数据持久化的问题，也不需要考虑IO持久能力的问题。这样就能让数据库可以做到完全无状态的。大家可能接触过很多数据库，没有任何一个数据库系统可以做到完全无状态的。这个完全无状态甚至包含cache无状态。
也就是说这种分层设计带来一个最大的好处，就是任何问题在一处解决了，很多处都会受益，同样问题在一个地方解决一次就够了，上层系统完全不需要考虑网络问题、丢数据的问题、IO能力的问题。
第二个经验，是要去为可用性设计，要能做到容错。通常我们计算可用性可以用：可用性=(总时间-故障数*恢复时间)/总时间。很多工程师和架构师做系统设计的时候，会把很多精力放在降低故障发生的频率，降低故障发生的机会，尽量让系统不要出故障，以这种方式来提高可用性，而在我们这套设计思想里，我们不通过这种方式提高可用性，为什么？
因为故障不可避免。假设我们单台服务器的平均故障间隔时间是30年，在市场上你是绝对买不到这种30年都不会坏的服务器的，但我们假设你有这种服务器，你去搭建一个万台的集群，你在使用这个集群的过程中会发现每一两天就会坏一台机器。也就是说无论你的服务器再好，都不能避免故障。
我们提高可用性的思路就是降低故障恢复的时间，平常所说的几个9，就是总请求数减去故障数，乘以故障影响的数，通过这套思想，这套分布式数据库做到比以前高一个9，就在于故障恢复时间。
第三个经验，是要去为低延迟设计。因为我们现在整个上层的业务系统都在从批量到实时过渡，我们要做实时系统，实时系统很大程度上对延迟有很高的要求，backup request是个很好的选择，我希望他99.9分位的延迟不要超过10毫秒。我期待这个服务平均1毫秒返回，如果2毫秒还没返回，我就再发一个请求到备份节点，这样来降低延迟的长尾。
另外是慎用自动GC的语言，实时处理，大量小请求，频繁触发STW，服务无响应，不必要的failover，导致整个系统不稳定，所以尽量不要用这种自动GC语言。剩下可选的语言可能就不多了，所以我们这套系统选择用C++开发。
这套系统未来的工作是走出百度、走向社区。今天，百度这一套核心的分布式系统已经完全开源了，我们也把所有的开发、codereview和版本的发布，全部放在GitHub上，外部提交的代码已经在驱动百度的这套搜索了。
大家可以登录Github，关注我们的项目，共同交流：
https://github.com/baidu/tera
作者介绍
颜世光，百度搜索基础架构团队技术负责人。2011年加入百度，从事Spider系统架构相关研发，期间主持了百度第三代Spider系统的设计与实现。 当前主要研究方向为大规模分布式系统，是百度海量数据库Tera、百度文件系统BFS和集群操作系统Galaxy的主要作者。 热衷开源，先后推动了百度多个重量级系统对外开源。