При упоминании БА многие читатели наверняка представляют себе раздутые хранилища данных со сложными 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 и прогностической аналитики, можно перейти к сути данной главы – определению эффективности взаимодействия вложений в безопасность с помощью размерного моделирования.
Только факты. Что такое размерное моделирование и зачем оно мне нужно?
Когда вы задаете