🏆 Рейтинг ІТ-работодателей 2019: уже собрано более 5000 анкет. Оцените свою компанию!
×Закрыть

Тестирование Big Data: вызов принят

Всем привет! Меня зовут Дмитрий Собко, и я занимаюсь тестированием больше 7 лет. Начинал свою карьеру с должности Junior Manual QA на проекте по разработке Android-приложения. Также был Automation Lead команды, которая разрабатывает приложение big data на стеке GCP (Google Cloud Platform). И именно эти опытом хотел бы поделиться.

В статье рассмотрены особенности тестирования именно приложений big data, которое немного отличается от тестирования REST API, UI и тем более Android/iOS. В то же время, зная основные моменты, можно построить достойный процесс контроля качества даже таких, на первый взгляд, нетестируемых решений.

Что такое big data

I keep saying that the sexy job in the next 10 years
will be statisticians, and I’m not kidding.

Hal Varian, chief economist at Google

Big data — это понятие, о котором, наверное, слышали уже все. Google Trends показывает, что интерес к big data возник примерно в 2012 году и не стихает до сих пор.

Чтобы определиться, что же такое big data, используем Google и находим следующие объяснения:

  • это просто много данных (> 10 Тбайт);
  • это настолько большие таблицы, что их невозможно открыть и проанализировать в Excel;
  • это неструктурированные данные из разных источников, разного объема, которые показывают, как ведут себя наши кастомеры и т. д.

Мне больше всего нравится определение из Википедии:

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

Существует и так называемая 3V-теорема, раскрывающая суть термина big data с другой стороны.

Volume — объем данных. Он действительно большой. Обычно это больше 50 Тбайт и до бесконечности.

Velocity — данные регулярно обновляются, поэтому требуется их постоянная обработка (от batch processing, когда данные загружаются пакетами, например раз в сутки, до real time streaming, когда данные в реальном времени попадают на графики / в отчеты и даже влияют на системы принятия решений на основе ML).

Variety — разнообразные данные могут иметь абсолютно разные форматы, быть неструктурированными или структурированными частично (от CSV/Avro-файлов с четкой структурой до логов в потоке).

Путь в Cloud

Со временем хранить такие объемы данных на собственных или арендованных серверах становится все сложнее и дороже. И когда в 2006-м появился AWS (Amazon Web Services), лишь немногие догадывались, к каким глобальным инфраструктурным изменениям это приведет.

В 2019 году достаточно взглянуть на этот график:

В 2020-м примерно половина всех серверов будет в клауде, и с этим необходимо считаться.

Одной из компаний, которая наиболее подробно описывала путь от собственной инфраструктуры к Google Cloud, является Spotify. В ее блоге подробно рассказывается, почему были выбраны те или иные решения. Рекомендую почитать всем, кто интересуется этой темой.

И немного о Cloud-провайдерах:

Каждое третье приложение в клауде приходится на AWS. Azure от Microsoft и Google Cloud Platform соответственно лидеры оставшегося сегмента. Сопоставив эти два графика, можно сделать вывод, что изучение Cloud-технологий в целом и AWS в частности для тех, кто пока далек от этого, в том числе для QA-инженеров, становится скорее необходимостью, чем возможным желанием.

Как вообще выглядит проект big data

Обычный проект big data выглядит (очень упрощенно) следующим образом:

  1. На вход приложения попадают разные данные из разных источников. Обычно таких источников два:
    • streaming (потоковые) данные — любая message queue (Kafka, Google PubSub, Amazon SNS и пр.);
    • batch (пакетные) данные — обычно CSV, TXT, Avro, JSON-файлы.
  2. Данные извлекаются и складываются в Staging-таблицы. На этом этапе также возможна дедубликация, отдельная обработка записей, которые мы не смогли распарсить, и т. д. По сути, это настоящие source-данные as is.
  3. Дальше данные из Staging-таблиц трансформируются, группируются, фильтруются, дополняются метаданными и попадают в DWH (Data Warehouse), или в так называемый Target layer. Эти данные уже структурированы (например, имеют одинаковый формат полей с датой), и таблицы также имеют структурные связи между собой. Подробнее можно почитать здесь. В случае Google Cloud Platform это может быть BigQuery. У Amazon это Redshift. Но также это может быть Oracle, PostgreSQL и т. д.
  4. На основе данных в DWH формируются аналитические отчеты / принимаются решения ML-системами. В самом простом случае на выходе у нас:
    • набор данных, на основе которых уже строится визуализация (Tableau, Power BI, Zoomdata и пр.);
    • отчеты в виде CSV-файлов, которые отправляются, например, на SFTP-сервер или на S3-бакет.

Пример data pipeline на Google Cloud Platform

На входе данные поступают в виде batch-файлов или потоков (stream).

С помощью фреймворка Cloud dataflow данные извлекаются, трансформируются, обрабатываются и загружаются в DWH. В данном примере в основе DWH лежит BigQuery.

На основе полученных данных строится аналитика Cloud Machine Learning, Data Studio, возможная визуализация (Third-Party Tools) и т. д. Также в данном примере для кеширования данных используется Cloud Bigtable.

А как это протестировать

Как видно, здесь нет в чистом виде ни back-end- (API), ни front-end-частей. То есть у нас есть:

  • входные данные, которые мы практически не можем проконтролировать;
  • data processing (программная часть, которая отвечает за ETL — extract, transform, load);
  • таблицы/файлы/визуализация на выходе.

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

Подходы к тестированию

Тестирование на моках/стабах

В этом случае мы проверяем корректность трансформаций, выгрузки на mocked-данных. Например, используем CSV с несколькими строками на входе. Отдельно проводим негативное тестирование (XML-файл с незакрытыми тегами и пр.). Таким образом, мы сможем покрыть практически весь функционал data flow, но при этом у нас не будет уверенности, что все корректно и правильно работает на проде (а это самое важное!).

Тестирование на реальных данных

В таком случае мы пишем тесты для реальных данных, только догадываясь, сколько их будет и какими они будут. Допустим, мы знаем, что все кастомеры из CSV Customers на входе из страны Ukraine должны попасть в staging-таблицу customers_stage с кодом страны UA, а уже оттуда — в таблицу super_customers в Target-слой. Соответственно, мы и пишем такие тесты, опираясь на те данные, которые к нам пришли реально, и отталкиваясь от них.

Микс двух подходов

Unit/Integration-тесты пишем с использованием mocks/stubs. Также пару функциональных (end-to-end) тестов пишем для проверки реальной ситуации на энвайронменте с реальными данными. По моему мнению, этот подход является самым оптимальным, поскольку позволяет получить уверенность, что все хорошо идет на проде. И при этом при разработке новых фич он позволяет с помощью Unit/Integration-тестов быстро убедиться, что нет регрессии и вся логика построена правильно. Кроме того, на проде, конечно же, должна работать система мониторинга со сбором разнообразных метрик и отправкой нотификаций/алертов и пр.

Виды тестирования

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

Metadata Testing

Проверяем метаданные собственно данных (длину, тип) и таблиц (дату изменения, дату создания, количество строк, индексы и пр.).

Data Validation Testing

Проверяем, корректно ли данные прошли все трансформации. В качестве примера можно использовать преобразование Unix-тайм-стампа к дате.

Completeness (Reconciliation) Testing

Проверяем, все ли source-данные корректно обработаны. (Данные, которые успешно распарсились, попали в staging-слой, а если нет, то в error-таблицы или просто записались в логи.)

Accuracy Testing

Проверяем корректность логики трансформаций таблиц по пути от staging до analytics-слоя. (Обычно это делается путем создания с помощью SQL соответствующих проверочных view.)

А как это все автоматизировать

Для Unit/Integration-тестов можно легко использовать JUnit/TestNG (в случае Java-кода). Для Scala и GCP интересной альтернативой может быть библиотека Scio от того же Spotify.

Для функциональных тестов в нашем случае оптимальной была связка Kotlin + Spring + Cucumber BDD.

С помощью BDD-подхода мы наиболее точно и лаконично описывали все манипуляции с данными в рамках тестов. И при этом тест-репортами пользовались также дата-аналитики.

Почему Kotlin? Как мне кажется, это сейчас один из самых интересных JVM-языков для использования в том числе в автотестах. Есть много фишек, отличающих его от Java в лучшую сторону. Для тестировщиков, знающих Java/Groovy, переход будет очень легким. Ну и по состоянию на 2019 год можно уже смело утверждать, что этот язык перерос большинство детских болезней и продолжает развиваться.

Spring использовали для Dependency injection и еще нескольких приятных особенностей.

Позитивные итоги

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

Тестирование приложения big data непривычно, ставит перед QA много вызовов, которые нужно принимать и можно уверенно решать. И вместе с тем это интересно.

Спасибо за внимание!

LinkedIn

15 комментариев

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

Спасибо за статью. Я большой ценитель Google BigQuery, нравится быстрота работы, удобство и темпы развития. С недавних пор, например, в BigQuery можно строить модели машинного обучения, автоматизировать расчет агрегированных данных, запрашивать содержание таблиц по состоянию на конкретное время. И для всего этого достаточно владеть только SQL.
О самых интересных решениях в BigQuery пишу в канале: t.me/BigQuery.

писати авто тест для тестування Big Data використовуючи BDD ? Можна глянути на приклад feature файла , або хоча б одного сценарію ? Просто хочу подивитись на це порно))

На псевдо-коді якось так:

 
Scenario: Check Beta feed 
	Given I check Beta passName field is correct 
	And I check Beta views field is correct 
...
	When Beta channelDate field is with current date
	Then Beta reportDate field contains correct time range
Существует и так называемая 3V-теорема, раскрывающая суть термина big data с другой стороны.

4V вроде ж ....

В мире структурированных данных это конечно работать будет, но мне кажется это и обычные фукнциональные тесты покроют. А что делать, например, с медицинскими записями (где пол может быть: m, f, 1, 0, −1, null, «", male, female и неожиданно после 2Тб строк данных например «other». Причем все это валидные значения. Или загадочный ML датасет на пару сотен гигабайт с «boolean» значениями в 99.999% 1 или 0, но иногда −1, а потом неожиданно −2 или 2.

Статья по факту небольшая выжимка базовой популярной теории по Big Data. Если уже такой заголовок, то нужно копать глубже и покрыть следующие темы:

1) Что привнесли BigData технологии в мир тестирования? Какие сложности и вызовы?
2) В чем отличие тестирования BigData проекта от BI/DWH проекта?
3) С помощью какого функционала (тулсета) выполняются разного рода вида тестирования на различных Cloud платформах?
4) Есть ли Best Practice от Cloud провайдеров, как лучше организовать тестирование?
5) Как тестировать данные реально на больших объемах?
6) Есть ли смысл применять мануальное тестирование? Если да, то каким образом?

и т.д.

Спасибо за комментарий. Если вкратце, то:

1) Что привнесли BigData технологии в мир тестирования? Какие сложности и вызовы?

Новые интересные проекты, в которых тестами нужно покрывать обработку данных, сами данные и тд. Один из основных вызовов состоит в том, что это отличается от тестирования API, Mobile и UI. Как использованием других подходов, так и намного более разнообразной архитектурой самих приложений.

2) В чем отличие тестирования BigData проекта от BI/DWH проекта?

Тестирование BI/DWH в данном примере — это составная часть тестирования всего проекта.

3) С помощью какого функционала (тулсета) выполняются разного рода вида тестирования на различных Cloud платформах?

Для Unit/Integration-тестов можно легко использовать JUnit/TestNG (в случае Java-кода). Для Scala и GCP интересной альтернативой может быть библиотека Scio от того же Spotify.

Для функциональных тестов в нашем случае оптимальной была связка Kotlin + Spring + Cucumber BDD.

Для AWS и GCP вполне рабочий вариант. В случае Python и R, используются уже другие библиотеки соответственно.

4) Есть ли Best Practice от Cloud провайдеров, как лучше организовать тестирование?

Да, полный ответ будет очень большим. Самый простой пример — GCP предлагает использовать замоканные PubSub, BigQuery и т.д.

5) Как тестировать данные реально на больших объемах?

Такой подход работал примерно на 1 Pb. Мне кажется, это уже достаточно большой объем.

6) Есть ли смысл применять мануальное тестирование? Если да, то каким образом?

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

это просто много данных (> 10 Тбайт);
это настолько большие таблицы, что их невозможно открыть и проанализировать в Excel;
это неструктурированные данные из разных источников, разного объема, которые показывают, как ведут себя наши кастомеры и т. д.

Первый пункт: а если данных 9Тб, то это не big data? А если данных 100Gb, но их нужно запроцессить за час?
Второй пункт: Excel в состоянии открыть таблицу на 1GB? А на 100Gb? (я не знаю, по этому и спрашиваю). Если нет, то как это пересекается с первым пунктом?
Третий пункт: это больше о формате данных, а не о их размере. Ведь кастомеров может быть не сильно и много, и там Big Data-ой и пахнуть не будет, но вот для ML данных уже будет достаточно.

Мне больше всего нравится определение из Википедии:

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

От части это так, но такие инструменты как Apache Hadoop и Apache Spark уже стали «традиционными способами обработки данных».

Всё что описано выше, это касается любой data processing системы.

Что касается тестирования Big Data, столько слов, но нет самого важного, если речь идёт о объёме данных(так как в статьи термин Big Data упирается именно в объём), — «performance».

Спасибо за комментарий. Постараюсь вкратце ответить на вопросы.

Чтобы определиться, что же такое big data, используем Google и находим следующие объяснения:

это просто много данных (> 10 Тбайт);
это настолько большие таблицы, что их невозможно открыть и проанализировать в Excel;
это неструктурированные данные из разных источников, разного объема, которые показывают, как ведут себя наши кастомеры и т. д.

— Это то, что можно прочитать в Гугле вбив в поиск «Big Data». На практике, конечно же, все индивидуально. И 9Тб данных тоже можно назвать Big data. Все зависит еще и от Variety и Velocity. Особенно, если учесть, что их очень скоро, скорее всего, станет уже 10 Тб.

— На 1 Гб Excel открывает часть файла. И этого не хватает для нормальной работы. И, соответственно, в интернете можно встретить такое определение понятия Big data. Так сказать, в сравнении со знакомым большинству Excel. В принципе, почему бы и нет?

— По данным от кастомеров аналогично. Одно из объяснений самого концепта.

По поводу перформанса — это отдельная большая тема, которая тянет на отдельную статью. И которая имеет очень много интересных аспектов именно в клауде, когда у нас динамически меняется количество нод и прочее.

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

Больше половины — теория о биг дате, так сказать интро, которое очень быстро перетекает в конец статьи. А где тестирование? :(

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

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

все вірно, але це теорія, яка останні роки перетікає зі статті в статтю.
Як на мене, це загальний підхід до тестування любого BI проекту. Big data проекти ж відрізняються технологіями, на яких реалізоване рішення, де складність додають обєми даних, швидкістю опрацювання і т.д. (і знову таки це дуже субєктивно, де межа, що ось це вже біг дата проект, а цей ще ні). В багатьох випадках приставка Big data до проекту використовується для додавання такої «перчинки» і вагомості.

хотілося б почути практику:
— яким чином і підходом на практиці ви реалізували види тестування, описані в статті, особливо Data Validation Testing, Accuracy Testing
— які існують нові тулзи, що вміють порівнювати дані

Дякую за коментар.

— На практиці ми реалізували підхід названий

Микс двух подходов

і відповідно частина перевірок Data Validation та Accuracy покривалася unit та integration тестами

Для Unit/Integration-тестов можно легко использовать JUnit/TestNG (в случае Java-кода). Для Scala и GCP интересной альтернативой может быть библиотека Scio от того же Spotify.

частина функціональними на

Kotlin + Spring + Cucumber BDD

— Для порівняння даних в різних місцях пайплайна використовували або Kotlin код і напряму працювали з даними або SQL, коли порівнювали дані з таблиць, вьюшок і т.д.

Подписаться на комментарии