/НАЗАД
Введение
Некоторое время назад многие российские компании, чей бизнес очень сильно завязан на обработке и анализе больших объемов данных (банки, ритейл, телеком) задумались о том, как можно уменьшить стоимость владения хранилищами данных, построенных на западных технологиях. События последнего времени только ускорили этот процесс. И сейчас количество компаний, для которых актуальна миграция существующих хранилищ данных, построенных на Oracle, MS SQL и других проприетарных СУБД, на решения открытого ПО и отечественных поставщиков, резко выросло, а СУБД GreenPlum фактически становится отраслевым стандартом в хранилищах данных.
При этом и компании-заказчику, и организации-исполнителю необходимо оценить бюджет проекта миграции. Первые обычно запрашивают подобную оценку у вторых.
Именно такую задачу поставил нам клиент – крупная торговая компания. После небольшого ознакомления с возможными методиками, выбор пал на метод COSMIC (Common Software Measurement International Consortium), являющийся одной из разновидностей оценки функционального объема по функциональным точкам и выросший до стандарта ISO 19761. Плюсом в пользу СOSMIC стало разработанное консорциумом адаптированное руководство для оценки функционального объема хранилищ данных.
Кратко о методе COSMIC
Метод COSMIC основан на декомпозиции функционала системы на минимальные функциональные процессы (Functional User Requirements), в которых считаются перемещения данных (object of interest). Одно перемещение – 1 CFP (COSMIC Function Point). Существуют четыре типа перемещений данных: вход, выход, чтение, запись.
-
Entry – внешний входной поток группы данных в функциональный процесс.
-
Exit – внешний выходной поток группы данных из функционального процесса.
-
Read – внутренний входной поток группы данных из области постоянного хранения в функциональный процесс.
-
Write – запись группы данных внутри функционального процесса в область постоянного хранения.
Хранилище данных имеет слои, наполнение которых можно представить как группу соответствующих функциональных процессов по перемещению групп данных (object of interest) со слоя на слой. При этом данные сохраняются в таблицах каждого слоя.
Согласно руководству по оценке функционального объема хранилища данных по методу COSMIC, заполнение таблицы в слое хранилища данных в batch-процессе можно представить следующим образом:
| Тип FP | Комментарий | Кол-во CFP |
|---|---|---|
| Entry | Начало процесса (триггер по времени или событию) | 1 CFP |
| Entry/Exit | Запрос и получение метаданных для корректной загрузки (например, при дельта-загрузке, информации о последних загрузках) | 2 CFP |
| Read или Entry | Чтение группы данных из внешнего источника или таблицы слоя хранилища данных | 1 CFP |
| Write | Трансформация и запись группы данных в целевую таблицу слоя хранилища данных | 1 CFP |
| Exit | Конец процесса. Журналирование результатов работы процедуры | 1 CFP |
При оценке необходимо учесть следующие моменты:
-
Если метаданные, используемые в процессе, лежат в той же системе, то пара запрос/получение метаданных может быть заменена на одно чтение (1 CFP).
-
Если в рамках batch-процесса загружается несколько таблиц (object of interest), то начало и конец процесса имеет смысл учитывать только один раз, а не по каждой таблице.
Итоговая оценка всего проекта рассчитывается как сумма загрузок всех групп данных.
Расчет трудоемкости проекта рассчитывается по формуле:
Трудоемкость проекта (чел/дни) = Функциональный объем (CFP) / Продуктивность
где продуктивность – количество CFP, выполняемое сотрудником за один день.
Пример расчета функционального объема на основе проекта миграции с Oracle на Arenadata DB
За 6 месяцев, с октября 2022 г. по март 2023 г., наша компания осуществила миграцию с Oracle на Arenadata DB (коммерческая сборка GreenPlum, далее по тексту просто ADB) хранилища данных по веб-аналитике для крупной торговой компании. Более подробно о проекте и его результатах можно узнать из доклада «Как мы пришли к Arenadata DB».
Здесь же посчитаем функциональный объем проекта. Для начала декомпозируем весь проект на типы функциональных точек. Выделим основные типы:
-
Загрузка существующих входных данных из исходной системы интернет-магазина в ADB без изменений, с накоплением истории (схема таблиц src_hybris).
-
Загрузка общих справочников и таблиц фактов из хранилища Oracle в целевые таблицы, без изменений (схема kdw).
-
Предварительный расчет дополнительных атрибутов и показателей, необходимых для формирования целевых таблиц детального слоя, с сохранением результатов в стэйджинге (схема stg_hybris).
-
Загрузка данных интернет-магазина в целевые таблицы детального слоя данных (схема hybris).
-
Обогащение данных. Расчет дополнительных характеристик или формирование новых расчетных показателей.
-
Загрузка истории.
-
Тестирование – сверка данных в старом хранилище на Oracle c новым на ADB.
Тип 1. Загрузка из исходной системы интернет-магазина
Из исходной системы данные таблиц копируются без преобразований. Метаданные о типе загрузке (полная загрузка, дельта …) и результатах предыдущей загрузки хранятся в самой базе ArenadataDB.
Согласно методике расчета, описанной выше, общий функциональный объем:
-
Entry – старт загрузки по расписанию – 1 CFP;
-
Read – чтение метаданных для загрузки 59 таблиц – 59 CFP;
-
Read – чтение данных 59 таблиц внешних таблиц – 59 CFP;
-
Write – запись данных в 59 таблиц – 59 CFP;
-
Write – запись в подсистему метаданных результатов 59 загрузок – 59 CFP;
-
Exit – завершение группы загрузок – 1 CFP.
Итого – 238 CFP.
Тип 2. Загрузка общих справочников и фактов из старого хранилища
Аналогично загрузка готовых таблиц из хранилища Oracle осуществляется по событию. Триггером начала загрузки является завершение их формирования в источнике. Общее количество таблиц – 44, функциональный объем этой группы загрузок – 178 CFP.
Тип 3. Предварительный расчет дополнительных атрибутов и показателей
Группа загрузок предварительного расчета дополнительных атрибутов и показателей реализует дополнительную бизнес-логику. Триггером начала осуществления загрузок этого типа является завершение первых двух. Качественную оценку функционального объема таких загрузок можно провести только при наличии четкого понимания, какие данные необходимы для реализации требований, и в каких моментах будет осуществляться их чтение, преобразование и сохранение в таблицах. В проектах миграции эти требования фактически уже реализованы в старой системе и могут быть проанализированы по коду реализации или по имеющейся документации.
Для лучшего понимания приведу два примера:
1.Из исходной системы в хранилище приходит информация о кликах пользователя на сайте интернет-магазина. Она представляется парой строк URL – с какой страницы на какую был осуществлен переход, плюс дополнительные атрибуты: пользователь, компания, дата и время визита и т.д. Для анализа поведения пользователей на сайте и мониторинга эффективности маркетинговых акций URL строки необходимо распарсить (выделить домен, иерархию страниц сайта, get-параметры). Ниже приведен расчет функционального объема для такой процедуры парсинга:
| Тип движения | Комментарий | Функциональный объем |
|---|---|---|
| Entry | Запуск процедуры расчета | 1 CFP |
| Read | Получение параметров выборки данных из подсистемы метаданных | 1 CFP |
| Read | Чтение массива данных строк URL в Python-процедуру | 1 CFP |
| Write | Запись результатов парсинга в стэйджиговую таблицу схемы stg_hybris через формирование текстового файла и последующей его загрузки в Arenadata DB по протоколу GPFDIST. N.B. Руководство по оценке COSMIC говорит, что промежуточные структуры хранения не должны учитываться в оценке, поэтому запись в файл/ чтение из файла мы не учитываем в нашей оценке. | 1 CFP |
| Write | Запись результатов работы процедуры расчета в подсистему метаданных | 1 CFP |
| Exit | Завершение работы процедуры и журналирование результатов | 1 CFP |
| Итого: | 6 CFP |
2.Визиты на сайт интернет-магазина осуществляют не только реальные пользователи, но и роботы. Соответственно, встает задача пометить эти «механические» визиты. Компания использует разные алгоритмы для этой задачи. Самый простой из них – это определение по известным характеристикам (ip-адрес, наличие известной подстроки в строке URL и т.д.)
Ниже приведен расчет функционального объема для такой процедуры расчета:
| Тип движения | Комментарий | Функциональный объем |
|---|---|---|
| Entry | Запуск процедуры расчета | 1 CFP |
| Read | Получение параметров выборки данных из подсистемы метаданных | 1 CFP |
| Read | Чтение массива данных строк URL в процедуру pgPLSQL | 1 CFP |
| Read | Чтение характеристик известных роботов (Алгоритм определения 1) | 1 CFP |
| Read | Определение роботов по поведенческим характеристикам (Алгоритм определения 2) | 1 CFP |
| Write | Запись результатов определения роботов по алгоритму 1 и 2 в стэйджиговую таблицу схемы stg_hybris. | 1 CFP |
| Write | Запись результатов работы процедуры в подсистему метаданных | 1 CFP |
| Exit | Завершение работы процедуры и журналирование результатов | 1 CFP |
| Итого: | 8 CFP |
Типы 4, 5. Загрузка в таблицы детального слоя и обогащение данных
Загрузка данных в таблицы детального слоя и дальнейшее обогащение осуществляется аналогично либо простым загрузкам, либо чуть более сложным, как в предыдущем примере.
К простым относятся загрузки, где источником для целевой таблицы может быть:
-
существующая таблица;
-
запрос, который можно оформить как представление и фактически получить один источник данных.
В этом случае функциональный объем такой загрузки будет равен 6 CFP.
К более сложным относятся процедуры, в которых несколько источников данных и несколько целевых таблиц. Например, процедура кластеризации клиентов для разных типов пользователей. Для каждого типа кластеризация осуществляется отдельно, поэтому количество чтений определяется количеством типов пользователей. На выходе получаются две таблицы – параметры кластеров и соотнесение пользователей к этим кластерам.
Тип 6. Загрузка истории
Загрузка истории в целевые таблицы осуществляется один раз, практически в полуавтоматическом режиме. В связи с этим, в оценке функционального объема можно пренебречь затратами на чтение метаданных и журналирование. Для грубой оценки будем использовать пару чтение/запись для одной таблицы. Итоговая оценка будет равна количеству мигрируемых целевых таблиц, умноженному на 2.
Тип 7. Тестирование
Результаты миграции и работы регламентных процедур загрузки проверяются тестами загруженных данных в старую и новую системы (какое-то время обе системы работают параллельно).
Соответственно, каждый тест состоит из перемещений (3 CFP):
-
чтение из старой системы;
-
чтение из новой системы;
-
сравнение и запись результатов сравнения в постоянную область хранения.
Итоговый функциональный размер нашего проекта:
| Тип функциональности | Кол-во загрузок/тестов | Функциональный объем, CFP |
|---|---|---|
| Экстракция из исходной системы (интернет-магазин) | 59 | 236 |
| Копирование данных из хранилища Oracle | 44 | 176 |
| Предварительный расчет доп. атрибутов и показателей | 5 | 23 |
| Формирование детального слоя и обогащение данных | 80 | 359 |
| Еженедельные расчеты | 8 | 33 |
| Загрузка истории | 80 | 160 |
| Тестирование | 189 | 567 |
| Пары Entry/Exit (количество батчей)* | 3 | 6 |
| ИТОГО: | 468 | 1560 |
При определении общего объема количества входов/выходов в процессы было рассчитано по количеству батчей-загрузок, другими словами, количеству AirFlow DAGs.
Адаптация модели COSMIC за счет ETL-фреймворка и автоматизации тестирования
Одно из правил метода COSMIC гласит: если один и тот же функционал вызывается несколько раз с разными наборами данных в рамках одного функционального процесса, то его нужно учитывать только один раз, а не по количеству вызовов.
Для реализации проектов хранилищ данных на GreenPlum наша компания разработала ETL-фреймворк (Описание ETL-фреймворка: Переходим на Greenplum быстро, Исходные коды ETL-фреймворка), позволяющий сократить объем работ как раз за счет переиспользования функционала.
В состав ETL-фреймворка, помимо прочих, входят функции:
-
реализация типовых загрузок;
-
работа с подсистемой метаданных;
-
журналирование.
Под типовыми понимается перемещение данных со слоя на слой без значительных преобразований и специфической бизнес-логики, при условии, что данные перемещаются из одного источник в один приемник. В этом случае разработчику необходимо только создать целевую таблицу и, при необходимости, исходное представление, и внести соответствующие метаданные в ETL-фреймворк. Дальше поток загрузки будет сформирован автоматически.
Таким образом, для типовых загрузок мы можем оценить функциональный объем в 1 CFP, а из оценки нетиповых загрузок исключить чтение и запись в подсистему метаданных.
Дополнительно, написание небольшой Python-процедуры, которая считывает два SQL запроса - к старому и новому хранилищу данных, сверяет возвращаемые данные между собой и записывает результат тестирования в отдельную таблицу, позволило сократить функциональный объем за счет операции записи, т.е. сделать ее типовой для всех тестов.
Таким образом, за счет этих ноу-хау мы сократили функциональный объем больше, чем на 50 %:
| Тип функциональности | Тип загрузки | Кол-во загрузок/тестов | Функц. объем, CFP | Скорректированный функц. объем, CFP |
|---|---|---|---|---|
| Экстракция из исходной системы (интернет-магазин) | Типовая | 59 | 236 | 59 |
| Копирование данных из хранилища Oracle | Типовая | 42 | 168 | 42 |
| Не типовая | 2 | 8 | 4 | |
| Предварительный расчет доп. атрибутов и показателей | Не типовая | 5 | 23 | 13 |
| Формирование детального слоя и обогащение данных | Типовая | 53 | 212 | 53 |
| Не типовая | 27 | 147 | 93 | |
| Еженедельные расчеты | Типовая | 4 | 16 | 4 |
| Не типовая | 4 | 17 | 9 | |
| Загрузка истории | Типовая | 80 | 160 | 80 |
| Тестирование | 189 | 567 | 378 | |
| Пары Entry/Exit (количество батчей) | 3 | 6 | 6 | |
| ИТОГО: | 468 | 1560 | 741 |
Заключение
Любая модель оценки – это прежде всего макет, имеющий свои недостатки. Внимательный читатель справедливо заметит, что предлагаемая модель никак не учитывает сложность трансформаций или требования по производительности. Да и продуктивность сотрудников разной квалификации очень вариативна. Это, конечно, так. Например, проведенное специалистами Измирского технологического института исследование [4] проектов, реализованных разными командами, фактически привело к пониманию несравнимости прогнозируемых трудозатрат.
Вместе с тем, модель COSMIC дает стандартную методику, по которой можно оценить функциональный объем в абсолютных, а не качественных показателях объема проекта. В проектах миграции, когда все процедуры загрузки уже есть, и их надо переложить на новый технологический стэк, оценка может быть достаточно точной.
Если же функциональный объем дополнить статистикой выполнения проектов стабильной командой, то для нашей компании, оказывающей профессиональные услуги в области создания хранилищ данных, методика COSMIC позволяет с высокой степенью точности оценить предстоящие работы миграции. Это очевидная выгода и заказчику, и нам.
/НАЗАД
Введение
Некоторое время назад многие российские компании, чей бизнес очень сильно завязан на обработке и анализе больших объемов данных (банки, ритейл, телеком) задумались о том, как можно уменьшить стоимость владения хранилищами данных, построенных на западных технологиях. События последнего времени только ускорили этот процесс. И сейчас количество компаний, для которых актуальна миграция существующих хранилищ данных, построенных на Oracle, MS SQL и других проприетарных СУБД, на решения открытого ПО и отечественных поставщиков, резко выросло, а СУБД GreenPlum фактически становится отраслевым стандартом в хранилищах данных.
При этом и компании-заказчику, и организации-исполнителю необходимо оценить бюджет проекта миграции. Первые обычно запрашивают подобную оценку у вторых.
Именно такую задачу поставил нам клиент – крупная торговая компания. После небольшого ознакомления с возможными методиками, выбор пал на метод COSMIC (Common Software Measurement International Consortium), являющийся одной из разновидностей оценки функционального объема по функциональным точкам и выросший до стандарта ISO 19761. Плюсом в пользу СOSMIC стало разработанное консорциумом адаптированное руководство для оценки функционального объема хранилищ данных.
Кратко о методе COSMIC
Метод COSMIC основан на декомпозиции функционала системы на минимальные функциональные процессы (Functional User Requirements), в которых считаются перемещения данных (object of interest). Одно перемещение – 1 CFP (COSMIC Function Point). Существуют четыре типа перемещений данных: вход, выход, чтение, запись.
-
Entry – внешний входной поток группы данных в функциональный процесс.
-
Exit – внешний выходной поток группы данных из функционального процесса.
-
Read – внутренний входной поток группы данных из области постоянного хранения в функциональный процесс.
-
Write – запись группы данных внутри функционального процесса в область постоянного хранения.
Хранилище данных имеет слои, наполнение которых можно представить как группу соответствующих функциональных процессов по перемещению групп данных (object of interest) со слоя на слой. При этом данные сохраняются в таблицах каждого слоя.
Согласно руководству по оценке функционального объема хранилища данных по методу COSMIC, заполнение таблицы в слое хранилища данных в batch-процессе можно представить следующим образом:
| Тип FP | Комментарий | Кол-во CFP |
|---|---|---|
| Entry | Начало процесса (триггер по времени или событию) | 1 CFP |
| Entry/Exit | Запрос и получение метаданных для корректной загрузки (например, при дельта-загрузке, информации о последних загрузках) | 2 CFP |
| Read или Entry | Чтение группы данных из внешнего источника или таблицы слоя хранилища данных | 1 CFP |
| Write | Трансформация и запись группы данных в целевую таблицу слоя хранилища данных | 1 CFP |
| Exit | Конец процесса. Журналирование результатов работы процедуры | 1 CFP |
При оценке необходимо учесть следующие моменты:
-
Если метаданные, используемые в процессе, лежат в той же системе, то пара запрос/получение метаданных может быть заменена на одно чтение (1 CFP).
-
Если в рамках batch-процесса загружается несколько таблиц (object of interest), то начало и конец процесса имеет смысл учитывать только один раз, а не по каждой таблице.
Итоговая оценка всего проекта рассчитывается как сумма загрузок всех групп данных.
Расчет трудоемкости проекта рассчитывается по формуле:
Трудоемкость проекта (чел/дни) = Функциональный объем (CFP) / Продуктивность
где продуктивность – количество CFP, выполняемое сотрудником за один день.
Пример расчета функционального объема на основе проекта миграции с Oracle на Arenadata DB
За 6 месяцев, с октября 2022 г. по март 2023 г., наша компания осуществила миграцию с Oracle на Arenadata DB (коммерческая сборка GreenPlum, далее по тексту просто ADB) хранилища данных по веб-аналитике для крупной торговой компании. Более подробно о проекте и его результатах можно узнать из доклада «Как мы пришли к Arenadata DB».
Здесь же посчитаем функциональный объем проекта. Для начала декомпозируем весь проект на типы функциональных точек. Выделим основные типы:
-
Загрузка существующих входных данных из исходной системы интернет-магазина в ADB без изменений, с накоплением истории (схема таблиц src_hybris).
-
Загрузка общих справочников и таблиц фактов из хранилища Oracle в целевые таблицы, без изменений (схема kdw).
-
Предварительный расчет дополнительных атрибутов и показателей, необходимых для формирования целевых таблиц детального слоя, с сохранением результатов в стэйджинге (схема stg_hybris).
-
Загрузка данных интернет-магазина в целевые таблицы детального слоя данных (схема hybris).
-
Обогащение данных. Расчет дополнительных характеристик или формирование новых расчетных показателей.
-
Загрузка истории.
-
Тестирование – сверка данных в старом хранилище на Oracle c новым на ADB.
Тип 1. Загрузка из исходной системы интернет-магазина
Из исходной системы данные таблиц копируются без преобразований. Метаданные о типе загрузке (полная загрузка, дельта …) и результатах предыдущей загрузки хранятся в самой базе ArenadataDB.
Согласно методике расчета, описанной выше, общий функциональный объем:
-
Entry – старт загрузки по расписанию – 1 CFP;
-
Read – чтение метаданных для загрузки 59 таблиц – 59 CFP;
-
Read – чтение данных 59 таблиц внешних таблиц – 59 CFP;
-
Write – запись данных в 59 таблиц – 59 CFP;
-
Write – запись в подсистему метаданных результатов 59 загрузок – 59 CFP;
-
Exit – завершение группы загрузок – 1 CFP.
Итого – 238 CFP.
Тип 2. Загрузка общих справочников и фактов из старого хранилища
Аналогично загрузка готовых таблиц из хранилища Oracle осуществляется по событию. Триггером начала загрузки является завершение их формирования в источнике. Общее количество таблиц – 44, функциональный объем этой группы загрузок – 178 CFP.
Тип 3. Предварительный расчет дополнительных атрибутов и показателей
Группа загрузок предварительного расчета дополнительных атрибутов и показателей реализует дополнительную бизнес-логику. Триггером начала осуществления загрузок этого типа является завершение первых двух. Качественную оценку функционального объема таких загрузок можно провести только при наличии четкого понимания, какие данные необходимы для реализации требований, и в каких моментах будет осуществляться их чтение, преобразование и сохранение в таблицах. В проектах миграции эти требования фактически уже реализованы в старой системе и могут быть проанализированы по коду реализации или по имеющейся документации.
Для лучшего понимания приведу два примера:
1.Из исходной системы в хранилище приходит информация о кликах пользователя на сайте интернет-магазина. Она представляется парой строк URL – с какой страницы на какую был осуществлен переход, плюс дополнительные атрибуты: пользователь, компания, дата и время визита и т.д. Для анализа поведения пользователей на сайте и мониторинга эффективности маркетинговых акций URL строки необходимо распарсить (выделить домен, иерархию страниц сайта, get-параметры). Ниже приведен расчет функционального объема для такой процедуры парсинга:
| Тип движения | Комментарий | Функциональный объем |
|---|---|---|
| Entry | Запуск процедуры расчета | 1 CFP |
| Read | Получение параметров выборки данных из подсистемы метаданных | 1 CFP |
| Read | Чтение массива данных строк URL в Python-процедуру | 1 CFP |
| Write | Запись результатов парсинга в стэйджиговую таблицу схемы stg_hybris через формирование текстового файла и последующей его загрузки в Arenadata DB по протоколу GPFDIST. N.B. Руководство по оценке COSMIC говорит, что промежуточные структуры хранения не должны учитываться в оценке, поэтому запись в файл/ чтение из файла мы не учитываем в нашей оценке. | 1 CFP |
| Write | Запись результатов работы процедуры расчета в подсистему метаданных | 1 CFP |
| Exit | Завершение работы процедуры и журналирование результатов | 1 CFP |
| Итого: | 6 CFP |
2.Визиты на сайт интернет-магазина осуществляют не только реальные пользователи, но и роботы. Соответственно, встает задача пометить эти «механические» визиты. Компания использует разные алгоритмы для этой задачи. Самый простой из них – это определение по известным характеристикам (ip-адрес, наличие известной подстроки в строке URL и т.д.)
Ниже приведен расчет функционального объема для такой процедуры расчета:
| Тип движения | Комментарий | Функциональный объем |
|---|---|---|
| Entry | Запуск процедуры расчета | 1 CFP |
| Read | Получение параметров выборки данных из подсистемы метаданных | 1 CFP |
| Read | Чтение массива данных строк URL в процедуру pgPLSQL | 1 CFP |
| Read | Чтение характеристик известных роботов (Алгоритм определения 1) | 1 CFP |
| Read | Определение роботов по поведенческим характеристикам (Алгоритм определения 2) | 1 CFP |
| Write | Запись результатов определения роботов по алгоритму 1 и 2 в стэйджиговую таблицу схемы stg_hybris. | 1 CFP |
| Write | Запись результатов работы процедуры в подсистему метаданных | 1 CFP |
| Exit | Завершение работы процедуры и журналирование результатов | 1 CFP |
| Итого: | 8 CFP |
Типы 4, 5. Загрузка в таблицы детального слоя и обогащение данных
Загрузка данных в таблицы детального слоя и дальнейшее обогащение осуществляется аналогично либо простым загрузкам, либо чуть более сложным, как в предыдущем примере.
К простым относятся загрузки, где источником для целевой таблицы может быть:
-
существующая таблица;
-
запрос, который можно оформить как представление и фактически получить один источник данных.
В этом случае функциональный объем такой загрузки будет равен 6 CFP.
К более сложным относятся процедуры, в которых несколько источников данных и несколько целевых таблиц. Например, процедура кластеризации клиентов для разных типов пользователей. Для каждого типа кластеризация осуществляется отдельно, поэтому количество чтений определяется количеством типов пользователей. На выходе получаются две таблицы – параметры кластеров и соотнесение пользователей к этим кластерам.
Тип 6. Загрузка истории
Загрузка истории в целевые таблицы осуществляется один раз, практически в полуавтоматическом режиме. В связи с этим, в оценке функционального объема можно пренебречь затратами на чтение метаданных и журналирование. Для грубой оценки будем использовать пару чтение/запись для одной таблицы. Итоговая оценка будет равна количеству мигрируемых целевых таблиц, умноженному на 2.
Тип 7. Тестирование
Результаты миграции и работы регламентных процедур загрузки проверяются тестами загруженных данных в старую и новую системы (какое-то время обе системы работают параллельно).
Соответственно, каждый тест состоит из перемещений (3 CFP):
-
чтение из старой системы;
-
чтение из новой системы;
-
сравнение и запись результатов сравнения в постоянную область хранения.
Итоговый функциональный размер нашего проекта:
| Тип функциональности | Кол-во загрузок/тестов | Функциональный объем, CFP |
|---|---|---|
| Экстракция из исходной системы (интернет-магазин) | 59 | 236 |
| Копирование данных из хранилища Oracle | 44 | 176 |
| Предварительный расчет доп. атрибутов и показателей | 5 | 23 |
| Формирование детального слоя и обогащение данных | 80 | 359 |
| Еженедельные расчеты | 8 | 33 |
| Загрузка истории | 80 | 160 |
| Тестирование | 189 | 567 |
| Пары Entry/Exit (количество батчей)* | 3 | 6 |
| ИТОГО: | 468 | 1560 |
При определении общего объема количества входов/выходов в процессы было рассчитано по количеству батчей-загрузок, другими словами, количеству AirFlow DAGs.
Адаптация модели COSMIC за счет ETL-фреймворка и автоматизации тестирования
Одно из правил метода COSMIC гласит: если один и тот же функционал вызывается несколько раз с разными наборами данных в рамках одного функционального процесса, то его нужно учитывать только один раз, а не по количеству вызовов.
Для реализации проектов хранилищ данных на GreenPlum наша компания разработала ETL-фреймворк (Описание ETL-фреймворка: Переходим на Greenplum быстро, Исходные коды ETL-фреймворка), позволяющий сократить объем работ как раз за счет переиспользования функционала.
В состав ETL-фреймворка, помимо прочих, входят функции:
-
реализация типовых загрузок;
-
работа с подсистемой метаданных;
-
журналирование.
Под типовыми понимается перемещение данных со слоя на слой без значительных преобразований и специфической бизнес-логики, при условии, что данные перемещаются из одного источник в один приемник. В этом случае разработчику необходимо только создать целевую таблицу и, при необходимости, исходное представление, и внести соответствующие метаданные в ETL-фреймворк. Дальше поток загрузки будет сформирован автоматически.
Таким образом, для типовых загрузок мы можем оценить функциональный объем в 1 CFP, а из оценки нетиповых загрузок исключить чтение и запись в подсистему метаданных.
Дополнительно, написание небольшой Python-процедуры, которая считывает два SQL запроса - к старому и новому хранилищу данных, сверяет возвращаемые данные между собой и записывает результат тестирования в отдельную таблицу, позволило сократить функциональный объем за счет операции записи, т.е. сделать ее типовой для всех тестов.
Таким образом, за счет этих ноу-хау мы сократили функциональный объем больше, чем на 50 %:
| Тип функциональности | Тип загрузки | Кол-во загрузок/тестов | Функц. объем, CFP | Скорректированный функц. объем, CFP |
|---|---|---|---|---|
| Экстракция из исходной системы (интернет-магазин) | Типовая | 59 | 236 | 59 |
| Копирование данных из хранилища Oracle | Типовая | 42 | 168 | 42 |
| Не типовая | 2 | 8 | 4 | |
| Предварительный расчет доп. атрибутов и показателей | Не типовая | 5 | 23 | 13 |
| Формирование детального слоя и обогащение данных | Типовая | 53 | 212 | 53 |
| Не типовая | 27 | 147 | 93 | |
| Еженедельные расчеты | Типовая | 4 | 16 | 4 |
| Не типовая | 4 | 17 | 9 | |
| Загрузка истории | Типовая | 80 | 160 | 80 |
| Тестирование | 189 | 567 | 378 | |
| Пары Entry/Exit (количество батчей) | 3 | 6 | 6 | |
| ИТОГО: | 468 | 1560 | 741 |
Заключение
Любая модель оценки – это прежде всего макет, имеющий свои недостатки. Внимательный читатель справедливо заметит, что предлагаемая модель никак не учитывает сложность трансформаций или требования по производительности. Да и продуктивность сотрудников разной квалификации очень вариативна. Это, конечно, так. Например, проведенное специалистами Измирского технологического института исследование [4] проектов, реализованных разными командами, фактически привело к пониманию несравнимости прогнозируемых трудозатрат.
Вместе с тем, модель COSMIC дает стандартную методику, по которой можно оценить функциональный объем в абсолютных, а не качественных показателях объема проекта. В проектах миграции, когда все процедуры загрузки уже есть, и их надо переложить на новый технологический стэк, оценка может быть достаточно точной.
Если же функциональный объем дополнить статистикой выполнения проектов стабильной командой, то для нашей компании, оказывающей профессиональные услуги в области создания хранилищ данных, методика COSMIC позволяет с высокой степенью точности оценить предстоящие работы миграции. Это очевидная выгода и заказчику, и нам.