Как стать автором
Обновить

Комментарии 9

Кстати, количество физических устройств Snowball в регионе тоже конечно и при планировании очень больших миграций это нужно выяснить предварительно у AWS и быть готовым, что заказать разом десяток может и не удастся.
>Для миграции есть много продуктов: Hadoop, Hive, Yarn, Spark, Kafka, Zookeeper, Jupyter, Zeppelin.
Вообще в отрыве от контекста эта фраза выглядит как будто эти продукты предназначены для миграции (являются ее инструментом), в то время как на самом деле автор скорее всего имеет в виду, что это их нужно мигрировать.
А можно простой вопрос? Какого размера хадуп кластер вы бы стали мигрировать? Исходя из вашего текста, и например вот этого:

до сих пор нет способов обеспечить высокую доступность (HA) для главных узлов NameNode или YARN ResourceManager.


я бы для себя сделал вывод, что эти ограничения довольно маленькие. Мы у себя вылезли на пределы масштабирования некоторых компонентов, например таких как YARN ResourceManager, Hive metastore, Sentry, причем по некоторым — довольно давно, а HA для NameNode на мой взгляд — так это просто must have. Причем ограничения масштабирования Sentry, к примеру, проявляются уже на довольно небольшом кластере, порядка 30 узлов примерно.

А можно поподробнее про ваш Sentry? Сколько узлов? Сколько трафика идет на Sentry? Размер БД?

Ну, я не админ, поэтому могу наврать в чем-то.

Насколько я помню, это во-первых, была старая версия клоудеры, возможно в более новой что-то оптимизировали (5.x.y).

Главная проблема, как ее озвучили в поддержке, в том, что у нас много групп и объектов, в итоге получалось что-то типа декартова произведения (ну, не буквально, но надеюсь понятно) из сочетаний объектов и прав на них.

Ну и где-то на уровне либо базы, либо сервиса все и тормозило, и падало.

А про размер кластера я выше писал — на менее чем 30 узлах кластера это уже вполне себя проявляло. Не исключаю, что многие с таким не столкнутся, впрочем. А у YARN проблемы уже на других масштабах, сильно побольше.
я такое видел, когда от многих тысяч баз данных hive metastore поплохело (GC + out of memory). но все легко решилось выделением ему побольше памяти.
в этом плане врядли, есть реальные проблемы. просто 30+ узлов уже на дефолтных настройках не поедут.
>выделением ему побольше памяти
Пробовали, настройки сентри давно не дефолтные. Помогало временно. Все равно сентри — это в некотором смысле горлышко, которое не масштабируется вместе с остальным.

Ну а Hive Metastore… да, там тоже десятки тысяч баз примерно, не без этого. Вот когда на них на всех накладываются роли и права роль->база, тут-то сентри и плохеет.

Вообще я бы сказал, что уже все сервисы, которые не масштабируются так же просто, как например датаноды, по ним по всем видно вот эти вот пределы. То есть кроме озвученных — еще и IPA например.

С учетом контекста хадупа, речь идет о sentry.apache.org, системе RBAC, а не о том Sentry который отвечает за трекинг исключений.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий