百度大规模在离线混部系统架构演进
百度文库系统架构
基于MySQL+PHP的技术架构体系，使用了thinkphp框架
服务层
用户认证服务、文档存储服技术架构体基于MySQL+PHP的技术架构体系，其中MySQL是一种关系型数据库管理系统。thinkphp是一种基于MVC模式的PHP开发框架，它提供了一系列的工具和方法，使得开发者可以更加高效地进行Web应用程序的开发。
核心技术存储在多个节点上，保证数据的安全性和可靠性。同时，通过负载均衡技术，实现文件存储的高效利用和带和关键词检索。通过建立索引和优化查询算法，实现快速准确的文档检索和匹配。同时，支持对文档内容的关键词提取和推荐，提高用户搜核和管理，防止恶意文件上传和不良内容传播。采用基于深度学习的图像识别和文本分类技术，对文档内容进行智能识别和分类，确保文档的安全性和行处理和分析。利用分布式计算框架和数据挖掘算法，实现数据的实时处理和价值挖掘。通过对用户行为数据的分析，优化用户体验和资源推荐。
业务层
位于应用层的下一层，主要负责处理业务逻辑和业务规则。这一层并不依赖于具体的用户界面或数据存储方式，而是独立于应用层，可以被多个应用层共享和复用。业务层的作用是对外提供服务，处理和执行业务逻辑
数据层
系统的最底层，主要负责数据的存储、检索、处理和保护等。数据层可以包含数据库管理系统、文件系统、分布式存储系统和其，为用户提供海量的文档资源共享与阅读服务。其系统架构设计以及所涉及的核心技术，旨在实现高效、稳定、安全地提供文档上传、存储、管理、检索、阅读等一站式服务。
基础设施层
包括服务器、网络设备、存储设备等，提供计算、存储、网络等基础设
百度X_精品文档
百度X当地时间12月2日，在加拿大举行的第32届NeurIPS神经信息处理系统大会上，百度正式发布自主研发的超级AI计算平台X-MAN3.0。
该平台专为AI深度学习场景优化设计，每秒完成2000万亿次深度神经网络计算，极大的加快了AI深度学习模型的训练速度。
NeurIPS作为机器学习和神经计算领域的顶级会议，吸引了机器学习、人工智能、统计等领域的众多国际专家参与。
近年来，在计算机视觉、语音识别、自然语言处理等领域也出现了大量的创新应用，NIPS在AI深度学习领域的学术影响力变得举足轻重。
算法、数据和计算是推动AI深度学习技术快速发展的三大要素。
为支持更强的泛化能力，更高的预测精度，算法模型日趋复杂，越来越多的数据需要被及时标注和处理，计算性能成为关键。
百度X-MAN 超级AI计算平台提供极致的计算性能，支持超大复杂算法模型，能够快速及时处理海量数据。
自2016年诞生以来，百度X-MAN超级AI计算平台历经3代发展，3次架构升级，创造6项业界第一，同时期关键技术&性能保持领先，引领行业发展趋势。
目前，X-MAN 系列产品已在百度大规模应用，正在助力百度AI战略快速落地。
X-MAN解决的3大关键技术挑战为提供更强的计算性能和最佳的计算效率，X-MAN在系统设计中面临了三大关键技术的挑战：如何有效提升单机计算性能、如何实现多机加速的高可扩展性以及如何均衡CPU与AI加速芯片的配比关系，以避免系统瓶颈。
在有限的单机空间内，集成更多数量、性能更强、互联带宽更高的AI加速卡，是提升单机计算性能的直接手段，但带来了高速互联、结构、散热、供电等硬件技术难题；单机训练方式难以满足超大规模数据集和复杂的模型场景下的计算力需求，大规模分布式训练成为必然，解决多机加速的可扩展性就成了关键技术难题；深度学习模型的负载差异较大，CPU密集型，计算密集型，通信密集型，存在着多种需求场景，为了避免系统性能瓶颈、充分发挥计算效率，如何快速灵活的调整CPU和AI计算芯片的配比并支持独立迭代升级成了关键的技术难题。
百度的分布式文件系统之路
MFS的问题和改进
• 问题 • Master元信息单点 • Master单线程性能瓶颈 • 修复与写入互斥
• 改进 • poll->epoll • 调大hash桶 • fuse调参
CCDB存储体系
Table
File
Object
Permission
Isolation
Priority
Replication
MFS
• 简介 • MFS是MooseFS的简称，是一个分布式网络文件系统， 将数据切片分散到多个存储设备上实现数据容错，可 以像本地文件系统一样进行挂载使用。
• 特点 • 类GFS的开源C实现 • 通用文件系统(POSIX支持) • 高易用性(Mount、Trash、Snapshot……)
MFS的读写流程
CCDB-NFS架构
• Master • 目录树 • 集群管理
• FileServer • 文件元信息 • 文件数据
CCDB-NFS链式复制
• 链式复制 • Primary最后Commit • 读Primary强一致 • 选主简化
CCDB-NFS的多租户支持
• User • Region • ACL • Quota
Recovery
Control
Table Engine
File Engine
KV Engine
Replica Block System
Raid-like Block System
Memory
SSD
Disk
Interface Platform Distributed Engine Block Hardware
AFS压缩支持
• DataNode透明压缩 • Client写入时压缩 • 分级压缩(LZ4/LZO->LZMA)
大数据离线计算平台流式Shuffle服务
环境 初始化
机器故障 自动化
机器 自动流转
结 算
高精硬件
FPGA
GPU整机柜背景-大数据计算平台C++
API层
Python
Java
……
Simplified Unified API
计算引擎
TM
DStream
DCE
(MR/DAG)
MPI/E LF
Spark
资源调度 资源管理 机器资源
Normandy
Session更新
状态汇报
• 数据缓存与异步发送
Session A Shuffler分配信息 Shuffler状态
• 异常处理
Process
K V
WriterBuffer
DataSender
rpc
Shufflers
Session B K V WriterBuffer DataSender
Shuffler分配信息引擎
背景-一般的Shuffle模式
Mapper
Mapper
Mapper
Reducer
Reducer
目录
• 背景 • 架构 • 关键技术 • 收益与总结 • 下一步计划
架构
架构
Control message Data Flow
JobMaster
ShardID SWID Primary
• 负载均衡
• 负载均衡
• Shuffler • Shard
pushShuffleWorkerInfo
1. Writer上报ShufflerException 2. Shuffler上报负载情况
pushSessionUpdate DataCollector RpcServer pushMapp
百度腾讯系统架构演化
看看腾讯、百度等这样的大型网站系统架构是如何演化的2014-9-29 01:01|发布者: 田云|查看: 715|评论: 0摘要: 前言一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、 ...前言一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随着业务的扩展而逐步完善的，并不是一蹴而就;不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿用户的实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段广泛运用在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：二、应用、数据、文件分离随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则(即80%的访问请求，最终落在20%的数据上)，所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。
互联网架构的演变过程（一）
互联⽹架构的演变过程（⼀）简介web1.0时代web2.0时代互联⽹时代互联⽹+ --》智慧城市。
2012年提出。
云计算+⼤数据时代背景随着互联⽹的发展，⽹站应⽤的规模不断扩⼤，常规的垂直应⽤架构已⽆法应对，分布式服务架构以及流动计算架构势在必⾏，亟需⼀个治理系统确保架构有条不紊的演进。
1、第⼀时期单⼀应⽤架构all in one(所有的模块在⼀起，技术也不分层)⽹站的初期，也认为互联⽹发展的最早时期。
会在单机部署上所有的应⽤程序和软件。
所有的代码都是写在JSP⾥⾯，所有的代码都写在⼀起。
这种⽅式称为all in one。
特点：1、不具备代码的可维护性。
2、容错性差。
因为我们所有的代码都写在JSP页⾥。
当⽤户或某些原因发⽣异常。
（1、⽤户直接看到异常错误信息。
2、这个错误会导致服务器宕机）容错性，是指软件检测应⽤程序所运⾏的软件或硬件中发⽣的错误并从错误中恢复的能⼒，通常可以从系统的可靠性、可⽤性、可测性等⼏个⽅⾯来衡量。
单体地狱。
:只需⼀个应⽤，将所有功能都部署在⼀起，以减少部署节点和成本。
2 第⼀时期后阶段解决⽅案:1、分层开发（提⾼维护性）【解决容错性】2、MVC架构（Web应⽤程序的设计模式）3、服务器的分离部署特点：1、MVC分层开发（解决容错性问题）2、数据库和项⽬部署分离问题：随着⽤户的访问量持续增加，单台应⽤服务器已经⽆法满⾜需求。
解决⽅案：集群。
3 可能会产⽣的⼏个问题：1.1. ⾼可⽤“⾼可⽤性”（High Availability）通常来描述⼀个系统经过专门的设计，从⽽减少停⼯时间，⽽保持其服务的⾼度可⽤性。
(⼀直都能⽤)1.2. ⾼并发⾼并发（High Concurrency）是互联⽹分布式系统架构设计中必须考虑的因素之⼀，它通常是指，通过设计保证系统能够同时并⾏处理很多请求。
⾼并发相关常⽤的⼀些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发⽤户数等。
大数据离线计算平台介绍
中间数据持久化：
避免重算（对daDCE揭秘 • 统一分布式计算引擎API-Bigflow
需求
• 学习成本：
• 学习使用、学习优化
Hadoop
一套逻辑，重写再重写
Spark
未来某种新的计算引擎
• 迁移成本：
• 单机作业迁移分布式、流式与批量 迁移、新引擎迁移大数据离线计算平台介绍目录
• 离线大数据平台发展历程 • 离线计算引擎DCE揭秘 • 统一分布式计算API-Bigflow私有云产品生态搜索
金融
糯米
AI
开放云
ADU
分布式计算
服 务 托 管 研 发 效 率 相 关 工 具 Batch RealTime Iterative
分布式存储
Ojbect Table NFS
批量计算引擎
提升时效性
实时计算引擎
• 维护成本：
• 用户作业维护、引擎演化兼容维护
恢复故障数据、提升结果准确性 一套逻辑，同时需要维护两个系统上完全不同的代码
统一分布式计算API
•
统一分布式计算API-Bigflow：
– 统一流式和批处理计算模型 – 自动优化用户代码 – 针对引擎特性，进一步优化执行 – 简单易学，高层抽象API
环境 初始化
结 算
高精硬件
FPGAGPU整机柜大数据计算平台Python
API层
C++
Java
……
Simplified Unified API - Bigflow
计算引擎
TM
DStream
DCE
(MR/DAG)
MPI/ ELF
Spark/ Flink
资源调度 资源管理 机器资源
百度的下一个15年
“
希 望 不 久 的将来
，
每
一
个普 通 患 者 通 过互联
”
。
在公 司 年会 上
｜
，
李 彦 宏 掷 地有 声
１
网
，
都 能获 得 权威 医 疗机构 的 救 助
李 彦宏 表 示
，
与
ｔ＝ ｃ ｒＨ ？ ＋ ＋ ？＊ ５５ ３ ０ １ ［＝
医 院共 建 网 上医 疗服 务 平 台
１
￥ 动 医 疗 和 ？ ＃ 硬 件的 发 展 将＃ 效 利 用 医 ４ 的 ＠ 片
、
员 身 份公布 了 自 己 的
医 院挂 号 号 源
，
两会
”
提案
，
建 议 全 面开 放 事 业 部 ＬＢ Ｓ 事 业 部 等组 织 架构 。
、
—
取 消部分 地 区 对 商 业 机构 开 展 网 络 如 今 问 题逐 渐 显 现 以 产 品驱 动 的 事业 群
， ， ， ，
管 理 架 构 在 ２ ０ １ ５ 年 依然 会 发 挥 高效 率 吗 同 几 挂 号 业 务 的 限 制 借 助 社会 力 量 优 化 医 疗资源 配 置
找到 所 求
而新的
１
５
年
，
百 度 则会 更进
一
步 解 我 国 医 疗 卫 生 领域的 信 息 化 还 处 于 粗 放 阶 段
一
，
决 人 与服 务 的连 接 问题
“
。
直 是政 策 破 冰 的 难 点
。
而 李 彦宏 的 目 的
，
是综
语 音 和 图 像将 成为未来人们表达 需 求 的 主要 合 最 强 的 信 息 技术 公 司 及 最 强 的 医 疗 服务 机构
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
计算框架(MR/Spark)的优化
• 避免本地磁盘IO： • 1）Shuffle由Pull变成Push • 2）通过FS（全内存）交换
• 减少重算： • 1）Map端节点挂掉重算 • 2）做好Backup
支撑系统建设
• 技术债： • 1）混部框架自动化入退场 • 2）机器环境一致性：网卡多队列、内
Task
离线作业 Task
Task
Task Task
Task
Task Task
离线框架
隔离：更加精细的管控策略
• CPU：
• 1）离线大框绑核：根据单机reclaim资源量；离线内共享； • 2）core-aware：快退避，慢启动，避免HT干扰； • 3）HT干扰规避：自动从迁移离线作业，避免和在线服务干扰； • 4）L3-cache：CAT隔离； • 5）CPI干扰抑制：检测、干扰源识别、避让；
D
D
D
D
SS
D
计算资源管理
问题
1. 磁盘调度是一个“超维” 问题
2. 磁盘利用率低
存储资源管理
效果
1. 磁盘管理调度扁平化 2. 提升磁盘管理效率
无差别混部
离线间混部 在线间混部 在离线混部
无差别混部
谢谢聆听！
• 内存：
• 1）离线大框嵌套：根据单机reclaim资源量；离线嵌套内存Cgroup； • 2）动态内存伸缩
避让：保证离线运行良好
• 精细的单机避让 • 1）可压缩资源优先压缩； • 2）不可压缩资源避让足量即可；
• 调度器优化 • 1）used = Max(used in last T) • 2）建立学习反馈闭环
核参数等等 • 3）资源化交付：资源订单至Quota交
付，业务看不见机器
目录
一、背景：为什么要做混部 二、方案：混部架构和核心技术
三、展望：收益和未来展望
混部收益
混部集群CPU利用率大幅提升40-80%！ 离线预算节省服务器30000+台！
存储计算分离
计算
计算
计算
计算
计算
HD
HD
SS
HD
HD
D
2014年
• Matrix上线 • 离线计算混部
• Normandy
• 在离线混部 （千寻）上 线
• 规模1万
2017年
• 混部规模达5万 台
• 在线合池启动
2019年
• 混部规模达10 万台
• 机器默认交付
混部技术栈
搜索
Feed
凤巢
在线服务
网盘
度秘
无人车
地图
离线作业
在线PaaS
(Opera、Beehive）
Matrix*-Scheduler
在线调度
MR/Spark
批量计算引擎
MPI/Paddle
机器学习框架
Normandy-Scheduler
离线调度
AFS
文件系统
容器引擎
Matrix-ResourceManager
实例管理
资源模型
资源隔离
镜像机制
机器自动维修
Matrix-Ultron
机器环境一致性
资源化交付流 2） 容器化基础设施 • 3） 混部隔离的基础设施
• 设计： • 1）容器引擎 • 2）镜像管理 • 3）实例管理 • 4）资源调度 • 5）隔离技术
Normandy
• 定位：离线调度系统 • 1）离线计算混部 • 2）混部的离线资源调度 • 3）Plugins on Matrix
一、背景：为什么要做混部 二、方案：混部架构和核心技术
三、展望：收益和未来展望
在离线混部思路
• 定义
• 1）机房统一规划 • 2）业务混合运行
• 难点
• 1）保证在线不受到影响 • 2）保证离线运行历程
2015年
2012年
• 提出混部 • BVC/IDLE上线 • 启动Matrix
• 设计： • 1）任务管理 • 2）作业排队 • 3）资源调度 • 4）等等
混部的理论基础
• 混部原则：一套在线、离线在单机运行的规则规范。
• 单机资源模型：优先级和超发模型
total
优先级 • STABLE > NORMAL > BESTEFFORT • 单机：可否抢占 • 集群：是否有Quota
超发 • 用户行为：request – used > 0 • 超发：total’ = total + sum(request – used) • 约束：sum(STABLE) < total
request
used
物理机
!STABLE STABLE
调度器
混部的核心思路
单机隔离
响应及时，快速避让！
集群调度
响应慢，但是有规划的调度
隔离：保证在线不受影响
• 基本思路： • 1）内核和用户态管控 • 2）离线“大框”模型
• CPU：大框绑核 • 内存：大框硬限 • IO：隔离磁盘、计算框架优化 • 网络：QoS、Transkeeper
• 兜底策略：单机SLA
Watch-Dog
在线服务
S1
S2
S3
S3
S3技术创新，变革未来大规模在离线混部系统演进目录
一、背景：为什么要做混部 二、方案：混部架构和核心技术
三、展望：收益和未来展望
从成本说起..
• 公司从什么阶段开始关注成本
• 规模化、平稳发展期
• 公司的成本构成
• 研发、运营、服务器
• 提升资源利用率是降低服务器成本的重要手段！！
资源利用率现状
• IDC规划： • 在线机房、离线机房分离规划
• 资源利用率的矛盾： • 1）离线利用率高，资源不足 • 2）在线利用率低，峰值高但不够弹性
• 现状分析： • 1）在线天然利用率不足，只有离线、在线统一规划集群才能充分利用资源 • 2）通过实施在离线混部：提升利用率、减少离线、在线服务器采购成本
目录