Вступление

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

Будете ли вы отправлять код в производство без тестов или проверки кода? Итак, почему компании создают конвейеры, не тестируя свои информационные ресурсы?

Качество данных

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

В этой области есть две распространенные проблемы:

  • Неправильное понимание требований. Часто логика преобразования и согласования может стать очень сложной. Бизнес-аналитик может писать требования, используя язык своей предметной области, который должен интерпретироваться разработчиками, которые часто совершают ошибки и планируют, разрабатывают, тестируют и развертывают решения, которые являются технически правильными, но с неправильными требованиями. Ошибки такого типа обходятся очень дорого.
  • Проверка данных: конвейерное тестирование сильно отличается от кода. При разработке программного обеспечения вы тестируете функции, это детерминированное тестирование черного ящика. Для заданного входа вы всегда получаете один и тот же результат. Для активов данных тестирование более сложное: вам нужно подтвердить типы данных, значения, ограничения и многое другое. Более того, вам необходимо применить агрегаты для проверки набора данных, чтобы убедиться, что количество строк или столбцов правильное. Например, очень сложно определить, снизится ли однажды размер данных на 10% или правильно заполнены определенные значения.

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

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

Инструменты

Вот некоторые инструменты, ориентированные на качество данных:

Apache Griffin

Являясь частью экосистемы Hadoop, этот инструмент предлагает унифицированный процесс для измерения качества ваших данных с разных точек зрения, помогая вам создавать надежные активы данных. Он предоставляет DSL, который вы можете использовать для создания утверждений для ваших данных и проверки их в рамках вашего конвейера. Он интегрирован с Spark. Вы можете добавить правила и утверждения для своего набора данных, а затем запустить проверку как задание Spark. Проблема с Griffin заключается в том, что DSL может стать сложным в управлении (JSON), и его трудно интерпретировать нетехническими специалистами, что означает, что он не решает проблему неправильно понятых требований.

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

Пример правила в Griffin:

"rules": [
      {
        "dsl.type": "griffin-dsl",
        "dq.type": "accuracy",
        "out.dataframe.name": "accu",
        "rule": "src.id = tgt.id AND src.age = tgt.age AND src.desc = tgt.desc",
        "details": {
          "source": "src",
          "target": "tgt",
          "miss": "miss_count",
          "total": "total_count",
          "matched": "matched_count"
        },
        "out": [
          {
            "type": "metric",
            "name": "accu"
          },
          {
            "type": "record",
            "name": "missRecords"
          }
        ]
      }
    ]

Большие надежды

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

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

БА или тестировщики пишут утверждения данных (Ожидания), которые преобразуются в удобочитаемый тест в пользовательском интерфейсе, чтобы каждый мог их увидеть и проверить. Он также может выполнять профилирование данных, чтобы генерировать для вас некоторые утверждения. Вот несколько примеров ожиданий, написанных на Python:

expect_table_row_count_to_equal(100)
expect_column_values_to_be_between(
    column="percent_agree",
    min_value=10,
    max_value=90,
)

Вы можете выбирать из множества ожиданий и создавать свои собственные:

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

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

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

Заключение

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

Если вы работаете в команде Scala и сильно полагаетесь на Spark, то Griffin будет легче внедрить. Если вы уже используете Airflow и / или Python, то Большие надежды станет разумным дополнением к вашему поясу с инструментами.

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

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