Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky
Návrh Kafka řešení v prostředí e-commerce BAKALÁŘSKÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Aplikovaná informatika
Autor: Mai Phuong Bui
Vedoucí bakalářské práce: RNDr. Helena Palovská, Ph.D.
Praha, duben 2021
Prohlášení
Prohlašuji, že jsem bakalářskou práci Návrh Kafka řešení v prostředí e-commerce vypracovala samostatně s použitím pramenů a literatury, které jsou v práci uvedeny.
V Praze dne 14. dubna 2021 ...
Mai Phuong Bui
Poděkování
Ráda bych poděkovala RNDr. Heleně Palovské, Ph.D. za odborné vedení, vstřícnost a rady při zpracování této bakalářské práce.
Dále bych chtěla poděkovat Jakubu Krejzovi za možnost využití dat jeho e-shopu k realizaci této práce.
Abstrakt
Cílem této práce je prozkoumat, na jakých principech funguje systém Apache Kafka a jaké může mít využití v prostředí e-commerce. Teoretická část popisuje pojmy relevantní pro daný systém a následně jednotlivé komponenty, ze kterých se Kafka skládá. Dále jsou zde uvedeny příklady využití Kafky v praxi známými společnostmi v oblasti e-commerce.
Nakonec jsou zde popsány platformy, které jsou využity v praktické části.
Praktická část spočívá v zobrazení funkcionality a možností Kafky na e-shopu. K těmto účelům poslouží e-shop Melry.cz. V rámci spolupráce s majitelem webu byly nadefinovány 3 události, pro které je navrženo řešení v podobě pohledů v databázi. Během zpracování těchto událostí bude ukázáno, jakým způsobem nakonfigurovat konektory, které nabízí Kafka Connect API.
Klíčová slova
Apache Kafka, Big Data, datový proud, Docker, Connect API, MySQL, PostgreSQL, e- commerce, Zookeeper, e-shop
Abstract
The goal of this thesis is to explore the principles on which Apache Kafka functions and what use it can have in the e-commerce environment. The theoretical part describes the concepts relevant to the system, followed by the description of each components that Kafka is made of. What follows are the examples of how Kafka is used in practice by well-known companies in the e-commerce field. The last part describes other platforms used in the practical part.
The practical part consists of displaying the functionality and possibilities of Kafka on the e-shop. E-shop Melry.cz will serve for these purposes. In cooperation with the website owner, 3 events were defined, for which a solution in the form of views in the database is proposed. During the processing of these events, a method pertaining to the configuration of the connectors offered by the Kafka Connect API will be presented.
Keywords
Apache Kafka, Big Data, data stream, Docker, Connect API, MySQL, PostgreSQL, e- commerce, Zookeeper, e-shop
Obsah
ÚVOD ... 8
Literární rešerše ... 10
1 Big Data ... 13
1.1 Charakteristika ... 13
1.1.1 Volume – objem ... 13
1.1.2 Velocity – rychlost ... 14
1.1.3 Variety – různorodost ... 14
1.1.4 Veracity – věrohodnost ... 14
1.1.5 Variability – proměnlivost ... 15
1.1.6 Visualization – vizualizace ... 15
1.1.7 Value – hodnota ... 15
1.2 Různorodost dat ... 15
1.2.1 Strukturovaná data ... 15
1.2.2 Nestrukturovaná data ... 16
1.2.3 Semistrukturovaná data ... 16
1.2.4 Behaviorální data ... 16
1.3 Proudové zpracování dat ... 17
1.3.1 Případy užití proudového zpracování dat ... 18
2 Apache Kafka ... 19
2.1 Topic – téma ... 21
2.2 Partition – oddíl ... 22
2.3 Offset ... 22
2.4 Broker & cluster ... 23
2.5 Producers – producenti ... 23
2.6 Consumers – konzumenti ... 24
2.7 Využití Kafky v oblasti e-commerce ... 25
2.7.1 Zalando ... 25
2.7.2 Adidas ... 26
2.7.3 Etsy ... 26
2.7.4 Shopify ... 26
3 Apache Zookeeper ... 27
4 PostgreSQL ... 29
5 Docker ... 31
6 Definice událostí řešení pro e-shop ... 33
6.1 O Melry.cz ... 33
6.2 Událost č. 1 – Vložení zboží do košíku ... 33
6.3 Událost č. 2 – Volba platební metody ... 33
6.4 Událost č. 3 – Volba dopravy ... 34
7 Návrh řešení ... 35
7.1 HW/SW specifikace a požadavky ... 35
7.2 Instalace a spuštění Apache Kafky ... 35
7.3 Instalace a spuštění Dockeru ... 38
7.4 Konfigurace source konektoru ... 41
7.5 Konfigurace sink konektoru ... 46
7.5.1 Návrh řešení události č. 1 ... 50
7.5.2 Návrh řešení události č. 2 ... 51
7.5.3 Návrh řešení události č. 3 ... 53
ZÁVĚR ... 57 8 Použitá literatura ... I
ÚVOD
Ve své bakalářské práci se zabývám systémem pro streamové zpracování dat Apache Kafka.
Pojem je často také překládán do češtiny jako proudové zpracování. O práci s daty jsem se začala zajímat po absolvování předmětu Databáze ve druhém ročníku. Byl to pro mě impulz najít si zaměstnání jako datový analytik a rozšířit tak své znalosti. Jako uživatele mě fascinovalo, jak rychle se mění obsah reklam na webu podle toho, které stránky jsem navštívila a zajímalo mě, jaká data společnost sbírá o uživatelích během užívání jejich produktu.
O Kafce jsem se dozvěděla díky konverzaci s kolegou na pozici Senior Data Scientist, který Kafku popisoval jako nástroj se širokým spektrem použití a znalost tohoto systému může mít pro jedince velkou přidanou hodnotu například v oblasti behaviorálních dat. Pokud chce být firma v dnešní době konkurenceschopná, je nutné, aby pracovala s aktuálními informacemi a byla schopná zpracovávat data ihned poté, co je obdrží, a Kafka tuto možnost nabízí.
Téma jsem si vybrala, protože mě Apache Kafka zaujal a chtěla jsem prozkoumat funkcionalitu systému a jeho možnosti využití, především za účelem získání nových zkušeností. Jelikož pracuji v e-commerce společnosti, rozhodla jsem se zaměřit na řešení Kafky v oblasti e-commerce.
Cíl práce
Dílčí cíle této bakalářské práce jsou:
1. Prozkoumat, na jakých principech Apache Kafka funguje a k čemu slouží jednotlivé komponenty.
2. Prozkoumat, jaké využití má Kafka v oblasti e-commerce.
3. Navrhnout a vyzkoušet řešení na zvoleném e-shopu.
Po prostudování práce by měl mít čtenář představu o tom, jak Apache Kafka funguje a znát možnosti využití této platformy v oblasti e-commerce.
Struktura práce
Bakalářská práce se skládá z několika částí. První část práce tvoří úvod.
Následuje teoretická část, ve které popíšu pojem Big Data, typy dat a způsob proudového zpracování dat, dále představím systém Apache Kafka, který zmíněným způsobem data zpracovává, a popíšu jeho komponenty a využití. V závěru teoretické části představím systémy Apache Zookeeper a PostgreSQL.
Další část se týká praktické ukázky funkčnosti Apache Kafka a postupu při instalaci systému na osobní počítač. Dále nadefinuji události relevantní pro e-shop Melry.cz po konzultaci
s vlastníkem e-shopu Jakubem Krejzou, a na základě těchto událostí navrhnu architekturu řešení v Kafce.
Poslední část tvoří závěr práce, který představuje shrnutí a hodnocení z hlediska splnění cílů bakalářské práce. Dále následuje seznam použité literatury, přílohy a terminologický slovník.
Literární rešerše
Pro účely rešerše byl proveden výzkum existující odborné literatury a akademických prací zabývajících se proudovým zpracováním dat a systému Apache Kafka.
REXA, Denis. Výpočetní úlohy pro řešení paralelního zpracování dat. Fakulta elektrotechniky a komunikačních technologií. Vysoké učení technické v Brně.
Brno. Vedoucí práce Jan Mašek, 2019. Diplomová práce.
Diplomová práce se zabývá navržením výpočetních úloh pro předmět vyučovaným na univerzitě VUT v Brně, kde budou studenti řešit zpracování dat s pomocí technologie Apache Kafka. Úlohy se týkají řešení problémů obchodního cestujícího a zpracování dat ze sociální sítě Twitter. Práce obsahuje také základní nastavení a používání Kafky, tato část se může překrývat s touto prací, ale pouze částečně.
NOVÁKOVÁ, Lucie. Spolehlivé zpracování dat ve streamové architektuře.
Fakulta informatiky. Masarykova univerzita. Brno. Vedoucí práce Barbora Bühnová, 2019. Bakalářská práce.
Autorka se v této práci zabývá odhalením rizik a kritických míst systému na streamové zpracování dat společnosti Seznam.cz, které by mohly v budoucnu společnosti bránit v úplném přechodu na streamové zpracování. V dané době Seznam.cz částečně provozoval streamové zpracování dat a částečně dávkové zpracování. K proudovému zpracování dat si společnost zvolila systém Apache Kafka, práce se tedy zabývá popisem Kafky a scénářů možných výpadků v systému.
LAŠTOVIČKA, Martin. Proudové zpracování dat: Bezpečnostní mmonitorování sítě pomocí Apache Samza. Fakulta informatiky. Masarykova univerzita. Brno. Vedoucí práce Tomáš Jirsík, 2016. Diplomová práce.
V teoretické části se autor této práce zabývá využitím proudového zpracování dat a jeho výhodami vůči dávkovému zpracování. Krátce zde také představí systém Apache Kafka a princip jeho fungování. V praktické části poté provádí výkonnostní testování vybraných frameworků, kde Kafku využívá jako prostředníka pro poskytnutí dat testovacím systémům.
S touto prací se tedy překrývá pouze v teoretické části, nicméně neobsahuje tak podrobný popis Kafky.
Hlavním literárním zdrojem při zpracování této práce je oficiální kniha vydaná vlastníky Kafky Neha Narkhede, Gwen Shapirou a Palino Toddem s názvem Kafka: The Definitive Guide: Real-Time Data and Stream Processing at Scale. Dalším důležitým zdrojem pro získání informací a návodů jak pracovat s Kafkou jsou oficiální dokumentace na webové stránce společnosti Confluent www.confluent.io, kterou založili tvůrci Apache Kafka, a dokumentace na webové stránce společnosti Cloudera www.cloudera.com, která je sponzorem The Apache Software Foundation. Dále budu čerpat z dokumentace oficiálních
webových stránek Apache Kafka www.kafka.apache.org, kde je mimo jiné také systém ke stažení.
Za zmínku stojí také kniha Learning Apache Kafka od autora Nishant Gant, která obsahuje základní informace a návod pro začátečníky, kteří chtějí začít s tímto systémem pracovat.
I. TEORETICKÁ ČÁST
1 Big Data
Abych plně porozuměla velikosti a typu dat, které Kafka zpracovává, je nutné nejprve prozkoumat a pochopit význam slova Big Data, jeho charakteristiku, a především způsob proudového zpracování těchto dat.
Big Data označuje velké množství složitých souborů dat, která nelze zpracovat na dosud známé technologii v reálném čase. Tato data mohou být jak strukturovaná, tak nestrukturovaná.
Vědci z mezinárodní americké technologické společnosti IBM uvádějí, že se Big Data skládá ze čtyř dimenzí: objem (volume), rychlost (velocity), různorodost (variety) a věrohodnost (veracity). Uznávaná výzkumná společnost v oblasti IT Gartner s tímto tvrzením souhlasí a konstatuje, že se Big Data skládá z velkoobjemových, rychlostních a rozmanitých informačních prvků, které vyžadují nákladově efektivní a inovativní formy zpracování informací za účelem lepšího přehledu a získání užitečných informací, které jsou prospěšné pro vývoj podniků a organizací. (1) Tyto vlastnosti jsou označovány jako „3V“ podle svých anglických názvů. Gartner poté k původním „3V“ přidává další „V“, jako například věrohodnost (veracity), hodnotu (value), proměnlivost (variability) a vizualizaci (visualization). (2) V takovém případě jsou charakteristiky označovány jako „7V“.
Sílu „velkých dat“ využívají nejen společnosti, vládní instituce, finanční a akademické instituce, ale i zdravotnické instituce ke zlepšení obchodních vyhlídek spolu se zlepšenou zákaznickou zkušeností. (3)
V další kapitole charakterizuji jednotlivé dimenze „7V“.
1.1 Charakteristika
1.1.1 Volume –objem
Jak již název napovídá, tato dimenze vyjadřuje objem dat. Současná data se pohybují v řádech desítek terabytů (TB) až petabytů (PB), což je problematické z hlediska zpracování a uchování. Objem dat v následujících letech se však odhaduje v řádech zettabytů (ZB). Ben Walker, Marketing Executive ve společnosti Vouchercloud zveřejnil statistiku v podobě informační grafiky týkající se denního nárůstu dat. Zde uvádí, že se každý den vytvoří 2,5 quintillionů1 bytů dat. Takové množství dat by zaplnilo 10 milionů blu-ray disků, a pokud bychom všechny tyto disky poskládali na sebe, její výška by se rovnala výšce čtyř Eiffelových věží postavených na sebe. (4) Primárním důvodem takového množství dat jsou sociální sítě a nárůst užívání mobilních zařízení. Společnost IBM uvedla, že uživatelé platformy YouTube
1 1 quintillion = 1018 bytes
měsíčně shlédnou přes 4 miliardy hodin videí. (5) Na Facebook je denně nahráno přes 350 milionů fotografií, společnost Facebook denně generuje 4 PB dat. (6) Mnoho lidí využívá mobilní zařízení mimo sociálních sítí také pro monitoring svého zdraví, cyklus spánku, nakupování nebo pro ovládání chytré domácnosti. Z každé takové činnosti se ukládá enormní množství dat všech uživatelů po celém světě.
1.1.2 Velocity – rychlost
Tato dimenze se týká jak rychlosti nárůstu dat, tak rychlosti zpracování dat. V současné době sociálních sítích je rychlost nárůstu obrovská a je důležité, aby každá nahraná fotografie, článek, video i audio bylo přístupné veřejnosti v co nejkratším možném čase.
Zmíněná statistika Bena Walkera udává, že se každou minutu na platformu Instagram nahraje 216 tisíc příspěvků a 277 tisíc „tweetů“ na platformu Twitter. Dále statistika uvádí, že se během jedné minuty zpracuje a odešle přes 204 milionů e-mailů. (4) Takové množství dat je velmi komplikované a náročné zpracovat v co nejkratším čase a poté uchovávat.
V dnešní době je běžné zpracovávat data v reálném čase, tento způsob jsem detailně prozkoumala a popsala v kapitole 1.3. Příkladem je třeba nahrání fotografie na sociální síť, kdy po kliknutí na tlačítko nahrát je fotografie ve stejnou chvíli zpracovaná a dostupná pro veřejnost. Zpracovávat data v reálném čase lze mimo jiné také pomocí softwaru Apache Kafka.
1.1.3Variety – různorodost
Data jsou shromažďována z různých zdrojů v různých formátech, a tak nejsou vždy jednotná. Mohou mít různou podobu, ať už je to databáze, fotografie, text, video či Facebookový příspěvek.
Obecně můžeme rozdělit data do tří kategorií:
§ Strukturovaná data
§ Nestrukturovaná data
§ Semistrukturovaná data
Jednotlivé kategorie popisuji dále v kapitole 1.2.
1.1.4Veracity – věrohodnost
Aby bylo možné data správně vyhodnotit a interpretovat, je nutné, abychom měli věrohodná vstupní data. Věrohodnost popisuje přesnost, správnost a pravdivost velkých dat. Realita je taková, že se v oblasti Big Data vyskytuje obrovská nejednoznačnost, neúplnost a nejistota dat, a proto je považována za jednu z dimenzí Big Data. (7) Je nutné se přesvědčit, že jsou shromažďovaná data správná a důvěryhodná, jinak jsou nám k ničemu. (8) Musíme tedy dbát na to, z jakých zdrojů data sbíráme a eliminovat včas ta nesprávná. Pokud by tato dimenze byla narušena, mohlo by to mít velmi negativní důsledky.
1.1.5 Variability – proměnlivost
Proměnlivost je jiná než různorodost. Zatímco různorodost se zaměřuje na data, která se neustále mění, proměnlivost sbírá data, která jsou stále stejná, ale mění se její podmínky a okolnosti. Jako příklad můžeme uvést příchod zaměstnance s flexibilní pracovní dobou do práce. Nebudeme neustále sbírat informace o tom, že zaměstnanec dorazil, neboť je tato informace stále stejná. Nicméně se může měnit čas příchodu a odchodu zaměstnance.
1.1.6 Visualization – vizualizace
Vizualizace dat je způsob, jakým lze prezentovat a interpretovat data managementu v podniku. Informace jsou tak přehledné a usnadňují nejen manažerům a ředitelům práci při rozhodování. Vhodná vizualizace dat často vede k rychlému odhalení nedostatků či naopak zajímavých vztahů a zjištění. Správná vizualizace dat by měla být čitelná, dostupná, věrohodná a srozumitelná.
1.1.7Value – hodnota
Práce s daty, její zpracování a následné uchovávání je velmi nákladná činnost ať už z časového, tak finančního hlediska, a proto se očekává adekvátní výsledek, který firmě bude přinášet užitek. Je nutné si proto uvědomit a dokázat rozlišit data, která mají velkou hodnotu pro firmu. Tato dimenze je považována za cíl, kterého chtějí všichni pomocí Big Data dosáhnout, ať už při rozhodování, jaké budou další kroky firmy, tak při argumentaci, proč investovat právě do daných projektů.
1.2 Různorodost dat
Jak jsem již zmínila v kapitole 1.1.3, shromažďovaná data jsou různorodá v závislosti na tom, z jakého zdroje jsou. Na obecné úrovni jsou klasifikovány do tří úrovní: strukturovaná data, nestrukturovaná data a semistrukturovaná data. Vzhledem k povaze této práce a tématem, kterým se budu zabývat v praktické časti, se dále zaměřím také na speciální typ dat, a to behaviorální Big Data.
1.2.1Strukturovaná data
Jako strukturovaná data označujeme taková data, která se dají zpracovat, ukládat a načítat ve fixním formátu. (3) Jinými slovy se jedná o data s pevně danou strukturou. Běžně jsou ukládána do relačních databází, ke kterým lze získat přístup přes dotazovací jazyky.
Příkladem takových dat jsou například databáze, ERP, adresní údaje či katastry.
Strukturovaná data se jednoduše zpracovávají a je předem jasné, kde lze konkrétní data dohledat. Nacházejí se stále na stejném místě, pouze se mění jejich hodnota.
1.2.2 Nestrukturovaná data
Nestrukturovaná data jsou taková data, která postrádají jakoukoliv konkrétní formu nebo strukturu – jsou volně strukturovaná. Díky tomu je velmi obtížně a časově náročné zpracovávat a analyzovat tato data. (3)
Příkladem nestrukturovaných dat jsou například e-maily, text, audio, data ze sociálních sítí, fotografie a další. Ben Walker ve své statistice uvádí, že 90 % dat, která jsou denně generována, jsou nestrukturovaná. (2) Jedná se přitom primárně o již zmíněná data ze sociálních sítích, multimédia a další. Jedním z dalších důležitých aspektů je tzv. IoT (Internet of Things), neboli Internet věcí. V dnešní době se stává chytrá domácnost pro lidi běžnou součástí života, kdy každý spotřebič disponuje vlastním aplikačním rozhraním, a tím generuje opět data. (9)
1.2.3 Semistrukturovaná data
Posledním typem dat jsou semistrukturovaná, neboli polostrukturovaná data. Tento typ dat je popisován také jako „data bez jasně definovaného schématu“. (9) Sem patří taková data, která nemohou být považována za strukturovaná, protože nemají pevně danou strukturu, ale ani nestrukturovaná, protože mají nepravidelnou strukturu. Tato data jsou obvykle zpracována jako nestrukturovaná data. (10)
Příkladem semistrukturovaných dat jsou formáty JSON nebo XML.
1.2.4Behaviorální data
Behaviorální data jsou speciálním typem Big Data, která vznikají interakcí zákazníka se společností nebo v reakci na ni. Příkladem mohou být činnosti jako návštěva webu, kliknutí na odkaz, přihlášení k odběru novinek a další. Zákazníkem může být například konečný spotřebitel, návštěvník webu, business společnosti či jednotlivci v businessu, avšak behaviorální data mohou být zpětně propojená s individuálními uživateli. Je důležité podotknout, že uživatel může být individuální (ti, co jsou v systému přihlášeni) nebo anonymní (ti, kteří nejsou v systému přihlášeni).
Tato data jsou obvykle vytvářena a uchovávána v podobě událostí (angl. events), které představují akci, jež byla provedena. Tato událost obsahuje vlastnosti (angl. properties), které představují metadata2 sloužící k popisu událostí. Příkladem události je návštěva webu, jejíž vlastností může být typ zařízení, ze kterého proběhla návštěva. Pro lepší představu se můžeme na události ptát otázkou „co“ a na vlastnosti otázkami „kdo, kde, kdy“. (11)
2 metadata = data, která poskytují informace o jiných datech
1.3 Proudové zpracování dat
Abych mohla definovat a popsat proudové zpracování dat, je nutné se nejdříve podívat na to, co je to datový proud (angl. data stream), často také nazýván proud událostí. Společnosti Google, Amazon a další definují datový proud jako neomezený datový soubor. Takový soubor je nekonečný a neustále rostoucí. Dataset je neomezený, neboť v průběhu času stále přicházejí nové záznamy. Příkladem datového proudu je například proud transakcí platebních karet, pohyby ve hře či odeslané e-maily. Příkladů může být mnoho, neboť téměř na vše se dá pohlížet jako na sled událostí.
Kromě neomezenosti obsahuje model datového proudu další vlastnosti:
• Datové proudy jsou seřazeny – obvykle dle času. Existuje inherentní představa, ke kterým událostem dojde před nebo po jiných událostech. Tato vlastnost je nejjasnější při pohledu na finanční událost. Sekvence, při které nejprve vložím peníze na svůj účet, které poté utratím, se velmi liší od sekvence, ve které nejprve utratím peníze, a poté svůj dluh teprve uhradím vložením peněz zpět, neboť v druhé sekvenci budou účtovány poplatky za přečerpání účtu, zatímco v první ne.
• Datové záznamy nelze měnit – jakmile k události dojde, už nikdy nemohou být upraveny. Finanční transakce, která je zrušena, nikdy nezanikne. Místo toho se zapíše další událost, která zaznamená zrušení dané transakce. Stejně tak když zákazník vrátí zboží do obchodu, nevymaže se skutečnost, že mu zboží bylo dříve prodáno, ale vrácení zboží se zaznamená jako další událost.
• Datové proudy lze znovu přehrát – pro většinu podnikových aplikací je velmi žádoucí mít možnost znovu přehrát datové proudy, které se odehrály měsíce (někdy i roky) zpátky. Tato vlastnost je nutná k opravě případných chyb, vyzkoušení nových metod analýzy nebo k provedení auditů.
Je nutné podotknout, že výše uvedené vlastnosti datových proudů nevypovídají nic o datech obsažených v událostech, ani o počtu událostí za sekundu. Data se liší od systému k systému. (12)
Nyní se již mohu zabývat zpracováním proudů dat. Proudové zpracování dat označuje zpracování dat současně při jejich generování nebo přijímání. Data přicházejí po síti v reálném čase tak, jak vznikají ve zdroji dat. Níže prozkoumám odlišnosti proudového paradigmatu od klasického dávkového zpracování (angl. batch processing).
Před proudovým zpracování dat byla data často uložena v databázi, systému souborů nebo jiných formách velkokapacitního úložiště. Dávkové zpracování dat vyžadovalo, aby byla data shromažďována v dávkové formě, než mohla být zpracována, uložena nebo analyzována, zatímco proudová data proudí nepřetržitě, což umožňuje zpracování dat v reálném čase bez nutnosti čekat na její doručení v dávkové formě. Ve většině případů je dávkové zpracování mnohem jednodušší na pochopení a řešení potíží. Schopnost dávkového zpracování dat navíc umožňuje mnohem vyšší propustnost zpracování dat než spoustu proudových
systémů. Proudové zpracování je však zásadní v tom, že umožňuje nižší latenci – když potřebuje aplikace rychle reagovat (v časovém rozmezí minut, sekund či milisekund), je zapotřebí proudový systém, který bude udržovat stav aplikace v paměti, aby dosáhl přijatelného výkonu. Dále také proudové zpracování může být efektivnější při aktualizaci výsledku než dávkové, protože automaticky inkrementuje výpočet. Například pokud budeme chtít vypočítat statistiku webového provozu za posledních 24 hodin, dávková úloha naskenuje všechna data pokaždé, když se spustí, a vždy zpracuje data za posledních 24 hodin. Oproti tomu si proudový systém může zapamatovat stav z předchozího výpočtu a počítat pouze nová data. Pokud tedy zadáme proudovému systému, aby report aktualizoval každou hodinu, zpracoval by pokaždé pouze data z poslední hodiny (nová data od posledního reportu). (13; 14)
Vzhledem ke složitosti dnešních moderních požadavků jsou původní metody zpracování dat zastaralé, neboť mohou zpracovávat data pouze jako skupiny transakcí shromážděných v průběhu času. Moderní společnosti využívají datové toky v reálném čase a jednají na základě dat za milisekundu. Tato nepřetržitá data nabízejí řadu výhod, které mění způsob, jakým podniky fungují. (13)
1.3.1 Případy užití proudového zpracování dat
Obecně je proudové zpracování užitečné v případech užití, kdy dokážeme detekovat problém a přiměřeně reagovat za účelem zlepšení výstupu. Klíčovou roli hraje především v data-driven3 společnostech. Ačkoliv v každém odvětví existují případy užití pro datové proudy, schopnost integrovat, analyzovat a odstraňovat problémy nebo předpovídat data v reálném čase ve velkém měřítku otevírá nové případy užití.
Mezi typické případy užití patří: (13)
• údaje o poloze,
• akciové obchody v reálném čase,
• marketing a prodej,
• business analytika,
• aktivita zákazníka či uživatele,
• reporting a rozhodování v reálném čase,
• odeslání upozornění a výstrah při proběhnutí nějaké události,
• monitoring a podávání zpráv o interních systémech IT,
• detekce podvodů.
3 data-driven společnost = společnost, která je zaměřená na data a dělá rozhodnutí na základě dat
2 Apache Kafka
Pochopení, na jakých principech Kafka funguje, je klíčové pro to, abych mohla správně navrhnout řešení v praktické části, provedla jsem proto průzkum systému z dostupných publikací a dokumentací. Výsledek popisuji v následujících řádcích a kapitolách.
Apache Kafka je distribuovaná platforma využívající publish-subscribe strategii pro zasílání zpráv, kterou vytvořila a spustila společnost LinkedIn v roce 2011. Publish-subscribe (někdy také pub-sub) systém se vyznačuje tím, že odesílatel (publisher) části dat neboli zprávy nesměruje tato data na konkrétního příjemce. Místo toho publisher danou zprávu klasifikuje dle určitých specifik a příjemce (subscriber) se přihlásí k příjmu určitých tříd zpráv. Tyto systémy mají často zprostředkovatele (angl. broker), centrální bod, kde jsou zprávy publikovány, aby tento proces usnadnil. (12)
Kafka rozlišuje těchto 5 základních typů API: (15)
• Admin API – slouží pro řízení a kontrolu témat, brokerů a dalších objektů v Kafce.
• Producenti (Producer API) – slouží k zapisování proudů události do jednoho či více témat Kafky.
• Konzumenti (Consumer API) – slouží ke čtení a zpracování těchto proudů událostí.
• Streams API – slouží k implementaci aplikací pro streamové zpracování. Jedná se o zpracovatelskou vrstvu, která poskytuje funkce pro zpracování proudů událostí, včetně transformací, stavových operací, zpracování založené na čase událostí a další.
Data načítá z různých témat, po zpracování generuje výstup opět do různých témat.
• Connect API – slouží pro vytváření a spouštění konektorů, které slouží pro čtení či zápis proudů událostí do a z externích systémů a aplikací pro integraci s Kafkou.
Příkladem je konektor relační databáze, který může zachytit jakoukoliv změnu v tabulkách. V současné době existuje mnoho předem naprogramovaných konektorů, které jsou volně dostupné na Internetu, oficiální konektory jsou dostupné na stránkách společnosti Confluent.4 Connect API využiji v praktické části, neboť nemám přístup ke zdrojovému kódu webové aplikace, do kterého bych v případě programování vlastního konektoru musela zasahovat, a tento způsob je tak nejvhodnější.
Základní datovou jednotkou Kafky je zpráva. Tyto zprávy jsou kategorizované do témat (angl. topic). Témata jsou dále rozdělena do oddílů (angl. partition). Zprávy jsou do oddílů zapisovány vždy na konec oddílu a čtou se v pořadí od začátku do konce. Rozdělení dat do jednotlivých témat a oddílů má na starost producent (angl. producers). (12)
4 https://www.confluent.io/hub/
Na druhé straně Kafky stojí konzument (angl. consumer), v jiných publish-subscribe systémech také nazýván čtenář (angl. reader) či odběratel (angl. subscriber), který dané zprávy čte na základě offsetu. (12)
Architektura Apache Kafky je založena na clusteru serverů, které se nazývají brokery, případně broker, pokud je server pouze jeden. Brokery přijímají zprávy od producentů, přidělí jim unikátní offset a umístí zprávy do úložiště na disku. Každý broker obsahuje různé oddíly určitého tématu. (12) Výše zmíněné komponenty Kafky zkoumám detailněji v následujících podkapitolách. Na Obr. 1 lze vidět znázorněnou výše popsanou architekturu Kafky.
Obr. 1. Znázornění Kafka architektury. Zdroj: autor
Ideální publish-subscribe systém je velmi přímočarý – zprávy Odesílatele A se musí dostat k Příjemci A, zprávy Odesílatele B se musí dostat k Příjemci B a tak dále.
Takový ideální systém má následující výhody: (16)
• Neomezené zpětné zobrazení – nový příjemce, který se přihlásí k příjmu zpráv daného odesílatele, si může zobrazit jeho odeslané streamy informací z jakékoliv doby.
• Uchování zpráv – žádné zprávy nejsou ztraceny.
• Neomezené úložiště – publish-subcribe systém má neomezené úložiště zpráv.
• Žádný výpadek systému.
• Neomezené škálování – publish-subscribe systém zvládne libovolný počet odesílatelů nebo příjemců s konstantní latencí doručování zpráv.
V současné době je nejnovější verzí Apache Kafka verze 2.7.0, která vyšla v prosinci roku 2020. V této verzi mimo jiné pracují vývojáři na odstranění závislosti Kafky na Zookeeperu, aby byla správa metadat škálovatelná, v době psaní práce však Kafka stále Zookeeper k fungování vyžaduje. Dále byla také přidána podpora PEM formátu pro ukládání privátních klíčů a SSL certifikátů za účelem zlepšení bezpečnosti. (17)
Mezi příklady aplikací, které mohou tuto platformu využívat, patří: (16)
• IoT – Internet of Things, například chytré televize, lednice, pračky, termostaty a další mohou odesílat data na server prostřednictvím Internetu,
• senzorové sítě – různé oblasti (farmy, lesy, zábavní parky) a komplexní zařízení (motory) mohou být navrženy s řadou senzorů pro sledování dat či aktuálního stavu,
• geolokační údaje – dodávky nebo on-line hry pro více hráčů mohou odesílat údaje o poloze na centrálu,
• e-commerce – tuto oblast popisuji detailněji v kapitole 2.7, neboť se jedná o hlavní oblast, které se věnuji v této práci,
• další data v reálném čase – družice či lékařské senzory mohou odesílat data do centrální oblasti ke zpracování.
2.1 Topic – téma
Události jsou organizovány a trvale uloženy v tématu, z anglického slova topic. Téma je tedy fronta zpráv napsaných jedním či více producenty a přečtených jedním či více konzumenty.
Představuje určitý proud dat. Jednotlivá témata jsou identifikovaná podle názvu. Příkladem názvu tématu může být „Platby“. Nejbližší analogií k tématu je databázová tabulka či složka v souborovém systému. Témat můžeme mít neomezené množství. (12) Zprávy v tématu lze číst tak často, jak je potřeba. Výkon Kafky je účinně konstantní s ohledem na velikost dat, a tak je dlouhodobé ukládání dat naprosto v pořádku.
Aby byla data odolná vůči chybám a vysoce dostupná, každé téma může být replikováno, a to i napříč geografickými regiony nebo datovými centry. Díky tomu vždy existuje více brokerů, kteří mají kopii dat pro případ, že by se něco pokazilo nebo když je nutná údržba brokerů. Replikační faktor by měl být větší než 1. Běžně je nastaven faktor replikace 3, to znamená, že vždy budou existovat tři kopie daných témat s daty. Replikace se provádí na úrovni témat-oddílů. (18) Proces replikace znázorňuje Obr. 2, kde jsou vyznačeny 3 brokery a téma X. Toto téma obsahuje 2 oddíly, Oddíl 1 je uložen v Brokeru 1, Oddíl 2 je uložen v Brokeru 3. Protože je replikační faktor 3, Oddíl 1 se replikuje do Brokeru 2 a 3 a Oddíl 2 se replikuje do Brokeru 1 a 2.
Obr. 2. Znázornění procesu replikace. Zdroj: autor
2.2 Partition – oddíl
Témata jsou rozdělena na oddíly. Když je nová událost přidána do tématu, je ve skutečnosti připojena k jednomu z oddílů tématu. Oddíly jsou také způsob, jakým Kafka poskytuje redundanci a škálovatelnost. Každý oddíl může být hostován na jiném serveru, což znamená, že jedno téma může být horizontálně škálováno napříč více servery, aby poskytlo vyšší výkon, než by bylo v možnostech jediného serveru. (12) Události se stejným klíčem (například ID zákazníka nebo vozidla) se zapisují do stejného oddílu a Kafka zaručuje, že každý konzument daného tématu-oddílu bude vždy číst události (zprávy) tohoto oddílu v přesně stejném pořadí, v jakém byly zapsány. (18)
2.3 Offset
Offset je identifikátor určující zprávy, které konzument už přečetl. Je to celočíselná hodnota, která se neustále zvyšuje. Začíná číslem 0, je nekonečný a neomezený. Každá zpráva v oddílu má svůj unikátní offset. Pomocí offsetu se může konzument v případě výpadku kdykoliv vrátit k místu čtení, kde naposledy skončil. Kafka ukládá offsety v reálném čase do tématu s názvem __consumer_offsets. Přesněji řečeno, konzument po zpracování dat, které od Kafky obdrží, odešle offset zprávy do tohoto tématu. Zprávy v Kafce jsou uchovávány pouze po určitý čas, poté jsou vymazány. Ve výchozím nastavení je doba stanovena na 7 dní.
Nicméně ačkoliv jsou zprávy vymazány, offset se nevrátí na 0, nýbrž se dál zvyšuje. (12) Konzument si může vybrat kdy a jak často zapisovat offsety do výše uvedeného tématu: (19)
• Nanejvýš jednou. Zde jsou offsety zapsány ihned poté, co konzument obdrží zprávu. V takovém případě však může dojít ke ztrátě dat, neboť mohl nastat problém při zpracování dat.
• Alespoň jednou. Tento způsob je nejpreferovanější. Offsety jsou zapsány až potom, co konzument zprávu přečte. To znamená, že v případě problému při zpracování bude zpráva znovu načtena. Tento způsob však může vést k duplikaci dat.
• Právě jednou. Tohoto způsobu lze dosáhnout pomocí Kafka Stream API, pokud se jedná o workflow v rámci Kafky. Pro workflow z Kafky do externího systému, například databáze, je zapotřebí konzument, který zprávu zpracuje idempotentně, což zajistí, že ve výstupu nebude žádná duplikace dat.
2.4 Broker & cluster
Kafka server se zde nazývá broker. Brokery jsou nadefinovány tak, aby fungovaly jako součást clusteru. Jak jsem již zmínila v předchozí kapitole, brokery přijímají zprávy od producentů, přidělí jim unikátní offset a poté umístí zprávy do úložiště na disku. Dále také reagují na požadavky konzumentů o načtení oddílů. Reagují zprávami, které byly umístěny na disk. V závislosti na konkrétním hardwaru a jeho výkonu může jeden broker snadno zpracovat tisíce oddílů a miliony zpráv za sekundu. Každý broker je identifikován vlastním ID v číselném formátu. Kafka brokeru se jinými slovy říká také bootstrap server. To znamená, že připojením k jakémukoliv brokeru se připojíme zároveň k celému clusteru.
Každý broker obsahuje metadata o všech ostatních brokerech, jejich tématech a oddílech.
(12)
V rámci clusteru brokerů funguje jeden broker jako správce clusteru (angl. cluster controller). Tento správce je zvolen z množiny aktivních brokerů pomocí Zookeeperu, o kterém píšu v kapitole 3. Správce je zodpovědný za administrativní operace, včetně přiřazování oddílů brokerům a monitorování selhání brokerů. (12)
Každý oddíl je vlastněn jedním brokerem v clusteru, takový broker je nazván vedoucím oddílu. Oddíl může být přiřazen více brokerům, což povede k replikaci oddílu. V jednu chvíli však může existovat pouze 1 vedoucí daného oddílu a pouze tento vedoucí může obdržet a odesílat data producentům a konzumentům, jinými slovy všichni konzumenti a producenti operující na daném oddílu se musí vždy připojit k vedoucímu brokeru. Každý oddíl tedy vždy obsahuje jednoho vedoucího a jednu a více replik, kterým se říká in-sync replica (dále ISR), v překladu synchronizovaná replika. V případě výpadku vedoucího brokeru ho jedna z replik ve funkci nahradí, a ve chvíli, kdy se vedoucí znovu připojí, se pokusí svoji funkci opět převzít. (20) O tom, kdo se stane vedoucím a ISR rozhoduje správce clusteru.
2.5 Producers – producenti
Producenti mají za úkol rozdělovat data do jednotlivých témat a oddílů. Tuto činnost vykonávají automaticky. Ve výchozím nastavení producent rovnoměrně vyvažuje zprávy
přes všechny oddíly v tématu. (12) Při zápisu zprávy si může producent vybrat, zda chce obdržet potvrzení. Existují tři stupně potvrzení: (21)
• Stupeň potvrzení = 0. V takovém případě nebude producent čekat na potvrzení o obdržení dat brokerem a hrozí zde možnost ztráty dat. Ztráta dat může nastat, pokud by se producent pokusil zapsat data na broker, který má například výpadek.
V takovém případě by se o výpadku nedozvěděl.
• Stupeň potvrzení = 1. Zde vyčká producent na potvrzení od vedoucího oddílu (viz.
kapitola 2.4), že zprávu obdržel.
• Stupeň potvrzení = vše (angl. all). Producent čeká na potvrzení jak od vedoucího oddílu, tak od synchronizovaných replik, že zprávu obdrželi. Tímto se zabrání ztrátě dat, neboť i při výpadku brokeru budou data uložená v replikách.
Producenti si můžou také vybrat odeslat klíč společně se zprávou. Tento klíč může být v jakémkoliv datovém formátu (např. vozidlo_id_157). Pomocí tohoto klíče může producent nasměrovat zprávy do určitých oddílů. Také je zapotřebí rozdělovač (angl.
partitioner), který vygeneruje hash klíče a namapuje jej na konkrétní oddíl. Tím je zajištěno, že všechny zprávy vytvořené daným klíčem budou zapsány do stejného oddílu. (12) Když použiji příklad klíče, který jsem uvedla výše, tak veškeré zprávy s klíčem vozidlo_id_157 budou zapsány pokaždé do stejného oddílu. Pokud má klíč hodnotu null, data jsou rovnoměrně rozdělená mezi všemi oddíly.
2.6 Consumers – konzumenti
Konzumenti čtou data z témat. Jsou naprogramovaní tak, aby vždy automaticky věděli, z jakého brokeru data číst. Jak jsem již zmiňovala, konzumenti sledují, které zprávy již byly přečteny pomocí offsetů. Data jsou čtená v pořadí tak, jak byla přidána v rámci oddílu.
Konzument tedy začíná číst data od offsetu 0 a výš, jak je znázorněno na Obr. 3. (22)
Obr. 3. Zobrazení způsobu čtení dat konzumentem. Zdroj: autor
Konzumenti jsou součástí tzv. skupiny konzumentů (angl. consumer group) skládající se z jednoho či více členů, kteří společně využívají jedno téma. Tato skupina zajišťuje, že je
každý oddíl využíván pouze jedním konzumentem v rámci skupiny. Tento princip znázorňuji na Obr. 4. Pokud by skupina obsahovala více konzumentů než oddílů, budou někteří konzumenti neaktivní. Takový stav je nežádoucí, ideální je mít tolik konzumentů, kolik máme oddílů v tématu. Jediná situace, kdy je vhodné mít více konzumentů než oddílů, je v případě výpadku konzumenta. V takovém případě ho může nahradit ten konzument, který byl do té doby neaktivní. (22) Nicméně tuto funkci by mohl převzít jakýkoliv jiný člen ve skupině, neboť při selhání jednoho člena ti zbývající vyvažují oddíly mezi sebou, aby převzali práci chybějícího člena. Neaktivního konzumenta proto nedoporučuji.
Obr. 4. Znázornění principu fungování skupin konzumentů. Zdroj: autor
2.7 Využití Kafky v oblasti e-commerce
Kafku využívá nespočet společností a stává se stále oblíbenější platformou. Patří mezi ně například společnosti Netflix, Spotify, Uber, Paypal, Pinterest a další. Velmi oblíbený je ale také v oblasti e-commerce, neboť nabízí široké možnosti zpracování dat v reálném čase.
Pomocí Kafky lze v oblasti e-commerce zaznamenávat a zpracovávat data o chování uživatelů na webu, například počet kliknutí, data o vyhledávání, objednávky, zboží v nákupním košíku nebo obsahu zboží v seznamu oblíbených. Na základě zpracovaných dat lze určit jaké produkty si zákazník nejpravděpodobněji zakoupí s jiným produktem a podle toho mu zobrazovat příslušné reklamy. Níže vyjmenuji příklady konkrétních společností, které Kafku využívají a jakým způsobem.
2.7.1Zalando
Internetový obchod Zalando využívá Kafku jako Enterprise Service Bus5 (dále ESB).
Jednotlivé služby a data tak lze snadno monitorovat a synchronizovat. Díky používání Kafky
5 Enterprise Service Bus (ESB) = softwarová architektura, která umožňuje integraci služeb při implementaci SOA v podnikovém prostředí.
pro streamové zpracování může Business Intelligence ve firmě probíhat téměř v reálném čase. (23)
2.7.2Adidas
Společnost Adidas využívá Kafku jako jádro platformy pro rychlé streamování dat, která integruje zdrojové systémy a umožňuje týmům implementovat zpracování událostí v reálném čase za účelem monitorování, analýzy a reportingu řešení. (23)
2.7.3 Etsy
Společnost Etsy využívá Kafku jako systém zasílání zpráv (angl. message system) a datovou sběrnici (angl. data bus) pro sjednocení více zdrojů dat a úložišť. Pro společnost je nyní mnohem jednodušší údržba dat, protože stačí spravovat pouze Kafku. Etsy dříve měla zdlouhavou časovou smyčku, ale nyní se dívá na analytická řešení, která umožní analýzu dat v reálném čase. (24)
2.7.4 Shopify
Společnost Shopify Kafku nejprve používala jako datovou sběrnici pro spolehlivé zasílání zpráv v roce 2014 a dále hlavně ke shromažďování událostí a agregaci protokolů napříč systémy. V současné době se společnost zaměřuje na analytiku, podpůrné nástroje a analýzu podvodů. Denně streamuje miliardy událostí napříč všemi clustery. Tyto události využívají vývojáři, analytici a datoví vědci k tomu, aby vybudovali data-driven společnost na světové úrovni. (25)
3 Apache Zookeeper
Aby bylo možné Kafku spustit, je nutné mít předtím spuštěný Apache Zookeeper. Lze tedy říct, že je Kafka na Zookeeperu závislá. Z tohoto důvodu jsem se rozhodla kapitolu věnovat právě tomuto systému.
Apache Zookeeper je software vyvinutý společností Apache, který funguje jako centralizovaná služba obsahující datové úložiště a používá se k udržování konfiguračních dat a k zajištění flexibilní a robustní synchronizace v distribuovaných systémech. Může také fungovat jako adresářová služba (angl. naming service). Datové úložiště je hierarchického typu key-value. Samotný Zookeeper umožňuje několika klientům provádět současně čtení a zápis a funguje jako sdílená konfigurační služba v systému. (26) Jádrem systému je protokol Zookeeper Atomic Broadcast (dále ZAB), který zajišťuje, že replikace v Zookeeperu probíhá v pořádku, a je také zodpovědný za výběr vedoucího uzlu (angl. leader node) a obnovení uzlů v případě selhání. V Zookeeperu je vedoucí uzel jádrem všeho – každý cluster má jednoho vedoucího a zbytek uzlů jsou následovníci (angl. followers). Všechny požadavky klientů a změny stavu nejprve obdrží vedoucí uzel s odpovědností replikovat je mezi všemi svými následovníky a sebou. Všechny příchozí požadavky na čtení jsou také vyvážené rovnoměrně mezi ním a následovníky. (27)
Zookeeper má v Kafce následující funkce: (26)
• Sleduje stav uzlů clusteru a sleduje stav Kafka témat, oddílů a dalších objektů.
• Spravuje a udržuje seznam brokerů.
• Pomáhá při procesu volby vedoucího oddílu.
• Odesílá Kafce upozornění o změně stavu (např. vznik nového tématu, výpadek brokeru, obnovení brokeru, smazání tématu a další).
• Má na starost konfiguraci všech témat včetně seznamu existujících témat, počtu oddílů pro každé téma, umístění všech replik a konfigurace toho, který uzel je preferovaným vedoucím a další.
• Jsou zde udržovány seznamy řízení přístupů pro všechna témata.
• Vybírá správce clusteru. Správce clusteru je jednou z nejdůležitějších zprostředkovatelských entit v Kafce, také je zodpovědný za určení vedoucího oddílu a správu stavů oddílů a replik.
Ačkoliv je v současné době Kafka na Zookeeperu závislý, tvůrci pracují na tom, aby byl schopen fungovat bez Zookeeperu. Došli k názoru, že ukládat metadata externě není příliš efektivní, navíc to omezuje škálovatelnost Kafky, a proto vznikl Kafka Improvement Proposal 500 (dále KIP-500), v překladu Návrh na zlepšení Kafky, kde budou metadata uložená v oddílu v Kafce a správce clusteru bude zároveň vedoucí tohoto oddílu. KIP-500 také urychlí vytváření a mazání témat. V současné době, když je téma vytvořeno nebo odstraněno, musí správce znovu načíst úplný seznam všech názvů témat ze Zookeeperu.
(28) Gwen Shapira, spoluautor knihy Kafka The Definitive Guide a zároveň Engineering
Leader ve společnosti Confluent odhaduje uvedení KIP-500 do provozu do konce roku 2021.
(29)
4 PostgreSQL
PostgreSQL, zkráceně Postgres, je objektově-relační databázový systém (dále ORDBMS, z anglického slova Object-Relational Database Management System) s otevřeným zdrojovým kódem (angl. open-source). Otevřený znamená mimo jiné dostupnost licence softwaru, která určuje, jaká práva k otevřenému kódu uživatel získá a jak s nimi může naložit. Software je bezplatný a volně dostupný, přesto však velmi pokročilý a nabízí řadu možností, z tohoto důvodu jsem ho zvolila pro následující část práce.
PostgreSQL, jaký známe v dnešní podobě, vznikl z projektu Ingres vyvíjeném na Kalifornské univerzitě v Berkley Michaelem Stonebrakerem v roce 1977. Software dostal název PostgreSQL v roce 1996 v reakci na podporu SQL, přesto je však často nazýván Postgres.
První verze PostgreSQL vyšla v roce 1997. První verzí Postgres byla verze 6.0. Jako open- source projekt s velmi dobrou pověstí přilákal software stovky vývojářů. V současné době má PostgreSQL nespočetné množství rozšíření a velmi aktivní komunitu. Software také zcela splňuje požadavky ACIDu6. (30)
Jak již z názvu vyplývá, PostgreSQL podporuje velkou část standardu SQL a nabízí mnoho funkcí, například: (31)
• složité dotazy,
• podporuje cizí klíče,
• podporuje spouštěče,
• aktualizovatelné pohledy,
• transakční integritu,
• ukládání procedur,
• a další.
Dále také podporuje z hlediska bezpečnosti několik metod ověřování, včetně hesla, LDAPu, GSSAPI, SSPI, Kerberosu, certifikace, RADUIS a PAM autentizace.
Uživatel také může PostgreSQL mnoha způsoby rozšířit, například přidáním nových (31)
• datových typů,
• funkcí,
• operátorů,
• agregačních funkcí,
• indexových metod,
• procedurálních jazyků,
• a další.
6 ACID = seznam požadavků na bezpečný transakční systém (atomic, consistent, isolated, durable).
PostgreSQL mimo SQL podporuje také NoSQL datové typy, jako je JSON7, který se často používá pro sdílení dat mezi různými systémy v moderních webových aplikacích. Dále také podporuje datový typ XML8, který je velmi flexibilní a často se používá k definování formátu dokumentů. XML se používá v RSS, Atomu, SOAP a XHTML. PostgreSQL podporuje několik XML funkcí pro generování a vytváření XML dokumentů. Také podporuje XPath, jazyk pro vyhledávání informací v XML dokumentech. (30)
7 JSON = JavaScript Simple Objection Notation
8 XML = Extensible Markup Language
5 Docker
V praktické části využiji mimo jiné také Docker, a proto nyní krátce představím, o jaký software se jedná.
Docker je open source platforma navržená k usnadnění vývoje, nasazení a spuštění aplikací za pomocí tzv. kontejnerů. Kontejnerem se označuje volně izolované prostředí umožňující vývojářům zabalit aplikaci se všemi potřebnými části, které potřebuje pro její běh (např.
knihovny), do jednoho balíčku. Šetří se tím hardwarové zdroje. Izolace a zabezpečení umožňují uživateli provozovat několik kontejnerů současně na jednom hostu. Obsahují vše potřebné ke spuštění aplikace, tudíž se uživatel nemusí spoléhat na to, co je aktuálně nainstalováno na hostu. (32)
Důležitou komponentou v Dockeru je tzv. obraz (angl. image), který představuje šablonu s pokyny k vytvoření kontejneru. Obraz je určen pouze ke čtení a obsahuje zdrojový kód, knihovny, nástroje a další soubory potřebné ke spuštění kontejneru. Často je obraz založen na nějakém jiném obrazu, pouze obsahuje další přizpůsobení. Tyto obrazy jsou ukládány v Docker registru. Veřejným registrem, ke kterému má kdokoliv přístup, je Docker Hub, kde se nacházejí volně dostupné obrazy. (32)
Ukázka toho, jak Docker funguje, bude předvedena v praktické části včetně jeho procesu instalace.
II. Praktická část
6 Definice událostí řešení pro e-shop
6.1 O Melry.cz
Pro úplnou představu a porozumění následujících událostí týkající se obchodu Melry.cz považuji za důležité představit a popsat jeho podstatu a zaměření.
Internetový obchod Melry.cz se zabývá prodejem šperků, které zlatnice ručně vyrábí v českém ateliéru. Prvotní myšlenka přišla v létě 2019 od Jakuba Krejzy, zakladatele a vlastníka obchodu. Celý e-shop naimplementoval svépomocí, během roku poté vyřešil napojení na dopravce, platební bránu, nafocení produktů a 7. února 2020 byl e-shop uveden do provozu. Obchod se zaměřuje především na kvalitu produktu, nikoliv na kvantitu a v současné době nabízí jednu kolekci šperků z vltavínu ve dvou variantách, zlatu a stříbru.
E-shop data o nákupu ukládá do MySQL databáze. Jelikož se jedná o malý obchod, jehož provoz byl spuštěn nedávno, neobsahuje příliš velké množství dat. Z důvodu ochrany osobních údajů zde nebudu zobrazovat údaje o zákaznících, na jednotlivé zákazníky se budu odkazovat skrze číslo objednávky, které je přiděleno každému zákazníkovi.
6.2 Událost č. 1 – Vložení zboží do košíku
Jako první událost jsem po konzultaci s vlastníkem webu zvolila událost vložení zboží do košíku zákazníkem. E-shop ukládá informaci o vloženém zboží v košíku do databáze až v momentě, kdy je objednávka odeslána. Cílem tedy bude získat informace o tom, jaké zboží zákazník zakoupil. Na základě těchto informací bychom poté mohli zhodnotit, jaký produkt byl nejčastěji zakoupen.
6.3 Událost č. 2 – Volba platební metody
Druhou událostí je volba platební metody. Cílem bude získat informace o tom, jakou platební metodu zákazníci volí nejčastěji. Na základě výsledků může obchod daný platební způsob v budoucnu vylepšovat či se na něj více zaměřit nebo naopak zvážit zrušení nevyužívaného způsobu platby.
V Melry jsou rozlišeny 3 způsoby platby – platba kartou, bankovním převodem či dobírkou.
Každá platební metoda má přidělený kód, jenž ji představuje.
Tabulka 1. Legenda pro typy platebních metod. Zdroj: autor
Kód transakce Popis
1 Platba kartou
2 Bankovní převod
3 Dobírka
6.4 Událost č. 3 – Volba dopravy
Poslední událostí je volba dopravy zákazníkem. Cílem je zaměřit se na to, který způsob dopravy zákazníci nejvíce preferují a který způsob naopak téměř nevyužívají. Melry nabízí 3 způsoby dopravy – odeslání přes Zásilkovnu, přes společnost DPD či přes Českou poštu.
Při odeslání objednávky přes Zásilkovnu je v databázi zaevidované číslo zásilky. V případě odeslání společností DPD je doprava označena kódem 106, doprava přes Českou poštu je označena kódem 13.
7 Návrh řešení
7.1 HW/SW specifikace a požadavky
Praktická část práce byla provedena na zařízení MacBook Pro 2017 s následujícími parametry:
• Operační systém: macOS Big Sur verze 11.2.
• Procesor: 2,3 Ghz dvoujádrový Intel Core i5.
• RAM: 8 GB.
Aby bylo možné Kafku spustit, je nutné mít nainstalovanou Javu, minimální požadovaná verze je Java 8 a výše. Na zařízení je Java JDK 8 v době provedení řešení již nainstalována, proto zde není uveden postup.
7.2 Instalace a spuštění Apache Kafky
Jako první krok jsem si stáhla instalační balíček Kafky z oficiální webové stránky Apache Software Foundation9. Zvolila jsem binární balíček verze 2.7.0. Po stažení jsem balíček přesunula do root adresáře a rozbalila ho pomocí příkazu tar.
Výpis 1. Ukázka použitých příkazů a částečný výstup. Zdroj: autor
maiphuong@Karel-MacBook-Pro ~ % mv Downloads/kafka_2.13-2.7.0.tgz . maiphuong@Karel-MacBook-Pro ~ % tar -xvf kafka_2.13-2.7.0.tgz x kafka_2.13-2.7.0/
x kafka_2.13-2.7.0/LICENSE x kafka_2.13-2.7.0/NOTICE x kafka_2.13-2.7.0/bin/
x kafka_2.13-2.7.0/bin/kafka-delete-records.sh x kafka_2.13-2.7.0/bin/trogdor.sh
x kafka_2.13-2.7.0/bin/kafka-preferred-replica-election.sh x kafka_2.13-2.7.0/bin/connect-mirror-maker.sh
x kafka_2.13-2.7.0/bin/kafka-console-consumer.sh x kafka_2.13-2.7.0/bin/kafka-consumer-perf-test.sh x kafka_2.13-2.7.0/bin/kafka-log-dirs.sh
x kafka_2.13-2.7.0/bin/zookeeper-server-stop.sh x kafka_2.13-2.7.0/bin/kafka-verifiable-consumer.sh x kafka_2.13-2.7.0/bin/kafka-features.sh
9 https://kafka.apache.org/downloads
x kafka_2.13-2.7.0/bin/kafka-acls.sh
x kafka_2.13-2.7.0/bin/zookeeper-server-start.sh x kafka_2.13-2.7.0/bin/kafka-server-stop.sh x kafka_2.13-2.7.0/bin/kafka-configs.sh
Pro usnadnění následující práce jsem si nastavila automatické dokončování pomocí tabulátoru všech Kafka příkazů z adresáře bin. Toho jsem dosáhla vytvořením souboru zshrc, kam jsem poté doplnila cestu PATH k adresáři bin Kafky, viz. Výpis 2.
Výpis 2. Zobrazení kódu ze souboru .zshrc pro nastavení cesty k souboru bin. Zdroj: autor
export PATH=".:/usr/bin:/bin:/usr/sbin:/sbin:$PATH:/Users/maiphuong/kafka_2.13-2.7.0/bin"
Nyní mohu spustit jakýkoliv příkaz z daného adresáře bez ohledu na to, v jakém adresáři se nacházím, aniž bych pokaždé psala celou cestu k souboru. Navíc stačí začít psát příkaz
„kafka“ a po stisknutí tabulátoru se zobrazí seznam příkazů, viz Obr. 5.
Obr. 5. Zobrazení seznamu příkazů pomocí automatického dokončování. Zdroj: autor Aby bylo možné Kafku spustit, je nutné nejprve spustit Zookeeper. Použitý příkaz a jeho průběh spuštění je zobrazen ve Výpis 3. Úspěšné spuštění Zookeeperu poznáme tak, že nám terminál zobrazí informaci o připojení k portu 2181.
Výpis 3. Proces spuštění Zookeeperu. Ukázka výpisu z kódu. Zdroj: autor
maiphuong@Karel-MacBook-Pro kafka_2.13-2.7.0 % zookeeper-server-start.sh config/zookeeper.properties
[2021-03-01 23:16:54,401] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2021-03-01 23:16:54,404] WARN config/zookeeper.properties is relative. Prepend ./ to indicate that you're sure! (org.apache.zookeeper.server.quorum.QuorumPeerConfig) [2021-03-01 23:16:54,435] INFO clientPortAddress is 0.0.0.0:2181
(org.apache.zookeeper.server.quorum.QuorumPeerConfig) .
. . .
[2021-03-01 23:16:54,526] INFO minSessionTimeout set to 6000 (org.apache.zookeeper.server.ZooKeeperServer)
[2021-03-01 23:16:54,526] INFO maxSessionTimeout set to 60000 (org.apache.zookeeper.server.ZooKeeperServer)
[2021-03-01 23:16:54,527] INFO Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 60000 datadir /tmp/zookeeper/version-2 snapdir /tmp/zookeeper/version-2 (org.apache.zookeeper.server.ZooKeeperServer)
[2021-03-01 23:16:54,546] INFO Using org.apache.zookeeper.server.NIOServerCnxnFactory as server connection factory (org.apache.zookeeper.server.ServerCnxnFactory)
[2021-03-01 23:16:54,551] INFO Configuring NIO connection handler with 10s sessionless connection timeout, 1 selector thread(s), 8 worker threads, and 64 kB direct buffers.
(org.apache.zookeeper.server.NIOServerCnxnFactory)
[2021-03-01 23:16:54,568] INFO binding to port 0.0.0.0/0.0.0.0:2181 (org.apache.zookeeper.server.NIOServerCnxnFactory)
Nyní již můžeme spustit Kafku. Příkaz ke spuštění je zobrazen ve Výpis 4, první zvýrazněný řádek. Informaci o tom, zda byl Kafka úspěšně spuštěn, nám udává poslední řádek ve Výpis 4.
Výpis 4. Proces spuštění Apache Kafky. Ukázka výpisu z kódu. Zdroj: autor
maiphuong@Karel-MacBook-Pro kafka_2.13-2.7.0 % kafka-server-start.sh config/server.properties
[2021-03-03 15:37:31,537] INFO Registered kafka:type=kafka.Log4jController MBean (kafka.utils.Log4jControllerRegistration$)
[2021-03-03 15:37:32,045] INFO Setting -D jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS renegotiation (org.apache.zookeeper.common.X509Util) [2021-03-03 15:37:32,119] INFO Registered signal handlers for TERM, INT, HUP
(org.apache.kafka.common.utils.LoggingSignalHandler)
[2021-03-03 15:37:32,124] INFO starting (kafka.server.KafkaServer) [2021-03-03 15:37:32,127] INFO Connecting to zookeeper on localhost:2181 (kafka.server.KafkaServer)
[2021-03-03 15:37:32,152] INFO [ZooKeeperClient Kafka server] Initializing a new session to localhost:2181. (kafka.zookeeper.ZooKeeperClient)
[2021-03-03 15:37:32,161] INFO Client environment:zookeeper.version=3.5.8- f439ca583e70862c3068a1f2a7d4d068eec33315, built on 05/04/2020 15:53 GMT (org.apache.zookeeper.ZooKeeper)
[2021-03-03 15:37:32,161] INFO Client environment:host.name=localhost (org.apache.zookeeper.ZooKeeper)
. . .
.
[2021-03-03 15:37:34,587] INFO Kafka version: 2.7.0 (org.apache.kafka.common.utils.AppInfoParser)
[2021-03-03 15:37:34,587] INFO Kafka commitId: 448719dc99a19793 (org.apache.kafka.common.utils.AppInfoParser)
[2021-03-03 15:37:34,587] INFO Kafka startTimeMs: 1614782254579 (org.apache.kafka.common.utils.AppInfoParser)
[2021-03-03 15:37:34,589] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
Jelikož budu dál v práci využívat Kafka GUI přes Docker kontejner, instalace Kafky na mém zařízení slouží pouze pro kontrolní účely, zda vše funguje tak, jak má.
7.3 Instalace a spuštění Dockeru
K dosažení svého cíle využiji Kafka Connect API, ke kterému v současné době existuje nespočet již předem naprogramovaných konektorů. Tento seznam konektorů lze nalézt na stránkách společnosti Confluent. Vzhledem k tomu, že e-shop ukládá svá data v databázi MySQL za využití REST API, použiji ve své práci JDBC source konektor. Pro čtení dat a jejich následný export do databáze PostgreSQL použiji JDBC sink konektor.
Pro výše zmíněný postup jsem využila Docker a pro tuto práci jsem zvolila obraz landoop.
Jedná se o Kafka obraz pro vývojáře, který má v sobě mimo jiné již naimplementované nejznámější konektory pro Kafka Connect API, včetně konektoru pro JDBC databáze. Tyto konektory jsou určeny k pohodlnému připojení k externím systémům pro sběr dat, vyžadují od uživatele pouze konfigurační soubor. Výhodou je také intuitivní GUI, které je užitečné pro přehlednou vizualizaci a vhodné pro začátečníky, aby si udělali představu o tom, jak Kafka funguje.
Software lze stáhnout z oficiální stránky společnosti Docker 10 jak pro macOS, Windows, tak pro Linux. V mém případě jsem zvolila verzi pro macOS. Po instalaci a spuštění programu se v horní liště obrazovky objeví logo Dockeru. Po kliknutí na ikonu lze vidět věta „Docker is running“, což indikuje, že se aplikace v pořádku nainstalovala (viz Obr. 6).
10 https://hub.docker.com/editions/community/docker-ce-desktop-mac/
Obr. 6. Screenshot obrazovky zobrazující stav Dockeru. Zdroj: autor
Nyní je kromě správné instalace nutné zkontrolovat, zda program běží správně. Toho můžeme dosáhnout zadáním následujících příkazů do terminálu. Nejprve jsem spustila příkaz pro kontrolu verze Dockeru. Pokud se zobrazila správně, spustila jsem příkaz pro zjištění verze docker-compose. I zde se musí zobrazit příslušná verze, jinak Docker nefunguje tak, jak má. Pokud oba tyto kroky proběhly v pořádku, použila jsem příkaz na spuštění obrazu hello-world. Výstupem by mělo být uvítání Dockeru, viz Výpis 5.
Výpis 5. Kontrola funkčnosti Dockeru přes příkazový řádek. Zdroj: autor
maiphuong@Karel-MacBook-Pro ~ % docker --version Docker version 20.10.5, build 55c4c88
maiphuong@Karel-MacBook-Pro ~ % docker-compose --version docker-compose version 1.28.5, build c4eb3a1f
maiphuong@Karel-MacBook-Pro ~ % docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
Po ujištění, že je Docker funkční, jsem se pustila do spuštění Kafka Connect UI. Ten, jak už jsem zmínila, je dostupný přes obraz landoop/ fast-data-dev11. Jelikož budu pouštět více obrazů, vytvořila jsem si konfigurační soubor docker-compose.yml, do kterého jsem vložila
11 https://github.com/lensesio/kafka-connect-ui
konfiguraci Kafka clusteru, abych nemusela specifikovat parametry pokaždé, co budu obraz spouštět.
Výpis 6. Ukázka konfiguračního souboru docker-compose.yml
services:
# konfigurace kafka clusteru kafka-cluster:
image: landoop/fast-data-dev:cp3.3.0 environment:
ADV_HOST: 127.0.0.1
RUNTESTS: 0 # Vypnutí running tests, aby se cluster sputil rychleji ports:
- 9092:9092 # Kafka Broker - 3030:3030 # Landoop UI - 2181:2181 # Zookeeper
- 8081-8083:8081-8083 # REST Proxy, Schema Registry, Kafka Connect porty - 9581-9585:9581-9585 # JMX Porty
volumes:
- /Users/maiphuong/code/mysql-connector-java-8.0.23.jar:/opt/confluent- 3.3.0/share/java/kafka-connect-jdbc/mysql-connector-java-8.0.23.jar
Nyní jsem se přesunula v terminálu do adresáře, kde je daný konfigurační soubor uložen a spustila příkaz pro spuštění Kafka clusteru.
Výpis 7. Průběh spuštění Kafka clusteru přes Docker. Ukázka z výpisu kódu. Zdroj: autor
maiphuong@Karel-MacBook-Pro ~ % cd code
maiphuong@Karel-MacBook-Pro code % docker-compose up kafka-cluster Starting code_kafka-cluster_1 ... done
Attaching to code_kafka-cluster_1
kafka-cluster_1 | Setting advertised host to 127.0.0.1.
kafka-cluster_1 | Starting services.
kafka-cluster_1 | This is landoop’s fast-data-dev. Kafka 0.11.0.0, Confluent OSS 3.3.0.
kafka-cluster_1 | You may visit http://127.0.0.1:3030 in about a minute.
. . . .
kafka-cluster_1 | 2021-03-17 16:36:10,931 INFO success: smoke-tests entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
kafka-cluster_1 | 2021-03-17 16:36:10,931 INFO success: connect-distributed entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
