De Moderne Datalake er et halvt datavarehus og en halv datasø og bruger objektlagring til alt. Brugen af objektlager til at bygge et datavarehus er muliggjort af Open Table Formats (OTF'er) som Apache Iceberg, Apache Hudi og Delta Lake, som er specifikationer, der, når de er implementeret, gør det problemfrit for objektlagring at blive brugt som underliggende lagringsløsning til et datavarehus. Disse specifikationer giver også funktioner, der muligvis ikke findes i et konventionelt datavarehus - for eksempel snapshots (også kendt som tidsrejser), skemaudvikling, partitioner, partitionsudvikling og nulkopi-forgrening.

Mens organisationer bygger Moderne Datalakes, er her nogle af de nøglefaktorer, vi mener, de bør overveje:

1. Disaggregering af databehandling og lagring
2. Migration fra monolitiske rammer til best-of-breed rammer
3. Datacenterkonsolidering - udskift afdelingsløsninger med en enkelt virksomhedsløsning
4. Problemfri ydeevne på tværs af små og store filer/objekter
5. Softwaredefinerede, cloud-native løsninger, der skaleres horisontalt

Dette papir taler om stigningen og faldet af Hadoop HDFS, og hvorfor højtydende objektlagring er en naturlig efterfølger i big data-verdenen.

Adoption af Hadoop

Med udvidelsen af internetapplikationer startede de første store datalagrings- og aggregeringsudfordringer for avancerede teknologivirksomheder for 15 år siden. Traditionelt RDBMS (Relational Database Management System) kunne ikke skaleres til at nærme sig store mængder data. Så kom Hadoop, en meget skalerbar model. I Hadoop-modellen er en stor mængde data opdelt i flere billige maskiner i en klynge, som derefter behandles parallelt. Antallet af disse maskiner eller noder kan øges eller reduceres i henhold til virksomhedens krav.

Hadoop var open source og brugte omkostningseffektiv råvarehardware, som gav en omkostningseffektiv model i modsætning til traditionelle relationelle databaser, som kræver dyr hardware og avancerede processorer for at håndtere big data. Fordi det var så dyrt at skalere i RDBMS-modellen, begyndte virksomheder at fjerne de rå data. Dette førte til suboptimale resultater på tværs af en række vektorer.

I denne henseende gav Hadoop en betydelig fordel i forhold til RDBMS-tilgangen. Det var mere skalerbart ud fra et omkostningsperspektiv uden at ofre ydeevnen.

Slutningen af Hadoop

Fremkomsten af nyere teknologier som change data capture (CDC) og streaming data, primært genereret fra sociale medievirksomheder som Twitter og Facebook, ændrede, hvordan data indtages og opbevares. Dette udløste udfordringer med at behandle og forbruge disse endnu større mængder data.

En vigtig udfordring var batchbehandling. Batch-processer kører i baggrunden og interagerer ikke med brugeren. Hadoop var effektiv med batchbehandling, når det kom til meget store filer, men led med mindre filer - både fra et effektivitetsperspektiv såvel som et latensperspektiv - hvilket effektivt gjorde det forældet, da virksomheder søgte efter behandlings- og forbrugsrammer, der kunne indtage forskellige datasæt store og lille i batch, CDC og realtid.

At adskille computer og lagring giver simpelthen mening i dag. Lagerplads skal overskride beregningen med så meget som ti til én. Dette er meget ineffektivt i Hadoop-verdenen, hvor du har brug for én computernode for hver lagerknude. At adskille dem betyder, at de kan indstilles individuelt. Compute noderne er statsløse og kan optimeres med flere CPU-kerner og hukommelse. Lagerknuderne er stateful og kan I/O-optimeres med et større antal tættere drev og højere båndbredde.

Ved at opdele kan virksomheder opnå overlegen økonomi, bedre håndterbarhed, forbedret skalerbarhed og øgede samlede ejeromkostninger.

HDFS kan ikke foretage denne overgang. Når du forlader datalokalitet, bliver Hadoop HDFS's styrke dens svaghed. Hadoop blev designet til MapReduce computing, hvor data og compute skulle placeres sammen. Som følge heraf har Hadoop brug for sin egen jobplanlægger, ressourcemanager, storage og computer. Dette er grundlæggende uforeneligt med container-baserede arkitekturer, hvor alt er elastisk, let og multi-lejer.

I modsætning hertil er MinIO født cloud-native og er designet til containere og orkestrering via Kubernetes, hvilket gør den til den ideelle teknologi at gå over til, når man trækker gamle HDFS-instanser tilbage.

Dette har givet anledning til Modern Datalake. Det drager fordel af at bruge råvare-hardware-tilgangen, der er arvet fra Hadoop, men opdeler lagring og databehandling - og ændrer derved, hvordan data behandles, analyseres og forbruges.

Opbygning af en moderne datasø med MinIO

MinIO er et højtydende objektlagringssystem, der blev bygget fra bunden for at være skalerbart og cloud-native. Holdet, der byggede MinIO, byggede også et af de mest succesrige filsystemer, GlusterFS, før de udviklede deres tanker om opbevaring. Deres dybe forståelse af filsystemer og hvilke processer, der var dyre eller ineffektive, informerede MinIOs arkitektur og leverede ydeevne og enkelhed i processen.

Minio bruger slettekodning og giver et bedre sæt algoritmer til at styre lagereffektivitet og give modstandsdygtighed. Typisk er det 1,5 gange kopi, i modsætning til 3 gange i Hadoop-klynger. Dette alene giver allerede lagereffektivitet og reducerer omkostningerne sammenlignet med Hadoop.

Fra starten var MinIO designet til cloud-driftsmodellen. Som følge heraf kører den på enhver sky – offentlig, privat, on-prem, bare metal og edge. Dette gør den ideel til multi-cloud og hybrid-cloud implementeringer. Med en hybrid konfiguration muliggør MinIO migrering af dataanalyse og datavidenskabelige arbejdsbelastninger i overensstemmelse med tilgange som f.eks. Strangler Fig mønster populariseret af Martin Fowler.

Nedenfor er flere andre grunde til, hvorfor MinIO er den grundlæggende byggeklods for en Modern Datalake, der er i stand til at understøtte din IA-datainfrastruktur såvel som andre analytiske arbejdsbelastninger såsom business intelligence, dataanalyse og datavidenskab.

Moderne data klar

Hadoop blev specialbygget til data, hvor "ustrukturerede data" betyder store (GiB til TiB-størrelse) logfiler. Når det bruges som en generel lagringsplatform, hvor ægte ustrukturerede data er i spil, forringer udbredelsen af små objekter (KB til MB) Hadoop HDFS i høj grad, da navneknuderne aldrig blev designet til at skalere på denne måde. MinIO udmærker sig ved enhver fil-/objektstørrelse (8KiB til 5TiB).

Open Source

De virksomheder, der adopterede Hadoop, gjorde det ud fra en præference for open source-teknologier. Evnen til at inspicere, friheden fra fastlåsning og komforten, der kommer fra titusindvis af brugere, har reel værdi. MinIO er også 100 % open source, hvilket sikrer, at organisationer kan forblive tro mod deres mål, mens de opgraderer deres oplevelse.

Enkel

Enkelhed er svært. Det kræver arbejde, disciplin og frem for alt engagement. MinIOs enkelhed er legendarisk og er resultatet af en filosofisk forpligtelse til at gøre vores software nem at implementere, bruge, opgradere og skalere. Selv Hadoops fans vil fortælle dig, at det er komplekst. For at gøre mere med mindre skal du migrere til MinIO.

Optrædende

Hadoop blev fremtrædende på grund af dets evne til at levere big data-ydeevne. De var i det meste af et årti benchmark for analyse af virksomhedskvalitet. Ikke længere. MinIO har bevist i flere benchmarks at det er materielt hurtigere end Hadoop. Dette betyder bedre ydeevne for din Modern Datalake.

Letvægts

MinIOs serverbinære er hele <100MB. På trods af sin størrelse er den kraftig nok til at køre datacentret, men stadig lille nok til at leve komfortabelt på kanten. Der er ikke noget sådant alternativ i Hadoop-verdenen. Hvad det betyder for virksomheder er, at dine S3-applikationer kan få adgang til data hvor som helst, når som helst og med den samme API. Ved at implementere MinIO til en kantplacering kan du fange og filtrere data ved kanten og bruge MinIOs replikeringsfunktioner til at sende dem til din Modern Datalake for aggregering og yderligere analyser.

Elastisk

MinIO beskytter data med per-objekt, inline sletningskodning, hvilket er langt mere effektivt end HDFS-alternativer, der kom efter replikering og aldrig blev vedtaget. Derudover sikrer MinIO's bitrot-detektion, at den aldrig vil læse korrupte data - indfange og helbrede beskadigede objekter i farten. MinIO understøtter også aktiv-aktiv replikering på tværs af regioner. Endelig understøtter MinIO en komplet objektlåsende ramme, der tilbyder både juridisk hold og tilbageholdelse (med styrings- og overholdelsestilstande).

Software defineret

Hadoop HDFS' efterfølger er ikke et hardwareapparat; det er software, der kører på råvarehardware. Det er, hvad MinIO er - software. Ligesom Hadoop HDFS er MinIO designet til at drage fuld fordel af råvareservere. Med evnen til at udnytte NVMe-drev og 100 GbE-netværk kan MinIO krympe datacentret – hvilket forbedrer driftseffektiviteten og håndterbarheden.

Sikker

MinIO understøtter flere, sofistikerede server-side krypteringssystemer for at beskytte data - uanset hvor de måtte være - under flyvning eller i hvile. MinIOs tilgang sikrer fortrolighed, integritet og autenticitet med ubetydelig ydeevne. Server- og klientsidekryptering understøttes ved hjælp af AES-256-GCM, ChaCha20-Poly1305 og AES-CBC, hvilket sikrer applikationskompatibilitet. Ydermere understøtter MinIO brancheførende nøglestyringssystemer (KMS).

Migrerer fra Hadoop til MinIO

MinIO-teamet har ekspertise i at migrere fra HDFS til MinIO. Kunder, der køber en Enterprise-licens, kan få hjælp fra vores ingeniører. For at lære mere om at bruge MinIO til at erstatte HDFS, tjek ud denne samling af ressourcer .

Konklusion

Enhver virksomhed er en datavirksomhed på dette tidspunkt. Lagringen af disse data og den efterfølgende analyse skal være problemfri, skalerbar, sikker og effektiv. De analytiske værktøjer, der er affødt af Hadoop-økosystemet, som Spark, er mere effektive og effektive, når de parres med objektlagringsbaserede datasøer. Teknologier som Flink forbedrer den overordnede ydeevne, da den giver en enkelt kørselstid for streaming samt batchbehandling, der ikke fungerede godt i HDFS-modellen. Frameworks som Apache Arrow omdefinerer, hvordan data lagres og behandles, og Iceberg og Hudi omdefinerer, hvordan tabelformater giver mulighed for effektiv forespørgsel efter data.

Disse teknologier kræver alle en moderne, objektlagringsbaseret datasø, hvor databehandling og lagring er adskilt og arbejdsbelastningsoptimeret. Hvis du har spørgsmål, mens du bygger din egen moderne datasø, er du velkommen til at kontakte os på [email protected] eller på vores Slap kanal.