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

Качество данных является важнейшей проблемой при пакетной обработке данных, поскольку некачественные данные могут привести к неправильной аналитике и принятию бизнес-решений. Инженерам по обработке данных, аналитикам, менеджерам по обработке данных и руководителям отделов обработки данных (CDO) необходимы надежные инструменты для профилирования данных, обнаружения аномалий, обеспечения соблюдения стандартов обработки данных и интеграции с существующими системами. В этой статье сравниваются семь инструментов обеспечения качества данных с открытым исходным кодом - Soda Core, Great Expectations, Deequ, Databricks DQX, Pandera, Nike Spark—Expectations и DQOps - на основе ключевых критериев: профилирование и обнаружение данных, очистка и стандартизация данных, возможности интеграции, масштабируемость и производительность, пользовательский интерфейс и простота использования. использование, а также поддержка сообщества и документация. Анализ основан на реальном опыте пользователей и отзывах профессионального сообщества (например, проблемы на GitHub, обсуждения на Reddit, статьи в Medium, обзоры G2), а не на маркетинговых материалах поставщиков, что позволяет принимать обоснованные решения. В конце приведен сравнительный краткий список сильных и слабых сторон.

Soda Core (Soda SQL)

Обзор: Soda Core - это компонент платформы обеспечения качества данных Soda с открытым исходным кодом. Это инструмент командной строки и библиотека Python, которая использует простой синтаксис на основе YAML (язык Soda Checks, или SodaCL) для определения тестов качества данных (называемых “проверками”) и запуска сканирования источников данных. Soda Core разработан таким образом, чтобы его было легко внедрять в рабочие процессы для упреждающего мониторинга качества данных.

Профилирование и обнаружение данных: Soda Core поддерживает базовое профилирование данных. Он предоставляет профилировщик командной строки, который может вычислять показатели набора данных и предлагать правила контроля качества. Однако результатом работы профилировщика является набор показателей, которые пользователи должны вручную интегрировать в проверки — он не генерирует автоматически понятные пользователю утверждения. Это менее автоматизировано, чем некоторые другие инструменты, но дает отправную точку для написания проверок. Набор встроенных показателей (например, количество строк, пропущенные значения, дубликаты) невелик (более 25 показателей), и пользователи могут определять пользовательские проверки с помощью SQL-запросов для более сложного профилирования.

Очистка и стандартизация данных: Основное внимание Soda Core уделяет выявлению проблем с данными, а не автоматической очистке. Когда проверка завершается неудачей (например, неожиданные значения null или значения, выходящие за пределы диапазона), Soda Core помечает “плохие” данные и может выводить строки, содержащие ошибки, но не изменяет и не удаляет данные самостоятельно. Любая очистка или помещение на карантин поврежденных данных должны быть реализованы пользователем в окружающем конвейере. На практике команды часто используют утверждения Soda Core, чтобы предотвратить загрузку некачественных партий (из-за сбоя задания) или запустить последующую обработку (например, пропуск или исправление ошибочных записей), но сам по себе этот инструмент не обеспечивает соблюдение политики стандартизации.

Возможности интеграции: Интеграция - сильная сторона Soda Core. Он может подключаться к более чем 20 различным источникам данных, включая реляционные базы данных (PostgreSQL, MySQL, SQL Server и т.д.), облачные хранилища данных (Snowflake, BigQuery, Redshift), хранилища данных (через Athena/Trino) и даже фреймы данных Spark. У каждого поддерживаемого источника есть специальный соединитель, который преобразует проверки Soda в соответствующие операции SQL или DataFrame. Например, проверки в базе данных SQL передаются как SQL-запросы, в то время как проверки в Spark DataFrame используют операции Spark. Soda Core обычно запускается в таких инструментах управления, как Airflow или конвейеры CI/CD. Однако обратите внимание, что некоторые возможности подключения или расширенной интеграции (например, оповещение в режиме реального времени, совместная работа или расширенный lineage) являются частью коммерческой облачной платформы Soda, а не инструмента OSS.

Масштабируемость и производительность: Soda Core разработан для пакетной обработки и использует базовую платформу обработки данных для обеспечения масштабируемости. Поскольку проверки Soda преобразуются в запросы, относящиеся к конкретному источнику, основная работа выполняется базой данных или движком Spark. Это означает, что Soda Core может обрабатывать большие наборы данных до тех пор, пока это возможно для самого источника данных (например, при передаче проверки row_count в SQL-движок будет использоваться оптимизация этого движка). Soda Core также поддерживает интеграцию с Spark (soda-core-spark-df) для работы с большими данными — он может выполнять проверку фреймов данных Spark, не требуя извлечения данных. С точки зрения повышения производительности, сканирование Soda Core сопряжено с затратами на выполнение определенных запросов. Пользователи сообщают, что она экономична и не приводит к существенному раздуванию: “Soda Core (OSS-вариант Soda) - это экономичный, приятный инструмент”, хотя он “несколько ограничен” по сравнению с полноценными платформами. Основное ограничение заключается в том, что в OSS недоступны расширенные функции, такие как обнаружение аномалий с течением времени (обсуждается ниже), поэтому Soda Core обычно проверяет одну партию за раз без учета исторического контекста.

Пользовательский интерфейс и простота использования: Ядро Soda Core с открытым исходным кодом в основном используется с помощью файлов конфигурации YAML и интерфейса командной строки, в версии OSS графический интерфейс отсутствует. Это делает его ориентированным на разработчиков: инженеры по обработке данных могут писать проверки на YAML и запускать сканирование, получая результаты в консоли или в формате JSON. Синтаксис SodaCL вполне читабелен (непрограммисты могут понять проверки, написанные простым языком, например, “значения в столбце X должны присутствовать в таблице Y”) и является ключевым преимуществом Soda. Однако, поскольку он основан на файлах, в OSS отсутствует интерактивный интерфейс без использования кода. Пользователи отметили, что отсутствие проверки схемы или автозавершения в YAML может привести к ошибкам при редактировании проверок. Soda действительно предлагает веб-интерфейс и функции информационной панели, но они являются частью Soda Cloud (платного SaaS); например, обнаружение аномалий и расширенная визуализация недоступны в Soda Core. Подводя итог, можно сказать, что простота использования хороша для разработчиков, привыкших к YAML/CLI, но не для бизнес—аналитиков - Soda Core проще, чем написание простых SQL-тестов, но сама по себе она не позволяет работать без использования кода. Поддержка сообщества и документация: Сообщество Soda Core активно, но меньше, чем ожидалось. Документация по SodaCL и коннекторам в целом хорошая (на сайте Soda docs приведены примеры и ссылки для написания проверок). Команда Soda и сообщество пользователей представлены на канале Slack. Поскольку Soda Core является частью продукта, разработанного компанией, обновления происходят довольно регулярно, и на GitHub принимаются вклады сообщества. Пользователи ценят внимание Soda Core к надежности данных в конвейерах, хотя некоторые предупреждают, что, поскольку проект с открытым исходным кодом привязан к компании, некоторые функции неизбежно будут “заблокированы” корпоративной версией. В целом, отзывы сообщества часто позиционируют Soda Core как надежный вариант с открытым исходным кодом для тестирования качества базовых данных, хваля его за простоту, но признавая его ограниченную применимость в OSS (отсутствие пользовательского интерфейса, мониторинга истории и т.д.).

Great Expectations (GX)

Обзор: Great Expectations (GX) - одна из самых популярных платформ для обеспечения качества данных с открытым исходным кодом. Это библиотека Python, которая позволяет пользователям определять “ожидания” — по сути, утверждения о данных — и затем проверять наборы данных на соответствие этим ожиданиям. GE предоставляет обширные функциональные возможности для организации тестирования, профилирования данных и даже представления результатов проверки в виде документов. С момента своего запуска в 2017 году GE получила широкое распространение и часто считается наиболее многофункциональным инструментом DQ с открытым исходным кодом.

Возможности профилирования данных и обнаружения: Great Expectations легко интегрируется с Pandas Profiling, позволяя пользователям создавать подробные отчеты о профилировании данных. Эта интеграция облегчает детальный поисковый анализ данных, позволяя получить представление о распределении данных, отсутствующих значениях, корреляциях и многом другом. Используя профилирование Pandas, команды могут эффективно анализировать свои наборы данных и выявлять потенциальные проблемы с качеством. Кроме того, GX Cloud предлагает функцию профилирования ресурсов данных, которая анализирует схему данных при создании ресурса данных и предоставляет описательные показатели, включая типы столбцов и статистические сводки. Однако важно отметить, что эта функция недоступна на бесплатном уровне.

Очистка и стандартизация данных: Как и Soda, Great Expectations - это, в первую очередь, инструмент проверки и документирования; он не изменяет данные. При запуске expectations GX определит, нарушают ли какие-либо записи правила (и может предоставить образцы строк с ошибками в своих выходных данных). Затем конвейер или инженер должны решить, как справиться с этими сбоями — например, остановить конвейер, предупредить кого-либо или выполнить этап очистки. Дизайн GX предполагает, что сбои в ожиданиях указывают на данные, которые требуют внимания или очистки, но сам GX этого не исправит. Один из способов, которым GX косвенно помогает, — это документирование того, как выглядят “чистые” данные. Expectation Suite служит в качестве соглашения о стандартах данных, которое может направлять процессы очистки. Однако автоматическая стандартизация (например, преобразование форматов или заполнение значений по умолчанию) выходит за рамки GX. На практике команды часто интегрируют GX с рабочими процессами, которые, скажем, удаляют записи с ошибками или помещают их в карантин (например, используя выходные данные GX в задаче Airflow для ветвления логики). Приложения Nike Spark-Expectations и Databricks DQX были созданы отчасти для того, чтобы добавить этот ориентированный на действия уровень в дополнение к проверке, чего GX сам по себе не делает. Возможности интеграции: у GX есть длинный список возможностей интеграции в экосистему данных. Он может подключаться ко многим источникам данных: плоским файлам (CSV, JSON), фреймворкам данных Pandas, фреймворкам данных Spark, базам данных SQL и хранилищам данных через SQLAlchemy (Postgres, MySQL, Snowflake, BigQuery, Redshift и т.д.). Он поддерживает развертывание в различных средах — например, он интегрируется с Airflow, Prefect и DBT (так что вы можете запускать ожидания как часть этих конвейеров). В нем также есть концепция хранилища ожиданий и хранилища проверки результатов, которые могут храниться в файлах, облачных хранилищах или даже в базе данных. Одно из ограничений интеграции, отмеченных пользователями, заключается в том, что использование GX SQLAlchemy для подключения к базам данных может привести к отставанию в поддержке новых или менее распространенных баз данных. Пользователь сообщил, что в новых версиях GX была отключена поддержка некоторых СУБД (Vertica, Oracle), что вызвало проблемы у тех, кто на них полагается. Помимо возможности подключения к исходному коду, гибкость GX в интеграции с другими инструментами (через Python и его подключаемые хранилища) считается главной сильной стороной — она “четко ориентирована на интеграцию и создание готовых к работе систем проверки”. Например:

Системы оповещения:

Slack: GX может отправлять автоматические уведомления о проверке качества данных по каналам Slack.
Электронная почта: GX поддерживает отправку уведомлений по электронной почте о результатах проверки данных.

Платформы для наблюдения за данными:

Neptune.ai: GX может быть интегрирован с Neptune.искусственный интеллект для регистрации конфигураций, результатов проверки и
Отчеты в формате HTML, улучшающие видимость данных.

Каталоги данных:

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

Конвейеры передачи данных ML:

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

Решения для обеспечения качества данных:

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

Масштабируемость и производительность: Производительность Great Expectations зависит от того, как выполняются ожидания. В своих последних версиях (v3 и выше) GX пытается внедрить в источник данных как можно больше проверок. Например, если вы проверяете таблицу в Snowflake, GX сгенерирует SQL-запросы для проверки каждого ожидаемого значения (таким образом, основная работа выполняется Snowflake). Это делает возможной пакетную обработку больших объемов данных. Однако не все ожидания могут быть оправданы — для оценки некоторых сложных ожиданий может потребоваться загрузка данных в локальный движок (Pandas), особенно если используется файловая система или если ожидания не могут быть выражены в SQL. Этот двойной подход (SQL pushdown и in-memory) означает, что пользователи должны помнить: проверка чрезвычайно больших наборов данных в Pandas через GX будет медленной или невозможной из-за ограничений памяти. На практике для работы с большими данными используется GX со Spark или SQL warehouse для использования распределенных вычислений. GX несколько тяжеловесна как библиотека (у нее более 100 зависимостей, и некоторым она может показаться “громоздкой”) — например, один пользователь Reddit пожаловался, что “Большие ожидания - это громоздко”, когда им требовались только более простые проверки. Несмотря на свой вес, GX успешно используется в производстве для пакетных конвейеров, но может потребовать настройки (использование конфигураций контрольных точек для управления тем, как и где выполняются проверки). Команды нередко ограничивают GX проверкой на основе выборок в огромных таблицах из-за соображений времени выполнения или используют его для обработки агрегированных результатов, а не необработанных миллиардов строк. Для потоковой передачи или использования в режиме реального времени GE обычно не применяется (он больше ориентирован на пакетную обработку).

Пользовательский интерфейс и простота использования: в предложениях GX с открытым исходным кодом исторически не было веб-интерфейса. Пользователи могли создавать ожидания в коде или в записных книжках Jupyter и просматривать результаты в консоли или в виде сгенерированных HTML-документов. Эти HTML—документы являются приятной особенностью - GX автоматически создает стилизованный документ, показывающий каждое ожидание, независимо от того, были ли данные переданы или нет, а также любые примеры сбоев. Это полезно для обмена результатами с заинтересованными сторонами, но отчеты являются статичными. Что касается простоты использования, мнения расходятся. GE чрезвычайно эффективна, но требует сложного обучения, особенно до версии 1.0, когда ее API только развивался. Она вводит множество новых концепций (набор ожиданий, пакетная обработка, контрольные точки, контекст данных), с которыми часто сталкиваются начинающие пользователи. Действительно, один из пользователей Reddit написал: “Я возлагал большие надежды, но, боже мой, это так громоздко, прошел целый день, а я все еще не разобрался”. Это мнение разделяют и другие пользователи, которые считают GX “потенциально чересчур сложным”, но все же ценят его как “наиболее универсальное” решение. Чтобы повысить удобство использования, команда GX выпустила Great Expectations Cloud (платное SaaS-приложение), которое включает пользовательский интерфейс для создания ожиданий и управления ими. Однако в open source нет полностью интерактивного пользовательского интерфейса — только интерфейс командной строки и рабочий процесс на основе записной книжки. Пользователям, не обладающим техническими знаниями (например, аналитикам данных), может быть сложно напрямую взаимодействовать с GX без посторонней помощи. Документация является исчерпывающей, но может оказаться непосильной. С положительной стороны, проект предоставляет шаблоны и множество примеров, а сообщество оказывает большую поддержку (что помогает со временем ускорить процесс обучения).

Поддержка сообщества и документация: Great Expectations может похвастаться одним из крупнейших сообществ в области качества данных. Это проект с открытым исходным кодом, активно работающий на GitHub (много участников) и специальное сообщество Slack для вопросов и ответов. Пользователи регулярно делятся советами на дискурсивных форумах и в обсуждениях на GitHub. Благодаря такому сильному сообществу, если вы столкнетесь с проблемой, есть большая вероятность, что кто-то обсудил ее или официальный автор поможет. Документация считается превосходной по охвату — она включает в себя руководство по основным концепциям, практические рекомендации и галерею ожиданий с примерами для каждого типа ожиданий. Однако, как уже отмечалось, огромный объем документации может отпугнуть новичков, и поступали жалобы на устаревшие разделы (особенно связанные с новыми интеграциями, такими как Databricks). Компания Great Expectations также выиграла от распространения в отрасли информации из уст в уста как “стандартного” варианта с открытым исходным кодом для обеспечения качества данных. Многие команды начинают с GX из-за этой репутации, хотя некоторые позже ищут более простые альтернативы, когда понимают, что не для каждого варианта использования требуется полная сложность. Подводя итог, можно сказать, что приложение Great Expectations обладает большим функционалом и проверено сообществом, но требует стремления к обучению и, возможно, дополнительной инфраструктуры (например, базы данных результатов для обеспечения наглядности), чтобы получить максимальную отдачу от него.

Deequ

Обзор: Deequ - это библиотека с открытым исходным кодом от Amazon (AWS Labs) для оценки качества данных, в частности, в Apache Spark. Написанная на Scala (с доступными API Java и Python), она была разработана для профилирования больших наборов данных и проверки ограничений в масштабе Spark. Deequ, в частности, используется в средах AWS Glue и EMR и обладает рядом уникальных возможностей, таких как определение ограничений и обнаружение аномалий в показателях качества данных.

Профилирование и обнаружение данных: Deequ предоставляет анализаторы, которые вычисляют статистику по данным (например, процент полноты столбца, приблизительные квантили и т.д.), а также утилиту для определения ограничений, которая может предлагать ограничения качества на основе этих показателей. Например, после профилирования фрейма данных Deequ может предложить ограничение, согласно которому значения min и max для определенного столбца находятся в пределах определенного диапазона или что столбец всегда ненулевой, если это указано в профиле. Это помогает при обнаружении и первоначальном создании правил, хотя предложения охватывают основные ограничения. Пользователи также могут вручную определять проверки (называемые VerificationSuite с помощью ряда объектов проверки в Scala API) для проверки показателей качества данных. Deequ не предоставляет такой обширный словарь данных или документацию, как data docs от Great Expectations, но он фокусируется на результатах числового профилирования и проверке истинности / ложности ограничений.

Очистка и стандартизация данных: Как и другие инструменты, используемые до сих пор, Deequ сам по себе не очищает данные; он только оценивает данные с учетом ограничений. Он выведет, какие ограничения были выполнены, а какие нет, и может предоставить показатели (например, “15% строк в столбце X были пустыми, что нарушает ограничение полноты <= 5%”). Затем пользователь должен выполнить задание Spark, чтобы принять меры. Deequ может быть интегрирован таким образом, что неудачная проверка предотвращает вывод неверного пакета (часто встречающегося в заданиях ETL). В сообщениях в блоге Amazon о Deequ часто говорится о том, что он используется для обеспечения того, чтобы по конвейеру передавались только качественные данные, но любое фактическое удаление или исправление данных должно быть запрограммировано разработчиком. Deequ не помещает записи в карантин автоматически и не исправляет их — это платформа для обнаружения проблем. Таким образом, пользователям, желающим выполнить этап автоматической очистки, придется дополнить Deequ пользовательским кодом Spark. Некоторые пользователи объединили Deequ с рабочими процессами AWS Glue, чтобы, например, переместить записи с ошибками в карантинное хранилище S3, но эта логика не относится к Deequ.

Возможности интеграции: Возможности интеграции Deequ ограничены: он работает с фреймворками данных Apache Spark (и, соответственно, с любыми источниками данных, которые может считывать Spark). Нет прямого подключения к реляционным базам данных или CSV-файлам; сначала вы должны загрузить данные в фрейм данных Spark. Это означает, что Deequ идеально подходит, если вы уже используете Spark или PySpark в своей пакетной обработке. Он не подходит в качестве автономного инструмента, скажем, для аналитика данных, для подключения к базе данных — он предназначен для встраивания в задания Spark. Что касается AWS, то Deequ часто используется в скриптах Glue ETL или записных книжках EMR. Для пользователей Python существует оболочка pydeequ, позволяющая им использовать Deequ в PySpark (хотя некоторые отзывы сообщества указывают на то, что API Python менее документирован и иногда отстает от версии Scala). Таким образом, интеграция с чем—либо за пределами экосистемы Spark ограничена — “Возможности подключения Deequ ограничены исключительно Apache Spark”, - но в рамках Spark он может обрабатывать различные форматы данных (parquet, ORC и т.д.) и при необходимости интегрируется с конвейером Spark ML (поскольку ограничения могут быть частью конвейер обработки данных).

Масштабируемость и производительность: Масштабируемость - одна из сильных сторон Deequ. Будучи построенным на базе Spark, он может работать распределенно в больших кластерах, что делает его пригодным для работы с огромными наборами данных. Например, вычисление статистики столбцов для фрейма данных, состоящего из миллиарда строк, может выполняться параллельно. Deequ используется в Amazon для проверки больших наборов данных журнала и clickstream, что указывает на его способность обрабатывать масштаб. Он также поддерживает вычисление дополнительных показателей: он может сохранять показатели предыдущих запусков и комбинировать их с показателями новых данных для обнаружения аномалий или изменений с течением времени. Это полезно для ежедневных пакетных проверок, когда вы хотите узнать, не отличаются ли сегодняшние данные значительно от вчерашних (обнаружение аномалий). Функция обнаружения аномалий в Deequ работает за счет хранения хранилища показателей (часто на диске или в памяти) и сравнения показателей (таких как среднее значение, количество и т.д.) в разных пакетах. Пользователи ценят эту функцию, поскольку она обеспечивает наблюдаемость базовых данных. Однако обнаружение аномалий Deequ является статистическим и несколько ограниченным (оно выявляет отклонения показателей за пределы определенных пороговых значений) — оно не такое совершенное, как платформы для наблюдения, полностью управляемые искусственным интеллектом. Что касается накладных расходов, Deequ добавляет некоторую обработку поверх заданий Spark, но, поскольку он использует Spark, он линейно масштабируется в соответствии с вашим кластером. Основные накладные расходы связаны с написанием ограничений на Scala/Python и дополнительным этапом задания Spark для вычисления показателей. При хорошей интеграции влияние на производительность можно контролировать. Одно предостережение: некоторые члены сообщества отметили, что документация Deequ скудна, что затрудняет оптимизацию или использование расширенных функций.

Пользовательский интерфейс и простота использования: В Deequ нет пользовательского интерфейса. Он используется при написании кода (Scala или PySpark). Это означает, что в первую очередь он предназначен для разработчиков и инженеров по обработке данных, которые знакомы с кодом Spark. В нем нет функции перетаскивания или декларативной настройки (в отличие от YAML в Soda или GX). Несмотря на то, что API работает свободно (вы добавляете проверки в код), процесс обучения может быть умеренным, если вы новичок в Spark / Scala. Пользователи отметили, что слабым местом является документация: “В Deequ отсутствует четкая документация”, что может усложнить первоначальную настройку. Тем не менее, основные понятия (полнота, уникальность и т.д.) знакомы, а в официальном репозитории GitHub приведены примеры. Что касается выходных данных, Deequ возвращает результаты в виде объектов или JSON — их можно распечатать в журналах или сохранить, но в нем нет встроенного формата отчетов или панели мониторинга. Многие пользователи в конечном итоге записывают результаты в таблицу или систему, такую как CloudWatch, для мониторинга. Отсутствие пользовательского интерфейса и управляемость кодом делают Deequ менее доступным для аналитиков или неинженеров. Это компромисс: вы получаете гибкость и производительность за счет удобства использования. Один пользователь Stack Overflow, который сравнил GX и Deequ резюмировали: “У Great Expectations очень хорошая и понятная документация и меньше накладных расходов; у Deequ есть функция обнаружения аномалий, но непонятная документация”. Это подчеркивает, что простота использования в GX была оценена как лучшая, в то время как для внедрения и поддержки Deequ может потребоваться больше инженерных усилий.

Поддержка сообщества и документация: Сообщество Deequ относительно небольшое и сосредоточено вокруг его проекта на GitHub. Он был разработан исследователями AWS, и, хотя у него открытый исходный код, у него нет такого широкого сообщества, как у инструмента Great Expectations. Проблемы в репозитории GitHub действительно получают ответы от сопровождающих (включая авторов Deequ). Однако новые функции и исправления появляются нечасто, поскольку проект не находится в стадии активной разработки, как некоторые другие (в последний раз основные обновления библиотеки Scala были внесены в 2020-2021 годах). Документация состоит в основном из README и нескольких примеров записных книжек. У Deequ нет богатой экосистемы блогов или плагинов, за исключением нескольких сторонних сравнений и статей для СМИ. В результате команды, использующие Deequ, иногда полагаются на самостоятельное устранение неполадок или просмотр исходного кода для расширенного использования. С положительной стороны, Deequ стабилен в своей области применения — он делает то, что рекламирует (профилирование и проверка ограничений в Spark), и имеет проверенные примеры использования в AWS. Подводя итог, можно сказать, что Deequ - отличный выбор для конвейеров данных, ориентированных на Spark, которые нуждаются в масштабируемых проверках, но требуют определенных усилий для кодирования и, возможно, расширения. Он был описан как “полезный для Spark, но его ограничения в подключении, пользовательском интерфейсе и отчетности ограничивают его более широкое применение”.

Databricks DQX (Quality eXtended)

Обзор: DQX - это новая платформа с открытым исходным кодом, выпущенная Databricks Labs (конец 2024 года), предназначенная для упрощения проверки качества данных для рабочих нагрузок Spark (как пакетных, так и потоковых). Это иногда называют “расширенным контролем качества Databricks”. DQX был разработан для интеграции с архитектурой Databricks Lakehouse, предоставляя инструменты для профилирования данных, проверки на соответствие ожиданиям и обработки неверных данных с использованием Spark-ориентированного подхода. Как лабораторный проект, он официально не поддерживается Databricks SLA, но вызвал интерес благодаря тому, что изначально привнес в экосистему Spark/Delta функциональность, на которую возлагаются большие надежды.

Профилирование и обнаружение данных: DQX уделяет большое внимание автоматизированному профилированию данных. Он может сканировать заданный фрейм данных (или таблицу) и генерировать сводную статистику и набор предполагаемых правил в конфигурационном файле YAML. На этом этапе профилирования, часто называемом рабочим процессом профилировщика, каждый столбец анализируется, чтобы предложить типы данных, диапазоны и возможные проверки качества (например, уникальность, не null, если столбец выглядит завершенным и т.д.). Результатом является YAML (и прилагаемый к нему файл сводной статистики), в котором перечислены эти предполагаемые ожидания. Затем пользователи могут просмотреть и отредактировать это, прежде чем применять проверку. Эта функция похожа по духу на профилировщик Great Expectations, но адаптирована для Spark. Это значительно ускоряет обнаружение, так как вы можете указать DQX на новый набор данных и быстро получить отчет о базовом качестве. Помимо первоначального профилирования, DQX также может непрерывно профилировать каждый пакет и поддерживать показатели. В документации указано, что выходные данные профилировщика могут храниться для каждого уровня данных (например, bronze, silver в архитектуре medallion), чтобы отслеживать, как меняется качество данных по мере их совершенствования. Такая постоянная наблюдаемость позволяет осуществлять мониторинг качества данных с течением времени, хотя в основном он основан на показателях (как и концепция хранилища показателей Deequ).

Очистка и стандартизация данных: Одной из отличительных особенностей DQX является возможность помещать неверные данные в карантин во время проверки. Когда DQX выполняет валидационные проверки в DataFrame, он может отделить записи, которые не прошли проверку, в определенный набор данных с “ошибкой”, что позволяет продолжить обработку только чистых записей. (Аналогичный подход был реализован в проекте BlueRidge Data Platform Project).Это хорошо согласуется с подходом Databricks medallion (бронза-серебро-золото). Например, вы можете предотвратить влияние неверных данных в слое bronze на слой silver с помощью DQX. Любые проблемные данные могут быть отложены для проверки, исправления и последующего добавления в случае необходимости. Этот подход очень похож на то, что делает Nike в Spark-Expectations (на самом деле, DQX, вероятно, был вдохновлен такими шаблонами). Предоставляя возможность автоматической изоляции "грязных" записей, DQX добавляет механизм очистки, которого нет в "Great Expectations" и "Soda". Однако стоит отметить, что DQX не исправляет данные волшебным образом — он просто перенаправляет их. Фактическая стандартизация (например, преобразование неверного значения во что-то стандартное) все равно была бы пользовательской, но, по крайней мере, фреймворк автоматизирует фиксацию сбоев. Это большой плюс для поддержания работоспособности конвейера передачи данных, поскольку это означает, что вам не нужно останавливать всю работу из-за нескольких ошибочных записей; вы можете отсеять их и сохранить основной поток с чистыми данными.

Возможности интеграции: DQX разработан специально для платформы Databricks и Spark. Он особенно хорошо интегрируется с функциями Delta Lake и Databricks. Например, его можно использовать в конвейерах Delta Live Tables (DLT) для обеспечения соответствия требованиям к потоковым данным или пакетным таблицам. Вероятно, для эффективного выполнения этой задачи в нем используются прослушиватели Spark или дельта-перехватчики. Поскольку он основан на Spark, он может работать с любыми данными, которые Spark может считывать (как и Deequ). DQX предоставляет как API Python, так и вариант конфигурации YAML для определения правил. Это означает, что вы можете либо написать код в записной книжке, либо использовать конфигурационные файлы, сохраненные в репозиториях, для декларативного подхода. Поскольку это проект Databricks Labs, он не ограничивается Databricks cloud — его можно использовать в Spark или других дистрибутивах Spark с открытым исходным кодом, хотя некоторые интеграции (например, DLT) зависят от Databricks. В настоящее время DQX не имеет подключений к системам, отличным от Spark (например, он не будет напрямую подключаться к базе данных MySQL; сначала вы должны перенести эти данные в Spark). В первую очередь это фреймворк для встраивания в задания Spark ETL. Для команд, которые уже инвестировали в Databricks, DQX привлекателен тем, что позволяет использовать на один внешний инструмент меньше — он может работать в рамках существующего рабочего процесса с минимальными затратами.

Масштабируемость и производительность: Будучи разработанным на базе Spark, DQX унаследовал масштабируемость Spark. Он предназначен для обработки крупномасштабных данных как в пакетном, так и в потоковом режиме. Проверки достоверности распределяются по всему кластеру. С точки зрения производительности, одним из возможных факторов является то, что профилирование очень большого набора данных для вывода правил может быть дорогостоящим (для вычисления статистики требуется считывать много данных). Однако это одноразовая или нечастая операция, и, вероятно, при необходимости вы могли бы создать профиль на основе выборки. Для рутинной проверки накладные расходы DQX должны быть аналогичны запуску эквивалентного кода Spark для каждой проверки (что обычно выполняется довольно быстро, например, count() для полноты или агрегация для уникальности в кластеризованном движке). Пока что доступно не так много реальных тестов, учитывая, насколько они новы, но, учитывая участие Databricks, можно ожидать, что они будут оптимизированы для общепринятых шаблонов. DQX явно поддерживает качество потоковых данных в Spark Structured Streaming, что означает, что он может работать в микропакетном режиме с новыми данными по мере их поступления с минимальным воздействием на задержку (вероятно, для проверки используются показатели из каждого микропакета). Это то, с чем сталкивались большие ожидания, поэтому дизайн DQX для потоковой передачи заслуживает внимания. Поскольку DQX является новым, его стабильность и производительность в очень больших масштабах могут быть подтверждены со временем; начинающим пользователям следует протестировать его на своих рабочих нагрузках, чтобы убедиться, что он соответствует требованиям SLA.

Пользовательский интерфейс и простота использования: В DQX нет специального приложения с пользовательским интерфейсом; оно используется через записные книжки, скрипты на Python или конфигурационные файлы. Однако пользователи Databricks могут использовать собственный интерфейс notebook и пользовательский интерфейс Jobs/Workflows для управления запусками DQX (например, в блоге показаны запущенные рабочие процессы DQX из пользовательского интерфейса Databricks с различными параметрами конфигурации. Это скорее удобство интеграции, чем полноценный пользовательский интерфейс. Что касается простоты использования, первоначальные отзывы были положительными — один пользователь из сообщества разработчиков данных, попробовав DQX, отметил, что он “выглядит довольно хорошо и очень прост в использовании”. Простота, вероятно, обусловлена возможностью автоматического вывода многих данных (что сокращает необходимость ручной настройки) и согласованием с тем, как пользователи Spark уже мыслят (фреймы данных и преобразования). Определения правил в YAML понятны для тех, кто знаком с написанием ожиданий или проверок. Поскольку это новый инструмент, документация по нему все еще находится в стадии разработки, но Databricks Labs опубликовала подробный README и примеры записных книжек. Поскольку документация взята из Databricks, предполагается, что они знакомы с Spark/Delta. Для пользователей, не являющихся пользователями Spark, DQX не будет инструментом начального уровня. Но для целевой аудитории (пользователей Spark), возможно, его будет проще внедрить, чем что-то вроде Great Expectations, которое пользователь Reddit счел громоздким в Databricks. Следует отметить одну вещь: поскольку это проект Labs, поддержка осуществляется через сообщество и GitHub, а не через официальную поддержку Databricks. В README явно указано, что официальной поддержки или соглашения об уровне обслуживания нет. Это означает, что простота использования в долгосрочной перспективе также будет зависеть от вклада сообщества и устранения неполадок.

Поддержка сообщества и документация: DQX находится в зачаточном состоянии. Его поддерживает Databricks Labs (которая разработала другие успешные проекты в области OSS), но у него пока нет большой базы пользователей. Документация доступна на страницах GitHub, а также в нескольких сообщениях в блоге (от Databricks и партнеров), объясняющих варианты использования. Первые отзывы сообщества обнадеживают — публикации на Reddit и substack вызвали интерес, особенно среди клиентов Databricks, которые ищут собственное решение для управления доступом. Если DQX наберет обороты, мы можем ожидать растущую поддержку сообщества, возможно, интеграцию в Databricks в качестве официально поддерживаемой функции в будущем (хотя это предположение). Прямо сейчас пользователи могут задавать вопросы на форумах сообщества Databricks или на GitHub issues. По состоянию на 2025 год, помимо первоначальных анонсов, сторонних обучающих программ не так много. При оценке DQX следует рассматривать его как экспериментальный продукт — это шанс продвинуться вперед с использованием современного подхода, но, учитывая его новизну, вы можете столкнуться с ошибками или отсутствующими функциями. Те, кто предпочитает зрелые, проверенные временем инструменты, могут пока придерживаться Deequ или GX, в то время как новаторы могут попробовать DQX и внести свой вклад в его развитие. Проекты Databricks Labs часто быстро улучшаются благодаря отзывам сообщества, поэтому участие в проекте (сообщение о проблемах, предложения по улучшению) может быть частью процесса внедрения.

Spark-Expectations от Nike

Обзор: Spark-Expectations - это система обеспечения качества данных с открытым исходным кодом, разработанная Nike. Он был создан для проверки качества данных в заданиях Spark (особенно в потоковых заданиях или заданиях “в полете”), устраняя пробелы, которые Nike обнаружила с помощью других инструментов. По сути, это библиотека Spark (доступна в PyPI), которая позволяет разработчикам определять правила качества данных, которые автоматически отфильтровывают неверные данные и проблемы с журналированием. Spark-Expectations основана на ожиданиях Great Expectations и Delta Live Tables, но разработана специально для обеспечения качества в режиме реального времени при передаче данных через Spark.

Профилирование и обнаружение данных: Программа Spark-Expectations больше ориентирована на обеспечение соблюдения требований, чем на профилирование. В ней нет сложной функции профилирования данных; нет автоматического предложения правил на основе данных. (В выпусках проекта есть намеки на то, что функции профилирования данных могут появиться в будущем, но начиная с версии 2.3 они сосредоточены на выполнении правил.) Как правило, пользователь Spark-Expectations уже знает или решает, какие правила применять (например, “столбец X не должен быть нулевым, столбец Y должен соответствовать регулярному выражению и т.д.”), а затем реализует их. Фреймворк действительно собирает статистику по мере выполнения — например, он отслеживает, сколько записей не выполнили каждое правило, и создает сводную таблицу (_stats). Со временем эта статистика могла бы послужить формой мониторинга качества данных (например, “сегодня у нас было на 5% больше сбоев, чем обычно”), но Spark-Expectations пока не включает обнаружение аномалий в эту статистику. По сути, профилирование выполняется вручную: вы должны изучить выходные данные _stats или выполнить отдельный анализ, чтобы обнаружить новые возможные правила, которые могут потребоваться. Преимущество этого инструмента заключается в эффективном применении известных правил, а не в изучении неизвестных проблем с данными.

Очистка и стандартизация данных: Именно здесь проявляется искра ожиданий. Платформа создана для принятия мер в отношении неверных данных по мере их обнаружения. Все записи, нарушающие какие-либо правила обеспечения качества данных, помещаются на карантин в таблицу “_error” (с метаданными о том, какие правила не сработали, и информацией о задании). При этом в основном потоке данных сохраняются только те записи, которые соответствуют всем правилам. Это позволяет эффективно отфильтровывать искаженные или недействительные данные в режиме реального времени. За счет раздельного сбора неверных записей упрощается последующий просмотр и корректирующие действия без остановки конвейера. Этот подход устраняет основную проблему в типичных конвейерах, где неверные данные либо приводят к сбою задания, либо, если их не отловить, загрязняют данные в последующих потоках. Spark-Expectations автоматизирует этап фильтрации, который в противном случае потребовал бы пользовательского кода. Он также предоставляет сводную информацию в таблице “_stats”, которая объединяет количество успешных действий / неудач для каждого правила и, возможно, другие показатели. С помощью этих двух выходных данных (_error и _stats) инженеры по обработке данных могут создавать процессы для уведомления заинтересованных сторон, запуска оповещений или даже автоматического исправления определенных ошибок. С точки зрения стандартизации, Spark-Expectations сам по себе не корректирует данные (например, не переформатирует строку в соответствии с шаблоном даты); он просто удаляет несоответствующие данные. Nike разработала его таким образом, чтобы “данные, качество которых не соответствует контракту, не перемещались на следующий уровень”. Любые дальнейшие действия (например, отправка записей об ошибках обратно в исходную команду или применение значений по умолчанию) будут зависеть от бизнес-логики. Тем не менее, предотвращая попадание плохих данных в целевую таблицу, Spark-Expectations обеспечивает получение чистого выходного набора данных, что является сильной формой стандартизации (стандартизация по принципу “присутствуют только хорошие данные”).

Возможности интеграции: Spark-Expectations глубоко интегрирован со Spark и связанными с ним технологиями. В PySpark он реализован как шаблон декоратора: вы можете оформить функции Spark или потоки данных правилами качества данных, и фреймворк будет выполнять эти проверки во время выполнения. Он поддерживает как пакетные, так и потоковые задания Spark. В блоге Nike engineering приведены примеры с Delta Lake (ошибка и статистика записаны в виде дельта-таблиц) и упоминается совместимость с такими источниками, как Kafka и Iceberg, с помощью структурированной потоковой передачи Spark. По сути, любая среда, в которой вы можете запустить PySpark (Databricks, EMR, Spark в Kubernetes и т.д.), может использовать Spark-Expectations. В ней нет подключений к внешним системам (ни прямого SQL, ни автономного интерфейса командной строки). Вместо этого он предназначен для встраивания в ваш ETL-код Spark. Для интеграции в более крупную экосистему дизайн Nike позволяет записывать результаты в приемники, такие как дельта-таблицы (которые можно отслеживать или подключать к инструментам BI). В навигации по документам есть упоминание о плагинах уведомлений (email, Slack), что означает, что вы можете настроить их для отправки оповещений по электронной почте / Slack при сбое правил. Это хорошая точка интеграции для операций. Кроме того, поскольку у него открытый исходный код, другие пользователи могут расширить его с помощью пользовательских приемников или уведомлений. Имейте в виду, что Spark-Expectations — это специализированная библиотека, которая лучше всего подходит, если вашей платформой пакетной обработки является Spark. Это не то, что вы бы использовали вне этого контекста (например, не для автономного хранилища данных SQL). Оно хорошо сочетается с архитектурами Delta Lake house, аналогично тому, как позиционируется DQX.

Масштабируемость и производительность: Фреймворк был создан с учетом масштабирования Nike, которое, по-видимому, предполагает большие объемы данных и потоковые конвейеры. Используя выполнение Spark, он масштабируется горизонтально вместе с кластером. Накладные расходы на Spark-ожидания - это затраты на оценку правил для каждой строки и, возможно, на запись записей об ошибках. Если у вас очень строгие правила, которые нарушают многие записи, вы можете в конечном итоге записать много данных в таблицу _error, что следует учитывать (но это неизбежно, если в ваших данных много ошибок). Дизайн должен быть эффективным: использование встроенного API DataFrame от Spark для проверок означает, что там, где это возможно, используются векторизованные операции. Например, проверка столбца на наличие нулей или регулярного выражения выполняется в Spark, что довольно быстро. Вклад Nike указывает на то, что было важно, чтобы это существенно не замедляло работу — вероятно, они добились этого, поскольку один из принципов заключался в том, чтобы избежать необходимости в отдельном этапе постобработки (проверка качества является частью работы и должна соответствовать скорости потоковой передачи). Общедоступная информация о тестах производительности ограничена, но, учитывая, что компании уже сталкивались с подобными моделями (например, ожидания DLT в Databricks могут выполняться с минимальным снижением производительности), вполне вероятно, что Spark-ожидания можно использовать в конвейерах реального времени без существенной потери пропускной способности. Масштабируемость ограничена ресурсами вашего кластера Spark; если они соответствуют объему ваших данных, Spark-Expectations будет масштабироваться соответствующим образом.

Пользовательский интерфейс и простота использования: в Spark-Expectations нет графического интерфейса пользователя; он используется путем написания конфигурации и кода. Вы определяете правила в формате JSON или YAML (или непосредственно в коде с помощью декораторов) и привязываете их к фреймам данных. Синтаксис конфигурации не такой высокоуровневый, как в SodaCL или Great Expectations; это больше похоже на написание утверждений в коде с некоторой структурой. На сайте документации Nike приведены примеры и четкое объяснение концепций. Для разработчика Spark использование библиотеки должно быть простым, но это все еще новый инструмент для изучения. Простота использования улучшается за счет того, что он автоматизирует обработку ошибок — раньше разработчик Spark мог написать множество операций filter() и отдельные фреймы данных для хороших и плохих данных, тогда как Spark-Expectations завершает эту логику за вас, как только вы настраиваете правила. Это сокращает количество шаблонов и потенциальных ошибок. Пользователи или аналитики, не являющиеся специалистами Spark, не будут напрямую взаимодействовать с этим; это определенно разработка инженеров для инженеров. Одно из будущих улучшений, на которое намекнул Nike, - это пользовательский интерфейс для ввода правил или управления ими. Без пользовательского интерфейса управление правилами может включать редактирование JSON и повторное развертывание заданий, что не очень удобно для больших наборов правил. Но, учитывая, что это только начало внедрения, у большинства пользователей, вероятно, есть небольшое количество правил, закодированных вместе с логикой выполнения заданий. Что касается процесса обучения, то это проще, чем большие ожидания, если вы уже знакомы со Spark, потому что вам не нужно осваивать совершенно новую экосистему; вы просто изучаете шаблоны для интеграции этой библиотеки. Примечание по документации: несмотря на то, что сайт Nike является всеобъемлющим, сообщество в нем меньше, поэтому устранение неполадок может быть связано с чтением исходного кода или открытием проблем на GitHub, а не с поиском ответов на StackOverflow (по крайней мере, до тех пор, пока он не станет более популярным).

Поддержка сообщества и документация: Nike выпустила Spark-Expectations с открытым исходным кодом, и, хотя он вызвал интерес (благодаря техническим блогам и даже пошаговому руководству на YouTube), это все еще нишевый проект. Сообщество, скорее всего, включает разработчиков из Nike и несколько внешних участников (на GitHub представлены десятки участников, которые в основном могут быть внутренней командой Nike). Документация (на инженерном сайте Nike) хорошо структурирована и охватывает установку, настройку правил и примеры для приемников (Delta, Kafka). Также ведется активная разработка, о чем свидетельствуют обновления версий (версия 2.3, как указано в ссылке) и обсуждения функций на GitHub (например, добавление профилирования данных, пользовательского интерфейса и т.д.). Поскольку это относительно новое приложение, в Интернете не так много сторонних руководств или обсуждений вопросов и ответов. Организациям, рассматривающим это, следует рассчитывать на некоторую самоподдержку. Хорошая новость заключается в том, что, поскольку это позволяет решить очень существенную проблему (остановить сбой данных в конвейерах) в конкретном контексте (Spark), те, кто в этом нуждается, скорее всего, внесут свой вклад в это. Это решение касается реальной проблемы, которую Great Expectations или Deequ не смогли решить в полной мере, а именно автоматического карантина поврежденных данных. В целом, Spark-Expectations играет особую роль для магазинов, использующих Spark. Сообщество разработчиков может быть меньше, чем у инструментов общего назначения, но если ваш вариант использования соответствует тому, что он предлагает, это может оказаться чрезвычайно ценным. Собственный успех Nike в области внедрения ИТ в производство подтверждает, что его стоит попробовать для аналогичных сценариев.

Pandera

Обзор: Pandera - это библиотека Python, которая обеспечивает проверку данных во фреймворках данных (в pandas и аналогичных фреймворках, таких как Dask, Modin и Polars). Он сильно отличается от других инструментов тем, что это не автономная платформа для обеспечения качества данных, а скорее упрощенный способ применения схем и инвариантов к данным в Python. Pandera была создана для специалистов по обработке данных — для проверки наборов данных в памяти во время анализа или обучения модели. Он приобрел популярность благодаря своей простоте и использованию языка Python: по состоянию на конец 2024 года его загрузили более 50 миллионов раз, что свидетельствует о широком использовании в сообществе разработчиков данных на Python.

Профилирование и обнаружение данных: Подход Pandera к профилированию заключается в упрощении определения и вывода схем. Пользователи могут объявить схему фреймов данных с ожидаемыми именами столбцов, типами данных, диапазонами, допустимыми значениями, шаблонами регулярных выражений и т.д., а затем использовать Pandera для проверки фрейма данных на соответствие этой схеме. Библиотека предоставляет функцию infer_schema(), которая проверяет пример фрейма данных и создает черновую схему с типами и простыми проверками. Например, если столбец в выборке не содержит нулей, это может указывать на значение Nullable=False; если в столбце все “Y” или “N”, это может указывать на категориальное ограничение. Это форма профилирования, позволяющая ускорить написание правил. Pandera не профилирует данные в смысле создания сводных статистических отчетов, но может использоваться в Python для проведения такого анализа (например, вы можете использовать профилирование pandas или свой собственный код, а затем формализовать результаты в схеме Pandera). Его основной функцией обнаружения является вывод схемы, который весьма удобен для быстрого документирования формы данных. Кроме того, поскольку Pandera может интегрироваться со стратегиями тестирования гипотез (она интегрирована с библиотекой гипотез для тестирования данных на основе свойств), опытные пользователи могут профилировать данные, генерируя множество примеров случайных данных, чтобы увидеть, что соответствует схеме, и соответствующим образом доработать их. В целом, Pandera скорее минимальна в плане обнаружения, чем оправдывает большие ожидания — она ориентирована на проверку схемы, а не на полное профилирование данных или документирование распределений.

Очистка и стандартизация данных: Pandera - это инструмент проверки; он не будет автоматически преобразовывать или очищать данные, кроме принудительных типов, если вы укажете. Например, вы можете указать в схеме, что столбец должен быть целым числом, и Pandera может преобразовать столбец с плавающей точкой в int, если это возможно (иначе возникнет ошибка). Pandera может быть интегрирована с процессами загрузки данных, чтобы убедиться, что данные соответствуют схеме, а если нет, вы можете удалить или исправить недопустимые строки. Она также предлагает функцию под названием “селекторы”, позволяющую легко применять определенные проверки к нескольким столбцам, но, опять же, это касается проверки подлинности. Поскольку она встроена в Python, одним из распространенных шаблонов является применение схемы Pandera в качестве декоратора или утверждения в функциях обработки данных: если данные не работают, выдайте ошибку или обработайте ее в коде. Это сродни модульным тестам для данных. Pandera не обеспечивает карантинирование или регистрацию ошибок "из коробки" (вы получите список исключений, проверка которых завершилась неудачей). Однако, поскольку это всего лишь Python, вы могли бы перехватить их и реализовать пользовательскую обработку. Таким образом, роль Pandera в очистке заключается в том, чтобы действовать как привратник — она обеспечивает соблюдение заведомо правильных условий, чтобы любая последующая очистка выполнялась явно в случае сбоя проверки. Она не выполняет за вас никаких действий, таких как заполнение пропущенных значений или стандартизация форматов; это оставлено на усмотрение pandas или других библиотек.

Возможности интеграции: Pandera тесно интегрирована со стеком данных Python. Он поддерживает фреймы данных pandas изначально и через свой уровень взаимодействия (основанный на библиотеке union, ранее pandera.engines), он также поддерживает фреймы данных Dask (для распределенных вычислений), Modin (для параллельных pandas), Koalas/PySpark.pandas и Polars. По сути, вы можете использовать Pandera для проверки данных в этих библиотеках фреймов данных практически прозрачно. Это большое преимущество, если ваша пакетная обработка основана на Python и, возможно, распределена (Dask) - вы получаете один API для проверки всех них. Однако Pandera напрямую не подключается к базам данных SQL и не имеет представления об источниках данных. Вы могли бы получить данные с помощью Python (например, с помощью pandas read_sql или получить Spark dataframe через PySpark), а затем применить Pandera. Для интеграции в рабочие процессы Pandera часто используется в записных книжках Jupyter, скриптах или даже модульных тестах. Некоторые команды рассматривают схемы Pandera как часть контрактов с данными своей кодовой базы, используя их в конвейерах CI для тестирования образцов данных. Поскольку он ориентирован на код, интеграция с orchestrators осуществляется на заказ (вы должны запустить скрипт, который включает проверки Pandera). Это не сервис или инструмент командной строки, который прослушивает задания. Таким образом, несмотря на то, что Pandera хорошо интегрируется с кодом, это не инструмент для системной интеграции вне процесса. Он отлично работает в средах, где данные обрабатываются на Python (задания ETL в pandas/Dask или конвейерах data science). Если ваша пакетная обработка сильно зависит от SQL или выполняется на платформе, подобной Spark (за пределами PySpark), Pandera напрямую применяться не будет.

Масштабируемость и производительность: Pandera сама по себе легкая — применение проверки схемы добавляет минимальные накладные расходы по сравнению с операциями pandas или Dask (в основном, некоторые дополнительные векторизованные проверки или утверждения Python). Масштабируемость ограничена серверной частью: с pandas вы ограничены объемом памяти; с Dask или Modin вы можете масштабировать еще больше. Для работы с очень большими данными Pandera не так масштабируема, как решения на основе Spark, просто потому, что фреймы данных на Python не так легко обрабатывают терабайты. Однако при небольших размерах пакетов или при использовании Dask в кластере она может масштабироваться до многих миллионов записей. Pandera была специально разработана для поддержки фрагментарной проверки (например, вы можете параллельно проверять каждый раздел фрейма данных Dask). Это позволяет использовать параллелизм Dask для наборов данных, объем которых превышает объем памяти. Тем не менее, с точки зрения производительности, большие ожидания или DQX, работающий внутри базы данных, или Spark могут превзойти Pandera в работе с огромными массивами данных, перенося вычисления на более оптимизированные движки. Распространенным вариантом использования является использование Pandera для агрегированных или выборочных данных: например, после агрегирования больших данных в базе данных вы загружаете результат в pandas и проверяете с помощью Pandera, соответствует ли результат определенным ожиданиям. Еще одно соображение, касающееся производительности: Pandera имеет 12 прямых зависимостей (по сравнению с более чем 100 пакетами GE), что отражает ее простоту. Это означает, что она быстро загружается и с меньшей вероятностью будет конфликтовать с другими пакетами — тонкий, но приятный аспект производительности с точки зрения управления средой.

Пользовательский интерфейс и простота использования: Pandera основана на коде и не имеет отдельного пользовательского интерфейса. Специалисты по обработке данных часто хвалят ее за простоту использования, потому что это похоже на работу с самой pandas. API для определения схем является декларативным, но в коде Python: вы создаете экземпляр столбца с проверкой, например, Check.in_range(0, 100), который вполне читаем. Процесс обучения описан как “поверхностный — предоставляет знакомый Pandas-подобный API”. По сути, любой, кто знает, как манипулировать фреймами данных, может быстро разобраться в схемах Pandera. Официальная документация содержит множество примеров, и ее качество отмечено как превосходное. С точки зрения опыта разработчика, поскольку Pandera интегрируется с редакторами и представляет собой просто код, вы получаете все типичные преимущества (автозаполнение, подсказки по вводу и т.д.). Нет необходимости изучать язык, специфичный для предметной области (в отличие от SodaCL или yml от GE) - вы используете сам Python. С другой стороны, это означает, что некодеры не будут напрямую использовать Pandera; она предназначена для тех, кто пишет на Python. Еще одним приятным аспектом является то, что Pandera может использоваться в качестве документации: схема Pandera в вашем репозитории четко описывает, какую форму и ограничения должны иметь ваши данные, действуя как живая документация для контракта с данными. Разработчики иногда включают определения схем в README или генерируют из них markdown, чтобы поделиться ими с членами команды. В целом, Pandera очень легко адаптировать для своих целевых пользователей (разработчиков Python). Она не перегружена новыми концепциями — пользователь может продуктивно поработать с ней в течение дня. Это контрастирует с более тяжелыми фреймворками: как было сказано в одном блоге, использование больших ожиданий для небольшого проекта может быть излишним, в то время как Pandera “проста… для небольшого проекта по обработке данных”.

Поддержка сообщества и документация: Сообщество Pandera постоянно растет. Изначально это был нишевый проект одного автора (который сейчас является частью команды Union.ai), что указывает на поддержку проекта компанией, специализирующейся на инструментах обработки данных. Документация очень хорошо подготовлена, содержит руководства, полный справочник по API и примеры использования различных серверных частей. Проект активно работает на GitHub, и его участники добавляют новые функции (например, поддержку Polars). Сообщество пользователей часто пересекается с сообществом Python, занимающимся исследованием данных. Например, вопросы о Pandera иногда появляются на Stack Overflow или Reddit в контексте очистки данных. По сравнению с крупными инструментами DQ сообщество Pandera меньше и менее формально (нет канала Slack с тысячами участников), но это дружелюбное сообщество с открытым исходным кодом. Инструмент работает стабильно и постепенно совершенствуется — пользователи редко сообщают о серьезных ошибках. Потенциальным недостатком Pandera является то, что, поскольку она не позиционируется как корпоративное решение для управления доступом, некоторые инженеры по обработке данных могут упустить это из виду при оценке “инструментов обеспечения качества данных”, однако она может элегантно справляться со многими задачами проверки. В профессиональной среде Pandera иногда используется в сочетании с другими инструментами: например, Great Expectations для больших таблиц базы данных и Pandera для проверки данных в коде после преобразования. Сообщество поощряет такое использование — это не "или-или". Как отметил один из пользователей Reddit, такие библиотеки, как Pandera (и Pydantic), отлично подходят для “защитного кодирования”, чтобы обеспечить качество данных в коде, даже если они не являются полноценными платформами для обеспечения качества данных. В заключение, Pandera - отличный выбор для рабочих процессов, ориентированных на Python, требующих быстрой и гибкой проверки данных, при поддержке специализированного, но узкоспециализированного сообщества.

DQOps

Обзор: DQOps (Data Quality Operations Center) - это платформа для обеспечения качества и наблюдаемости данных с открытым исходным кодом, запущенная в 2023 году. Он позиционирует себя как комплексное решение, охватывающее профилирование данных, автоматизированный мониторинг, обнаружение аномалий и даже управление инцидентами с качеством данных, с акцентом на простоту использования как техническими, так и нетехническими пользователями. DQOps сочетает в себе панель управления пользовательским интерфейсом и конфигурацию на основе YAML, что позволяет повысить качество корпоративных данных с помощью DataOps с открытым исходным кодом. Он поддерживает пакетную обработку данных в различных системах хранения данных (особенно в базах данных и хранилищах SQL).

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

Очистка данных и стандартизация: DQOps сам по себе не очищает данные, но он очень активно выявляет проблемы, чтобы можно было запустить очистку. Он рассматривает проблемы с качеством данных как инциденты, которыми можно управлять — например, он может поместить разделы данных в карантин, не позволяя разделу, прошедшему проверку с ошибкой, считаться “принятым” (при использовании проверки разделенной таблицы). Он также поддерживает правила обработки недопустимых данных: например, если значение выходит за пределы допустимого диапазона, система может пометить эту проверку как неудачную и даже присвоить ей степень серьезности. В дальнейшем вы можете интегрировать DQOps с рабочими процессами для удаления или исправления этих записей. Одной из сильных сторон DQOps является его ориентация на процессы DataOps — он включает в себя такие функции, как контракты на качество данных в YAML, которые формализуют ожидания и могут контролироваться версиями и тестироваться в CI. Это гарантирует, что правила стандартизации последовательно применяются в разных средах (dev/test/prod) и с течением времени. Несмотря на то, что DQOps не изменяет данные, он предоставляет все средства для обеспечения соблюдения стандартов: оповещения, отчеты, светофоры для конвейеров передачи данных и т.д., гарантируя, что когда данные отклоняются от стандарта, это немедленно становится видимым и можно принять меры. По сравнению с другими инструментами, DQOps больше ориентирован на профилактический контроль (например, ежедневное проведение проверок и предотвращение получения статуса “пройден”, если что-то не так). На практике некоторые пользователи DQOps интегрируют его с инструментами обработки данных, так что неудачная проверка DQOps может остановить конвейер или запустить исправительное задание.

Возможности интеграции: DQOps поддерживает широкий спектр источников данных, в первую очередь SQL и облачные системы хранения. Согласно документации, он может подключаться к BigQuery, Snowflake, AWS Redshift, Azure SQL, PostgreSQL, MySQL и многим другим. Он создан для мониторинга данных в этих системах, не требуя извлечения данных — он выполняет SQL-запросы для проверки непосредственно в источниках. Это упрощает интеграцию с существующими платформами обработки данных: вы указываете DQOps в своих базах данных или хранилищах и настраиваете проверки. Кроме того, DQOps имеет REST API и клиент Python, что означает, что вы можете интегрировать его в пользовательские рабочие процессы или вызывать из других приложений (например, запускать сканирование DQOps в качестве шага в Airflow или получать результаты программным путем). Он также поддерживает внутреннее планирование проверок (так что он может выполнять ежедневные или ежемесячные проверки по расписанию без внешнего организатора). Для получения результатов DQOps предоставляет информационные панели и может отправлять уведомления (например, по электронной почте, Slack и т.д., которые, вероятно, настраиваются с помощью модуля управления инцидентами). Одно из ограничений заключается в том, что DQOps, по крайней мере, в его текущем состоянии, ориентирован на пакетную/периодическую проверку сохраненных данных. Он не предназначен для потоковой передачи данных или проверки в полете; он просматривает данные, находящиеся в состоянии покоя в базах данных или файлах. Но в этой области он охватывает множество точек интеграции (несколько облаков, различные диалекты SQL). Тот факт, что он хранит свою конфигурацию в YAML и даже предоставляет плагин VS Code для редактирования конфигураций с автозавершением схемы, демонстрирует интеграцию с рабочими процессами разработчиков для управления правилами. В целом, DQOps нацелен на внедрение в современный стек данных по аналогии с коммерческими инструментами, такими как Monte Carlo или BigEye, но с открытым исходным кодом, что означает, что он ориентирован на то, где находятся ваши данные, и интегрируется с существующими методами мониторинга / оповещения.

Масштабируемость и производительность: Архитектура DQOps позволяет обрабатывать большие наборы данных, передавая вычисления к источнику данных (как это делают GE и Soda с SQL). Если вы настроите проверку на наличие нулевых значений в процентах для огромной таблицы, DQOps выполнит подсчет(*) или COUNT(col) в базе данных, который должен масштабироваться так же, как и эта база данных. Сама служба DQOps просто организует эти запросы и собирает результаты. Это означает, что DQOps может масштабироваться до корпоративных объемов данных, если ваши базы данных / хранилища надежны. Выполнение 150 проверок для очень большой таблицы может быть трудоемким процессом, но DQOps позволяет планировать их в небольших группах или в нерабочее время и т.д. При обнаружении аномалий используются сохраненные исторические результаты, для чего требуется место для хранения метаданных (вероятно, реляционное хранилище, которым управляет DQOps). Это упрощенная операция по сравнению со сканированием данных. С точки зрения развертывания, DQOps может выполняться локально (для одного пользователя) или как сервер для команды. Поскольку он относительно новый, все еще появляются варианты его широкомасштабного использования в производстве, но ранние отзывы (включая упоминание в Reddit) говорят о том, что он эффективен и “очень прост в использовании”, даже если он обрабатывает несколько конвейеров. Одним из факторов является частота загрузки пакетов — DQOps хорошо подходит для ежедневных или внутридневных проверок загрузки пакетов; он не рассчитан на задержку меньше минуты. Таким образом, в центре внимания находится масштабируемость с точки зрения количества наборов данных и проверок (мониторинг потенциально тысяч таблиц с большим количеством проверок в каждой), в то время как масштабирование в реальном времени выходит за рамки. Благодаря открытому исходному коду, организации могут также развернуть несколько экземпляров DQOps, если это необходимо для масштабирования задач мониторинга. Сообщений о проблемах с производительностью пока не поступало, возможно, потому, что для выполнения тяжелой работы используются проверенные базы данных.

Пользовательский интерфейс и простота использования: DQOps предлагает интуитивно понятный веб-интерфейс, который является одной из его главных достопримечательностей. С помощью пользовательского интерфейса пользователи могут настраивать источники данных, выбирать или настраивать проверки, просматривать информационные панели с ключевыми показателями качества данных и расследовать инциденты. Это позволяет аналитикам данных или менее техническим специалистам по управлению данными участвовать в управлении качеством данных. В то же время все конфигурации могут быть представлены в файлах YAML (с определениями схем, доступными для поддержки IDE) для инженеров, предпочитающих управление кодом и версиями. Такой двойной подход (пользовательский интерфейс + код) соответствует современной философии DataOps. Пользовательский интерфейс включает в себя такие функции, как системы показателей качества данных, диаграммы тенденций и детализация результатов неудачных проверок. По сути, это похоже на панель мониторинга качества данных с открытым исходным кодом, аналогичную некоторым коммерческим инструментам. Пользователи высоко оценили простоту платформы: один пользователь Reddit порекомендовал “заценить DQOps и поблагодарить меня позже”, когда другой пытался оправдать большие ожидания в Databricks. Автор оригинального постера позже ответил, что DQOps “выглядит довольно хорошо, а также очень прост в использовании”. Этот анекдот показывает, что по сравнению с написанием большого количества кода для GE или Deequ удобный для пользователя подход DQOps может привести к более быстрому внедрению. Время обучения DQOps относительно невелико: если вы знаете основы SQL и понимаете концепции качества данных, пользовательский интерфейс поможет вам настроить проверки. Документация и пользовательский интерфейс также объясняют, что означает каждая проверка (полезно для новичков в области качества данных). Поскольку он более новый, возможно, все еще требуется некоторая доработка, но команда, стоящая за DQOps, похоже, сосредоточена на UX, чтобы привлечь пользователей. Одной из небольших проблем может быть установка и развертывание платформы (она написана на Java / Python; вы можете установить ее через pip или использовать образ Docker и т.д. — Эти шаги необходимы, в то время как чистая библиотека, такая как Pandera, - это просто установка pip в вашем существующем проекте). Но после запуска DQOps предоставляет гораздо более широкие возможности, чем большинство других открытых инструментов.

Поддержка сообщества и документация: DQOps разрабатывается специальной командой, которая предоставляет исчерпывающую документацию, руководства и обучающие видеоролики, помогающие пользователям эффективно использовать платформу. Это относительно новый проект, и его сообщество в настоящее время невелико, но растет. Команда активно взаимодействует с пользователями через такие платформы, как GitHub, где вопросы и обсуждения доступны для внесения вклада, а сопровождающие реагируют на отзывы. Кроме того, DQOps был представлен инженерам по обработке данных на таких форумах, как Reddit и Hacker News, что позволило собрать первоначальные отзывы и способствовать раннему вовлечению. В документации подчеркиваются лучшие практики DataOps, включая контроль версий и продвижение правил в среде, что отражает дальновидный подход. В заключение, DQOps превращается в комплексную платформу, управляемую сообществом, которая занимается не только тестированием данных, но и такими операционными аспектами, как мониторинг, оповещение и отчетность, с акцентом на удобство использования. Сообщество стремится объединить инженеров и аналитиков на единой платформе для совместного повышения качества данных.

Сравнение платной и бесплатной версий:

Бесплатно (с открытым исходным кодом) Особенности:

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

Платные (облачные) функции:

DQOps Cloud предлагает дополнительные функциональные возможности, включая хранение определений качества данных и результатов в облачном хранилище данных о качестве данных, позволяющем создавать расширенные информационные панели и анализировать долгосрочные тенденции.
После первоначальной 15-дневной пробной версии уровня Professional пользователи cloud будут переведены на бесплатный уровень, что ограничит доступ к бесплатному хранилищу данных только пятью таблицами. Данные из дополнительных таблиц не будут сохранены в облаке, хотя локальная функциональность останется неизменной.
Прямой доступ к личному хранилищу качественных данных (хранилище с поддержкой BigQuery, использующее Parquet data) доступен только при наличии корпоративной подписки на DQOps Cloud.

Сравнение инструментов: сильные и слабые стороны

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

Soda Core

Сильные стороны

Простые проверки на основе YAML (SodaCL) - легко читаются и записываются инженерами по обработке данных
Интегрируется с более чем 20 источниками данных для гибкого развертывания
Легкий инструмент CLI, который хорошо вписывается в конвейеры CI/CD

Недостатки

Ограниченные расширенные возможности в версии с открытым исходным кодом
Нет графического интерфейса (только YAML/CLI)
В YAML нет применения схемы, что приводит к ошибкам пользователей

Great Expectations (GX)

Сильные стороны

Обширная библиотека ожиданий (более 50 встроенных типов, более 300 с поддержкой сообщества)
Мощная экосистема интеграции с системами хранения и оркестраторами
Активное сообщество и обширная документация

Слабые стороны

Сложный процесс обучения и сложная конфигурация
В open-source нет пользовательского интерфейса (только HTML-отчеты)
Проблемы с производительностью при работе с большими наборами данных, если не использовать pushdown

Deequ

Сильные стороны

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

Недостатки

Только для Spark; не может запускаться на других движках или базах данных
Нет пользовательского интерфейса или визуального вывода; результаты в формате JSON /code
Скудная документация и небольшое сообщество

Databricks DQX

Сильные стороны

Данные автоматически профилируются, чтобы соответствовать ожиданиям
Работает как с пакетными, так и с потоковыми данными
Легко интегрируется в архитектуру Databricks medallion (бронзовая/серебряная/золотая)

Слабые стороны

Совсем новый (2024); продолжает развиваться
Официальной поддержки нет (проект Databricks Labs)
Ориентирован на Spark; отсутствуют внешние соединители

Pandera

Сильные стороны

Простой в освоении синтаксис, похожий на pandas
Работает с pandas, Dask, Polars, PySpark (pandas API)
Легкий и хорошо документированный интерфейс

Недостатки

Фокусируется на памяти; не подходит для больших наборов данных
Нет встроенного мониторинга или оповещений
Только на Python; нет пользовательского интерфейса или поддержки для пользователей, не являющихся программистами

Spark-Expectations (Nike)

Сильные стороны

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

Слабые стороны

Только для Spark (требуется PySpark)
Небольшое специализированное сообщество с ограниченной документацией
Пользовательского интерфейса нет; для настройки требуются индивидуальные решения

DQOps

Сильные стороны

Объединяет профилирование, более 150 проверок, обнаружение аномалий и управление инцидентами
Имеет удобный пользовательский интерфейс и YAML-как-код для обеспечения гибкости
Поддерживает основные облачные базы данных и визуальное отслеживание качества данных

Недостатки

Все еще находит применение; пока не зарекомендовал себя в широком масштабе
Ориентирован на SQL; ограничен для хранилищ данных и потоковой передачи
Некоторые функции (информационные панели, хранилище результатов) платного облака

Со временем дорожная карта, ориентированная на поставщика, может измениться

Вывод

Выбор подходящего инструмента для пакетной обработки данных с открытым исходным кодом зависит от ваших конкретных потребностей и среды. Например, если вам требуется ориентированная на код, легко настраиваемая платформа и у вас есть инженерные ресурсы, Great Expectations предлагает беспрецедентный набор функций и интеграций - это доказано во многих организациях, хотя вы должны быть готовы к ее сложности. С другой стороны, если вы предпочитаете экономичное решение с простой конфигурацией YAML, Soda Core легко внедрить в конвейеры для базовых проверок, учитывая, что для расширенной наблюдаемости потребуется дополнительное оборудование или коммерческое облако Soda.

У команд, работающих на Spark, есть широкий выбор: Deequ предоставляет надежную библиотеку для Scala/PySpark с функцией обнаружения аномалий (подходит для пользователей Amazon EMR или AWS Glue), в то время как Databricks DQX и Spark-ожидания Nike сосредоточены на обеспечении качества данных в режиме реального времени, что может изменить ситуацию с предотвращением некачественных данных в будущем. озера данных. Первые отзывы пользователей указывают на то, что простота использования DQX в Databricks является большим плюсом и эффективно устраняет проблемы, связанные с использованием GE на этой платформе

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

Наконец, для команд, работающих в экосистеме Python/Pandas, Pandera может стать ценным дополнением для обеспечения соблюдения контрактов на передачу данных в рамках data science и ETL-кода. Он не предоставляет панель мониторинга или оповещения, но гарантирует, что данные в ваших фреймах данных соответствуют ожидаемой схеме и ограничениям, что является важным уровнем защиты приложений. Он хорошо сочетается с модульным тестированием и позволяет выявлять проблемы на ранних этапах разработки или пакетной обработки.

Подводя итог, можно сказать, что у каждого инструмента есть своя ниша: большие надежды возлагаются на полнофункциональную проверку в виде кода, Soda Core - на упрощенные проверки, Deequ/DQX/Spark- на конвейеры, ориентированные на Spark (при этом DQX/Spark-на контроль качества "на лету"), Pandera - на интеграцию рабочих процессов на Python, и DQOps для создания более целостной и доступной платформы управления качеством данных. Принимая решение, учитывайте такие факторы, как технические навыки вашей команды, системы, в которых хранятся ваши данные, и то, отдаете ли вы предпочтение глубокой настройке или простому использованию. Используя сильные стороны этих инструментов с открытым исходным кодом и помня об их ограничениях, специалисты по качеству данных могут значительно повысить доверие к своим конвейерам пакетной обработки данных и предоставлять организации более надежные данные.

← Предыдущая статья

Great Expectations и качество данных

Следующая статья →

Data Lineage - это стратегия: за пределами наблюдаемости и отладки