Запуск кластера HDFS на AWS без EMR - PullRequest
1 голос
/ 04 мая 2020

Я хочу запустить кластер HDFS на AWS, где я могу хранить данные, которые должны быть обработаны, используя мое специальное приложение, работающее на экземплярах EC2. AWS EMR - единственный способ найти кластер HDFS на AWS. В сети доступно учебных пособий для создания кластера HDFS с использованием экземпляров EC2. Но, если я использую экземпляры EC2, я рискую потерять данные при закрытии экземпляров.

Что мне нужно:
1. Кластер HDFS, который можно отключить, когда он не находится в используйте.
2. При завершении работы данные должны оставаться постоянными.

Существует решение, которое говорит, что я могу хранить свои данные в S3 и загружать их каждый раз, когда запускаю кластер EMR. Тем не менее, это повторяющиеся и огромные накладные расходы, особенно если данные огромны.

В GCP я использовал кластер DataPro c, который удовлетворял двум вышеуказанным критериям. Выключение кластера по крайней мере сэкономило стоимость виртуальных машин, и я платил только за хранилище, когда не использовал кластер HDFS. Мне интересно, есть ли какой-то аналогичный способ в AWS.

Ответы [ 2 ]

1 голос
/ 05 мая 2020

Вы можете использовать файловую систему EFS Elasti c, которая сохранит все ваши данные на s3 и будет доступна вам при каждом перезапуске вашего экземпляра ec2.

Также вы можете поделиться этой EFS с несколько экземпляров EC2, если требуется. Поэтому создание EFS как HDFS - хороший вариант в вашем случае.

Подробнее здесь .

0 голосов
/ 06 мая 2020

Я думаю, что у вас может быть проблема XY здесь. Вы почти наверняка не хотите иметь удаленную файловую систему HDFS на EMR.

EMR предоставляет две HDFS-совместимые файловые системы для Had oop и Spark изначально:

1) Переходная файловая система, к которой осуществляется доступ через hdfs: //. Это в первую очередь для временных / временных данных. Он длится столько же, сколько и кластер, и поддерживается EBS.

2) Постоянная файловая система, доступ к которой осуществляется через s3: //. Это упоминается как EMRFS в документации. Он поддерживается S3.

Так, например, если вы находитесь в Spark и вы привыкли делать что-то вроде spark.read.parquet ("hdfs: // mydata / somepartition /") .doWork ( ) .write.parquet ("hdfs: // mynewdata / somepartition /")

теперь вы просто делаете spark.read.parquet ("s3: // mybucket / mydata / somepartition /") .doWork () .write.parquet ("s3: // mybucket / mynewdata / somepartition /")

и все просто работает. s3: // оптимизирован для EMR людьми с точки зрения скорости, так как они знают, что ваш кластер EMR совместно использует центр данных с данными S3.

EFS, согласно ответу Шубхам Джейн, вероятно, вызовет проблемы с EMR, поскольку вы эффективно работает второй бэкэнд HDFS помимо переходного, обеспеченного EMR. Я полагаю, вы могли бы, но это было бы немного странно. В вашем кластере EMR вам понадобятся узлы имен для HDFS EMR (в EMR они называются базовыми узлами) и отдельные узлы имен для HDFS с EFS-поддержкой (которые, я полагаю, должны были бы работать как узлы задач EMR?). EFS будет медленнее, чем поддерживаемая EBS HDFS для переходных данных, и дороже, чем S3 для постоянных данных.

Если по какой-то причине вы не хотите использовать EMRFS (я понятия не имею, почему), вы Вероятно, было бы лучше развернуть свой собственный кластер и не использовать EMR, потому что в этот момент вы хотите настроить способ установки HDFS, и цель EMR - сделать это для вас.

...