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

Путь от монолита к разделению Compute и Storage: пример поиска «хранилища мечты» для большой аналитической платформы

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров3.3K
Всего голосов 16: ↑16 и ↓0+16
Комментарии6

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

Разделение Compute и Storage  это случаем не CQRS?

Нет. В статье описан подход к разделению монолитного Hadoop на независимые системы хранения и вычисления.

хм, может "не догнал". Можно по подробней про самое деление данных на хранение и для вычислений? Как реализовано, ведь в аналитике может внезапно потребоваться совершенно неожиданный набор данных.

Мы у себя разделили не наборы данных, а сами компоненты хранения и вычисления в Hadoop. Хранение перенесли в Apache Ozone, а вычисление в Spark on k8s. Тегирование данных в данной статье не рассматривалось.

Поясните, пожалуйста, как 5% просадка производительности привела к сокращению количества стоек в 4 раза?

В отличии от hadoop, рекомендуемый объем одного узла для Ozone больше. 500Тб против 100Тб у hadoop. Отсюда и выйгрыш по количеству стоек. Интегральная производительсть чтения при этом проседает всего на 5%.

Разработчики Ozone заявляют, что озон сохраняет высокие показатели производитедьности чтения, и при узлах объемом до 1Пб. Но мы такой сценарий не тестировали.

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