![](https://habrastorage.org/webt/yx/ci/_m/yxci_m53vubfnyblhhx-n5vubes.png)
Любой специалист, который когда-либо работал с Big Data знает, что в подобных проектах большой не только объем данных. Также это внушительные вычислительные ресурсы, разветвленный технологический стек и мощная инфраструктура. Поэтому Big Data-проекты часто реализовывают в облаке.
Меня зовут Алексей Бестужев, я архитектор VK Cloud, и в этой статье мы обсудим нюансы и неочевидные особенности запуска процессов при работе с большими данными в облаке.
Материал подготовлен на основе нашего совместного вебинара с Кириллом Сливчиковым, управляющим партнером компании 7RedLines.
Почему компании выбирают облака для работы с большими данными
Начну с того, что реализация Big Data-проектов — часто длительный и сложный процесс. В исследовании «Как компании реализуют Big Data-проекты в России?» мы определили, что сложности внедрения типовые. Основные — недостаток компетенций в команде и плохая каталогизация данных. Среди барьеров компании также называют затруднения при выборе технологического стека, неготовность ИТ-инфраструктуры и недостаточное финансирование Big Data-проектов. Некоторые организации сталкиваются со сложностью оценки ROI (Return on Investment, коэффициент возврата инвестиций) — универсальной модели расчета не существует.
![](https://habrastorage.org/webt/jh/pz/6f/jhpz6fib2uastbuyiwvsuy7hv7k.jpeg)
С какими сложностями сталкиваются компании при реализации Big Data-проектов
Работа с облачными сервисами для Big Data-проектов позволяет обойти большинство из перечисленных ограничений, об этом поговорим ниже; а сейчас вернемся к нулевой точке, когда компания решила, что «бигдате — быть» и начала движение в сторону реализации проекта.
Эволюция пользы Big Data-проектов
Классическое внедрение проекта по работе с Big Data состоит из пяти этапов:
- разработка концепции управления данными;
- разработка архитектуры;
- определение инфраструктуры и стека;
- реализация;
- сопровождение и развитие.
Проект важно начинать с разработки концепции управления данными: определить, на каком этапе работы с ними компания сейчас находится, и начать поступательное движение именно с этой точки. Путь от первого этапа к последнему — эволюционный: перепрыгнуть через любую из ступеней не получится, это отразится на качестве аналитики. Каждый этап аналитики ценен для бизнеса и предполагает уровень подготовки данных, экспертизы, инфраструктуры и инструментов.
-
Описательная аналитика. Это первый этап работы с Big Data, на котором компании важно внедрить на организационном уровне подходы к работе с данными: организовать их сбор, очистку и структурирование. Это позволит создавать стандартные и Ad-hoc-/OLAP-отчеты для оценки произошедшего. Например, так можно обнаружить, что один из этапов воронки продаж является «узким горлышком», которое мешает достичь цели по выручке.
-
Предиктивная аналитика. Если данные систематически собираются, соблюдается политика Data Quality, данные полны, достоверны и связаны, то можно переходить к предиктивной аналитике. Такой подход позволит моделировать сценарии развития событий на основе собранных данных. Например, прогнозировать, как корректировка определенной метрики в воронке продаж могла бы повлиять на выручку компании в прошедших периодах, и уже на основе этого анализа корректировать дальнейшие действия.
-
Предиктивное моделирование. После освоения работы с предиктивной аналитикой можно переходить к предиктивному моделированию и пытаться прогнозировать будущее. Например, какой будет динамика продаж компании с учетом множества переменных: внешних событий и внутренних факторов? Достоверность прогноза на этом этапе зависит от качества и полноты данных, качества моделей, а целесообразность применения такой аналитики — от готовности компании интегрировать результаты предиктивного анализа в бизнес-процессы и принимать решения с опорой на прогнозы.
-
Прескриптивное управление. Прескриптивное управление позволяет находить наилучший вариант решения проблемы и отвечает на вопрос «Что нужно, чтобы…?». Метод позволяет получать аналитику на основе исторических и текущих данных о бизнес-процессах: он помогает построить множество сценариев развития событий в режиме реального времени и выбрать из них наиболее подходящий. Например, при каких условиях продажи увеличатся на n % в ситуации, когда на рынок оказывают влияние факторы a, b, c, d, x, а ситуация в компании обстоит определенным образом?
Определяемся с типом архитектуры
В Big Data-проектах большое значение имеет концепция архитектуры хранилища. Она зависит от модели данных, алгоритма работы потоков и сложности проекта. Наиболее распространены четыре архитектуры DWH:
-
Архитектура Ральфа Кимбалла. Простой вариант. Согласно концепции, хранилище — это набор витрин данных и ничего больше.
-
Архитектура Билла Инмона. Усовершенствованная модель. Подразумевает наличие не только витрин, но и корпоративного слоя данных, который выполнен в модели 3NF или приближен к нему.
-
Архитектура Дэна Линстедта. Модель хранилища, в которой с помощью архитектурных решений и выделения таблиц разных типов, в том числе для хранения историчности, стоимость вносимых изменений сильно снижена. Такая архитектура динамичнее предыдущих, удобнее в работе и не требует постоянной доработки.
-
Архитектура EAV. Динамическая модель, в которой структура хранилища меняется добавлением не колонок, а строк. Это позволяет расширять модель практически бесконечно и дешево. Реализует принцип колоночного управления структурой данных и адаптирована для работы с колоночными СУБД.
![](https://habrastorage.org/webt/de/5n/jp/de5njplunetqmwjzeoqxaaxcs8m.png)
Типы архитектур хранилища данных
Выбираем стек ПО под архитектуру
Для каждого из этапов работы с большими данными важно подобрать оптимальный набор инструментов с учетом нагрузки и задач.
В облаке подбирать технологии удобно, поскольку в нем есть готовые инструменты для работы с данными (DataPaaS) — от преднастроенного Hadoop до сервисов BI-аналитики. Поэтому в облаке удобно как тестировать пилотные проекты и апробировать технологический стек, так и разворачивать полноценные решения для работы с данными.
Администрирование инфраструктуры и Managed-сервисов выполняет провайдер, а бизнес может не расширять собственный ИТ-отдел для этих задач. Более того, у провайдера можно запрашивать экспертизу и рекомендации по реализации проекта.
Рассмотрим один из вариантов архитектуры Big Data-решения с применением технологического стека на основе облачных сервисов на платформе VK Cloud.
Этап |
Компонент |
Сервис VK Cloud |
Источник |
Передача данных или файлов разных форматов от устройств, систем и БД |
Система-источник на стороне клиента |
Озеро данных |
Хранение и обработка неструктурированных данных |
Arenadata Hadoop |
Корпоративное хранилище данных |
Хранение структурированных данных |
Arenadata DB (на базе Greenplum) |
Витрины данных |
Подготовка предметно-ориентированных выборок данных |
ClickHouse |
BI-системы |
Подготовка отчетов и выгрузок данных, их визуализация для бизнес-пользователей |
Apache Superset |
В Big Data-проектах могут понадобиться дополнительные сервисы для инженеров данных и Data Scientists.
![](https://habrastorage.org/webt/cf/rx/8u/cfrx8uctp6jdznxk1g1b80f6goy.png)
Пример архитектуры облачного Big Data-проекта с применением сервисов VK Cloud
Особенности развертывания проектов на облачной инфраструктуре
При реализации Big Data-проектов в облаке еще на этапе планирования или раннего внедрения надо учесть несколько моментов.
Обеспечить сетевую связность. Некоторые компании, у которых уже есть своя инфраструктура, хотят продолжать ее использовать в связке с облачной. Это можно организовать, но надо обеспечить сетевую связность: настроить коммуникацию, проработать алгоритм передачи данных от железа к облаку и учесть пропускную способность каналов.
![](https://habrastorage.org/webt/zd/lx/3b/zdlx3bzs6tmxu8gdrcckd_6d2fa.png)
Пример схемы реализации сетевой связности в облаке VK Cloud
Выбрать и согласовать меры информационной безопасности (ИБ). Перед развертыванием Big Data-проекта в облаке надо разработать и согласовать со службой информационной безопасности меры защиты данных. В том числе: какие данные будут передаваться, через какие каналы (выделенные или публичные), каким требованиям ИБ должно соответствовать облако (например, в VK Cloud инфраструктура соответствует требованиям 152-ФЗ и УЗ-1). Отдельно надо прорабатывать и соблюдать меры внутренней защиты, которые не входят в зону ответственности облачного провайдера. Например, настроить резервное копирование и сбор логов, разделение ролей и прав доступа, добавить средства аутентификации и авторизации и др.
Проработать план миграции. Перенос данных без плана почти всегда обречен на провал. В плане надо учесть: какие данные надо перенести, сколько и в каком порядке, какие каналы использовать, когда именно переносить. При этом надо учитывать, можно ли остановить сервис — источник данных на период миграции.
Учитывать технические ограничения облака. Чтобы при реализации Big Data-проектов не возникло трудностей, еще на этапе планирования надо учесть технические возможности облачного провайдера. Например: пропускную способность, скорость подключения, предельные параметры виртуальных машин (ВМ), дисков, процессоров и отдельных компонентов. Эти ограничения будут влиять на формат архитектуры и стек технологий.
Использовать экспертизу облачного провайдера. Специалисты облачного провайдера зачастую имеют опыт участия в проектах с применением технологий для работы с Big Data. Их советы могут оказаться ценными для реализации проекта. Например, клиенты VK Cloud могут получить консультацию архитекторов, которые помогут подобрать оптимальную архитектуру и технологический стек, рассчитать необходимый объем ресурсов и не только.
Что учесть и запомнить
Внедрение Big Data-проектов — не быстрый процесс. Согласно исследованию VK Cloud, на это зачастую уходит от одного до двух лет. Реже — от двух лет.
![](https://habrastorage.org/webt/h5/h9/uw/h5h9uw5vqkten_5nuh9hhb1u8q4.jpeg)
Внедрение состоит из пяти этапов: разработка концепции управления данными, разработка архитектуры, определение инфраструктуры и стека, реализация, развитие и сопровождение.
![](https://habrastorage.org/webt/uc/zr/tw/uczrtwohzjb7099iymvfjnocvks.jpeg)
На каждом из этапов внедрения надо решить много задач, каждая из которых требует определенной экспертизы. Поэтому для реализации проекта или его отдельных этапов компании нередко привлекают внешних интеграторов.
![](https://habrastorage.org/webt/zp/54/vf/zp54vfbqof43tqngk8bjr8-gcli.jpeg)
При внедрении Big Data-проектов некоторые компании создают отдел управления данными, для которого нужны специалисты разных направлений — от архитекторов до специалистов по качеству данных. Эта практика позволяет повысить эффективность внедрения проекта.
![](https://habrastorage.org/webt/-z/zx/6p/-zzx6pgzk7wpxaynmyrfuqn2zoq.jpeg)
При реализации Big Data-проектов в облаке зоны ответственности разделены между заказчиком, интегратором и облачным провайдером. Умелое применение экспертизы каждого из участников и их слаженная работа с учетом опыта каждой их сторон позволяет эффективнее реализовать Big Data-проекты любой сложности.
![](https://habrastorage.org/webt/4e/2m/dp/4e2mdpf-wkrxgi4nasbp0fzvi6m.jpeg)
За что конкретно отвечает заказчик, интегратор и облако при разделении зон ответственности
В облаке удобно реализовывать Big Data-проект. Необходимые вычислительные ресурсы и сервисы для работы с данными можно получить в несколько кликов, что значительно ускоряет запуск и реализацию проектов. Не нужно покупать и настраивать оборудование, готовить инфраструктуру, закупать и устанавливать ПО: облачный провайдер предложит преднастроенные инструменты и мощности для вашего проекта. Оплата облачных ресурсов — по модели Pay-as-you-go (только за фактически используемые ресурсы), а еще компания может заменить капитальные вложения (CAPEX) на операционные расходы (OPEX).
Облака позволяют легко, часто автоматически, масштабировать объем используемых ресурсов для хранения данных, их обработки или аналитики. Причем в сторону как увеличения, так и уменьшения, когда нагрузка снижается. При этом оплата начисляется по модели Pay-as-you-go. С физической инфраструктурой это невозможно: оборудование надо закупать впрок с учетом пиковых нагрузок, что не всегда оправдано и допустимо по бюджету.
Вы можете попробовать облачные сервисы VK Cloud для работы с Big Data. Для тестирования мы предоставляем расширенный грант, в рамках которого вы сможете использовать наши сервисы и инфраструктуру с оплатой по модели Pay-as-you-go, чтобы собрать прототип проекта и оценить его эффективность для своего бизнеса. Также мы предоставляем бесплатную консультацию архитектора (поможем выбрать стек технологий, построить архитектуру, расскажем про варианты на основе Open Source и проприетарного ПО) и поделимся, как работать с чувствительными данными в облаке и строить системы по требованиям ИБ.
Комментарии (21)
EvgenyVilkov
08.02.2023 00:43+1Первое правило бойцовского клуба - не устанавливаете hadoop в облаке.
Ivan22
08.02.2023 12:45второе правило бойцовского клуба - вообще не устанавливайте hadoop
EvgenyVilkov
08.02.2023 12:51+1Нет, второе правило бойцовского клуба - в on-prem устанавливайте правильный Hadoop с правильным ruki.sys который может закрыть все задачи аналитического ландшафта.
AlexeyBest Автор
08.02.2023 17:17В целом Hadoop - вещь не для всех :) Лучше с S3 начать для хранения. На мой взгляд в облаке Hadoop можно использовать для обработки данных (Spark, Hive).
А какие минусы использования Hadoop в облаке? Интересно синхронизироваться)
EvgenyVilkov
08.02.2023 17:38+2Минус в том что HDFS в облаке звучит дико, учитывая требования к дисковой подсистеме, которые в облаке никак не обеспечишь и симметричность масштабирования Hadoop как такового (диски и вычислительные мощности заканчиваются по разному, а масштабируются всегда вместе)
Правильное решение:
S3 + managed k8s над которым compute сервисы в виде spark и чего то для SQL (Impala Presto\Trino, но конечно же не HIVE). В итоге честный pay as you go и стоимость вычислений самая низкая из тех что можно придумать. Ниже даже чем тот же GreenPlum в SaaS
AlexeyBest Автор
08.02.2023 18:11Согласен! Не сравнивал бы Greenplum и Datalake на S3/HDFS, всё под свои задачи.
Такое решение предлагали, но для заказчиков требования оказываются довольно высокими к техническим компетенциями: spark, kuber.
Спасибо за развёрнутый ответ!EvgenyVilkov
08.02.2023 18:27Ну потому что вы мыслите спарком. Если вы возьмете нормальный SQL like джижок, то узнаете что он не только быстрее чем GP в большинстве ETL, ad-hoc и BI задач, но и стоимость вычислений в облаке будет значительно ниже.
Ivan22
08.02.2023 18:50+1у нас сейчас Snowflake + azure data lake. Цена хранения копеечная, скорость обработки нас устраивает (притом она легко масштабируется). Никаких спарков не требуется, компетенции DE ограничиваютя умением SQL правильно писать. Никаких хадупов и куберов на пушечный выстрел никто сюда не подпустит
EvgenyVilkov
08.02.2023 19:10+1Где вы возьмете снежинку в VK клауде? Это главный вопрос. А так, подход правильный.
Ivan22
08.02.2023 18:55Hadoop в облаке никому не нужен, стораж - это s3 либо Azure DL, вычисления либо датабрикс либо сразу Snowflake. Администрирование в 100 раз проще, цены на хранение дешовые, порог входа для DE - минимальный. Проекты плодятся как грибы.
Рекомендую как отличный пример:
EvgenyVilkov
08.02.2023 19:17Да, облако VK оно ведь такое! Хочешь Azure DL, хочешь Snowflake. бери не хочу!
vadim_bv
09.02.2023 10:50Уловил сарказм. А по сути что в VK cloud? Что-то своё? Arenadata Hadoop? (понимаю, что это принципиально другая технология, нежели тот же Snowflake)
mishamota
В чем смысл разделения КХД и Витрин в представленной архитектуре, с учётом того, что и Кликхаус и Гринплам OLAP базы, и там и там структурированная информация?
К тому же, Кликхаус,в отличие от Гринплама, имеет существенные ограничения по поддержке сложного SQL в кластере, если говорить про аналитические запросы, характерные для витрин данных.
Ivan22
да Кликхаус тут просто как быстрый кэш, никаких SQL трансформаций.
А вот к выбору BI тула вопросы. Нужен PowerBi
AlexeyBest Автор
Сейчас выбор ограничен)
Power BI - крутой инструмент, люблю его.
vadim_bv
Почему PowerBI, он же от Microsoft?
Можно же отечественное решение использовать, тот же Visiology, который внешне похож на PowerBI.
EvgenyVilkov
Смысл в том что так говорит делать аренадата :)
AlexeyBest Автор
Всё-таки ClickHouse лучше работает с большим количеством подключений. Поэтому я бы начинал с Greenplum, а дальше при необходимости выносил нагрузку с витринами данных в ClickHouse.
Также раньше BI вроде Power BI, Tableu и Click подгружали периодически данные в себя и визуализация строилась из загруженных данных в своё хранилище. А вот Superset и Redash работают только по модели Direct Query и каждое изменение параметра в визуализации может создавать нагрузку на КХД. Когда её слишком много, лучше использовать промежуточный ClickHouse.
В конечном итоге я бы оставил ELT и хранилище в Greenplum, все данные в нормальной форме начиная с 3-ей. А вот в ClickHouse витрины в максимально плоском виде.
Ivan22
не раньше а и сейчас PowerBi и все продвинутые BI tools имею свою встроенную olap субд для кэшерования. А на счет подключений - опять же. PowerBi имеет один конекшен к субд, выкачивает данные, а пользуются им потом 100500 человек.