Урок за кошери - Архитектура на кошерите и казус на НАСА

Урок за Apache Hive: Въведение

Hive е строго използван в цялата индустрия инструмент за анализ на големи данни и чудесен инструмент за стартиране на вашия с. В този блог с уроци по Hive ще обсъждаме задълбочено Apache Hive. Apache Hive е инструмент за съхранение на данни в , който предоставя език, подобен на SQL, за заявки и анализ на големи данни. Мотивацията, която стои зад развитието на Hive, е пътят за обучение, който не изисква триене, за разработчиците и анализаторите на SQL. Hive е не само спасител за хора от непрограмиращ произход, но също така намалява работата на програмисти, които прекарват дълги часове в писане на програми MapReduce. В този блог с уроци за Apache Hive ще говоря за:

• Какво е кошер?
• История на Apache Hive - От Facebook до Apache
• Предимства на Apache Hive
• Apache Hive - казус на НАСА
• Архитектура на кошер Apache
• Конфигурация на Metastore
• Модел на данни за кошери

Урок за Apache Hive: Какво е Hive?

Apache Hive е система за съхранение на данни, изградена върху Hadoop и се използва за анализ на структурирани и полуструктурирани данни.Hive абстрахира сложността на Hadoop MapReduce. По принцип той осигурява механизъм за проектиране на структура върху данните и извършване на заявки, написани на HQL (Hive Query Language), които са подобни на SQL изрази. Вътрешно тези заявки или HQL се преобразуват, за да намалят задачите от компилатора на Hive. Следователно не е нужно да се притеснявате за писането на сложни програми MapReduce за обработка на вашите данни с помощта на Hadoop. Той е насочен към потребители, които се чувстват добре с SQL. Apache Hive поддържа език за дефиниране на данни (DDL), език за манипулиране на данни (DML) и дефинирани от потребителя функции (UDF).

Урок за кошери за начинаещи | Разбиране на кошера в дълбочина | Едурека

SQL + Hadoop MapReduce = HiveQL

Урок за Apache Hive: История на Hive - от Facebook до Apache

Фиг : Hive Tutorial - случай на използване на Facebook

Предизвикателства пред Facebook: Експоненциален растеж на данните

Преди 2008 г. цялата инфраструктура за обработка на данни във Facebook е изградена около склад за данни, базиран на търговски RDBMS. Тези инфраструктури бяха достатъчно способни да задоволят нуждите на Facebook по това време. Но тъй като данните започнаха да растат много бързо, стана огромно предизвикателство да се управлява и обработва този огромен набор от данни. Според статия във Facebook данните, мащабирани от набор от 15 TB през 2007 г. до 2 PB през 2009 г. Също така, много продукти на Facebook включват анализ на данните като Audience Insights, Facebook Lexicon, Facebook Ads и т.н. Така че, те се нуждаеше от мащабируемо и икономично решение, за да се справи с този проблем и затова започна да използва рамката на Hadoop.

Демократизиране Hadoop - MapReduce

Но с нарастването на данните сложността на Map-Reduce кодовете нараства пропорционално. И така, обучението на хора с непрограмиращ опит да пишат програми MapReduce стана трудно. Също така, за извършване на прост анализ трябва да се напишат сто реда MapReduce код. Тъй като SQL беше широко използван от инженери и анализатори, включително Facebook, следователно поставянето на SQL на върха на Hadoop изглеждаше логичен начин да се направи Hadoop достъпен за потребители с SQL фон.

Следователно способността на SQL да е достатъчна за повечето аналитични изисквания и мащабируемостта на Hadoop родиха Apache Hive което позволява да се изпълняват SQL подобни заявки за данните, налични в HDFS. По-късно проектът Hive е отворен през август 2008 г. от Facebook и е свободно достъпен като Apache Hive днес.

Сега нека разгледаме характеристиките или предимствата на Hive, което го прави толкова популярен.

Урок за Apache Hive: Предимства на Hive

• Полезно за хора, които не са от програмен произход, тъй като елиминира необходимостта от писане на сложна програма MapReduce.
• Разтегателен и мащабируема да се справи с нарастващия обем и разнообразие от данни, без да се засяга производителността на системата.
• Той е като ефективен инструмент за извличане, трансформиране, зареждане.
• Hive поддържа всяко клиентско приложение, написано на Java, PHP, Python, C ++ или Ruby, като излага своите Пестелив сървър . (Можете да използвате тези клиентски езици, вградени в SQL за достъп до база данни, като DB2 и т.н.).
• Тъй като информацията за метаданните на Hive се съхранява в RDBMS, това значително намалява времето за извършване на семантични проверки по време на изпълнение на заявката.

Урок за Apache Hive: Къде да използвам Apache Hive?

Apache Hive се възползва от двата свята, т.е. SQL база данни и рамка. Следователно, той се използва от огромно множество компании. Използва се най-вече за съхранение на данни, където можете да извършвате анализи и извличане на данни, които не изискват обработка в реално време. Някои от полетата, в които можете да използвате Apache Hive, са както следва:

• Съхранение на данни
• Ad-hoc анализ

Както се казва, не можете да пляскате само с една ръка, т.е.не можете да решите всеки проблем с един инструмент. Следователно можете да свържете Hive с други инструменти, за да го използвате в много други домейни. Например, Tableau заедно с Apache Hive може да се използва за визуализация на данни, интеграцията на Apache Tez с Hive ще ви осигури възможности за обработка в реално време и т.н.
Продължавайки напред в този блог на Apache Hive Tutorial, нека разгледаме казус на НАСА, където ще разберете как Hive е решил проблема, пред който са били изправени учените от НАСА, докато извършват оценка на климатичните модели.

Урок за кошери: Проучване на НАСА

Климатичният модел е математическо представяне на климатичните системи, основано на различни фактори, които влияят върху климата на Земята. По принцип той описва взаимодействието на различни двигатели на климата като океан, слънце, атмосфера и т.н.дават представа за динамиката на климатичната система. Използва се за проектиране на климатични условия чрез симулиране на климатичните промени въз основа на фактори, които влияят върху климата. Лабораторията за реактивно задвижване на НАСА разработи Регионална система за оценка на климатичния модел (RCMES) за анализ и оценка на модела на климатичния изход спрямо данните от дистанционното наблюдение, налични в различни външни хранилища.

RCMES (Регионална система за оценка на климатичните модели) има два компонента:

рекурсивна серия на Фибоначи в Java

• RCMED (Регионална база данни за оценка на климатичния модел):

Това е мащабируема облачна база данни, която зарежда данните от дистанционното наблюдение и данните за повторен анализ, които са свързани с климата, използвайки екстрактори като екстрактори Apache OODT, Apache Tika и др. И накрая, тя трансформира данните като модел на точката на данни, който е във формата (географска ширина , дължина, време, стойност, височина) и го съхранява в My SQL база данни. Клиентът може да извлече данните, налични в RCMED, като изпълнява заявки за пространство / време. Описанието на такива заявки не е актуално за нас сега.

• RCMET (Регионален инструментариум за оценка на климатичния модел):

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

Референтните данни в RCMED идват от сателитно дистанционно зондиране, според различните параметри, необходими за оценка на климатичния модел. Например - AIRS (Atmospheric Infrared Sounder) осигурява параметри като температура на повърхностния въздух, температура и геопотенциал, TRMM (Tropical Rainfall Measurement Mission) осигурява месечни валежи и т.н.

Проблеми, с които се сблъсква НАСА при използване на системата за бази данни MySQL:

• След зареждане на базата данни MySQL с 6 милиарда кортежа на формата (географска ширина, дължина, време, стойност на точката за данни, височина), системата се срива, както е показано на изображението по-горе.
• Дори след разделянето на цялата таблица на по-малки подмножества, системата генерира огромни режийни разходи, докато обработва данните.

И така, те се нуждаеха от мащабируемо решение, което може да съхранява и обработва това огромно количество данни с SQL като възможност за заявки. Накрая те решиха да използват Apache Hive, за да преодолеят горепосочените проблеми.

Как Apache Hive може да реши проблема?

Сега, нека видим, кои са тези функции, които убедиха екипа на JPL на НАСА да включи Apache Hive като неразделна част от стратегията си за решение:

• Тъй като Apache Hive работи върху Hadoop, той е мащабируем и може да обработва данни по разпределен и паралелен начин.
• Той предоставя Hive Query Language, който е подобен на SQL и следователно лесен за научаване.

Разполагане на кошер:

Следващото изображение обяснява RCMES Architect с интеграция на Apache Hive:

Фиг : Hive Tutorial - RCMES Architecture with Apache Hive

Горното изображение показва разполагането на apache hive в RCMES. По време на разполагането на Apache Hive екипът на НАСА предприе следните стъпки:

• Те инсталираха Hive с помощта на Cloudera и Apache Hadoop, както е показано на горното изображение.
• Те използваха Apache Sqoop за поглъщане на данни в кошера от базата данни MySQL.
• Apache OODT обвивката е внедрена, за да изпълнява заявки в Hive и да извлича данните обратно в RCMET.

Първоначални бенчмаркинг наблюдения с кошер:

• Първоначално те заредиха 2,5 милиарда точки с данни в една таблица и изпълниха заявка за преброяване. Например, Кошера> изберете брой (datapoint_id) от dataPoint. Отнемаха 5-6 минути за преброяване на всички записи (15–17 минути за пълните 6,8 милиарда записи).
• Фазата на намаляване беше бърза, но фазата на картата отне 95% от цялото време за обработка. Те използваха шест ( 4x четириядрен ) системи с 24 GB RAM (приблизително) във всяка от системите.
• Дори след добавяне на повече машини, промяна на размера на блока HDFS (64 MB, 128 MB, 256 MB) и промяна на много други конфигурационни променливи (io.вид.коефициент, т.е..вид.mb), те не постигнаха голям успех при намаляване на времето за попълване на броенето.

Материали от членове на общността на кошерите:

И накрая, членовете на общността на кошерите пристигнаха на помощ и предоставиха различни прозрения за решаване на проблемите с настоящите им изпълнения на кошера:

• Те споменаха, че скоростта на четене на HDFS е приблизително 60 MB / s в сравнение с 1GB / s в случай на локален диск, в зависимост от мрежовия капацитет и натоварването на NameNode.
• Членовете предложиха това 16 картографи ще се изисква в текущата им система да съвпада с I / O изпълнението на локална задача, различна от Hadoop.
• Те също така предложиха да се намали разделен размер за всеки картограф да увеличи броянакартографи и следователно, осигурявайки повече паралелизъм.
• Накрая членовете на общността им казаха използване на броя (1) вместо да се позовава на броя ( datapoint_id) . Това е така, защото в случай на преброяване (1) няма референтна колона и следователно не се извършва декомпресия и десериализация, докато се извършва преброяването.

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

Урок за Apache Hive: Архитектура на кошерите и нейните компоненти

Следващото изображение описва архитектурата на кошера и потока, в който е подадена заявкаКошераи накрая обработени с помощта на рамката MapReduce:

Фиг : Урок за кошери - Архитектура на кошера

Както е показано на горното изображение, архитектурата на кошера може да бъде категоризирана в следните компоненти:

• Клиенти на кошери: Hive поддържа приложение, написано на много езици като Java, C ++, Python и др., Използвайки драйвери JDBC, Thrift и ODBC. Следователно винаги може да се пише клиентско приложение на кошер, написано на език по техен избор.
• Услуги за кошери: Apache Hive предоставя различни услуги като CLI, уеб интерфейс и др., За да изпълнява заявки. Ще разгледаме всеки един от тях скоро в този урок на Hive tutorial.
• Рамка за обработка и управление на ресурси: Вътрешно,Hive използва рамката Hadoop MapReduce като де факто двигател за изпълнение на заявките. е отделна тема сама по себе си и следователно не се обсъжда тук.
• Разпределено съхранение: Тъй като Hive е инсталиран върху Hadoop, той използва основния HDFS за разпределеното хранилище. Можете да се обърнете към Блог на HDFS за да научите повече за него.

Сега нека разгледаме първите два основни компонента в архитектурата на кошера:

1. Клиенти на кошери:

Apache Hive поддържа различни видове клиентски приложения за изпълнение на заявки в Hive. Тези клиенти могат да бъдат категоризирани в три типа:

• Пестеливи клиенти: Тъй като Hive сървърът е базиран на Apache Thrift, той може да обслужва заявката от всички онези езици за програмиране, които поддържат Thrift.
• Клиенти на JDBC: Hive позволява на Java приложенията да се свързват с него с помощта на JDBC драйвер, който е дефиниран в org на класа.апаш.хадооп.кошер.jdbc.HiveDriver.
• Клиенти на ODBC: ODBC драйверът на Hive позволява на приложения, които поддържат протокола ODBC, да се свързват с Hive. (Подобно на JDBC драйвера, ODBC драйверът използва Thrift за комуникация със сървъра на Hive.)

2. Услуги за кошери:

Hive предоставя много услуги, както е показано на изображението по-горе. Нека да разгледаме всеки от тях:

• Hive CLI (интерфейс на командния ред): Това е обвивката по подразбиране, предоставена от Hive, където можете директно да изпълнявате своите заявки и команди за Hive.
• Уеб интерфейси на Apache Hive: Освен интерфейса на командния ред, Hive предлага и уеб базиран GUI за изпълнение на заявки и команди на Hive.
• Hive сървър: Hive сървърът е изграден на Apache Thrift и следователно се нарича още Thrift Server, който позволява на различни клиенти да подават заявки до Hive и да извличат крайния резултат.
• Apache Hive Driver: Той е отговорен за получаване на заявки, подадени чрез клиентски интерфейс, уеб интерфейс, Thrift, ODBC или JDBC интерфейси от клиент. След това драйверът предава заявката на компилатора, където се извършва синтактичен анализ, проверка на типа и семантичен анализ с помощта на схема, присъстваща в мета-магазина. В следващата стъпка се генерира оптимизиран логически план под формата на DAG (Directed Acyclic Graph) на задачи за намаляване на картата и HDFS задачи. И накрая, механизмът за изпълнение изпълнява тези задачи в реда на техните зависимости, използвайки Hadoop.
• Metastore: Можете да мислите за metastoreкато централно хранилище за съхраняване на цялата информация за метаданните на Hive. Метаданните на кошера включват различни видове информация, като структура на таблици и дяловезаедно с колоната, типа на колоната, сериализатора и десериализатора, които са необходими за операцията за четене / запис на данните, налични в HDFS. Метастазасе състои от две основни единици:
  • Услуга, която предоставя metastoreдостъп до другиrУслуги за кошери.
  • Дисково хранилище за метаданните, което е отделно от HDFS съхранението.

Сега нека да разберем различните начини за внедряване на Hive metastoreв следващия раздел на този урок за кошери.

Урок за Apache Hive: Конфигурация на Metastore

Metastore съхранява информацията за метаданни, използвайки RDBMS и слой с отворен код ORM (Object Relational Model), наречен Data Nucleus, който преобразува представянето на обекта в релационна схема и обратно. Причината за избора на RDBMS вместо HDFS е да се постигне ниска латентност. Можем да приложим metastore в следните три конфигурации:

1. Вграден Metastore:

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

2. Местна метастаза:

Тази конфигурация ни позволява да имаме множество сесии на Hive, т.е. множество потребители могат да използват базата данни на metastore едновременно. Това се постига чрез използване на която и да е JDBC съвместима база данни като MySQL, която работи в отделна JVM или друга машина, различна от тази на услугата Hive и услугата metastore, които се изпълняват в същия JVM, както е показано по-горе. Като цяло, най-популярният избор е да се внедри MySQL сървър като база данни на metastore.

3. Отдалечен Metastore:

В конфигурацията на отдалеченото metastore услугата metastore работи на своя отделна JVM, а не в JVM на Hive услугата. Други процеси комуникират със сървъра на metastore, използвайки API на Thrift Network. В този случай можете да имате един или повече метастори сървъри, за да осигурите повече наличност.Основното предимство на използването на отдалечен metastore е, че не е необходимо да споделяте идентификационни данни за вход в JDBC с всеки потребител на Hive за достъп до базата данни на metastore.

Урок за Apache Hive: Модел на данни

Данните в Hive могат да бъдат категоризирани в три типа на гранулирано ниво:

• Таблица
• Преграда
• Кофа

Маси:

Таблиците в Hive са същите като таблиците, присъстващи в релационна база данни. Можете да извършвате операции по филтриране, проектиране, присъединяване и обединяване върху тях. В Hive има два вида таблици:

1. Управлявана таблица:

Команда:

СЪЗДАВАНЕ НА ТАБЛИЦА (тип колона1 тип данни, тип колона2 тип данни)

ЗАГРУЖЕТЕ ДАННИ ВЪВ ВЪВ таблицата управлявана_таблица

Както подсказва името (управлявана таблица), Hive е отговорен за управлението на данните на управлявана таблица. С други думи, това, което имах предвид, казвайки „Hive управлява данните“, е, че ако заредите данните от файл, наличен в HDFS, в кошер Управлявана таблица и издайте команда DROP върху нея, таблицата заедно с нейните метаданни ще бъдат изтрити. И така, данните, принадлежащи на отпадналите управлявана_таблица вече не съществуват никъде в HDFS и не можете да го извлечете по никакъв начин. По принцип премествате данните, когато издавате командата LOAD от местоположението на HDFS файла в директорията на хранилището на Hive.

Забележка: Пътят по подразбиране на директорията на склада е зададен на / user / hive / warehouse. Данните от таблица на кошер се намират в warehouse_directory / име на таблица (HDFS). Можете също да посочите пътя на директорията на склада в конфигурационния параметър hive.metastore.warehouse.dir, присъстващ в hive-site.xml.

2. Външна маса:

Команда:

видове филтри в таблицата

СЪЗДАВАНЕ НА ВЪНШНА ТАБЛИЦА (тип колона1 тип данни, тип колона2 тип данни) ЛОКАЦИЯ ‘’

ЗАЧЕТЕТЕ ДАННИ ВЪВ ВРЪЗКА „’ В МАСА

За външна маса , Hive не носи отговорност за управлението на данните. В този случай, когато издадете командата LOAD, Hive премества данните в своята директория на склада. След това Hive създава информация за метаданните за външната таблица. Сега, ако издадете команда DROP на външна маса , само информацията за метаданни относно външната таблица ще бъде изтрита. Следователно все още можете да извлечете данните от тази много външна таблица от директорията на склада, използвайки HDFS команди.

Дялове:

Команда:

СЪЗДАВАНЕ НА ТАБЛИЦА име на таблица (колона1 тип_данни, колона2 тип_данни) РАЗДЕЛЕН ОТ (тип дял1 тип_данни, тип_раздел2 тип_и hellip.)

Hive организира таблици в дялове за групиране на подобен тип данни заедно въз основа на колона или дялов ключ. Всяка Таблица може да има един или повече дялове за идентифициране на определен дял. Това ни позволява да имаме по-бърза заявка за резени от данни.

Забележка: Не забравяйте, че най-често допусканата грешка при създаването на дялове е да се посочи име на съществуваща колона като колона на дяла. Докато го правите, ще получите грешка - „Грешка при семантичен анализ: Повтаря се колона в колоните за разделяне“.

Нека разберем разделянето, като вземем пример, в който имам таблица student_details, съдържаща информацията за студента на някакъв инженерен колеж като student_id, име, отдел, година и т.н. принадлежащи към определен отдел ще се съхраняват заедно в този дял. Физически дялът не е нищо друго освен поддиректория в директорията на таблицата.

Да приемем, че имаме данни за три отдела в нашата таблица student_details - CSE, ECE и Civil. Следователно ще имаме общо три дяла за всеки от отделите, както е показано на изображението по-долу. И за всеки отдел ще имаме всички данни относно този отдел, пребиваващи в отделна поддиректория в директорията на таблицата на кошера. Например, всички данни за студентите по отношение на отделите за CSE ще се съхраняват в user / hive / warehouse / student_details / dept. = CSE. Така че, запитванията относно учениците от CSE ще трябва само да преглеждат данните, присъстващи в дяла на CSE. Това прави разделянето много полезно, тъй като намалява латентността на заявката само чрез сканиране от значение разделени данни вместо целия набор от данни. Всъщност, в реални изпълнения ще имате работа със стотици TB данни. И така, представете си как сканирате това огромно количество данни за някаква заявка къде 95% сканираните от вас данни не са свързани с вашата заявка.

Бих ви предложил да преминете през блога на Кошери команди където ще намерите различни начини за внедряване на дялове с пример.

Кофи:

Команди:

СЪЗДАЙТЕ ТАБЛИЦА име на таблица ИЗДЕЛЕНО ОТ (тип дял1 тип_данни, тип_раздел2 тип данни, & hellip.) КЛУСТРИРАНО ОТ (име_колона1, име_колона2, ...) СОРТИРАНО ПО (име_на колона [ASC | DESC], ...)] В БЪЛГАРСКИ БУКЕТИ

Сега можете да разделите всеки дял или неразделената таблица на сегменти въз основа на хеш функцията на колона в таблицата. Всъщност всяка група е само файл в директорията на дяловете или директорията на таблицата (неразделена таблица). Следователно, ако сте избрали да разделите дяловете на n групи, ще имате n файлове във всяка от вашата директория на дялове. Например можете да видите изображението по-горе, където сме групирали всеки дял на 2 групи. И така, всеки дял, да речем CSE, ще има два файла, където всеки от тях ще съхранява данните на студента на CSE.

Как Hive разпределя редовете в кофи?

Е, Hive определя номера на сегмента за ред, използвайки формулата: hash_function (bucketing_column) modulo (num_of_buckets) . Ето, чash_function зависи от типа данни на колоната. Например, ако сте групирали таблицата на базата на някаква колона, да речем user_id, от INT тип данни, функцията хеш ще бъде - hash_function (user_id ) = целочислена стойност на user_id . И, да предположим, че сте създали две групи, тогава Hive ще определи редовете, които отиват в група 1 във всеки дял, като изчисли: (стойност на user_id) по модул (2). Следователно, в този случай редове с user_id, завършващи с четна цифра, ще се намират в една и съща група, съответстваща на всеки дял. Функцията hash_ за други типове данни е малко сложна за изчисляване и всъщност за низ тя дори не е разпознаваема от човека.

Забележка: Ако използвате Apache Hive 0.x или 1.x, трябва да издадете команда - задайте hive.enforce.bucketing = true от вашия Hive терминал, преди да извършите сегментиране. Това ще ви позволи да имате правилния брой редуктори, докато използвате клъстер по клауза за групиране на колона. В случай, че не сте го направили, може да откриете, че броят на файловете, генерирани в директорията на вашата таблица, не е равен на броя на сегментите. Като алтернатива можете също да зададете броя на редуктора, равен на броя на сегментите, като използвате set mapred.reduce.task = num_bucket.

Защо се нуждаем от кофи?

Има две основни причини за извършване на групиране към дял:

• ДА СЕ карта страна се присъедини изисква данните, принадлежащи към уникален ключ за присъединяване, да присъстват в същия дял. Но какво ще кажете за онези случаи, при които вашият дялов ключ се различава от присъединяването? Следователно, в тези случаи можете да извършите присъединяване от страна на картата, като групирате таблицата с помощта на клавиша за присъединяване.
• Групирането прави процеса на вземане на проби по-ефективен и следователно ни позволява да намалим времето за заявка.

Бих искал да завърша този блог с уроци по Hive тук. Сигурен съм, че след като прегледате този урок на Hive, бихте осъзнали простотата на Apache Hive. Оттогава вие сте научили всички основи на Кошера, крайно време е да имате опит с Apache Hive. Така че, разгледайте следващия блог от тази серия блогове с Hive Tutorial, който е за инсталиране на Hive и започнете да работите върху Apache Hive.

След като разбрахте Apache Hive и неговите характеристики, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение по сертифициране на големи данни Hadoop на Edureka помага на обучаващите се да станат експерти в HDFS, прежди, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, като използват случаи в реално време за търговия на дребно, социални медии, авиация, туризъм, финанси.

Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.