Amazon EMR против EC2 для выгрузки загрузки BI & Analytics anno 2018 - PullRequest
0 голосов
/ 04 декабря 2018

Я просмотрел несколько постов, но они немного старше по этой теме.Я также читал AWS и другие блоги, но ...

Мой простой вопрос, не связанный с программированием для AWS в современных условиях:

  • Если у нас естьDWH, скажем, 20+ ТБ и растущий, который мы хотим разгрузить в Облако, как это делают многие, затем

    • , если у нас есть регулярная ежедневная подача DWH с некоторыми мутациями,затем

      • следует ли нам в случае AWS использовать EMR или EC2?
    • Более того, это полная пакетная среда, без потоковой передачи илиТребования КАФКА.Использование SPARK наверняка.

EMR выглядит великолепно, но у меня сложилось впечатление, что для ученых-данных специалисту приходится делать все, что он хочет, когда хочет.Для более регулярного ETL мне интересно, подходит ли это.Обращение к меньшему количеству менеджеров, безусловно, является благом.

В документах по AWS я не могу найти однозначного ответа, отсюда и этот вопрос.

У меня сложилось впечатление, что с AMI и загрузкой собственных сервисов, чтоEMR - это, безусловно, один из способов, и EC2 больше подходит для кластера KAFKA или если вы действительно хотите контролировать свою собственную среду и инструменты полностью на основе, скажем, дистрибутива Cloudera как такового.

1 Ответ

0 голосов
/ 04 декабря 2018

Итак, ответ здесь для других, которым, возможно, потребуется оценить, какие варианты применимы для разгрузки, что угодно.Это на самом деле не так сложно в ретроспективе.Обратите внимание, что поставщики AZURE и не-AWS здесь не рассматриваются.В двух словах:

EMR - это управляемая служба Hadoop (PaaS) AWS

EMR предоставляет инструменты, которые, по мнению AMAZON, сделают эту работудля Data Science, Analytics и т. д. Но при необходимости вы можете «загрузить» свои собственные требования / программное обеспечение.

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

Эластичность, очевидно, применяется в большей степени, поэтому для вычисления данные должны быть там, пока они вам нужны.EMR полагается на S3 для сохранения результатов в долгосрочной перспективе.После сохранения один завершает EMR-кластер, а при необходимости запускает новый EMR-кластер и присоединяет сохраненные результаты S3 - если применимо - к этому новому кластеру.EMRFS позволяет S3 выглядеть как часть HDFS и обеспечивает легкий доступ.Существует хранилище на основе EBS, которое позволяет сохранять результаты в хранилище, привязанном к экземпляру EC2, на время этого экземпляра.

Это новый способ работы.У каждого есть доступ к «спотовым» экземплярам с явно спотовыми ценами.Выставление счетов менее предсказуемо, так как зависит от того, что вы делаете, но в целом может быть дешевле - при условии правильного управления.Примером этого является управление EMD-кластерами в компании Experia.

Нерегулярные запросы не очень хорошо обслуживаются с S3, поэтому вам потребуются другие управляемые сервисы AWS, такие как Presto / Athena или Redshift (Spectrum), который являетсядополнительный набор услуг и стоимость.Просто упомяну это из-за более низкой производительности S3.

EC2 (IaaS) более "традиционный"

Вы выбираете этот путь, если выВы хотите, чтобы экземпляры EC2 сами контролировали программное обеспечение и то, что вы хотите в своей среде Hadoop.

Экземпляры EC2 - виртуальные машины - имеют вычислительную мощность, память, временное хранилище на основе EBS и используют EFS для файловых систем для HDFS или, скажем, KUDU и S3.Доступ к S3 не так прост, как в EMRFS с EMR.

Вы сами устанавливаете и обслуживаете программное обеспечение Hadoop, применяете исправления и т. Д. Управление Hadoop в этих экземплярах EC2, конечно, не так уж сложноCloudera и Cloudbreak.

Тарификация является более предсказуемой, как можно утверждать, исходя из времени готовности экземпляра EC2, а биллинг применяется постоянно для любого постоянного хранилища.

Важный момент: можно объединить подход EC2, скажем, для загрузки DWH в Hadoop - если он «разгружается», и кластеров EMR для Data Science.

Местонахождение данных MR

Это не соблюдается в обоих подходах, если только не используются варианты с чистым металлом, но тогда упругость - E - сложнее дляобе стороны, что позволяет экономить средства.

Локальность данных, похоже, принимается большинством, но на самом деле она идет с облачными вычислениями, как и ожидалось, и кажется вполне приемлемой с точки зрения производительности для Data Science и т. Д.

Для специальных запросов AMAZONскажем, они не так уверены в S3, и по опыту использование EFS для HDFS / PARQUET или KUDU работает довольно быстро, по меньшей мере, по моему опыту, по крайней мере.

...