--- title: "Apache Avro: kontrakten mellom moduler" url: "https://hurukan.com/no/blog/apache-avro-kontrakten-mellom-moduler" description: "Hver hendelse mellom moduler er en kontrakt. Avro skriver den inn i dataene, og en skjemaendring blir et forslag en person godkjenner." --- # Apache Avro: kontrakten mellom moduler 2\. september 2026·4 min lesing·Redaksjonen To ingeniører sett bakfra ved et felles bord på et stille kontor, en stor veggskjerm mellom dem som viser et abstrakt blågrått diagram av et skjema og versjonene dets, et utskrevet ark under den enes hånd, ett blått statuslys på skjermrammen Salgsteamet legger til en rabattprosent på ordren. Det er en liten endring, avtalt i et møte, og modulen som oppretter ordrer, begynner å sende den samme ettermiddag. Økonomimodulen, som har lest ordrer i to år, kjenner ikke feltet og slutter å godta meldingen. Ingen mente å endre en kontrakt. Det fantes en kontrakt, den var bare aldri skrevet ned noe annet sted enn i to kodebiter som pleide å være enige. I et system bygd av moduler som utveksler hendelser, er hver hendelse en avtale. Apache Avro er ett av formatene som skriver den avtalen inn i selve dataene, og grunnen til at det sitter i designet av Hurukans [datalag](https://hurukan.com/no/system/data), som er under bygging, handler mindre om byte enn om hva som skjer når avtalen må endres. ## Skjemaet reiser med dataene En Avro-post er en kompakt binær rad. Alene kan den ikke leses: feltnavnene, typene og rekkefølgen er ikke i bytene. De er i skjemaet, skrevet i JSON, og [spesifikasjonen](https://avro.apache.org/docs/1.12.0/specification/) definerer et lite sett typer å skrive det med: null, boolean, int, long, float, double, bytes, string, og de sammensatte record, enum, array, map, union og fixed. Et felt kan bære en standardverdi, og den standardverdien er det som senere gjør endring overlevbar. Gjeldende utgivelse er 1.12.2 ([prosjektbloggen](https://avro.apache.org/blog/), kontrollert 21. oktober 2026). Skjemaet når leseren på én av to måter. I en fil legger Object Container File-formatet skjemaet i hodet, etterfulgt av blokker med poster atskilt av et synkroniseringsmerke, slik at en fil som finnes år senere, fortsatt forklarer seg selv. På en meldingsbuss, der det ville vært sløsing å sende skjemaet med hver hendelse, legger spesifikasjonens enkeltobjektkoding (single-object encoding) et tobyte-merke og et åttebyte-fingeravtrykk av skjemaet foran hver post; et register oppbevarer skjemaet under det fingeravtrykket. Det mye brukte Confluent-registeret gjør det samme med sin egen innramming, en magisk byte og en firebyte-skjemaidentifikator foran Avro-bytene ([Confluent-dokumentasjonen](https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html)). Uansett gjetter leseren aldri. Den har skriverens skjema og sitt eget, og resten er regler. ## Oppløsning: hvordan en leser møter en skriver den aldri har sett Spesifikasjonen fastsetter hva som skjer når skriverens skjema og leserens skjema er ulike. Felt matches etter navn. Et felt skriveren sendte og leseren ikke har, ignoreres. Et felt leseren forventer og skriveren ikke sendte, fylles fra leserens standardverdi, og finnes det ingen standardverdi, feiler lesingen med en tydelig grunn. Noen typer kan forfremmes på veien: en int kan leses som en long, en long som en float eller double, en float som en double, og string og bytes kan leses som hverandre. En union matches mot den første kompatible grenen på leserens side. Skrevet ut er de reglene hele disiplinen rundt rabattfeltet. Legg det til med en standardverdi, og økonomimodulen fortsetter å lese og ignorerer feltet til den læres opp til å bruke det. Legg det til uten standardverdi og fjern et gammelt felt i samme endring, og den eldste leseren i virksomheten stanser. Reglene er ikke råd; de avgjør hvilken versjon av morgenen du får. ## En skjemaendring som et forslag I Hurukan er designet at et hendelsesskjema er et objekt i ontologien som ethvert annet: det har en eier, versjoner og en plass i registeret. Det gjør rabattfeltet fra en ettermiddags kodeendring til en kort, registrert vei. **En agent foreslår.** Salgsmodulen trenger et nytt felt; en agent utarbeider skjemaendringen, med standardverdien, typen og grunnen, og navngir modulene som leser denne hendelsen. **Registeret sjekker.** Den foreslåtte versjonen testes mot lesernes skjemaer etter oppløsningsreglene over. En endring som ville stanset en eksisterende leser, avvises før noen ser den, med leseren navngitt. **Eieren godkjenner.** En kompatibel endring er fortsatt en endring i en avtale mellom moduler. Eieren av hendelsen, en person, godkjenner den, og først da begynner produsentene å skrive den nye versjonen. **Registeret beholder den.** Godkjenningen, versjonen og tidspunktet skrives inn i registeret, så spørsmålet «når dukket rabatter opp på ordrer, og hvem tillot det» har et svar et år senere. Det er samme vei hver endring i systemet tar: en agent foreslår, en person beslutter, systemet registrerer. Den bredere ideen finnes i [nåtilstand og register](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner). ## Hva Avro ikke er til Avro bærer hendelser godt og leser hele poster godt. Det er et dårlig oppsett for spørsmålet superintelligens oftest stiller, noen få felt på tvers av en million rader, fordi hvert felt er i veien for alle de andre. Derfor samles hendelser i Avro, i designet, i kolonner i partier når de er akseptert. Hvilken form som hører hjemme hvor, er satt opp i [Parquet og Avro: hendelsen og registeret](https://hurukan.com/no/blog/parquet-og-avro-hendelsen-og-registeret). Avro dukker også opp på et sted få ser: tabellformatet Apache Iceberg skriver manifestene sine, listene over datafiler som utgjør en tabell, som Avro-filer ([Iceberg-spesifikasjonen](https://iceberg.apache.org/spec/)). Radformatet som bærer hendelser mellom moduler, bærer også regnskapet i registeret. ## Hva som blir hos mennesker En agent kan utarbeide et skjema, kjøre kompatibilitetssjekken og navngi leserne. Den kan ikke avgjøre at et felt økonomimodulen stolte på, kan fjernes, at en standardverdi på null er en sann påstand om gamle ordrer, eller at en leser kan få lov til å feile. Det er beslutninger om virksomhetens mening, og i Hurukan tas de av eieren av hendelsen og skrives ned. ## En test du kan gjøre i dag Velg én melding som flyttes mellom to av systemene dine. Finn ut hvor feltene dens er definert. Hvis svaret er «i avsenderkoden» og «i mottakerkoden», har du to definisjoner og ingen kontrakt. Spør deretter hvem som ville godkjent å legge til et felt i den, ved navn. Hvis det ikke finnes et navn, vil det neste feltet bli lagt til av den som trenger det først, og oppdaget av den det ødelegger for. Siden om [datalaget](https://hurukan.com/no/system/data) beskriver hvor den kontrakten er ment å bo i Hurukan; [oversikten](https://hurukan.com/no) viser modulene rundt. - Apache Avro - skjemaregister - hendelseskontrakter - skjemaevolusjon - datalag ## Les videre - [Én identitet for mennesker og agenter: hvem får gjøre hva](https://hurukan.com/no/blog/en-identitet-for-mennesker-og-agenter) - [Nåtilstand og register: to minner i et operativsystem for virksomheten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner)