Airbnb 向 Homes、Experiences 和 Services 的扩展，要求其离线数据仓库的数据建模框架进行重构。核心挑战在于如何在保持一致性与灵活性的同时，避免数据孤岛和技术债务。他们采取了一种平衡策略，将集中化原则与去中心化建模指南相结合。三项基础原则确保了数据的一致性：禁止混合模型、统一的标识符命名规范以及清晰的命名空间组织。建模指南使各团队能够根据属性的共享性与独特性、未来演进方向以及下游消费场景，自主选择独立模型或单体模型。针对 Listing（房源）、Availability（可用性）、Location（位置）及 Guest Interactions（用户互动）等特定产品领域，因其属性差异显著，采用独立模型；而 Messaging（消息）、Payments（支付）和 Customer Support（客户支持）等跨领域概念，则通过单体模型实现统一视图。离线数据仓库作为关键的转换层，负责将原始生产数据标准化以供分析使用。管理数据债务（包括迁移遗留表）是一项重大任务，需要谨慎的沟通与验证。该框架为 Airbnb 不断变化的数据需求提供了可扩展且一致的基础。

Airbnb 开发了 Sitar Agent，一个轻量级的 Kubernetes Sidecar，用于可靠地向数千个服务实例交付动态配置变更。配置交付始于开发人员通过 Git 或 UI 创建或更新配置值，这些值随后存储于 Sitar Service 中。Sitar Service 会定期将配置的全量状态打包为压缩快照并上传至 AWS S3。当服务 Pod 启动时，Sitar Agent 首先将这些 S3 快照下载到挂载的磁盘上，从而实现快速引导。随后，Agent 与 Sitar Service 同步自快照创建以来所做的任何变更，并向主应用容器发出就绪信号。启动后，Agent 每隔数秒持续轮询 Sitar Service 以获取更新。主应用容器通过 Sitar 客户端库从挂载的磁盘读取配置，该库缓存配置值并检测文件变更。一项关键的设计决策是将 Sitar Agent 作为独立的 Sidecar 容器，而非集成到主容器中，此举优先考虑了可靠性、操作安全性和多语言支持，而非微小的成本节约。该系统采用拉取（pull）模型，Agent 轮询 Sitar Service，并通过服务端缓存和基于令牌的数据库访问进行优化，以降低负载。对于本地磁盘键值存储，Airbnb 选择了 SQLite 而非基于 Sparkey 的旧版实现，原因在于 SQLite 在并发能力、性能及多语言支持方面表现更优。SQLite 内置的预写日志（Write-Ahead Logging）允许在写入期间进行并发读取，其更简单的运维模型也优于 RocksDB 虽性能更高但复杂度更大的方案。这种健壮的 Sidecar 设计确保了关键配置能够快速、可靠地交付至 Airbnb 庞大的服务舰队。

新冠疫情带来了预测挑战，因为它扰乱了历史模式，使得传统模型不可靠。需求复苏不同步且地理分布不均，疫苗接种和边境重新开放的进度各不相同。若等待每个复苏市场的本地数据，将导致在相当长一段时间内处于“盲目预测”状态。Airbnb 的解决方案是横向跨地理区域观察，而非仅向后回溯时间。 他们观察到复苏是顺序展开的，某些走廊在其他地区之前便已出现变化。一个关键信号是平均预订提前期：在干扰期间缩短，在复苏期间延长。通过比较欧洲和北美等地区这些提前期变化的时序，他们可以推断一个市场如何基于另一个市场的经验对重新开放做出反应。这使得他们能够将早期受影响走廊的后验分布作为信息丰富的先验，用于后期受影响的市场。 这种先验传播机制实现了实时学习与预测，即使在本地数据稀缺的市场也是如此。该方法需要全球覆盖范围、细粒度数据以及分层贝叶斯建模框架。该方法不仅适用于危机情境，还可用于预测新产品功能上线或监管变更的影响。它允许从早期采用市场立即学习，从而为尚未经历变化的市场提供预测依据。

Airbnb 从使用 PaaS 图数据库转向构建内部知识图谱基础设施，以提升性能。身份图谱对于信任与安全至关重要，最初依赖关系型数据库，随后采用 SaaS 图数据库，但面临可扩展性和延迟挑战。新的内部托管基础设施基于 JanusGraph 和 DynamoDB 构建，提供统一平台。为实现 Airbnb 的性能需求，实施了关键优化，包括自定义事务和并行查询执行。该平台支持多租户操作并强制执行模式约束。客户端查询优化（包括重写 Gremlin 查询）进一步提升了性能。内部图谱基础设施显著提高了可扩展性并增强了系统稳定性。各类查询模式均实现了性能提升，从而加快了读 API 的响应时间。自管理系统能够更快地解决故障事件。新系统的写入 QPS 达到原有方案的 10 倍。迁移大幅降低了复杂查询的 P99 延迟。Airbnb 的知识图谱现已支持关键用例。

Viaduct 是 Airbnb 面向数据的服务网格，现已作为社区驱动的项目发布，并提供了稳定的 API。它作为基于 GraphQL 的接口，用于访问和交互各种数据源。Viaduct 的目标是为组织的数据提供统一模式，同时支持去中心化开发。与 GraphQL Federation 不同，Viaduct 通过部署在共享多租户运行时上的模块来分布开发工作。团队通过创建包含 SDL 和解析器的模块来贡献代码，专注于领域逻辑。Viaduct 也可作为联邦架构中的子图运行。1.0 版本新增了功能、通过注解实现的稳定性以及自动化发布机制。Airbnb 致力于社区参与，利用 GitHub 进行架构讨论。文章还突出了 Airbnb 工程师将在 GraphQLConf 2026 上举行的 upcoming 讨论，展示 Viaduct 的能力，包括概率测试、监控、分片解决方案以及使用大语言模型生成模拟数据。该公告鼓励希望统一数据层或为项目做出贡献的人员参与。

核心问题在于，可观测性系统在它所监控的基础设施发生故障时也可能失效，从而形成循环依赖。Airbnb 与许多组织一样，曾面临此类问题：其指标管道依赖于它所观测的同一套系统。必须打破这一依赖链，以确保监控的可靠性，尤其是在发生中断时。为解决这一问题，Airbnb 通过由云团队管理的专用 Kubernetes 集群实现了计算隔离。他们重新设计了网络架构，构建了一个基于 Envoy 的自定义第 7 层入口层，以绕过服务网格来传输遥测数据，从而确保优先级和隔离性。由于指标具有极高的数据量，专用网络路径可避免拥塞和潜在的中断。Airbnb 还实施了元监控（meta-monitoring），即对可观测性栈本身进行监控，以检测潜在问题。元监控的关键组成部分是采用“死信开关”（Dead Man's Switch）机制来检测监控系统自身的故障。这一整体方法构建了一个稳健的信号链，可防止可观测性设置中出现静默故障。关键启示在于将监控视为生产系统，确保其可靠性超越其所观测的系统。这对于实现及时的故障响应以及维持用户和业务信心至关重要。这些原则具有普适性，涉及为构建稳健的系统设计而隔离故障域。

Airbnb 面临复杂工作流（如保险理赔）的持久化执行挑战。现有的外部编排引擎解决方案存在运维复杂和供应商锁定等缺点。为解决这些问题，Airbnb 构建了 Skipper，一种嵌入到每个服务内部的流程引擎。Skipper 强调简洁性、无单点故障以及复用现有数据库。其核心设计包括定义逻辑与动作的工作流，这些工作流封装了单个操作。持久性通过回放机制实现：将动作结果检查点化地写入数据库。回放机制使得工作流在中断后能够从断点处恢复。为提高效率，状态字段被持久化，并通过信号来更新工作流的状态。使用 Skipper 测试工作流更加简便，因为它无需配置队列或模拟任何基础设施。这种方法在确保持久化执行的同时，不引入额外依赖，也不牺牲性能。

Airbnb 开发了一套内部存储系统，用于处理每秒 5000 万个样本以及 2.5 PB 的时间序列数据。这一转变的必要性源于其不断演进的产品和基础设施中广泛部署的代码监控所产生的海量数据。主要工程挑战在于如何高效地持久化并服务这一庞大的数据集。 为应对如此巨大的规模，Airbnb 采用了多租户架构，按服务或进程对租户进行隔离，以实现稳定的分组与归因。他们实施了 Shuffle Sharding 机制，将租户工作负载隔离开来，通过将租户仅写入并查询部分节点，从而提升了系统的容错能力。针对租户接入和配置管理等运营复杂性，系统引入了统一的控制平面，自动化租户接入流程并简化配置更新。 该系统的关键需求包括：每秒处理超过 5000 万个样本、支持大量仪表板和告警，并保持低查询执行延迟。初期通过影子集群进行的验证揭示了可靠性问题、压缩延迟以及在大数据量负载下查询性能缓慢等问题。解决这些挑战的第一步是确保单个集群的可靠性，重点通过基准测试、防护机制和查询路径隔离，来稳定写入、读取和压缩操作。 系统通过在三可用区部署具备状态感知能力的组件实现了容错。同时，实施了副本级限制和租户级控制，以有效管理集群规模并保护系统。随后，系统演进为多集群架构，以降低故障影响范围并增强灵活性。 然而，多集群方案也带来了指标发现、查询以及运营开销等方面的复杂性。这些问题通过租户与集群映射工具以及基于 Kubernetes Operator 的自动化部署策略得到了缓解。引入带有自定义增强的 Promxy 后，实现了跨集群查询与告警功能。 此次实践的关键经验包括：跨集群查询成本高昂，以及部署一致性的重要性——这可通过自动化和标准化部署来实现。其理念逐渐演变为将集群视为可替换的资源（类似“牲畜”），而非关键且独特的“宠物”，从而更易于扩展和维护。最终，构建该平台需要架构创新、严谨的运营实践，以及在管理预期方面的文化转变。

Airbnb 正演变为一个更具社交属性的平台，通过“体验”（Experiences）功能强调社区连接。平台将用户隐私置于首位，通过区分内部用户数据与面向公众的个人资料来实现这一目标。用户可自主控制个人资料的可见性，决定在“体验”中分享哪些信息。为此，Airbnb 采用独特的用户 ID 和资料 ID，以支持不同场景下的灵活隐私设置。这使得用户能够在适当情况下拥有多个独立资料，例如房东资料和租客资料。Airbnb 还采用名为 Himeji 的权限管理系统，确保最小权限原则并强化数据安全。该实施过程包括自动化审计、团队协作以及借助 AI 进行重构，以确保标识符的正确使用。在迁移过程中，类型安全与严格测试对于维护数据完整性至关重要。最终，Airbnb 的隐私原则旨在平衡社交功能与用户对个人信息的控制权。这一方法致力于在 Airbnb 社区中同时促进连接与隐私。该系统的建立，旨在让用户能够自信地与他人建立联系并分享信息。

Airbnb 将其巨大的 JVM 单体仓库从 Gradle 迁移到 Bazel，这个过程花了 4.5 年。切换的主要原因是 Bazel 的速度、可靠性和统一的构建基础设施更为出色。Bazel 的缓存和远程执行大大加快了构建和测试时间，提高了开发人员的生产力。迁移解决了 Gradle 的不可靠性问题，这些问题源于非 hermetic 构建和资源竞争。Airbnb 的 Viaduct 服务的概念验证证明了 Bazel 的有效性，从而导致了更广泛的采用。一个关键组件是自动构建文件生成器，以最小化开发人员的工作量并维护共存的构建系统。这个生成器高效地解析源文件、管理依赖循环并支持细粒度的构建图。迁移还涉及解决诸如多版本第三方库支持和确保部署兼容性等挑战。最后，严格的测试，特别是服务的启动和集成测试，验证了 Bazel 构建部署的正确性。总的来说，结果是一个大大改进的构建系统，开发人员的满意度也大大提高。