Big Data-problem
Mængden af store data vokser eksponentielt. Dette fænomen har fundet sted i årevis, men dets tempo er accelereret dramatisk siden 2012. Tjek denne blog med titlen Big Data Just Beginning to Explode fra CSC for et lignende syn på fremkomsten af big data og de udfordringer, der er forbundet hermed.
IRI har været opmærksom på denne tendens siden virksomhedens grundlæggelse i slutningen af 1970'erne. Dens flagskib CoSort-pakke er designet til at håndtere voksende datamængder gennem effektivitet i softwarealgoritmer og design, "bærbare" hardwareudnyttelsesteknikker og opgavekonsolidering (f.eks. sort-join-aggregate-encrypt-report). Spørgsmålet, som denne artikel stiller, er en tilgang, givet "maskinernes opståen."
Hardwares begrænsning i at løse det
Computerens ydeevne har bestemt været accelereret i næsten alle henseender i årtier. Og for mange er det kun en anden natur at kaste hardware efter big data-problemet. Problemet kan dog være større end som så. Overvej Moores lov, hvor CPU-kraften kun fordobles i bedste fald hver 18. måned og den iboende forældelse, vedligeholdelsesproblemer og rene omkostninger ved en hardware-centreret strategi.
Noget nyt at overveje også er en forventning om, at dette præstationsparadigme for big data kan være ved at være slut. Ifølge Gery Menegaz er hans præmis, at afslutningen på Moores lov er nær. Time Magazine bragte en lignende historie i maj 2012 med titlen Collapse of Moore's Law: Physicist Says Its Everything Happening. Ifølge Time-artiklen,
I betragtning af det siger Kaku, at når Moores lov endelig kollapser ved udgangen af det næste årti, vil vi "simpelthen justere [det] lidt med chiplignende computere i tre dimensioner." Ud over det siger han "vi bliver muligvis nødt til at gå til molekylære computere og måske sent i det 21. århundrede kvantecomputere."
For de fleste brugere er deres hardware dog købt for at håndtere og til en vis grad skalere for at imødekomme de store databehandlingsudfordringer, de står over for eller forudser. Men jo mindre effektivt den software, der kører på den, yder, jo flere hardwareressourcer skal der bruges på at overvinde ineffektiviteten. Et eksempel i vores verden kan være at købe en IBM p595 for at køre /bin/sort, når en maskine, der er en tredjedel af den størrelse og koster at køre CoSort i stedet ville give det samme resultat.
I mellemtiden kræver DB- og ELT-apparater som Exadata og Netezza bygget op omkring hardware allerede investeringer på 6-7 tal. Og selv om de kan skalere til at påtage sig større belastninger, er der normalt en grænse for, hvor meget de kan skalere (bestemt ikke eksponentielt), hvor mange penge der kan bruges på forsøget på at blive ved med at skalere, og hvor villige folk er til at stole på en enkelt leverandør for hvert missionskritiske aspekt af deres arbejdsbelastninger. Og er det en god idé at pålægge overhead af big data-transformation i databaser, der er designet til lagring og genfinding (forespørgsels) optimering i stedet?
Selv hvis alle disse spørgsmål havde nemme svar, hvordan løses beregningsproblemer (med blot lineært skalering af big data-vækst), der kræver eksponentielt større ressourceforbrug (som sortering), ? På en eller anden måde ser svaret ikke ud til at ligge i blot at vente på overkommelig kvanteberegning …
Softwarens rolle
Som Hadoop- og datavarehusarkitekter ved, er sortering - og sammenføjnings-, aggregerings- og indlæsningsoperationerne i ETL, der er afhængige af sortering - kernen i den store databehandlingsudfordring og en eksponentiel forbruger af computerressourcer. Efterhånden som big data fordobles, kan ressourcekravene til at sortere dem tredobles. Derfor er algoritmerne, hardwareudnyttelsesteknikkerne og behandlingsskemaerne involveret i multi-platform multi-core sorteringssoftware nøglerne til at håndtere dette problem på skalerbare, overkommelige og effektive måder.
CoSorts bidrag
CoSorts ydeevne skaleres lineært i volumen, mere i overensstemmelse med Amdahls lov. Mens CoSort kan transformere hundredvis af gigabyte big data på få minutter med et par dusin kerner, kan andre værktøjer tage mere end dobbelt så lang tid, skaleres ikke nær så godt og/eller forbruge mere hukommelse og I/O i processen. Måske endnu vigtigere, CoSort integrerer sortering direkte i relaterede applikationer og udfører alle sine tunge løft uden for DB- og BI-laget, hvor iscenesættelse af data ville være mindre effektiv.
CoSorts co-rutine-arkitektur flytter poster mellem sortereren og programmer som SortCL (CoSorts datatransformation, filtrering, opslag, rapportering, migration og beskyttelsesværktøj) interaktivt gennem hukommelsen. Så snart den næste sorterede post er tilgængelig, kan den flytte ind i applikationen, indlæse osv. Det ser ud til, at appen læser en inputfil, men i virkeligheden er bagenden af kilden endnu ikke blevet produceret. Og nej, du kommer ikke foran sortereren.
I slutningen af 2015 blev CoSort også motoren i IRIs moderne big data management- og manipulationsplatform, Voracity. Voracity udnytter både CoSort- eller Hadoop-motorer problemfrit.
Konklusion
Fysiske computerressourcer alene kan ikke regne med at skalere op til problemet med at behandle big data. CoSort-softwaremiljøet er et, hvor påkrævet big data-transformation og relaterede jobs ikke kører som selvstændige processer, men parallelt under samme I/O-passage.
Så hvis du har brug for en hurtig sortering til et andet formål end blot tiden til at sortere, bør du tænke på, hvad der sker nedstrøms fra sorteringen, og de bedste måder at forbinde sådanne processer sammen. Og når du først har fundet det bedste runtime-paradigme, kan du så kombinere højtydende hardware med sådan software for at optimere ydeevnen? Kan du f.eks. iscenesætte DW-data med CoSort i databaseserversiden af Exadata? Eller ville det give mere mening at beholde din IBM p595 og tilføje CoSort til tredobbelt gennemløb? Eller hvis du har til hensigt at bruge Hadoop, kan du overveje at bruge den samme simple 4GL af CoSort eller intuitive ETL-kortlægninger af Voracity til at drive MapReduce 2-, Spark-, Storm- eller Tez-job.
Lad dit budget og din fantasi være dine guider til at tackle datavækst.