Проблем с големи данни
Обемът на големите данни нараства експоненциално. Това явление се случва от години, но темпът му се ускори драстично от 2012 г. Разгледайте този блог, озаглавен Big Data Just Beginning to Explode от CSC за подобна гледна точка относно появата на големи данни и свързаните с тях предизвикателства.
IRI е наясно с тази тенденция от основаването на компанията в края на 70-те години. Неговият водещ пакет CoSort е проектиран да обработва нарастващи обеми данни чрез ефективност в софтуерните алгоритми и дизайн, „преносими“ техники за използване на хардуер и консолидиране на задачи (например сортиране-присъединяване-агрегат-криптиране-отчет). Въпросът, който тази статия поставя, е подход, като се има предвид „възходът на машините“.
Ограничение на хардуера при решаването му
Със сигурност производителността на компютъра се ускорява във всяко едно отношение от десетилетия. И за мнозина хвърлянето на хардуер към проблема с големите данни е просто втора природа. Проблемът обаче може да е по-голям от това. Помислете за закона на Мур, според който мощността на процесора само удвоява в най-добрия случай на всеки 18 месеца и присъщата остаряване, проблеми с поддръжката и чисти разходи на хардуерно ориентирана стратегия.
Нещо ново, което също трябва да се вземе предвид, е очакването, че тази парадигма за производителност за големи данни може да е към своя край. Според Гери Менегас, неговата предпоставка е, че краят на закона на Мур е близо. Списание Time публикува подобна история през май 2012 г., озаглавена Крахът на закона на Мур: Физик казва, че това вече се случва. Според статията на Time,
Като се има предвид това, Каку казва, че когато законът на Мур най-накрая рухне до края на следващото десетилетие, ние „просто ще го настроим малко с компютри, подобни на чип в три измерения“. Освен това той казва, че „може да се наложи да отидем до молекулярните компютри и може би в края на 21-ви век квантовите компютри.
За повечето потребители обаче техният хардуер се купува, за да се справя и до известна степен да мащабира, за да отговори на предизвикателствата при обработката на големи данни, пред които са изправени или предвиждат. Но колкото по-малко ефективно работи софтуерът, работещ върху него, толкова повече хардуерни ресурси трябва да бъдат изразходвани за преодоляване на неефективността. Пример в нашия свят може да бъде закупуването на IBM p595 за стартиране на /bin/sort, когато машина с една трета от този размер и цена, изпълняваща CoSort вместо това, ще даде същия резултат.
Междувременно, DB и ELT уреди като Exadata и Netezza, изградени около хардуер, вече изискват инвестиции от 6-7 цифри. И докато те могат да мащабират, за да поемат по-големи натоварвания, обикновено има ограничение за това колко могат да мащабират (със сигурност не експоненциално), колко пари могат да бъдат изразходвани за опита да продължат да мащабират и колко са готови хората да разчитат на един доставчик за всеки критичен за мисия аспект на техните работни натоварвания. И добра идея ли е вместо това да се налагат режийните разходи за трансформация на големи данни в бази данни, които са предназначени за оптимизиране на съхранение и извличане (заявка)?
Дори ако всички тези въпроси имат лесни отговори, как се решават изчислителните проблеми (дори само с линейно мащабиране на големи данни), които изискват експоненциално по-голямо потребление на ресурси (като сортиране) ? По някакъв начин отговорът не изглежда да се крие в простото чакане на достъпни квантови изчисления...
Ролята на софтуера
Както знаят архитектите на Hadoop и хранилища за данни, сортирането — и операциите за присъединяване, обобщаване и зареждане в ETL, които разчитат на сортиране — е в основата на голямото предизвикателство за обработка на данни и експоненциален потребител на изчислителни ресурси. Тъй като големите данни се удвояват, изискванията за ресурсите за сортирането им могат да се утроят. Следователно алгоритмите, техниките за използване на хардуера и схемите за обработка, свързани с многоплатформения, многоядрен софтуер за сортиране, са ключовете за управление на този проблем по мащабируеми, достъпни и ефективни начини.
Приносът на CoSort
Ефективността на CoSort се мащабира линейно по обем, повече в съответствие със закона на Амдал. Докато CoSort може да трансформира стотици гигабайта големи данни за минути с няколко десетки ядра, други инструменти могат да отнемат повече от два пъти повече време, да не се мащабират почти толкова добре и/или да консумират повече памет и I/O в процеса. Може би по-важното е, че CoSort интегрира сортирането директно в свързани приложения и върши цялата си тежка работа извън слоя DB и BI, където данните за етапа биха били по-малко ефективни.
Архитектурата на съвместната рутинна програма на CoSort премества записи между сортира и програми като SortCL (полезна програма за преобразуване на данни, филтриране, търсене, отчитане, миграция и защита на CoSort) интерактивно, през паметта. Така че веднага щом бъде наличен следващия сортиран запис, той може да се премести в приложението, да се зареди и т.н. Изглежда приложението, че чете входен файл, но всъщност задният край на източника все още не е създаден. И не, няма да изпревариш сортировача.
В края на 2015 г. CoSort също стана двигател в модерната платформа за управление и манипулиране на големи данни на IRI, Voracity. Прожорливостта използва безпроблемно както CoSort, така и Hadoop двигатели.
Заключение
Физическите изчислителни ресурси сами по себе си не могат да се разчитат за увеличаване на проблема с обработката на големи данни. Софтуерната среда CoSort е тази, в която изискваната трансформация на големи данни и свързаните с тях задачи се изпълняват не като самостоятелни процеси, а паралелно по време на едно и също I/O преминаване.
Така че, ако имате нужда от бързо сортиране за някаква цел, различна от само времето за сортиране, трябва да помислите какво се случва надолу по веригата от сортирането и най-добрите начини за свързване на такива процеси заедно. И след като определите най-добрата парадигма по време на изпълнение, можете ли да комбинирате високопроизводителен хардуер с такъв софтуер, за да оптимизирате производителността? Можете ли да поставите DW данни с CoSort в сървъра на базата данни на Exadata, например? Или би имало повече смисъл да запазите вашия IBM p595 и да добавите CoSort към утроената пропускателна способност? Или ако възнамерявате да използвате Hadoop, помислете за използването на същите прости 4GL CoSort или интуитивни ETL съпоставяния на Voracity, за да управлявате MapReduce 2, Spark, Storm или Tez задания.
Нека вашият бюджет и вашето въображение да бъдат вашите водачи за справяне с нарастването на данните.
