哪些论坛百度可以收录❝发文合作-收录效果好❞发帖子的平台有哪些
尊敬的客户，您好！我们是北京一家专注互联网技术服务公司，可以提供收录效果好，文章排名好的网站进行发文，发得多，各种关键词排名就多，流量越多越稳定，如果您有需要欢迎您前来资讯！可以随意添加图文和视频广告，助您的企业或者项目服务实现推广效果！如需合作欢迎请加微信
建筑师
我们都是建筑师！
架构未来，你来吗？
本文主要介绍百度搜索全网万亿级规模内容理解的工程实践，涉及机器学习工程化、资源调度、存储优化等。
全文6648字，预计阅读时间17分钟。
商业背景
百度汇集了海量的互联网内容，要索引这些内容，首先需要对内容进行深度理解，提取包括内容语义、内容质量、内容安全等多维度的信息，从而进一步支撑内容筛选、语义库建设等需求。对全网海量内容进行深度理解是非常具有挑战性的，主要体现在成本和效率上。
从成本上看，计算量非常大。除了全网内容数据量巨大（万亿级规模）和特征数量庞大之外，两个趋势也加大了计算压力。一方面，互联网内容中图形和视频的占比持续大幅增长，图片/视频的计算量远大于文本。另一方面，深度学习技术的大规模应用，特别是近期大模型的兴起，也加大了对算力的需求。从效率上看，如何让系统更加简单易用，尽可能提高业务迭代的效率，是所有工程系统的核心目标之一。
关键思想
（1）成本优化：满足如此庞大的算力需求，需要把“开源节流”做到极致。
1、“开源”：尽可能扩大计算资源池，通过采购满足ROI低迷，挖掘现有资源潜力是关键。从公司整体来看，资源利用率不高，在线资源有高峰有低谷，库存闲置资源很多。我们的计算大部分都是离线的，对资源稳定性要求不高。可以把两者结合起来，构建一套弹性计算调度体系来解决资源问题。
2、“节流”：尽可能优化服务性能，降低单位计算成本。模型推理计算量很大，但优化空间很大。结合模型结构和GPU硬件特性进行优化，可以大幅提升模型服务单卡吞吐量。此外，优化CPU处理、使用百度自研昆仑芯片等方法也可以降低单位成本。
（2）效率优化：如图所示，整体业务流程包括实时计算和离线计算。新增特征需要离线刷新已有数据。对于新采集的数据，会筛选出时效性高的数据进行实时计算，其余数据也会进行离线计算。大部分计算都在离线部分完成。主要的效率问题是：如何支撑快速模型工程？如何提升离线计算效率？
1. 模型服务框架与平台：通过统一的模型服务框架和支撑模型服务平台实现模型工程化，模型服务框架与平台支撑和覆盖模型服务从构建、测试到上线的全生命周期环节。
2、特征批量计算平台：为了解决离线特征计算效率问题，建设了统一的批量计算平台，从离线任务开发到计算过程，对各个环节的效率和性能瓶颈进行分析和深度优化，尽可能的提高效率。
技术方案
3.1 总体架构
总体架构如下图所示，核心部分为模型服务平台、批量计算平台、计算调度系统、模型服务框架。
1. 模型服务框架：算法同事采用统一的模型服务框架进行服务封装。基于研发效率的考虑，我们选择它作为框架语言，但性能问题也比较明显，因此需要进行大量针对性的优化。另外我们也在框架中不断集成多种推理优化方法，尽可能降低服务的单位计算成本。
2、模型服务平台：模型服务平台支撑模型服务和能力输出。平台以“算子”为管理粒度，“算子”代表一个完整的功能，比如视频分类，通常需要多个模型服务组合完成。算法同事在平台上注册算子，提供服务拓扑等元数据，并通过性能参数自动调整、自动化压测等方式生成性能报告。服务拓扑和性能报告是后续调度的重要输入。平台还提供算子检索、研究试用等功能，并以中台方式支撑其他业务需求。
3、计算调度系统：计算调度系统对流量和资源进行统一调度，所有模型服务的请求都会经过计算调度系统的网关，执行流控、路由等流量策略，同时计算调度系统还会调度百度多个PaaS平台的各种闲置异构资源，自动部署合适的算子，为离线计算提供更大的吞吐能力。
4、批量计算平台：批量计算平台支持离线作业任务生成、任务调度等功能，构建基于HTAP的存储方案解决Scan吞吐瓶颈问题，联动计算调度系统支撑大规模离线计算。
3.2 技术关键点
本章主要讲解了系统的关键技术点，包括遇到的技术难点、思考和权衡。也希望读者能就一些常见问题与我们多多交流。
3.2.1 模型服务框架
在实际的业务场景中，模型服务框架有几个关键问题需要解决：业务编程模型、服务性能优化、推理性能优化，下面分别介绍。
3.2.1.1 业务编程模型
为了实现某一功能，往往需要组合多种模型、多种数据处理逻辑。为了抽象表达处理流程、实现通用逻辑的复用，采取以下解决方案：
3.2.1.2 服务性能优化
这种选择虽然降低了开发成本，但是也引入了 GIL（ Lock）问题，导致无法充分利用 CPU 多核，大大限制了服务吞吐量。解决方案如下：
主要的优化手段包括推理调度、推理优化、模型量化、模型压缩等，优化后业务单卡吞吐量通常比原生实现提升数倍。
1、推理调度：动态批处理（）和多次执行。GPU 批量计算效率更高。由于服务也接受实时单次请求，不可能同时请求，所以使用服务缓存，牺牲延迟换取吞吐量。可以看作是一个 GPU 任务队列，默认全局单次任务串行执行，当发生 GPU IO 操作（内存和显存互相复制）时，计算单元处于空闲状态。通过创建多个、不同的推理请求走不同的路，让 IO 和计算完全并行。
2. 推理优化：业界主流方案是使用 ，但在实际应用中会出现动态图无法静态化、Op覆盖不全等问题。针对这些问题，团队开发了自己的（开源版本： ），结合、图优化、、vLLM 等技术，实现无需复杂的模型转换，增加几行代码就能大幅提升推理性能，效率和性能的双赢，同时也支持昆仑等异构硬件。
3、模型量化：GPU、昆仑等硬件对于低精度计算能力更强，量化虽然效果损失不大，但带来的是吞吐量的明显提升，因此线上会使用FP16甚至INT8/INT4量化，也是支持的。
4. 模型压缩：可以通过模型蒸馏、模型剪枝等方法精简模型参数，减少计算量，但需要训练，效果会有所下降，一般会和算法专家协同优化。
3.2.2 计算调度系统
计算调度系统的运行架构图如下。所有请求流量经过统一网关（），网关支持流控、路由等多种流量策略。离线作业也通过网关提交计算需求，网关将需求转发给调度器（），进行调度。调度器对接百度内部多个PaaS，不断检测空闲资源，根据需求、多项指标、空闲异构资源分布等，自动调度部署合适的算子。算子元信息从服务平台获取。调度完成后，调度器会调整网关的流控、路由等。
该系统两个关键问题是：如何实现运营商（复合业务，包括复杂的业务拓扑）的自动化部署？如何在流量分布不稳定、多种异构资源等复杂情况下进行调度？
3.2.2.1 自动部署
为了简化开发的复杂度，采用了声明式编程，其实是基于k8s机制开发的，自动化部署实施方案如下：
1.CRD扩展：使用K8S CRD自定义（算子部署包）等对象，通过机制在PaaS等外部系统进行部署等操作。其中包含算子所需的所有子服务部署信息以及它们的拓扑关系。在调度创建算子服务时，会从底层开始逐层创建子服务，上层子服务通过通信托管机制，可以获取下游子服务地址。
2、通信托管：通信托管机制是基于配置中心和模型服务框架实现的，服务启动命令会携带远程配置地址，通过加载远程配置，在启动时改变下游服务地址。其实更理想的方案是利用 等技术来解耦架构能力和业务策略，但考虑到我们需要在多个PaaS上部署，在每个PaaS上都部署 等组件成本太高，集成到框架中又太重。所以我们先基于配置中心搭建方案，等时机成熟再考虑迁移。
3.2.2.2 调度设计
调度是一个非常复杂的问题，在我们的场景中，它的复杂性主要体现在以下几个方面：
1. 运营商调度：一个运营商（组合业务）能够承载的流量大小取决于其最短子业务的容量，调度时需要将运营商作为一个整体来考虑，避免资源浪费在长板业务上。
2、流量分布变化：部分算子的表现会受到输入数据分布的影响，例如视频OCR会受到视频时长、文字占屏比例的影响，调度时需要进行自适应调整。
3、多种异构硬件：有的算子可以支持多种异构硬件（昆仑/GPU/CPU等），有的算子只能绑定一种，如何分配才能保证全局资源最高效的利用？
4、其他因素：作业优先级、资源优先级、资源波动等因素也会影响调度，实际调度需要考虑的因素非常多样。
基于以上因素，我们的调度设计如下：
1、两阶段调度：分为流量调度和资源调度两个阶段，每个阶段独立调度。流量调度负责将当前运营商服务能力分配给各个作业，并将结果同步到网关，并调整流量策略；资源调度负责根据资源空闲情况和运营商能力缺口进行调度，最终实现运营商服务实例的扩容和缩容。
2、流量调度：在流量调度阶段，会根据任务运行指标调整归一化系数，然后通过该系数映射任务所需的Qps，作为后续所有调度的依据，从而解决流量分布变化带来的影响问题。在Sort阶段，会对作业优先级进行排序，并在该阶段根据Sort结果，将现有的算子容量按照优先级分配给各个作业。在Bind阶段，执行结果并同步路由下发到网关。
3、资源调度：在资源调度阶段，会将作业的容量缺口折算成对应的服务实例缺口，然后将需要扩容的服务分配到合适的硬件资源队列中，并按照资源稀缺性、计算性价比等进行排序，最后将资源预分配给各个子服务，最后再考虑组合服务各个子服务的调度满足情况，对组合服务各个子服务的容量进行微调，避免资源浪费。
3.2.3 批量计算平台
批量计算平台需要解决以下问题：在弹性资源比较充足的情况下（比如晚上），（分布式表系统）的Scan吞吐量瓶颈以及如何尽可能优化离线任务的效率。下面介绍具体的解决方案。
3.2.3.1 HTAP存储设计
首先分析一下Scan慢的原因，主要有以下几点：
1、读写混合：需要OLTP（抓取更新等）和OLAP（特征批量计算等）访问，多种读写方式混合。底层存储为HDD，大量读写混合导致磁盘IO吞吐量严重下降。
2、扫描放大：采用宽表结构存储，通常不同任务只需要扫描几列，但扫描时需要读取并过滤整行数据百度收录哪些平台的视频，造成严重的IO放大。
3、扩容成本高：由于OLTP、OLAP混合读写，单独对Scan进行扩容成本较高，同时由于读写配比难以固定，扩容资源难以预估。
从上面的分析可以看出，关键问题是OLTP/OLAP混合使用。参考业界实践，很难用单一的存储引擎同时满足OLTP和OLAP两种场景。但为了存储系统的易用性，我们希望一个存储系统可以同时支持这两种场景。因此，我们结合业务场景和行业经验，实现了HTAP存储解决方案。具体方案如下：
1、OLAP/OLTP存储分离：针对批量计算等OLAP场景构建高效的OLAP存储，减少OLAP/OLTP混合使用带来的混合读写问题，也可根据需要独立扩展。
2、高效的OLAP存储设计：自研的OLAP存储构建在AFS（类百度HDFS）上，采用增量同步、行数据分区、列数据动态合并存储的设计。将全量数据划分为N个物理数据分区，通过增量数据定期高效同步更新OLAP存储数据（由于底层使用LSM存储，增量效率远高于全量扫描）。列存储根据字段访问热点进行重组，将热点列在物理层存储在一起，降低IO放大，支持动态调整。该方案会有数据同步延迟的问题，但在我们的场景下，对时效性要求不高，可以忽略该问题。
3.HTAP SDK：提供支持访问HTAP和OLAP存储的统一SDK，用户可以基于SDK同时执行自己的OLAP和OLTP任务。
3.2.3.2 任务生成与调度
为了简化批量计算任务的开发，平台目前提供配置、KQL、离线框架三种任务开发模式，开发自由度/成本由低到高，易用性由高到低：
Function classify = {def classify(cbytes, ids): unique_ids=set(ids) classify=int.from_bytes(cbytes, byteorder='little', signed=False) while classify != 0: tmp = classify & 0xFF if tmp in unique_ids: return True classify = classify 8 return False}
declare ids = [2, 8];select * from my_tableconvert by json outlet by row filter by function@classify(@cf0:types, @ids);
除了后面几种方法，平台也在尝试结合大模型来实现基于自然语言的任务生成。其实不管用哪种方法，最终生成的离线任务都是基于离线框架的，只是根据更具体的场景进行了更高度的封装。
任务生成后会调度到FaaS平台执行。不同的任务生成方式，调度前的预处理也有所不同。比如KQL任务需要解析后才能生成实际的任务进行调度。通过业务框架开发的任务更容易出现各种突发问题，因此会使用自动化接入等流程。任务执行时会先将需要的算子、预期吞吐量提交给计算调度系统，然后不断从网关获取可用信息，根据当前的任务实例数、失败率等自适应调整请求投递速度。
总结
目前系统支撑搜索产出、视频搜索、图片搜索等十多个业务方向，支撑数百个算子的开发上线、每天数百亿次的计算调用，支撑全网万亿级内容特征的日常更新。随着AI大模型时代的到来，带来了很多新的场景和挑战，有很多值得重新思考的点，未来我们会结合大模型进行更多的探索。
如果你喜欢这篇文章，请点击右上角分享给你的朋友。
如果想了解更多技术点，请给若飞留言，安排分享
由于公众号推送规则变更，请点击“阅读”并加“Star”，以便第一时间获取精彩的技术分享。
·结尾·
相关阅读：