Выгрузчик ЕКХД Приложение 2 ТЗ 1809. Техническое задание по реализации модуля выгрузки данных в единое корпоративное хранилище данных (екхд) пао ростелеком
 Скачать 0.54 Mb.
|
|
Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 1 из 13 ТЕХНИЧЕСКОЕ ЗАДАНИЕ ПО РЕАЛИЗАЦИИ МОДУЛЯ ВЫГРУЗКИ ДАННЫХ В ЕДИНОЕ КОРПОРАТИВНОЕ ХРАНИЛИЩЕ ДАННЫХ (ЕКХД) ПАО «РОСТЕЛЕКОМ» Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 2 из 13 Содержание 1.1 Назначение документа ..................................................................................................................................... 3 1.2 Глоссарий ........................................................................................................................................................ 3 2 Назначение модуля .............................................................................................................................................. 4 3 Функциональные требования к модулю ......................................................................................................... 4 4 Требования к целевой архитектуре решения ................................................................................................. 7 4.1 Требования к платформе реализации ........................................................................................................ 7 4.2 Требования к системной архитектуре ........................................................................................................ 8 4.3 Требования к безопасности .......................................................................................................................... 8 5 Состав и содержание работ по созданию системы ......................................................................................... 9 6 Порядок контроля и приемки системы ........................................................................................................... 9 6.1 Виды и объем испытаний системы ............................................................................................................. 9 6.2 Требования к приемке работ по стадиям ................................................................................................ 10 7 Требования к документированию .................................................................................................................. 10 7.1 Требования к составу проектной документации ................................................................................... 11 7.2 Требования к составу эксплуатационной документации ..................................................................... 11 7.3 Требования к детализации документации .............................................................................................. 13 8 Требования к организации выгрузки ............................................................................................................ 13 Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 3 из 13 1.1 Назначение документа Назначением данного документа является предъявление требований к реализации модуля выгрузки данных из систем источников в ЕКХД. 1.2 Глоссарий Компания, Заказчик ПАО «Ростелеком» ЕКХД Единое корпоративное хранилище данных Пакет файлов Фиксированный набор консистентных данных. Содержат файлы с данными, а же контрольную информацию и информацию для аудита. КЦ Корпоративный Центр МРФ Макрорегиональный филиал SVN Сервер средства контроля версий Subversion Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 4 из 13 2 Назначение модуля Модуль предназначен для организации процесса выгрузки данных источников ЕКХД в структуры пакетов файлов согласованных форматов. В функции модуля выгрузки входит: управляемая метаданными выгрузка данных систем-источников Заказчика; формирование файловых пакетов данных, в соответствии с требованиями и согласованной спецификацией на выгрузку; размещение подготовленных пакетов производится на специализированном файловом ресурсе МРФ; проверка качества выгружаемых данных, на уровне соответствия структур СУБД форматам, специфицированным к выгрузке. Модуль является универсальным, и выполняет свои функции для всех СУБД источников, поддерживающих jdbc интерфейс и совместимых со стандартом SQL:2003. Спецификация форматов файлов и требования к выгрузке специфицируются для каждого источника. Файловый ресурс представляет собой полностью пассивный компонент, т. е. соединение с файловым сервером всегда происходит по инициативе модуля выгрузки. Файловый ресурс доступен по протоколам NFS или CIFS. 3 Функциональные требования к модулю Модуль выполняет следующие функции: EDWEX001. Транзакционная выгрузка консистентного пакета данных. Файлы данных сохраняются в сжатом виде. Формирует тикет с сохранением контрольных MD5-ключей для всех файлов архивов и защитой данных тикет-файла цифровой подписью. EDWEX002. Транзакционная выгрузка статистического пакета сверочных отчѐтов, в соответствии с требованиями настоящей спецификации. Требования к формированию пакета аналогично EDWEX001. EDWEX003. Проверка полноты и неизменности структур источника. Проверка осуществляется полным сравнением структур Источника с настройками управляющих метаданных Модуля выгрузки. EDWEX004. Проверка актуальности и неизменности настроечных метаданных. Проверка осуществляется путѐм сравнения файлов управляющих метаданных Модуля выгрузки с актуальной продуктивной копией на сервере контроля версий (SVN). EDWEX005. Логирование работы в файл и syslogd сервис, уведомление об исключениях (email) Выгрузка управляется централизованно ETL инструментом, развѐрнутым в КЦ, при этом запуск модуля осуществляется через ssh-туннель на стороне источника. Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 5 из 13 tab1 Метаданные СУБД Модуль выгрузки данных EDW_EXTRACTOR Метаданные EDW_EXTRACTOR Файл параметров Файл параметров Модуль СККД filen filen file2 file2 file1 file1 tab3 tab2 view Источник Область выгрузки данных Файлы аудита выгрузки Файлы аудита выгрузки Пакет Администратор МРФ Администратор МРФ ssh, 22 Модуль выгрузки данных EDW_EXTRACTOR ETL ETL КЦ SVN SVN 80 порт ssh-туннель, 22 Рисунок 1. Архитектура модуля выгрузки Работа модуля управляется следующими параметрами запуска: Таблица 1. Параметры запуска модуля выгрузки Параметр Формат, возможные значения Значение по умолчанию Описание srctp number(3) - Код типа системы-источника (обязательный параметр) srcno number(6) - Код экземпляра системы-источника (обязательный параметр) specver number(6) - Номер версии спецификации на выгрузку данных источника (обязательный параметр) dbcs jdbc строка соединения - Строка соединения с СУБД Источника dbuser строка - Имя пользователя СУБД Источника dbpass строка - Пароль пользователя СУБД Источника svncs http строка соединения - Строка соединения с репозиторием метаданных (SVN) svnuser строка - Имя пользователя SVN svnpass строка - Пароль пользователя SVN fromdt YYYYMMDDHHMISS 00:00 30 дней назад от $actualdt Операционная глубина выгрузки (ограничение периода датой, начиная с которой выгружаются факты), по умолчанию T-1 actualdt YYYYMMDDHHMISS время старта выгрузки Время актуальности данных encoding UTF-8 UTF-8 Кодировка текста файла данных depers 0 – не обезличенная, 1 – обезличенная 1 Требуется ли обезличивание при выгрузке данных maxthreads number(3) 10 Максимальное количество параллельных потоков выгрузки данных (чем меньше, тем ниже нагрузка на сервер) Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 6 из 13 Параметры запуска модуля могут использоваться в его метаданных в качестве макроопределений, для этого к имени параметра добавляется символ $, например $srcno. Так же, в вычислимых выражениях настроек метаданных выгрузки ( Таблица 3 , Таблица 4 ) могут использоваться динамические макроопределения: Таблица 2. Динамические макроопределения Параметр Наименование Возможные значения Описание currentdt выгружаемая дата DATE Применяется для выгрузки партиционированных по дате таблиц filepnum номер файла NUMBER(4) Номер партиции партиционированного файла Выгрузка управляется метаданными, которые представляют собой текстовые, разделѐнные табуляцией csv файлы. Эти файлы загружаются из репозитория SVN, расположенного по адресу $svncs. Настройки, определяющие структуру пакета: Таблица 3. Метаданные модуля выгрузки. Структура пакета $srctp_$specver_pack.edwex Параметр Наименование Возможные значения Описание fileno тип файла number(4) Код типа файла filenm имя файла строка Имя файла schnm имя схемы БД строка Имя схемы БД (может быть пусто) tblnm имя таблицы БД строка Имя таблицы или представления tblpartdt имя атрибута бизнес-даты пусто строка Таблица не партиционирована Имя атрибута бизнес-даты, по которой ведѐтся партиционирование выгрузки tblfltr срока фильтрации SQL выражение Строка фильтрации данных; содержит часть SQL инструкции, применимой в опции WHERE Настройки, определяющие структуры файлов данных: Таблица 4. Метаданные модуля выгрузки. Структура файлов $srctp_$specver_data.edwex Параметр Наименование Возможные значения Описание fileno тип файла number(4) Код типа файла attrno номер атрибута в списке number(4) Номер атрибута в отсортированном по возрастанию списке; формирование строки данных при выгрузке осуществляется в порядке номеров $attrno attrnm имя атрибута таблицы строка Код экземпляра системы-источника (обязательный параметр) attrtp тип атрибута NUMBER VARCHAR CHAR CLOB DATE TIMESTAMP Атрибут CLOB выгружается в формате varchar(4000), при этом символы c кодом < 32 транслируются в пробелы. Атрибуты DATE сохраняются в формате YYYYMMDD. Атрибуты TIMESTAMP сохраняются в формате YYYYMMDD HH24MISS.FF6. attrln размер атрибута пусто number(3) для NUMBER, VARCHAR, CHAR attrprc точность атрибута пусто number(3) для NUMBER attrdepers алгоритм обезличивания пусто BLANK MD5 SQL выражение никаких действий не производится данные не выгружаются шифрование MD5 выполняется вычислимое выражение Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 7 из 13 Параметры метаданных модуля могут использоваться в его метаданных в качестве макроопределений, для этого к имени параметра добавляется символ $, например $fileno. Деперсонализация (выполнение настроек $attrdepers) производится при запуске модуля в с параметром $depers=1. Партиционирование выгрузки осуществляется, если для таблицы заполнен атрибут $tblpartdt, при этом выгрузка таблицы осуществляется параллельно, для каждого дня в промежутке между $fromdt и $actualdt создаѐтся отдельный файл, имеющий номер $filepnum, равный разнице в днях между $actualdt и выгружаемой в данной партиции датой $currentdt. Утилита фиксирует время старта транзакции СУБД ($actualdt) и осуществляет последовательную выгрузку файлов в порядке их упоминания в «структуре файлов» ($srctp_$specver_data.edwex). Для каждого файла формируется SQL инструкция SELECT в порядке следования атрибутов в «структуре файлов» ($srctp_$specver_data.edwex). При этом, для транзакционных фактов, выгрузка которых должна быть ограничена оперативной глубиной $fromdt, необходимо указание настройки $tblfltr, например: Таблица 5. Пример структуры пакета fileno filenm schnm tblnm tblpartdt tblfltr 1 $srctp_$specver_$srcno_$fromdt_$actualdt_$fileno_$filepnum_fct_table.csv FCT FCT_TABLE tran_date tran_type = 1 2 $srctp_$specver_$srcno_$fromdt_$actualdt_$fileno_$filepnum_dim_table.csv DIM DIM_TABLE Таблица 6. Пример структуры файлов fileno attrno attrnm attrtp attrln attrprc attrdepers 1 1 fct_id NUMBER 1 2 business_date DATE 1 3 client_id NUMBER 1 4 amt NUMBER 32 6 2 1 client_id NUMBER 2 2 inn VARCHAR 200 MD5 2 2 fio VARCHAR 200 BLANK 2 3 birthday DATE to_date(to_char(birthday, ‘YYYYMM’)||’01’, ‘YYYYMMDD’) 4 Требования к целевой архитектуре решения Модуль должен обеспечивать эффективную и производительную работу для всех СУБД источников ЕКХД. 4.1 Требования к платформе реализации Модуль выгрузки представляет собой платформонезависимое приложение – консольную утилиту, реализованную на Java. Для его корректной работы необходима установка следующих пререквизитов: JRE 7 JDBC драйвер СУБД Источника Для источников Oracle рекомендуется использование OCI драйвера (толстый клиент). Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 8 из 13 Модуль выгрузки должен быть совместим и обладать полной функциональностью на следующих ОС: - Unix/Linux - MS Windows Модуль выгрузки должен быть совместим и обладать полной функциональностью выгрузки из БД: - Oracle - MS SQL - Cache 4.2 Требования к системной архитектуре Производительную работу модуля обеспечивает его разворачивание непосредственно на SMP сервере СУБД источника, либо с доступом к вычислительному узлу через interconnect MPP сервера (соединение 10Gb или выше). Доступ к файловому хранилищу (области выгрузки данных) должен осуществляться по каналу не ниже 1Gb, с фактической пропускной способностью от 50МБ/c. Файловое хранилище должно обеспечить ту же скорость последовательной записи данных. Для централизованного управления утилитой необходимо организовать ssh-туннель из КЦ; пользователь ОС должен иметь необходимые привилегии (см.4.3). Для обеспечения возможности автоматического обновления метаданных из централизованного хранилища, необходим HTTP доступ к SVN серверу хранения артефактов ЕКХД. 4.3 Требования к безопасности Взаимодействие КЦ с утилитой осуществляется через SSH-туннель, настроенный поверх шифрованного VPN соединения между ETL сервером ЕКХД и сервером СУБД МРФ. При этом, для доступа к ресурсам сервера СУБД реализуется отдельный профиль пользователя с ограниченными привилегиями: запуска утилиты выгрузки; обновления метаданных утилиты выгрузки; доступа к драйверам СУБД; необходимой квоты на сохранение данных в файловом хранилище. Параметры соединения с сервером СУБД источника, в том числе логин и пароль, передаются в утилиту в виде параметров еѐ запуска, при этом данные параметры не сохраняются на диск. Параметры соединения с сервером SVN, в том числе логин и пароль, передаются в утилиту в виде параметров еѐ запуска, при этом данные параметры не сохраняются на диск. Порядок реализации алгоритмов обезличивания данных и подписания файла-тикета ЭЦП осуществляется по согласованию со Службой безопасности Заказчика. При этом возможно выполнение дополнительных требований по использованию сертифицированных Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 9 из 13 криптостойких алгоритмов и специальных программных средств, определѐнных Службой безопасности Заказчика. 5 Состав и содержание работ Состав работ по проекту должен включать в себя: 1. Определение проекта 2. Анализ требований к Системе 3. Проектирование Системы 4. Разработку Системы 5. Тестирование Системы 6. Опытная эксплуатация Системы 7. Переход в промышленную эксплуатацию Системы 8. Гарантийное сопровождение Системы Детальный поэтапный план реализации системы и сроки выполнения стадий и этапов разработки и создания Системы определяются Планом выполнения работ, подготавливаемым Претендентом, и утверждаемым Заказчиком. Тестирование проводится в течение не более 5-ти рабочих дней с момента переноса функциональности на серверы UAT-тестирования и служит для прохождения тестов приемочных испытаний. Тестирование системы производится согласно тестовым сценариям, согласованным на этапе формирования требований к системе. Опытная эксплуатация Системы проводится в течение не более 30-ти рабочих дней с момента переноса на определяемые Заказчиком системы-Источники по их типам согласно п.4.1. Дефекты системы, обнаруженные по истечении периода приемочного тестирования, исправляются в ходе гарантийного периода и не должны препятствовать подписанию Акта сдачи-приемки работ. Гарантийный период составляет 12 календарных месяцев с даты подписания Сторонами Акта сдачи-приемки Услуг. Исполнитель обязуется без дополнительной оплаты внести в систему исправления по всем дефектам, выявленным в течение гарантийного периода. Исправление дефектов, обнаруженных по истечении гарантийного периода, производится в рамках работ по технической поддержке системы и является предметом отдельного договора. 6 Порядок контроля и приемки системы 6.1 Виды и объем испытаний системы Система на каждой из систем-источников подвергается испытаниям следующих видов: 1. Опытная эксплуатация; 2. Приемочные испытания. Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии проектирования. Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 10 из 13 Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Опытная эксплуатация» с учетом результатов проведения предварительных испытаний и опытной эксплуатации. 6.2 Требования к приемке работ по стадиям Требования к приемке работ по стадиям приведены в таблице. Стадия испытаний Участники испытаний Место проведения Порядок согласования документации Статус приемочной комиссии Опытная эксплуатация Организации Заказчика и Разработчика На территории Заказчика Проведение опытной эксплуатации. Фиксирование выявленных неполадок в Протоколе испытаний. Устранение выявленных неполадок. Проверка устранения выявленных неполадок. Принятие решения о готовности Системы к приемочным испытаниям. Составление и подписание Акта о завершении опытной эксплуатации Системы. Группа тестирования Приемочные испытания Организации Заказчика и Разработчика На территории Заказчика Проведение приемочных испытаний. Фиксирование выявленных неполадок в Протоколе испытаний. Устранение выявленных неполадок. Проверка устранения выявленных неполадок. Принятие решения о возможности передачи Системы в промышленную эксплуатацию. Составление и подписание Акта о завершении приемочных испытаний и передаче Системы в промышленную эксплуатацию. Оформление Акта завершения работ. Приемочная комиссия 7 Требования к документированию Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 11 из 13 Документирование разработанной Cистемы необходимо для ее успешной реализации, ввода в действие и эксплуатации. В соответствии с принятыми мировыми и российскими стандартами качества должна оформляться проектная и сопроводительная документация. Документация должна иметь детализацию, достаточную для использования и поддержки Системы. 7.1 Требования к составу проектной документации Перечень разрабатываемой и представляемой проектной документации включает: 1. Описание системы; 2. План-график работ по проекту; 3. Уточненное ТЗ на разработку Системы; 4. Технорабочий проект; 5. Программа и методика испытаний; Необходимость доработки прочих проектных документов, в том числе методологических, согласовывается при утверждении соответствующих функциональных требований. 7.2 Требования к составу эксплуатационной документации Минимальный перечень эксплуатационной документации приведен ниже: Общее описание системы 1. назначение системы a. вид деятельности, для автоматизации которой предназначена система; b. перечень объектов автоматизации, на которых используется система; c. перечень функций, реализуемых системой. 2. описание системы a. Общая конфигурация системы b. Описание системы и ее частей c. Описание функционирования системы 3. описание взаимосвязей АС с другими системами a. Перечень интегрированных систем b. Принципы построения интеграции Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 12 из 13 Описание комплекса технических средств 1. Общие положения a. Исходные данные, использованные при проектировании технического обеспечения 2. Структура комплекса технических средств a. Обоснование структуры КТС b. Размещение КТС на площадках 3. Средства вычислительной техники a. Спецификация комплекса технических средств b. Требования к организации рабочих мест 4. Аппаратура передачи данных a. Общая схема сети для основной и резервной площадок b. Требования к каналам связи 5. Обеспечение отказо- и катастрофоустойчивости 6. Конфигурация программного обеспечения АС a. Перечень сред и их размещение в КТС b. Конфигурация промышленной среды i. Основная площадка 1. СХД 2. Уровень СУБД 3. Уровень серверов приложений 4. Уровень интеграционной шины ii. Резервная площадка 1. СХД 2. Уровень СУБД 3. Уровень серверов приложений 4. Уровень интеграционной шины iii. Уровень терминальных серверов iv. Балансировка нагрузки c. Конфигурация тестовых d. Конфигурация среды обучения e. Конфигурация среды разработки f. Конфигурация сред разработки и тестирования миграции данных g. Конфигурация инструментов конфигурационного управления Схема структурная комплекса технических средств (обновляется по мере масштабирования системы) 1. Диаграмма размещения компонентов системы и каналов коммуникации между ними 2. Реестр серверов системы 3. Реестр точек интеграции с внешними системами Интеграционная архитектура и описание структуры БД Схемы данных основных сущностей и их взаимосвязей, описание интеграционных интерфейсов Регламент промышленной и опытной эксплуатации 1. Регламент взаимодействия подразделений; 2. Регламент резервного копирования и восстановления; 3. Регламент планового обслуживания ИС 4. Регламент действия при сбоях; 5. Регламент эксплуатации ИС Приложение 2 ТЕХНИЧЕСКОЕ ЗАДАНИЕ стр. 13 из 13 7.3 Требования к детализации документации Документация по выполненным работам должна быть выполнена как в виде комментариев в коде, так и в составе проектной документации в MS Word. Порядок документации и степень регламентации работ должен соответствовать следующим критериям: Достаточность, полнота описания системы в целом; Модульный подход к документации по каждой области; Стандартизированный подход к описании каждой области и элемента; Детальное описание каждого элемента; Детальное описание всех механизмов; Контрольные мероприятия (тестирование, проверка выгрузок и пр.) должны отражаться в документации по проекту; Шаблоны эксплуатационной документации будут переданы Исполнителю на этапе подготовки этой документации, однако в процессе их заполнения возможны корректировки и изменения данных шаблонов по согласованию с Заказчиком. 8 Требования к организации выгрузки Окно доступности источника определяется индивидуально, согласно регламенту выгрузки. Настройка времени выгрузки осуществляется централизованно, средствами ETL платформы, развѐрнутой в КЦ. Пользователь выгрузки должен иметь достаточную квоту для сохранения в области выгрузки объѐмов данных за 1 год. Для отработки инцидентов возможен нештатный ручной запуск утилиты администратором МРФ. В этом случае, параметры вызова утилиты формируются вручную, в соответствии с рекомендациями Руководства администратора. |