Оболочка Impala или Spark для ETL?
Недавно я начал работать над средой Hadoop. Мне нужно было сделать базовый ETL для заполнения нескольких таблиц. В настоящее время я импортирую данные в Hadoop с помощью sqoop и использую команду оболочки Impala для написания SQL-запросов для преобразований.
Но в последнее время я много слышу о Spark. В моей ситуации будет ли у меня какое-либо преимущество при написании ETL в Spark вместо оболочки Impala?
Спасибо С
SQL помимо выбора также имеет вставку, обновление, удаление. На протяжении веков люди писали ETL с использованием SQL. Следовательно, Impala, ImpalaQL также использовались в аналогичном ключе для выполнения ETL. Представление о том, что другой ответ лучше моего, менее очевидно. Кстати, 2 ответа выбрать нельзя. Мне любопытно объяснение.
@thebluephantom, как вы можете сказать, я новичок в stackoverflow. Если я делаю что-то не так, принимая ответы, пожалуйста, дайте мне знать. Я не слишком хорошо знаком с тем, что происходит, когда я принимаю.
Вы можете принять только 1 ответ. Вы можете проголосовать за все ответы / проголосовать против. Я думаю, что мой ответ намного лучше, чем принятие другого, который отвергает мой. Но я могу жить с этим, но чувствую, что вы можете быть новичком во всем этом.
Спасибо за объяснение и понимание.
Ответы 2
Многие люди в прошлом использовали либо A) сценарии SQL (например, Impala) со сценариями UNIX, либо использовали B) инструменты ETL для ETL.
Однако вопрос в том, 1) больше масштаба imo и 2) стандартизация технологий.
Поскольку используется Spark, почему бы не стандартизировать Spark?
Я прошел через этот цикл, и обработка Kimball DWH вполне может быть выполнена с помощью Spark. Это означает меньшие затраты с точки зрения платных инструментов ETL, таких как Informatica. Но есть общественные издания.
Некоторые моменты, на которые следует обратить внимание:
- Сохранение файла в различных форматах HDFS проще и удобнее с помощью Data Frame Writer и т. д.
- Но отображения с ветвями, подобные Informatica, немного отличаются.
- Производительность в масштабе будет лучше с Spark, когда данные будут получены из внешних источников.
- Управление файлами проще с помощью сценариев UNIX, чем внутри Spark imo, но к этому нужно привыкнуть, если это делается в Spark.
- Sqoop можно избежать, и вы можете использовать JDBC DF Reader of Spark, но нет причин отказываться от sqoop, хотя вместо этого я бы использовал Confluent Kafka Connect с более высокой задержкой, но тогда мы переходим к Zen Questions, поскольку Kafka более реален. временные аспекты.
- В целом я не убежден в преимуществах инструментов ETL.
С учетом сокращения затрат, которое необходимо для ИТ-отдела, Spark является хорошим вариантом. Но это не для слабонервных, нужно быть хорошим программистом. Это то, что я слышу от многих людей.
Спасибо thebluephantom за ваш ответ. Мы следуем тому же методу, который вы упомянули. Инструменты ETL для нашего хранилища данных impala и сценарии оболочки для загрузки/преобразования данных в Hadoop Мы не хотим покупать инструменты ETL для работы Hadoop. Мы хотим продолжать использовать инструменты, уже доступные в экосистемах Hadoop. Теперь один момент, который вы упомянули о стандартизации. Использование Spark вместо скриптов Imapala/shell выгодно только для стандартизации или будет реальный прирост производительности? Я не понял этого момента из вашего ответа.
Impala по определению быстрее по сравнению с HiveQL, использующим Map Reduce. Spark действительно предназначен для больших объемов, запуск задания Spark требует дополнительных затрат. Но стандартный подход привлекателен, и люди, конечно, хотят узнать что-то новое для своего резюме. Ладно с последним. Однако Spark не подходит для обработки всех kpi.
Коснувшись, нажав на галочку
Я просто принял это. Потребовалось некоторое время, чтобы понять, как это принять, поскольку это первая публикация чего-либо в stackoverflow. Еще раз спасибо.
Я бы добавил, что Impala — это не инструмент ETL, это механизм запросов SQL, который позволяет вам выполнять запросы SQL к очень большим наборам данных после того, как данные были очищены в процессе ETL.
Исторически Pig и Hive использовались для ETL до Spark. Hive по-прежнему актуален, если вы предпочитаете SQL-подобный синтаксис, и есть много вариантов, которые предлагают более высокую производительность, например Hive на Tez и Hive на Spark, которые заменяют MapReduce на Spark.
использованная литература
Вы можете использовать +1 вместо отметки «принять» (флажок), поскольку ответ @thebluephantom является более полным. Я предоставляю некоторую дополнительную информацию, которая охватывает вещи, не упомянутые в его ответе.
Просто любопытно, почему бы просто не перейти на SparkSQL (вместо Hive/Pig), если мы уже используем Spark и хотим возможности SQL?
На мой взгляд неудачный выбор. Используется Импала.