Глава 1 «Big Data» — Data Architectures

Перевод первой главы Big Data.

Big Data — Большие данные

Число компаний, создающих архитектуры данных, значительно увеличилось в 2020-х годах. Этот рост вряд ли замедлится в ближайшее время, главным образом благодаря тому, что объем доступных данных достиг беспрецедентного уровня. Данные поступают из социальных сетей, устройств Интернета вещей (IoT), собственных приложений и программного обеспечения сторонних разработчиков, чтобы назвать лишь несколько источников.

Согласно исследованию BCG, проведенному в 2023 году, «объем генерируемых данных примерно удвоился с 2018 по 2021 годы, достигнув около 84 зеттабайт, и ожидается, что темпы роста сохранятся». Исследователи прогнозируют, что «объем данных будет увеличиваться с совокупным среднегодовым темпом роста (CAGR) в 21% с 2021 по 2024 год, достигнув 149 зеттабайт». Компании понимают, что могут сэкономить миллионы долларов и увеличить доходы, собирая эти данные и используя их для анализа прошлого и настоящего, а также для прогнозирования будущего. Но для этого им необходим способ хранения всех этих данных.

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

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

Все сводится к тому, чтобы доставить нужную информацию нужным людям в нужное время и в нужном формате. Для этого вам нужна архитектура данных, которая может принимать, хранить, преобразовывать и моделировать данные (обработка больших данных), чтобы их можно было точно и легко использовать. Такая архитектура должна позволять любому конечному пользователю, даже обладающему минимальными техническими знаниями, анализировать данные и генерировать отчеты и дашборды, не полагаясь на специалистов из IT-отдела с глубокими техническими навыками.

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

Что такое большие данные и как они могут вам помочь?

Несмотря на то что термин «большие» используется применительно к данным, речь идет не только о размере данных. Речь также обо всех данных, больших или малых, как внутри вашей компании, так и за ее пределами, которые могли бы быть вам полезны. Данные могут быть в любом формате и собираться с любой регулярностью.

Таким образом, лучший способ определить большие данные — это рассматривать их как все данные, независимо от их размера (объем), скорости (скорость поступления) или типа (разнообразие). Помимо этих критериев, есть еще три фактора, которые можно использовать для описания данных: достоверность (veracity), изменчивость (variability) и ценность (value). Вместе они известны как «шесть V» больших данных, как показано на рисунке 1-1.

Рисунок 1-1. Шесть «V» больших данных (источник: The Cloud Data Lake Рукмани Гопалан [O’Reilly, 2023]).

Рассмотрим каждую из них подробнее.

Объем (Volume)

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

Разнообразие (Variety)

Разнообразие описывает широкий спектр источников и форматов данных. Данные можно разделить на:

  • структурированные (например, из реляционных баз данных),
  • полуструктурированные (такие как логи, форматы CSV, XML и JSON),
  • неструктурированные (например, электронные письма, документы, PDF),
  • бинарные данные (изображения, аудио, видео).

Например, данные из системы ввода заказов будут структурированными, так как они поступают из реляционной базы данных, а данные от IoT-устройства, скорее всего, будут представлены в формате JSON.

Скорость (Velocity)

Скорость касается темпов генерации и обработки данных. Нечастый сбор данных называется пакетной обработкой (batch processing); например, заказы за день собираются и обрабатываются ночью. Данные также могут собираться с высокой частотой или в реальном времени, особенно если они генерируются с высокой скоростью, как данные из социальных сетей, IoT-устройств или мобильных приложений.

Достоверность (Veracity)

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

Изменчивость (Variability)

Изменчивость касается согласованности (или несогласованности) данных в их формате, качестве и значении. Обработка структурированных, полуструктурированных и неструктурированных данных требует разных инструментов и методов. Например, тип, частота и качество данных с датчиков IoT могут значительно варьироваться. Датчики температуры и влажности могут генерировать данные с регулярными интервалами, в то время как датчики движения — только при обнаружении движения.

Ценность (Value)

Ценность, самый важный «V», относится к полезности и релевантности данных. Компании используют большие данные для получения инсайтов и принятия решений, которые могут привести к бизнес-выгоде, такой как повышение эффективности, снижение затрат или создание новых источников дохода. Например, анализируя данные о клиентах, организации могут лучше понять их поведение, предпочтения и потребности. Это позволяет разрабатывать более целевые маркетинговые кампании, улучшать клиентский опыт и увеличивать продажи.

Collecting big data (Сбор больших данных)

Сбор больших данных позволяет компаниям получать инсайты для улучшения бизнес-решений.

Прогнозная аналитика (Predictive Analysis) — это вид анализа данных, который использует статистические алгоритмы и машинное обучение для анализа исторических данных и прогнозирования будущих событий и трендов. Это позволяет бизнесу действовать проактивно, а не реактивно.

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

Данные подобны нефти по нескольким причинам:

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

Например, с помощью больших данных можно создавать отчеты и дашборды, которые покажут, где продажи отстают, и принимать меры «задним числом» для их улучшения. Можно также использовать машинное обучение для прогнозирования, где продажи будут падать в будущем, и принимать проактивные меры для предотвращения этого падения. Это называется бизнес-аналитикой (BI) — процессом сбора, анализа и использования данных для помощи бизнесу в принятии более информированных решений.

Как показано на Рисунке 1-2, данные можно собирать из новых источников, таких как IoT-устройства, веб-логи и социальные сети, а также из старых источников, таких как приложения ERP, CRM и системы управления операциями. Эти данные могут быть в различных форматах, таких как файлы CSV, JSON или Parquet. Они могут поступать пакетно (например, раз в час) или стримингом в реальном времени с частотой несколько раз в секунду.

Рисунок 1-2. Обработка больших данных (Источник: The Cloud Data Lake Рукмани Гопалан [O’Reilly, 2023])

Важно, чтобы компании понимали, где они находятся на своем пути использования данных относительно других. Это называется зрелостью данных (data maturity), и в следующем разделе описаны этапы этого пути, чтобы вы могли определить, на каком уровне находится ваша компания.

Зрелость данных (Data Maturity)

Вы, возможно, слышали термин «цифровая трансформация», который описывает процесс внедрения технологий в бизнес-процессы компаний для их фундаментального изменения с целью получения ценности из данных, улучшения операций и предоставления ценности клиентам. Этот процесс предполагает отказ от традиционных, ручных или бумажных процессов в пользу цифровых, с использованием технологий для повышения эффективности, продуктивности и инновационности.

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

Эта цифровая трансформация делится на четыре стадии, называемые этапами зрелости данных в организации (см. Рисунок 1-3). Эти этапы описывают уровень развития и зрелости организации в управлении, использовании и извлечении ценности из данных. Модель позволяет оценить способности организации к управлению данными и готовность к применению аналитики, искусственного интеллекта и других инициатив на основе данных. Каждый этап отражает шаг вперед в использовании данных для извлечения бизнес-ценности и принятия решений.

Рисунок 1-3. Этапы зрелости данных в организации

Этап 1: Реактивный (Reactive)

На первом этапе данные разрознены — скорее всего, они хранятся в Excel-таблицах и/или локальных базах данных на разных файловых системах и пересылаются по электронной почте. Архитекторы данных называют это «spreadmart» (сокращение от «spreadsheet data mart») — неформализованное, децентрализованное хранилище данных, часто встречающееся в организациях, которые используют электронные таблицы для хранения, управления и анализа данных.

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

Spreadmarts страдают от:

  • несоответствия данных,
  • отсутствия управления,
  • ограниченной масштабируемости,
  • неэффективности (из-за дублирования усилий).

Этап 2: Информативный (Informative)

На втором этапе зрелости компании начинают централизовать свои данные, что упрощает анализ и отчетность. Этапы 1 и 2 ориентированы на историческую отчетность (то есть на анализ трендов и событий из прошлого), поэтому их называют «зеркалом заднего вида» (rearview mirror). На этих этапах вы реагируете на то, что уже произошло.

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

Большинство компаний находятся именно на этом этапе, особенно если их инфраструктура остается on-premises (локальной).

Этап 3: Прогнозирующий (Predictive)

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

На этом этапе также улучшается процесс принятия решений за счет внедрения машинного обучения (advanced analytics), что позволяет принимать решения в реальном времени.

Например, пользователь заходит в интернет-магазин, и система рекомендует дополнительные книги на странице оформления заказа, основываясь на его предыдущих покупках.

Этап 4: Трансформирующий (Transformative)

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

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

Этапы 3 и 4 являются ключевыми в контексте этой книги. В частности, когда конечные пользователи самостоятельно занимаются созданием отчетов, это называется самообслуживанием в бизнес-аналитике (self-service BI), что является темой следующего раздела.

Самообслуживание в бизнес-аналитике (Self-Service Business Intelligence)

Ранее, если конечному пользователю в организации требовался отчет или дашборд, он должен был:

  1. Собрать все свои требования (какие источники данных необходимы и как должен выглядеть отчет или дашборд).
  2. Заполнить форму запроса в IT.
  3. Ждать.

IT-отдел затем выполнял следующие шаги:

  1. Извлекал данные.
  2. Загружал их в хранилище данных.
  3. Создавал модель данных.
  4. Наконец, генерировал отчет или дашборд.

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

Сегодня этот подход называется «традиционной BI» (traditional BI), так как на смену ему пришло самообслуживание BI.

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

Как этого достичь?

IT-отдел должен предварительно провести анализ потребностей пользователей, выяснив, какие данные им необходимы.

На основании этих потребностей строится архитектура данных, ориентированная на конечных пользователей.

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

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

Создание решения, которое легко воспринимается конечными пользователями, приводит к реализации концепции самообслуживания в BI. Создание отчета должно быть настолько простым, чтобы пользователи могли буквально перетаскивать поля в рабочей области. Им не нужно разбираться в том, как объединить данные из разных таблиц или беспокоиться о производительности отчета.

Когда вы разрабатываете решение для работы с данными, всегда задавайте себе вопрос:
«Насколько просто будет людям создавать собственные отчеты?»

Резюме

В этой главе вы узнали, что такое большие данные и как они могут помочь вам и вашей организации принимать более взвешенные бизнес-решения, особенно в сочетании с машинным обучением. Вы изучили шесть характеристик больших данных (6 Vs) и поняли, что такое зрелость данных (data maturity) и как определить её этапы. Наконец, вы познакомились с различиями между традиционной бизнес-аналитикой (traditional BI) и самообслуживанием в BI (self-service BI), где цель заключается в том, чтобы каждый мог быстро и легко использовать данные для создания отчетов и выявления инсайтов.

Теперь позвольте рассказать, чего ожидать в следующих главах.

Глава 2 будет посвящена тому, что такое архитектура данных. Вы получите обзор изменений типов архитектур данных за последние годы.

Глава 3 покажет, как проводить сессии проектирования архитектуры, чтобы определить, какая архитектура данных лучше всего подойдет для ваших целей.

Часть II: Общие концепции архитектуры данных

Глава 4 расскажет, что такое хранилище данных (data warehouse), зачем его использовать и что им не является. Мы рассмотрим подход сверху вниз (top-down approach), обсудим, действительно ли реляционное хранилище данных устарело, и изучим способы его наполнения.

Глава 5 описывает, что такое data lake, зачем он нужен, а также подход снизу вверх (bottom-up approach). В ней также будет разбор дизайна data lake и случаев, когда стоит использовать несколько data lakes.

Глава 6 охватывает ключевые концепции архитектуры данных, связанные с хранилищами, включая витрины данных (data marts), операционные хранилища (operational data stores), управление мастер-данными (master data management) и виртуализацию данных (data virtualization).

Глава 7 фокусируется на архитектурных концепциях, связанных с проектированием, включая OLTP и OLAP, операционные и аналитические данные, SMP и MPP, архитектуры Lambda и Kappa, а также полиглотную персистентность (polyglot persistence).

Глава 8 посвящена моделированию данных, включая реляционное и многомерное моделирование, дебаты между подходами Кимбалла и Инмона, общую модель данных (common data model) и хранилища данных (data vaults).

Глава 9 будет о загрузке данных (data ingestion), где мы обсудим ELT и ETL, обратный ELT (reverse ETL), пакетную обработку против обработки в реальном времени, а также управление данными (data governance).

Часть III: Конкретные архитектуры данных

Глава 10 описывает современное хранилище данных (modern data warehouse) и пять этапов его построения.

Глава 11 охватывает архитектуру data fabric и её сценарии использования.

Глава 12 объясняет архитектуру data lakehouse и компромиссы при отказе от реляционного хранилища данных.

Глава 13 и 14 посвящены архитектуре data mesh.

Глава 13 сосредоточена на децентрализованном подходе data mesh, четырёх принципах data mesh, а также описывает, что такое домены данных и продукты данных.

Глава 14 рассматривает проблемы и вызовы при создании data mesh, а также опровергает распространённые мифы. Эта глава поможет вам оценить готовность к внедрению data mesh и представить, каким будет его будущее.

Глава 15 исследует причины успехов и провалов проектов, а также описывает организацию команды, необходимую для построения архитектуры данных.

Глава 16 завершает обсуждением open-source решений, преимуществ облака, крупных облачных провайдеров, использования мультиоблака и программных фреймворков.

Теперь я готов перевернуть ваш мир данных. Вы готовы?

0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x