Tulip: Esquematització de la plataforma de dades de Meta

  • Compartim Tulip, un protocol de serialització binari que admet l’evolució d’esquemes.
  • Tulip ajuda amb l’esquematització de dades abordant la fiabilitat del protocol i altres problemes simultàniament.
  • Substitueix diversos formats heretats utilitzats a la plataforma de dades de Meta i ha aconseguit guanys significatius de rendiment i eficiència.

Hi ha nombrosos serveis heterogenis, com ara l’emmagatzematge de dades de magatzem i diversos sistemes en temps real, que conformen la plataforma de dades de Meta, tots intercanviant grans quantitats de dades entre ells mentre es comuniquen mitjançant API de servei. A mesura que continuem augmentant el nombre de càrregues de treball relacionades amb la IA i l’aprenentatge automàtic (ML) als nostres sistemes que aprofiten les dades per a tasques com ara la formació de models d’ML, treballem contínuament per fer que els nostres sistemes de registre de dades siguin més eficients.

L’esquematització de dades té un paper important en una plataforma de dades a l’escala de Meta. Aquests sistemes estan dissenyats amb el coneixement que cada decisió i compensació poden afectar la fiabilitat, el rendiment i l’eficiència del processament de dades, així com l’experiència dels desenvolupadors dels nostres enginyers.

Fer apostes enormes, com canviar els formats de serialització per a tota la infraestructura de dades, és un repte a curt termini, però ofereix majors avantatges a llarg termini que ajuden la plataforma a evolucionar amb el temps.

El repte d’una plataforma de dades a escala exabyte

biblioteca de registre d’anàlisi de dades està present al nivell web així com als serveis interns. És responsable de registrar dades analítiques i operatives via Escrivà (El sistema de cua de missatges persistent i durador de Meta). Diversos serveis llegeixen i ingereixen dades de Scribe, inclosa (però no limitada a) la plataforma de dades Ingestion Service i sistemes de processament en temps real, com ara Puma, Stylusi XStream. Té biblioteca de lectura d’anàlisi de dades En conseqüència, ajuda a deserialitzar les dades i rehidratar-les en una càrrega útil estructurada. Tot i que aquest article es centrarà només en la biblioteca de registre, la narració s’aplica a totes dues.

Figura 1: Diagrama del sistema d’alt nivell per al flux de dades de registre d’anàlisi a Meta.

A l’escala en què opera la plataforma de dades de Meta, milers d’enginyers creen, actualitzen i suprimeixen esquemes de registre cada mes. Aquests esquemes de registre veuen petabytes de dades que hi flueixen cada dia a través de Scribe.

Esquematització és important assegurar-se que qualsevol missatge registrat en el present, passat o futur, en relació amb la versió de (des)serialitzador, es pugui (des)serialitzar de manera fiable en qualsevol moment amb la màxima fidelitat i sense pèrdua de dades. Aquesta propietat s’anomena evolució segura d’esquemes mitjançant compatibilitat cap endavant i cap enrere.

Aquest article se centrarà en el format de serialització per cable triat per codificar les dades que finalment són processades per la plataforma de dades. Motivem l’evolució d’aquest disseny, els compromisos considerats i les millores que se’n deriven. Des del punt de vista de l’eficiència, el nou format de codificació necessita entre Del 40% al 85% menys de bytesi usos Entre un 50% i un 90% menys de cicles de CPU per (des)serialitzar les dades en comparació amb els formats de serialització utilitzats anteriorment, és a dir Hive Text delimitat i JSON serialització.

Com hem desenvolupat Tulip

Una visió general de la biblioteca de registre d’anàlisi de dades

La biblioteca de registre la fan servir aplicacions escrites en diversos idiomes (com ara Hack, C++, Java, Python i Haskell) per serialitzar una càrrega útil segons un esquema de registre. Els enginyers defineixen esquemes de registre d’acord amb les necessitats empresarials. Aquestes càrregues útils serialitzades s’escriuen a Scribe per a un lliurament durador.

La pròpia biblioteca de registre es presenta en dos tipus:

  1. Codi generat: En aquest gust, es generen configuradors de tipus estàticament per a cada camp per a un ús segur de tipus. A més, el codi de postprocessament i serialització també es genera amb codi (si escau) per obtenir la màxima eficiència. Per exemple, el serialitzador d’estalvi de Hack utilitza a Accelerador de C++on la generació de codi s’utilitza parcialment.
  2. Genèric: Es proporciona una biblioteca C++ anomenada Tulib (que no s’ha de confondre amb Tulip) per dur a terme la (des)serialització de càrregues útils escrites dinàmicament. En aquest gust, un missatge escrit dinàmicament es serialitza segons un esquema de registre. Aquest mode és més versàtil que el mode generat per codi perquè permet la (des)serialització de missatges sense reconstruir i tornar a desplegar el binari de l’aplicació.

Format de serialització heretat

La biblioteca de registre escriu dades a diversos sistemes de fons que històricament han dictat els seus propis mecanismes de serialització. Per exemple, els usos d’ingestió de magatzem Delimitadors de text Hive durant la serialització, mentre que altres sistemes utilitzen Serialització JSON. Hi ha molts problemes quan s’utilitza un d’aquests formats o tots dos per a la serialització de càrregues útils.

  1. Normalització: Abans, cada sistema aigües avall tenia el seu propi format, i n’hi havia sense estandardització dels formats de serialització. Això va augmentar els costos de desenvolupament i manteniment.
  2. Fiabilitat: El format Hive Text Delimited és de naturalesa posicional. Per mantenir la fiabilitat de la deserialització, només es poden afegir columnes noves al final. Qualsevol intent d’afegir camps al mig d’una columna o suprimir columnes canviarà totes les columnes després d’ella, cosa que farà que la fila sigui impossible de deserialitzar (ja que una fila no s’autodescribe, a diferència de JSON). Distribuïm l’esquema actualitzat als lectors en temps real.
  3. Eficiència: Tant el protocol Hive Text Delimited com el JSON estan basats en text i són ineficients en comparació amb la (des)serialització binària.
  4. Correcció: Els protocols basats en text, com ara Hive Text, requereixen l’escapament i desescapament dels delimitadors de camp i dels delimitadors de línia dels caràcters de control. Això ho fa cada escriptor/lector i suposa una càrrega addicional per als autors de la biblioteca. És un repte tractar amb implementacions heretades/buggy que només comproven la presència d’aquests caràcters i no permeten tot el missatge en lloc d’escapar dels caràcters problemàtics.
  5. Compatibilitat cap endavant i cap enrere: És desitjable que els consumidors puguin consumir càrregues útils que es van serialitzar mitjançant un esquema de serialització tant abans com després de la versió que veu el consumidor. El protocol de text Hive no ofereix aquesta garantia.
  6. Metadades: Hive Text Serialization no permet de manera trivial afegir metadades a la càrrega útil. Propagació de metadades per als sistemes aigües avall és fonamental per implementar funcions que es beneficiïn de la seva presència. Per exemple, certs fluxos de treball de depuració es beneficien de tenir un nom d’amfitrió o una suma de verificació transferida juntament amb la càrrega útil serialitzada.

El problema fonamental que va resoldre Tulip és el fiabilitat problema, garantint un format d’evolució d’esquemes segur amb compatibilitat cap endavant i cap enrere entre els serveis que tenen els seus propis horaris de desplegament.

Un podria haver-se imaginat resoldre els altres de manera independent perseguint una estratègia diferent, però el fet que Tulip fos capaç de resoldre tots aquests problemes alhora va fer que fos una inversió molt més atractiva que altres opcions.

Serialització de tulipes

El protocol de serialització Tulip és un protocol de serialització binari que utilitza Thrift’s TCompactProtocol per serialitzar una càrrega útil. Segueix les mateixes regles per a la numeració de camps amb identificadors que s’esperaria que utilitzi un enginyer quan actualitzi identificadors en una estructura Thrift.

Quan els enginyers creen un esquema de registre, ho especifiquen una llista de noms i tipus de camps. Els enginyers no especifiquen els ID de campperò en canvi són assignats pel mòdul de gestió de la plataforma de dades.

Figura 2: Flux de creació d’esquemes de registre.

Aquesta figura mostra el flux de treball orientat a l’usuari quan un enginyer crea/actualitza un esquema de registre. Un cop la validació té èxit, els canvis a l’esquema de registre es publiquen a diversos sistemes de la plataforma de dades.

L’esquema de registre es tradueix a un esquema de serialització i s’emmagatzema al fitxer Repositori d’esquemes de serialització. Una configuració de serialització conté llistes de (nom de camp, tipus de camp, identificador de camp) per a un esquema de registre corresponent, així com l’historial de camps. Es realitza una operació transaccional a l’esquema de serialització quan un enginyer vol actualitzar un esquema de registre.

Figura 3: Evolució de l’esquema de serialització de tulipa

L’exemple anterior mostra la creació i actualització d’un esquema de registre i el seu impacte en l’esquema de serialització al llarg del temps.

  1. Addició de camp: Quan s’afegeix un camp nou anomenat “autors” a l’esquema de registre, s’assigna un nou identificador a l’esquema de serialització.
  2. Canvis de tipus de camp: De la mateixa manera, quan el tipus del camp “isbn” es canvia de “i64” a “cadena”, s’associa un nou ID al camp nou, però l’ID del camp “isbn” escrit “i64” original es conserva al esquema de serialització. Quan el magatzem de dades subjacent no permet canvis de tipus de camp, la biblioteca de registre no permet aquest canvi.
  3. Supressió de camps: Els identificadors mai s’eliminen de l’esquema de serialització, cosa que permet una compatibilitat completa amb les càrregues útils ja serialitzades. El camp d’un esquema de serialització d’un esquema de registre és indeleble encara que s’afegeixin/eliminin camps de l’esquema de registre.
  4. Canviar el nom del camp: No hi ha cap concepte de canvi de nom de camp, i aquesta operació es tracta com una supressió de camp seguida d’una addició de camp.

Agraïments

Volem donar les gràcies a tots els membres de l’equip de la plataforma de dades que han ajudat a fer que aquest projecte sigui un èxit. Sense el suport XFN d’aquests equips i enginyers de Meta, aquest projecte no hauria estat possible.

Un agraïment especial a Sriguru Chakravarthi, Sushil Dhaundiyal, Hung Duong, Stefan Filip, Manski Fransazov, Alexander Gugel, Paul Harrington, Manos Karpathiotakis, Thomas Lento, Harani Mukkala, Pramod Nayak, David Pletcher, Lin Qiao, Milos Stojanovic, Ezra Stuetzel. , Huseyin Tan, Bharat Vaidhyanathan, Dino Wernli, Kevin Wilfong, Chong Xie, Jingjing Zhang i Zhenyuan Zhao.

Leave a Comment

Your email address will not be published. Required fields are marked *