Проектирование озера данных с открытым исходным кодом

[azzas]

Я дико извиняюсь за вопрос не по теме, но что на первой фотке? Титульной фотке, так сказать.

[CoolJuice]

Да, это фильм Чужой. Если быть точным, то это панель управления корабля Ностромо, из этого фильма.

[akryukov]

Вроде бы архитектура правильно написана, но я не пойму, при чем тут kubernetes?

[CoolJuice]

Это один из вариантов DevOps-подхода для построения гибридных решений. Важная деталь в обсуждении методов разворачивания озёр данных — это привязка к поставщику. Kubernetes де факто стал отраслевым стандартом из-за его возможностей к переносу. Если мы используем Kubernetes, такое решение поможет без лишних сложностей развернуть сервис в AWS, GCP, Azure или где-то ещё. Прагматично подходя к проблеме привязки к провайдеру, мы объединяем мощь облачных сервисов с возможностью перенести сервисы куда угодно.

[akryukov]

Какой организацией "стандартизирован" ваш отраслевой стандарт?
Вы желаемое за действительное выдаёте. В бигдате на своем железе это сборка cloudera или horthonworks без прослойки с виртуализацией. А на облачных сервисах из коробки есть и Спарк и Кафка и все остальное.

[nad_oby]

Все еще хуже.
Та-же клоудера и хортон могут преспокойно разворачиваться в облаке.
Это частый случай если переносят "on premises" в облако как есть.

[CoolJuice]

О том, что kubernetes стал де факто отраслевым стандартом говорим не мы, kubernetes был передан консорциуму The Linux Foundation, который как раз и занимается стандартизацией и продвижением продуктов на базе открытого ПО, так же об этом говорит большая распространённость и поддержка этого инструмента большинством провайдеров, так же, косвенно может служить подтверждением разработка стандартов для kubernetes такими независимыми организациями, как Center for Internet Security и др. И речь шла именно об общих подходах для публичных/гибридных решений на базе открытого ПО, о чем в статье и было упомянуто.

[akryukov]

Я не ставлю под сомнение его всеобщую распространенность. (хотя стоило бы)
Моя претензия в том, что вы его позиционируете как решение для бигдаты. А это неправильно. Spark и hive это не вебсервисы, которые и с базой и с внешним миром работают через сеть. Для ETL очень важно, чтобы данные были на той же железной машине, что и исполняемый код. Передавать данные по сети для обработки — ненужные накладные расходы.

[CoolJuice]

Вы говорите абсолютно верно про накладные расходы. Но случаи и ситуации бывают разные, я описал общее решение, которое позволило бы комбинировать/портировать инфру с минимальными потерями. Если бы я описывал что-то более конкретное, а не общее, то взял бы другой кейс. Никто не мешает видоизменить схему под собственные нужны. Как я уже писал, прагматично подходя к проблеме привязки к провайдеру, можно объединить мощь облачных сервисов с возможностью перенести куда угодно. Итоговая же реализация будет продиктована разными требованиями бизнеса, бюджета и времени.