Взгляд сверху на Big Data

~ 35 минут
Вы уже знакомы с архитектурами больших данных — Big Data. Рассмотрели DWH изнутри и узнали, что существует Data Lake.
В этом спринте мы подробнее рассмотрим этот вопрос и выявим особенности как монолитных, так и распределённых подходов. Это поможет вам эффективнее решать задачи бизнеса: будет проще определить оптимальный формат работы с большими данными в рамках стратегической и операционной деятельности компании. В условиях глобального тренда на искусственный интеллект накопление данных и их качественное использование становится конкурентным преимуществом.
Но сначала давайте поймём, что отличает архитектуру Big Data от других архитектур данных. Предлагаем подумать над вопросом, будет ли пара систем с СУБД уже считаться Big Data или нет.

Большие данные

✏️ Сам термин Big Data окончательно оформился в начале 2000-х и часто используется для обозначения структурированных и неструктурированных объёмов данных и подходов, инструментов и их методов обработки, которые слишком велики или сложны для обработки традиционными базами данных, инструментами и приложениями.
Появлялись социальные сети, развивались поисковики, основной доход которых идёт от рекламы. Как следствие, развивалась пользовательская аналитика, это повлияло на продажи.
Основным драйвером бизнеса всегда были и являются деньги. То есть большие данные появились в ситуации, когда компании решили перейти от накопительства к ещё большему накопительству. Они захотели использовать данные не только для SQL-отчётов и понимания «что было», а перейти к пониманию «почему это произошло» и в идеале «что происходит прямо сейчас». Для этого нужно ещё больше различных данных и подходов к их обработке.
Здесь и происходит разделение: традиционные способы обработки данных и сами традиционные данные отличаются от больших.
  • Объёмами (Volume): гигабайты или терабайты против петабайтов и эксабайтов больших данных.
  • Скоростью накопления (Velocity): традиционные данные обновляются периодически и в большинстве своём статичны, тогда как большие данные могут расти экспоненциально и поступают в режиме реального времени (данные телеметрии, соцсети и так далее).
  • Разнообразием (Variety): традиционные данные чаще всего структурированы и легко поддаются анализу, тогда как большие имеют высокую вариативность (видеоконтент, изображения, текстовые данные).
  • Достоверностью (Veracity): традиционные данные в силу своей меньшей вариативности, объёмов и структуры легче поддаются проверке, тогда как в больших может быть противоречивая информация, которая требует дополнительной обработки.
  • Ценностью (Value): данные сами по себе неважны, если из них невозможно извлечь полезную информацию, всегда есть необходимость поиска закономерностей в больших объёмах различной информации. Анализ данных должен приносить ценность для бизнеса или решать конкретные задачи.
Таких характеристик больших данных может быть и больше, но основными считаются первые три V: Volume, Velocity, Variety.
Если взять в расчёт эти признаки, становится понятно, что вопрос «Будет ли пара систем с СУБД уже Big Data?» не приведёт нас к нужному ответу. Чтобы определить принадлежность систем к Big Data, нужно уточнить их назначение, объёмы и вариативность. Вдруг, помимо СУБД, там хранят неструктурированный контент прямо на диске рядом с системами и используют ML и Deep Learning для получения инсайтов.
Предлагаем рассмотреть другую ситуацию: есть онлайн-магазин (маркетплейс), где в СУБД хранятся данные по заказам, клиентам и другие данные. И на основе этих данных периодически генерируются типовые отчёты.
Чтобы понять, будет ли такая система считаться Big Data, стоит взглянуть на признаки:
  • Объём может быть существенным, но петабайты накопятся, пожалуй, нескоро.
  • Вариативности нет: все данные заранее определены структурой.
  • Скорость может быть высокой в случае роста бизнеса или распродаж.
  • Достоверность быть, конечно, должна, иначе это какие-то странные продажи.
Вывод такой: сам по себе магазин не будет относиться Big Data. Но если добавить пользовательскую аналитику, где будет накапливаться различная информация о пользователях (отзывы, картинки, видео, поведение) и обработке контента от продавца (данные о качестве изображения), будут различные алгоритмы для работы с такими данными и прогнозирование, то это вполне можно считать большими данными.

Особенности работы с большими данными

Большие и разнородные данные нужно где-то хранить и эффективно использовать, поэтому появилась необходимость в архитектуре их обработки.
Первым решением стали хранилища данных (Data Warehouse, DWH), где данные структурировались и использовались для бизнес-аналитики. Затем, в качестве ответа на минусы этого подхода, появились озёра данных (Data Lake). Вы знакомы с этими архитектурами, но стоит вспомнить их особенности, чтобы понять, как появилось современное решение — Data Lakehouse.

Data Warehouse

Для Data Warehouse характерно, что процесс преобразования данных (ETL, Extract Transform Load) выполняется до того, как данные попадут в хранилище. Такая архитектура представляет собой единый источник «правды» в компании и служит основным компонентом отчётности и бизнес-аналитики.
DWH позволил бизнесу накапливать ещё больше данных и исследовать их с помощью витрин, где аналитики могли построить необходимый им срез.
Примеры DWH
  • Amazon Redshift,
  • Snowflake,
  • Google BigQuery,
  • Azure Synapse Analytics,
  • PostgreSQL.
Минусы этого типа архитектуры
  • Высокая стоимость традиционных хранилищ данных в условиях постоянно растущих объёмов данных: решения чаще всего вендорские и требуют лицензии.
  • DWH-структура не подходит для сложной обработки данных, как машинное обучение. Эти хранилища обычно содержат данные, относящиеся к конкретным задачам, в то время как машинное обучение и задачи, связанные с обработкой данных, требуют наличия всех собранных данных.
  • Неспособность обрабатывать неструктурированные данные, такие как аудио, видео, текстовые файлы и прочее.
Эти ограничения влияют на возможность понимания бизнесом «Почему это случилось». Поэтому продолжением эволюции стала архитектура озера данных (Data Lake).

Data Lake

Озеро данных представляет собой централизованное хранилище полуструктурированных, неструктурированных и структурированных данных сразу. Это даёт больше возможности по анализу. Данные хранятся в изначальном состоянии и обрабатываются уже в зависимости от потребности — подход ELT (Extract Load Transform).
На начальном этапе источники структурированных данных (СУБД, различные отчёты) и неструктурированных данных (информация социальных сетей, телеметрия, геоданные, контент) загружаются в хранилище неструктурированных данных (Raw Data Store).
✏️ Raw Data Store (хранилище необработанных данных) — это недорогое постоянное хранилище, способное хранить данные в больших объёмах.
У нас есть аналитическая «песочница» — некий аналог витрин данных. Она используется для анализа данных, создания прототипов, обработки данных и изучения данных для выдвижения новых гипотез и сценариев использования.
С помощью механизма пакетной обработки (Batch-Processing Engine) данные преобразуются из необработанных в структурированные данные. Ещё существует механизм обработки в реальном времени (Real-Time Processing Engine), который принимает потоковые данные и обрабатывает их. Данные попадают в хранилище обработанных данных и затем используются для анализа, составления отчётов и других целей конечными пользователями.
💡 После появления Data Lake компании смогли анализировать поведение пользователей, оптимизировать бизнес-процессы и улучшить производительность за счёт понимания, как работают процессы на основе анализа данных.
Для обработки на этом этапе развития архитектур в основном использовались подходы на базе Hadoop и MapReduce.
Примеры технологий, на которых можно построить Data Lake
  • S3 — популярное объектное хранилище (изначально от Amazon, но сейчас уже много S3-подобных хранилищ);
  • HDFS (Hadoop Distributed File System) — распределённая файловая система, предназначенная для работы с большими данными в экосистеме Hadoop на распределённых кластерах.
Минусы озёр
  • Озёра данных очень часто в силу «накопительства» и сложностей каталогизации всего этого превращаются в «болото данных».
  • В озёрах нет транзакционности: данные вполне могут быть противоречивыми, а бизнесу нужны достоверные отчёты.
  • Для запросов к озеру нужно иметь навыки инженера, нет схемы и аудита действий.
  • Низкое качество и целостность данных требуют дополнительных инструментов.
  • Существуют проблемы с безопасностью данных и управлением ими. В неструктурированных данных сложней каталогизировать чувствительную информацию и настроить уровни доступа к ней.

Сергей

Какой вывод?

Data Lake заменить Data Warehouse не смогли в силу их разного назначения. Поэтому частыми стали ситуации, когда в компании есть и то, и другое. Такую архитектуру называют двухуровневой. Ещё она известна как современное хранилище данных (Modern Data Warehouse). В этом случае Data Lake используют для стейджинга, подготовки данных и построения моделей машинного обучения, а DWH — для запросов и отчётности. Две технологии удачно дополняют друг друга и закрывают бо́льшую часть потребностей бизнеса.

Сергей

Как это выглядит?

Двухуровневая архитектура

Двухуровневая архитектура с Data Lake и Data Warehouse строится таким образом: все данные сначала попадают в озеро данных. В Data Lake хранятся сырые и разнородные данные в любом формате. Отсюда данные берутся для задач машинного обучения и Data Science, где важно работать с большими объёмами информации без предварительной обработки.
Часть данных из озера проходит этап ETL, где они очищаются, структурируются и попадают в хранилище данных (DWH). Здесь хранятся только те данные, которые подготовлены для использования в отчётах и бизнес-аналитике.
В этом случае у бизнеса есть операционные отчёты, которым можно верить (есть понимание, что случилось). А аналитики данных могут экспериментировать и использовать данные для понимания, почему что-то произошло, а затем создавать рекомендательные системы и прочее.
Тут могут использоваться, например:
  • ELT и ETL — AWS Glue, Google Dataflow, talend, Pantaho, Airflow;
  • Data Lake — S3, HDFS, GCS;
  • DWH — Snowflake, Amazon Redshift или Google BigQuery.
Основные минусы
  • сложность пайплайнов для данных,
  • стоимость поддержки и инфраструктуры.
И как решение этих проблем получился живой гибрид — Data Lakehouse. В прошлых спринтах о нём говорилось кратко, давайте разберёмся, в чём преимущества такой архитектуры.

Data Lakehouse

Гибридное решение принесло ряд полезных возможностей:
  • Требуется всего одно решение вместо двух (DWH и Data Lake);
  • Система получает транзакционность;
  • Есть возможность управлять схемой данных как в DWH с обеспечением целостности и полноты данных, а также надёжные механизмы управления и аудита;
  • Можно использовать BI напрямую на исходных данных;
  • Открытые форматы позволяют делать обработку бóльшим количеством инструментов;
  • Архитектура «заточена» под высокие нагрузки и AI-обработку;
  • Аудит, хранение, мониторинг происхождения и поддержка наблюдаемости, в том числе каталоги данных и показатели их использования;
  • Обеспечивается безопасность и контроль доступа.

Архитектура Data Lakehouse

Внутри Data Lakehouse представляет собой:
  • Хранилище — масштабируемое и гибкое решение для работы со структурированными, полуструктурированными и неструктурированными данными, такие как Amazon S3 или HDFS.
  • Уровень метаданных — единый каталог, который предоставляет метаданные для всех объектов в хранилище и позволяет управлять данными (транзакции, версионирование, управление схемой и другое). Реализуется на основе открытого Apache Iceberg, Delta Lake или Apache Hudi.
Кажется, что у этого решения всё слишком хорошо. Но у этой архитектуры есть существенный минус — сложность построения и достаточно небольшое количество реальных внедрений.
На этом основные варианты монолитных архитектур для обработки больших данных заканчиваются, а распределённые мы посмотрим в следующих уроках. В этом уроке осталось ответить только на один вопрос.

Сергей

Как выбрать подходящую архитектуру?

💡Перед выбором подходящей архитектуры важно:
  • Понять количество источников данных, а также какие данные вы планируете использовать и их формат;
  • Оценить объём этих данных и скорость накопления;
  • Определить, зачем вам эти данные (строить отчёты, обучать нейронные сети или, может быть, всё вместе);
  • Понять, точно ли у вас большие данные.

Что почитать про проектирование хранилищ данных

Задание 1

Управляющая компания ЖКХ внедрила систему управления умными устройствами в жилых домах, которая:
  • считывает данные с умных счётчиков воды и электричества, обновляя информацию раз в день;
  • хранит клиентскую базу с историей заявок и платежей;
  • обрабатывает данные о состоянии систем отопления и освещения в зданиях в режиме реального времени;
  • использует SQL-отчёты для анализа расхода коммунальных услуг.
Можно ли считать, что компания работает с Big Data?

Задание 2

Сопоставьте характеристику Big Data с действиями, которые её обеспечивают.
Внедрение мониторинга и сбор данных с устройств в реальном времени
Velocity
Расширение системы хранения для работы с петабайтами данных
Volume
Анализ данных разных типов: текстовых запросов, изображений неисправностей, видеопотоков
Variety
Установление алгоритмов проверки данных на соответствие требованиям и устранение противоречий
Veracity

Задание 3

Компания рассматривает внедрение Data Lakehouse. Какое из утверждений лучше описывает преимущества этого подхода?

Задание 4

Компания собирает данные из множества источников — базы данных клиентов, лог-файлов, социальных сетей и IoT-устройств. Объём данных достигает 50 терабайт ежемесячно, и они поступают в реальном времени. На основе этих данных требуется:
  1. Проводить продвинутую аналитическую обработку для обучения моделей машинного обучения.
  2. Создавать достоверные отчёты для бизнес-анализа в реальном времени.
  3. Управлять доступом к данным и обеспечивать транзакционную целостность.
Какую архитектуру следует выбрать для решения задач компании?

Итоги

  • С появлением цифровых технологий и интернета объёмы данных начали расти экспоненциально, что сделало традиционные методы обработки недостаточными. Большие данные отличаются от обычных по объёму, скорости поступления, разнообразию и достоверности. Эти особенности потребовали новых подходов для хранения и обработки данных.
  • DWH является оптимальным решением для бизнес-аналитики и отчётности. Такая архитектура помогает объединить данные из хранилищ и привести к единому формату, но исходные данные в DWH не сохраняются, поэтому в случае «битых» входных данных придётся их снова загружать.
  • Data Lake подходит как для хранения, так и для обработки. Такая архитектура позволяет хранить в исходном состоянии поступающую от источников информацию. Это отличное решение для выполнения аналитических задач посредством AI, но в силу своей неструктурированности не очень подходит для достоверных отчётов для бизнеса, поэтому будьте готовы, что после внедрения Data Lake вам понадобится и DWH.
  • Data Lakehouse — это решение с возможностями и DWH, и Data Lake, но заплатить придётся потенциальным недостатком экспертизы на рынке и сложностью в поддержке.