Двигатели за обработка на големи данни – Коя да използвам?:Част 1

Тази публикация в блога е публикувана на Hortonworks.com преди сливането с Cloudera. Някои връзки, ресурси или препратки може вече да не са точни.

Специални благодарности на Bill Preachuk и Brandon Wilson за прегледа и предоставянето на техния опит

Въведение

Колонното съхранение е често обсъждана тема в света на обработката и съхранението на големи данни днес – има стотици формати, структури и оптимизации, в които можете да съхранявате данните си и дори повече начини да ги извлечете в зависимост от това какво планирате да направите с него. Това изобилие от опции се появи поради необходимостта не само да се поглъщат бързо данни с помощта на инструменти за онлайн транзакционна обработка (OLTP), но и поради необходимостта да се консумират и анализират данни с по-голяма ефективност с помощта на онлайн аналитична обработка (OLAP) инструменти. Хиляди различни случаи на употреба всеки има свои специфични нужди и по този начин се появиха много опции. Например, четенето на данни за борсови тикери изисква напълно различен начин на мислене от анализирането на качествени показатели в производствена линия. С всички тези възможности е лесно да се изгубите, когато навигирате до крайната си цел:избор на инструмент, който работи за вас.

HDP включва редица решения за съхранение, всяко от които е специално създадено за конкретни случаи на употреба. Искаме да започнем тази серия от блогове, като говорим за следните три инструмента/двигатели и свързаните с тях формати за съхранение:

• Apache Hive използва Apache ORC като ефективен колонен формат за съхранение, който позволява  производителност както за OLAP, така и за дълбока обработка на SQL заявки
• Apache Phoenix/Apache HBase заедно образуват OLTP база данни, която позволява заявки в реално време над милиарди записи и предлага бързи произволни търсения, базирани на ключове, както и актуализации
• Apache Druid е хранилище на данни с висока производителност, което позволява анализ на времеви серии в реално време на потоци от събития и OLAP анализ върху исторически данни с изключително ниска латентност.

В тази статия възнамеряваме да формулираме кой инструмент е подходящ за даден случай на употреба, да сравним и съпоставим различните инструменти и да предоставим основни насоки за избор на подходящия инструмент или набор от инструменти за справяне с вашия случай на употреба.

Това е много като да играете на Tetris – всяко парче има различна ниша, но всяко добавя уникална стойност към по-голямата структура

Обработка на големи данни и нейните прилики

Данните са групирани по колони в хранилището, защото често се опитваме да стесним сумите, средните стойности или други изчисления за конкретна колона. Представете си, че сте авиокомпания, която се опитва да разбере колко гориво да даде на самолета, когато е акостиран – може да искате да изчислите средните мили, прелетяни от всеки полет, от таблица с данни за полета. Това ще изисква изпълнение на средната функция на една колона. Бихме съхранили тези данни в колонен формат, тъй като последователните четения на диска са бързи и това, което искаме да направим в този случай, е да прочетем една пълна колона от таблицата последователно (и след това да извършим средно изчисление).

Има много разлики между тези машини, но независимо от това коя машина за обработка на данни изберете, ще се възползвате от няколко общи черти. Една от тях е споделената функция за кеширане. Всеки от тези три механизма работи ръка за ръка с кеширане в паметта, за да повиши производителността на своята обработка, без да променя формата за съхранение на бекенда, постигайки времена за реакция под секунда. HBase има BlockCache, Hive има LLAP IO слой, а Druid има няколко опции за кеширане в паметта. Често скъпата част от обслужването на заявка включва синтактичен анализ на заявката и отиване в постоянно хранилище за извличане на подмножеството от данни, от които потребителят се интересува. Цялата тази стъпка обаче може да бъде избегната, когато се използва механизъм за кеширане в паметта, тъй като много колонни формати за съхранение използване, което позволява на процеса да достигне до паметта за предварително запитани данни за части от секундата. Нека се върнем към нашия пример за изчисляване на горивото:да речем, че току-що попитах за средните излетени мили за всички полети в моята компания, но осъзнавам, че вътрешните полети ще имат изисквания за гориво, които са много различни от международните полети. След това ще искам да филтрирам предишната си заявка с клауза WHERE country=’US’ (или еквивалентен код на държавата). Този модел на заявка е много често срещан при изследване на данни. Тъй като вече имаме данните от предишната заявка в паметта, резултатите от тази заявка могат да бъдат върнати, без да се налага да извършваме скъпо четене на диск.

Структурата на LLAP слоя на Hive – част от паметта му се използва за кеширане, докато дългосрочното съхранение е на HDFS. HBase и Druid също имат подобна концепция за кеш и съхранение.

Друга прилика съществува в преките пътища, които всеки от тези двигатели използва за нулиране на конкретните данни, които се заявяват. HBase има произволен достъп O(1), базиран на HashMap, Druid използва индекси на обърнати растерни изображения, за да разбере кои стойности на колоните са в кои редове, а таблиците Hive имат статистика, индекси и разделяне за бърз достъп до данни. Тези функции позволяват на двигателите да комбинират начина, по който се съхраняват данните с начина, по който се осъществява достъп, позволявайки бърз анализ, като същевременно оптимизират ефективността на хардуера и извличат максимума от наличните CPU и RAM.

Последната прилика е готовността за предприятие на всеки от тези двигатели. От страна на резервирането на данни, и трите от тези двигатели използват HDFS като свой механизъм за дълбоко съхранение; коефициентът на репликация на HDFS от 3x гарантира, че копия на данните съществуват другаде, дори ако два възела се повредят едновременно. Данните могат незабавно да бъдат репликирани отново до здрави възли, за да се поддържа излишък. По темата за толерантността на грешки в клъстер, всеки инструмент запълва празнината по някакъв начин. HBase предлага регионална репликация, Druid има дублиране на главни и работни компоненти, както и повишен коефициент на репликация на HDFS, а Hive има HDFS наред с отказоустойчивата логика на рамката YARN. Готовността на предприятието гарантира, че тези двигатели са устойчиви на повреда и са готови да работят в производство от първия ден.

Разликите между нашите машини за обработка на големи данни

Кой е най-добрият начин за поглъщане на данни? След като погълнете данните си, как бързо да извлечете прозрения от тях? Нека се потопим в това как тези три машини за обработка на големи данни поддържат този набор от задачи за обработка на данни

Тези двигатели понякога са мислено свързани заедно и се обмислят по подобен начин поради способността им да съхраняват и обработват големи данни, но както ще разберем, те са избрани за случаи на употреба и цели, които са специално подходящи за техните силни страни. Ще видите, че колекцията от инструменти, която съдържа платформата за данни на Hortonworks, е много подходяща за всяко работно натоварване с големи данни, което можете да хвърлите върху нея, особено с HDP 3.0 и възможностите за база данни в реално време, които въведохме.

Hive е OLAP машината, която е представителна за най-широката гама от случаи на използване, като най-често използва разпределената файлова система Hadoop (HDFS) като свой слой за съхранение, за да позволи съхранение на почти всякакъв тип данни. Може да заявява, обработва и анализира неструктурирани текстови данни, CSV файлове, XML, полуструктуриран JSON, колонен паркет и множество други формати. Hive също така поддържа алтернативни носители за съхранение като облачно съхранение, Isilon и други. Де факто стандартът за съхранение за Hive е ORC, който оптимизира най-ефективно и извлича предимствата на колонното съхранение. След като бъдат преобразувани в ORC, вашите данни се компресират и колоните във вашата таблица се съхраняват последователно на диск, което позволява на слоя за кеширане в паметта на Hive LLAP да изтегли данните от диска веднъж и да ги обслужва от паметта няколко пъти. Комбинацията от Hive+LLAP се използва за ad-hoc анализ, изчисляване на големи агрегати и отчитане с ниска латентност. Страхотен случай на използване на Hive е ежедневното стартиране на набор от отчети на таблото за управление за потребителите; повтарящите се заявки не само се възползват от кеша на LLAP, но и от функцията „Кеш на резултатите от заявките“ – която връща почти мигновени резултати, ако данните не са се променили (Отстрани:Кешът на резултатите от заявките е функция, налична в Hive 3.0 – пусната в HDP 3.0). Наред с това, Hive Data Warehouse е чудесно използване на ad-hoc анализите, на които Hive е способен; потребителите могат да обединяват данни заедно, да изпълняват едновременни заявки и да изпълняват ACID транзакции. Считайте, че Hive е SQL жак на всички занаяти в това отношение, докато другите два двигателя осигуряват изключително бърза производителност за специфични случаи на използване в ниша.

Вторият ни двигател, HBase, е разпределено хранилище за ключ-стойност, което има възможности за произволно четене, запис, актуализиране и изтриване. HBase (вариант на NoSQL) е проектиран да бъде OLTP двигател, позволяващ архитектура на транзакционни операции с голям обем – помислете за платформи за съобщения с постоянни съобщения, които се обменят между потребителите или транзакции, генерирани във финансова система. HBase е изключително ефективен при бързото въвеждане на данни, съхраняването им и връщането им – произволни вмъквания/актуализации/изтривания с ултра ниска латентност. Това, за което не е предназначено, е агрегиране и обединяване на данни – тази функционалност се осъществява чрез Phoenix, SQL слой и двигател върху HBase, но не се препоръчва за по-големи количества данни, тъй като данните не са структурирани по начин за постигане на оптимално производителност (вместо това използвайте Hive). За да обобщим, HBase е страхотен в обработката на големи обеми операции Създаване-Актуализиране-Изтриване, но не успява, когато дойде време да представи тези данни в консумативен формат за потребителите.

И накрая, Druid е третият двигател и е подходящ за OLAP времеви серии с ниска латентност, както и за индексиране в реално време на поточни данни. Druid предоставя OLAP заявки с кубична скорост за вашия клъстер. Естеството на Друид от времеви серии е крайъгълен камък на двигателя; той е проектиран по този начин, тъй като времето е основен филтър, когато се анализират базирани на време данни. Помислете, когато анализирате времето за полет, за да резервирате пътуване – искам да знам най-евтиния полет до Италия в рамките на този конкретен 2-седмичен период от време. Druid се вписва в нишата да бъде много бърз за поглъщане на данни, както и за намирането им при поискване. От друга страна също така позволява на бизнес потребителите и анализаторите да търсят данните и да ги разберат чрез Superset, слой за визуализация, тясно свързан с Druid. Druid е превъзходен в определянето на шепа редове данни сред стотици милиони или милиарди за по-малко от секунда, а също така превъзхожда в изчисляването на обобщени стойности за същия обем данни изключително бързо. Въпреки това, той не прави свързвания и следователно не може да се използва за комбиниране на набори от данни заедно за анализ. Ако планирате да анализирате комбинация от набори от данни в Druid, би било разумно предварително да обедините данните, преди да ги вмъкнете в Druid, или да използвате Hive (и таблици Hive, поддържани от Druid), за да извършите обединения. Казано с други думи, Druid се вписва добре в ролята на последната спирка за вашите данни, след като те бъдат обработени и трансформирани в начина, по който вашите бизнес потребители ще имат достъп до тях. Druid е чудесен за бизнес анализатори, тъй като те могат да влизат в Superset и да визуализират показатели във формата на таблото, без да се налага да пишат каквито и да е запитвания; те просто използват GUI за избор на източник на данни и филтри на заявката. Освен това е страхотен като резервен източник на данни за системни табла за управление, независимо дали са оперативни или аналитични, поради бързото време за заявка.

Ето един от начините, по които можете да разделите вземането на решение кой инструмент да използвате за вашето работно натоварване:

Обединен SQL

До този момент обсъдихме множество системи и всяка от тях има свои собствени начини за достъп до своите данни. Това е чудесно, когато вашите потребители знаят как работят всички тези инструменти, но може да им предстои крива на обучение, преди да успеят да достигнат пълна производителност, ако идват от света на SQL, SQL и повече SQL, както правят повечето анализатори. Ето защо се опитахме да направим това взаимодействие възможно най-просто; с Hive 3.0 в HDP 3.0 можете да използвате HQL синтаксиса на Hive, подобен на SQL, за да взаимодействате с толкова много различни хранилища на данни в това пространство. Hive може да се използва като портал за достъп и промяна на Druid, HBase и всичко, което предоставя JDBC интерфейс и драйвер. Hive може да се използва за администриране на задача за поглъщане на друиди, която слуша Кафка, осигурявайки прост начин за поглъщане в реално време. И накрая, Hive може да се използва за обединяване на всичко – съхранявайте вашите данни там, където има най-голям смисъл, и достъп до тях от едно място. Обединете го заедно, може би дори съхранявайте този нов резултат на друго място. Възможностите са много, но интерфейсът е значително опростен, така че вашата потребителска база може да отдели по-малко време за изучаване на друг инструмент и повече време, за да донесе стойност на бизнеса.

Заключение

Hive, Druid и HBase имат различни места в архитектурата на данни, както видяхме от предишния анализ. Те обаче са допълнителни инструменти; можете да поглъщате транзакционни данни с HBase с неговите бързи търсения, да премествате тези данни в Druid за бързо разбивка/обединяване и да накарате Hive да интегрира двете заедно със собствените си управлявани от Hive данни, за да позволи на потребителите да комбинират данни, където и да пребивават за един възглед и изобилие от прозрения. С този подход Druid съхранява данни, които могат да бъдат достъпни самостоятелно, но тази функционалност се допълва от Hive, който може да изтегля данни на Druid и да ги обедини с допълнителни данни. Добавете към това основните подобрения, които влязоха в игра с Hive 3.0, не на последно място са материализирани изгледи, подобрени интеграции с Druid, както и много други двигатели и увеличена функционалност, подобна на склад за данни, и ще получите група от инструменти, които могат да решат почти всеки случай на употреба.

Архитектури като гореспоменатата внасят най-доброто от всеки инструмент за оптимизиране на вашия работен процес и в същото време абстрахират детайлите за тези потребители, които се интересуват само от данните. Архитектите настройват тръбопроводите, поставяйки данните там, където им е мястото въз основа на случая на употреба. След това това води до анализаторите на данни, които използват Hive като свой единен интерфейс, за да получат знания и прозрения. Те могат да намерят интересни модели в данните, вместо да се тревожат къде се съхраняват данните или да научат нов синтаксис за достъп до тях – ще се изненадате да разберете колко често виждаме това в света.

На този етап ние демонстрирахме силните, слабите страни и най-добрите практики на всеки инструмент; Надяваме се, че ще си тръгнете с по-добро разбиране на това къде се вписва, както и с по-голямата картина на комбинирането на трите, за да получите най-добри резултати.