Обязательно:
Желательно:
Высшее образование. Опыт работы в роли прикладного и/или системного архитектора в ИТ проектах от 3х лет. Опыт участия в проектировании хранилища данных (SAS или Oracle). Знание технологии ETL. Работа с одним из продуктов класса ETL IBM DataStage Oracle DI, SAS. Знание банковских продуктов и технологий желательно. Английский язык - технический.
Читать дальше »
Для проекта доработки хранилища данных и построения отчетности в крупной западной компаниии требуется разработчик/консультант DWH/BI
Обязанности:
Для проекта по построению хранилища данных в крупном российском банке требуется Архитектор данных/ Разработчик моделей данных
Архитектор данных:
Для проекта по построению хранилища данных в крупном российском банке требуется Архитектор хранилища данных/Технический лидер.
Архитектор хранилища данных:
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.
Читать дальше »
Книга известного популяризатора технологий хранилищ данных Ральфа Кимбала рассказывает о том, как построить систему ETL для хранилища данных, построенного на основе многомерной модели данных. В книге рассматриваются все аспекты, связанные с ETL, включая планирование, архитектуру, структуры и потоки данных, очистку данных и мониторинг качества данных, процессы разработки и оптимизации, поддержку ETL в режиме производственной эксплуатации, управление метаданными, зоны ответственности и процессы, извлечение и загрузку данных в режиме реального времени.
Читать дальше »
Автор: Константин Лисянский
В предыдущей статье были рассмотрены административные и два аппаратных способа повышения производительности хранилища данных. Сегодня рассмотрим другие способы.
Балансировка системы. Строго говоря, нельзя сказать, что это только аппаратный способ. И этот способ сильно перекликается с предыдущим (добавлением “железа”). Просто здесь хочется сделать упор на то, что добавлять нужно именно того, что требуется, чтобы сделать систему сбалансированной путём расширения узкого места. Ну, например, в случае, если высобираете массивно-параллельную систему (MPP) сами, то может получиться, что проблема с производительностью может возникать из-за того, что не хватает пропускной способности сети, и решить её можно добавлением дополнительных сетевых карт в узлы системы. Ещё одним примером может стать перераспределение дисков между пространством пользовательских данных, пространством для индексов и пространством для временного хранения промежуточных результатов запросов.
Читать дальше »
Автор: Константин Лисянский
Рано или поздно все разработчики хранилищ данных (DWH) сталкиваются с проблемой производительности хранилища данных. В этой статье мне хочется вспомнить возможные способы повышения производительности подсистем хранилища данных и всего хранилища в целом.
Готовых советов о том, что делать, в этой статье не будет, я просто попытался вспомнить обо всех известных мне способах. Замечу также, что речь пойдёт и о способах ускорения, изначально заложенных в соответствующие программные продукты. Таким образом, я уделю немного внимания “встроенным” в разные СУБД средствам ускорения.
Для начала (поскольку способов вспомнилось, как ни странно, довольно много) хотелось бы предложить некоторую классификацию этих способов, а также перечислить те места, в которых можно ускорять.
Читать дальше »
Loading ...
