Любой специалист, который когда-либо работал с Big Data знает, что в подобных проектах большой не только объем данных. Также это внушительные вычислительные ресурсы, разветвленный технологический стек и мощная инфраструктура. Поэтому Big Data-проекты часто реализовывают в облаке. 

Меня зовут Алексей Бестужев, я архитектор VK Cloud, и в этой статье мы обсудим нюансы и неочевидные особенности запуска процессов при работе с большими данными в облаке. 

Материал подготовлен на основе нашего совместного вебинара с Кириллом Сливчиковым, управляющим партнером компании 7RedLines. 

Почему компании выбирают облака для работы с большими данными


Начну с того, что реализация Big Data-проектов — часто длительный и сложный процесс. В исследовании «Как компании реализуют Big Data-проекты в России?» мы определили, что сложности внедрения типовые. Основные — недостаток компетенций в команде и плохая каталогизация данных. Среди барьеров компании также называют затруднения при выборе технологического стека, неготовность ИТ-инфраструктуры и недостаточное финансирование Big Data-проектов. Некоторые организации сталкиваются со сложностью оценки ROI (Return on Investment, коэффициент возврата инвестиций) — универсальной модели расчета не существует.


С какими сложностями сталкиваются компании при реализации Big Data-проектов

Работа с облачными сервисами для Big Data-проектов позволяет обойти большинство из перечисленных ограничений, об этом поговорим ниже; а сейчас вернемся к нулевой точке, когда компания решила, что «бигдате — быть» и начала движение в сторону реализации проекта. 

Эволюция пользы Big Data-проектов 


Классическое внедрение проекта по работе с Big Data состоит из пяти этапов: 

  1. разработка концепции управления данными;
  2. разработка архитектуры;
  3. определение инфраструктуры и стека;
  4. реализация;
  5. сопровождение и развитие.

Проект важно начинать с разработки концепции управления данными: определить, на каком этапе работы с ними компания сейчас находится, и начать поступательное движение именно с этой точки. Путь от первого этапа к последнему — эволюционный: перепрыгнуть через любую из ступеней не получится, это отразится на качестве аналитики. Каждый этап аналитики ценен для бизнеса и предполагает уровень подготовки данных, экспертизы, инфраструктуры и инструментов.  

  • Описательная аналитика. Это первый этап работы с Big Data, на котором компании важно внедрить на организационном уровне подходы к работе с данными: организовать их сбор, очистку и структурирование. Это позволит создавать стандартные и Ad-hoc-/OLAP-отчеты для оценки произошедшего. Например, так можно обнаружить, что один из этапов воронки продаж является «узким горлышком», которое мешает достичь цели по выручке.
  • Предиктивная аналитика. Если данные систематически собираются, соблюдается политика Data Quality, данные полны, достоверны и связаны, то можно переходить к предиктивной аналитике. Такой подход позволит моделировать сценарии развития событий на основе собранных данных. Например, прогнозировать, как корректировка определенной метрики в воронке продаж могла бы повлиять на выручку компании в прошедших периодах, и уже на основе этого анализа корректировать дальнейшие действия. 
  • Предиктивное моделирование. После освоения работы с предиктивной аналитикой можно переходить к предиктивному моделированию и пытаться прогнозировать будущее. Например, какой будет динамика продаж компании с учетом множества переменных: внешних событий и внутренних факторов? Достоверность прогноза на этом этапе зависит от качества и полноты данных, качества моделей, а целесообразность применения такой аналитики — от готовности компании интегрировать результаты предиктивного анализа в бизнес-процессы и принимать решения с опорой на прогнозы. 
  • Прескриптивное управление. Прескриптивное управление позволяет находить наилучший вариант решения проблемы и отвечает на вопрос «Что нужно, чтобы…?». Метод позволяет получать аналитику на основе исторических и текущих данных о бизнес-процессах: он помогает построить множество сценариев развития событий в режиме реального времени и выбрать из них наиболее подходящий. Например, при каких условиях продажи увеличатся на n % в ситуации, когда на рынок оказывают влияние факторы a, b, c, d, x, а ситуация в компании обстоит определенным образом?

Определяемся с типом архитектуры 


В Big Data-проектах большое значение имеет концепция архитектуры хранилища. Она зависит от модели данных, алгоритма работы потоков и сложности проекта. Наиболее распространены четыре архитектуры DWH:

  1. Архитектура Ральфа Кимбалла. Простой вариант. Согласно концепции, хранилище — это набор витрин данных и ничего больше.
  2. Архитектура Билла Инмона. Усовершенствованная модель. Подразумевает наличие не только витрин, но и корпоративного слоя данных, который выполнен в модели 3NF или приближен к нему.
  3. Архитектура Дэна Линстедта. Модель хранилища, в которой с помощью архитектурных решений и выделения таблиц разных типов, в том числе для хранения историчности, стоимость вносимых изменений сильно снижена. Такая архитектура динамичнее предыдущих, удобнее в работе и не требует постоянной доработки.
  4. Архитектура EAV. Динамическая модель, в которой структура хранилища меняется добавлением не колонок, а строк. Это позволяет расширять модель практически бесконечно и дешево. Реализует принцип колоночного управления структурой данных и адаптирована для работы с колоночными СУБД.


Типы архитектур хранилища данных

Выбираем стек ПО под архитектуру


Для каждого из этапов работы с большими данными важно подобрать оптимальный набор инструментов с учетом нагрузки и задач. 

В облаке подбирать технологии удобно, поскольку в нем есть готовые инструменты для работы с данными (DataPaaS) — от преднастроенного Hadoop до сервисов BI-аналитики. Поэтому в облаке удобно как тестировать пилотные проекты и апробировать технологический стек, так и разворачивать полноценные решения для работы с данными.  

Администрирование инфраструктуры и Managed-сервисов выполняет провайдер, а бизнес может не расширять собственный ИТ-отдел для этих задач. Более того, у провайдера можно запрашивать экспертизу и рекомендации по реализации проекта. 

Рассмотрим один из вариантов архитектуры Big Data-решения с применением технологического стека на основе облачных сервисов на платформе VK Cloud.

Этап 
Компонент
Сервис VK Cloud
Источник
Передача данных или файлов разных форматов от устройств, систем и БД
Система-источник на стороне клиента
Озеро данных 
Хранение и обработка неструктурированных данных
Arenadata Hadoop
Корпоративное хранилище данных
Хранение структурированных данных
Arenadata DB (на базе Greenplum)
Витрины данных
Подготовка предметно-ориентированных выборок данных
ClickHouse
BI-системы
Подготовка отчетов и выгрузок данных, их визуализация для бизнес-пользователей
Apache Superset

В Big Data-проектах могут понадобиться дополнительные сервисы для инженеров данных и Data Scientists.


Пример архитектуры облачного Big Data-проекта с применением сервисов VK Cloud

Особенности развертывания проектов на облачной инфраструктуре


При реализации Big Data-проектов в облаке еще на этапе планирования или раннего внедрения надо учесть несколько моментов.

Обеспечить сетевую связность. Некоторые компании, у которых уже есть своя инфраструктура, хотят продолжать ее использовать в связке с облачной. Это можно организовать, но надо обеспечить сетевую связность: настроить коммуникацию, проработать алгоритм передачи данных от железа к облаку и учесть пропускную способность каналов.


Пример схемы реализации сетевой связности в облаке VK Cloud

Выбрать и согласовать меры информационной безопасности (ИБ). Перед развертыванием Big Data-проекта в облаке надо разработать и согласовать со службой информационной безопасности меры защиты данных. В том числе: какие данные будут передаваться, через какие каналы (выделенные или публичные), каким требованиям ИБ должно соответствовать облако (например, в VK Cloud инфраструктура соответствует требованиям 152-ФЗ и УЗ-1). Отдельно надо прорабатывать и соблюдать меры внутренней защиты, которые не входят в зону ответственности облачного провайдера. Например, настроить резервное копирование и сбор логов, разделение ролей и прав доступа, добавить средства аутентификации и авторизации и др. 

Проработать план миграции. Перенос данных без плана почти всегда обречен на провал. В плане надо учесть: какие данные надо перенести, сколько и в каком порядке, какие каналы использовать, когда именно переносить. При этом надо учитывать, можно ли остановить сервис — источник данных на период миграции.

Учитывать технические ограничения облака. Чтобы при реализации Big Data-проектов не возникло трудностей, еще на этапе планирования надо учесть технические возможности облачного провайдера. Например: пропускную способность, скорость подключения, предельные параметры виртуальных машин (ВМ), дисков, процессоров и отдельных компонентов. Эти ограничения будут влиять на формат архитектуры и стек технологий.

Использовать экспертизу облачного провайдера. Специалисты облачного провайдера зачастую имеют опыт участия в проектах с применением технологий для работы с Big Data. Их советы могут оказаться ценными для реализации проекта. Например, клиенты VK Cloud могут получить консультацию архитекторов, которые помогут подобрать оптимальную архитектуру и технологический стек, рассчитать необходимый объем ресурсов и не только. 

Что учесть и запомнить


Внедрение Big Data-проектов — не быстрый процесс. Согласно исследованию VK Cloud, на это зачастую уходит от одного до двух лет. Реже — от двух лет.



Внедрение состоит из пяти этапов: разработка концепции управления данными, разработка архитектуры, определение инфраструктуры и стека, реализация, развитие и сопровождение.



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



При внедрении Big Data-проектов некоторые компании создают отдел управления данными, для которого нужны специалисты разных направлений — от архитекторов до специалистов по качеству данных. Эта практика позволяет повысить эффективность внедрения проекта. 



При реализации Big Data-проектов в облаке зоны ответственности разделены между заказчиком, интегратором и облачным провайдером. Умелое применение экспертизы каждого из участников и их слаженная работа с учетом опыта каждой их сторон позволяет эффективнее реализовать Big Data-проекты любой сложности. 


За что конкретно отвечает заказчик, интегратор и облако при разделении зон ответственности

В облаке удобно реализовывать Big Data-проект. Необходимые вычислительные ресурсы и сервисы для работы с данными можно получить в несколько кликов, что значительно ускоряет запуск и реализацию проектов. Не нужно покупать и настраивать оборудование, готовить инфраструктуру, закупать и устанавливать ПО: облачный провайдер предложит преднастроенные инструменты и мощности для вашего проекта. Оплата облачных ресурсов — по модели Pay-as-you-go (только за фактически используемые ресурсы), а еще компания может заменить капитальные вложения (CAPEX) на операционные расходы (OPEX). 

Облака позволяют легко, часто автоматически, масштабировать объем используемых ресурсов для хранения данных, их обработки или аналитики. Причем в сторону как увеличения, так и уменьшения, когда нагрузка снижается. При этом оплата начисляется по модели Pay-as-you-go. С физической инфраструктурой это невозможно: оборудование надо закупать впрок с учетом пиковых нагрузок, что не всегда оправдано и допустимо по бюджету. 

Вы можете попробовать облачные сервисы VK Cloud для работы с Big Data. Для тестирования мы предоставляем расширенный грант, в рамках которого вы сможете использовать наши сервисы и инфраструктуру с оплатой по модели Pay-as-you-go, чтобы собрать прототип проекта и оценить его эффективность для своего бизнеса. Также мы предоставляем бесплатную консультацию архитектора (поможем выбрать стек технологий, построить архитектуру, расскажем про варианты на основе Open Source и проприетарного ПО) и поделимся, как работать с чувствительными данными в облаке и строить системы по требованиям ИБ.

Комментарии (21)


  1. mishamota
    06.02.2023 11:53
    +1

    В чем смысл разделения КХД и Витрин в представленной архитектуре, с учётом того, что и Кликхаус и Гринплам OLAP базы, и там и там структурированная информация?

    К тому же, Кликхаус,в отличие от Гринплама, имеет существенные ограничения по поддержке сложного SQL в кластере, если говорить про аналитические запросы, характерные для витрин данных.


    1. Ivan22
      06.02.2023 16:17
      +1

      да Кликхаус тут просто как быстрый кэш, никаких SQL трансформаций.

      А вот к выбору BI тула вопросы. Нужен PowerBi


      1. AlexeyBest Автор
        08.02.2023 17:19

        Сейчас выбор ограничен)
        Power BI - крутой инструмент, люблю его.


      1. vadim_bv
        09.02.2023 10:44

        Почему PowerBI, он же от Microsoft?
        Можно же отечественное решение использовать, тот же Visiology, который внешне похож на PowerBI.


    1. EvgenyVilkov
      08.02.2023 00:42

      Смысл в том что так говорит делать аренадата :)


    1. AlexeyBest Автор
      08.02.2023 17:15

      Всё-таки ClickHouse лучше работает с большим количеством подключений. Поэтому я бы начинал с Greenplum, а дальше при необходимости выносил нагрузку с витринами данных в ClickHouse.
      Также раньше BI вроде Power BI, Tableu и Click подгружали периодически данные в себя и визуализация строилась из загруженных данных в своё хранилище. А вот Superset и Redash работают только по модели Direct Query и каждое изменение параметра в визуализации может создавать нагрузку на КХД. Когда её слишком много, лучше использовать промежуточный ClickHouse.
      В конечном итоге я бы оставил ELT и хранилище в Greenplum, все данные в нормальной форме начиная с 3-ей. А вот в ClickHouse витрины в максимально плоском виде.


      1. Ivan22
        08.02.2023 20:29

        не раньше а и сейчас PowerBi и все продвинутые BI tools имею свою встроенную olap субд для кэшерования. А на счет подключений - опять же. PowerBi имеет один конекшен к субд, выкачивает данные, а пользуются им потом 100500 человек.


  1. EvgenyVilkov
    08.02.2023 00:43
    +1

    Первое правило бойцовского клуба - не устанавливаете hadoop в облаке.


    1. Ivan22
      08.02.2023 12:45

      второе правило бойцовского клуба  - вообще не устанавливайте hadoop


      1. EvgenyVilkov
        08.02.2023 12:51
        +1

        Нет, второе правило бойцовского клуба - в on-prem устанавливайте правильный Hadoop с правильным ruki.sys который может закрыть все задачи аналитического ландшафта.


    1. AlexeyBest Автор
      08.02.2023 17:17

      В целом Hadoop - вещь не для всех :) Лучше с S3 начать для хранения. На мой взгляд в облаке Hadoop можно использовать для обработки данных (Spark, Hive).

      А какие минусы использования Hadoop в облаке? Интересно синхронизироваться)


      1. 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


        1. AlexeyBest Автор
          08.02.2023 18:11

          Согласен! Не сравнивал бы Greenplum и Datalake на S3/HDFS, всё под свои задачи.

          Такое решение предлагали, но для заказчиков требования оказываются довольно высокими к техническим компетенциями: spark, kuber.


          Спасибо за развёрнутый ответ!


          1. EvgenyVilkov
            08.02.2023 18:27

            Ну потому что вы мыслите спарком. Если вы возьмете нормальный SQL like джижок, то узнаете что он не только быстрее чем GP в большинстве ETL, ad-hoc и BI задач, но и стоимость вычислений в облаке будет значительно ниже.


            1. Ivan22
              08.02.2023 18:50
              +1

              у нас сейчас Snowflake + azure data lake. Цена хранения копеечная, скорость обработки нас устраивает (притом она легко масштабируется). Никаких спарков не требуется, компетенции DE ограничиваютя умением SQL правильно писать. Никаких хадупов и куберов на пушечный выстрел никто сюда не подпустит


              1. EvgenyVilkov
                08.02.2023 19:10
                +1

                Где вы возьмете снежинку в VK клауде? Это главный вопрос. А так, подход правильный.


                1. Ivan22
                  08.02.2023 20:31

                  во-о-от. И тут вопрос нам шашечки или ехать. Нам VK клауд или чтоб работало


      1. Ivan22
        08.02.2023 18:55

        Hadoop в облаке никому не нужен, стораж - это s3 либо Azure DL, вычисления либо датабрикс либо сразу Snowflake. Администрирование в 100 раз проще, цены на хранение дешовые, порог входа для DE - минимальный. Проекты плодятся как грибы.

        Рекомендую как отличный пример:

        https://www.youtube.com/watch?v=XJa3gGWidg0


        1. EvgenyVilkov
          08.02.2023 19:17

          Да, облако VK оно ведь такое! Хочешь Azure DL, хочешь Snowflake. бери не хочу!


          1. Ivan22
            08.02.2023 19:49

            слава богу нам не надо юзать облако VK


          1. vadim_bv
            09.02.2023 10:50

            Уловил сарказм. А по сути что в VK cloud? Что-то своё? Arenadata Hadoop? (понимаю, что это принципиально другая технология, нежели тот же Snowflake)