Jak na velké množství dat? Batch inicializace a rekonciliace nemusí být nejvhodnější

Batch inicializace a rekonciliace nemusí být pro vaše potřeby nejvhodnější. Nejčastější způsob, jak se inicializují a opravují data nad streamingem, je existence paralelního batchového přenosu.

Tento způsob však skýtá řadu nevýhod:

• Cílová aplikace si musí postavit další parser na transformaci dat do své cache/databáze.
• Není to vhodné pro použití v reálném čase během provozu.
• Přenos dat může probíhat ručně či jinou otevřenou cestou, kde hrozí riziko kompromitace dat
• Je to náročné na testování a udržování

Zkuste to jinak – k inicializaci a rekonciliaci použijte právě streaming

Streaming, neboli průběžný tok dat v reálném čase, vám místo výše uvedeného přístupu přináší několik výhod.

• Jeden datový formát s průběžným streamem událostí.
• Bezpečnost přenosu bude stejná jako v průběžném topicu.
• Standardizaci procesu inicializace, schopnost jeho trackingu a monitoringu.
• Schopnost dělat dílčí rekonciliace v reálném čase.

Jen je k tomu potřeba pamatovat na několik věcí:

1. Vůle – tuto aktivitu neudělá jeden člověk, je třeba sáhnout do metodiky a tu dodržovat
2. Podpora tohoto paternu napříč celou firmou – toto řešení se musí nějak řídit a vyvíjet, a to stojí peníze navíc.
3. Naučit se přenášet dávky přes Kafku – klienti musí vědět, kde je začátek a konec (data by měla chodit v jiném než průběžném topicu).
4. Je třeba zajistit, aby inicializační data nečetli zbytečně ti, co o ně nestojí.

‍

Ukázka, jak vypadá streaming v praxi.

‍

Spuštění procesu inicializace by mělo podléhat schválení release managementu. Takto postavené řešení vám dává možnosti například pro automatické opravy. Stačí jen povolit proceduru, která spouští inicializaci jen na omezené množství dat nebo konkrétní entity zvenčí – například přes REST API – a otevřou se vám nové možnosti, jak data spravovat a občerstvovat.

Obecně inicializaci streamingu vnímáme jako hodně řešené téma ve firmách, avšak často ne úplně správně. Klienti se uchylují k nekoncepčním řešením, která jim přidělávají problémy v budoucnu nebo neumožňují využít potenciál streamingu naplno.

‍

‍

‍

Jak to může vypadat v praxi

• Příklad 1
  Klient si stěžuje, že aktualizace jeho údajů byla potvrzená, ale pořád ji nevidí. Aplikace si tedy může zkusit znovu načíst data z BE o tomto klientovi a aktualizovat si tak cache.
  ‍
• Příklad 2
  Máme při vybírání dat z Kafky nastavený filtr na relevantní data. Ale stane se nám, že entita, kterou jsme považovali za irelevantní, se stala relevantní, přičemž my o ní potřebujeme získat data (jelikož na této entitě neproběhla změna).

‍

Řešíte velké množství dat i ve své firmě? 

Pokud právě řešíte takovýto typ problému, z našich zkušeností je lepší tuto oblast přenechat profesionálům. Rádi vám proto pomůžeme a celý proces nastavíme správně. Neváhejte se na nás obrátit.

‍

Autoři

‍

‍

Tomáš Huml
Partner

‍

‍

‍

Michal Vlach
Architekt