Big data-probleem
De volumes aan big data groeien exponentieel. Dit fenomeen doet zich al jaren voor, maar het tempo is sinds 2012 enorm versneld. Bekijk deze blog met de titel Big Data Just Beginning to Explode van CSC voor een vergelijkbare kijk op de opkomst van big data en de uitdagingen die daarmee samenhangen.
IRI is zich bewust van deze trend sinds de oprichting van het bedrijf eind jaren zeventig. Het vlaggenschip CoSort-pakket is ontworpen om groeiende gegevensvolumes aan te kunnen door efficiëntieverbeteringen in software-algoritmen en -ontwerp, "draagbare" hardware-exploitatietechnieken en taakconsolidatie (bijv. sort-join-aggregate-encrypt-report). De vraag die dit artikel stelt, is er een van benadering, gezien de "opkomst van de machines".
Hardware's beperking bij het oplossen ervan
Zeker, de computerprestaties zijn in bijna elk opzicht al tientallen jaren aan het versnellen. En voor velen is het een tweede natuur om hardware op het big data-probleem te gooien. Het probleem kan echter groter zijn dan dat. Overweeg de wet van Moore, waarin de CPU-kracht slechts verdubbelt in het beste geval elke 18 maanden, en de inherente veroudering, onderhoudsproblemen en pure kosten van een hardwaregerichte strategie.
Iets nieuws om te overwegen is ook de verwachting dat dit prestatieparadigma voor big data ten einde loopt. Volgens Gery Menegaz is zijn uitgangspunt dat het einde van de wet van Moore nabij is. Time Magazine publiceerde in mei 2012 een soortgelijk verhaal met de titel The Collapse of Moore's Law:Physicist Says Its Al Happening. Volgens het Time-artikel,
Gezien dat, zegt Kaku dat wanneer de wet van Moore aan het einde van het volgende decennium eindelijk instort, we "het gewoon een beetje zullen aanpassen met chipachtige computers in drie dimensies". Verder zegt hij:"Misschien moeten we naar moleculaire computers gaan en misschien laat in de 21e-eeuwse kwantumcomputers."
Voor de meeste gebruikers wordt hun hardware echter gekocht om te kunnen omgaan met, en tot op zekere hoogte te schalen, om de uitdagingen op het gebied van big dataverwerking aan te gaan waarmee ze worden geconfronteerd of die ze voorzien. Maar hoe minder efficiënt de software die erop draait presteert, des te meer hardwarebronnen moeten worden besteed om de inefficiëntie te overwinnen. Een voorbeeld in onze wereld zou kunnen zijn het kopen van een IBM p595 om /bin/sort uit te voeren, terwijl een machine van een derde van die grootte en kosten waarop CoSort draait hetzelfde resultaat zou opleveren.
Ondertussen vereisen DB- en ELT-appliances zoals Exadata en Netezza die rond hardware zijn gebouwd, al investeringen van 6-7 cijfers. En hoewel ze kunnen schalen om grotere ladingen aan te kunnen, is er meestal een limiet aan hoeveel ze kunnen schalen (zeker niet exponentieel), hoeveel geld kan worden uitgegeven aan pogingen om te blijven schalen en hoe bereid mensen zijn om te vertrouwen op een één enkele leverancier voor elk bedrijfskritisch aspect van hun workloads. En is het een goed idee om de overhead van big data-transformatie op te leggen in databases die in plaats daarvan zijn ontworpen voor optimalisatie van opslag en ophalen (query's)?
Zelfs als al die vragen gemakkelijke antwoorden hadden, hoe worden rekenproblemen (met zelfs maar lineair schalen van big data-groei) die een exponentieel groter verbruik van hulpbronnen vereisen (zoals sorteren) opgelost? Op de een of andere manier lijkt het antwoord niet te liggen in het wachten op betaalbare kwantumcomputers …
De rol van software
Zoals Hadoop en datawarehouse-architecten weten, vormt sorteren — en de samenvoeg-, aggregatie- en laadbewerkingen in ETL die afhankelijk zijn van sorteren — de kern van de uitdaging van big dataverwerking, en een exponentiële consument van computerbronnen. Naarmate big data verdubbelt, kunnen de resourcevereisten om het te sorteren verdrievoudigen. Daarom zijn de algoritmen, technieken voor hardware-exploitatie en verwerkingsschema's die betrokken zijn bij multi-platform, multi-core sorteersoftware de sleutels om dit probleem op schaalbare, betaalbare en efficiënte manieren te beheren.
De bijdrage van CoSort
De prestaties van CoSort schalen lineair in volume, meer in de trant van de wet van Amdahl. Terwijl CoSort honderden gigabytes aan big data kan transformeren in minuten met enkele tientallen cores, kunnen andere tools meer dan twee keer zo lang duren, lang niet zo goed schalen en/of meer geheugen en I/O verbruiken in het proces. Wat misschien nog belangrijker is, CoSort integreert sorteren rechtstreeks in gerelateerde applicaties en doet al het zware werk buiten de DB- en BI-laag, waar het verzamelen van gegevens minder efficiënt zou zijn.
De co-routinearchitectuur van CoSort verplaatst records tussen de sorteerder en programma's zoals SortCL (CoSort's hulpprogramma voor gegevenstransformatie, filtering, opzoeken, rapportage, migratie en bescherming) interactief door het geheugen. Dus zodra het volgende gesorteerde record beschikbaar is, kan het naar de applicatie gaan, laden, enz. Het lijkt erop dat de app een invoerbestand leest, maar in werkelijkheid is de back-end van de bron nog niet geproduceerd. En nee, u loopt niet voor op de sorteerder.
Eind 2015 werd CoSort ook de motor in Voracity, het moderne platform voor big data-beheer en -manipulatie van IRI. Voracity maakt naadloos gebruik van zowel CoSort- als Hadoop-engines.
Conclusie
Fysieke computerbronnen alleen kunnen niet worden gerekend om op te schalen naar het probleem van het verwerken van big data. De CoSort-softwareomgeving is er een waarin de vereiste big data-transformatie en gerelateerde taken niet als op zichzelf staande processen worden uitgevoerd, maar parallel worden uitgevoerd tijdens dezelfde I/O-doorgang.
Dus als je een snelle sortering nodig hebt voor een ander doel dan alleen de tijd om te sorteren, moet je nadenken over wat er stroomafwaarts van de sortering gebeurt, en de beste manieren om dergelijke processen aan elkaar te koppelen. En als u eenmaal het beste runtime-paradigma hebt bepaald, kunt u dan hoogwaardige hardware combineren met dergelijke software om de prestaties te optimaliseren? Kun je DW-gegevens met CoSort bijvoorbeeld in de databaseserverkant van Exadata stagen? Of zou het logischer zijn om uw IBM p595 te behouden en CoSort toe te voegen aan een driedubbele doorvoer? Of als je van plan bent Hadoop te gebruiken, overweeg dan om dezelfde eenvoudige 4GL van CoSort of intuïtieve ETL-toewijzingen van Voracity te gebruiken om MapReduce 2-, Spark-, Storm- of Tez-taken aan te sturen.
Laat uw budget en uw verbeeldingskracht uw gids zijn bij het aanpakken van gegevensgroei.