Během několika posledních let jsem měl mnoho rozhovorů s přáteli a kolegy frustrovaný s tím, jak nevyzpytatelně komplexní datové infrastruktury, ekosystém je. I když to není tak špatné jako svět front-end, věci se mění dostatečně rychle, aby vytvořily polévku buzzword.

jako začátečník je velmi náročné rozhodnout, jaké nástroje jsou pro vás to pravé. Nadace Apache uvádí 38 projektů v sekci“ velká Data “ a tyto nástroje mají spoustu překrývání problémů, které tvrdí, že řeší. Například Flink, Samza, Storm a Spark Streaming jsou „distributed stream processing engines“, Apex a Beam „unify stream and batch processing“.

v tomto příspěvku doufám, že poskytnu nějakou pomoc při navigaci v možnostech, jak jste se rozhodli vybudovat datovou infrastrukturu. To jsou zhruba kroky, které bych dnes sledoval na základě svých zkušeností za poslední desetiletí a rozhovorů s kolegy pracujícími v tomto prostoru.

Na začátku vašeho projektu, pravděpodobně se vydáte s ničím víc než cíl „získat poznatky z mé údaje“ v ruce. Mapování na konkrétní sadu technologií je velmi skličující. Pravděpodobně nemáte velký smysl pro to, jaké nástroje jsou populární, co znamená“ stream „nebo“ batch“, nebo zda vůbec potřebujete datovou infrastrukturu.

v tomto příspěvku doufám, že poskytnu nějaké pokyny, které vám pomohou rychle se dostat ze země a získat hodnotu z vašich dat. Pevně věřím v udržení věci jednoduché tak dlouho, jak je to možné, zavedení složitost pouze tehdy, když je to nutné pro škálovatelnost. Tento příspěvek sleduje tento oblouk ve třech fázích. V mnoha ohledech opakuje kroky budování datové infrastruktury, které jsem sledoval v posledních několika letech.

Všimněte si, že neexistuje žádný jeden správný způsob, jak architekt datové infrastruktury. Pro odborníky, kteří to čtou, možná jste upřednostňovali alternativy k Zde navrženým řešením. To je fantastické a zdůrazňuje rozmanitost úžasných nástrojů, které dnes máme. Ušli jsme velmi dlouhou cestu od doby, kdy Hadoop MapReduce bylo vše, co jsme měli.

takže tady je věc: pravděpodobně ještě nemáte „velká data“. Téměř o 4 roky později je článek Chrisa Stucchia z roku 2013 nepoužívejte Hadoop stále na místě. Pokud máte méně než 5 TB dat, začněte malý. To vám ušetří provozní bolesti hlavy s údržbou systémů, které ještě nepotřebujete. Ale hej, pokud máte rádi 3am požární cvičení z pracovních neúspěchů, neváhejte a tuto sekci přeskočit…

Jinak, drž se dál od všech buzzword technologií na začátku, a zaměřit se na dvě věci: (1) aby vaše data queryable v SQL, a (2) výběr Nástroje BI. Ty budou páteří „Ahoj, svět“ pro veškerou vaši budoucí datovou infrastrukturu.

vše v SQL

to je opravdu důležité, protože odemkne data pro celou organizaci. Se vzácnými výjimkami pro nejvíce neohrožený marketing, lidi, jste se nikdy přesvědčit, non-technické kolegové naučit Kibana, grep některé protokoly, nebo použijte obskurní syntaxe NoSQL datastore.

Poskytuje SQL umožňuje přístup celé společnosti, aby se stala self-sloužit analytici, již protáhl inženýrství tým z kritické cesty. To také změní každého do volného QA týmu pro vaše data. „Hej, tato čísla vypadají trochu divně…“ je neocenitelná pro nalezení chyb ve vašich datech a dokonce i ve vašem produktu.

pokud je vaším primárním datovým úložištěm relační databáze, jako je PostgreSQL nebo MySQL, je to opravdu jednoduché. Stačí nastavit repliku čtení, přístup k poskytování, a máte vše nastaveno.

S NoSQL databáze jako ElasticSearch, MongoDB, nebo DynamoDB, budete muset udělat více práce, aby převést vaše data a dát je do SQL databáze. Pokud jste ve světě dat nováčkem, říkáme tomu potrubí ETL. Pokud je to možné, vyhněte se tomu sami, protože zapojení off-the-shelf řešení bude mnohem méně nákladné s malými objemy dat. V závislosti na vaší stávající infrastruktuře může existovat segment poskytovatele cloudových ETL, jako je Segment, který můžete využít.

pokud zjistíte, že potřebujete vytvořit vlastní datové potrubí, nejprve je udržujte velmi jednoduché. Napište skript, který pravidelně vypíše aktualizace z databáze a zapíše je někam, kde je lze dotazovat pomocí SQL.

příběh pro ETLing dat ze zdrojů 3rd stran je podobný jako u databází NoSQL. Použijte poskytovatele ETL-as-a-service nebo napsat jednoduchý skript a jen uložit data do databáze SQL-queryable.

nastavte stroj pro spuštění skriptů ETL jako denní cron a jste na závodech.

nástroj BI

dobrý nástroj BI je důležitou součástí porozumění vašim datům. Některé skvělé nástroje, které je třeba zvážit, jsou Chartio, Mode Analytics a Periscope Data-každý z nich by měl fungovat skvěle, aby se vaše analytika dostala ze země. Ve většině případů můžete tyto nástroje nasměrovat přímo do databáze SQL s rychlou konfigurací a ponořit se přímo do vytváření dashboardů.

když to všechno spojíme, tady je „Dobrý den, svět“ datové infrastruktury:

Fáze 1: „Hello, World“ malé datové potrubí

Fáze 2: řekněme, že je to „střední“ data

V tomto bodě, máte více než několik terabajtů plovoucí kolem, a vaše cron+scénář ETL není zcela udržet krok. Možná jste rozšířili datové úložiště a máte heterogenní směs backendů SQL a NoSQL. Nyní můžete mít také několik třetích stran, ze kterých shromažďujete data. Konečně, možná začínáte mít ve svých potrubích ETL více fází s určitými závislostmi mezi kroky.

řízení pracovního postupu & automatizace

vaším prvním krokem v této fázi by mělo být nastavení proudění vzduchu pro správu potrubí ETL. Airflow vám umožní naplánovat úlohy v pravidelných intervalech a vyjádřit Časové i logické závislosti mezi úlohami. Je to také skvělé místo ve vaší infrastruktuře pro přidání opakování úloh, sledování & upozornění na selhání úkolů. Je to běžící vtip, že každý startup nad určitou velikost píše svůj vlastní správce pracovních postupů / Plánovač úloh. Spotify mimo jiné napsal Luigi a Pinterest napsal Pinball. Ty však mají v komunitě menší dynamiku a postrádají některé funkce s ohledem na proudění vzduchu.

budování potrubí ETL

jak vaše podnikání roste, vaše požadavky na potrubí ETL se výrazně změní. Budete muset začít budovat škálovatelnější infrastrukturu, protože jediný skript ji už neřeže. Vaše cíle se také pravděpodobně rozšíří z pouhého povolení přístupu SQL k podpoře dalších navazujících úloh, které zpracovávají stejná data.

nakonec, jednoduché potrubí nebude rozsahu

K řešení těchto měnící se požadavky, budete chtít převést vaše ETL skripty spustit jako distribuované práci v clusteru. Počet možných řešení je zde naprosto ohromující. Důrazně doporučuji začít s Apache Spark. Spark má obrovský, velmi aktivní komunita, váhy dobře, a je poměrně snadné se dostat nahoru a běží rychle. Na AWS, můžete spustit Spark pomocí EMR; pro GCP, pomocí Cloud Dataproc. Pokud přijímáte data z relační databáze, Apache Sqoop je do značné míry standardem.

V tomto bodě, vaše ETL infrastruktury začne vypadat jako pipeline fázích práce, které provádějí tři ETL slovesa: extrahovat data ze zdrojů, transformovat data do standardizovaných formátů na trvalé úložiště, a vložte jej do SQL-queryable datastore.

datový sklad

v této fázi zůstane prioritou získání všech vašich dat do SQL, ale toto je čas, kdy budete chtít začít budovat „skutečný“ datový sklad.

pro ty, kteří právě začínají, bych doporučil používat BigQuery. BigQuery je snadno nastavit (stačí načíst záznamy jako JSON), podporuje vnořené/komplexní datové typy, a je plně spravované/serverless, takže nemusíte mít více infrastruktury zachovat. Stejně jako u mnoha doporučení zde jsou k dispozici alternativy k BigQuery: na AWS, Redshift a on-prem, Presto. Mám silnou preferenci pro BigQuery před Redshift díky svému designu bez serverů, jednoduchosti konfigurace správného zabezpečení/auditu a podpoře složitých typů. Presto stojí za zvážení, pokud máte tvrdý požadavek na on-prem.

Když přemýšlíte o nastavení datového skladu, vhodný vzor je přijmout 2-stage model, kde nezpracované údaje přistál přímo v sadu tabulek, a druhý v práci post-zpracovává tato data do „čistší“ tabulky.

považujte tyto čistší tabulky za příležitost vytvořit kurátorský pohled do vašeho podnikání. Pro každou z klíčových entit ve vaší firmě byste měli vytvořit a upravit tabulku se všemi metrikami / KPI a dimenzemi, které často používáte k analýze této entity. Například tabulka „Uživatelé“ může obsahovat metriky, jako je čas registrace, počet nákupů a rozměry, jako je geografická poloha nebo akviziční kanál.

Na konci toho všeho, vaše infrastruktura by měla vypadat nějak takhle:

Fáze 2: „střední“ data potrubí

🚀 Fáze 3: Jít velký

se správnými základy, další růst nemusí být bolestivý. Často si můžete vystačit jednoduše házením hardwaru na problém s manipulací se zvýšenými objemy dat.

nejnáročnějšími problémy v tomto období jsou často nejen surové měřítko, ale rozšiřující se požadavky. Například možná budete muset podporovat testování A / B, trénovat modely strojového učení nebo transformovat data do clusteru ElasticSearch.

některé věci, které budete chtít zvážit v této fázi:

  • téměř v reálném čase: Pravděpodobně nebudete potřebovat distribuovanou frontu nebo infrastrukturu téměř v reálném čase až mnohem později, než si myslíte. Dodává se s velkou přidanou složitostí pro zvládnutí všech možných režimů selhání,což nestojí za to brzy. Jakmile má návratnost investic smysl, zkuste Kafku nebo Cloud Pub / Sub.
  • Škálovatelnost: S jedním monolitické Jiskra clusteru, téměř jistě budete spouštět do problémů s konflikty prostředků. Když tak učiníte, stojí za to prozkoumat plně elastické klastry jisker s rozsahem práce.
  • Bezpečnost & Audit: V určitém okamžiku možná budete chtít prosadit podrobnější kontroly přístupu k datům datového skladu. Pokud používáte BigQuery, můžete poskytnout datový soubor přístup ke skupinám Google, a programově spravovat tento přístup pomocí Správce nasazení. BigQuery také poskytuje protokoly auditu k pochopení uživatelských dotazů. Další nástroje jako Apache Knox a Apache Sentry jsou k dispozici pro bezpečnostní řešení on-prem.
  • A/B testování: pro budování in-house A/B testování a podporu experimentování, tam bohužel není mnoho off-the-shelf řešení. Budování potrubí Jiskrových úloh, které naplňují tabulky ve vašem datovém skladu, je pravděpodobně vaše nejlepší sázka.
  • strojové učení: pro extrakci funkcí můžete v Spark vytvářet další datové potrubí. U samotných modelů byste měli znovu začít v malém. Zpracované prvky jsou pravděpodobně dostatečně malé, aby se vešly na jeden stroj, takže můžete trénovat modely pomocí scikit-learn nebo TensorFlow. Když jeden stroj již nestačí, můžete použít Spark MLlib nebo distribuovaný TensorFlow.

budoucnost

je vzrušující vidět, jak moc se ekosystém datové infrastruktury za poslední desetiletí zlepšil. Ušli jsme dlouhou cestu od hlídání Hadoop clusterů a gymnastiky, abychom donutili naši logiku zpracování dat do map a zmenšili se v nepříjemné Javě. Tehdy se budování datové infrastruktury cítilo jako pokus o stavbu mrakodrapu pomocí kladiva na hračky.

dnes máme úžasnou rozmanitost nástrojů. Spark jasně dominoval jako náhrada jack-of-all-trades na Hadoop MapReduce; totéž se začíná dít s TensorFlow jako platformou strojového učení. Až na velmi málo výjimek nemusíte v těchto dnech budovat infrastrukturu nebo nástroje od nuly a pravděpodobně nemusíte spravovat fyzické servery. Mrakodrap je již tam, stačí si vybrat barvy barvy.

na serverless budoucnosti — bude to zcela být jako je tato,

při Pohledu do budoucna, jsem se očekávat, že datové infrastruktury a nástroje, aby i nadále pohybovat směrem zcela serverless platformy — DataBricks právě oznámila, taková nabídka pro Jiskru. Serverless infrastruktury, která umožňuje elegantní oddělení zájmy: cloud poskytovatelé mohou starat o hardware, devops, a nástroje, který umožňuje inženýrům soustředit se na problémy, které jsou jedinečné (a v souladu s ním) své firmy. Budoucnost je bez selhání hardwaru, Zookeeper freakouts, nebo problémy s tvrzením o zdrojích příze, a to je opravdu skvělé.

upravit: přidání odkazů na některé předchozí příspěvky, které jsem psal o datové infrastruktuře Thumbtack:

Napsat komentář

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

lg