Большинство методологий о жизненном цикле систем включают три фазы тестирования.
Во время ETL-процесса рекомендуется следовать трехфазному подходу при выходе в продуктивную среду с новыми источниками данных, смоделированными предметными областями или крупными релизами.
Следующие три типа тестирования должны быть проведены на каждой фазе ETL.
Тестирование модулей (Unit Testing)
Это тестирование проводится во время и после разработки до этапа тестирования QA. Оно выполняется разработчиком ETL и системным аналитиком в dev среде.
Тестирование качества (QA)
Это тестирование обычно проводится отдельной группой внутри организации в отдельной среде, имитирующей продуктив.
Среда создается и контролируется DBA и членами QA команды. Эта среда используется для того, чтобы убедиться, что все процессы ETL работают как ожидается, соответствуют всем бизнес-правилам и требованиям по времени (окно загрузки). Поскольку имитируется производственная среда, группа QA может подтвердить, что процессы ETL будут работать в продакшн-среде.
Тестирование приемки пользователем (UAT)
Эта фаза обычно проводится группой пользователей в отдельной контролируемой среде, созданной из среды QA.
Эта база данных контролируется членами команды DBA. В небольших организациях после завершения тестирования QA можно открыть эту среду для тестирования/приемки пользователями, что уменьшит затраты на поддержание инфраструктуры и оборудования.
UAT — это фаза тестирования, которая приносит пользу команде, позволяя пользователям на практике ознакомиться с данными и убедиться, что процессы работают как ожидалось. В конце UAT необходимо получить подтверждение от пользователей. Как только оно получено, можно переходить в продуктив.
Развертывание ETL
Далее наступает момент, которого все ждали: развертывание ETL.
Чтобы миграция в продуктивную среду была максимально плавной, обязательно создавайте документацию по поддержке продакшн-среды.
Эта документация должна включать следующую информацию:
- Отчет о происхождении данных (data lineage).
- Процедуры для запуска (и перезапуска) процесса инкрементальной загрузки.
- Расписание загрузки.
Важно создавать документированные процедуры восстановления после сбоев. В случае сбоя загрузки, пользователи могут получить доступ к некорректным или устаревшим данным. Поэтому необходимо заранее разработать план для предотвращения этой ситуации, прежде чем продуктивная среда будет доступна пользователям.
Документируйте и тестируйте процедуры восстановления, чтобы в случае сбоев можно было быстро восстановить данные и сделать их доступными для пользователей в кратчайшие сроки.
Работайте с командой DBA, чтобы создать стабильную продуктивную среду.
Загрузите исторические данные и запустите процесс инкрементальной загрузки с помощью планировщика для продакшн-среды.
Обязательно проведите тесты на данных в продуктиве (исторические и инкрементальные), чтобы убедиться, что данные были успешно загружены.
Миграция в продуктив
Как правило, команда ETL является частью разработки и должна избегать отвлекающих факторов, связанных с предоставлением первого уровня поддержки хранилища.
Операционная поддержка
Команда ODS — включая команду ETL — является как аналитиками, так и разработчиками.
Они собирают все бизнес-требования, анализируют результаты и строят ODS.
После того как ODS построен, он обычно передается другой команде, которая будет отслеживать и поддерживать продуктивную среду.
Архитектор ODS и моделлеры данных отвечают за модель данных, а менеджер ETL — за наполнение спроектированного ODS.
Команда разработки ETL строит процессы для загрузки ODS, а команда качества (QA) тщательно тестирует их согласно написанным тест-планам.
ODS должен быть передан группе в вашей организации, которая будет поддерживать его ежедневную работу.
Как только процесс ETL будет разработан и протестирован, первый уровень операционной поддержки для ODS и ETL должна предоставлять группа, занимающаяся мониторингом операций в продуктиве, а не команда разработки.
Команда разработки должна быть привлечена только в случае, если команда операционной поддержки исчерпала все варианты по устранению неполадок.
Объединение версий релиза
Как только команда ETL справится с большинством трудностей, свойственным разработке ETL-процессов и завершит создание всех джобов для загрузки ODS, эти джобы должны быть упакованы и перемещены в следующую среду в соответствии с жизненным циклом.
Поддерживает ли ETL инструмент инкрементальное обновление всех изменений, чтобы можно было мигрировать вашу тестовую систему в разработку одной командой?
Или нужно открывать, проверять, закрывать и переносить все файлы по одному?
С каждым релизом хранилища данных команда разработки должна создавать документ с процедурами релиза.
Документ релиза представляет релиз и предоставляет технические детали, необходимые для его миграции и поддержки.