Meta introducerar 'Tulip', ett binärt serialiseringsprotokoll som hjälper till med dataschematisering genom att adressera protokolltillförlitlighet för AI- och maskininlärningsarbetsbelastningar

Meta introducerar "Tulip", ett binärt serialiseringsprotokoll som stödjer schemautveckling. Detta hanterar samtidigt protokolltillförlitlighet och andra problem och hjälper oss med dataschematisering. Tulip har flera äldre format. Därför används den i Metas dataplattform och har sett en avsevärd ökning i prestanda och effektivitet. Metas dataplattform består av ett flertal heterogena tjänster, såsom lagerdatalagring och olika realtidssystem som utbyter stora mängder data och kommunicerar sinsemellan via tjänstens API:er. I takt med att antalet AI- och maskininlärnings-ML-relaterade arbetsbelastningar i Metas system ökar som använder data för att träna dessa ML-modeller, är det nödvändigt att kontinuerligt arbeta med att göra våra dataloggningssystem effektiva. Schematiseringen av data spelar en enorm roll för att skapa en plattform för data i Metas skala. Dessa system är designade baserat på kunskapen om att varje beslut och avvägning påverkar tillförlitlighet, dataförbehandlingseffektivitet, prestanda och ingenjörens utvecklarupplevelse. Att ändra serialiseringsformat för datainfrastrukturen är en stor satsning men erbjuder fördelar i det långa loppet som gör att plattformen utvecklas över tiden.

Data Analytics Logging Library finns i webbnivån och de interna tjänsterna, och detta ansvarar också för att logga analytisk och operationell data med Scribe - ett hållbart meddelandekösystem som används av Meta. Data läses och matas in från Scribe, som även inkluderar en dataplattformsinmatningstjänst och realtidsbearbetningssystem. Läsbiblioteket för dataanalys hjälper till att deserialisera data och återfukta den till en strukturerad nyttolast. Loggningsscheman skapas, uppdateras och raderas varje månad av tusentals ingenjörer på Meta, och dessa loggningsschemadata flödar i petabyteintervall varje dag över Scribe. 

Schematisering är nödvändig för att säkerställa att alla meddelanden som loggats i det förflutna, nuet eller framtiden, beroende på (av) serializerns version, kan (av)serialiseras på ett tillförlitligt sätt när som helst med största trohet och ingen dataförlust. Säker schemautveckling via bakåt- och framåtkompatibilitet är namnet på denna egenskap. Artikelns huvudfokus ligger på det on-wire serialiseringsformat som används för att koda data som slutligen bearbetas av dataplattformen. Jämfört med de två serialiseringsformaten som tidigare använts, Hive Text Delimited och JSON-serialisering, är det nya kodningsformatet mer effektivt och kräver 40 till 85 procent färre byte och 50 till 90 procent färre CPU-cykler för att (av)serialisera data.

Loggningsbibliotekets applikationer är skrivna på olika språk som C++, Java, Haskell, Hack och Python för att serialisera nyttolasten enligt loggningsschema, och dessa loggningsscheman definieras enligt affärsbehov och skrivs till Scribe för enklare leverans . Loggningsbiblioteket finns i två varianter nämligen Code Generated och Generic. I Code Generated flavor för typsäker användning genereras statiskt typade sättare för varje fält. För optimal effektivitet genereras även efterbearbetnings- och serialiseringskod. Medan i generisk smak för att utföra (av)serialisering av dynamiskt typade nyttolaster, erbjuds ett C++-bibliotek med namnet Tulib. Ett meddelande som använder dynamisk typning serialiseras i enlighet med ett loggningsschema. Eftersom den tillåter (av)serialisering av meddelanden utan att kräva ombyggnad och omdistribuering av applikationsbinären, är denna metod mer flexibel än det kodgenererade läget.

Loggningsbiblioteket skickar data till flera back-end-system, som vart och ett traditionellt har specificerat sina egna serialiseringsregler och olika problem uppstår när man använder dessa format för att serialisera nyttolaster, och de är

• Standardisering: Det fanns ingen standardisering av serialiseringsformat tidigare; varje nedströmssystem hade sitt eget format vilket ledde till ökade underhålls- och utvecklingskostnader. 
• Pålitlighet: Nya kolumner kan bara läggas till i slutet för att bibehålla avserialiseringens tillförlitlighet. Varje försök att infoga ett fält i mitten av en befintlig kolumn eller ta bort en kolumn skulle få alla följande kolumner att flyttas, vilket gör det omöjligt att deserialisera raden, och det uppdaterade schemat distribueras till läsarna i realtid. 
• Effektivitet: Jämfört med binär (av)serialisering är både Hive Text Delimited och JSON-protokollen textbaserade och ineffektiva.
• Korrekthet: Fältavgränsare och radavgränsare måste escaped och unescaped för textbaserade protokoll som Hive Text. Varje författare och läsare gör detta, vilket ökar trycket på biblioteksförfattarna. Att hantera föråldrade eller felaktiga implementeringar som bara letar efter närvaron av dessa karaktärer och avvisar hela meddelandet snarare än att fly de besvärliga karaktärerna är svårt.
• Framåt- och bakåtkompatibilitet: Konsumerande nyttolaster som serialiserades av ett serialiseringsschema både före och efter den version som konsumenten ser är önskvärt. Hive Text Protocol ger inte denna garanti.
• metadata: Metadatainfogningen i nyttolasten stöds inte trivialt av Hive Text Serialization. För att nedströmssystem ska kunna implementera funktioner som drar nytta av närvaron av metadata, är spridning av dessa data väsentligt.

Tulip löser vårt grundläggande problem, tillförlitlighetsfrågan, genom att tillhandahålla ett säkert schemautvecklingsformat som är både bakåt- och framåtkompatibelt över tjänster med distinkta distributionscykler. Tulip löste alla dessa problem på en gång, vilket gjorde det till en bättre investering än andra tillgängliga alternativ. 

TCompactProtocol från Thrift används för att serialisera en nyttolast i Tulips serialiseringsprotokoll, som är ett binärt serialiseringsprotokoll. Fälten är numrerade med ID på samma sätt som en ingenjör skulle förväntas göra när man ändrar ID:n i en Thrift-struktur. Ingenjörer definierar en lista med fältnamn och typer när de skapar ett loggningsschema, och fält-ID:n hanteras av dataplattformshanteringsmodulen snarare än de angivna ingenjörerna. Serialiseringsschemalagret innehåller en översättning av loggningsschemat till ett serialiseringsschema. Listor över fältnamn, fälttyp, fält-ID för ett relaterat loggningsschema och fälthistorik lagras i en serialiseringskonfiguration. När en ingenjör vill uppdatera ett loggningsschema, utförs en transaktionsoperation på serialiseringsschemat.

Referens: https://engineering.fb.com/2022/11/09/developer-tools/tulip-schematizing-metas-data-platform/

Glöm inte att gå med Vår ML Subreddit

Avanthy Yeluri är en Dual Degree student vid IIT Kharagpur. Hon har ett starkt intresse för datavetenskap på grund av dess många tillämpningar inom en mängd olika branscher, såväl som dess banbrytande tekniska framsteg och hur de används i det dagliga livet.

<!–

->