12 篇内容
本文介绍 LinkedIn 自研图数据库 LIquid 如何支撑其经济图谱（2700 亿条边、200 万 QPS）的实时访问。文章以 People You May Know 功能为例，说明从遗留系统 GAIA 迁移到 LIquid 的架构：用声明式 Datalog 查询做图遍历，再由 Venice 和 Pinot 提供特征与排序。迁移后 QPS 从 120 提升到 18000，延迟降到平均 50ms 以下，CPU 降低 3 倍以上，并支持更细粒度、可解释的推荐和快速 A/B 实验。作者也指出当前同质化架构在数据规模扩大时的低效问题，以及未来分层存储与工作负载优化的方向。
文章以真实生产系统为例，提供了从离线批量到实时图查询的完整迁移路径和可量化性能结果，证据具体、架构清晰。适合关注大规模图数据库、实时推荐或高并发基础设施的工程师借鉴，其关于声明式查询、索引优化和成本控制的方法具有跨团队可迁移价值。
本文介绍 LinkedIn 收入归因报告系统如何用加法对称同态加密（ASHE）替代逐行 AES 解密。原系统每次查询都从 Pinot 拉取全部相关记录、解密敏感列后在明文上聚合，导致网络和 CPU 开销大且暴露明文。新方案把 ASHE 加密列和标识符一起存入 Pinot，将聚合下推到存储层，利用 Pinot 内建聚合与 ArrayAgg 拼接标识符，API 服务器仅对每列聚合结果做一次解密。对于按敏感状态分组的查询，还结合确定性加密防止频率攻击。实际效果显示网络响应从 2MB 降至约 5KB（降幅 99%），CPU 尖峰缓解，端到端时延基本持平。方案适用于数据所有者与查询方为同一实体的场景，依赖支持聚合下推的 OLAP 存储。
推荐收录。文章提供了真实系统中同态加密落地的完整工程案例，包含原方案瓶颈、ASHE 原理、Pinot 集成细节、扩展方案和量化性能对比，证据充分。对需要隐私保护分析、加密数据聚合或优化 OLAP 查询的工程师有直接迁移价值，尤其展示了如何将密码学原语与存储层能力结合。
文章介绍 LinkedIn 为替代 Kafka 而自研的可扩展日志存储系统 Northguard，以及其上的虚拟化发布订阅层 Xinfra。Northguard 通过分段、范围、主题的数据模型，基于 Raft 的动态分片元数据状态机（DS-RSM）和 SWIM 去中心化成员协议实现高可扩展性与可运维性。核心设计是以段为复制单元的日志条带化，自然均衡负载、避免资源倾斜，并论证范围模型相比固定分区能减少流处理中的 shuffle。评测对比显示 Northguard 在元数据可扩展性、集群数量、负载均衡、自愈、一致性和持久性上均优于 Kafka，且通过 Xinfra 虚拟化和双写实现了透明迁移。文章主要面向大规模日志存储和分布式系统工程，技术细节以高层设计为主，缺少底层实现参数和故障恢复的深入展开。
本文来自 LinkedIn 真实生产环境，规模达 32T 记录/天、17PB/天，详细展示了从 Kafka 迁移到自研系统的完整工程决策与权衡，包括数据模型、复制单元选择、元数据分片和虚拟化迁移。适合分布式存储、基础设施和架构师参考，尤其关注日志存储、自动负载均衡和大规模系统演进。其可迁移价值在于以细粒度分段替代整日志复制来改善可运维性和可用性的思路，但读者需注意文章未公开具体实现代码和完整故障处理细节。
文章介绍了 LinkedIn 为应对超大规模基础设施中“谁拥有什么资产”问题而设计的 Crews 所有权模型。作者首先分析了规模庞大、组织演进、人员流动、技术依赖复杂和多组织对齐等挑战，然后提出以稳定的团队 Crew 作为资产所有者的核心思路。该模型要求每个 Crew 有明确的责任经理、团队化所有权和唯一资产归属，并支持资产分组、Conventional/Virtual Crew 以及单树层级来保障升级路径。文中还讨论了推动落地的技术集成、组织对齐、数据质量策略和强制政策，并给出已覆盖 15 万关键资产、减少数万运维工单等效果。该方案更适合大型平台型组织，需要较强领导层推动和持续数据治理。
推荐收录，因为这是一线工程组织在超大规模场景下解决资产所有权问题的完整实践案例，提供了清晰的模型设计、实施约束和量化收益，而非泛泛的管理理念。适合平台工程负责人、基础设施团队和大型组织架构师借鉴；其将资产归属从个人转向稳定团队、用单树层级兜底升级的思路具有可迁移价值，但落地时需结合组织授权和数据治理能力。
文章复盘了LinkedIn My Network页面加载缓慢和内容跳动的问题，旧架构中移动端与Web端并行请求多个API，独立渲染不同推荐区块，导致首屏等待近两秒并出现UI闪烁。作者团队将多端点统一为单一API并引入分页，把无限滚动的PYMK拆成多个小cohort，预构建后放入缓存，后续按页获取；同时采用渲染模型，由API定义通用banner和内容容器，减少客户端业务逻辑。优化后P90延迟下降43%，成本节省七位数，Web端LCP和FID显著改善，会员参与度提升。文章未深入讨论缓存一致性、失败处理和更复杂个性化场景，但提供了可工程迁移的架构权衡。
推荐收录，因为文章给出了完整的性能优化工程案例：从多端点并行到统一API、分页和预构建缓存，再通过渲染模型简化客户端，并用量化指标验证收益。适合后端、前端及系统设计工程师参考，其中缓存设计、API收敛和渲染模型解耦的思路可直接迁移到类似推荐流或内容聚合页面的优化中。
文章介绍了 LinkedIn 用 Rust 构建的通用检索引擎 FishDB，替换了运行近十年的 Java 系统 FollowFeed。文章首先分析了旧系统的局限：Java 对象内存开销大、GC 导致高尾延迟、数据模型僵化且业务逻辑耦合，限制了推荐系统的扩展和迭代。随后解释了选择 Rust 的原因，并通过对比实验展示 Rust 在内存效率上的显著优势。FishDB 采用 scatter-gather 架构和 lambda 架构，提供了灵活的命令式查询语言和多种索引结构，包括倒排索引、前向索引、引用索引和基于 RocksDB 的属性存储，以支持图状数据模型和高效过滤排序。迁移采用分层渐进方式，通过 JNI 桥接保持 API 不变，实现了零中断切换，最终取得 2 倍效率、减少 50% 硬件、p99 延迟 40ms 的成果，并将实验周期从数周缩短到数天。文章也指出当前查询语言仍为命令式，未来计划引入声明式语言和向量搜索。
本文是一份高度完整的工程案例，从问题诊断、技术选型、系统架构、索引设计到灰度迁移提供了详实细节和量化结果，展示了如何用内存安全的高性能语言重构大规模检索基础设施。适合负责推荐系统、搜索引擎、分布式存储或性能优化的工程师阅读，可迁移的经验包括内存数据结构设计、Rust 在服务端的应用模式、分层迁移策略以及如何平衡灵活性与性能。
本文复盘了LinkedIn职位摄取系统的设计，该系统每日处理数百万职位、超20TB原始数据。文章先梳理异构源、传输协议、安全、数据新鲜度等挑战，再介绍模块化事件驱动流水线和Job Intake、Job Processing Pipeline两大阶段。重点阐述Job Pull的orchestrator与专用Mining Node分离、抽取逻辑配置化、AI辅助Sitemap创建，以及基于START/JOB/END状态机的Mining Task和优先级队列。处理层通过静态/动态Job Field Processor和pre/mid/post三层实现清洗、增强与校验，并通过multiplexing生成衍生职位。文章以配置驱动扩展、上游背压和让用户掌控平台为关键经验，但偏高层架构，未深入具体实现与性能数据。
收录的直接证据在于文章展示了从异构数据摄取到标准化处理再到发布的全链路架构，包括orchestrator/worker分离、配置驱动抽取、优先级队列和动态处理器等可迁移设计。适合分布式系统、数据平台或集成工程师借鉴，尤其对需要快速接入多源数据、控制上游负载和将定制能力下放给非工程团队的系统有启发。风险是偏高层描述，缺少细粒度实现和量化验证，但整体技术深度满足长期参考要求。
本文介绍 LinkedIn 基于 cert-manager 构建的 Kubernetes 工作负载身份安全框架。系统通过 CSI 驱动将证书以只读卷挂载到容器，私钥仅存内存，并利用 Identity Registry 进行身份证明和签发，防止身份冒用。针对多集群和 25 万 Pod 规模，团队发现开源 approver-policy 无法满足 5 万并发 CertificateRequest 的 SLO（P95 60 秒），遂自研 lipki-controller 作为审批和签发器，并通过 API QPS/并发调优、分区 sharding 实现水平扩展。文章还介绍了 Kyverno 策略限制签发源、渐进式迁移和 Java/Go/Rust 认证库集成。测试显示 54K 请求审批与签发 P90 为 19.3 秒，但水平扩展目前仅用于容灾，尚未实现动态扩缩。
推荐收录。文章不是简单的工具介绍，而是完整展示了 LinkedIn 在超大规模 Kubernetes 集群中落地 cert-manager 的真实工程路径：从身份注册、CSI 挂载、Kyverno 策略到自研 lipki-controller，并给出 54K CertificateRequest 下 P90 19.3 秒的实测数据。适合负责容器平台安全、PKI/证书生命周期、服务网格 mTLS 或大规模 Kubernetes 运维的工程师借鉴，其控制器调优、分区 sharding 和渐进式迁移策略具有可迁移价值；主要边界是 LinkedIn 内部系统和规模假设，且水平扩展暂仅用于容灾。
文章介绍了LinkedIn Hiring Assistant中基于语义搜索的AI代理检索与排序系统MUSE。面对自然语言招聘查询与十亿级会员画像的匹配问题，团队构建了LLM-as-a-judge驱动的教师模型，生成海量资格匹配标签，训练双塔Transformer嵌入模型，并采用Matryoshka嵌入同时服务检索与排序。生产系统采用Lambda架构，结合批量重建与CDC增量推理，通过IVFPQ索引和优化管道实现亚秒级检索。离线回放与在线A/B测试表明，MUSE提升了候选相关性和招聘者参与度，但近似检索与后过滤的损失叠加仍是后续优化方向。
本文详细披露了LinkedIn大规模语义搜索系统的设计与实现，覆盖教师监督、双塔嵌入、十亿级向量检索和在线评估等关键环节，技术细节丰富且可验证。适合搜索推荐、AI基础设施和MLOps方向的工程师参考，其Matryoshka嵌入分层服务、CDC增量更新和IVFPQ优化等实践可直接迁移到类似规模系统。
文章详细介绍了 LinkedIn 如何集成 SGLang 来优化其基于 LLM 的推荐系统，重点解决长输入短输出场景下的推理延迟问题。作者提出了多项目评分（MIS）方法，通过自定义注意力掩码复用成员前缀，将单个请求的延迟降低 69%，并进一步通过 FA3 内核和逐 token FP8 量化获得额外加速。此外，文章还介绍了 Knock-Knock 技术，利用预取成员上下文 KV 缓存并与项目检索并行，将整体延迟从 520ms 降低到 200ms。文中包含具体性能数据和开源贡献，展示了从内核到系统层面的优化路径。
文章展示了 LinkedIn 在真实生产环境中优化推荐系统推理的完整工程案例，提供了多项目评分、FP8 精细量化、延迟隐藏等可复用的技术方案和量化指标。适合从事推荐系统、LLM 推理优化和基础设施建设的工程师参考，其从内核到系统的优化顺序和取舍思路可迁移至类似长上下文低延迟场景。
文章详细介绍了LinkedIn为保障Hadoop集群安全而对其LDAP/Kerberos基础设施进行的现代化改造。旧架构存在单点故障、手工运维繁琐、缺乏测试环境等问题，团队构建了全新的多主复制集群，通过四主节点星型复制、三hub冗余、HAProxy负载均衡和自动故障转移消除了单点故障，并将部署、证书刷新等操作集成到标准部署栈中实现自动化。迁移过程采用先读后写、跨集群复制同步、延迟监控和1分钟TTL的DNS切换，实现了零事故切换和可回滚。文章还说明了GSS-API与负载均衡结合的DNS约束，以及避免双写的一致性考量，适用于大规模分布式系统认证基础设施的演进参考。
推荐收录，因为文章提供了完整的大规模LDAP/Kerberos基础设施迁移案例，包含真实的单点故障痛点、多主复制架构设计、自动化运维改造和零停机迁移方法，证据具体且可迁移。适合负责安全认证、分布式系统高可用或基础设施现代化的工程师参考，特别是面对类似目录服务、Kerberos或负载均衡部署的团队。
文章介绍了LinkedIn在管理约5EB数据和100亿对象的HDFS集群时，如何通过重新设计块放置策略来加速维护操作。默认BPP在维护时会导致大量数据复制和网络拥塞，而采用升级域BPP并定义20个升级域，将同一机架节点归入同一升级域，可以消除维护时的数据复制需求。文章详细描述了对3+EB存量数据进行分批再分布的过程，以及发现开源升级域BPP的写性能问题并开发新BPP排除已选升级域节点的改进。最终实现了每天升级约4.5%节点，显著提升了可靠性和安全性。
推荐收录，因为文章提供了真实超大规模HDFS集群维护中的完整工程案例，包含问题定义、架构取舍、数据迁移方案和性能优化细节，证据充分。适合负责分布式存储、大规模基础设施或HDFS运维的读者参考，其中升级域划分、利用维护模式减少复制和分批迁移的策略可直接迁移到类似系统。