Backtesting / Testování a jak na něj (3/6)

V minulém díle minisérie jsme se zabývali otázkou kde splašit testovací data, nyní tedy neméně závažná věc – kam s nimi? Tohle vypadá jako banalita – a skutečně to banalita je, pokud máte k otestování 300 řádků dat. Pokud jsou jich ale stovky tisíc, nebo stovky miliónů, začnete narážet a způsob uložení testovacích dat bude pro Váš úspěch kritickou veličinou.

Tahle problematika bývá někdy od uživatele docela odstíněná, protože ji řeší testovací platforma (viz níže), je ale dobré o ní něco vědět. Jednoduše řečeno, málokdy pracujeme při testování se vzdálenými daty, protože to je pomalé. Nejčastěji jsou tedy data stažena a uložena na místní počítač, z něhož se pro účely testování “nasosávají”.

Přitom opravdu není jedno, v jaké formě jsou data na místním počítači uložena, protože způsob uložení dat ovlivňuje jednak to, zda data najdeme, a jednak to, jestli je najdeme dostatečně rychle. V zásadě se používají čtyři hlavní způsoby uložení dat.

Textové soubory

Nejjednodušší na pochopení. Data jsou v textovém souboru – co řádek to záznam, oddělena středníky nebo třeba tabulátory. Hlavní výhodou tohoto způsobu je jeho přenositelnost – neznám systém, který by neuměl otevírat textové soubory. Dalším plusem je poměrně úspěšná komprimace, pokud je to potřeba. A konečně, v textových souborech se dá hledat i vizuálně, prostě se v případě otevře datový soubor v textovém editoru a řádek se vyhledá.

Největší nevýhodou je potom to, že text snese všechno. To znamená, že pokud budete pořizovat data v textových souborech, narazíte nejspíše na soubory s americkým způsobem uložení kalendářního data (rok-měsíc-den) a ceny budou oddělené desetinnou tečkou namísto čárky, jak je našinec zvyklý. A nevýhoda je taky v tom, že potřebujete-li nějaká data opravit, musíte si dát pozor, aby se Vám struktura souboru nerozházela.

Tabulky v Excelu

Valnou většinu nevýhod textových souborů eliminuje uložení dat do Excelu. Data prostě tvoří tabulku s řádky a sloupci, snadno se v tom hledá a poměrně jednoduše se s tím i programuje.

Největší nevýhoda je potom v tom, že potřebujete Microsoft Excel pro práci s takto uloženými daty. A to je placený software. Dnes už to není tak hrozné jako dřív, protože existují alternativy, některé dobré a zadarmo. Třeba LibreOffice.

V souvislosti s Excelem je ještě třeba zmínit jednu výhodu – existují doplňky, které data do Excelu stáhnou a umístí do příslušných buněk z externích zdrojů. To může ušetřit spoustu času a peněz. Mezi nejzdařilejší produkty v tomto směru patří třeba Qmatix XLQ.

Proprietární formát

Existuje celá řada testovacích platforem, které si ukládají data po svém. Typicky do binárních souborů, kterým běžný člověk nerozumí. Největší nevýhodou bývá v takovém případě to, že datům rozumí pouze daná platforma a nelze je snadno použít jinde.

Ovšem má to taky výhody. Tyhle binární soubory jsou vymyšleny s cíle maximalizovat rychlost přístupu k datům a tak se může snadno stát, že potřebná data jsou k dispozici mnohem rychleji než data z textů a nebo Excelu.

Relační databáze

Podle mých zkušeností je správná cesta toto. Relační databáze jsou už skoro 50 let vymyšleny a optimalizovány pro rychlé zpracování dat, a to i ve větším množství (milióny řádků, stovky tabulek). Pokud se Vám podaří dostat testovací data do relační databáze, máte výhody v:

  • jistotě, že počítač ví, kde jsou datumy, kde čísla a kde texty a nepomíchá to,
  • možnosti jednoduše zajistit, že data zůstanou unikátní (např. že nebudete mít dvě ceny pro jednu akcii a stejný čas)
  • téměř konstantním čase nezbytném pro vyhledání informace i při narůstajícím objemu dat (to platí hlavně v případě použití SSD disků)
  • tom, že data půjde napojit na jakýkoliv rozumný testovací engine (například na ten Excel).
  • tom, že data mohou být na jiném PC než na jakém se testuje (rozložení výkonu).

Jinak relačních databází je spousta a používám pro uložení dat minimálně tři. Všechny tři jsou zadarmo a jsou to:

  • Oracle MySQL – možno pod Windows i Linux; není prakticky omezena velikost databáze, škálovatelné
  • Firebird, možno pod Windows i Linux, není prakticky omezena velikost databáze, hůře se zajišťuje high availability, to ale při testování nevadí.
  • Microsoft SQL server – pouze Windows, velikost databáze v edici Express je omezena na 10 GB, to může být pro testování opcí docela málo, ale zase je to databáze, která má k dispozici nejvíce nástrojů pro správu

Doporučení závěrem? Tady je každá rada drahá, protože závisí hodně na tom, co přesně chci testovat. Viděl bych to asi takto:

  1. Rychlé otestování myšlenky – textové soubory
  2. Používám-li platformu – binární formát, nechat to na platformě
  3. Potřebuji-li hezké grafy nebo mám na to doplňky – Excel
  4. Chci-li testovat hodně dat nebo mít profi přístup – relační databáze.

Jak to máte Vy, řešíte to nějak?

Příspěvek byl publikován v rubrice Nezařazené. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

28 komentářů u Backtesting / Testování a jak na něj (3/6)

  1. misch napsal:

    Jelikož jsem z práce zvyklej pracovat s PostgreSQL na Linuxu, tak při rozhodování o backtestovací (a live) platformě nebylo co řešit :). Ohledně databáze je pak pro nováčky dobré uvědomit si ještě jednu (pro spoustu lidí asi samozřejmou) výhodu: jednak se do ní ukládat i výsledky backtestů, a navíc se nad zdrojovými daty dají provádět jednoduché a rychlé selecty, které leckdy pomůžou ověřit nějakou myšlenku ještě dřív než na to člověk napíše kompletní backtest.

    • admin napsal:

      Jaj, PostgreSQL jsem nezmínil, přitom je multiplatformní, open source a snadno škálovatelná. Tímto se jí omlouvám ;-)). Máš pavdu, ukládat lze nejenom data, ale i výsledky testů a ty pak třeba aktualizovat.

      navíc vychytávky jako je https://wiki.postgresql.org/wiki/UPSERT se můžou při správě dat fakt hodit…

      • misch napsal:

        Jinak já jsem v průběhu času naznal, že místa na disku je vždycky dost, takže je škoda neukládat si některé výstupu jen proto, že si člověk na začátku řekne „to by bylo zbytečné“. Smazat se to dá vždycky :). V backtestech si tím pádem ukládám i jednotlivé obchody (to se hodí pro případnou pozdější analýzu), samozřejmě EOD equity pro každý den, procentuální expozici vůči trhu, spočtené statistiky (sharpe apod.), atd.

        Je mnohem jednodušší si to pak v UI vytáhnout přímo z databáze, než to pokaždé znovu zdlouhavě zjišťovat. A dvojnásob se to hodí, pokud člověk spouští backtesty třeba s různými kombinacemi parametrů, aby si ověřil jestli ta jedna výdělečná kombinace indikátorů nebyla jen náhoda :), pak se takové výsledky dají dobře zobrazit, exportovat, udělat z nich graf … prostě cokoliv.

        Podobným způsobem pak řeším i evidenci obchodů a výsledků v live prostředí, ale to je v tomhle tématu trochu offtopic. Přijde mi totiž lepší mít všechna čísla v databázi (s tím, že si pak můžu ke konkrétním obchodům přiřadit jednotlivé systémy a mít tak přehled o jejich výkonnosti), než se spoléhat na reporty od brokera, které navíc v průběhu času mění svůj vzhled a formát, a nemůžu si z nich tak snadno dolovat data.

        Ale možná je to jen moje databázová úchylka :). Spousta lidí nedá dopustit na Excel, a dokážou v něm zázraky.

  2. jacobson napsal:

    Dobrý den,
    Mohu se zeptat co přesně znamená při reálném obchodování „výstup na EOD“? Definici chápu, jde mi o praxi. Zatím v tom mám zmatek, a budu rád pokud mi to vysvětlíte hezky polopatě.
    Pokud pracujete ve Vaší „devadesátce“ s Close cenou (předpokládám že 200 a 5 day SMA se počítá z Close), tak znáte reálnou hodnotu Close až když trhy zavřou, a tím pádem už není čas uzavřít obchod. Takže nejspíš výstup na EOD znamená, že vycházíte z dat cca 20 minut před zavřením burzy, a tudíž vzniká odchylka, jelikož sice pomocí příkazu MOC nakoupíte/uzavřete za Close, ale výpočet pro vstup/výstup se počítá z dat Close(-20minut).
    Chápu to správně? A pokud ano, jak velká je odchylka, a není kvůli tomu backtesting tak trošku nesprávně počítaný, protože při něm počítáme signály pro vstup/výstup z Close cen.
    Moc děkuji za vysvětlení, a přeji mnoho úspěchů!

    • admin napsal:

      Chápete to správně až na větu „výpočet pro vstup/výstup se počítá z dat Close(-20minut)“. My nepoužíváme příkaz MOC zadaný na burzu 20 minut před uzavřením. Proč taky? Za 20 minut se toho může hodně stát. Používáme příkaz MKT zaslaný na burzu ve 21:59. To sice znamená, že máme ještě minutu, takže to taky není přesné, těch odlišností je ale minimum.

      Čili k výpočtu např. SMA5 používám 4 ceny EOD z posledních čtyč dnů a pátou cenu, okamžitou, která je samozřejmě živá a pochází z 21:59, prostě minutu před zavřením burzy.

  3. peha napsal:

    Chapu, ze to neni podstata clanku, ale proc se omezovat pouze na relacni databaze. Osobne pouzivam ve svem engine nerelacni MongoDB. Vzhledem k tomu, ze burzovni data nemusi mit imho relacni charakter (me stacilo vzdycky nekolik samostatnych tabulek/kolekci), nemusim udrzovat zadne DB schema (data jsou proste na jedne „hromade“), odezva je srovnatelna s RDBMS, a z pohledu platformy/licencovani plati neco podobneho jako treba o PostgreSQL.

    • admin napsal:

      Díky za doplnění. S těmito databázemi nemám žádné zkušenoasti, tak nevím, jestli by mi stačily z hlediska výkonu, škálování a tak dále. A třeba referenční integritu bych rozhodně neoželel.

      Jinak ale samozřejmě lepší MongoDB než třeba ty texťáky, o tom žádná …

  4. Hanz napsal:

    Zdarec všem,

    aktuálně stavím malou backtestingovou platformu na pythonu/djangu takže jsem seriál o BT přivítal.
    Za mě byla volba pro ukládání dat jasná – a to databáze PostreSQL do které přistupuji přes ORM takže se sní pěkně pracuje. Rychlost je i na obyčejném pecku solidní, třeba denní bary pro tickery z SP500 od 2000-01 mám natažené v řádech sekund. (1977529 OHCL records in database, 510MB) Do databáze sypu uplně všechno – OHCL +metadata tickerů, průběh a výsledky z backtestingu, různé číselníky indexů, data z predictorů atd. Pokud se chci daty prohrabávat tak to dělám pěkně z IDEčka, kde data vidím ala excel tabulka. Jak již někdo napsal, další výhodu pro PostreSQL vidím v tom, že se k datům jednoduše dostanu z různých skriptů, UI, atd, které můžete mít rozházené na více počítačích. Tohle však člověk ocení v pozdější fázi vývoje BT.Takže za mě pro PostreSQL palec nahoru. S ostatními databázemi to bude asi podobné…

    Hanz

    • admin napsal:

      Ze zvědavosti: Po postgreSQL jsi sáhl protože ji používáš i jende, nebo jsi dělal nějaký výběr a vyšla Ti jako nejlepší? já to moc nesrovnával, a na malé věci používám FireBird a na velké MSSQL, tak jen pro zajímavost co Tě k výběru vedlo? PostgreSQL neznám, nechám se poučit ;-)

      • JetPack napsal:

        Výkon, údržba, podpora. Vývoj probíhá i v ČR, profesionální komunita, volně k použití.

        • Hanz napsal:

          Souhlas s JetPack + PgSQL nemá z mého pohledu žádné nedostatky a má skvělý ekosystém nástrojů a různých udělátek. MsSQL je molouch a za prachy a FireBird není IMHO tak moc vyspělý jak PgSQL a moc nevyvíji.
          A to nejdůležitější, kombinace ORM Django + PgSQL mi šetří spoustu času.
          Hanz

          • admin napsal:

            MSSQL samozřejmě není moloch na prachy, verze Express je do velikosti databáze 10 GB zdarma pod Windows a nově i Linux, ale pokud je u PostgreSQL v pohodě výkon, možná to vyzkouším ;-)

    • jacobson napsal:

      Dobrý den,

      Já už delší dobu bojuji s platformou, na které bych rád postavil BT. Problém je, že se buď budu muset naučit programovat od píky, (rozhoduji se mezi Pythonem a R), + se naučit v postgreSQL, které už využívám spíš mimoděk při jiné práci, resp. ji využívá jeden software, ale reálně s tím pracovat neumím.

      Pokoušel jsem se napsat jednoduchý BT v excelu, ale narazil jsem na cap, je to skoro nereálné při objemu dat které potřebuji zpracovat.

      Další možnost je, že se spojím s někým, kdo se pokouší v podstatě o to samé, co já, a platformu od něj koupím. Byl by někdo ochotný mi prodat funkční backtestingovou platformu? (otázka na kohokoliv kdo si to přečte)
      Stačí mi relativně jednoduchá (For Loop), tak, abych ji po krátkém briefingu dokázal sám patřičně ovládat.

      • admin napsal:

        Pokud začínáš tím, že potřebuješ zpracovat takový objem dat, který položí Excel, pak na to jdeš na 99% špatně. Nemyslím to zle, ale testy začínáme jednoduše, od klouzavých průměrů a jednoduchých indikátorů, a to zkrátka Excel musí zvládnout.

  5. jacobson napsal:

    A nebo ještě lépe, poradí mi někdo již existující backtestingový software, v cenové relaci do 10K CZK, do kterého můžu implementovat vlastní, mnou vytvořený indikátor, a který dokáže backtestovat systém, který sleduje koš složený ze stovek akcí? Důležité je také aby dokázal správně započítat komise a fee-čka, jelikož můj systém obchoduje velké volume, a poplatky jsou obrovské.

    Díky za radu! ;)

    • myk napsal:

      Nemusíš nic kupovat. Naopak, když nějaký backtestovací systém koupíš, narazíš na omezení, které bude limitující a odstranit ho by znamenalo předělat komplet ten bactestovací systém.

      Já jsem zkoušel v Pythonu 2 bactestovací knihovny a stálo mě to několik dnů do té knihovny vůbec proniknout, pak jsem zkoušel postupně v tom něco dělat, vztekal jsem se, proč to počítá zrovna tak a tak, když logika by říkala, že to má dělat jinak, a nakonce jsem to zahodil.
      Pak jsem si to napsal od začátku celé sám, jak píšeš jednoduchý for loop, když je indikátor X tak to kup, když je Y tak to prodej. Měl jsem to napsané za 2 dny (kostra backtestu – for loop, order_buy, order_sel, pak jsem samozřejmě ladil algoritmus obchodování), ale rozumněl jsem tomu co to kde dělá.

      Doporučuji:
      Python – for loop pochopíš snadno.
      Pandas – umožní ti efektivně pracovat s časovou řadou a snadno vypočítáš indikátory, které potřebuješ. Pak s tím snadno filtruješ, třídíš….

      • jacobson napsal:

        Díky za radu! Ono to tak nejspíš dopadne, ale nevím jestli to z původního příspěvku bylo úplně zřetelné – mám skoro nulové zkušenosti s programováním. Takže to pro mě bude španělská vesnice a desítky, spíš stovky hodin strávených něčím, co by někomu jinému zabralo možná jen pár hodin. A můj čas je relativně drahý, proto mě napadlo že bude mnohem efektivnější si to koupit.

        • misch napsal:

          Tohle bohužel nefunguje (ale neber si to osobně). Pokud chce člověk vědět co dělá, tak do toho ten čas prostě investovat musí. Alternativou je koupit si nejen backtesty, ale i systém, a někoho kdo se o to bude starat, a věřit mu, atd. atd. … a to nevidím jako robustní variantu :). A pokud u backtestů někomu zaplatíš za framework, stejně vzápětí zjistíš že tam potřebuješ mít další dosud neimplementované věci, a postupem času se to bude jen komplikovat.

          Tzn. pokud chceš časem dělat něco víc, než jen zbacktestovat konkrétní verzi jednoho systému, tak nevidím jinou dlouhodobě udržitelnou variantu, než si na to buď najmout vývojáře který to celé bude trvale dělat za tebe (což poleze hodně do peněz, a stejně by pak bylo potřeba umět mu kvalitně popsat co chceš), nebo tomu věnovat čas a naučit se to, a nebo zkrátka investovat jiným způsobem.

          Tím tě nechci odradit, jen se snažím upozornit na možné komplikace.

          • misch napsal:

            Samozřejmě koupit si nějakou knihovnu nebo framework (nebo použít nějaké volně dostupné) není na škodu. Určitě nemá smysl vynalézat kolo, a pomalu a pracně ladit to, co už dávno vyřešil někdo jiný. Ale stále je potřeba rozumět tomu co ta zmíněná komponenta dělá, málokdy to funguje stylem „koupil jsem XYZ, a tím mám po starostech“. Ono bohatě stačí, když algoritmus nedělá to co by měl, a člověk potřebuje zjistit kde je chyba.

    • admin napsal:

      Koš složený ze stovek akcií? Systém obchoduje velké volume? A ty teprve sháníš testovací platformu? ???

      • jacobson napsal:

        Systém ještě nic neobchoduje samozřejmě, jen jsem chtěl zmínit důležitost možnosti správně nasimulovat poplatky (což je důležité vždy, ale pochopitelně na systému který udělá několik obchodů denně se to v longrunu projeví několikanásobně více, než u systému který uskuteční pár obchodů za měsíc….)

  6. cubecoop napsal:

    Já používám FireBird a to z důvodu, že jsem tu DB chtěl mít embedded, zdarma a co nejvíc feature, na které jsem byl zvyklý z Oracle. Ale možná bych se dneska rozhodl jinak…

  7. Jellyman napsal:

    Zdravím,děkuji za opět zajímavý článek.dovolte mi prosím se zeptat (můj dotaz bude zacatecnicky) bohužel nemám ve svém okolí nikoho kdo by mi s tím helpnul. Zajímalo by mě jestli se dá (případně jak) v excelu udělat simulace obchodů. Ze bych mu „řekl“ když jsou takove podmínky,kup x kusů, k tomu bych nastavil Sl a PT u Excel by mi vyplivl kolik bylo obchodů, jakem byl win, RRR atd s tím ze bych bych měl otevrenejch napr 30 titul a každý v jiném sešitě anebo jestli je lepší se naučit programovat?momentálně jsem začal úplně začátky pascalu:) ( do budoucna chci python a propojit pravé s daty z excelu) a testovat si tam pravě podobně myšlenky. Jaký je na to Váš názor? Snad jsem to napsal srozumitelne

    • Jellyman napsal:

      ještě prosím Vás jedna věc, snad mě za to neukamenujete:), co si myslíte o sw multicharts? díky moc

    • myk napsal:

      Ano, jde to, bez programování je to piplačka a narazíš na limity excelu. S programováním je to jednodušší.

      Udělat to čistě v excelu můžeš tak, že si výpočtové kroky budeš dávat postupně do sloupců.
      Třeba tady je návod a máš tam i sample excel:
      https://www.quantinsti.com/blog/vectorized-backtesting-in-excel/

      Na Pascal bych se vykašlal, nenajdeš tam knihovny, nauč se ten Python rovnou.

  8. Jellyman napsal:

    To myk: díky moc

  9. Pingback: Backtesting / Testování a jak na něj (4/6) | Akcie

Napsat komentář

Vaše emailová adresa nebude zveřejněna.