Vertex AI Tips + Tricks: проверка данных в Vertex Pipelines с использованием больших ожиданий

Введение

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

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

В этом сообщении блога мы покажем, как реализовать проверку данных с помощью приложения «Большие надежды» в конвейерах Google Cloud Vertex AI. Vertex AI Pipelines основан на KubeFlow Pipelines (KFP), платформе с открытым исходным кодом для создания конвейеров машинного обучения с использованием контейнеров и предоставляет отличный способ организовать рабочий процесс машинного обучения в Google Cloud.

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

Мы создадим компоненты KFP для выполнения двух разных задач:

1. Создание источника данных «Большие ожидания».
2. Проверка данных, которая выводит отчет и, при необходимости, включает ведение журнала и оповещение.

Что такое Большие надежды?

Great Expectations — это инструмент Python с открытым исходным кодом для проверки данных, профилирования и документирования. С Большими ожиданиями мы можем утверждать, что мы ожидаем от набора данных, используя «Ожидания», которые по сути являются утверждениями или модульными тестами, применяемыми к данным. Great Expectations предлагает отличный способ смягчить проблемы с качеством данных, которые сохраняются в конвейерах машинного обучения.

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

• Контекст данных.Контекст данных представляет собой проект «Большие надежды». Он организует хранение и доступ к наборам ожиданий, источникам данных, настройкам уведомлений и приборам данных. Контекст данных создается путем создания экземпляра Great Expectations через интерфейс командной строки, а также настраивается и поддерживается с помощью результирующего файла great_expectations.yml.
• Источники данных.Источник данных — это конфигурация, которая описывает, где находятся данные, как к ним подключиться и какой механизм выполнения использовать при выполнении контрольной точки. Таким образом, источники данных состоят из двух компонентов: хранилище (например, таблицы BigQuery) и вычисления (например, SQLAlchemy). Одним из основных преимуществ Great Expectations является возможность проверки данных в различных источниках данных, таких как Pandas в памяти, фреймы данных Spark, CSV-файлы, хранящиеся в облаке, или реляционные базы данных, такие как BigQuery и PostgreSQL.
• Ожидания.Ожидания предоставляют язык для описания ожидаемого поведения данных. Они хранятся в наборах ожиданий, которые представляют собой набор ожиданий в формате JSON. Наборы ожиданий и наборы данных имеют отношения многие ко многим; Пакет ожиданий можно использовать для проверки данных в одном или нескольких наборах данных, а один набор данных можно проверить с помощью одного или нескольких наборов ожиданий. Некоторые часто используемые ожидания включают проверку отсутствующих значений, проверку типов данных и проверку того, находится ли значение в заранее определенном наборе или находится между минимальным и максимальным значением. Полный список доступных Ожиданий можно найти в Галерее Ожиданий.
• Пакетный запрос.Пакетный запрос определяет пакет данных для запуска ожиданий из заданного источника данных. Они могут описывать данные в файле, базе данных или фрейме данных.
• Конфигурация контрольной точки.Конфигурации контрольной точки описывают, какой Expectation Suite следует запускать для каких данных и какие действия следует выполнять во время и после запуска (например, отправка уведомлений Slack, информирующих о неудачных проверках).
• Документы данных.Документы данных — это четкие, удобочитаемые документы, которые содержат информацию о проверке, такую ​​как набор ожиданий, используемый для проверки, результат каждого утверждения ожидания и т. д. Документы данных существуют в формате HTML внутри Контекст данных.

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

Как мы можем интегрировать Большие надежды в Vertex AI?

Прежде чем мы создадим компонент проверки данных с помощью Great Expectations, нам сначала нужно настроить наш проект Google Cloud, чтобы иметь возможность запускать Great Expectations с контекстом данных, расположенным в Google Cloud Storage.

Создание контекста данных в GCS

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

Для начала откройте терминал и выполните следующие команды:

pip install great_expectations
great_expectations init

Это установит библиотеку Great Expectations и инициализирует ее. В терминале мы увидим сообщение от Great Expectations о том, что будет создан новый контекст данных, а вместе с ним и новый каталог, содержащий следующую структуру:

   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations

Если выбрать да при появлении запроса, приложение «Большие надежды» создаст структуру папок. Результирующие папки и файлы говорят сами за себя: great_expectations.yml содержит информацию о контексте данных и источниках данных. Папка expectations содержит все файлы JSON Expectations Suite, папка checkpoints содержит все файлы контрольных точек YAML и т. д. Папка uncommitted/data_docs/local_site_validations будет содержать документы Data Docs в формате HTML, являющиеся результатами примененных проверок.

После создания каталога great_expectations нам нужно скопировать его в корзину GCS, выполнив следующее:

gsutil cp -r great_expectations gs://<BUCKET NAME>/great_expectations

В качестве примечания, мы должны принять во внимание, что Большие надежды работают только с локальным контекстом данных. К счастью для нас, Vertex Pipelines использует GCSFuse, чтобы сделать сегменты Google Cloud Storage доступными в файловой системе в разделе /gcs/‹BUCKET NAME›.

В будущем каждый раз, когда нам нужно будет указывать путь либо к компоненту конвейера Vertex, либо к блокноту в Workbench с этим бэкендом GE, нам нужно будет указать следующее:

import great_expectations as gx
context = gx.data_context.DataContext(context_root_dir=/gcs/<BUCKET NAME>/great_expectations)

Это определение контекста данных — это то, что позволит нам работать с серверной частью Great Expectations, расположенной в GCS, которую можно использовать в любой части или инструменте проекта.

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

1. Подключиться к источникам данных
2. Создайте наборы ожиданий
3. Создайте компонент проверки, который будет включать создание контрольных точек.
4. Создать логику регистрации и оповещения

1. Подключиться к источникам данных

Первым шагом рабочего процесса является определение подключений ко всем источникам данных, которые мы хотим проверить. В этом сообщении блога мы сосредоточимся только на создании источника данных, который подключается к корзине GCS, содержащей файлы CSV. Определение подключений к источникам данных выполняется путем настройки файла great_expectations.yml. Есть несколько способов сделать это, и в Документации о больших надеждах есть руководства, которые охватывают большинство вариантов использования.

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

1.1. Статический источник данных

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

from ruamel import yaml

import great_expectations as gx
from great_expectations.core.batch import Batch, BatchRequest, RuntimeBatchRequest

context = gx.get_context()

datasource_yaml = rf"""
name: {DATASOURCE_NAME}
class_name: Datasource
execution_engine:
    class_name: PandasExecutionEngine
data_connectors:
    default_runtime_data_connector_name:
        class_name: RuntimeDataConnector
        batch_identifiers:
            - default_identifier_name
    default_inferred_data_connector_name:
        class_name: InferredAssetGCSDataConnector
        bucket_or_name: {BUCKET_NAME}
        prefix: {PREFIX_NAME}
        default_regex:
            pattern: (.*)\.csv
            group_names:
                - data_asset_name
"""

context.add_datasource(**yaml.load(datasource_yaml))

Обязательно отредактируйте имя источника данных, сегмент GCS и имя префикса для того места, где находятся ваши CSV-файлы. В целях проверки мы рекомендуем следовать разделу Протестируйте новый источник данных документации Большие надежды.

ПРИМЕЧАНИЕ. Строка кода context=gx.get_context() рекомендуется, если вы работаете локально. Однако, как мы уже упоминали, мы стремимся использовать Большие надежды в производственной среде, и поэтому мы рекомендуем работать в Workbench и указывать контекст данных на серверную часть GCS, которую мы загрузили ранее, определяя контекст следующим образом:

context = gx.data_context.DataContext(context_root_dir=/gcs/<BUCKET NAME>/great_expectations)

1.2. Динамический источник данных

При работе с Vertex AI Pipelines очень часто приходится работать с промежуточными артефактами, которые находятся между разными компонентами. Среди этих артефактов мы найдем наборы данных, которые иногда могут быть результатами предварительной обработки или отображать инженерные шаги, созданные определенным компонентом. Эти артефакты обычно хранятся во вложенном пути, который автоматически генерируется Vertex внутри корзины pipeline_root, которую мы определяем при построении конвейера. Это означает, что расположение набора данных меняется каждый раз, когда происходит новый запуск конвейера. Следовательно, для этого конкретного варианта использования нам необходимо создать новый компонент Vertex AI Pipelines, который автоматически обновляет местоположение источника данных в контексте данных «Большие ожидания».

Компонент, который работает для этого варианта использования, представлен ниже. Шаги, за которыми следует компонент:

1. Во-первых, у нас есть полный путь к артефакту набора данных в качестве входных данных, но нам нужно разделить этот путь на имя корзины и префикс (подпуть внутри корзины, где находится набор данных), чтобы добавить его в определение источника данных.
2. Мы определяем источник данных и добавляем его в контекст данных «Большие ожидания», как мы это делали в статическом источнике данных.
3. Мы хотим убедиться, что соединение с источником данных установлено и работает правильно. Этот шаг не является обязательным, но рекомендуется. Для этого нам нужно, чтобы Expectation Suite уже был загружен в наш сервер GCS. Нам также нужно создать BatchRequest из источника данных. Наконец, мы проверяем данные с помощью объекта валидатора, используя BatchRequest и Expectation Suite. Если валидатор терпит неудачу, компонент терпит неудачу.

from kfp.v2 import dsl
from kfp.v2.dsl import Dataset, Input


@dsl.component(base_image="python:3.9", packages_to_install=["great_expectations==0.15.32"])
def create_gcs_great_expectations_datasource(
   dataset_bucket: str
   dataset: Input[Dataset],
   datasource_name: str,
   ge_context_root_dir: str,
   expectation_suite_validation: str,
   data_connector_name: str,
  
):

   import logging
   from pathlib import Path

   import great_expectations as gx
   from great_expectations.core.batch import BatchRequest
   from pathlib import Path

   context = gx.data_context.DataContext(context_root_dir=ge_context_root_dir)
   
   bucket=Path(dataset.path).parts[2]
   datasource_prefix = "/".join(Path(dataset.path).parts[3:-1])

   datasource_yaml = rf"""
       name: {datasource_name}
       class_name: Datasource
       execution_engine:
           class_name: PandasExecutionEngine
       data_connectors:
           default_runtime_data_connector_name:
               class_name: RuntimeDataConnector
               batch_identifiers:
                   - default_identifier_name
           {data_connector_name}:
               class_name: InferredAssetGCSDataConnector
               bucket_or_name: {bucket}
               prefix: {datasource_prefix}
               default_regex:
                   pattern: (.*)\.csv
                   group_names:
                       - data_asset_name
       """

   context.add_datasource(**yaml.load(datasource_yaml))
   # Test the connection
   context.test_yaml_config(yaml_config=datasource_yaml)
   logging.info("Data Source updated")

   data_asset_name = dataset.path.replace(f"{pipeline_root_path}/", "").replace(".csv", "")
   logging.info(f"Data Asset Name: {data_asset_name}")

   batch_request = BatchRequest(
       datasource_name=datasource_name,
       data_connector_name=data_connector_name,
       data_asset_name=data_asset_name,
   )

   context.get_expectation_suite(expectation_suite_name=expectation_suite_validation)
   context.get_validator(
       batch_request=batch_request, expectation_suite_name=expectation_suite_validation
   )

   logging.info("Data Source successfully created")

После создания нашего источника данных GCS раздел источников данных в файле great_expectations.yml выглядит следующим образом:

datasources:
 my_datasource:
   data_connectors:
     default_runtime_data_connector_name:
       module_name: great_expectations.datasource.data_connector
       batch_identifiers:
         - default_identifier_name
       class_name: RuntimeDataConnector
       name: default_runtime_data_connector_name
     default_inferred_data_connector_name:
       module_name: great_expectations.datasource.data_connector
       default_regex:
         pattern: (.*)\.csv
         group_names:
           - data_asset_name
       prefix: my_prefix
       class_name: InferredAssetGCSDataConnector
       name: default_inferred_data_connector_name
       bucket_or_name: dataset_bucket
   module_name: great_expectations.datasource
   execution_engine:
     module_name: great_expectations.execution_engine
     class_name: PandasExecutionEngine
   class_name: Datasource

2. Создайте наборы ожиданий

Существует четыре рабочих процесса, которые можно использовать для создания Expectation Suite (подробные инструкции здесь), но в этом блоге мы сосредоточимся на создании одного с использованием интерактивного рабочего процесса с помощью метода Python, написав код в блокноте Jupyter. Этот метод требует, чтобы источник данных, который мы хотим проверить, был настроен в файле great_expectations.yml, как мы сделали в 1. Подключиться к разделу Источники данных.

Этот метод имеет следующий рабочий процесс:

1. Создайте пакетный запрос, в котором указывается пакет данных, который будет использоваться для создания ожиданий.
2. Указываем название нашего набора ожиданий.
3. Создайте экземпляр объекта проверки, отвечающего за выполнение нашего набора ожиданий для данных.
4. Создайте ожидания с помощью объекта валидатора и сохраните их в наборе ожиданий.

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

import great_expectations as gx
from great_expectations.core.batch import BatchRequest

DATASOURCE_NAME = {DATASOURCE_NAME}
DATA_CONNECTOR_NAME = {DATA_CONNECTOR_NAME}
GCS_PREFIX = {GCS_PREFIX}
FILE_NAME = {FILE_NAME.csv}
EXPECTATION_SUITE_NAME = {EXPECTATION_SUITE_NAME}

context = gx.data_context.DataContext(context_root_dir=/gcs/<BUCKET_NAME>/great_expectations)

batch_request = BatchRequest(
    datasource_name = DATASOURCE_NAME,
    data_connector_name = DATA_CONNECTOR_NAME,
    data_asset_name = f"{GCS_PREFIX}/{FILE_NAME}"
) 

suite = context.create_expectation_suite(expectation_suite_name = EXPECTATION_SUITE_NAME, overwrite_existing=True)

validator = context.get_validator(
    batch_request = batch_request,
    expectation_suite_name = {EXPECTATION_SUITE_NAME}
)

# Expect all `customer_id` values to not be null
validator.expect_column_values_to_not_be_null(column='customer_id')

# Expect all `unique_key` values to be unique
validator.expect_column_values_to_be_unique(column='unique_key')

# Expect all `unique_key` values to be 40 characters long
validator.expect_column_value_lengths_to_equal(column = 'unique_key', value=40)

# Expect `taxi_trip_in_seconds` values to be greater than 0
validator.expect_column_values_to_be_between(column = 'taxi_trip_in_seconds', min_value=0)

# Expect mean of all `taxi_trip_fare` values to be between 20 and 30 dollars
validator.expect_column_mean_to_be_between(column = 'taxi_trip_fare', min_value=20, max_value=30)

# Expect `trip_start_timestamp` dates to be between 01/01/2000 and today
validator.expect_column_values_to_be_between(column = 'trip_start_timestamp', min_value=date.fromisoformat("2000-01-01"), max_value=datetime.date.today().strftime('%Y-%m-%d'))

# Expect `payment_type` values to be in set {'Cash', 'Credit Card'}
validator.expect_column_values_to_be_in_set(column = 'payment_type', value_set=["Cash", "Credit Card"])

validator.save_expectation_suite(discard_failed_expectations=False)

После создания набора ожиданий не забудьте использовать gsutil, чтобы скопировать полученный файл JSON в папку ожиданий в GCS.

ПРИМЕЧАНИЕ. Нам известно, что наборы ожиданий автоматически сохраняются в папке great_expectations/expectations. Кроме того, мы также можем определить любую другую папку или корзину для размещения наших наборов ожиданий. Компания Большие надежды называет это магазином ожиданий. Нам просто нужно соответствующим образом обновить файл great_expectations.yml, но для получения дополнительной информации см. здесь.

Соображения

Список всех доступных Ожиданий можно найти здесь. Тем не менее, есть несколько вещей, которые мы должны учитывать:

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

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

• Пользовательские ожидания также могут быть созданы. Подробнее см. здесь.

3. Компонент проверки данных

Теперь мы можем создать компонент Data Validator внутри компонента Vertex AI Pipelines, который позволит нам проверять наш подключенный источник данных с помощью только что созданного набора ожиданий. Рекомендуемый метод проверки данных — использование контрольных точек. Контрольные точки будут проверять данные, сохранять результаты проверки, выполнять любые указанные нами действия и, наконец, создавать документы данных с их результатами.

Логика проста. Нам нужно предоставить всю информацию, которую мы упоминали ранее: все, что связано с контекстом данных, источником данных и набором ожиданий. Кроме того, у нас есть артефакт Output[HTML], который будет использоваться для вывода результатов проверки в формате HTML с использованием документов данных Great Expectation.

Компонент состоит из следующих шагов:

1. Определение контекста данных (помните, что мы используем контекст данных, расположенный в GCS).
2. Как упоминалось ранее, для выполнения проверки нам нужно создать контрольную точку, где мы определяем комбинацию набора ожиданий и набора данных, которую необходимо проверить.
3. Мы запустим только что созданную и сохраненную контрольную точку, в результате чего появится объект CheckpointResult, содержащий соответствующие метаданные.
4. Наконец, мы анализируем CheckpointResult в объекте ExpectationSuiteValidationResult, чтобы иметь возможность отображать его HTML и отображать его в качестве вывода.

from kfp.v2 import dsl
from kfp.v2.dsl import HTML, Output

@dsl.component(
    base_image="python:3.9",
    packages_to_install=["great_expectations==0.15.32", "google-cloud-logging==3.2.5"],
)
def data_validation(
    ge_context_root_dir: str,
    checkpoint_name: str,
    datasource_name: str,
    data_connector_name: str,
    data_asset_name: str,
    expectation_suite_validation: str,
    output_html: Output[HTML],
    project_id: str,
) -> list:

  import logging
  
  import great_expectations as gx
  from great_expectations.render.renderer import ValidationResultsPageRenderer
  from great_expectations.render.view import DefaultJinjaPageView
  from ruamel import yaml
  
  context = gx.data_context.DataContext(context_root_dir=ge_context_root_dir)
  
  # In order to create a validation step, a checkpoint needs to be created.
  # Checkpoints combine the data_asset_name with its corresponding expectation suite.
  
  yaml_config = f"""
              name: {checkpoint_name}
              config_version: 1.0
              class_name: SimpleCheckpoint
              run_name_template: "%Y%m%d-%H%M%S"
              validations:
                - batch_request:
                    datasource_name: {datasource_name}
                    data_connector_name: {data_connector_name}
                    data_asset_name: {data_asset_name}
                    data_connector_query:
                      index: -1
                  expectation_suite_name: {expectation_suite_validation}
              """
  
  context.add_checkpoint(**yaml.load(yaml_config))
  # Run checkpoint to validate the data
  checkpoint_result = context.run_checkpoint(checkpoint_name=checkpoint_name)
  
  # Validation results are rendered as HTML
  document_model = ValidationResultsPageRenderer().render(
      list(checkpoint_result.run_results.values())[0]["validation_result"]
  )
  
  if not output_html.path.endswith(".html"):
      output_html.path += ".html"
  
  # Write validation results as output HTML
  with open(output_html.path, "w") as writer:
      writer.write(DefaultJinjaPageView().render(document_model))

Окончательный выходной HTML-артефакт показывает результаты проверки:

ПРИМЕЧАНИЕ. В приведенном здесь примере кода мы определили конфигурацию, используя YAML в строке, чтобы она соответствовала документации Great Expectations. Однако вы также можете определить конфигурацию непосредственно в словаре Python.

4. Регистрация и оповещение

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

if not checkpoint_result["success"]:
        raise RuntimeError(f"Validations failed")

Или, возможно, мы хотим, чтобы компонент отправлял журнал в Google Cloud Logging, который мы можем использовать позже для создания настраиваемых предупреждений или электронных писем. Если мы хотим быть более конкретными, мы можем, например, создать определенные журналы для любого инструмента мониторинга и оповещения. Мы можем добавить следующий фрагмент кода к уже существующему компоненту, который поможет нам анализировать результаты проверки и генерировать правильные предупреждения о регистрации.

Вот следующие шаги:

1. Получите словарь со всеми результатами проверки.
2. Создайте Google Logger. Если в будущем мы захотим найти конкретное сообщение журнала, будет проще, если это сообщение журнала будет иметь определенное имя, форму или сообщение.
3. Переберите все результаты проверки и проверьте столбцы и ожидания, которые не увенчались успехом.
4. Зарегистрируйте эти конкретные сбои.

# Return validation results to check its results
validation_results = (checkpoint_result.to_json_dict()
            .get("run_results")
            .get(str(list(checkpoint_result.get("run_results").keys())[0]))
            .get("validation_result")
            .get("results")
        )

import google.cloud.logging
from google.cloud.logging.handlers import CloudLoggingHandler
from google.logging.type import log_severity_pb2 as severity


# Create a handler for Google Cloud Logging.
log_name="great_expectations_logger"
gcloud_logging_client = google.cloud.logging.Client(project=project_id)
gcloud_logging_handler = CloudLoggingHandler(gcloud_logging_client, name=log_name)
gcs_logger = gcloud_logging_client.logger(log_name)

# Handle failed validations to check in which lists appear (ERRORS & WARNINGS)
errors = []
for validation in validation_results:
   if not validation["success"]:
      column_failed = validation["expectation_config"]["kwargs"]["column"]
      expectation_failed = validation["expectation_config"]["expectation_type"]
      errors.append(column_failed, expectation_failed)


if errors:
  json_payload = {"message": f"Great Expectations Errors: {errors}"}
  gcs_logger.log_struct(json_payload, severity=severity.ERROR)

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

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

logName="projects/{my_project}/logs/great_expectations_logger"
resource.type="k8s_container"
severity="ERROR"
jsonPayload.message:"Great Expectations Errors"

Заключение

Низкое качество данных — одна из самых больших проблем в машинном обучении, которая часто приводит к скрытым сбоям или низкой производительности в производственной среде. Теперь вы можете использовать Great Expectations для обеспечения качества данных в ваших производственных конвейерах машинного обучения на Vertex AI! В этом посте мы показали только простой пример проверки данных с помощью Больших ожиданий, но это очень мощный инструмент, поэтому обязательно ознакомьтесь с Документацией по «Большим ожиданиям для получения более подробной информации. Наконец, не забудьте подписаться на нас на Medium, чтобы узнать больше советов и рекомендаций Vertex AI и многое другое!

Datatonic является Партнером года в области машинного обучения Google Cloud с богатым опытом разработки и развертывания эффективных моделей машинного обучения и сборок платформы MLOps. Нужна помощь в разработке модели машинного обучения или быстром развертывании моделей машинного обучения? Посмотрите наш вебинар MLOps101, где наши эксперты расскажут вам, как начать масштабное машинное обучение, или свяжитесь с вами, чтобы обсудить ваши требования к ML или MLOps!

Автор хотел бы поблагодарить Валентина I Кожокару и Джонни Браунинга за их внимательное рассмотрение и вдумчивые комментарии.