6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.

1. Построение
Хранилищ Данных
в крупных банках
06-07 июня 2017
Теренин
Алексей
Алексеевич
AATerenin.SBT@
sberbank.ru

2.  Принципы и основные виды
архитектуры Хранилищ Данных (ХД)
 Основные компоненты ХД и стадии проекта внедрения ХД
 Управление релизами ХД
 Цели и методы тестирования на разных стадиях проекта
 Тестирование основных компонент
 Важно покрытие не только кода, но и данных
 Производительность и масштабируемость
 Сравнение тестирование Баз Данных и ХД
 Лучшие практики тестирования ХД
Аннотация

3. Хранилище данных – репозиторий данных, хранящий данные
организации в исторической перспективе с целью их использования
для отчётности, принятия стратегических и тактических решений,
использования в оперативной деятельности.
Хранилище данных – объединенная и совместная
модель данных для сбора всех данных организации.
Что собой представляет Хранилище Данных?
Хранилище данных – предметно ориентированный, интегрированный,
неизменяемый и поддерживающий хронологию набор данных,
поддерживающий управление принятия решений [Инмон]
Хранилище данных – это копия данных, возникающих в ходе ведения
дел (транзакций), которые подвергнуты структурированию для
выставления запросов и получения отчетов [Ральф Кимбелл].

4. Перенос данных из различных гетерогенных источников в единый приемник.
Консолидация и очистка данных, для дальнейшего анализа данных и выработки
решений на основе этого анализа
Проведение OLAP (online analytical processing, аналитическая обработка в
реальном времени)
Не предназначено для OLTP!
Основное назначение и схема хранилища данных (ХД)

5. Не нормализованы!
Представлены в виде, наиболее удобном для быстрого
извлечения стандартных отчетов или многофакторного анализа
▪В виде таблиц измерений и фактов,
▪Схемы «звезда» или «снежинка»,
▪В виде многомерных кубов,
▪Историчность
Некоторый компромисс множества разрозненных данных,
хранящихся в различных системах
Данные в Витринах хранилища

6. • Слияния и поглощения
• Развитие бизнеса, внедрение системы
поддержки решений
• Возрастающие требования регулирующих
органов и внутренних политик организации
• Консолидация центров обработки данных
• Технологические преимущества
Почему хранилища данных завоевали популярность?

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

8. • Все возрастающая потребность бизнеса компании в
определенных категориях данных за различный период
времени
• Объем информации, на основании которой необходимо
принимать решение, постоянно растет
• Систематизация и анализ разнородных
бизнес-процессов (холдинги, крупные
универсальные многофилиальные банки,
крупные розные сети)
Основание для начала проектирования хранилища

9. • Отчеты, аналитика на отдельных серверах
• Модель данных ускоряющая OLAP, но не транзакции
• Сокращение стоимости ИТ эксплуатации
• Источник данных с предварительно очищенной информацией
• Упрощение процесса подготовки отчетов
• Исторические данные и выполнение анализа «в прошлом»;
• Упрощение работы пользователей
Основные преимущества при внедрении ХД
Ценность хранилища приобретается в процессе наполнения его
данными из разных источников: внутрикорпоративных, конкурирующих
компаний, статистической и аналитической информации, данных от
заказчиков и покупателей.

10. • Данные забираются из источников, т.е. оперативных систем
организации, перерабатываются, загружаются в БД
хранилища, и затем на основе переработанных данных
строятся отчёты
• Центральное ХД (Инмон)
• Функционально-ориентированное (Кимбел)
Архитектура хранилищ данных

11. • Независимые витрины данных (independent data marts);
• Шина взаимосвязанных витрин данных(data-mart bus architecture
with linked dimensional data marts);
• Архитектура «звезда» (hub-and-spoke);
• Централизованное хранилище данных (centralized data
warehouse);
• Федеративная архитектура (federated architecture).
Пять наиболее распространенных архитектур

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

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

14. • Централизованное хранилище данных с зависимыми витринами
данных
• Разрабатывается на основе корпоративного анализа требований
к данным
• Детальные данные хранятся в нормализованной форме в
хранилище
• Зависимые витрины данных агрегируют данные из хранилища и
разрабатываются для подразделений или функций
Архитектура «звезда»

15. • Похожа на архитектуру «звезда» за исключением отсутствия
зависимых витрин данных
• Хранилище данных содержит детальные данные, некоторое
количество агрегированных данных и логические представления
• Запросы и приложения выполняются как на реляционных
данных, так и на многомерных представлениях
Централизованное хранилище данных

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

17. Рациональные факторы:
▪информационная зависимость между организационными
подразделениями;
▪информационные потребности руководства;
▪срочность внедрения хранилища данных;
▪характер пользовательских задач;
▪ограниченные ресурсы;
▪стратегическое представление хранилища данных до внедрения;
▪совместимость с существующими системами;
▪возможности персонала.
Выбор архитектуры

18. Технические факторы:
▪масштаб проекта;
▪сложность;
▪отделять ли данные от аналитики?
▪организационный интерес к качеству данных;
▪гибкость к росту;
▪бюджет;
▪ресурсы, навыки.
Социальные факторы:
▪влияние экспертов
▪процесс принятия решений
Выбор архитектуры

19. • Независимые витрины данных (independent data marts);
• Шина взаимосвязанных витрин данных(data-mart bus architecture
with linked dimensional data marts);
• Архитектура «звезда» (hub-and-spoke);
• Централизованное хранилище данных (centralized data
warehouse);
• Федеративная архитектура (federated architecture).
Пять наиболее распространенных архитектур

20. • виртуальные хранилища данных;
• независимые витрины данных;
• централизованные хранилища данных;
• инмонова модель со слоями детальных и консолидированных данных;
• расширенная инмонова модель с персональными витринами данных;
• инверсная инмонова модель;
• централизованное хранилище с накоплением данных в независимых
витринах;
• централизованное хранилище с тематическими витринами данных;
• централизованная очистка данных с параллельными хранилищами и
витринами данных.
Дальнейшая классификация архитектур ХД

21. • Возможно модульное построение с использованием ПО
различных фирм
• Наиболее полно позволяет учесть специфику конкретной
организации
• Дополнительные модули других производителей будут иметь
свое хранилище
• Сложная работа с совокупностью таких подсистем и
хранилищ
• Потребуется системная интеграция
Независимые компоненты

22. • Дополнительные затраты на закупку и тестирование
разнообразных продуктов
• Сложнее сопровождать
• Увеличивать производительность возможно только в
частном порядке для отдельных компонент
• Увеличение производительности потребует
перепроектирования структуры хранения или перехода на
более современные
и сложные программные средства
Тестирование и развитие независимых компонент

23. • Интерфейс с системами источниками
• ETL извлечение, трансформация и загрузка
• Область консолидации и очистки данных
• Собственно хранилище данных
• Загрузчик витрин данных
• Витрины данных
• Отчеты и средства их экспорта
• Средства анализа и визуализации
Компоненты Хранилищ данных

24. • Прямой доступ к БД источника или ее копии,
прямой доступ к БД хранилища, обмен файлами
• Очистка данных
• Удаленные записи
• Гибкость ETL-ELT средств
ETL и ELT извлечение, преобразование, загрузка

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

26. • Отчетность в режиме онлайн
• Ad hoc (хаотичные) запросы
• Интеллектуальный анализ данных,
data mining
• Экспорт в другие систем
• Использование хранилища как ODS
Отчеты и анализ

27. • Постановка цели
• Разбиение на этапы
• Проектирование хранилища
• Модель данных
• Проектирование и разработка ETL
• Первоначальная загрузка
• Периодическая загрузка
• Построение отчетов
• Приложения OLAP анализа
Этапы проекта реализации хранилища данных

28. • Доступ к информации
• Команда внедрения
• Пилотный проект
• Сложности проектирования
• Эксплуатация и опровождение
Аспекты успешности проектов построения хранилища данных

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

30. Подходы к внедрению ХД
▪«Большой взрыв»
▪Сверху вниз
–от бизнес требований к модели данным и извлечении
данных из источников
▪Снизу вверх
–от имеющихся данных к модели данных,
далее к бизнес отчетам и анализу данных

31. ▪Проектирование хранилищ данных есть прикладная наука по
процессам реструктуризации и интеграции гетерогенных
множественных систем хранения данных
▪Четко определить цели построения
–Решение определенных задач
▪Хранилище должно быть гибким
–по мере развития бизнеса задачи меняются
–должно учитываться возможное расширение бизнеса
Постановка цели

32. • Насколько экстенсивным будет хранилище?
• Будут ли покрыты все измерения корпоративных данных?
• Будут ли удовлетворены требования системы принятия
решений к данным?
• Будет ли хранилище масшатабиуемым и устойчивым? Будет
ли оно отвечать будущим нуждам организации?
Тестовая стратегия

33. • Анализ предметной области и существующей инфраструктуры и
данных
• Проектирование самого хранилища
• Загрузка в него информации
• Наладка ежедневных процедур наполнения
• Эксплуатация и внедрение изменений
• Каждый этап должен завершаться
тестированием
Разбиение на этапы

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

35. • Анализ НСИ и ее упорядочение
• Бизнес-анализ процессов и данных предприятия
▫создание единого информационного пространства
• Метаданные
• Отраслевые модели данных
▫переработка под потребности заказчика
• Тесное сотрудничество с заказчиком
• Целостность данных
Модель данных

36. • Разные системы в разных отделах
• Анализ разрозненных данных
• Выбор и очистка нужных данных
• Системы проверки качества данных
Проектирование и разработка ETL – гетерогенность источников

37. • Дополнительная настройка правил,
• Очистка данных в системах источниках
• Изменения в процессах
• Алгоритмы выверки и унификации данных
• Тестирование загрузки и проверки данных
▫гарантировать корректность после любых изменений,
настроек или для новых типов данных
▫проверить полноту, однозначность и корректность данных
после всех преобразований и очисток
Первоначальная загрузка

38. • Определить периоды сбора, загрузки и обработки данных из
различных источников
• Технологические окна
• Требования к каналам передачи данных
• Распределение нагрузки
• Тестирование параметров
▫Функциональное
▫Нагрузочное (максимальный объем данных)
▫Проверка метаданных и справочников
Периодическая (инкрементальная) загрузка

39. Внешние (для регулирующих органов)
▪Иногда в готовом виде
Внутрикорпоративные
Поэтапное внедрение
▪По подразделениям
▪По приоритетам
Тестирование отчетности
▪Соответствие витринам
▪Соответствие требованиям по данным и формам
▪Производительность
Построение отчетов

40. • Бизнес-аналитикам, сотрудникам управления рисками,
менеджерам нужна информация в своем виде, формате, с
возможностью увидеть картинку в целом или погрузится в
детали, посмотреть историю не несколько лет или увидеть
очень важный срез именно на текущий момент,
поманипулировать данными
Приложения OLAP анализа

41. • Данные для анализа:
▪Только из витрин
▪Из витрин и хранилища
▪Из хранилища и источников
• Разграничение доступа
• Ручной доступ
• Тестирование ограничений доступа и функционирования
приложений анализа
Доступ к информации

42. • Чрезвычайно важна команда внедрения
• Со стороны поставщиков и заказчиков
• Выбор разработчика хранилища данных
• Диалог с заказчиком
• Взаимодействие с ИТ-командой
Команда внедрения

43. • Упрощение задачи построения хранилища
▫для одного отдела
• Соблюдение баланса
▫мета данные для всего бизнеса
▫в связи с данными других отделов
• Изменения в пилотном проекте
• Выработка стандартных решений и их повторение в дальнейшем
• Тестирование пилотного проекта
Пилотный проект

44. • Большие объемы данных
• Сложность
• «Широта» предметной области, применяемых методик анализа
• Многочисленные системы-источники
• Организационная перестройка предприятия
• Возможно и изменения в бизнес-процессах
• Потребность в новой категории высококвалифицированных
специалистов
• Аналитическая группа и обучение пользователей, во главе с топ
менеджерами
Сложности проектирования

45. Завершение работ и сдача в эксплуатацию
Стадию постоянного развития
▪бизнес развивается
▪растут и изменяются требования
▪улучшаются процедуры выборки и подготовки данных
Итеративное тестирование изменений и регресса для
каждых изменений
Эксплуатация и сопровождение

46. Данных и отчетов становится всё больше
Некорректность исходных данных
Рост использования, нехватка ресурсов
▪оптимизация данных и операций
▪создание большего количества агрегатов
▪тиражирование данных на несколько серверов
Резервное копирование хранилища
Финансовые затраты
Тестирование доработок
Проблемы развития хранилища данных на предприятии

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

48. Управление релизами ХД
Охват
▪Компоненты ХД
▪Системы источники
– Синхронизация
Процессы
▪Планирование релизов
▪Управление конфигурацией
▪Коммуникации, документооборот
▪Координация разработок
▪Развертывание
▪Управление качеством, Тестирование

49. Алексей
Теренин
Спасибо за внимание
Ваши вопросы

50.  Более 17 лет в управлении ИТ в банковской сфере
 Проекты внедрения Хранилищ данных в нескольких банках
 Руководил различными группами IT-специалистов на всех
стадиях создания ПО, организовывал отделы «с нуля»
 Работал в крупнейших российских и иностранных компаниях,
участвовал во внедрении стандартов качества
Six Sigma, ISO 9000, CMMi
Об авторе: Алексей Теренин

51.  Внедрял новые технологии в ИТ и инструменты поддержки процессов
разработки и внедрения, разработал и читает авторские курсы по
тестированию и другим дисциплинам.
 Собственные исследования в области развития методов повышения
качества ПО, метрик и техник тестирования, разработки ПО, и проектного
управления
 Экономика, финансы, банковские технологии,
 В 2004 г. получил степень к.т.н.
 Около 100 публикаций, участие в
телевизионных программах
и конференциях
 AATerenin.SBT@sberbank.ru
Об авторе: Алексей Теренин