Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

Big Data a Hadoop v enterprise

10. 06. 2014 4 min čtení CORE SYSTEMSdata

„Big Data” — slovní spojení, které v roce 2014 zaznívá na každé konferenci, v každém boardroomu a v každém prodejním pitchi. Jenže mezi marketingovým buzzwordem a reálným nasazením v enterprise prostředí je propast. My jsme ji překročili. Tady je, co jsme se naučili.

Proč vůbec Hadoop?

Náš klient — velká česká pojišťovna — měl problém, který znal dobře: terabajty logů z webových aplikací, transakční data za deset let, call-centre záznamy a data z poboček. Vše leželo v Oracle Data Warehouse, který stál měsíčně víc než celý IT tým. Analytické dotazy běžely hodiny. A noví analytici chtěli pracovat s daty způsobem, na který relační databáze prostě nebyla stavěná.

Apache Hadoop nabídl lákavou alternativu: distribuovaný souborový systém (HDFS) běžící na commodity hardware, výpočetní framework MapReduce pro paralelní zpracování a rostoucí ekosystém nástrojů nad tím vším. Cena za terabajt úložiště: zlomek Oracle licence.

Architektura — jak to vypadá v praxi

Nasadili jsme Cloudera CDH 5 na cluster 12 serverů. Nic exotického — běžné rackové servery s 64 GB RAM, 12 SATA disky a gigabitovou sítí. Celkový raw storage: přibližně 500 TB. Po trojité replikaci HDFS asi 160 TB využitelného prostoru.

# Základní architektura clusteru
NameNode (2x HA)  → metadata, namespace HDFS
DataNode (10x)     → ukládání bloků dat
ResourceManager    → YARN, scheduling MapReduce jobů
Hive Metastore     → SQL-like přístup k datům
Oozie              → orchestrace workflow

Klíčové rozhodnutí bylo použít Hive jako primární analytický nástroj. Analytici uměli SQL — nechtěli a nemuseli psát Java MapReduce joby. HiveQL jim dal známé rozhraní nad neznámou infrastrukturou.

ETL pipeline — data dovnitř

Největší výzvou nebylo zprovoznit Hadoop. Bylo to dostat data z desítek různých zdrojů do HDFS v rozumném formátu. Naše ETL pipeline vypadala takto:

  • Apache Sqoop — import dat z Oracle do HDFS v Avro formátu
  • Flume — real-time ingestion webových logů
  • Custom Java joby — transformace a čištění dat
  • Oozie koordinátor — denní a hodinové workflow

Sqoop import celé tabulky s 200 miliony řádků trval 45 minut. Inkrementální import posledních 24 hodin méně než minutu. Oproti předchozímu ETL v Informatice to byl řádový skok.

Co funguje skvěle

Ad-hoc analytika. Analytik si napíše HiveQL dotaz, odešle ho a za pár minut má výsledek z celé historie dat. Žádné čekání na IT, žádné requestování nových dimenzí v datovém skladu.

Škálovatelnost. Potřebujete víc prostoru? Přidáte DataNode. Hadoop se o rebalancing postará sám. Žádné downtime, žádné migrace. To je luxus, na který jsme u Oracle nebyli zvyklí.

Fault tolerance. Vypadl jeden server z dvanácti. Cluster pokračoval jako by se nic nestalo. Data byla na dalších dvou replikách. Automatický re-replication proběhl na pozadí. U Oracle RAC by to byl noční incident.

Co bolí

Latence. Hadoop není pro interaktivní dotazy. MapReduce job má startup overhead 30–60 sekund. I jednoduchý SELECT COUNT(*) trvá minutu. Pro dashboard v reálném čase to není. Sledujeme Apache Spark a Impala — oba slibují řádový zlepšení, ale zatím jsou příliš čerstvé pro produkci.

Složitost operací. Hadoop cluster není „nastav a zapomeň”. HDFS balancing, YARN tuning, Hive optimalizace, security (Kerberos!) — to vše vyžaduje zkušený ops tým. A těch je v Česku zatím málo.

Java ekosystém. Vše je Java. Classpath hell, verzování JAR souborů, Hadoop verze vs. Hive verze vs. Sqoop verze — dependency management je noční můra. Maven nepomůže, když každá komponenta tahá jinou verzi Guava.

Lekce pro enterprise

Po šesti měsících provozu jsme si odnesli několik klíčových poučení:

  • Hadoop nenahrazuje datový sklad — doplňuje ho. OLTP zůstává v Oracle, cold data a explorace jdou do Hadoopu.
  • Investice do dat governance od začátku se vyplatí. Bez katalogu a lineage se v petabajtech dat ztratíte.
  • Cloudera Manager (nebo Ambari) je nutnost. Ruční správa clusteru je cesta do pekla.
  • Školení analytického týmu je polovina úspěchu. Technologie bez uživatelů je drahý nábytek.
  • Nepodceňujte síťovou infrastrukturu. MapReduce shuffle generuje obrovský síťový provoz.

Čísla, která přesvědčila management

TCO za první rok Hadoop clusteru (hardware + Cloudera licence + interní ops): přibližně třetina ročních nákladů na Oracle DWH. Při trojnásobné kapacitě dat. Analytický tým zpracoval za šest měsíců víc ad-hoc analýz než za předchozí dva roky dohromady. ROI se spočítal sám.

Big Data není jen buzzword

Hadoop v enterprise funguje — ale vyžaduje realistická očekávání, investici do lidí a pragmatický přístup k architektuře. Nenahrazujte Oracle z principu. Používejte Hadoop tam, kde Oracle nestačí. A hlavně: začněte s konkrétním business problémem, ne s technologií.

big datahadoopmapreducehdfsenterprise