Airbnbs Key-Value-Store Mussel verwendete ursprünglich ein einfaches QPS-Rate-Limiting, um zu verhindern, dass einzelne Clients das System überlasten. Als der Datenverkehr wuchs und komplexer wurde, erwies sich dieser Ansatz aufgrund von Kostenabweichungen und Traffic-Skew als unzureichend. Um dies zu beheben, entwickelte sich Mussel zu einem mehrschichtigen Quality-of-Service (QoS)-System. Die erste Schicht, Resource-Aware Rate Control (RARC), berechnet Anfragen in Request Units (RU), die Zeilen, Bytes und Latenz berücksichtigen und die tatsächlichen Backend-Kosten widerspiegeln. Dieses System verwendet Token-Buckets mit statischen RU-Quoten für jeden Aufrufer. Die zweite Schicht, Load Shedding, bietet Echtzeitschutz, wenn die Kapazität überlastet ist oder Hotspots entstehen. Es kombiniert die Kritikalität des Datenverkehrs, ein Latenzverhältnis, das die Systembelastung anzeigt, und eine von CoDel inspirierte Warteschlangenrichtlinie. Dies ermöglicht es, dass der Datenverkehr mit hoher Priorität reaktionsfähig bleibt und anderen Datenverkehr sanft zurückweist, wenn die Latenz zunimmt. Die dritte Schicht, Hot-Key-Erkennung und DDoS-Abwehr, identifiziert und mildert Anstiege identischer Anfragen, die auf bestimmte Daten abzielen. Sie verwendet einen In-Memory-Top-k-Zähler zur Echtzeiterkennung, lokales Caching auf Dispatcher-Pods und Request Coalescing, um nur eine Anfrage an die Speicherschicht für doppelte Hot-Key-Lookups zu senden. Diese mehrschichtigen Kontrollen haben die Fähigkeit von Mussel, Traffic-Spitzen zu bewältigen und die Zuverlässigkeit zu erhalten, erheblich verbessert. Zu den wichtigsten Erkenntnissen gehören der Wert des frühen Impacts für die Validierung von Konzepten, die Bevorzugung lokaler Kontrollschleifen für die Skalierbarkeit und der Einsatz von Mechanismen, die auf unterschiedlichen Zeitskalen arbeiten. Dieser ausgeklügelte QoS-Stack stellt sicher, dass Mussel auch unter extremen und volatilen Verkehrsbedingungen schnell und zuverlässig bleibt.

Airbnb hat seinen wichtigsten Key-Value-Store, Mussel, von V1 auf V2 umgestaltet, um den sich wandelnden Anforderungen an Echtzeitdaten gerecht zu werden. Mussel V2 behebt die betriebliche Komplexität, Kapazitätseinschränkungen und Konsistenzprobleme von V1 mit einem Cloud-nativen NewSQL-Backend. Zu den wichtigsten Verbesserungen gehören die automatisierte Bereitstellung von Kubernetes, dynamisches Bereichs-Sharding für ein besseres Kapazitätsmanagement und flexible Konsistenzoptionen. Die neue Architektur verfügt über einen zustandslosen Dispatcher-Dienst zum Übersetzen von API-Aufrufen und einen ereignisgesteuerten Schreibpfad mit Kafka für die Dauerhaftigkeit. Die Massenladefunktionen bleiben erhalten und werden durch zustandslose Controller und zustandsbehaftete Worker-Flotten für einen hohen Durchsatz verbessert. Der automatisierte Ablauf der Time-To-Live (TTL) ist jetzt topologieorientiert und skalierbarer. Bei der Migration von V1 auf V2 wurde eine komplexe Blau/Grün-Strategie mit dualen Schreibvorgängen und Schattenlesevorgängen verfolgt, um Ausfallzeiten und Datenverluste zu vermeiden. Zu den wichtigsten Lektionen, die wir gelernt haben, gehören der Umgang mit Konsistenzkomplexitäten und die Bedeutung von Presplitting für die bereichsbasierte Partitionierung. Kafka spielte eine entscheidende Rolle bei der Aufrechterhaltung der Konsistenz während des Migrationsprozesses. Mussel V2 vereint erfolgreich Massenerfassung, Schreibvorgänge mit hoher Geschwindigkeit und Lesevorgänge mit geringer Latenz auf einer einzigen Plattform und vereinfacht so die Dateninfrastruktur für Entwicklungsteams.

Viaduct, Airbnbs datenorientiertes Service Mesh, ist jetzt Open Source. In den letzten fünf Jahren ist die Nutzung von Viaduct bei Airbnb erheblich gewachsen, wobei der Datenverkehr um das Achtfache und die Anzahl der Teams um das Doppelte gestiegen ist. Es wird weiterhin von drei Kernprinzipien geleitet: einem zentralen Schema, gehosteter Geschäftslogik und Reentrancy. Das zentrale Schema integriert Daten unternehmensweit und macht Viaduct zu einem zentralen Data Mesh. Das Hosten von Geschäftslogik direkt in Viaduct, ermöglicht durch eine serverlose Plattform, vereinfacht die Abläufe für Entwickler. Reentrancy ermöglicht es der gehosteten Logik, sich über GraphQL-Fragmente und -Abfragen mit anderer Logik zu verbinden und so die Modularität zu erhalten. Eine kürzliche Überarbeitung, "Viaduct Modern", geht frühere Komplexitäten an, indem die entwicklerseitige Tenant-API auf zwei Resolver-Typen vereinfacht wird: Knoten- und Feld-Resolver. Diese Modernisierung führt auch die Tenant-Modularität ein und formalisiert "Tenant-Module" als Einheiten von Schema und Code, die von einem einzelnen Team verwaltet und über GraphQL zusammengesetzt werden. Die Framework-Modularität wurde ebenfalls verbessert, wodurch stärkere Abstraktionsgrenzen zwischen der GraphQL-Ausführungs-Engine, der Tenant-API und dem gehosteten Code geschaffen wurden. Die neue Engine-API ist dynamisch typisiert, während die Tenant-API statisch typisiert ist, was eine unabhängige Weiterentwicklung ermöglicht. Viaduct bietet eine schrittweise Migration, indem sowohl die Classic- als auch die Modern-Tenant-APIs gleichzeitig auf der neuen Engine ausgeführt werden. Weitere Verbesserungen umfassen eine verbesserte Beobachtbarkeit, schnellere Build-Zeiten durch Schema-First-Entwicklung und Direkt-zu-Bytecode-Generierung sowie einen Dispatcher für Kubernetes-Skalierung und die Eindämmung des Explosionsradius. Airbnb stellt Viaduct Open Source zur Verfügung, um von Beiträgen der Community zu profitieren, und ist der Ansicht, dass es sowohl für groß angelegte als auch für neu entstehende GraphQL-Projekte wertvoll sein kann. Die Modern-API befindet sich derzeit in der Alpha-Phase, aber die neue Engine ist voll produktiv.

Airbnb entwickelte Viaduct, ein datenorientiertes Service Mesh, um die Modularität in seiner auf Microservices basierenden Architektur zu verbessern. Traditionelle Service Meshes sind prozedurorientiert, während sich Viaduct auf Daten konzentriert und ein GraphQL-Schema als zentrales Organisationsprinzip verwendet. Dieses Schema definiert Typen, Abfragen und Mutationen und abstrahiert Service-Abhängigkeiten von den Konsumenten. Viaduct ermöglicht Datenkonsumenten den Zugriff auf Informationen aus mehreren Microservices ohne direkte Abhängigkeiten und vereinfacht so die Architektur. Das zentrale Schema ermöglicht einfachere API- und Datenbank-Schema-Änderungen, wodurch die Datenagilität verbessert und der Koordinierungsaufwand reduziert wird. Viaduct integriert serverlose Funktionen für abgeleitete Daten und minimiert so die Anzahl und Komplexität der Microservices. Das System, das mit graphql-java erstellt wurde, bietet Funktionen wie detaillierte Feldauswahl, Datenbeobachtbarkeit und Intra-Request-Caching. Es nutzt die Tools des GraphQL-Ökosystems und betreibt einen erheblichen Teil des API-Traffics von Airbnb. Viaduct begegnet Herausforderungen im Zusammenhang mit spaghettihaften Abhängigkeitsgraphen, die in großen Service-Oriented Architectures weit verbreitet sind. Der Übergang zu einem datenorientierten Ansatz zielt darauf ab, den Datenzugriff zu rationalisieren und die allgemeine Systemwartbarkeit zu verbessern. Die Architektur begann mit einem sauberen Schema und ist gewachsen, um zahlreiche Kernentitäten zu umfassen. Die bereits in der Produktion eingesetzte Lösung veranschaulicht das Engagement von Airbnb für die Weiterentwicklung seiner SOA.

Airbnb hat sein riesiges JVM-Monorepo von Gradle auf Bazel migriert, ein Prozess, der 4,5 Jahre dauerte. Die Hauptgründe für den Wechsel waren die überlegene Geschwindigkeit, Zuverlässigkeit und die einheitliche Build-Infrastruktur von Bazel. Bazels Caching und die Remote-Ausführung beschleunigten Build- und Testzeiten erheblich und steigerten die Entwicklerproduktivität. Die Migration adressierte die Unzuverlässigkeit von Gradle, die sich aus nicht-hermetischen Builds und Ressourcenkonflikten ergab. Ein Proof-of-Concept mit Airbnbs Viaduct-Service demonstrierte die Effektivität von Bazel und führte zu einer breiteren Akzeptanz. Eine entscheidende Komponente war ein automatischer Generator für Build-Dateien, um den Aufwand für die Entwickler zu minimieren und nebeneinander existierende Build-Systeme beizubehalten. Dieser Generator analysierte effizient Quelldateien, verwaltete Abhängigkeitszyklen und unterstützte detaillierte Build-Graphen. Die Migration beinhaltete auch die Bewältigung von Herausforderungen wie die Unterstützung von Drittanbieterbibliotheken in mehreren Versionen und die Gewährleistung der Kompatibilität bei der Bereitstellung. Abschließend validierten rigorose Tests, insbesondere Start- und Integrationstests für Dienste, die Korrektheit von mit Bazel erstellten Deployments. Das Gesamtergebnis ist ein dramatisch verbessertes Build-System mit erhöhter Entwicklerzufriedenheit.

Airbnb hat erfolgreich sein Istio Service Mesh 14 Mal aktualisiert und verwaltet dabei Zehntausende von Pods über Dutzende von Kubernetes-Clustern und Tausende von VMs. Ihr Aktualisierungsprozess priorisiert Nullausfallzeiten und schrittweise Rollouts, die unabhängige Aktualisierungen ohne Benutzereingriffe ermöglichen. Die Architektur umfasst einen Management-Cluster für Istiod und mehrere Workload-Cluster. Aktualisierungen folgen einem Canary-Modell, bei dem aktuelle und neue Istio-Versionen gleichzeitig ausgeführt werden. Dies wird durch die Koordinierung von Control Plane (Istiod) und Data Plane (istio-proxy) Updates erreicht. Entscheidend ist, dass ältere istio-proxy-Versionen nicht mit neueren Istiods verwendet werden; sie werden atomar aktualisiert. Eine zentrale Management-Datei, rollouts.yml, diktiert die gewünschte Verteilung der Istio-Versionen über Namespaces hinweg. Für Kubernetes injiziert ein Inhouse-Tool namens Krispr während der CI und der Pod-Aufnahme Istio-Revisionslabels in Deployments. Dieser Mechanismus stellt sicher, dass Workloads aktualisiert werden, auch wenn sie nicht häufig eingesetzt werden. Für virtuelle Maschinen werden Aktualisierungen von einem On-Host-Daemon, mxagent, verwaltet, der Artefakte basierend auf VM-Tags installiert. Ein zentraler Controller, mxrc, aktualisiert diese Tags, um sie mit rollouts.yml abzugleichen. Mxrc überwacht auch die VM-Gesundheit und gewährleistet einen kontrollierten Aktualisierungsprozess. Dieser Ansatz entkoppelt effektiv Infrastrukturaktualisierungen von Anwendungsdeployments. Airbnbs kontinuierliche Investitionen in Wartbarkeit und Sicherheit haben diese komplexen, groß angelegten Istio-Aktualisierungen ermöglicht.

Organisationen nutzten traditionell kostspielige, eigenständige Server mit Sharding zur Datenbankskalierung, aber dieser Ansatz erwies sich bei wachsenden Datenanforderungen als problematisch für die Wartung. Der zuverlässige Betrieb horizontal skalierbarer Open-Source-Datenbanken in der Cloud mit hoher Verfügbarkeit, geringer Latenz und Skalierbarkeit zu einem vernünftigen Preis ist eine erhebliche Herausforderung. Airbnb verfolgte eine innovative Strategie, indem es einen verteilten Datenbankcluster über mehrere Kubernetes-Cluster hinweg einsetzte, um die Zuverlässigkeit und Bedienbarkeit zu verbessern. Die Verwaltung von zustandsbehafteten Diensten wie Datenbanken auf Kubernetes ist schwierig, insbesondere im Hinblick auf den Knotenersatz und Upgrades, da Kubernetes kein Bewusstsein für die Datenverteilung hat. Um dies zu mildern, verband Airbnb Speicherdatenträger über AWS EBS mit den Knoten, was eine automatische Wiederanbindung an neue virtuelle Maschinen über Kubernetes Persistent Volume Claims ermöglichte. Spezielle Kubernetes-Operatoren wurden entwickelt, um Ereignisse beim Ersetzen von Knoten zu verwalten, die in datenbankinitiierte, proaktive Infrastruktur- und ungeplante Ausfälle unterteilt wurden. Für datenbankinitiierte und proaktive Ereignisse stellen die Operatoren sicher, dass alle Knoten vor dem Ersetzen laufen und fangen Pod-Evictions ab, um sichere Löschungen zu koordinieren. Ungeplante Ausfälle können nicht koordiniert werden, aber die laufende Wartung wird durch die Blockierung von Ersetzungen geschützt, bis ausgefallene Hardware behoben ist. Um eine hohe regionale Verfügbarkeit zu gewährleisten, setzt Airbnb jede Datenbank in drei unabhängigen Kubernetes-Clustern in verschiedenen AWS Availability Zones ein, was den Einflussbereich von Problemen begrenzt. Die Überprovisionierung von Datenbankclustern garantiert ausreichende Kapazität, selbst wenn eine gesamte Availability Zone, ein Kubernetes-Cluster oder alle Speicher-Nodes in einer Zone ausfallen. AWS EBS bietet eine schnelle Wiederanbindung bei Knotenersetzungen und überlegene Langlebigkeit, was einen hochverfügbaren Cluster mit nur drei Replikaten ermöglicht. Spitzen bei der Tail-Latenz in EBS werden durch die Implementierung von Lese-Timeouts für Speicher und die Erlaubnis von Lesezugriffen auf Replikate zur Reduzierung der Latenz und Vermeidung von Cross-AZ-Kosten gemildert, wobei veraltete Lesezugriffe die Leseleistung weiter optimieren. Diese Multi-Cluster-Kubernetes-Strategie, die AWS EBS und benutzerdefinierte Operatoren nutzt, ermöglicht es Open-Source-verteilten Speichersystemen, hohe Verfügbarkeit, geringe Latenz und Skalierbarkeit in Cloud-Umgebungen zu erreichen und ein robustes Datenmanagement zu ermöglichen.

Airbnb nahm SwiftUI 2022 an, was die Produktivität der Ingenieure verbesserte, aber neue Leistungsprobleme mit sich brachte. Um diese Probleme anzugehen, erstellte Airbnb neue Werkzeuge, um leistungskritische Code-Muster zu identifizieren und zu validieren. Die Feature-Architektur des Unternehmens verwendet deklarative UI-Muster und einrichtungsorientierte Datenflusssysteme, was die Adoption von SwiftUI vereinfachte. Allerdings funktionierten die SwiftUI-Funktionen, die diese Architektur verwendeten, nicht so gut wie erwartet, und das Verständnis der Leistungsmerkmale von SwiftUI ist entscheidend für die Erstellung leistungsfähiger Funktionen. Der Ansichtsdifferenzierungsalgorithmus von SwiftUI, der bestimmt, wann der Körper einer Ansicht neu ausgewertet werden muss, wird oft übersehen und ist nicht offiziell dokumentiert. Der Algorithmus vergleicht jede der gespeicherten Eigenschaften der Ansicht, aber gemeinsame Code-Muster können ihn verwirren, was zu unnötigen Auswertungen des Ansichtskörpers führt. Um dies anzugehen, erstellte Airbnb ein neues @Equatable-Makro, das Equatable-Konformitäten für Ansichten generiert, damit Ingenieure selektiv entscheiden können, welche Eigenschaften bei der Differenzierung verglichen werden sollten. Dieser Ansatz stellt sicher, dass Ansichten differenzierbar sind und verhindert, dass Regressionsfehler später auftreten. Darüber hinaus implementierte Airbnb eine benutzerdefinierte SwiftLint-Regel, um Ingenieuren zu helfen, zu erkennen, wenn ein Ansichtskörper zu komplex ist und in kleinere, differenzierbare Teile aufgeteilt werden muss. Durch die Aufteilung von Ansichten in kleinere Teile kann SwiftUI effizient nur die Teile der Ansicht aktualisieren, die tatsächlich geändert wurden, und die Leistung bei wachsender Komplexität der Funktionen aufrechterhalten.

Das Load-Testing auf Systemebene ist für Airbnb von entscheidender Bedeutung für Zuverlässigkeit und Effizienz. Es dient zur Identifizierung von Engpässen, zur Bewertung der Kapazität, zur Festlegung von Performance-Grundlagen und zur Erkennung von Fehlern. Impulse ist ein internes Load-Testing-as-a-Service-Framework, das Tools zur Erzeugung synthetischer Lasten, zur Simulation von Abhängigkeiten und zur Erfassung von Traffic-Daten aus Produktionsumgebungen bereitstellt. Impulse umfasst vier Hauptkomponenten: einen Load-Generator, einen Traffic-Collector, einen Dependency-Mocker und einen Testing-API-Generator. Der Load-Generator ermöglicht es Service-Betreibern, kontextbezogene Load-Tests durchzuführen, Anfragen on-the-fly zu generieren und Abhängigkeiten zu simulieren. Der Traffic-Collector erfasst sowohl Upstream- als auch Downstream-Traffic, sodass Impulse den Produktions-Traffic während des Load-Testings präzise wiedergeben kann. Der Dependency-Mocker simuliert Downstream-Antworten mit Latenz, wodurch Interferenzen zwischen Diensten beseitigt und Kommunikationskosten reduziert werden. Der Testing-API-Generator erstellt HTTP-APIs während der CI-Phase, sodass Load-Testing-Tools Traffic an diese synthetischen APIs senden können, wodurch asynchrone Abläufe so ausgeführt werden können, als wären sie synchron. Impulse ist darauf ausgelegt, den manuellen Aufwand zu minimieren, sich nahtlos in den Observability-Stack von Airbnb zu integrieren und Teams in die Lage zu versetzen, potenzielle Probleme proaktiv anzugehen. Das Framework hat positives Feedback erhalten und hilft Teams, potenzielle Probleme in ihren Diensten zu identifizieren und zu beheben. Impulse wird derzeit in mehreren Backend-Diensten des Kundensupports implementiert und wird von Teams im gesamten Unternehmen geprüft.

Airbnb hat sein interaktives Sprachdialogsystem (IVR) mithilfe von maschinellem Lernen verbessert, um Nutzer besser zu verstehen und Agenten effektiver zu unterstützen. Das IVR-System hört zu, versteht und antwortet in Echtzeit, sodass Anrufer ihre Probleme auf natürliche Weise beschreiben und sofort Unterstützung erhalten können. Das System verwendet automatische Spracherkennung, Erkennung des Anrufgrunds und Sprachmodelle, um Nutzer zu verstehen und Agenten zu unterstützen. Das automatische Spracherkennungssystem wurde verbessert, um Fehler zu reduzieren, und ein Modell zur Erkennung des Anrufgrunds wurde entwickelt, um die Absicht hinter der Anfrage eines Anrufers zu identifizieren. Ein System zur Abfrage von Hilfeartikeln stellt Nutzern relevante Informationen zur Verfügung, und ein Paraphrasierungsmodell stellt sicher, dass Nutzer die Lösung verstehen, bevor sie an einen Agenten weitergeleitet werden. Das System hat die Nutzerzufriedenheit verbessert, den Bedarf an menschlichem Eingreifen reduziert und ein intuitiveres Sprachunterstützungserlebnis geboten.

Airbnb verwendet ein Framework, um den Wert von Listings für Gäste zu bestimmen, indem es den Lifetime-Wert (LTV) von Listings berechnet. Dieses Framework umfasst Baseline-, inkrementellen und marketing-induzierten inkrementellen LTV. Der Baseline-LTV schätzt die Gesamtbuchungen über 365 Tage, indem es Machine-Learning- und Listing-Daten verwendet. Der inkrementelle LTV behandelt die Herausforderung der Kannibalisierung, indem er den Wert berechnet, der durch jedes Listing hinzugefügt wird. Der marketing-induzierte LTV misst den Einfluss von Airbnbs Initiativen auf den Listing-Wert. Eine genaue Messung des Baseline-LTV ist entscheidend, was Modelltraining und -bewertung über Zeit erfordert. Die Berücksichtigung von Inkrementalität erfordert die Schätzung einer Produktionsfunktion, um Angebot und Nachfrage mit Buchungen zu verknüpfen. Die Bewältigung von Ungewissheit, insbesondere während der Pandemie, umfasste die Aktualisierung von LTV-Schätzungen mit tatsächlichen Buchungen. Dieses LTV-Framework hilft Airbnb, wertvolle Listings zu identifizieren, Versorgungsstrategien zu informieren und interne Initiativen zu bewerten. Der Ansatz kann auch auf andere Bereiche wie Airbnb-Erlebnisse ausgeweitet werden. Die laufende Entwicklung des Frameworks zielt darauf ab, die Erfahrung für beide Gastgeber und Gäste zu verbessern.

Die Suche von Airbnb spielt eine entscheidende Rolle bei der Suche nach dem perfekten Aufenthalt für Gäste, aber es ist eine herausfordernde Aufgabe aufgrund der großen Anzahl verfügbarer Häuser und komplexer Suchanfragen. Um dies zu bewältigen, baute Airbnb ein Embedding-basiertes Retrieval-System (EBR) zur Eingrenzung der initialen Menge an geeigneten Häusern auf eine kleinere Auswahl. Das EBR-System besteht aus drei Schlüsselkomponenten: dem Erstellen von Trainingsdaten, dem Entwerfen der Modellarchitektur und der Entwicklung einer Online-Dienststrategie. Die Trainingsdaten-Pipeline nutzt kontrastives Lernen, um Häuser und Suchanfragen in numerische Vektoren abzubilden. Die Modellarchitektur folgt einem traditionellen Zweiturm-Netzwerk-Design, wobei ein Turm Merkmale der Hausliste verarbeitet und der andere Turm Merkmale in Bezug auf die Suchanfrage verarbeitet. Der Listing-Turm wird täglich offline berechnet, was die Online-Latenz reduziert. Für den Online-Dienst erkundete Airbnb approximative nächste Nachbarlösungen (ANN) und wählte einen invertierten Datei-Index (IVF) aufgrund seines besseren Kompromisses zwischen Geschwindigkeit und Leistung. Die IVF-Lösung clusteriert Listen vorher und ruft Häuser aus den Top-Clustern ab, indem sie Cluster-Zuweisungen als Standard-Suchfilter behandelt. Das EBR-System führte zu einem statistisch signifikanten Anstieg der Gesamtbuchungen bei A/B-Tests, indem es den Kontext der Abfrage effektiver berücksichtigte und Häuser genauer bei der Retrieval rangierte. Das System wurde vollständig in der Produktion von Suche und E-Mail-Marketing lanciert.

"Airbnb verwendete einen LLM-basierten Ansatz, um fast 3.500 React-Komponententest-Dateien von Enzyme zu React Testing Library (RTL) zu migrieren. Anfangs schätzten sie, dass dies 1,5 Jahre dauern würde, aber sie haben es in nur sechs Wochen abgeschlossen. Die Migration umfasste die Refactoring von Testdateien, während die ursprüngliche Testabsicht und die Codeabdeckung erhalten blieben. Sie bauten eine automatisierte Pipeline mit Validierung, Refactoring-Schritten und Wiederholungsschleifen auf. Dem LLM wurde zunehmend Kontext, einschließlich Komponenten-Code und verwandter Tests, bereitgestellt, um die Erfolgsraten zu verbessern. Sie verwendeten einen "Beispiel, einstellen und durchsuchen"-Ansatz, um Anweisungen und Skripte zu verbessern, wodurch die Vollendungsrate von 75 % auf 97 % stieg. Die Automatisierung behandelte effizient den größten Teil der Migration, während ein kleiner Prozentsatz manuelle Korrekturen erforderte. Das Projekt behielt die Testabsicht und die Codeabdeckung bei und erwies sich als viel schneller und kosteneffizienter als eine manuelle Migration. Diese Erfahrung unterstreicht die Macht von LLMs für groß angelegte Code-Transformationen. Airbnb plant, den Einsatz von LLMs für die Produktivität von Entwicklern auszuweiten. Sie suchen auch Ingenieure, die komplexe Probleme auf großem Maßstab lösen möchten."

Airbnb hat sein Ranking-Algorithmus für die Kartenansicht angepasst, um Gäste besser mit Gastgebern zu verbinden. Anfangs basierte der Algorithmus auf Buchungswahrscheinlichkeiten, aber dieser Ansatz funktioniert nicht für Karten, auf der die Aufmerksamkeit der Nutzer gleichmäßig auf die Pins verteilt ist. Um die Nutzererfahrung zu verbessern, testete Airbnb verschiedene Modelle der Nutzer-Aufmerksamkeit, darunter die Begrenzung der Anzahl von Kartenpins und die Schaffung von zwei Ebenen von Pins basierend auf Buchungswahrscheinlichkeiten. Diese Änderungen führten zu signifikanten Verbesserungen bei den Buchungen und der Nutzerzufriedenheit. Das Unternehmen entwickelte auch ein Algorithmus, um die Karte neu zu zentrieren, um Listings mit den höchsten Buchungswahrscheinlichkeiten hervorzuheben, was zu weiteren Verbesserungen bei den Buchungen und einer Reduzierung der Kartenzüge führte. Trotz dieser Fortschritte gibt es immer noch die Herausforderung, den gesamten Bereich der verfügbaren Listings auf der Karte darzustellen, was ein Schwerpunkt für zukünftige Arbeit ist.

Airbnb hatte eine bedeutende Präsenz auf der KDD-Konferenz 2024 in Barcelona, Spanien, mit drei vollständigen ADS-Track-Papieren, einem Workshop und sieben Workshop-Papieren und eingeladenen Vorträgen, die in die Hauptkonferenz-Verhandlungen aufgenommen wurden. Die Themen der Arbeiten umfassten Tiefes Lernen & Suche-Ranking, Online-Experimentation & Messung und Zweischienen-Märkte. Die Beiträge des Unternehmens zum Workshop über die Optimierung von Zweischienen-Märkten diskutierten die Entwicklung der Inhalts-Ranking, Empfehlungssysteme und Daten-Mining bei der Lösung für Produzenten und Verbraucher auf diesen Plattformen. Airbnbs Arbeit zum Gast-Intention-Modell für Personalisierung verwendet einen tiefen Lernansatz, um Reisepläne vorherzusagen und produziert multiple Benutzer-Intent-Signale. Das Unternehmen stellte auch ein Papier über das Verständnis der Gäste-Nachfrage vor, kombinierte ökonomische Modellierung mit kausalen Inferenz-Techniken, um die Preissensitivität unter Gäste-Segmenten zu schätzen.

Vijaya Kaza ist die Chief Security Officer und Leiterin der Abteilung für Engineering für Vertrauen und Sicherheit bei Airbnb, wo sie Teams leitet, die Technologien entwickeln, um die Community zu schützen und die Infrastruktur sicher zu machen. Sie ist auch die exekutive Co-Sponsorin des Diversity Council von Airbnb Tech. Vijaya wuchs in einer großen Familie in Indien auf, wo sie akademisch hervorragend sein sollte, und entwickelte eine starke Affinität zu Naturwissenschaften und Mathematik, studierte Elektrotechnik im College. Nach dem College bekam sie einen Job bei Cisco als Software-Entwicklerin und stieß zufällig auf das Sicherheitsfeld, indem sie einem Manager folgte, den sie mochte. Sie verbrachte 17 Jahre bei Cisco, wo sie die Produktentwicklung für ein Sicherheitsproduktportfolio im Wert von 1 Milliarde Dollar leitete, und arbeitete später bei FireEye und Lookout, einem Startup in San Francisco, das sich auf mobile Sicherheit konzentrierte. Vijaya wurde für die CSO-Rolle bei Airbnb angesprochen, was sie zunächst zögerte, aber von der Vision und Mission des Unternehmens beeindruckt war. Sie trat Airbnb 2019 bei, angezogen von der Unternehmensmission, eine positive Nutzererfahrung zu liefern, und der mission-orientierten Herangehensweise. Vijaya leitet zwei Teams, Trust and Safety und Security, die ein gemeinsames Ziel teilen, die Nutzer und die Plattform zu schützen, aber unterschiedliche Techniken, Bedrohungen und Fokusgebiete haben. Außerhalb der Arbeit hat Vijaya Improvisationskomödie betrieben, die ihr wertvolle Führungslektionen beigebracht hat, wie zum Beispiel, auf den Füßen zu denken und auf neue Szenarien im Moment zu reagieren. Sie rät anderen, sich auf das Ziel zu konzentrieren, einen ruhigen Kopf zu bewahren und unbeirrt voranzuschreiten, wenn sie professionelle Rückschläge erleben.

"Airbnb nutzt datengetriebene Segmentierung, um die Verfügbarkeitsmuster seiner Gastgeber zu verstehen. Dieser Prozess beinhaltet die Analyse der Verfügbarkeitsrate, der Streakiness (Verfügbarkeit in aufeinanderfolgenden Zeiträumen) und der Saisonalität von Listings, um Gastgeber mit ähnlichen Profilen zu unterscheiden. Durch die Anwendung eines K-Means-Clustering-Algorithmus identifiziert Airbnb acht unterschiedliche Cluster von Gastgebern basierend auf ihren Verfügbarkeitsmustern. Diese Cluster umfassen "Immer verfügbar", "Kurze Saison", "Veranstaltungsmotiviert" und andere, jedes mit einzigartigen Merkmalen und Vorlieben. Das Unternehmen validiert diese Segmente durch A/B-Tests, korreliert sie mit bekannten Attributen und führt UX-Forschung durch, um sicherzustellen, dass sie mit dem realen Verhalten übereinstimmen. Dieses Segmentierungsmodell wird dann mithilfe eines Entscheidungsbaum-Algorithmus auf alle Listings skaliert und in das Data Warehouse integriert, um von verschiedenen Teams genutzt zu werden. Dieser Ansatz hilft Airbnb, gezielte Strategien, Produkte und Messaging zu entwickeln, um seine Gastgeber besser zu unterstützen und die Gesamtnutzererfahrung zu verbessern."

Airbnb entwickelte eine Plattform für Stream-Verarbeitung namens User Signals Platform (USP), um die Benutzererfahrung durch Personalisierung zu verbessern. Die Plattform nutzt Benutzer-Engagement-Daten, um maßgeschneiderte Interaktionen während des Buchungsprozesses bereitzustellen. Sie besteht aus einer Daten-Pipeline-Schicht und einer Online-Dienstschicht, wobei Flink-Streaming für nahezu Echtzeit-Verarbeitung und Batch-Verarbeitung für Datenkorrektur und -nachführung eingesetzt wird. USP unterstützt verschiedene Benutzer-Ereignis-Verarbeitungen, einschließlich Benutzer-Signale, Benutzer-Segmenten und Sitzungs-Engagements. Sie verwendet auch Metriken wie Ereignis-Latenz, Ingestions-Latenz, Job-Latenz und Transformations-Latenz, um die Leistung von Streaming-Jobs zu messen. Die Plattform ermöglicht es Entwicklern, Transforms und Benutzer-Segmente zu definieren, ohne sich um Streaming-Komponenten kümmern zu müssen. Um die Stabilität von Flink-Jobs zu verbessern, verwendet Airbnb standby-Task-Manager, um kontinuierliche Verarbeitung sicherzustellen, wenn ein Task-Manager ausfällt.

Airbnb hat ein KI-gesteuertes Foto-Tour-Feature entwickelt, um das Gästeerlebnis durch detaillierte Informationen über Angebote zu verbessern. Das Feature verwendet Vision-Transformers, um Angebotsfotos in 16 verschiedene Raumspezifikationen zu klassifizieren und zu organisieren. Um die Modellgenauigkeit zu verbessern, setzte Airbnb Vorverarbeitung, Multitask-Lernen, Ensemble-Lernen und Wissensdestillation ein. Der Vorverarbeitungsprozess umfasste die Schulung eines Vision-Transformer-Modells auf Millionen von Airbnb-Angebotsfotos. Multitask-Lernen nutzte ein vielfältiges Datenset, um die Fähigkeit des Modells zu verbessern, visuelle Informationen zu interpretieren. Ensemble-Lernen kombinierte die Stärken mehrerer Modelle für robuste Vorhersagen und Wissensdestillation ermöglichte eine effiziente Bereitstellung ohne Genauigkeitsverlust. Die KI-gesteuerte Foto-Tour wurde als Teil von Airbnbs Winter-Release 2023 gestartet und das Unternehmen setzt die Modelle weiterhin für ein besseres Benutzererlebnis ein.

Airbnb hat kürzlich Bazel, Googles Open-Source-Build-Tool, als universelles Build-System für Backend-, Web- und iOS-Plattformen übernommen. Das große Web-Monorepo des Unternehmens, das aus über 11 Millionen Codezeilen besteht, stellte Herausforderungen mit maßgeschneiderten Build-Skripten und Caching-Logik dar, die schwer zu warten und zu skalieren waren. Um diese Probleme zu lösen, migrierte Airbnb zu Bazel, das Sophistikation, Parallelität, Caching und Leistung bot. Der Migrationsprozess begann 2021, aber es gab keine öffentliche Industrie-Vorgabe für die Integration von Bazel mit Web im großen Maßstab außerhalb von Google. Das Team musste Leistungsprobleme bei der Übertragung großer Dateien in die Remote-Umgebung überwinden und etablierte Migrationsprinzipien, die die Verbesserung oder Aufrechterhaltung der Gesamtleistung und die Reduzierung der Auswirkungen auf Entwickler, die zum Monorepo beitragen, während des Übergangs umfassten. Um das Repository für Bazel vorzubereiten, führte das Team Zyklusbrechungen und automatisierte die Generierung von BUILD.bazel-Dateien durch. Sie migrierten auch CI-Jobs zu Bazel, beginnend mit Typprüfung, Linting und Unit-Testing. Das Team aktivierte TypeScript, ESLint und Jest und führte Caching ein, um die Eingabegröße zu reduzieren und die Leistung zu verbessern. Um ein Zurückfallen zu verhindern, versetzte das Team Tests von "versteckt" zu "erforderlich" über ein Regelattribut und stellte sicher, dass es nur eine einzige Wahrheitsquelle gibt, indem es Tests nicht unter der Jest-Konfiguration ausführt, die ersetzt wird. Sie schrieben auch ein Skript, um vor und nach Bazel zu vergleichen und die Migrationsbereitschaft mithilfe von Metriken wie Testlaufzeit, Code-Coverage-Statistiken und Fehlerhäufigkeit zu bestimmen. Parallel zur CI-Migration stellte das Team sicher, dass Entwickler Bazel lokal ausführen können, um CI-Fehler zu reproduzieren und zu iterieren. Sie lieferten ein lokales Bazel-Erlebnis, das dem bestehenden Entwickler-Erlebnis und der Leistung entspricht oder überlegen ist, sodass Entwickler weiterhin vertraute Tools verwenden und sich bei Bedarf für Bazel entscheiden können.

Airbnb hat die Art und Weise, wie Menschen auf der ganzen Welt reisen, revolutioniert, aber die Bereitstellung relevanter Optionen für Gäste in den Suchergebnissen ist aufgrund der vielfältigen Standorte und Unterkunftsarten in ihrem Bestand zunehmend komplex geworden. Um diese Herausforderung zu meistern, wechselte Airbnb von einfachen Heuristiken zu fortgeschrittenen maschinellen Lernalgorithmen und Verstärkungslernalgorithmen, um ihren Standortabrufprozess zu transformieren. Anfangs verwendete Airbnb Heuristiken, um Kartenbereiche basierend auf der Art der Suche zu definieren, aber diese Heuristiken hatten Grenzen und konnten nicht zwischen verschiedenen Suchtypen unterscheiden oder sich gut an neue Daten anpassen. Airbnb erkundete dann die Statistik, um den Standortabruf zu verbessern, indem sie für jedes Reiseziel ein Dataset erstellte, das aufzeichnete, wo Gäste Listings gebucht hatten, wenn sie nach diesem Ziel suchten. Diese statistische Vorgehensweise hatte jedoch immer noch Grenzen und behandelte alle Suchen für einen Standort gleich, unabhängig von spezifischen Suchparametern. Dies führte Airbnb dazu, zu glauben, dass der Standortabruf möglicherweise fortgeschrittenere Techniken wie maschinelles Lernen erfordert. Airbnb entwickelte ein maschinelles Lernalgorithmus, das aus verschiedenen Suchparametern wie der Anzahl der Gäste und der Aufenthaltsdauer lernen und relevantere Kartenbereiche für jede Suche vorhersagen konnte. Das maschinelle Lernsystem erhöhte die Trefferquote der gebuchten Listings um 7,12 % und reduzierte die Größe des Abrufbereichs um 40,83 %, was zu einem kumulativen Effekt von +1,8 % bei nicht stornierten Buchungen auf der Plattform führte. Airbnb führte dann Verstärkungslernen in den Standortabrufprozess ein, sodass das System kontinuierlich aus den Interaktionen der Gäste lernen und den Abrufbereich basierend auf dem Buchungsverhalten der Gäste anpassen konnte. Das Verstärkungslernalgorithmus erkundete erfolgreich mehr für weniger besuchte Standorte und erkundete weniger für Standorte, die oft gesucht und gebucht werden, was zu einem kumulativen Anstieg von 0,51 % bei nicht stornierten Buchungen und 0,71 % bei 5-Sterne-Reisen führte. Airbnbs Reise von einfachen Heuristiken zu komplexen maschinellen Lernalgorithmen und Verstärkungslernalgorithmen zeigt die Kraft datengetriebener Ansätze bei der Transformation komplexer Systeme. Die Transformation führt kumulativ zu einem Anstieg von 2,66 % bei nicht stornierten Buchungen, einer bedeutenden Leistung für ein Unternehmen, das auf der Größe von Airbnb operiert.

Airbnb's Automatisierungsplattform v2 ist eine konversationale KI-Plattform, die darauf ausgelegt ist, aufkommende Anwendungen für große Sprachmodelle (LLM) zu unterstützen. Die Plattform ermöglicht es Entwicklern, LLM-Anwendungen zu erstellen, die die Effizienz und Reaktionszeiten des Kundensupports verbessern. Sie umfasst mehrere wichtige Komponenten wie den Chain-of-Thought-Workflow, das Kontextmanagement und den Guardrails-Framework. Der Chain-of-Thought-Workflow verwendet LLMs als Denkmaschinen, um zu bestimmen, welche Werkzeuge in welcher Reihenfolge verwendet werden sollen. Das Kontextmanagement stellt sicher, dass das LLM Zugriff auf notwendige Kontextinformationen hat, während der Guardrails-Framework die Kommunikation mit dem LLM überwacht, um sicherzustellen, dass sie hilfreich, relevant und ethisch ist. Die Plattform entwickelt sich weiter, um transformative Technologien zu integrieren, die Fähigkeiten des Chain-of-Thought-Tools zu erweitern und die Simulation von LLM-Anwendungen zu untersuchen.