Сегодня термин «data-driven» знаком практически всем. Это уже не просто модное слово, а важная часть стратегии развития многих компаний. Быть «data-driven» означает использовать данные для принятия решений. Вдохновлённые успехом X5 Retail, Ozon и Яндекс, руководители стремятся сделать свои компании ориентированными на данные, внедряют аналитику данных и искусственный интеллект.
Возможно, прямо сейчас ваш руководитель под впечатлением от очередной корпоративной программы, отчёта консультантов или подкаста про генеративный ИИ продумывает план трансформации компании (или хотя бы своего подразделения). А может быть, вы и есть тот самый руководитель или собственник компании.
В этой статье мы рассмотрим, как используется аналитика данных, ключевые аспекты архитектуры и современные технологии, а также дадим практические советы по внедрению.
Перспективы трансформации и типовые проблемы на пути
Сегодня данные собираются постоянно: при каждой покупке, рейсе, просмотре рекламы и постов в социальных сетях. Это делает данные более доступными. Однако многие компании, имея доступ к огромному количеству данных, не могут эффективно их использовать.
Почему это происходит? Основная причина в том, что данные часто не подготовлены для анализа. Они могут быть неструктурированными, несвязанными, неполными или содержать ошибки. Данные почти всегда нуждаются в обогащении — дополнении информацией и преобразовании в удобный для анализа формат. Более того, интеграция данных из различных источников требует значительных усилий и специальных навыков, что приводит к задержкам и ошибкам в обработке. Кроме подготовки и интеграции данных, компании должны уметь их анализировать и делать прогнозы. Это требует использования продвинутых аналитических инструментов и методов, а также привлечения специалистов, способных интерпретировать результаты.
Какие сложности возникают на практике? Многие команды используют десятки систем и инструментов, таких как CRM-системы, базы данных, рекламные платформы, аналитические инструменты, системы управления проектами и платформы для автоматизации маркетинга. Однако ни один из этих инструментов не может легко взаимодействовать с другими без настройки силами квалифицированных ИТ-специалистов.
К чему это приводит? В результате подразделения часто просто копируют и вставляют данные из одной электронной таблицы в другую или используют инструменты для автоматизации этих процессов. К сожалению, это реальность для многих бизнес-команд. Они вынуждены использовать устаревшие методы для создания отчётов или получения сводной информации.
Какие есть варианты решения? Чтобы воспользоваться всеми возможностями аналитики данных, необходимо создать соответствующую архитектуру. Построение такой архитектуры — сложный процесс, включающий как технические, так и организационные аспекты.
Что мешает успешной реализации? Компании тратят много времени и денег на разработку детальных планов внедрения ИТ-решений, анализ технологий и поиск поставщиков. Эти планы часто устаревают ещё до начала их реализации. Когда компании наконец готовы приступить к проекту, они сталкиваются с трудностями. В итоге руководители и акционеры начинают сомневаться в ценности всей этой затеи с аналитикой данных, и всё возвращается к копированию и вставке данных, экспорту в Excel и пересылке друг другу разрозненных табличек.
Или другая крайность: многие компании начинают внедрение дата-аналитики совсем без плана и без стратегии. В результате усилия часто заканчиваются небольшими пилотными проектами, которые не масштабируются и не приносят существенного эффекта. Некоторые из этих пилотных проектов — скорее упражнения во «внедрении инноваций», чем попытки изменить бизнес. Они не учитывают условия для внедрения и проводятся в отдельных подразделениях департаментов по цифровизации с ограниченной связью с бизнесом. Даже если пилот отвечает на правильные вопросы, он может не учитывать организационные аспекты, которые, например, убедили бы руководителя отдела продаж доверять модели больше, чем собственному опыту.
Что показывает практика? Наш опыт работы с клиентами — от небольших до крупных компаний — показывает, что правильное использование данных может значительно повлиять на бизнес. Давайте разберёмся, что нужно сделать для внедрения аналитики данных.
Что такое принятие решений на основании данных?
Все обсуждаемые далее аспекты будут сосредоточены на трёх основных элементах аналитики данных: данных, анализе и действиях.
Данные, собранные из различных источников. Для качественного анализа данные должны быть точными, полными и актуальными. Качество данных напрямую влияет на надёжность и полезность выводов, которые можно получить в дальнейшем.
Анализ — это процесс преобразования данных в полезную информацию. Включает в себя применение различных методов и технологий, таких как статистический анализ, машинное обучение и визуализация данных. Цель анализа — скрытые закономерности, тенденции и отношения в данных, которые могут помочь в понимании процессов и прогнозирование событий. Полученные в результате анализа выводы и рекомендации можно использовать для принятия стратегических и оперативных решений.
Действие — это применение выводов, полученных в результате анализа. На этом этапе результаты анализа применяются на практике для улучшения бизнес-процессов, повышения эффективности и достижения целей. Действия могут включать оптимизацию операций, изменения стратегий и улучшение обслуживания клиентов.
Все три элемента одинаково важны. Data-driven компании не только собирают и анализируют данные, но и действуют на основании полученных выводов. Сотрудники получают доступ ко всей необходимой информации, что позволяет им тратить меньше времени на сбор данных и больше — на принятие решений и их реализацию. Руководители используют результаты анализа данных как в оперативном управлении, так и в стратегическом планировании.
Принятие решений на основании данных (Data-Driven Decision Making)
Прежде чем начать, давайте определимся, что такое принятие решений на основании данных (Data-Driven Decision Making, DDDM). Это процесс, при котором решения принимаются на основе анализа и интерпретации данных. DDDM состоит из шести шагов, каждый из которых фокусируется на данных, анализе или действиях.
Жизненный цикл данных
Жизненный цикл данных описывает путь, который проходят данные с момента их создания до превращения в практические выводы. Жизненный цикл данных можно разделить на восемь этапов: генерация данных, сбор, обработка, хранение, управление, анализ, визуализация и интерпретация.
Этапы работы с данными описываются как цикл, потому что результаты и выводы, полученные в одном проекте, обычно используются в следующих. Последний этап интерпретации возвращается к начальному этапу генерации, позволяя циклу начинаться заново, с уточнёнными целями и накопленными знаниями.
4 типа аналитики данных
Существует четыре основных типа аналитики данных, каждый из которых служит различным целям в зависимости от задачи и имеющихся данных.
1. Описательная аналитика
Описательная аналитика использует данные для изучения, понимания и описания того, что уже произошло. Отвечает на вопросы «что произошло?» и помогает создать общее представление о прошлом, предоставляя отчёты и визуализации.
2. Диагностическая аналитика
Диагностическая аналитика помогает понять, «почему» произошло то, что произошло. Этот вид аналитики анализирует причины и взаимосвязи событий, позволяя выявить основные факторы и причины происходящего. Это помогает понять не только результат, но и его предпосылки.
3. Предиктивная аналитика
Предиктивная аналитика опирается на исторические данные, прошлые тенденции и предположения, чтобы ответить на вопросы о том, что произойдёт в будущем. Используя статистические модели и машинное обучение, она помогает прогнозировать события и тренды.
4. Предписывающая аналитика
Предписывающая аналитика определяет конкретные действия, которые следует предпринять для достижения целей. Этот вид аналитики предлагает решения для достижения желаемых результатов, используя алгоритмы оптимизации и рекомендации.
Как применяется аналитика данных в бизнесе
Стоит ли инвестировать в аналитику данных? Ответ на этот вопрос всё чаще становится положительным. Аналитика данных помогает повысить рентабельность инвестиций в двух ключевых областях: увеличении доходов и снижении затрат. Поэтому инвестиции в аналитику данных приводят к измеримым улучшениям бизнес-показателей и становятся все более экономически обоснованными. В McKinsey подсчитали, что компании, внедрившие аналитику данных, повысили EBITDA на 15-25% за счёт роста продаж и повышения маржинальности.
Использование аналитики данных позволяет компаниям увеличивать продажи, выявлять новые рыночные тенденции и возможности для запуска новых продуктов, прогнозировать финансовые показатели и лучше понимать факторы, влияющие на бизнес.
1. Увеличение продаж с помощью аналитики данных
Компании внедряют аналитику для повышения эффективности маркетинга и продаж. Данные играют ключевую роль в различных проектах и процессах, ориентированных на клиента. Рассмотрим, как именно аналитика помогает в этом направлении.
1.1. Таргетированный маркетинг. Анализ данных о клиентах позволяет создавать персонализированные маркетинговые кампании. Учитывая текущие и исторические данные, можно сегментировать клиентов и предлагать им наиболее интересные продукты и услуги.
1.2. Оптимизация ассортимента. Данные о продажах и предпочтениях клиентов помогают оптимизировать ассортимент товаров. Анализ исторических данных позволяет определить наиболее востребованные товары и своевременно корректировать ассортимент, чтобы удовлетворить потребности клиентов.
1.3. Прогнозирование спроса. Предиктивная аналитика, основанная на исторических данных, помогает прогнозировать спрос. Это позволяет избежать дефицита товаров и улучшить управление запасами, что ведёт к снижению затрат и увеличению продаж. Понимая ключевые показатели, такие как коэффициент конверсии потенциальных клиентов, маркетолог-аналитик может определить количество потенциальных клиентов, которые должны быть привлечены его усилиями для увеличения объёма продаж.
2. Выявление инновационных возможностей с помощью аналитики данных
2.1. Анализ рыночных тенденций. Сбор и анализ данных о рынке помогают выявить новые тренды и потребности. Это позволяет разрабатывать новые продукты и услуги, соответствующие текущим рыночным условиям. Например, отслеживание предпочтений потребителей и изменения их поведения помогает компаниям оставаться на шаг впереди конкурентов.
2.2. Изучение конкурентов. Анализ данных о конкурентах выявляет их сильные и слабые стороны, стимулирует инновации и улучшает предложения компании. Например, сравнение цен, ассортимент, оценка эффективности рекламных кампаний и анализ отзывов клиентов помогают оптимизировать собственные стратегии и улучшить конкурентоспособность.
2.3. Внутренние исследования и разработки. Данные о внутренних процессах и клиентских отзывах могут подсказать направления для исследований и разработок. Понимая, как клиенты реагировали на особенности продукта в прошлом, аналитика может помочь в разработке продукта, дизайне и улучшении взаимодействия с пользователями в будущем. Предиктивная аналитика помогает прогнозировать, какие новые продукты смогут стать успешными, что позволяет фокусироваться только на разработках с наибольшим потенциалом.
3. Управление рисками
Понимая вероятность возникновения определённых бизнес-рисков и связанных с ними расходов аналитик может дать экономически целесообразные рекомендации по их устранению.
4. Прогнозирование финансовых показателей
3.1. Финансовое планирование и бюджетирование. Анализ исторических данных о доходах и расходах помогает создавать точные бюджеты и финансовые планы, основанные на анализе прошлых данных.
3.2. Анализ затрат. Анализ текущих и исторических данных о затратах на производство, маркетинг и другие операции позволяет выявить области для снижения расходов.
3.3. Понимание доходности продуктов и услуг. Анализ данных помогает определить наиболее прибыльные продукты и услуги, что позволяет сосредоточиться на их развитии.
3.4. Управление денежными потоками. Анализ данных о движении денежных средств помогает оптимизировать управление денежными потоками.
3.5. Прогнозирование финансовых показателей и понимание факторов, влияющих на финансы.
Как организована дата-аналитика в компании?
Как любят говорить консультанты: «It depends…»
Практики постоянно обсуждают, должна ли аналитика быть централизованной функцией или распределённой между различными подразделениями и регионами.
Централизованная модель. Аналитика управляется одним центральным подразделением, например, под руководством CDO (Chief Data Officer) или руководителем подразделения отчётности. Это помогает стандартизировать процессы и повысить качество данных.
Децентрализованная модель. Каждое подразделение имеет свои аналитические команды, которые подчиняются руководителям этих подразделений, например, финансовому директору или директору по маркетингу. Это позволяет лучше адаптироваться к потребностям каждого подразделения.
Гибридная модель. Сочетает элементы обеих моделей — объединяет централизованное аналитическое подразделение со встроенными аналитическими командами в некоторых подразделениях.
Кто отвечает за аналитику данных
В компаниях аналитикой могут заниматься разные руководители.
- Генеральный директор. Видит общую картину и может инициировать крупные проекты и обеспечивать необходимые ресурсы для их реализации.
- Финансовый директор. Занимается финансовым анализом, бюджетированием и прогнозированием, улучшая финансовые показатели и управляя затратами.
- Директор по маркетингу. Использует аналитику для таргетированного маркетинга, изучения предпочтений клиентов, анализа конкурентов и оптимизации маркетинговых кампаний. Часто отвечает за аналитику, так как маркетинговые стратегии требуют глубокого понимания клиентских данных и рыночных тенденций.
- Директор по работе с данными и аналитике (CDAO — Chief Data and Analytics Officer). Координирует работу аналитических команд, разрабатывает политику работы с данными и следит за их качеством и безопасностью. Эта должность может называться по-разному: Сhief Data Officer, Chief Analytics Officer, Руководитель подразделения данных и аналитики и так далее.
- ИТ-директор. Обеспечивает ИТ-инфраструктуру и технологии для аналитики, внедряет аналитические платформы и следит за безопасностью данных. Управление данными и технологическими платформами является его основной компетенцией. Из минусов такое организации обычно отмечают, что ИТ—специалисты, которые привыкли управлять долгосрочными проектами, могут оказаться не готовы к управлению краткосрочными, гибкими проектами по поддержке клиентов. Проекты по поддержке клиентов могут оказаться последними в списке их приоритетов.
- Другие руководители. Внедряют аналитику в свои области и бизнес-процессы. Руководители бизнес-единиц используют аналитику для решения специфических задач своих подразделений. Это часто бывает оправданно, так как они лучше всех понимают потребности и задачи своих отделов и могут эффективно применять аналитику для их решения. Из минусов обычно отмечают то, что такая организация может ограничить потенциал по преобразованию остальных подразделений.
- Иногда за аналитику не отвечает кто-то один. В таких случаях ответственность делят между подразделениями или специализированными подразделениями.
Многие консалтинговые компании делают опросы и исследования по тому, кто отвечает за аналитику данных в компаниях. Пример одного такого исследования от Deloitte приведён ниже.
Как устроены команды аналитики данных
Роли в команде аналитики данных
Чтобы эффективно использовать данные, нужны различные специалисты. Дата-сайентисты анализируют большие объёмы данных и разрабатывают алгоритмы и модели для выявления скрытых закономерностей и тенденций. Инженеры данных отвечают за создание и поддержание систем хранения и обработки данных, обеспечивая их доступность и качество. Аналитики данных работают с уже подготовленными данными, разрабатывают отчёты и визуализации для поддержки принятия решений.
Также важно определиться, кто несёт ответственность за хранение, защиту и интерпретацию различных наборов данных (эта роль часто называется data owner). В крупных компаниях есть менеджеры данных, координирующие работу команды и разрабатывающие стратегии управления данными, дата-стюарды (data stewards), которые следят за качеством данных и управляют метаданными, и многие другие роли.
Организация команд аналитики данных
Команды могут быть организованы по-разному. В централизованной модели одна команда обслуживает всю компанию, что упрощает управление данными и стандартизацию процессов. В децентрализованной модели каждое подразделение имеет свою команду аналитиков, что обеспечивает гибкость и оперативность, но может привести к несогласованности данных. Гибридная модель сочетает преимущества обеих систем: центральная команда координирует работу и обеспечивает соответствие стандартам, а подразделения сохраняют своих аналитиков для решения специализированных задач.
Стратегия работы с данными
Стратегия работы с данными зависит от целей компании. Если данные используются для всех бизнес-решений, необходима большая и хорошо оснащённая команда. Если данные важны только для стратегических решений, команда может быть меньше и более специализированной. Выбор подхода определяется бизнес-целями и масштабом операций компании.
Эволюция архитектуры аналитики данных
- До 2000 года: время корпоративных хранилищ данных (EDW — Enterprise Data Warehouse)
Компании использовали корпоративные хранилища данных для централизованного хранения структурированных данных. Все данные хранились в одном месте, что обеспечивало структурированный подход к управлению данными. - 2000-2010 годы: время после корпоративных хранилищ данных
Анализ данных был фрагментированным. Компании использовали витрины данных, которые зависели от основного хранилища данных. Это привело к созданию изолированных хранилищ и несогласованному анализу данных. Разные подразделения компании могли иметь свои версии данных, что затрудняло получение единого правильного ответа. - 2010-2020 годы: время логических хранилищ данных (LDW)
В этот период компании начали использовать более унифицированный подход к анализу данных. Был создан общий семантический слой, который позволял объединять данные из различных источников: хранилищ данных, витрин данных и озёр данных. Это обеспечивало более согласованный и точный анализ данных. - С 2020 года и далее: время активных метаданных
Будущее аналитики данных связано с использованием всех доступных данных с использованием аналитических инструментов и рекомендательных систем. Метаданные играют ключевую роль, помогают автоматизировать процессы анализа данных и предоставлять выводы в режиме реального времени.
Демократизация доступа к данным и аналитика самообслуживания (self-service analytics)
Доминирующая сегодня тенденция — это упрощение доступа к данным для всех пользователей в компании. Это позволяет аналитикам, инженерам и другим сотрудникам самостоятельно работать с данными без необходимости обращаться к ИТ-подразделениям. Руководители по данным и аналитике стремятся расширить использование данных, включая управление мастер-данными, обмен данными между разными компаниями и интеграцию данных B2B.
Что такое метаданные и какую роль они играют в этой эволюции?
Метаданные — это информация о данных, которая описывает их различные аспекты, такие как контекст и происхождение. Они создаются как побочный продукт, когда данные проходят через различные системы компании. Существует четыре типа метаданных: технические, операционные, бизнес-метаданные и социальные. Метаданные могут быть пассивными (собираются, но не используются) или активными (используются для идентификации действий между двумя или более системами, использующими одни и те же данные, и для автоматизации процессов). 
2 современных подхода к построению архитектуры аналитики данных: Data Fabric и Data Mesh
Gartner видит два пути для перехода от логических хранилищ данных (LDW) к периоду активных метаданных. Эти два подхода — это Data Fabric и Data Mesh. Оба подхода нацелены на упрощение доступа к данным для всех пользователей.
Data Fabric — это централизованная платформа, которая оптимизирует управление данными, используя метаданные. Она объединяет доступ к данным, их преобразование и управление в единую систему, обеспечивает возможность работы с данными независимо от их местоположения.
Data Mesh, наоборот, предлагает децентрализованный подход. Специализированные команды управляют своими данными как продуктами. Каждая команда работает независимо в рамках общей структуры, отвечает за качество и доступность своих данных.
Теперь рассмотрим, как эти подходы различаются с точки зрения архитектуры.
Data Fabric
- Централизованная архитектура: вся инфраструктура управления данными централизована, что позволяет обеспечить единое управление данными.
- Унифицированное управление: предоставляет общий слой управления для всех данных, улучшая согласованность и контроль.
- Гибкость интеграции: поддерживает интеграцию с различными источниками данных через общую платформу.
Data Fabric является естественной эволюцией для многих компаний, переходящих от моделей логического хранилища данных (LDW). Эта концепция использует существующие технологии и метаданные. При переходе к Data Fabric не требуется полностью заменять существующие системы.
Data Mesh
- Децентрализованная архитектура: данные распределены по доменам, где каждая команда или бизнес-линия несёт ответственность за свои данные.
- Автономное управление: команды управляют своими данными независимо, что позволяет им быстрее реагировать на изменения и не зависеть от централизованного ИТ-подразделения.
- Данные как продукт: каждая команда или бизнес-линия рассматривает данные как продукт.
Хотя эти подходы могут казаться конкурирующими, на самом деле они дополняют друг друга, обеспечивают более простой доступ к данным.
Какая архитектура нужна для того, чтобы организовать процесс принятия решения на основании данных?
Для организации процесса принятия решений на основании данных необходима продуманная архитектура данных. Архитектура данных состоит из инструментов и процессов, которые позволяют работать с данными и анализировать их. Эти элементы могут включать в себя разные виды локального и облачного оборудования и программного обеспечения.
Важно определить, какие наборы данных есть в бизнес—подразделениях компании. Для анализа данных сначала необходимо сохранить их в едином хранилище, таком как хранилище данных или озеро данных. Скорее всего вы захотите интегрировать или преобразовать их, чтобы представить в формате, который лучше подходит для анализа. Для этого нужны конвейеры данных, они позволяют получать необработанные данные из разных источников, преобразовывать и сохранять их в месте назначения для последующего хранения и анализа.
Универсальной инструкции к проектированию архитектуры данных нет, но есть несколько общих слоёв, каждый из которых играет важную роль.
1. Генерация данных
Производителями данных являются пользователи, системы и устройства. Они генерируют данные через различные системы и приложения, датчики в оборудовании или системы управления.
2. Источники данных
Данные могут поступать из внутренних и внешних источников. Внутренние данные собираются внутри компании, например, данные о продажах. Внешние данные могут быть получены из рыночных исследований и других внешних источников.
3. Сбор данных
Сбор данных может происходить непрерывно (в реальном времени) или периодически (пакетами). Для этого используются процессы ETL (Extract, Transform, Load) и ELT (Extract, Load, Transform). В ETL данные извлекаются, преобразуются и загружаются в хранилище данных. В ELT данные извлекаются, загружаются в хранилище и затем преобразуются. Для поддержки и оркестрации этих процессов используются конвейеры данных, такие как Talend, Informatica, Apache Airflow, Apache NiFi, Epsilon Workflow, Fivetran и Stitch.
4. Хранение данных
Данные могут храниться в хранилище данных (Data Warehouse), озере данных (Data Lake) или Lakehouse. Data Warehouse оптимизировано для хранения структурированных данных (например, Amazon Redshift, Google BigQuery, Snowflake). Data Lake подходит для хранения структурированных, полуструктурированных и неструктурированных данных (например, Amazon S3, Azure Data Lake).
5. Интеграция данных
Данные из разных источников объединяются и подготавливаются для анализа с помощью различных сервисов, конвейеров данных и API. Примеры инструментов включают Apache NiFi для потоковой интеграции данных, MuleSoft и Zapier для интеграции через API, а также службы ETL/ELT, такие как Fivetran и Stitch. Инструменты, такие как Alteryx, Apache Airflow, Epsilon Workflow, помогают объединять данные из различных источников, преобразовывать их для анализа и автоматизировать рабочие процессы интеграции данных.
6. Аналитика данных
На этом этапе данные анализируются с использованием различных инструментов и методов. Примеры включают платформы для машинного обучения и анализа данных, такие как Apache Spark, DataRobot и TensorFlow, а также инструменты для подготовки данных и создания моделей машинного обучения, такие как Epsilon Workflow и Alteryx. BI-инструменты, такие как Visiology, Tableau и Power BI, используются для визуализации данных и создания отчётов, геоаналитические решения, такие как Epsilon Metrics или Epsilon On Point — для анализа геоданных и разработки интерактивных карт.
7. Доступ к данным
Специализированные аналитические приложения и дашборды обеспечивают удобный доступ к данным и результатам анализа. Alteryx и Epsilon Workflow позволяют в no-code интерфейсе разрабатывать и автоматизировать рабочие процессы, облегчая доступ к данным и их использование.
8. Потребители данных
Потребителями данных являются сотрудники компании, системы или устройства, принимающие решения на основе данных. Примеры включают в себя маркетинговые команды, использующие данные для таргетированных рекламных кампаний, финансовые отделы, анализирующие данные для отчётов и прогнозов, и системы автоматизации, принимающие решения в реальном времени (например, рекомендации товаров на Amazon).
9. Основные элементы поддержки архитектуры
9.1. Управление данными (Data Governance)
Data Governance включает в себя разработку и внедрение политик, процедур и стандартов для обеспечения качества, целостности и безопасности данных. Инструменты управления данными, такие как каталоги данных и бизнес-глоссарии, помогают управлять данными и обеспечивать их соответствие нормативным требованиям.
Каталог данных (data catalog) — это инструмент, используемый для организации, управления и поиска данных в компании. В нём хранятся метаданные. Каталоги данных позволяют специалистам по обработке данных понимать, с какими данными можно работать, откуда эти данные берутся и как их можно использовать. Каталог данных можно разработать самостоятельно или использовать коммерческие решения или решения с открытым исходным кодом. Посмотреть примеры каталогов данных решений можно здесь, отечественное решение Arenadata Data Catalog — описано здесь. Ссылка на выступление Анастасии Ожигиной о каталоге данных в T-Банке — здесь.
9.2. Безопасность
Безопасность включает меры защиты данных от несанкционированного доступа, утечек и других угроз. Системы управления доступом и идентификацией, такие как AWS IAM, Azure Active Directory и Google Cloud IAM, обеспечивают контроль доступа к данным и управление разрешениями.
9.3. Управление жизненным циклом данных
Процессы управления данными на всех этапах их существования — от генерации и сбора до архивирования и удаления. Инструменты, такие как Apache Atlas, Veritas и Commvault, помогают автоматизировать и контролировать эти процессы.
9.4. Инфраструктура
Технические компоненты обеспечивают работу всей системы. Это облачные платформы для хранения и обработки данных и локальные серверы и оборудование.
9.6. Доступ пользователей к данным
Системы контроля доступа обеспечивают безопасность данных и ограничивают доступ в зависимости от роли пользователя.
9.7. Контроль и мониторинг
Инструменты для мониторинга качества данных и эффективности аналитических процессов (Data Quality Monitoring и Performance Monitoring), помогают отслеживать и улучшать качество данных и производительность аналитических систем.
Ключевые изменения в архитектуре аналитики данных
Архитектура аналитики данных претерпевает значительные изменения, позволяя компаниям более эффективно использовать данные для принятия решений.
McKinsey выделили 6 ключевых изменений в архитектуре данных. Они затрагивают практически все операции с данными, включая сбор, обработку, хранение, анализ и предоставление результатов анализа.
Изменение 1. Переход от локальных платформ к облачным решениям
Во-первых, модель Infrastructure as a Service (IaaS) предлагает эластичное масштабирование. Это позволяет компаниям быстро увеличивать или уменьшать объём ресурсов в зависимости от потребностей, оплачивая только фактически используемые ресурсы, снижать затраты на поддержку инфраструктуры.
Во-вторых, облачные решения предоставляют S3-совместимые объектные хранилища данных и системы управления базами данных (СУБД). Примеры включают в себя Yandex Object Storage, VK Cloud Storage, Object Storage Service от Сбер Cloud и Google Cloud SQL и другие. Эти хранилища обеспечивают хранение данных. Облачные СУБД, такие как Amazon RDS и Google Cloud SQL, предлагают управляемые базы данных (БД), которые автоматизируют задачи администрирования, такие как резервное копирование, обновление и масштабирование.
В-третьих, облачные инструменты для аналитики данных и поддержки жизненного цикла данных предлагают решения для анализа и моделирования, а также для управления метаданными, обеспечения качества данных и автоматизации ETL-процессов. Некоторые примеры таких инструментов включают в себя Google Cloud Data Catalog и Azure Data Catalog для управления метаданными, Informatica Data Quality и Talend Data Fabric для поддержания качества данных, а также AWS Glue и Google Cloud Dataflow для автоматизации извлечения, трансформации и загрузки данных. Облачные сервисы также включают в себя средства для аналитики и визуализации данных, такие как Amazon QuickSight и Google Data Studio, а также платформы для машинного обучения, такие как Yandex DataSphere, Amazon SageMaker и Google AI Platform.
Кроме того облака позволяют разделять ресурсы для вычислений и хранения, и за счёт этого создавать гибридные аналитические инфраструктуры при необходимости, когда данные хранятся в облаке, а вычисления проводятся во внутренней ИТ-инфраструктуре компании, или наоборот.
Например, компания может хранить большие объёмы исторических данных о транзакциях в облаке, где они более доступны и дешевле в хранении. При этом ежедневные расчёты и аналитика, требующие повышенной безопасности и быстродействия, проводятся на внутренних серверах компании. Или данные, собранные с датчиков и IoT-устройств на производственных линиях, могут быть временно сохранены в облаке для последующего анализа и прогнозирования. Однако непосредственное управление производственными процессами и оперативная аналитика могут выполняться на локальных серверах для минимизации задержек и повышения надёжности.
Классическим препятствием для перехода в облако является беспокойство компаний по поводу информационной безопасности и доступности данных. Однако облачные провайдеры внедряют меры для обеспечения безопасности и доступности, что вместе с преимуществами аналитических инструментов и машинного обучения побуждает компании постепенно переходить на облачные технологии для большей части их аналитической экосистемы.
Изменение 2. Переход от пакетной к потоковой обработке в реальном времени
Снижение затрат на технологии для передачи и потоковой обработки данных в реальном времени открыло новые возможности для бизнеса.
Эти технологии востребованы в различных отраслях, где важна оперативность. Например, транспортные компании теперь могут информировать клиентов о приближении такси с точностью до секунды. Страховые компании — анализировать данные о поведении водителей в реальном времени, чтобы предлагать индивидуальные тарифы и снижать риски. Производственные компании прогнозируют и предотвращают поломки оборудования, используя данные датчиков в режиме реального времени, что повышает эффективность и сокращает простои.
Реализация потоковой обработки данных в реальном времени требует использования соответствующих механизмов и инфраструктуры.
Механизмы подписки. Позволяют потребителям данных подписываться на определённые «темы» или потоки данных, чтобы получать постоянный поток обновлений и сообщений по мере их поступления. Приложения или устройства, генерирующие данные, отправляют сообщения в определённые темы (это называется «публикация»). Темы — это логические каналы, через которые данные распределяются. Потребители данных подписываются на интересующие их темы, чтобы получать сообщения в реальном времени (это называется «подписка»).
Решения для потоковой обработки и аналитики: позволяют анализировать данные в реальном времени. Этот анализ может быть основан на простых правилах или использовать сложные аналитические методы для выявления событий и сигналов в данных. Часто такие решения используют исторические данные для сравнения паттернов, что особенно важно для рекомендательной аналитики и предиктивной аналитики. Известные примеры таких решений: Apache Kafka Streaming, Apache Flume, Apache Storm и Apache Spark Streaming.
Платформы оповещений. Играют ключевую роль в оперативном реагировании на события. Они могут автоматически выполнять бизнес-действия на основе данных в реальном времени. Например, если представитель подразделения продаж не достигает своих дневных целей, платформа может отправить ему уведомление. Эти платформы часто интегрируются с внутренними системами (например, с ERP или CRM), чтобы действия, вызванные оповещениями, автоматически запускали процессы или обновление данные в этих системах. Известные примеры таких решений: Graphite или Splunk.
Изменение 3. Переход к модульным решениям
Компании переходят от монолитных, централизованных решений к модульной архитектуре, используя лучшие компоненты в своём классе и часто компоненты с открытым исходным кодом. Это позволяет заменять технологии без влияния на другие части архитектуры. Что даёт модульная архитектура — увеличивает скорость разработки и вывода новых продуктов на рынок, и при этом снижает вероятность возникновения ошибок в существующих приложениях.
Основу для модульной архитектуры создают следующие решения: конвейеры данных, API-интерфейсы и рабочие места аналитиков.
Конвейеры данных (data pipelines) автоматизируют процессы трансформации и интеграции данных. Их использование позволяет добавлять, удалять или заменять компоненты без пересмотра всей архитектуры.
Интерфейсы API стандартизируют взаимодействие между различными системами, облегчают интеграцию новых технологий. Они помогают изолировать компоненты друг от друга, что позволяет вносить изменения в один компонент без влияния на другие при изменении требований.
Аналитические рабочие места, такие как Amazon Sagemaker и Kubeflow позволяют подключаться к различным базам данных и сервисам.
Изменение 4. Переход от точечного доступа к доступу через API
Компании переходят от точечной интеграции к доступу через API. Это позволяет ограничить и обезопасить прямой доступ к данным, обеспечивая при этом быстрый доступ к общим наборам данных. Такой подход упрощает повторное использование данных между командами и поддерживает совместную работу команд.
В реализации этой идеи помогают следующие технологические решения: API-шлюзы и решения для буферизации транзакций вне основных систем.
API-шлюз (API gateway) выполняет множество функций, упрощая и улучшая управление API. Он служит единой точкой входа для всех клиентских запросов, направляя их к соответствующим микросервисам или серверам. Шлюз обеспечивает безопасность запросов с помощью аутентификации и авторизации, а также собирает данные о производительности для мониторинга. Кроме того, API-шлюз кэширует ответы на часто запрашиваемые данные, что снижает нагрузку на серверы и ускоряет обработку запросов. Он также преобразует формат запросов и ответов, чтобы соответствовать требованиям различных клиентов и серверов. Функции управления версиями API, мониторинга и логирования запросов помогают выявлять и устранять ошибки, а также обеспечивают безопасность.
Платформы данных для буферизации транзакций вне основных систем.
В традиционных архитектурах системы напрямую связываются друг с другом для обмена данными, создавая многочисленные зависимости и увеличивая сложность управления. Любое изменение в одной системе требует корректировок в других.
Буферизация транзакций помогает изолировать основные (core) системы от непосредственного взаимодействия с множеством других систем, что снижает зависимость и сложность интеграций.
Централизованные платформы, как озёра данных, собирают данные в одном месте, упрощая интеграцию и доступ к ним. Приложения могут получать данные из единого источника, вместо множества прямых подключений. Data mesh структурирует данные по доменам, где каждая команда отвечает за свой домен и предоставляет стандартизированный доступ к данным. Это обеспечивает независимое развитие систем без учёта изменений в других доменах.
Буферизация транзакций также существенно повышает масштабируемость и производительность. Благодаря этому платформы данных обрабатывают большие объёмы данных, распределяют нагрузку и предотвращают перегрузки.
Изменение 5. От корпоративного хранилища к доменно-ориентированной архитектуре
Многие компании переходят от централизованного хранения данных к доменно-ориентированной архитектуре, используя принципы доменно-ориентированного проектирования (Domain-Driven Design, DDD). Это позволяет настраивать системы под конкретные бизнес-задачи и домены, что ускоряет разработку и внедрение новых продуктов и услуг на основе данных.
Каждый домен (например, маркетинг, продажи, производство) организует свои наборы данных так, чтобы они были доступны как для внутренних пользователей, так и для внешних потребителей данных. В каждой бизнес-области назначаются владельцы продуктов, которые отвечают за организацию и доступность данных.
Ниже перечислены концепции и технологии, которые помогают перейти к доменно-ориентированной архитектуре.
Инфраструктура данных как платформа: предоставляет общие инструменты для хранения и управления данными, поэтому командам не нужно разрабатывать собственные системы для работы с данными.
Виртуализации данных: метод управления данными, который позволяет приложениям извлекать и обрабатывать данные без необходимости знать технические детали о самих данных, такие как их формат или физическое расположение. Основная цель виртуализации данных — создать единое представление данных из различных разрозненных источников, не копируя и не перемещая их. Это достигается за счёт создания абстрактного слоя, который объединяет данные из разных систем и предоставляет доступ к ним через унифицированный интерфейс. Например, в крупной компании есть отделы маркетинга, продаж и производства, каждый из которых управляет своими данными. С помощью виртуализации данных эти данные можно объединить в единое виртуальное хранилище. Маркетологи могут получить доступ к нужным им данным о продажах и производстве без необходимости прямого подключения к системам других подразделений.
Инструменты каталогизации данных: обеспечивают возможность поиска и изучения данных без необходимости полного доступа к ним или обработки, предоставляя метаданные и интерфейс для доступа к данным.
Изменение 6. От жёстких моделей данных к гибким, расширяемым схемам данных
Data Vault 2.0 — это методология создания гибких хранилищ данных. В основе лежат хабы, ссылки и спутники, которые позволяют легко добавлять новые данные или изменять существующие, не нарушая целостность системы. Это снижает риск сбоев, минимизирует затраты времени и ресурсов на изменения. Например, при добавлении нового продукта достаточно создать новый хаб и соответствующие спутники, без необходимости перестраивать всю модель данных. Технологии Data Vault 2.0 также обеспечивают полное сохранение истории изменений данных.
Графовые базы данных — это тип базы данных, в которой данные представляются и хранятся в виде графов, состоящих из узлов (объектов) и рёбер (связей). Эти базы данных относятся к NoSQL базам данных. Оптимизированы для управления данными, где важное значение имеют отношения между элементами и особенно полезны для анализа сложных взаимосвязей. Новые объекты и связи в графовых базах данных можно добавлять без необходимости значительных изменений в существующей структуре.
В целом все NoSQL базы данных отлично подходят для приложений, требующих работы в реальном времени. Они особенно эффективны для ИИ-приложений благодаря способности работать с неструктурированными данными. Графовые базы данных особенно хороши для моделирования отношений между данными. Поэтому многие компании используют их для создания мастер-хранилищ данных, которые могут адаптироваться к изменениям в информационных моделях.
Примеры графовых баз данных: Tarantool Graph DB от VK, Neo4j.
Технологические сервисы, такие как Azure Synapse Analytics, позволяют выполнять запросы к данным в файлах так же, как к реляционным базам данных, динамически применяя структуры таблиц к файлам. Это даёт пользователям возможность использовать привычные интерфейсы, такие как SQL, для доступа к данным в файлах.
Использование файлов форматов JSON и Parquet для хранения данных обеспечивает гибкость и адаптивность при изменении структуры данных, что позволяет организациям вносить изменения без необходимости корректировать информационные модели и нарушать текущие процессы.
О чём нужно помнить при проектировании архитектуры аналитики данных
Большинство компаний уже имеют архитектуру данных, включающую в себя несколько поколений устаревших технологий. В разрозненных хранилищах используются несогласованные структуры данных и метаданные. Разрозненность ИТ-ландшафта приводит к разрозненности данных. Управление данными в этих архитектурах является сложным и дорогостоящим процессом. Для каждого запроса на анализ данных требуются свой конвейер передачи данных. Любая попытка создать новые интерфейсы панели мониторинга или визуализацию данных требует привлечения ИТ-команды. При проектировании модернизации существующей или проектировании новой архитектуры аналитики данных необходимо обратить внимание на несколько ключевых аспектов.
Оценка потребностей. Первым шагом является оценка бизнес-целей и определение критериев успешности проекта. Это поможет выяснить, какие именно проблемы можно решить с помощью аналитики данных и какие результаты ожидать.
Анализ текущей ИТ-инфраструктуры. Включает в себя инвентаризацию существующих данных и хранилищ, а также оценку возможностей текущих систем. Определение, какие компоненты можно использовать, а какие нужно заменить или обновить.
Доступ к данным. Просто найти возможность хранить и обрабатывать большие объёмы данных — недостаточно для создания data-driven культуры. Нужны удобные и понятные инструменты для работы с данными, чтобы сотрудники из всех подразделений и с разным уровнем технической подготовки могли быстро искать и получать доступ к необходимым данным.
Безопасность и контроль доступа. Внедрить меры безопасности для защиты данных. Разработать и реализовать политики контроля доступа, чтобы только авторизованные пользователи могли работать с определенными данными. Подумать над чёткими стандартизованными правилами разграничения доступа для того, чтобы можно большую часть согласований выполнять в автоматизированном режиме, без индивидуальных согласований каждого доступа для каждого сотрудника с подразделениями информационной безопасности и ответственными руководителями направлений.
Стандартизация и установление общего бизнес-глоссария. Стандартизировать термины и определения, чтобы все сотрудники использовали одни и те же бизнес-термины при работе с данными.
Качество данных. Обеспечить высокое качество данных путём их очистки, структурирование и управление ключевыми метриками.
Минимизация перемещения данных. Сократить количество перемещений данных между различными системами и хранилищами для снижения затрат и повышения точности. Современные платформы данных позволяют обрабатывать большие объёмы данных прямо в хранилище, без необходимости их переноса с места на место.
Масштабируемость архитектуры. Спроектировать систему с учётом возможного роста и изменений в будущем. Использовать модульные и масштабируемые решения, которые можно быстро адаптировать к новым требованиям.
Обучение и поддержка пользователей. Обучить сотрудников работе с новыми процессами, с новой архитектурой и инструментами аналитики данных. Обеспечить ресурсы на методологическую поддержку пользователей и обучение.
Интеграция с существующими бизнес-процессами. Убедиться, новые решения интегрированы в текущие бизнес-процессы и системы и обеспечить бесшовное взаимодействие между различными компонентами ИТ-ландшафта компании.
Оптимизация затрат на хранение. Данные обычно становятся менее полезными по мере их устаревания и к ним реже обращаются. Со временем данные можно перенести в более дешёвые и «медленные» хранилища, чтобы они оставались доступными для отчётов и аудита, но не требовали лишних затрат на высокопроизводительное хранилище.
И самое сложное: добиться того, что данные будут восприниматься, как актив. Компании, которые рассматривают данные как общий актив, имеют конкурентное преимущество. Если этого понимания в компании нет, то все усилия по разработке архитектуры и внедрению процессов окажутся бесполезными.
Заключение
В статье мы рассмотрели ключевые шаги, необходимые для трансформации компании в data-driven организацию. Одну из главных ролей в этом играет современная архитектура аналитики данных. Она помогает интегрировать разрозненные данные компании и устранить технические и организационные барьеры. Это позволяет разным подразделениям обмениваться данными, обеспечивать единое понимание метрик и клиентов, продуктов и продаж в регионах.
Целостная архитектура, разработанная с учётом всех рассмотренных в этой статье аспектов, в конечном счёте принесёт пользу, поможет экономить время и генерировать идеи. Она позволит сотрудникам сосредоточиться на принятии решений, а не на поиске, обработке и подготовке данных для анализа.
Успешная трансформация зависит не только от внедрения современных технологий, но и от культуры принятия решений на основе данных и организационной структуры управления данными.
Подробнее о том, как мы можем помочь в создании архитектуры данных, и какое место в ней может занять наш продукт Epsilon Workflow, можно прочитать в нашем блоге: «No-code аналитика с Epsilon Workflow».
Я надеюсь, что представленные идеи и советы помогут успешно реализовать ваши идеи в части data-driven подхода. Теперь у вас есть все необходимые знания для начала внедрения аналитики данных.
