Spark Connect Hive для HDFS против Spark Connect HDFS напрямую и Hive на вершине? - PullRequest
0 голосов
/ 19 июня 2019

Краткое описание проблемы:

У меня есть случайный случай использования для записи> 10 ГБ данных в день в HDFS через потоковую передачу искры. В настоящее время мы находимся в стадии проектирования. Мы хотим записать данные в HDFS (ограничение), используя потоковую передачу. Данные столбчатые. У нас есть 2 варианта (пока):

Естественно, я хотел бы использовать контекст улья для подачи данных в HDFS. Схема определена, и данные передаются партиями или по строкам.

Есть еще один вариант. Мы можем напрямую записывать данные в HDFS благодаря API Streaming Streaming. Мы также рассматриваем это, потому что мы можем запрашивать данные из HDFS через куст, тогда в этом сценарии использования. Это оставит открытыми варианты использования других технологий в будущем для новых вариантов использования.

Что лучше?

Spark Streaming -> Hive -> HDFS -> Используется Hive.

VS

Spark Streaming -> HDFS -> Используется Hive или другими технологиями.

Спасибо.

Пока я не нашел обсуждения по этой теме, мое исследование может быть коротким. Если есть какая-нибудь статья, которую вы можете предложить, я был бы очень рад ее прочитать.

Ответы [ 2 ]

1 голос
/ 19 июня 2019

У меня есть особый вариант использования для записи> 10 ГБ данных в день, а данные столбчатые

, что означает, что вы храните данные за день.если в этом случае куст имеет столбец раздела в качестве даты, так что вы можете легко запрашивать данные за каждый день.Вы можете запросить необработанные данные из инструментов BI, таких как looker, presto или из любого другого инструмента BI.если вы запрашиваете у spark, вы можете использовать свойства / свойства улья.Более того, если вы храните данные в столбчатом формате в паркетном импале, вы можете запросить данные с помощью метастаза улья.

Если ваши данные столбчатые, рассмотрите паркет или орк.

Относительно варианта 2: если у вас есть кустОпция NO не требует подачи данных в HDFS и создания внешней таблицы из куста и доступа к ней.

Заключение : Я чувствую, что оба одинаковы.но улей предпочтительнее, учитывая прямой запрос необработанных данных с использованием инструментов BI или спарк.Из HDFS также мы можем запрашивать данные, используя спарк.если его есть в таких форматах, как json, parquet или xml, не будет добавлено преимущество для варианта 2.

0 голосов
/ 19 июня 2019

Это зависит от ваших окончательных вариантов использования.При принятии решения рассмотрите следующие два сценария:

Если у вас случай RT / NRT и все ваши данные полностью обновлены , тогда я бы предложил использовать второй подход Spark Streaming -> HDFS -> Consumed by Hive.Это будет быстрее, чем ваш первый подход Spark Streaming -> Hive -> HDFS -> Consumed by Hive.Так как в нем на один слой меньше.

Если ваши данные являются инкрементными и также имеют многократное обновление, операции удаления , тогда будет трудно использовать HDFS или Hive поверх HDFS с искрой.Так как Spark не позволяет обновлять или удалять данные из HDFS.В этом случае оба ваших подхода будут трудны для реализации.Либо вы можете перейти с Управляемая таблица Hive и выполнить обновление / удаление с помощью HQL ( поддерживается только в версии Hortonwork Hive ), либо вы можете перейти с NOSQL база данных, такая как HBase или Cassandra , так что искра может легко восстановить и удалить.С точки зрения программы, это будет также легко по сравнению с обоими вашими подходами.Если вы сбрасываете данные в NoSQL, то вы можете использовать для них hive для обычного SQL или для создания отчетов.

Существует так много инструментов и подходов, но они подходят для всех случаев.:)

...