Ознакомительная версия. Доступно 19 страниц из 92
формой моделирования процессов и побудить ее исследовать.
Задача данной главы – дать базовое, интуитивно понятное объяснение одного из элементов бизнес-аналитики: размерного моделирования.
Размерное моделирование является логическим подходом к проектированию физических витрин данных. Витрины данных, в свою очередь, представляют собой специфические структуры, которые могут быть соединены вместе через измерения, как детали конструктора лего. Таким образом, они хорошо вписываются в область метрик операционной безопасности.
Рис. 11.1 – это схема, что используется для размерного моделирования в большинстве случаев, ее обычно называют «кубом» трех ключевых измерений: времени, ценности и риска. Такую форму принимают почти все метрики операционной безопасности, и фактически единственное, что меняется в зависимости от области, это конкретный изучаемый риск. Время и ценность оказываются согласованной соединительной тканью, позволяющей измерять (т. е. прорабатывать) все области риска. Помните, что это лишь краткий обзор размерного моделирования. Нам хотелось бы надеяться, что размерные подходы к метрикам безопасности со временем будут развиваться. Сейчас, когда идет рост больших данных и соответствующих аналитических приложений, самое подходящее время.
Рис. 11.1. Стандартная витрина данных безопасности
Решение проблем, связанных с БА
При упоминании БА многие читатели наверняка представляют себе раздутые хранилища данных со сложными ETL-системами (извлечение, преобразование и загрузка). И действительно, для осуществления процессов ETL и даже визуализации требуется немало времени. Причина этой проблемы в сложности инфраструктуры нижележащей реляционной базы данных, а также особенностях формирования результатов анализа. В части инфраструктуры проблема более или менее решаема: многие облачные провайдеры предлагают средства для работы с большими данными. Например, у таких компаний, как Amazon, Google и Microsoft, есть зрелые продукты для масштабируемых облачных баз данных. Даже редактор Excel явно стал мощнее, так как способен увеличивать объем до миллиардов строк записей с помощью надстройки PowerPivot.
Если не хочется зависеть от какого-то одного поставщика, воспользуйтесь решениями с открытым исходным кодом, скажем, Apache Drill предоставляет унифицированный интерфейс на языке SQL (язык структурированных запросов) для большинства хранилищ данных, в том числе баз данных NoSQL, различных типов файлов (CSV, JSON, XML и т. д.), а также коннекторы Open Database Connectivity для устаревших баз данных (включая Excel). Идея заключается в том, чтобы полностью убрать для конечных пользователей аналитические барьеры, вызванные сложностью ETL-систем. Подобный процесс наблюдался более десяти лет назад в области визуализации данных. Инструменты визуализации значительно ослабили барьер, мешавший конечным пользователям проводить анализ. Но для этого, безусловно, должен иметься правильно сформированный и понятный источник данных. К сожалению, последние достижения в области создания баз данных, такие как Hadoop и NoSQL-системы, не смогли значительно продвинуться в решении этой проблемы. Собственно говоря, сложность доступа к данным только возросла. Но постепенно тот же самый «беспроблемный» подход, применявшийся в визуализации, реализуется и в области доступа к данным. В общем, технические барьеры, связанные с размером, скоростью и интерфейсом, полностью стираются. Что остается после решения технических вопросов? Логическое формулирование проблем анализа и выбор правильных подходов для их решения.
В отношении аналитического подхода также существуют свои предубеждения. Возможно, вам встречалось такое: «БА – это все равно, что пытаться вести бизнес вперед, глядя в зеркало заднего вида». Еще можно услышать, что «Бизнес-аналитика мертва!». Но это все равно, что сказать «Описательная аналитика мертва!» или «Изучение явлений с помощью данных за прошлые периоды мертво!». Что мертво или должно быть мертвым, так это бестолковые, трудоемкие подходы к аналитике, не имеющие стратегической ценности. Те, кто делает подобные заявления, просто подвержены заблуждению «обогнать медведя», или Еxsupero Ursus, упоминавшемуся в главе 5. Разумеется, вся прогностическая аналитика опирается на события, произошедшие в прошлом, что позволяет прогнозировать будущее! Проще говоря, когда дело доходит до наблюдаемых фактов, составляющих прогностическую модель, всегда существует некоторая задержка. Мы даже видим решения потоковой аналитики, где создаются микрокубы (мини-витрины данных) в памяти. Это волнующее время для бизнес-аналитики!
Теперь, когда вроде бы разрушены все предрассудки, связанные с противопоставлением БА, больших данных, NoSQL и прогностической аналитики, можно перейти к сути данной главы – определению эффективности взаимодействия вложений в безопасность с помощью размерного моделирования.
Только факты. Что такое размерное моделирование и зачем оно мне нужно?
Когда вы задаете размерные вопросы о фактах прошлого, которые позволяют как обобщать, так и детализировать до элементарных событий, вы проводите БА. Метатребование обычно подразумевает последовательность данных, а значит, моделируемая проблема требует определенной согласованности с точки зрения временных рядов: день за днем, месяц за месяцем и т. д. Далеко не все задачи, для решения которых применяется моделирование, нуждаются в подобной согласованности временных рядов. Метрики же безопасности измеряют операционные процессы и потому должны быть согласованны, поэтому они идеально подходят для БА. Так вот, когда вы применяете полученные сведения о фактах прошлого, чтобы смоделировать или спрогнозировать, какую форму данные примут в будущем, вы по-настоящему занимаетесь прогностической аналитикой или, как мы любим ее называть, «статистикой». Однако в основе источника прогнозов лежала БА, а ее технологией проектирования является размерное моделирование.
Размерное моделирование представляет собой логический процесс проектирования с целью получения витрин данных. Оно имеет дело с двумя макрообъектами: фактами и измерениями. Совокупность измерений, окружающая список фактов, – это и есть витрина данных. На рис. 11.2 показана простая логическая витрина данных для уязвимостей. Обратите внимание, что она построена по схеме, представленной на рис. 11.1. Уязвимость в данном случае соответствует конкретному измерению риска. Активы – измерению ценности, при этом под ценностью понимается то, что следует защищать. И остается измерение даты или времени, присутствующее почти во всех моделях.
В центре размерных таблиц находится так называемая таблица фактов, которая содержит указатели на таблицы измерений и может насчитывать миллионы или даже миллиарды строк. Если ваше измерение активов составляет сотни тысяч, а то и миллионы строк (одному из авторов доводилось моделировать подобный вариант), то в таблице фактов их точно будут миллиарды. Здесь чистая математика: на один актив может приходиться N уязвимостей, существующих в определенный момент времени. Также обратите внимание, что прозвучало
Ознакомительная версия. Доступно 19 страниц из 92
