+7(499)495-49-41

Опыт внедрения Хранилища данных

Содержание

Основные факторы риска при создании хранилищ данных

Опыт внедрения Хранилища данных

Submitted by admin on Mon, 12/29/2008 – 15:55

Translated by: 

Бралгин Игорь

В этой статье приведены ответы ведущих специалистов в области хранилищ данных на вопросы: «Каковы основные факторы риска в проектах внедрения хранилища данных?» и «Есть ли у вас какие-либо результаты исследования этих факторов риска?».

Отвечают: Сид Аделман (Sid Adelman), Лес Барбусински (Les Barbusinski), Чак Келли (Chuck Kelley), Джо Оатес (Joe Oates), Клей Рем (Clay Rehm).

Отвечает Сид Адельман (Sid Adelman)

Основные факторы риска:

  • Нереалистичные ожидания пользователей;
  • Отсутствие руководства (No management commitment);
  • Нереалистичные графики;
  • Слишком малый бюджет;
  • Неподготовленность персонала;
  • Отсутствие необходимых специалистов;
  • Плохое управление проектом;
  • Не подходящая архитектура;
  • Превышение способностей платформы;
  • Неподходящая организационная структура;
  • Расползание рамок проекта (Scope creep);
  • Изменение требований;
  • Изменение приоритетов;
  • Спонсор покидает проект;
  • База данных слишком велика;
  • Недооценили очичтку данных;
  • Не контролируемые поставщики (разработчики);
  • Не понятна новая технология;
  • Недоступны необходимые Вам пользователи;
  • Отсутствие процедур урегулирования разногласий.

Отвечает Лес Барбусински (Les Barbusinski)

Большинство фатальных опасностей, угрожающих проектам создания хранилищ данных, являются организационными, а не техническими (например, построение хранилища данных, которое не адресовано соответствующим потребностям бизнеса). Впрочем, в главе 4 книги “Data Warehouse Project Management” (Sid Adelman и Larissa Moss) представлен довольно лаконичный перечень основных рисков, с которыми может столкнуться проект хранилищ данных.

Отвечает Чак Келли (Chuck Kelley)

Факторы риска далеко не ограничены следующим списком:

  • нет корпоративного спонсора, занимающего достаточно высокого положения;
  • руководство проекта, не имеющее опыта по построению хранилищ данных, и настаивающее, чтобы делалось подобно оперативным (транзакционным) системам;
  • разногласия внутри вашей команды;
  • разработка базы данных, ориентированной на операции (transaction-oriented), а не ориентированной на агрегирование (aggregation-oriented);
  • отсутствие группы пользователей, вовлеченных в процессы выявления требований и разработки.

Отвечает Джо Оатес (Joe Oates)

Имеется много факторов риска реализации хранилища данных. Не могу сослаться на какие-либо результаты исследований, но могу сослаться на свой опыт участия в более чем 30 проектах внедрения хранилищ данных. Я охвачу те риски, которые, по-моему, являются наиболее важными. Кстати, они не имеют отношения к инструментам. Вот мой список самых важных факторов риска:

  • Отсутствие сильного спонсора или спонсор, не обладающий достаточно высоким уровнем, необходимым для мотивации людей;
  • Отсутствие надлежащей квалификации и опыта. Большинству людей нужен, по меньшей мере, один провал, прежде чем они поймут, насколько отличается хранилище данных – от оперативной системы обработки данных, или от небольшой витрины данных. Вы можете иметь прекрасные логические модели, но превращение их в реально работающую, интегрированную систему масштаба предприятия – самая трудная задача;
  • Непонимание того, что организации требуется от хранилища данных, и каким образом хранилище данных поможет в достижении стратегических целей организации;
  • Отсутствие этапа (проекта) по обеспечению качества данных, как составной части внедрения хранилища данных. Если пользователи не уверены в ответах от хранилища данных, они не будут его использовать;
  • Неадекватное (недостаточное) финансирование;
  • Политические ссоры как между, так и внутри структурных подразделений;
  • Отсутствие людей, которые действительно понимают исходную систему;
  • Плохое управление проектами.

Есть много других рисков, но перечисленные выше, по отдельности или в комбинации, навредили проектам хранилищ данных больше всего.

Отвечает Клей Рем (Clay Rehm)

Основных факторов риска гораздо больше, чем эта статья может вместить! Достаточно подробно про них написано в книге Сида Аделмана и Ларисы Мосс (Sid Adelman и Larissa Moss) под названием «Руководство проектом Хранилища данных» («Data Warehouse Project Management»). Некоторые из факторов риска, которые приходят на ум – это равнодушие или отсутствие спонсоров, проект с менталитетом “если мы будем строить это, то они придут” (“if we build it they will come”), техническая среда выбрана и создана до проекта.

Источник: http://www.dwh-club.com/node/12

Проектирование и внедрение хранилища данных в облаке

Опыт внедрения Хранилища данных

Построение современного хранилища – задача не из легких. В этой статье описываются методы, которые вы можете использовать для проектирования и внедрения хранилищ данных, которые вписываются в современные облачные инфраструктуры.

Введение

В вычислительной терминологии хранилище данных относится к системе, которая используется для анализа данных, отчетности в режиме реального времени и принятия решений. Его часто считают фундаментальной частью эффективной бизнес-аналитики.

Хранилища данных используются в качестве централизованных хранилищ для интегрированных данных, происходящих из разных источников.

Текущие, а также исторические данные хранятся в одном месте и используются для создания отчетов для бизнес-работников по мере необходимости.

Необработанные данные, полученные от различных отделов в бизнесе, подвергаются очистке перед использованием для дополнительной обработки. Этот процесс очистки данных имеет решающее значение для обеспечения стандартного качества данных, прежде чем они будут использоваться для отчетности и других подобных целей.

Более широкое определение хранилищ данных также включает в себя множество инструментов, используемых для бизнес-аналитики, извлечения данных и преобразования, для загрузки данных в репозиторий и для управления, а также для получения метаданных.

Проектирование хранилища данных

Хранилища данных помогают принимать бизнес-решения на основе исторических данных, собранных в течение определенного периода времени.

Однако бизнес-данные обычно распределяются между несколькими базами данных и приложениями, расположенными в разных географических зонах.

Теперь представьте, что вы компилируете эти данные, а затем используете Big Data Analytics для повышения удовлетворенности клиентов, упрощения затрат и поиска новых возможностей для роста. Хорошо спроектированное хранилище данных может помочь вам в этом.

Большинство компаний, которые утверждают, что у них есть хранилище данных, не понимают, что это понятие не связано с построением “свалки” для таблиц.

Вместо этого хорошее хранилище превращает необработанные данные в нечто очищенное, организованное, обобщенное и дополненное. Существует множество стандартных конструкций, которые вы можете попытаться построить.

Например, стандартное хранилище данных с извлечением, преобразованием и загрузкой (ETL) использует уровни продвижения, интеграции и доступа к данным для поддержания основных функций:

  1. В промежуточной базе данных хранятся необработанные данные, извлеченные из нескольких источников системы данных.
  2. Затем уровень интеграции объединяет различные наборы данных и преобразует их из более раннего уровня и сохраняет эти преобразованные данные в базе данных хранилищ операционных данных (ODS). После процесса интеграции данные снова перемещаются в базу данных хранилища, где они сортируются по иерархии и сохраняются как факты, так и агрегированные факты.
  3. Третий уровень, уровень доступа, – это то, где пользователи могут извлекать данные по мере необходимости.

Архитектура хранилища данных

Существует несколько различных способов построения или организации хранилища данных. Окончательная структура архитектуры хранилища данных обычно основывается на потребностях организации.

Основными факторами, определяющими архитектуру DW, являются используемые аппаратные компоненты, созданное программное обеспечение, а также конкретные ресурсы данных, необходимые для обеспечения правильной работы хранилища данных.

В большинстве случаев хранилище данных использует трехуровневую архитектуру. Каждый из уровней описан ниже:

  1. Нижний уровень. Архитектура нижнего уровня состоит из сервера базы данных хранилища данных. Это реляционная система баз данных. Пользователи могут использовать бэкэнд-инструменты, а также утилиты для ввода данных в этот уровень. Бэкэнд инструменты отвечают за выполнение функций Extract, Clean, Load, а также функции обновления.
  2. Средний уровень – средний уровень содержит сервер аналитической обработки On-Line (OLAP), который реализуется реляционными OLAP (ROLAP) и многомерными OLAP (MOLAP).
  3. Верхний уровень – это клиентский слой, расположенный на лицевой стороне. Верхний уровень содержит инструменты, используемые для запросов, отчетов, анализа и разработки данных.

Существует много реализаций трехуровневой архитектуры. Традиционная реализация использовала базы данных для реализации складов. В современной реализации используется облако.

Локальное хранилище данных

До эволюции хранилищ данных в реальном времени или облачных хранилищ существовало множество традиционных методов хранилища данных. Традиционные методы хранилища данных были разработаны для поддержки поддержки запрограммированных функций, таких как:

  • Data Roll Up – данные обобщаются путем сводки
  • Pivot – данные перекрестно табулируются или чередуются по мере необходимости
  • Slice and Dice – на основе определенных измерений выполняются операции проецирования
  • Drill Down – раскрывает подзадачи различных наборов данных
  • Selection – возможность выбора данных на основе значений и диапазона
  • Sorting – возможность сортировки данных на основе порядкового значения

Недостатком традиционного метода хранения данных является то, что он требует больше ресурсов, большего времени разработки и доступа к инструментам бизнес-аналитики.

Коды ETL должны быть написаны от руки, что требует чрезмерно длительного периода времени для создания хранилища данных.

Из-за задержки во времени хранилище данных, чаще всего, не синхронизируется с требованиями, необходимыми во время развертывания.

К сожалению, фактическое значение, а также возможности данных плохо понимались до создания хранилища данных и к тому времени хранилище уже не соответствовало текущим требованиям. Если проектирование хранилища данных не было остановлено на полпути к завершению, его завершение приводило к дорогостоящему и негибкому способу анализа данных.

Процесс создания традиционного хранилища включал следующие шаги:

  1. Определение и сбор требований
  2. Проектирование размерной модели
  3. Выполнение запросов T-SQL для создания и заполнения таблиц измерений и фактов

Хранилище данных в облаке

Облачное хранилище данных – это, по сути, подход Data Warehouse as Service (DWaaS), предназначенный для упрощения дорогостоящего и трудоемкого управления, обслуживания и администрирования и тонкой настройки, необходимой при работе с локальными хранилищами данных. Реализация архитектуры DW в облаке проще, потому что инструменты облачного хранилища построены соответствующим образом.

Реализация средних и верхних уровней функциональности архитектуры требует очень мало усилий по сравнению с инфраструктурой DW на месте. Инструменты облачного хранилища данных также используют алгоритмы машинного обучения, которые иначе трудно построить для предприятия.

Размещение DW на облаке приносит много преимуществ. Перенос традиционного хранилища данных в облако может быть сложным процессом перемещения данных, схемы и ETL. В случае реструктуризации схемы базы данных или если вы планируете перестраивать различные конвейеры данных, сложность миграции возрастает экспоненциально.

Когда бизнес решает о облачном хранилище, возникает следующий очевидный вопрос: следует ли использовать открытое облако или частное?

Проблемы, с которыми сталкиваются при использовании открытого облака, такие как производительность рабочей нагрузки, безопасность данных и законы о конфиденциальности, можно легко решить, если использовать частное облако.

Производительность рабочей нагрузки намного лучше в частном облаке, чем в открытом, поскольку аппаратное обеспечение можно настраивать для таких тяжелых рабочих нагрузок.

Кроме того, при использовании частного облака организация или бизнес управляет облачной средой.

Защита данных и конфиденциальность также предусмотрены, так как большинство частных облаков размещаются в сети центра обработки данных. Частные облака также могут обеспечить производительность, стоимость, масштабируемость, гибкость, а также преимущества эластичности.

Таблица сравнения традиционного, облачного частного и открытого хранилищ данных

Традиционное хранилище данныхОткрытое облачное хранилище данныхЧастное облачное хранилище данных
Начальные затратыВысокиеНизкиеОт средних к высоким
Дополнительные затратыВысокиеНизкиеНизкие, пока не достигнут лимит оборудования
Время выполнения средыВысокоеНизкоеНизкое, при условии, что настроены все приобретенные аппаратные средства и виртуальные машины
МасштабируемостьНеобходимо предварительное планированиеБезотлагательноеНеобходимо предварительное планирование
Производительность рабочей нагрузкиВысокие рабочие нагрузкиНизкие рабочие нагрузкиВысокие рабочие нагрузки
Интеграция данныхЛегкаяТяжелаяЛегкая
Законы о конфиденциальностиСоблюдаютсяМогут как соблюдаться, так и нетСоблюдаются
Безопасность данныхВысокаяНизкаяВысокая

Подводя итог:

Источник: http://spbdev.biz/blog/proektirovanie-i-vnedrenie-hranilishcha-dannyh-v-oblake

Как успешно внедрить хранилище данных

Опыт внедрения Хранилища данных

Согласно исследованиям, более 50% проектов по внедрению хранилищ данных и аналитических приложений заканчиваются неудачей.

Такую неутешительную статистику нам озвучили сотрудники лаборатории IBM в Ирландии, где ведется разработка и поддержка индустриальных моделей данных, включая модель данных банковских хранилищ. Это было неожиданно.

Особенно, если учесть, что информация была озвучена делегации топ-менеджеров Государственного сберегательного банка Украины, которые в 2011 году приехали в Дублин, чтобы ближе познакомиться с моделью IBM Banking Data Warehouse (IBM BDW).

Не знаю, как мне удалось тогда убедить руководство приступить к созданию такого хранилища.

В одном из разговоров мой бывший шеф, член правления и финансовый директор банка, сказал: «Если бы я знал, во что я ввязываюсь, я бы еще раз хорошо подумал».

Но, видимо, иногда в жизни бывают моменты, когда сама судьба сталкивает нужных людей в нужное время и в нужном месте. И тогда ты задаешь себе простой вопросы: если не я, то кто, и, если не сейчас, то когда?

Сегодня, оглядываясь назад, можно выделить семь факторов, благодаря которым стал возможен успех нашего проекта.

1. Заинтересованность первого лица

Итак, статистика по успешным проектам неутешительная. С высоты моего нынешнего опыта могу сказать, что в действительности число успешных проектов еще меньше.

Даже если IT-система вводится в эксплуатацию, это не означает, что она будет жизнеспособна, будет развиваться и поддерживаться в долгосрочной перспективе.

Иногда ввод в эксплуатацию – это лучший способ закрыть неудачный проект, отчитавших об успехах перед правлением или собственниками банка.

В таких сложных IT-проектах, как внедрение хранилищ и построение систем отчетности, параллельно с проектом автоматизации происходят системные и глубокие изменения в процессах банка, затрагиваются интересы и сферы ответственности ключевых менеджеров. Неизбежно происходит серьезная перестройка всего банка. Поэтому одним из главных факторов успеха все же является желание председателя и, как минимум, одного из его ключевых заместителей, изменить банк, сделать его более управляемым и прозрачным.

2. Финансовый директор – лучший бизнес-спонсор

Именно финансовый директор в силу служебных обязанностей отвечает перед национальным банком, регуляторами и возможными инвесторами за предоставление достоверной и полной финансовой информации.

А с внедрением в Украине и России международных стандартов финансовой отчетности (МСФО), раскрытие информации становится отраслевым стандартом, особенно, если банк ищет внешние заимствования на международных рынках капитала.

Кроме того, именно у финансового директора в руках бюджет и штатное расписание, что немаловажно, как для нормального финансирования текущих расходов проекта и удержания команды высококвалифицированных разработчиков, так и для капитальных инвестиций в оборудование и программное обеспечение.

Роль бизнес-спонсора такого проекта может взять на себя и операционный директор, и директор по IT. Но, как правило, они озадачены другими системными вопросами, которые находятся в зоне их непосредственной ответственности (централизация бэк-офиса, автоматизация и оптимизация бизнес процессов). Хранилище и система отчетности играют для них второстепенную роль.

3. Прямое подчинение менеджера спонсору проекта

Наличие спонсора необходимое, но недостаточное условие успеха. Проект должен возглавить надежный менеджер с опытом в банковском бизнесе, пониманием IT-технологий, знаниями в области моделирования и работы с данными. Кроме того, менеджер должен обладать четким видением будущего и пониманием тенденций развития системы отчетности.

Ключевым фактором успеха является прямое подчинение менеджера проекта бизнес-спонсору, регулярная отчетность и обратная связь между ними. Это в разы повышает эффективность управления и снимает многие проектные риски на старте.

Менеджер проекта должен обладать не только хорошими лидерскими качествами, но также быть хорошим психологом. Умение слушать людей, понимать и примирять разные точки зрения – это те неоценимые качества, без которых эффективное управление отношениями и управление информацией в проекте просто невозможны.

Менеджер должен уметь общаться с людьми на разных уровнях организационной иерархии, знать, как, кому и когда доносить нужную информацию. А главное, он должен понимать, зачем он это делает, какой результат он хочет получить, воздействуя на систему, и, какую цену он готов заплатить за этот результат.

4. Внутреннее управление проектом при создании новых функций

Один из ключевых выборов для менеджера, который инициирует проект, является выбор между внутренним и внешним управлением проектом. Ему необходимо решить – брать ли ответственность на себя или перепоручить эту роль внешней компании.

На старте нашего проекта в 2011 году на рынке Украины уже было начато несколько проектов по внедрению хранилищ на основе IBM BDW.

Но на тот момент у IT-партнеров IBM в Украине не было знаний не только в части моделирования IBM BDW, но и в части поддержки других программных продуктов IBM InfoSphere Information Server, которые необходимы для полноценного внедрения хранилищ данных. Не было и локальных консультантов, которые способны были бы эти знания и опыт передать команде разработки.

Мне было очевидно, что для успеха проекта просто необходимо найти надежного западного IT-консультанта, который сможет обучить команду на этапе разработки и обеспечить необходимое качество ведения проекта.

Именно из-за этого понимания, и возникла необходимость организовать визит в Дублин, о котором я упомянула вначале статьи.

Необходимо было понять, кто из партнеров IBM за рубежом способен передать уникальные знания разработчикам и бизнес-аналитикам в Украине.

Как потенциальный менеджер проекта, я очень хорошо осознавала, что местные IT-компании будут учиться моделированию и построению хранилища вместе с нами. При этом мы не сможем напрямую контролировать и удерживать их сотрудников, которые будут приобретать уникальные знания за счет работы с западными консультантами.

Было принято решение ввести внутреннее управление проектом, чтобы, в том числе, создать и сохранить новые навыки и уникальные, даже для западного рынка, компетенции внутри организации.

5. Создание отдельного подразделения

Проектная команда по сути была вписана в функциональную организацию финансово-экономического департамента, в жесткие рамки иерархической структуры банка. На ранних этапах проекта было создано отдельное подразделение систем информации для менеджмента или Management Information Systems (MIS) с абсолютно новыми функциями.

Кроме того, проектные роли были вложены в штатное расписание, насколько это было возможно. При этом проектные роли по сути превалировали над штатными должностями. Я осознанно нивелировала иерархическую структуру подчинения и выстроила между членами команды плоскую горизонтальную коммуникацию.

Основным условием была 100% фокусировка подразделения на участии в проекте. В будущем это подразделение должно было стать собственником хранилища и системы отчетности. Это снимало возможное напряжение в проектной команде. Люди понимали, что и после окончания проекта у них будет постоянная работа, перспективы развития и карьерного роста.

6. Вовлечение владельцев источников в команду на аутстафинге

В рамках подразделения MIS было создано пять команд, каждая из которых решала свою задачу: бизнес-анализ и моделирование; разработка процедур загрузки данных ETL и метаданными; разработка отчетов BI; разработкой WEB-приложений для хранилища; выгрузкой данных из систем-источников хранилища.

Последняя команда была сформирована из сотрудников компании-разработчика основных источников данных. Мы привлекли команду дата-аналитиков и разработчиков на аутстафинге. Это ускорило коммуникации, упростило процесс разработки выгрузок данных и в разы ускорило маппинг данных источников на модель данных хранилища (Source to Target).

Первый релиз был внедрен в рекордно короткие сроки в течение девяти месяцев по методу Waterfall и по нынешним временам с очень скромным бюджетом. Во время последующих релизов команда освоила гибкое управление проектом по методу Agile.

7. Мотивация команды и миссия проекта

Важнейшим фактором была готовность людей обучаться, работать с новыми программными продуктами, осваивать сложную модель IBM BDW. Как менеджеру проекта, мне было абсолютно понятно, что люди должны быть мотивированы не только и не столько деньгами, сколько перспективой получения новых знаний и освоения новых инновационных технологий.

Наверное, во многом успех проекта был обусловлен тем, что мне удалось связать мотивы топ-менеджмента банка, личные мотивы членов команды и мои личные мотивы как консультанта.

Но главное мне удалось показать команде внедрения высший смысл их работы: прозрачность и управляемость одного из системообразующих банков страны.

Кроме того, прозрачная отчетность была основным требованием внешних институциональных инвесторов, которые хотели войти в капитал банка. Это могло изменить в лучшую сторону инвестиционный климат страны в целом.

К моменту ввода хранилища в тестовую эксплуатацию команда MIS чувствовала невероятный подъем. Это произошло 24 декабря 2012 накануне католического рождества. Дата была символичной. Девять месяце прошло, и родилось наше детище. Мы это сделали, мы действительно это сделали. Но как показала история, это было лишь начало нового этапа жизни.

8. Желание заказчика продолжать изменения

Хранилище ясно проявило проблемы с данными в системах-источниках: некорректное ведение справочников, хранение истории… Проблемы с данными отражали наши проблемы не только в архитектуре источников-данных, но и пробелы в процессах и функциях банка. Это напрямую затрагивало интересы и сферу ответственности многих менеджеров среднего и высшего звена. И именно в этот момент вступили в игру совсем другие факторы и мотивы.

На этом этапе развития проекта топ-менеджменту приходиться отвечать себе на главный вопрос: действительно ли нам нужна прозрачная отчетность, хотим ли мы понятную систему поощрений, хотим ли мы менять правила игры? В этот момент решается дальнейшая судьба системы информации. И, как в известной поговорке, часто возникает ситуация «наказания невиновных и награждения непричастных».

На этом этапе нужны воля и желание председателя и бизнес-спонсора продолжать изменения. Именно здесь возникает необходимость внедрять политики и процедуры управления данными, закреплять новые роли и ответственность пользователей за данные, которых ранее в банке не было.

Эти процессы и роли (Data Stewards, Business Experts, Bank Data Managers, Data Quality Managers, Data Owners), уже давно стали стандартом в западных банках. Нашим же банкам еще только предстоит внедрять их в свою практику и процессы.

9. Благодарные пользователи – ключ к успеху

Мы в свое время недооценили важность вовлечения бизнес-пользователей отчетов на ранних этапах проекта. Именно их участие в определение терминов, в разработке требований к отчетам, справочникам, алгоритмам расчетов является важнейшим фактором успеха проекта на этапе тестирования и ввода в эксплуатацию.

Это помогает пользователям легче принять ответственность за формируемую отчетность, стать собственниками данных и включиться в процессы управления данными после ввода в эксплуатацию. Благодарные пользователи – ключ к дальнейшему развитию хранилища и системы информации.

10. Нужен Chief Data Officer

В моем нынешнем проекте в венском Erste Bank, где также внедряется хранилище на основе IBM BDW, меня поразил тот факт, что весь банк (от членов правления до рядовых сотрудников) разговаривает на языке моделирования, на языке атрибутов и терминов модели данных.

Основная цель Erste Bank на ближайшие годы связана не с улучшением обслуживания и лояльности клиентов, а с Data Excellence. Бонусы и ключевые показатели (KPI) топ-менеджмента банка напрямую связаны с качеством данных.

Для решения проблем с данными часто требуется эскалация на уровень соответствующего комитета (Operational Decision Committee) или правления. Возникает абсолютно новая управленческая роль – директор по данным (Chief Data Officer).

В Европе такой топ-менеджер входит в состав правления банка, и такой подход уже стал отраслевым стандартом.

Источник: https://www.e-xecutive.ru/finance/business/1987721-kak-uspeshno-vnedrit-hranilische-dannyh

Хранилища данных: новый виток развития #электронный архив #СЭД #ECMJ

Опыт внедрения Хранилища данных

В настоящий момент внедрение Хранилищ данных (ХД) и связанных с ними технологий находится в процессе невиданного за последние несколько лет  ускоренного развития и изменения. Недавние результаты, представленные аналитиками компании IDC, показывают, что рынок ХД составляет сегодня около 10 млрд. долларов, а в ближайшие годы может возрасти до 13,5 млрд.

Казалось бы, идея ХД, «с нуля» выросшая во всемирный многомиллиардный рынок, уже изживает себя. Однако осуществленные за последние годы новые разработки говорят о том, что в этой области грядет возрождение. Крупные корпорации по всему миру получают существенные преимущества за счет технологии Хранилищ, которая потенциально может принести еще больше пользы.

Конечно же, рассматриваемый ренессанс вызван ничем иным, как довольно суровыми требованиями современного бизнеса.

Особый акцент на соответствие нормативным актам, быстрый доступ к бизнес-информации (необязательно в реальном времени, но хотя бы в режиме ежедневного или ежечасного, а не ежемесячного обновления), а также все более растущая необходимость повышения эффективности бизнеса – вот те факторы, которые стимулируют разработку и модернизацию методов и технологий ХД. Несколько лет назад даже нельзя было себе представить, как некоторые прогрессивные компании будут использовать современные Хранилища сегодня.

Эти организации строят свою работу на основе «информационного менеджмента».

Идейное руководство такими фирмами, как правило, находится в руках бизнес-специалистов, а не IT-директоров, а поэтому в них применяется серьезный подход к управлению данными, в том числе рассматривается качество данных, используются Хранилища и управление нормативно-справочной информацией. Подобное изменение в культуре деятельности компании, сочетающееся с более эффективными технологиями, и является тем самым фактором, который предвещает «второе рождение» отрасли ХД.

Разработка или покупка?

Идея Хранилищ, как известно, не нова: они появились в середине 1980-х годов, когда компания IBM выдвинула термин «информационное хранилище». Билла Инмона (Bill Inmon) часто именуют «отцом Хранилищ данных» за ту работу, которую он проводил в те времена в канадском филиале компании Shell.

В 1994 году термин был широко признан и получил распространение в отрасли, хотя на рынке это новшество стало появляться лишь в конце 90-х.

Если не считать дебатов между известными «гуру» — Биллом Инмоном и Ральфом Кимболлом (Ralph Kimball), которые предлагали несколько разные подходы, фактически, сам по себе подход к разработке ХД с тех времен не сильно изменился. Команды разработчиков традиционно создавали специализированный продукт на основе потребностей своей организации.

Это всех устраивало до тех пор, пока не происходила реструктуризация бизнеса или не изменялись требования к бизнес-отчетности. Часто в таких ситуациях Хранилище теряло свой смысл и проект терпел провал. Вот откуда происходит та печальная статистика, согласно которой 50% ХД оказываются неудачными.

Тем не менее, базовая идея ХД  очень сильная и удобная. Данные из изолированных систем объединяются вместе, интегрируются, и результирующая выборка анализируется.

Также проводится сравнение эффективности бизнеса на любом уровне, от отдельного департамента до всей корпорации. Обычно для создания такого ХД применялся метод «большого взрыва».

При этом существенным ограничением было задание всех параметров ХД заранее (в среднем за 16 месяцев) с целью определить исходные системы, а также требования к запросам и отчетам.

Этот традиционный, но вместе с тем и весьма  неудобный подход со временем изменился. Появилась технология бизнес-моделей, обеспечивающая исходную структуру базы данных, которую в дальнейшем можно внедрить и быстро адаптировать к любому бизнесу в очень короткие промежутки времени. Работает это следующим образом.

Вся информация хранится в нейтральном формате, не привязанном к какой-либо специфической структуре.

Бизнес-модель компании можно легко настраивать и изменять отдельно, что позволяет быстро получать отчеты по любой структуре (например, по продуктам, клиентам, внутренней организации или по поставщикам) в произвольный момент времени.

Теперь  ХД, как правило, уже не реализуется методом «большого взрыва». Хранилища поставляются в виде готовых пакетов, а не разрабатываются на заказ.

Поэтапное внедрение

Основной упор сегодня делается на поэтапную разработку и получение бизнес-преимуществ на ранних стадиях (от одного до трех месяцев).  Максимальные шансы на успех у тех проектов, которые разбиваются на мелкие шаги и с самого начала дают компании какие-то положительные результаты. Принцип таков: «мыслить глобально, начинать с малого,  развиваться постепенно».

Контроль изменений

Что касается поддержки бизнес-изменений, то, по сути дела, речь здесь идет об отслеживании всех малейших изменений в кодах и структурах кодирования, а также в хранении дат начала и окончания использования кодов.

Эти исторические сведения могут быть очень важным источником бизнес-информации для сравнения эффективности на различных временных этапах, например, для аудита, выявления изменений в поведении клиентов, анализа влияния организационных изменений с целью улучшений планирования.

Во времена построения специализированных ХД оценку временных изменений было очень дорого и сложно проводить. Теперь новые возможности технологии позволяют извлекать полезную информацию из огромных объемов данных, которые накапливаются в компании за несколько лет.

Управление нормативно-справочной информацией

Еще одна причина вновь возникшего интереса к Хранилищам — управление нормативно-справочной информацией (НСИ), то есть возможность создавать и управлять определениями объектов Хранилища. Речь идет о продуктах, клиентах, поставщиках и марках продукции.

Управление НСИ покорило отрасль буквально за последний год, обеспечивая полноценный контекст,  позволяющий оценивать эффективность бизнеса, благодаря повышению качества отчетности по данным, взятым из Хранилища, а также из оперативных систем (например, ERP и CRM).

А что же с витринами данных?

Еще одно изменение в практике внедрения ХД –  практически полное вымирание идеи независимых «витрин данных» (подмножеств Хранилища для конкретных типов объектов).

В 1990-е годы, разочаровавшись в дорогих специализированных ХД, некоторые компании отказались  от них и стали проектировать специализированные витрины, не задумываясь о центральном ХД. Этот подход неудачен по целому ряду причин.

И в наше время передовые организации считают, что оптимальный путь состоит в построении Хранилища, которое может генерировать зависимые витрины, тем самым добиваясь решения двух главных задач: корпоративного масштаба и локальной скорости и гибкости.

Рост масштабов Хранилищ

Недавний опрос, проведенный Институтом Хранилищ данных (The Data Warehousing Institute — TDWI), подчеркивает растущую потребность в Хранилищах, которые проектируются с возможностью масштабирования до многотерабайтных объемов данных. Результаты этого опроса среди участников конференции TDWI показали, что рынок все больше требует от ХД скорости, простоты и масштабируемости.

Кратко результаты исследования можно изложить следующим образом:

●     на сегодняшний день 36% ХД содержат несколько терабайт данных;

●     к 2007 году таких Хранилищ будет уже 48%;

●     87% данных Хранилищ находятся в оперативном доступе и могут быть использованы для выполнения запросов;

●     Хранилища, которые традиционно начинались с небольшого объема данных, теперь проектируются в расчете на несколько терабайт;

●     TDWI рекомендует для многотерабайтных объемов применять «опережающее планирование» и требовать параллельной обработки по всем компонентам, как аппаратным, так и программным.

«Исследование TDWI показывает, что в последние годы наблюдается скачок в развитии многотерабайтных Хранилищ, и новый виток ожидается в конце 2007-го года», — заявляет Филип Рассом (Philip Russom), руководитель исследований TDWI.

«В среднем объем данных в Хранилищах будет ежегодно расти на 33%.

Пользователи должны планировать мощности с учетом многотерабайтного потока данных, рассчитывая на такие платформы, которые уже оптимизированы для выполнения запросов в масштабах всего Хранилища и легко расширяются с минимальными усилиями на администрирование», — продолжает он.

Заключение

Та самая печальная статистика, показывающая, что половина проектов по созданию Хранилищ данных заканчивается неудачно, смущает IT-  и бизнес-руководителей, ответственных за внедрение средств Business Intelligence.

  Однако эта пугающая цифра, скорее всего, сократится, поскольку все большее число компаний становится умнее и переходит на полномасштабное использование передовых адаптируемых возможностей ХД, а также отказывается от собственной разработки и покупает готовые продукты ХД.

Вдохновляет тот факт, что в отрасли наблюдается явный рост.

Сегодня поставщики предлагают витрины, оперативные склады данных и Хранилища. Можно выбрать нужную платформу, оптимизированную с точки зрения производительности ХД (так называемые устройства для Хранилищ данных — data warehouse appliances), причем даже для очень больших объемов транзакций.

Передовые устройства для ХД  удовлетворяют требованиям масштабирования, возникающим по мере роста объема информации и усложнения запросов. Устройства, лидирующие на рынке, созданы специально для хранения, фильтрации, обработки и анализа терабайтов детальных данных.

Источник: https://ecm-journal.ru/docs/Khranilishha-dannykh-novyjj-vitok-razvitija.aspx

Хранилище логов для облачной платформы. Опыт внедрения ELK

Опыт внедрения Хранилища данных

Источник

Всем привет! Сегодня мы продолжим рассказывать про облачное хранилище Техносерв Cloud, но уже с точки зрения эксплуатации. Ни одна ИТ-инфраструктура не обходится без инструментов мониторинга и управления, и наше облако не исключение.

Для решения повседневных задач, связанных с мониторингом, мы используем продукты с открытым исходным кодом, одним из которых является стек ELK.

В этой статье мы расскажем, как в нашем облаке устроен мониторинг журналов, и как ELK помог нам пройти аудит PCI DSS.

Задача централизованного сбора и анализа логов может возникнуть на любом этапе жизненного цикла продукта.

В случае с облачным хранилищем Техносерв Cloud необходимость единой консоли для просмотра журналов стала очевидной еще до запуска решения в эксплуатацию, уже на старте проекта требовался инструмент, позволяющий быстро выявить проблемы в используемых системах.

В качестве такого инструмента был выбран стек ELK – простой в настройке и эксплуатации продукт с открытым исходным кодом и возможностью масштабирования.

ELK – основной инструмент наших инженеров для просмотра логов платформы: в Elasticsearch собираются записи журналов со всех эксплуатируемых серверов и сетевого оборудования. Мы убеждены, что логов много не бывает, поэтому наши системы делают записи в журналы с максимальным уровнем отладки.

Для получения событий используется Beats: filebeat и winlogbeat, syslog и SNMP трапы. С сетевых устройств также собирается информация о трафике по протоколу Netflow.

На сегодняшний день наш стек ELK обрабатывает около 1000 входящих записей в секунду с пиками до 10000 записей, при этом выделенных ресурсов по предварительным прогнозам должно хватить на 2-/3-кратное увеличение потока логов.

Архитектура

Надежность – одно из ключевых требований, предъявляемых к используемым системам. По этой причине ELK был установлен в отказоустойчивой конфигурации: нам важно быть уверенными, что логи продолжат собираться в случае недоступности части серверов.

Количество VM Назначение Используемое ПО
2Балансировщики нагрузкиKeepalived + HAproxy + nginx
4Получение и обработка входящих журналовLogstash
3Master-ноды кластера ElasticsearchElasticsearch
6Data-ноды кластера ElasticsearchElasticsearch
1Пользовательский интерфейсKibana

Так выглядит архитектура нашей инсталляции ELK:

В качестве балансировщиков трафика используются HAproxy и nginx, их отказоустойчивость достигается при помощи keepalived – приложения, реализующего протокол маршрутизации VRRP (Virtual Router Redundancy Protocol).

Keepalived настроен в простой конфигурации из master и backup нод, таким образом, входящий трафик приходит на ноду, которой в настоящий момент принадлежит виртуальный IP адрес.

Дальнейшая балансировка трафика в Logstash и Elasticsearch осуществляется по алгоритму round-robin (все так же используем простые решения).

Для Logstash и Elasticseach отказоустойчивость достигается избыточностью: система продолжит корректно работать даже в случае выхода из строя нескольких серверов. Подобная схема проста в настройке и позволяет легко масштабировать каждый из установленных компонентов стека.

Сейчас мы используем четыре Logstash сервера, каждый из которых выполняет полный цикл обработки входных данных.

В ближайшее время планируем разделить сервера Logstash по ролям Input и Filter, а также добавить кластер RabbitMQ для буферизации данных, отправляемых из Logstash.

Использование брокера сообщений позволит исключить риски потери данных в случае разрыва соединения между Logstash и Elasticsearch.
Конфигурация Elasticsearch у нас также проста, мы используем три master ноды и шесть data нод.

Kibana – единственный компонент, который не резервируется, так как выход «кибаны» из строя не влияет на процессы сбора и обработки логов. Для ограничения доступа к консоли используется kibana-auth-plugin, а при помощи плагина Elastic HQ мы можем наблюдать за состоянием кластера Elasticsearch в веб-интерфейсе.

Как было отмечено выше, помимо логов, мы собираем статистику Netflow при помощи коробочного плагина logstash. Настроенные представления помогают дежурным администраторам получать актуальные данные о трафике.

Для диагностики сетевых проблем это важный инструмент, так как Netflow позволяет получить детальную информацию о потоках трафика внутри сети в тех случаях, когда логов сетевого оборудования недостаточно.

На скриншоте ниже видно представление Kibana для Netflow: диаграммы показывают адреса, участвующие в обмене трафиком, и объем принятых/переданных данных.

В мае текущего года мы решали задачу прохождения сертификации PCI DSS — стандарту безопасности данных индустрии платежных карт. Одним из требований соответствия данному стандарту является наличие системы контроля событий информационной безопасности.

На момент прохождения сертификации стек ELK уже работал и собирал данные с большей части эксплуатируемого оборудования, поэтому было принято решение использовать его в качестве системы контроля событий ИБ.

В ходе подготовки к аудиту, для всех системных компонентов Техносерв Cloud была настроена отправка в ELK событий безопасности, в том числе следующих:

• любой доступ к данным заказчиков; • все действия, совершенные с использованием административных полномочий, на серверах и сетевом оборудовании облачной платформы; • любой доступ к журналам регистрации событий системных компонентов Техносерв Cloud; • любой доступ пользователей к системным компонентам платформы; • добавление, изменение и удаление учетных записей; • запуск и остановка системных компонентов платформы;

• создание и удаление объектов системного уровня.

Для демонстрации наличия перечисленных выше событий в системе были подготовлены представления Kibana. На скриншотах ниже видны попытки доступа пользователей на наши сервера и записи о выполнении команд из-под sudo.

Зафиксированные неуспешные попытки доступа

Выполнение команд от имени суперпользователя

Подводя итоги

Централизованная консоль для работы с событиями позволяет эффективно управлять IT инфраструктурой. В нашем случае с ELK мы достигли следующих целей:

• используя единую консоль для работы с записями журналов, сократили время на диагностику проблем и, следовательно, уменьшили время недоступности сервисов; • с помощью представлений Kibana получили информацию о работе платформы в целом;

• реализовали требования PCI DSS по регистрации и хранению событий безопасности.

Источник: https://habr.com/company/technoserv/blog/336154/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.