Zdroj dat a právo je používat
Architektura začíná otázkou, k čemu budou data sloužit: obrazovka pro člověka, interní výpočet, historická analýza nebo další distribuce. Stejné cenové číslo může mít pro každé použití odlišné smluvní podmínky. Zaznamenejte poskytovatele, tržiště, typ feedu, požadované instrumenty a povolený způsob zobrazení či uchování. Technický tým musí znát tato omezení před návrhem cache a exportů. Bez nich může vybudovat funkci, kterou licence nepovoluje.
Oddělte smluvní přístup od technické schopnosti data získat. Úspěšné připojení k API není oprávněním poskytovat výstup dalším zákazníkům. U historických dat určete povolenou dobu uchování a pravidla oprav. Práva se posuzují podle konkrétní smlouvy a trhu, proto zde neuvádíme obecné licenční závěry. Dobrý inventář zdrojů ale umožňuje obchodnímu a právnímu týmu ověřit správnou variantu včas.
Čas není jediné číslo
Událost může mít čas vzniku na trhu, odeslání poskytovatelem, přijetí ve vaší infrastruktuře a zpracování aplikací. Pokud se tyto okamžiky sloučí do jediného pole, nelze zjistit, zda zpoždění vzniklo u zdroje, v síti nebo v systému. Dokumentace Databento popisuje rozdíly mezi event, publisher a receive timestamp a upozorňuje, že přesnost značek od původního trhu se liší. Tento princip platí i mimo jejich konkrétní feed.
Při normalizaci zachovejte původní značku a přidejte vlastní měření. Uveďte časové pásmo, přesnost a případné chybějící hodnoty. Porovnání napříč trhy vyžaduje vědět, zda dva zdroje měří stejný okamžik. U historické analýzy může nesprávné pořadí vytvořit falešnou kauzalitu. U živé obrazovky musí uživatel rozumět tomu, jak starou informaci sleduje. Časová kvalita je tedy obchodní vlastnost dat, ne jen formát databázového sloupce.
Normalizace bez ztráty významu
Poskytovatelé používají různé identifikátory instrumentů, velikosti, cenové jednotky a typy událostí. Normalizační vrstva pomůže aplikaci pracovat s jednotným modelem, ale nesmí skrýt rozdíly, které ovlivňují výsledek. U každého pole držte původ a pravidlo převodu. Některé údaje je vhodné ponechat specifické pro daný trh a doplnit je pouze tam, kde jsou potřeba. Univerzální struktura se stovkami prázdných polí může být horší než jasně verzované typy.
Vytvořte testovací vzorky pro běžnou aktualizaci, chybějící hodnotu, opravu historické události a změnu definice instrumentu. Nová verze mapování nesmí tiše přepsat význam starých uložených dat. Vedle normalizovaných záznamů uchovejte podle možností i referenci na původní zprávu, aby šlo vysvětlit sporný výpočet. Pokud poskytovatel změní schéma, potřebujete alarm a postup, ne pouze další prázdný sloupec.
Snapshot, inkrementy a mezery
Živý proud může začínat úplným snapshotem a pokračovat dílčími změnami. FIX Trading Community popisuje zprávy pro úplné obnovení i inkrementální aktualizace tržních dat. Aplikace musí vědět, jak z nich sestavit konzistentní stav a co dělat, když jedna změna chybí nebo přijde mimo pořadí. Bez této logiky může obrazovka vypadat aktivně, ale zobrazovat neplatnou knihu či cenu.
Sledujte sekvenční čísla, čas poslední zprávy a stav připojení podle možností zdroje. Při zjištěné mezeře označte výstup jako nedůvěryhodný, získejte nový snapshot a obnovte tok podle protokolu poskytovatele. Nepokračujte tiše v počítání nad neúplným stavem. Historické přehrání musí pracovat se stejnou definicí pořadí jako živá cesta, jinak se výsledky pilotu a produkce mohou lišit.
Distribuce a cache podle skutečného použití
Jedna aplikace může potřebovat každý tick, jiná jen poslední známou cenu nebo agregaci v určitém intervalu. Nesnažte se každému konzumentovi vnucovat nejnáročnější proud. Vytvořte jasné datové produkty s informací o stáří, úplnosti a způsobu výpočtu. Cache má definovanou dobu platnosti a chování při výpadku zdroje. Starší hodnota musí být označená jako starší; neměla by se tvářit jako živá.
Rozhodnutí o ukládání se řídí objemem, dotazy a licencí. Při historických analýzách zvažte oddělení surového vstupu od odvozených agregací, aby šla chyba výpočtu opravit. U živých obrazovek sledujte počet současných příjemců a schopnost systému dohnat zpoždění. Kompresi a dávkování měřte proti potřebné latenci; nejnižší technická latence není vždy obchodní cíl.
Monitoring kvality je součást datového produktu
Pro každý feed stanovte očekávanou frekvenci a relevantní obchodní hodiny. Zpoždění, výpadek, duplicitní zprávy a neobvyklý skok hodnoty představují různé problémy a vyžadují různé reakce. Dashboard má ukazovat stáří poslední validní zprávy, počet mezer, rychlost zpracování a stav důležitých konzumentů. Alert potřebuje vlastníka. Bez něj je graf pouhou dekorací, zatímco uživatelé mohou rozhodovat podle starých dat.
Ověřte také vztah mezi zdroji. Dva feedy nemusí mít shodnou metodiku, takže rozdíl sám o sobě není důkaz chyby. Při opravě uveďte, odkud pochází nová hodnota a zda se má přepočítat historický výstup. Důležitá je možnost incident vysvětlit: kdy začal, koho ovlivnil, jaké výstupy se mají znovu zkontrolovat a jak se zabrání opakování.
První implementace má ověřit rozhodující riziko
Pilotujte jeden zdroj, omezenou sadu instrumentů a konkrétní konzument. Zahrňte běžný trh, období bez zpráv, restart spojení a opravu dat. Připravte srovnání mezi původní zprávou a výsledkem v aplikaci. Pokud produkt potřebuje více tržišť, ověřte nejdříve jejich rozdílnou časovou a identifikační sémantiku. Výkonnostní test na syntetických náhodných číslech sám neprokáže správnost tržního toku.
EXCOIN zde neuvádí přístup ke konkrétnímu placenému feedu, vlastní burzovní licenci ani výsledky klientských implementací. Před skutečným návrhem je třeba získat podmínky poskytovatele a přesný účel užití. Vhodným výstupem úvodní práce je datový kontrakt, definice stáří, test obnovy po mezeře a měření kvality. Na nich lze rozhodnout, zda stačí jednoduchá integrace, nebo je potřeba samostatná platforma pro více konzumentů.
Součástí pilotu má být také změna zdroje nebo formátu zprávy. Ověřte, kdo dostane upozornění, jak se zastaví publikace nedůvěryhodných hodnot a kdy se obnoví běžný tok. Jednotliví konzumenti mohou mít různou toleranci k výpadku: interní analýza může počkat, zatímco živá obrazovka musí okamžitě ukázat stáří dat. Zapište pravidlo pro každého z nich. Po incidentu přehrajte uložené zprávy a porovnejte, zda nová verze výpočtu dává očekávaný výsledek. Pokud nelze chybu reprodukovat, zůstane oprava pouze domněnkou. Právě schopnost vysvětlit konkrétní chybný údaj odlišuje provozovatelnou datovou službu od feedu, který vypadá dobře jen během demonstrace.
Při rozšiřování na další trhy nepředpokládejte stejný kalendář obchodování, identifikátory nebo pravidla oprav. Připravte malý soubor srovnávacích událostí pro každý nový zdroj a ověřte s jeho poskytovatelem význam důležitých polí. Tento krok může zabránit tiché chybě, která by jinak prošla běžným testem dostupnosti.