RSS Der Airbnb Tech Blog - Med... Notiz

RSS Der Airbnb Tech Blog - Medium

Airbnb Engineering ist ein Portfolio von Artikeln des Airbnb-Ingenieurteams, in dem verschiedene Technologien, Innovationen und Fallstudien der Branche diskutiert werden. Die Webseite bietet Lesern tiefgreifende Analysen und Einblicke in die verschiedenen Ansätze und Herausforderungen, mit denen sie im Hinblick auf Software-Engineering, Produktentwicklung, Skalierbarkeit, Leistung und vieles mehr konfrontiert sind. Der Blog behandelt auch neue Technologie-Trends, Führungsprinzipien und Team-Zusammenarbeit, um Weisheiten für die Verbesserung von Technologieunternehmen zu teilen.

Notizfaden

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.
CdXz5zHNQW_D4i1N1yN56.jpeg
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.
CdXz5zHNQW_xJf1iLzWz1.jpeg
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.
CdXz5zHNQW_Ry0cTKX3TG.jpeg
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.
CdXz5zHNQW_YzRZpul0zT.jpeg
CdXz5zHNQW_RVap6w2FjE.jpeg
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.
CdXz5zHNQW_deZowKwyHD.jpeg
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.
CdXz5zHNQW_5ISBolXzut.jpeg
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.
CdXz5zHNQW_IYTQREK32w.jpeg
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.
CdXz5zHNQW_MMZuwGyO3E.jpeg
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.
CdXz5zHNQW_ZoLewXZBkI.jpeg
CdXz5zHNQW_HzB4Yizqpc.jpeg
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 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.