Småsnak om Apache Hudi

Om Hudi

Apache Hudi er en datasøplatform, der kombinerer funktionerne i en database og et datalager i datasøen. Det muliggør realtidsanalyse af streamingdata med minimal latenstid, hvilket giver mulighed for analyse på minutniveau. Hudi introducerer en ny ramme for trinvis behandling, der erstatter den langsomme batchdatabehandling, der almindeligvis anvendes. Med Hudi kan brugerne drage fordel af funktioner som tabeller, transaktioner, effektive upserts og deletes, avanceret indeksering, streamingtjenester til dataindtagelse, dataklynger, komprimeringsoptimeringer og samtidighedskontrol. Det, der adskiller Hudi, er dens evne til at vedligeholde data i open source-filformater, hvilket gør den kompatibel med forskellige forespørgselsmotorer som Apache Spark, Flink, Presto, Hive og mere. Den er ideel til streaming af arbejdsbelastninger og understøtter også oprettelsen af effektive trinvise batchpipelines, hvilket sikrer analyser med høj ydeevne.

Sådan fungerer Hudi-opdateringen

Hudi arbejder ud fra indeksering. Det opretter et indeks baseret på primær nøgle. Hvis der kommer opdateringer til den primære nøgle, søger den efter den fil, der indeholder posten for denne nøgle, og opretter en ny version af filen med opdaterede poster.

Skriveoperationer

Før det kan det være nyttigt at forstå de 3 forskellige skriveoperationer, der leveres af Hudi datasource eller delta streamer-værktøjet, og hvordan man bedst udnytter dem. Disse handlinger kan vælges/ændres på tværs af hver commit/deltacommit, der udstedes i forhold til tabellen.

Egenskaber, der kræves til indsatser.

• OPERATION_VÆLGE_NØGLE('hættetrøje.datasource.write.operation') : Henviser til den type operation, der udføres med Hudi - UPSERT_OPERATION_VÆLGE_VAL (standard)BULK_INDSÆTTE_OPERATION_VÆLGE_VAL, INSERT_OPERATION_VÆLGE_VAL, SLET_OPERATION_VÆLGE_VAL
• PARTITIONPATH_FIELD.key() ('hoodie.datasource.write.partitionpath.field') : Refererer til partitionsstien, hvor posten tilhører.
• FORKOMBINERE_FIELD.key() ('hættetrøje.datasource.write.precombine.field') : Felt, der bruges til at fjerne duplicering af flere poster i den batch af poster, der indtages.
• OPTAGET_MARK_VÆLGE_NØGLE (Kræves): Primær nøgle felt(s). Postnøgler identificerer entydigt en post/række inden for hver partition.
• hoodie.insert.shuffle.parallelism : Refererer til gnistparallelitet, der skal bruges under indtagelse af poster til hudi
• hoodie.datasource.write.table.type : Refererer til tabeltypen for hudi-tabellen. Der er to tabeltyper i Hudi, nemlig COPY_PÅ_SKRIVE(standard) og FLET_PÅ_LÆSE.
• BORD_NAVN ('hoodie.table.name') : Henviser til hudi-tabelnavn.

KO vs MOR

Kopier på skrivebord

Filudsnit i tabellen Copy-On-Write indeholder kun basis-/kolonnefilen, og hver commit producerer nye versioner af basisfiler. Med andre ord komprimerer vi implicit på hver commit, så der kun findes kolonnedata. Som følge heraf skriveforstærkningen (antal bytes skrevet for 1 byte indgående data) er meget højere, hvor læseforstærkningen er nul. Dette er en meget ønsket egenskab for analytiske arbejdsbelastninger, som overvejende er læsetunge.

Følgende illustrerer, hvordan dette fungerer konceptuelt, når data skrives ind i kopi-på-skrive-tabel og to forespørgsler, der kører oven på den.

Efterhånden som data skrives, producerer opdateringer til eksisterende filgrupper et nyt udsnit for den pågældende filgruppe, der er stemplet med det øjeblikkelige tidspunkt for bekræftelsen, mens indsættelser tildeler en ny filgruppe og skriver det første udsnit for den pågældende filgruppe. Disse filudsnit og deres commit-øjeblikkelige tider er farvekodet ovenfor. SQL-forespørgsler, der kører mod en sådan tabel (F.eks.: Vælg antal(*) Tælling af det samlede antal poster i den pågældende partition)kontrollerer først tidslinjen for den seneste bekræftelse og filtrerer alle undtagen de nyeste filudsnit i hver filgruppe. Som du kan se, kan en gammel forespørgsel ikke se den aktuelle inflight-commit-filer farvekodet i pink, men en ny forespørgsel, der starter, efter at commit'en henter de nye data. Forespørgsler er derfor immune over for eventuelle skrivefejl/delvise skrivninger og kører kun på forpligtede data.

Hensigten med kopi på skrivetabel er fundamentalt at forbedre, hvordan tabeller administreres i dag gennem

• Førsteklasses understøttelse af atomisk opdatering af data på filniveau i stedet for at omskrive hele tabeller/partitioner
• Mulighed for trinvise forbrugsændringer i modsætning til spildte scanninger eller fumlen med heuristik
• Stram kontrol af filstørrelser for at holde forespørgselsydelsen fremragende (Små filer skader forespørgslens ydeevne betydeligt).

Flet på læsebord

Flet på læsetabel er et supersæt af kopi ved skrivning, i den forstand at det stadig understøtter læseoptimerede forespørgsler i tabellen ved kun at eksponere basis-/kolonnefilerne i de nyeste filudsnit. Derudover gemmer den indgående upserts for hver filgruppe i en rækkebaseret delta-log for at understøtte snapshotforespørgsler ved at anvende deltaloggen på den nyeste version af hvert fil-id på farten i løbet af forespørgselstiden. Denne tabeltype forsøger således at balancere læse- og skriveforstærkning intelligent for at give data i næsten realtid. Den mest betydningsfulde ændring her ville være komprimeringsmaskinen, som nu omhyggeligt vælger, hvilke deltalogfiler der skal komprimeres på deres kolonnebaserede basisfil, for at holde forespørgselsydeevnen i skak (Større deltalogfiler ville medføre længere flettetider med flettedata på forespørgselssiden)

Følgende illustrerer, hvordan tabellen fungerer, og viser to typer forespørgsler – snapshotforespørgsel og læseoptimeret forespørgsel.

Der sker mange interessante ting i dette eksempel, som fremhæver finesserne i tilgangen.

• Vi har nu commits hvert 1. minut eller deromkring, noget vi ikke kunne gøre i den anden tabeltype.
• Inden for hver fil-id-gruppe er der nu en delta-logfil, som indeholder indgående opdateringer til de poster, der allerede findes i basiskolonnefilerne. I eksemplet indeholder deltalogfilerne alle data fra 10:05 til 10:10. De grundlæggende kolonnefiler er stadig versioneret med commit, som før. Så hvis man blot skulle se på basisfiler alene, så ser tabellayoutet nøjagtigt ud som en kopi på skrivetabellen.
• En periodisk komprimeringsproces afstemmer disse ændringer fra deltaloggen og producerer en ny version af basisfilen, ligesom det skete kl. 10:05 i eksemplet.
• Der er to måder at forespørge på den samme underliggende tabel på: Læseoptimeret forespørgsel og Snapshot-forespørgsel, afhængigt af om vi vælger forespørgselsydeevne eller dataaktualitet.
• Semantikken omkring, hvornår data fra en bekræftelse er tilgængelige for en forespørgsel, ændres på en subtil måde for en læseoptimeret forespørgsel. Bemærk, at en sådan forespørgsel, der kører kl. 10:10, ikke kan se data efter kl. 10:05 ovenfor, mens en snapshotforespørgsel altid ser de nyeste data.
• Når vi udløser komprimering og hvad den beslutter sig for at komprimere, har hele nøglen til at løse disse svære problemer. Ved at implementere en komprimeringsstrategi, hvor vi aggressivt komprimerer de nyeste partitioner sammenlignet med ældre partitioner, kan vi sikre, at de læseoptimerede forespørgsler ser data offentliggjort inden for X minutter på en ensartet måde.

Hensigten med merge on read table er at muliggøre næsten realtidsbehandling direkte oven på DFS, i modsætning til at kopiere data ud til specialiserede systemer, som muligvis ikke er i stand til at håndtere datamængden. Der er også et par sekundære sidefordele ved denne tabel, såsom reduceret skriveforstærkning ved at undgå synkron fletning af data, dvs. mængden af data, der skrives pr. 1 bytes data i en batch

Ulemper

• For at bruge HUDI upsert skal vi kun få opdateret/poster fra kilden.
• HUDI upsert er muligvis ikke nyttigt, hvis næsten alle posterne i tabellen bliver opdateret. Det tilføjer indeksering og søgeomkostninger.
• Vi kan ikke direkte slette en fil eller slippe en partition i HUDI, da HUDI vedligeholder alle filnavne og registreringsnøgler i sin metadatafil. Skal udføre disse handlinger gennem HUDI sletning.
• Tidsstempelkolonnen er ikke tilgængelig fra beeline. (Den kan tilgås via Spark )
• Filstørrelsen er mere sammenlignet med ORC. (De kan også skyldes metadata. Vi kan se, om vi kan reducere filstørrelsen ved komprimering)