25.03.2012
Причина:
хранилище данных - это сущность с постоянно изменяющимися структурой (форма, количество, расположение объектов) и данными (в любой момент может прийти исключение).
На вопрос "как вы тестировали DWH?", в целом, получаемый ответ "никак", за исключением корректных ответов, суть которых сводится к "почти никак".
И это логично, писать тесты занимает много времени, потому что нужно придумать, как по другому проверить трансформацию, а не так как она реализована в ETL. Однажды измененная, логика или исключения в данных автоматически делают тесты устаревшими. Нет того, кто сидит и следит за всеми изменениями, люди приходят и уходят и, как правило, уходят сразу после ETL.
Если все так плохо, то что вообще тестировать и нужно ли после того, как ETL сдан и вроде как работает. Как придумать механизм, который будет фиксировать изменения, решать - аномалии это или нет и сообщать о них до того, как эти аномалии попадают в финансовый отчет? Кому вообще сообщать и кому это надо? И что сообщать, чтобы не отправляли в корзину?
Год назад я задался этими вопросами и пробую их решить на примере одного долгосрочного проекта.
Входные данные:
- хранилище данных с 4х слойной архитектурой (Stage, Cleansing, DWH, Data Marts)
- объем данных порядка 45 TB во всех слоях, ежедневное движение данных порядка 500 GB
- количество таблиц в слое DWH более 200, средний рост более 10 таблиц в квартал
- база данных Oracle 11g
- железяка Exadata
- организация ETL смешанная: пакеты PL/SQL и средство Business Objects Data Integrator
14.04.2012
Предмет:
Тестировать нужно все, но пока ограничимся тем, что в облаках, так как здесь происходят все транcформации.
Предметом являются все артефакты данной области:
- Техническая документация.
- Объекты базы данных, модель.
- Реализованные трансформации (ETL).
- Процесс выполнения кода механизмами загрузки данных, обработка параметров, инициальная и дельта загрузка данных.
- Отчеты.
- Мониторинг и поддержание качества.
Стратегии:
За основу можно взять стратегии, которые предложил Jeff Theobal.
- Полнота данных - все ожидаемые данные загружаются
- Преобразование данных - все данные преобразуются правильно, в соответствии с бизнес-правилами и / или проектными спецификациями.
- Качество данных - ETL правильно осуществляет обработку значений по-умолчанию, исправляет или игнорирует неверные данные.
- Производительность и масштабируемость - загрузка дынных осуществляется в пределах ожидаемого времени, техническая архитектура является масштабируемой.
- Интеграция - реализованный ETL работает с другими, уже реализованными, процессами загрузки данных.
- Приемо-сдаточные испытания - реализованное решение соответствует ожиданиям пользователей.
- Регрессия и мониторинг - обеспечение работоспособности функциональности при каждом изменении кода.