Многие люди в прошлом использовали либо 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, но в этом случае нужно привыкнуть, если это сделатьвнутри искры.
- Sqoop можно избежать, и вы можете использовать JDBC DF Reader of Spark, но нет причин отказываться от sqoop, хотя я бы вместо этого использовал Confluent Kafka Connect с более высокой задержкой, но тогда мы получим Zen Вопросы какKafka предназначена для большего количества аспектов в реальном времени.
- В целом я не убежден в преимуществах инструментов ETL.
Благодаря сокращению затрат, которое требуется ИТ-специалистам, Spark является хорошимвариант.Но это не для слабонервных, нужно быть хорошим программистом.Это то, что я слышу от многих людей.