Big Data Problem
Big datavolymer växer exponentiellt. Det här fenomenet har funnits i flera år, men takten har ökat dramatiskt sedan 2012. Kolla in den här bloggen med titeln Big Data Just Beginning to Explode från CSC för en liknande syn på framväxten av big data och de utmaningar som är relaterade till detta.
IRI har varit medveten om denna trend sedan företaget grundades i slutet av 1970-talet. Dess flaggskepp CoSort-paket är utformat för att hantera växande datavolymer genom effektivitetsvinster i mjukvarualgoritmer och design, "portabel" teknik för hårdvaruexploatering och uppgiftskonsolidering (t.ex. sort-join-aggregate-encrypt-report). Frågan som den här artikeln ställer är ett tillvägagångssätt, med tanke på "maskinernas framväxt."
Hårdvarans begränsning när det gäller att lösa det
Visst har datorprestanda accelererat i nästan alla avseenden i årtionden. Och för många är det bara en annan natur att kasta hårdvara på big data-problemet. Problemet kan dock vara större än så. Tänk på Moores lag, där CPU-kraften bara fördubblas i bästa fall var 18:e månad, och den inneboende inkuransen, underhållsproblemen och de rena kostnaderna för en hårdvarucentrerad strategi.
Något nytt att tänka på är också en förväntning om att detta prestandaparadigm för big data kan vara på väg att ta slut. Enligt Gery Menegaz är hans utgångspunkt att slutet på Moores lag är nära. Time Magazine publicerade en liknande berättelse i maj 2012 med titeln Collapse of Moore's Law: Physicist Says Its Its Everything Happening. Enligt Time-artikeln,
Med tanke på det säger Kaku att när Moores lag äntligen kollapsar i slutet av nästa decennium kommer vi "helt enkelt att justera [det] lite med chipliknande datorer i tre dimensioner." Utöver det säger han "vi kanske måste gå till molekylära datorer och kanske sent på 2000-talets kvantdatorer."
För de flesta användare är deras hårdvara dock köpt för att hantera, och i viss mån skala, för att möta de stora databearbetningsutmaningar de står inför eller förutser. Men ju mindre effektivt programvaran som körs på den fungerar, desto mer hårdvaruresurser måste spenderas för att övervinna ineffektiviteten. Ett exempel i vår värld kan vara att köpa en IBM p595 för att köra /bin/sort när en maskin som är en tredjedel av den storleken och kostar att köra CoSort istället skulle ge samma resultat.
Samtidigt kräver DB- och ELT-apparater som Exadata och Netezza byggda kring hårdvara redan investeringar på 6-7 siffror. Och även om de kan skala för att ta på sig större belastningar, finns det vanligtvis en gräns för hur mycket de kan skala (absolut inte exponentiellt), hur mycket pengar som kan spenderas på försöket att fortsätta skala och hur villiga människor är att förlita sig på en enda leverantör för varje uppdragskritisk aspekt av deras arbetsbelastning. Och är det en bra idé att lägga på overheaden för big data-transformation i databaser som utformats för lagring och hämtning (frågeoptimering) istället?
Även om alla dessa frågor hade enkla svar, hur löses beräkningsproblem (med enbart linjär skalning av big data-tillväxt) som kräver exponentiellt större resursförbrukning (som sortering) ? På något sätt verkar svaret inte ligga i att bara vänta på prisvärd kvantberäkning …
Mjukvarans roll
Som Hadoop och datalagerarkitekter vet är sortering — och sammanfognings-, aggregerings- och laddningsoperationerna i ETL som är beroende av sortering — kärnan i utmaningen för big data-bearbetning, och en exponentiell konsument av datorresurser. När big data fördubblas kan resurskraven för att sortera den tredubblas. Därför är algoritmerna, teknikerna för hårdvaruexploatering och bearbetningsscheman som är involverade i multiplattformssorteringsprogramvara med flera kärnor nyckeln till att hantera detta problem på skalbara, prisvärda och effektiva sätt.
CoSorts bidrag
CoSorts prestanda skalar linjärt i volym, mer i linje med Amdahls lag. Medan CoSort kan omvandla hundratals gigabyte big data på några minuter med några dussin kärnor, kan andra verktyg ta mer än dubbelt så lång tid, skalas inte lika bra och/eller förbruka mer minne och I/O i processen. Kanske ännu viktigare, CoSort integrerar sortering direkt i relaterade applikationer och gör alla sina tunga lyft utanför DB- och BI-lagret där iscensättningsdata skulle vara mindre effektivt.
CoSorts samrutinarkitektur flyttar poster mellan sorteraren och program som SortCL (CoSorts datatransformation, filtrering, uppslagning, rapportering, migrering och skyddsverktyg) interaktivt genom minnet. Så snart nästa sorterade post är tillgänglig kan den flytta in i applikationen, ladda, etc. Det ser ut som om den läser en indatafil, men i själva verket har den bakre delen av källan ännu inte producerats. Och nej, du kommer inte före sorteraren.
I slutet av 2015 blev CoSort även motorn i IRI:s moderna plattform för hantering och manipulation av big data, Voracity. Voracity utnyttjar både CoSort- och Hadoop-motorer sömlöst.
Slutsats
Enbart fysiska datorresurser kan inte räknas med för att skala upp till problemet med att bearbeta big data. CoSort-mjukvarumiljön är en där nödvändig big data-transformation och relaterade jobb körs inte som fristående processer, utan parallellt under samma I/O-pass.
Så om du behöver en snabb sortering för något annat syfte än bara tiden att sortera, bör du fundera på vad som händer nedströms från sorteringen, och de bästa sätten att länka samman sådana processer. Och när du väl har bestämt det bästa runtime-paradigmet, kan du då kombinera högpresterande hårdvara med sådan mjukvara för att optimera prestandan? Kan du iscensätta DW-data med CoSort i till exempel databasserversidan av Exadata? Eller skulle det vara mer meningsfullt att behålla din IBM p595 och lägga till CoSort till tredubbla genomströmningen? Eller om du har för avsikt att använda Hadoop, överväg att använda samma enkla 4GL av CoSort eller intuitiva ETL-mappningar av Voracity för att driva MapReduce 2-, Spark-, Storm- eller Tez-jobb.
Låt din budget och din fantasi vara dina guider för att hantera datatillväxt.