Beslutning

Det er besluttet at følge en event-baseret overordnet arkitektur, hvilket i nedenstående analyse svarer til den allernederste beskrevne løsning (mulighed 2 med implementering forberedt på mulighed 3 (streaming)).

Det er af erfaring klart at mulighed 1, med den enkelte store transaktion, ikke skalerer så godt som man kunne ønske, samt at det er uhensigtsmæssigt at en hel indlæsning herved skal vente på enkelte fejlende transaktioner. På den anden side er det umiddelbart et for stort hop/risici/opgave at gå direkte til en streaming baseret-arkitektur (som mulighed 3), hvilket heller ikke forventes at være nødvendigt for de fleste stamdataindlæsere, i hvert fald indtil videre. At der følges et event-baseret arkitektur vil gøre det nemmere på sigt at skifte til streaming, skulle dette blive fundet fordelagtigt, og der vil blive gjort en indsats for at indlæserene designes sådan at producer og consumer delene nemt kan skilles ad på sigt.

Analyse

For de nye stamdataindlæseres overordnede arkitektur er der identificeret tre mulige arkitekturer, med hver deres fordele og ulemper.

Mulighed 1 - "enkelt stor transaktion"

Den første mulighed er at benytte den samme arkitektur som de eksisterende indlæsere benytter sig af, hvilket er illustreret på nedenstående archimate diagram:

Archimate diagram - mulighed 1

Mulighed 1 "enkelt stor transaktion - Archimate diagram


Denne arkitektur er karakteriseret ved, at en enkelt komponent står for både parsningen af kildedata og indlæsning i databasen. Yderligere håndteres det indlæste data i en stor transaktion, hvilket gør at hele indlæsningen enten fejler og intet indlæses, eller går godt og det er vidst at alt er indlæst.

Fordele

Ulemper

  • Kun fuldstændige indlæsninger kommer igennem
  • En stor transaktion kan være hårdt for en relationel database, og det kan gå ud over performance ved større dataindlæsninger. Yderligere da relationelle databaser er optimeret til commits, vil eventuelle fejl og derved tilbagerulninger være meget store og ikke til at afbryde.

  • At indlæsninger foregår i en stor transaktion, vil det derfor også være svært at parallelisere indlæsningen.

  • Det har i det nuværende setup været nødvendigt at tilføje en fuldstændig indlæsning til en ikke-prod database (preflight), for at 'afprøve' indlæsningen før det gøres rigtigt. 

  • Hvis en enkelt hændelse ud af en hel indlæsning fejler, betyder det at alle de (ellers valide) hændelser i indlæsningen ikke vil blive indlæst, før den fejlende bliver rettet.



Arkitektur mulighed 1

Mulighed 1 "enkelt stor transaktion" - arkitektur sketch

Mulighed 2 - "event-baserede transaktioner"

Det logiske trin videre fra de store transaktioner er at dele en indlæsning op i events og indlæse dem i databasen for sig. 

Mulighed 2 "event-baserede transaktioner" - Archimate diagram

Denne arkitektur er karakteriseret ved, at når en fil er parset, deles den op i events, som hver repræsenterer et forretningselement for den kilde der indlæses (en person, yder, organisatorisk enhed osv). Disse events kan derfra indlæses i hver deres transaktion, og fejlende indlæste events kan håndteres separat fra dem, der går godt.

Fordele

Ulemper

  • Mindre transaktioner

  • En fejlende transaktion lader ikke de 'sunde' events vente

  • Gør det nemmere at parallelisere indlæsningen
  • Kræver mere modellering af events end den store transaktion.

  • Rækkefølgen af events kan have betydning.


Mulighed 2 "event-baserede transaktioner" - sketch diagram


Mulighed 3 - "streaming baseret"

Den tredje mulighed er at gå endnu videre med events og loade dem i en streaming platform og derved udnytte fleksibiliteten af streaming.

Mulighed 3 - "streaming baseret" - archimate diagram

For streaming arkitekturen bliver indlæsningen også delt op i events, ligesom i den event baserede arkitektur. Indlæsningskomponenten deles op i to komponenter; en producer som parser filen og danner events som publiseres til en streaming-kø (her vist som Kafka). For at understøtte den nuværende replikeringsmetode med database-replikering, dannes også en Consumer som tager denne stream af events, og indlæser dem i databasen.

Fordele

Ulemper

  • Mindre transaktioner

  • En fejlende transaktion lader ikke de 'sunde' vente

  • Endnu nemmere at parallelisere indlæsningen. Faktisk kan Consumere naturligt duplikeres og herved parallelisere indlæsningen, da dette er et indbygget feature ved en streaming arkitektur i Kafka

  • Mere fleksibelt end de to tidligere. Ved at indlæse data som en stream i Kafka kan det give fordele som:
    • Andre aftagersystemer kan aftage direkte fra streamen frem for at skulle 'vente' på databasen.
    • Man kan nemmere tilføje producere af samme forretningsdata, hvis visse kilder i fremtiden skulle understøtte hændelsesbaserede integrationer.
    • Streaming understøtter dataintegrationer, der er yderst skalerbare og som kan give dataopdateringer i nær-realtid. Producere kan opdateres til dette som integrationerne tillader hyppigere opdateringer, uden at Consumere behøves ændret.
  • Kræver to deployable units, frem for bare en

  • Kræver viden/indblanding af Kafka (eller eventuel anden streaming kø)


Mulighed 3 - "streaming baseret" - sketch diagram


Mulighed 2 med implementering forberedt på mulighed 3 (streaming)

Den streaming-baserede arktitektur, har fordele på sigt - men det er ikke sikkert at behovet er så presserende lige pt.  Derfor kan der beskrives en variant af Mulighed 2, som har sin stamdatakomponent designet ved en producer og consumer med events imellem sig på en måde, der vil gøre en eventuel senere transition til den streaming-baserede arkitektur (mulighed 3) nemmere:

Mulighed 2 med implementering forberedt på mulighed 3 (streaming) - archimate diagram

Denne arkitektur benytter ikke streaming, men organiserer stamdataindlæser deployment-componenten i producer, events/streaming og consumer, således at transitionen til den streaming-baserede arkitektur minimeres. Man kan overveje at definere tydelige skemaer af event-typer, for yderligere at fastholde denne struktur. Det bemærkes, at integrationsframeworket Camel har en grundlæggende opbygning som passer godt ind i dette design.

Denne variant vil give de samme arkitekturelle fordeler og ulemper som mulighed 2, men med en nemmere overgang til den streamede arkitektur (mulighed 3).



Mulighed 2 med implementering forberedt på mulighed 3 (streaming) - sketch diagram


  • No labels