Сегодня хочу начать публикацию перевода некоторых частей документа Oracle Data Integrator Best Practices for a Data Warehouse. Я выбрал около восьми отрывков из этого документа, и, хотя документ и нацелен на новую версию ODI, я думаю, полезен он будет многим.
Так как ODI хранит все данные в централизованном хранилище, состоящем из нескольких репозиториев, необходимо иметь возможность разделять права для разных категорий пользователей. Ниже в таблице приведен пример такого разделения.
| Роль | Описание | Модули ODI |
|---|---|---|
| Бизнес пользователь | Бизнес пользователи имеют доступ к результирующим данным ХД посредством отчетов или через выполнение прямых запросов к ХД. В некоторых случаях, им необходимо понимания того, что означают показатели, как именно они рассчитываются и с какой периодичностью данные обновляются. Также они должны быть осведомлены о любых проблемах с качеством данных. | ODI Console |
| Бизнес аналитик | Бизнес аналитики определяют перечень ключевых данных. Они знают источники данных и разрабатывают бизнес правила для преобразования данных из систем источников в приемники данных. Они ответственны за поддержку правил преобразования семантики данных источников в единообразное представление ХД. | Designer Navigator (ограниченный доступ), ODI Console |
| Разработчик | Разработчики отвечают за реализацию бизнес правил преобразования данных, которые предоставляются бизнес аналитиками. Результаты работы в виде сценариев передаются на промышленный сервер команде технологов. Разработчики должны знать как технические аспекты используемых источников и приемников данных, так и понимать бизнес процессы, в которых задействованы данные. | Topology Navigator (только чтение), Designer Navigator (ограниченный доступ к моделям, полный доступ к проекту), Operator Navigator, ODI Console |
| Администратор метаданных | Администратор метаданных ответственнен за реверс-инжиниринг источников и приемников данных. Именно он гарантирует непротиворечивость метаданных в репозитории ODI. Имеет глубокие знания структур данных систем источников и приемников данных, а также участвует в моделировании целевых данных ХД. В сотрудничестве с бизнес аналитиками, улучшает качество метаданных, добавляя к моделям комментарии, описания, и, при необходимости, правила целостности, такие как констрейнты. Администратор метаданных ответственнен, также, за контроль версий. | Topology Navigator (ограниченный доступ), Designer Navigator (полный доступ к моделям, доступ на восстановление к проектам), ODI Console |
| Администратор БД | Отвечает за настройку инфраструктуры баз данных в ODI. Настраивает профили БД для того, чтобы ODI получил доступ к данным. Создает схемы и базы данных для области стейджа. Определяя и настраивая объекты в топологии, формирует различные среды выполнения ETL процедур (разработка, тестирование и т.п.) | Topology Navigator (полный доступ), Designer Navigator (полный доступ), Operator Navigator (полный доступ), ODI Console |
| Системный администратор | Системный администратор отвечает за поддержку технических средств и инфрастуктуры проекта. Ему свойственно выполнение таких, например, задач, как:
| Agents, Topology Navigator (ограниченный доступ), ODI Console |
| Администратор безопасности | Администратор безопасности в ответе за создание или удаление пользователей ODI, а также за выдачу прав на объекты репозитория ODI этим пользователям. | Security Navigator (полный доступ), Designer Navigator (чтение), Topology Navigator (чтение), ODI Console |
| Технолог | Технологи ответственны за импортирование завершенных и протестированных сценариев в промышленную эксплуатацию. Они запускают эти сценарии сами или устанавливают для этого расписание. Отслеживают выполнение сценариев, и, при необходимости, перезапускают их. | Operator Navigator, ODI Console, Oracle Enterprise Manager Plug-in For ODI |
Мастер репозиторий ODI содержит стандартные встроенные профили прав доступа, которые могут быть назначены пользователям. Следующая таблица показывает пример назначения профилей для разных пользовательских ролей.
| Роль | Стандартный профиль |
|---|---|
| Бизнес пользователь | CONNECT, NG REPOSITORY EXPLORER |
| Бизнес аналитик | CONNECT, NG REPOSITORY EXPLORER, NG DESIGNER |
| Разработчик | CONNECT, DESIGNER |
| Администратор метаданных | CONNECT, METDATA ADMIN, VERSION ADMIN |
| Администратор БД | CONNECT, DESIGNER, METADATA ADMIN, TOPOLOGY ADMIN |
| Системный администратор | CONNECT, OPERATOR |
| Администратор безопасности | CONNECT, SECURITY ADMIN |
| Технолог | CONNECT, OPERATOR |
Хочу отметить отсутствие роли тестировщика в приведенном перечне типичных ролей на проекте. Возможно, считается что тестировать данные должен либо бизнес-аналитик, либо бизнес-пользователь. Но мой опыт показывает, что тестирование ETL процессов все же может иметь место, и оно совсем не лишнее.
Процесс разработки и внедрения серьъезных ХД занимает достаточно долгое время. За это время формируется список решенных проблем с данными, отталкиваясь от которого вполне вероятно получить список причин, которые приводят или потенциально могут привести к появлению ошибок. Именно по перечню причин (реальных или потенциальных) ошибок можно создать набор проверок для тестирования по методу белого ящика, когда тестировщик проверяет реализацию разработанного ETL.
Второй момент, о котором бы хотелось сказать, это наличие всех перечисленных выше ролей у участников проекта. Не всегда одна роль отдается одному сотруднику, возможен вариант, когда один сотрудник выполняет обязанности нескольких ролей. И тогда, в момент передачи ХД и ETL, его заполняющего, в промышленную эксплуатацию, возникает задача по разделению прав между разработчиками и теми, кто будет поддерживать загрузку.
На мой взгляд, чем раньше произойдет такое разделение на разработку и поддержку, а с ним и ограничение прав команды разработки на пром сервер, тем лучше будет для качества всего хранилища данных, так как у команды разработки будет стимул разрабатывать и тестировать ETL более качественно.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.