Справочник

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

→Pub/Sub для приема -> Dataflow (потоковая передача) для преобразования -> BigQuery со потоковыми вставками или Storage Write API для аналитики.

Почему: Это канонический бессерверный, автоматически масштабируемый шаблон потоковой передачи. Пакетная обработка (например, Dataproc) не соответствовала бы требованиям низкой задержки.

Конвейер данных должен справляться с непредсказуемыми скачками трафика (например, 10-кратный сезонный объем), сохраняя при этом низкую задержку.

→Используйте полностью управляемые, автоматически масштабируемые сервисы: Pub/Sub для приема, Dataflow с включенным автомасштабированием и BigQuery для хранения.

Почему: Управляемые сервисы автоматически масштабируют ресурсы в соответствии с нагрузкой, избегая затрат на избыточное выделение ресурсов и обеспечивая производительность при пиковом трафике.

Мигрировать большое локальное хранилище данных Hadoop/Hive в Google Cloud.

→Мигрируйте данные в Cloud Storage, затем загрузите в BigQuery. Замените Hive/Spark SQL на BigQuery для бессерверной аналитики. Используйте Dataproc для заданий Spark, которые нелегко преобразовать в SQL.

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

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

→Публикуйте сообщения в Pub/Sub с ключом упорядочивания. Обрабатывайте с помощью потокового конвейера Dataflow, который гарантирует обработку по порядку для заданного ключа.

Почему: Ключи упорядочивания Pub/Sub в сочетании с Dataflow обеспечивают управляемую, масштабируемую, упорядоченную и ровно однократную обработку без ручного управления состоянием.

Источник↗

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

→Используйте Cloud Storage в качестве уровня хранения. Используйте Dataflow как для пакетной, так и для потоковой обработки. Используйте Dataplex с Data Catalog для управления метаданными, обнаружения и управления.

Почему: Эта архитектура разделяет хранение и вычисления, позволяя использовать несколько механизмов обработки (Dataflow, Dataproc) на центральном хранилище данных с унифицированным управлением.

Конвейер, обрабатывающий конфиденциальные данные (например, PHI, PII), должен соответствовать таким правилам, как HIPAA или GDPR.

→Включите Cloud Audit Logs для всего доступа к данным. Внедрите VPC Service Controls для создания периметра безопасности, предотвращающего эксфильтрацию данных.

Почему: Ведение журналов аудита критически важно для отслеживания доступа к данным в целях соответствия требованиям. VPC Service Controls обеспечивают надежную защиту от эксфильтрации данных, что является ключевым требованием для конфиденциальных данных.

Архитектура Lambda с отдельными пакетными и скоростными уровнями должна представлять единое представление данных.

→Используйте BigQuery для уровня обслуживания. Используйте оператор MERGE для обновления/вставки пакетно обработанных данных в главную таблицу, перезаписывая потоковые данные за тот же период. Предоставьте представление, которое объединяет исторические пакетные данные с потоковыми данными в реальном времени за текущий период.

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

Внедрить децентрализованную архитектуру Data Mesh, где домены владеют своими продуктами данных.

→Используйте Dataplex для федеративного управления домено-специфичными "озерами" и "зонами". Используйте наборы данных BigQuery для каждого домена. Используйте Analytics Hub для обмена продуктами данных между доменами.

Почему: Dataplex предоставляет центральную плоскость управления, обеспечивая при этом автономию доменов, что является основным принципом Data Mesh.

Объединить озеро данных и хранилище данных, позволяя выполнять задания Spark на необработанных данных и быстрые SQL-запросы на курируемых данных.

→Храните данные в открытых форматах (Iceberg, Delta Lake) в Cloud Storage. Используйте BigLake для предоставления унифицированного уровня управления и доступа. Запрашивайте данные как из Dataproc (Spark), так и из BigQuery.

Почему: BigLake позволяет запрашивать данные непосредственно в Cloud Storage с производительностью BigQuery и детализированной безопасностью, объединяя озеро и хранилище.

Разработайте стратегию аварийного восстановления для критически важного хранилища данных BigQuery с низким RPO (например, 1 час).

→Настройте межрегиональную репликацию наборов данных BigQuery для критически важных наборов данных. Используйте Terraform или Dataform для управления схемами и определениями представлений. Организуйте переключение с помощью Cloud Functions, запускаемых оповещениями Cloud Monitoring.

Почему: Межрегиональная репликация обеспечивает постоянно обновляемую, доступную для запросов копию в регионе аварийного восстановления, соответствующую низким требованиям RPO/RTO для критически важных данных.

Непрерывно реплицировать изменения из базы данных OLTP (например, Oracle, PostgreSQL, MySQL) в BigQuery с низкой задержкой.

→Используйте Datastream для выполнения Change Data Capture (CDC). Настройте его для потоковой передачи изменений непосредственно в BigQuery, который применяет их с помощью своей функции MERGE.

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

Источник↗

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

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

Почему: Модель Dataflow с водными знаками, триггерами и допустимым опозданием предоставляет надежную основу для балансирования полноты и задержки при работе с неупорядоченными данными.

Конвейер Dataflow, записывающий данные в BigQuery, сталкивается с дубликатами после перезапусков или временных сбоев.

→Используйте приемник BigQuery Storage Write API (STORAGE_WRITE_API) с методом, установленным в "at-least-once" (по умолчанию, ранее STREAMING_INSERTS) или "exactly-once" (режим COMMITTED).

Почему: Storage Write API в режиме COMMITTED обеспечивает встроенную семантику "exactly-once" для потоковой передачи, устраняя необходимость в пользовательской логике дедупликации.

Прием данных из страничного, с ограничением скорости REST API с использованием Dataflow.

→Используйте SplittableDoFn для параллельной обработки страничного источника. Реализуйте логику ограничения скорости (например, с использованием Guava RateLimiter) и экспоненциальную задержку для повторных попыток внутри DoFn.

Почему: SplittableDoFn позволяет динамически перераспределять работу. Сочетание его с ограничением скорости и логикой повторных попыток создает отказоустойчивый и эффективный шаблон для работы с внешними API.

Один поток данных необходимо записать в несколько назначений (например, BigQuery, Bigtable, Cloud Storage).

→В одном конвейере Dataflow после первоначальной обработки примените несколько писателей PTransform к одной и той же конечной PCollection.

Почему: Шаблон "веерной" записи (fan-out) высокоэффективен, так как данные обрабатываются только один раз. Он позволяет избежать затрат и сложности запуска нескольких отдельных конвейеров, читающих из одного и того же источника.

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

→Используйте шаблон бокового ввода (side input) в Dataflow. Загрузите таблицу измерений как PCollectionView. Настройте периодический триггер для обновления бокового ввода по расписанию, предотвращая перезапуски конвейера.

Почему: Боковые входы транслируют данные измерений всем рабочим для быстрого поиска в памяти, избегая вызовов API/БД для каждого элемента. Периодическое обновление эффективно обрабатывает изменения.

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

→Создайте кластер Dataproc с политикой автомасштабирования. Определите минимальное/максимальное количество первичных и вторичных рабочих узлов. Политика будет масштабировать кластер на основе метрик YARN.

Почему: Автомасштабирование оптимизирует затраты, сопоставляя ресурсы кластера с потребностями задания, масштабируясь вверх при больших нагрузках и вниз в периоды простоя.

Конвейер Dataflow требует пользовательских бинарных файлов, проприетарных библиотек или определенных версий, отсутствующих в стандартных образах рабочих узлов, и должен работать в VPC без доступа в интернет.

→Создайте пользовательский образ контейнера со всеми предварительно установленными зависимостями. Загрузите образ в Artifact Registry. Разверните конвейер с помощью Flex Template, который ссылается на пользовательский контейнер.

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

Задание Dataflow или Spark, выполняющее GroupByKey, работает медленно, потому что некоторые ключи имеют непропорционально много значений ("горячий ключ").

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

Почему: Эта техника "веерного" распределения (fanout) вручную разделяет работу для горячего ключа, позволяя обрабатывать его параллельно и преодолевать узкое место.

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

→В DoFn используйте блок try-catch для парсинга. Используйте DoFn с несколькими выходами и TupleTag для маршрутизации валидных записей в основной выход и невалидных записей (с контекстом ошибки) в отдельный выход ошибок. Перенаправьте PCollection ошибок в целевое назначение для "мертвых" писем (dead-letter queue), например, в тему Pub/Sub или таблицу BigQuery.

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

Запросы BigQuery работают медленно и дорого, обычно фильтруя по столбцу даты/времени и другим столбцам с высокой кардинальностью (например, customer_id).

→Разбейте таблицу на разделы по столбцу даты/времени (например, ежедневные разделы). Кластеризуйте таблицу по четырем часто фильтруемым столбцам (например, customer_id, product_category).

Почему: Разделение сокращает объем сканируемых данных только до соответствующих временных периодов. Кластеризация дополнительно сортирует данные внутри разделов, минимизируя объем данных, сканируемых для фильтров по кластеризованным столбцам. Это основной шаблон настройки производительности BQ.

Источник↗

Приложение требует чтения и записи с низкой задержкой (менее 10 мс) для огромных наборов данных (миллиарды строк), например, для персонализации в реальном времени или хранилища признаков IoT.

→Используйте Bigtable. Разработайте ключ строки, который поддерживает основной шаблон доступа. Для временных рядов используйте entity_id#reverse_timestamp.

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

Транзакционное приложение требует глобального распределения, горизонтальной масштабируемости и строгой согласованности с SQL-интерфейсом.

→Используйте Cloud Spanner с многорегиональной конфигурацией.

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

Хранилище данных BigQuery содержит большие объемы исторических данных, которые запрашиваются нечасто, но должны быть сохранены, что приводит к высоким затратам на хранение.

→Не требуется никаких действий для разделов/таблиц, не изменяемых в течение 90 последовательных дней. BigQuery автоматически применяет ценообразование на долгосрочное хранение, что приводит к снижению затрат примерно на 50%.

Почему: Это автоматическая, встроенная оптимизация. Ручное перемещение данных в GCS (если только не для уровня Archive) часто излишне и добавляет сложности.

Данные в корзине Cloud Storage имеют предсказуемый шаблон доступа: частый в течение 30 дней, случайный в течение 90 дней, затем редкий.

→Настройте политику жизненного цикла корзины для перехода объектов: Standard -> Nearline (через 30 дней) -> Coldline (через 90 дней).

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

Таблица BigQuery должна обеспечивать ограничение уникальности ключа.

→Обеспечьте уникальность в конвейере загрузки. Используйте оператор MERGE с логикой, которая вставляет данные только тогда, когда ключ еще не существует. Альтернативно, используйте состояние DoFn в Dataflow для дедупликации.

Почему: BigQuery не обеспечивает соблюдение ограничений PRIMARY KEY или UNIQUE. Уникальность должна управляться процессом загрузки данных.

Таблица измерений в BigQuery должна поддерживать полную историю изменений для анализа на определенный момент времени (SCD Type 2).

→Добавьте столбцы временных меток valid_from и valid_to. При изменении используйте оператор MERGE для обновления valid_to в старой записи и вставки новой записи.

Почему: Это стандартный шаблон для реализации SCD Type 2 в хранилище данных. MERGE предоставляет эффективный, атомарный способ выполнения необходимых операций обновления и вставки.

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

→Используйте Firestore в нативном режиме. Используйте коллекции, документы и подколлекции для моделирования данных. Создавайте составные индексы для сложных запросов.

Почему: Firestore — это бессерверная документоориентированная база данных NoSQL, оптимизированная для транзакционных нагрузок с широкими возможностями запросов, в отличие от Bigtable (ключ-значение) или BigQuery (аналитическая).

Необходимо запрашивать данные в Cloud Storage (Parquet, Avro и т. д.) через BigQuery, обеспечивая при этом детальную безопасность (на уровне строк/столбцов).

→Создайте таблицы BigLake поверх данных Cloud Storage. Примените политики безопасности BigQuery на уровне строк и столбцов к таблицам BigLake.

Почему: BigLake расширяет управление BigQuery на данные в открытых форматах в Cloud Storage, обеспечивая безопасную, унифицированную архитектуру Lakehouse.

Команде специалистов по данным необходимо обучать модели машинного обучения на больших наборах данных BigQuery без перемещения или экспорта данных.

→Используйте BigQuery ML. Пишите операторы CREATE MODEL на SQL для обучения, оценки и прогнозирования непосредственно в BigQuery.

Почему: BQML устраняет перемещение данных, упрощает рабочий процесс ML и использует вычислительную мощность BigQuery, ускоряя итерации.

Источник↗

Модели ML требуют признаков как для пакетного обучения, так и для онлайн-вывода с низкой задержкой, с согласованностью между ними, чтобы избежать перекоса.

→Используйте Vertex AI Feature Store. Принимайте признаки с помощью пакетной или потоковой передачи. Он предоставляет офлайн-хранилище (BigQuery) для обучения и онлайн-хранилище (Bigtable) для обслуживания с низкой задержкой.

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

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

→Реализуйте семантический слой Looker с использованием LookML. Определите измерения, меры и соединения один раз. Пользователи исследуют управляемую модель вместо необработанных таблиц.

Почему: LookML предоставляет "единый источник истины" для бизнес-логики, обеспечивая согласованную и точную отчетность, при этом позволяя самообслуживаемое исследование.

Необходимо реализовать автоматизированные проверки качества данных (нулевые значения, уникальность, диапазоны значений) и мониторинг данных в BigQuery и Cloud Storage.

→Используйте Dataplex Data Quality. Определяйте правила в YAML или используйте автоматически сгенерированные правила из профилирования. Планируйте сканирования для мониторинга качества с течением времени.

Почему: Dataplex предоставляет управляемое, интегрированное решение для качества данных, которое более масштабируемо и поддерживаемо, чем пользовательские SQL-проверки или скрипты.

Обнаружить естественные группировки или сегменты в наборе данных клиентов без предопределенных меток.

→Используйте BigQuery ML для обучения модели кластеризации KMEANS непосредственно на данных клиентов.

Почему: K-means — это алгоритм обучения без учителя, идеально подходящий для сегментации. BQML делает его доступным через SQL без экспорта данных.

Включить семантический поиск (основанный на значении, а не на ключевых словах) по текстовым данным, хранящимся в BigQuery.

→Используйте функцию ML.GENERATE_EMBEDDING с базовой моделью Vertex AI для создания векторных вложений. Храните их и используйте функцию VECTOR_SEARCH для поиска сходства.

Почему: Этот шаблон вносит мощные возможности семантического поиска непосредственно в BigQuery, избегая необходимости во внешних поисковых индексах, таких как Elasticsearch.

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

→Создайте удаленную модель BigQuery ML, которая указывает на конечную точку Vertex AI LLM. Используйте функцию ML.GENERATE_TEXT в SQL-запросе для обработки текстовых данных.

Почему: Это тесно интегрирует генеративный ИИ в SQL, позволяя аналитикам использовать LLM на своих данных, не покидая среду BigQuery и не написав сложный код приложения.

Многоэтапный конвейер данных включает сложные зависимости, повторные попытки и задачи в различных сервисах GCP (например, Dataflow, BigQuery, Dataproc).

→Используйте Cloud Composer (управляемый Apache Airflow). Определите рабочий процесс как направленный ациклический граф (DAG) с использованием Python.

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

Задача Airflow DAG, которая вызывает внешний API, часто завершается сбоем из-за временных проблем с сетью.

→Настройте повторные попытки на уровне задачи в DAG с retry_exponential_backoff=True. Это увеличивает задержку между повторными попытками, давая внешней системе время на восстановление.

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

Управлять, версионировать, тестировать и планировать сложный набор взаимозависимых SQL-преобразований в BigQuery.

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

Почему: Dataform — это собственное решение Google Cloud для ELT, предоставляющее управление зависимостями, тестирование и контроль версий для преобразований BigQuery, способствуя внедрению лучших практик DataOps.

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

→Используйте Dataplex, который автоматически захватывает и отображает происхождение данных из поддерживаемых сервисов Google Cloud в пользовательском интерфейсе Data Catalog.

Почему: Автоматическое отслеживание происхождения данных имеет решающее значение для анализа воздействия, отладки и управления. Dataplex предоставляет это "из коробки" для интегрированных сервисов.

Запущенное потоковое задание Dataflow необходимо обновить новой логикой без потери данных или состояния.

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

Почему: Механизм обновления на месте Dataflow предоставляет способ развертывания изменений в потоковых конвейерах без простоев, сохраняя состояние и гарантируя обработку "ровно один раз".

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

→Включите Cloud Audit Logs, в частности журналы доступа к данным, для соответствующих служб. Создайте приемник журналов для экспорта этих журналов в BigQuery для долгосрочного хранения и анализа.

Почему: Cloud Audit Logs предоставляют защищенную от подделки, всеобъемлющую запись доступа к данным. Отправка журналов в BigQuery позволяет проводить мощный аудит и создавать отчеты на основе SQL.

Наборы данных, таблицы и элементы управления доступом BigQuery должны управляться как код для повторяемости и версионирования (Инфраструктура как код).

→Определите все ресурсы BigQuery (наборы данных, таблицы, политики IAM) в файлах конфигурации Terraform (.tf). Управляйте развертываниями через конвейер CI/CD.

Почему: Terraform является стандартом для IaC в GCP, обеспечивая аудируемое, версионируемое и согласованное управление инфраструктурой данных, предотвращая расхождение ручной конфигурации.

Модель ML в продакшене со временем показывает ухудшение производительности.

→Внедрите Vertex AI Model Monitoring. Настройте задание мониторинга для обнаружения расхождения между обучением и обслуживанием, а также дрифта прогнозов путем сравнения производственного трафика с базовым. Настройте оповещения для запуска расследования или автоматического переобучения.

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