Высшее образование. Опыт работы в роли прикладного и/или системного архитектора в ИТ проектах от 3х лет. Опыт участия в проектировании хранилища данных (SAS или Oracle). Знание технологии ETL. Работа с одним из продуктов класса ETL IBM DataStage Oracle DI, SAS. Знание банковских продуктов и технологий желательно. Английский язык - технический.
Читать дальше »
Для проекта по построению хранилища данных в крупном российском банке требуется Архитектор хранилища данных/Технический лидер.
Архитектор хранилища данных:
The Deutsche Bank Finance-IT department is responsible for the design, implementation and support of middle- and back-office systems with in Finance Group Risk Control in Frankfurt and in the regions. dbArtos is the central Credit Risk data management, calculation and reporting system that provides all Deutsche Bank Credit Risk reports for internal management and external/regulatory purpose. This has become more and more important given the current market conditions. The system is based on an Oracle data management layer, SAS calculation and a Java client weblogic J2EE / Microstrategy reporting layer. A significant portion of the development is performed by a Moscow based vendor.
Читать дальше »
В предыдущей статье были рассмотрены аппаратные и программные способы повышения производительности хранилищ данных (DWH). Сегодня рассмотрим архитектурные способы, проектирование и администрирование.
Правильная архитектура имеет ключевое значение для производительности и пропускной способности всей системы в целом. Элементами архитектуры являются все системы, вовлечённые в наполнение и использование хранилища данных, начиная от систем-источников (source system), и заканчивая отдельными витринами данных (data mart) и аналитическими приложениями (analytical application). При правильно построенной архитектуре данные максимально быстро попадают из систем, в которых они создаются, к конечным пользователям. При этом инфраструктура хранилища данных (оборудование, программное обеспечение) используется наиболее оптмальным образом (отсутствуют пики и простои). Оптимизация хранилища данных с точки зрения архитектуры может включать перенос нагрузки из узких мест в более производительные и/или недозагруженные. Например, перенос части нагрузки с ETL-серверов на СУБД хранилища данных (ELT). Или, наоборот, разгрузка СУБД хранилища данных за счёт переноса нагрузки с СУБД на серверы OLAP.
Читать дальше »
Автор: Андрей Пивоваров
Дата публикации оригинала: 2008-12-17
Источник: Блог Андрея Пивоварова
Продолжение. Начало здесь.
LOCKDFN
Интересная особенность большинства объектов, которые вы создаете в AWM. Например, возьмем описание измерения PRODUCT:
>dsc product
DEFINE PRODUCT DIMENSION READONLY LOCKDFN TEXT
Можно увидеть слова LOCKDFN и READONLY.
Это значит, что теперь объекты, созданные в AWM нельзя менять при помощи DML. Ни структуру, ни содержимое. Использовать на чтение можно, менять нельзя. Более того, нельзя даже добавить новое значение эелемента измерения при помощи команды MAINTAIN.
Читать дальше »
Автор: Андрей Пивоваров
Дата публикации оригинала: 2008-12-16
Источник: Блог Андрея Пивоварова
Когда Дмитрий Волков предложил мне выступить на семинаре Database Options Details с рассказом про OLAP опцию в 11g, я сначала подумал – да о чем тут рассказывать? Между девятой и десятой версией было много различий. А между 10 и 11 вроде ничего особо не было. Ну, кроме Cube-Organized Materialized Views. Потом решил, что на семинаре будет масса людей, которые вообще с OLAP не работали, ни с какой версией, поэтому им, возможно, будет интересно узнать об OLAP вообще. Заодно при подготовке и посмотрю внимательнее, что там изменилось. Но оказалось, что изменений неожиданно много.
Читать дальше »
Автор: Константин Лисянский
В предыдущей статье были рассмотрены административные и два аппаратных способа повышения производительности хранилища данных. Сегодня рассмотрим другие способы.
Балансировка системы. Строго говоря, нельзя сказать, что это только аппаратный способ. И этот способ сильно перекликается с предыдущим (добавлением “железа”). Просто здесь хочется сделать упор на то, что добавлять нужно именно того, что требуется, чтобы сделать систему сбалансированной путём расширения узкого места. Ну, например, в случае, если высобираете массивно-параллельную систему (MPP) сами, то может получиться, что проблема с производительностью может возникать из-за того, что не хватает пропускной способности сети, и решить её можно добавлением дополнительных сетевых карт в узлы системы. Ещё одним примером может стать перераспределение дисков между пространством пользовательских данных, пространством для индексов и пространством для временного хранения промежуточных результатов запросов.
Читать дальше »
Автор: Richard Skriletz
Дата публикации оригинала: 2007-06-26
Перевод: Олег Кузьменко
Источник: Сайт BeyeNETWORK
Продолжение. Начало в части 1.
То, как будут реализованы основные данные (master data), окажет существенное влияние как на операционные процессы, так и на информационные технологии (ИТ). Каким образом будут созданы основные данные? Как они будут сосуществовать с существующими и будущими приложениями? Какое влияние это окажет на принятие решений по поводу прикладных систем и их функциональных возможностей? Эти вопросы затрагивают не одно подразделение, и ими надо заняться для достижения бизнесом успеха. Существует ряд важных факторов, относящихся к ИТ, которые жизненно важны для успеха решения по основным данным:
Опубликовано 10.03.2009 | Автор сообщения Олег Кузьменко | Категории: MDM, RDM, Skriletz, Richard, Архитектор данных, Бизнес-аналитик, Бизнес-спонсор, Для начинающих, Для продвинутых, Для экспертов, На русском, Руководитель подразделения BI/DWH, Стюард данных, Технический архитекторАвтор: Richard Skriletz
Дата публикации оригинала: 2007-06-26
Перевод: Олег Кузьменко
Источник: Сайт BeyeNETWORK
В моих двух предыдущих статьях (здесь и здесь) я рассказал, почему основные (master data) и справочные (reference data) данные являются, в первую очередь, предметом заботы бизнес-подразделений, и о том, как службы ИТ вносят свой вклад в появление проблем с основными данными. Теперь рассмотрим то, как же все-таки добиться успеха в управлении основными данными (MDM).
Достижение успеха в управлении основными данными — дело непростое. Вопрос основных данных носит стратегический характер, и в настоящее время основные данные находятся в центре важнейших инициатив на многих предприятиях. Ставит ли ваша компания своей приоритетной задачей ориентацию на клиента, на продукты или на достижение совершенства в ведении бизнеса (operational excellence) - основные данные являются основным ингредиентом успеха, и степень успеха будет зависеть от того, как ваша компания управляет основными данными и как справляется со своими обязанностями, вытекающими из этого.
Поскольку основные данные являются, в первую очередь, предметом заботы всего бизнеса, ими надо заниматься на уровне всего предприятия, а не уровне отдельных направлений бизнеса. Например, для основных данных по клиентам — кто отвечает за удовлетворение запросов клиентов, и какие данные нужны этим сотрудникам? Для основных данных по продуктам — кто решает, какие продукты и услуги предлагаются компанией, и кто отвечает за обеспечение того, что ценообразование происходит единым образом для всех каналов продаж? Эти вопросы являются типичными. Ответы на них нельзя найти внутри только одного подразделения, и их получение необходимо для успешного достижения целей бизнеса.
Опубликовано 10.03.2009 | Автор сообщения Олег Кузьменко | Категории: MDM, RDM, Skriletz, Richard, Архитектор данных, Бизнес-аналитик, Бизнес-спонсор, Для начинающих, Для продвинутых, Для экспертов, На русском, Руководитель подразделения BI/DWH, Стюард данных, Технический архитектор
Новое издание классического бестселлера, который послужил началом отрасли хранилищ данных.
Книга описывает новые подходы и технологии, во многих из которых пионером выступил сам Билл Инмон (Inmon). В дополнение к объяснению основ хранилищ данных (DWH), книга овещает новые темы, такие как методы обработки неструктурированных данных (unstructured data) и хранение данных в хранилище данных на нескольких типах носителей (multi-temperature data warehousing).
Книга обсуждает достоинства и недостатки реляционного и многомерного подходов к проектированию, а также то, как измерять возврат на инвестиции (ROI) при планировании проектов по построению хранилищ данных.
Читать дальше »
Loading ...