О сетке данных вкратце

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

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

Теперь, если вы похожи на меня и потратили значительную часть своей карьеры на размышления о базах данных, вы, возможно, подумаете: «Кое-что из этого кажется знакомым». И вы будете правы. Давайте разбираться.

Децентрализация, ориентированная на домен: вид сверху

В сетке данных каждый домен (например, маркетинг, продажи, логистика) владеет своими данными и отвечает за их предоставление остальной части организации. Это может показаться чем-то новым, но не так уж далеко от того, как мы годами представляли себе VIEW в базах данных.

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

Напомним, что нематериализованное представление — это виртуальная таблица, которая не хранит данные физически. Вместо этого она при каждом обращении к ней генерирует результаты на основе запроса динамически. Например, предположим, что отдел маркетинга хочет поделиться показателями вовлеченности клиентов с отделом продаж. Они могут создать нематериализованное представление под названием customer_engagement_summary, чтобы выбирать соответствующие поля, такие как customer_id, last_login, и recent_purchases из подробных таблиц. Это представление данных в упрощенном формате позволяет отделу продаж получать актуальную информацию, не вникая в сложности схемы маркетинговой базы данных.

В каком-то смысле нематериализованные представления базы данных были нашей первой попыткой создать продукты с данными, ориентированными на домены. Представление могло объединять сложные данные конкретного домена, представляя только то, что необходимо другим частям системы. Команда маркетологов могла создать представление customer_summary, а команда логистов — представление shipping_status. Каждый «домен» (в данном случае команда или отдел) отвечал за поддержание своих представлений, чтобы они точно отражали данные.

Данные как продукт: материализация имеет значение

Концепция «данных как продукта» в рамках сетки данных подразумевает, что к данным нужно относиться как к полноценному продукту, уделяя внимание их качеству, документации и потребностям потребителей. С точки зрения баз данных, в качестве продуктов данных могут выступать как не материализованные, так и материализованные представления, каждое из которых имеет свои преимущества.

Нематериализованные представления похожи на «живые» продукты с данными. Они инкапсулируют бизнес-логику и предоставляют единый интерфейс для потребителей данных, всегда отражая текущее состояние данных.

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

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

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

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

Инфраструктура самообслуживания: база данных как платформа

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

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

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

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

Федеративное управление: ограничения и контракты

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

Однако найти золотую середину между автономностью и стандартизацией может быть непросто. Слишком жесткий контроль может подавлять нововведения, а слишком слабый может привести к сценарию «Дикого Запада» с несовместимыми форматами данных и дырами в безопасности. Если в каждом домене используется свои кодировка данных или соглашение об именовании, интеграция данных между доменами превращается в настоящий кошмар. Чтобы решить эту проблему, организации могут внедрить набор «контрактов данных» — соглашений, определяющих ожидаемые форматы данных, стандарты качества и протоколы доступа к данным. Эти контракты служат общим языком и набором ожиданий. Они гарантируют, что, несмотря на независимую работу доменов, домены в рамках более крупной экосистемы остаются совместимыми и безопасными.

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

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

Вывод: все новое — хорошо забытое старое

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

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

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

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

Далее я расскажу, как применять эти принципы в GlareDB, чтобы создавать архитектуры в стиле «сетки данных». Мы подробно рассмотрим, как GlareDB упрощает создание архитектур в стиле «сетки данных», позволяя командам разработчиков без труда создавать собственные продукты на основе данных и управлять ими, обеспечивая при этом эффективное управление и высокую производительность.

Сетка данных на практике с GlareDB

Уникальные функции GlareDB делают ее идеальным инструментом реализации архитектур сетки данных. Ее способность объединять различные источники данных, создавать представления на основе нескольких источников и материализовывать продукты данных идеально соответствует принципам сетки данных. Далее расскажем о том, как GlareDB может стать вашим основным инструментом для создания сетки данных и управления ею.

Мы рассмотрели концепции сетки данных с точки зрения традиционного проектирования баз данных. Теперь посмотрим, как GlareDB может воплотить эти концепции в жизнь.

Децентрализация, ориентированная на домен: соединить все

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

Допустим, ваша команда маркетологов использует Postgres, команда продаж — MongoDB, а команда логистики хранит данные в бакетах S3. С помощью GlareDB вы можете подключаться ко всем этим источникам:

CREATE EXTERNAL DATABASE marketing_db
FROM postgres
OPTIONS (
    host = 'marketing.db.example.com',
    port = '5432',
    user = 'glaredb',
    password = 'password',
    database = 'marketing'
);

CREATE EXTERNAL DATABASE sales_db
FROM mongodb
OPTIONS (
    connection_string = 'mongodb://sales.db.example.com:27017'
);

CREATE EXTERNAL TABLE logistics_data
FROM s3
OPTIONS (
    location = 's3://logistics-bucket/shipping_data/*.parquet',
    file_type = 'parquet'
);

Теперь у вас есть доступ ко всем этим источникам данных для конкретных доменов через всего один экземпляр GlareDB. Каждая команда может продолжать использовать привычные инструменты. GlareDB действует как слой унификации.

Данные как продукт: представления и материализация

В сетке данных каждый домен отвечает за предоставление своих данных как продукта. Представления и возможности материализованных данных GlareDB подходят для этого идеально.

Создадим представление о клиенте customer_360, объединяющее данные нескольких доменов:

CREATE VIEW customer_360 AS
SELECT 
    m.customer_id,
    m.email,
    m.customer_segment,
    s.lifetime_value,
    l.last_shipment_date
FROM marketing_db.customers AS m
JOIN sales_db.customer_sales AS s ON m.customer_id = s.customer_id
JOIN logistics_data AS l ON m.customer_id = l.customer_id;

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

COPY (
    SELECT * FROM customer_360
) TO './materialized_customer_360.parqeut';

Теперь у нас есть продукт с материализованными данными, который дает более высокую производительность запросов. Операция GlareDB COPY TO позволяет обновлять это материализованное представление, соблюдая баланс актуальности данных и производительности запросов.

Инфраструктура самообслуживания данных: GlareDB как платформа

Самообслуживание в сетке данных позволяет командам доменов управлять собственными продуктами данных. GlareDB поддерживает это управление несколькими способами. Это:

1. Простая настройка — команды могут легко добавлять источники данных в GlareDB без сложных процессов ETL.
2. Гибкое развертывание — GlareDB может работать локально, в облаке или встраиваться в приложения, предоставляя командам свободу в работе с данными.
3. Интерфейс SQL — знакомый интерфейс SQL означает, что командам не нужно изучать новые языки запросов.

Например, команда может использовать биндинг GlareDB к Python, чтобы настроить автоматическое обновление данных:

import glaredb

def refresh_customer_360():
    con = glaredb.connect("glaredb://<user>:<password>@<org>.remote.glaredb.com:6443/<deployment-name>")
    con.execute("""
        COPY (SELECT * FROM customer_360)
        TO './materialized_customer_360.parquet';
    """)

# Запускать эту функцию по расписанию

Этот скрипт может быть частью собственного конвейера CI/CD команды, что позволит им самостоятельно управлять своим продуктом данных.

Федеративное управление — согласованность доменов

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

1. Согласованный язык запросов — интерфейс SQL для различных источников данных. GlareDB обеспечивает согласованный способ взаимодействия с данными во всей организации.
2. Контроль доступа — подключение GlareDB к внешним базам данных учитывает средства контроля доступа уровнем ниже, что помогает поддерживать политики безопасности.
3. Проверка качества данных — представления в GlareDB могут содержать проверку качества данных либо путем фильтрации некорректных данных, чтобы продукты данных соответствовали стандартам организации, либо путем интеграции с другими библиотеками качества данных, такими как Great Expectations, Soda Data или metaplane.

Заключение. GlareDB как инструмент для создания сетки данных

Уникальное сочетание функций GlareDB — подключение к различным источникам данных, создание представлений на основе нескольких источников, материализованные представления продуктов данных и согласованный интерфейса SQL — делают его идеальным инструментом реализации архитектур сетки данных.

С помощью GlareDB вы сможете:

• Соблюдать границы домена, предоставляя обмен данными.
• Легко создавать продукты данных и обслуживать их.
• Расширить возможности команд с помощью инфраструктуры самообслуживания данных.
• Внедрить федеративное управление с помощью согласованных интерфейсов и проверок качества данных.

Читайте также:

• Мой опыт добавления нереляционной MongoDB в кластер Kubernetes
• SQL в браузере  —  веб-оболочка DuckDB для анализа локальных данных
• SCDB: простая Open Source БД типа «ключ — значение»

Читайте нас в Telegram, VK и Дзен

---

Переводы статей Sam Kleinman: Data Mesh: From the Database’s Point of View, Data Mesh in Practice with GlareDB