3 июня 2020 г. | Статья
Антонио Кастро, Хорхе Мачадо, Маттиас Роггендорф и Хеннинг Соллер
Такие рыночные инновации, как персонализированные предложения, оповещения в реальном времени и профилактическое обслуживание потребовали от организаций новых технологий рядом с уже работающей инфраструктурой обработки данных. В частности, появились такие технологические структуры, как озеро данных, платформы клиентской аналитики, приложения обработки потоков, модели искусственного интеллекта. Хотя такие технологии предоставляют новые возможности, но они же приводят к росту сложности архитектуры данных. Рост сложности архитектуры снижает способность организации максимально использовать новые технологии для укрепления конкурентных преимуществ. Для создания конкурентных преимуществ - или даже для поддержания паритета, - компаниям требуется новый подход к определению, внедрению и интеграции своих стеков данных, требуются новые концепции и компоненты.
Итак, шесть сдвигов в создании "революционной" архитектуры данных:
- От локальных систем к облачным решениям.
- От пакетов данных к данным в реальном масштабе времени.
- От преднастроенных интегрированных коммерческих решений до лучших в своем классе модульных платформ.
- От точечного доступа к данным до свободного доступа к данным.
- От корпоративных хранилищ данных к доменной архитектуре данных.
- От жестких моделей данных до гибких расширяемых схем данных.
Даже несмотря на то, что организации могут осуществить некоторые изменения, не затрагивая свой основной стек технологий, многие из них требуют тщательной перестройки существующей платформы данных и инфраструктуры, включая как устаревшие, так и новые технологии, которые ранее были внедрены.
Инвестиции могут варьироваться от десятков миллионов долларов для базовых сценариев использования данных (таких как автоматическая отчетность), до сотен миллионов долларов для внедрения передовых архитектурных компонентов (таких как услуги в реальном времени).
Следовательно важно иметь четкий стратегический план, и лидерам необходимо сделать смелый выбор, определить приоритеты тех изменений, которые будут напрямую влиять на бизнес-цели, и вложить средства в правильный уровень сложности архитектуры.
Заметим, что архитектура данных компаний часто сильно различаются. Но если все сделано правильно, возврат инвестиций может быть значительным. Примеры. Более 500 миллионов долларов в год в случае одного американского банка. От 12 до 15 процентов роста прибыли в случае одной нефтегазовой компании.
Какие ключевые изменения следует учитывать организациям?
1. От локальных до облачных решений.
Облако, вероятно, является наиболее разрушительным драйвером радикально нового подхода к архитектуре данных, поскольку предлагает компаниям способ быстрого масштабирования инструментов и возможностей ИИ для получения конкурентного преимущества. Крупные глобальные облачные провайдеры, такие как Amazon (с Amazon Web Services), Google (с Google Cloud Platform) и Microsoft (с Microsoft Azure), произвели революцию в том, как организации любого размера создают, развертывают и запускают инфраструктуру данных, платформы и приложения в нужном организациям масштабе.
Возможные концепции и компоненты:
- Бессерверные платформы данных, такие как Amazon S3 и Google BigQuery, позволяют организациям создавать и использовать ориентированные на данные приложения с неограниченным масштабом без хлопот по установке, настройке решений и управлению рабочими нагрузками. Такие предложения могут снизить потребность в экспертных знаниях, ускорить развертывание с нескольких недель до нескольких минут и практически не потребуют накладных расходов.
- Контейнеры данных с использованием Kubernetes позволяют компаниям отделить и автоматизировать развертывание дополнительных вычислительных мощностей и систем хранения данных. Эта возможность особенно ценна для обеспечения высокой доступности и высокой степени масштабирования.
2. От пакетной обработки данных до обработки данных в реальном времени.
Стоимость обмена данными в реальном масштабе времени значительно снизилась, а возможности потоковой передачи расширились, что открывает путь массового использования этих технологий. Данные технологии позволяют использовать множество новых бизнес-приложений: например, транспортные компании могут информировать клиентов о приближении такси с помощью прогнозов прибытия с точностью до секунды; страховые компании могут анализировать с помощью смарт-устройств поведенческих данных в режиме реального времени и индивидуализировать ставки страховых премий; производители могут прогнозировать техническое состояние инфраструктуры на основе данных датчиков в реальном времени.
Функции потоковой передачи в реальном времени, такие как механизм подписки, позволяют потребителям подписываться требуемые им на «темы». Общее озеро данных обычно служит «мозгом» для таких сервисов, сохраняя все детали транзакций.
Возможные концепции и компоненты:
- Платформы обмена сообщениями, такие как Apache Kafka, обеспечивают полностью масштабируемые, надежные и отказоустойчивые службы публикации и подписки, которые могут обрабатывать и хранить миллионы сообщений каждую секунду для немедленного или последующего использования. Это позволяет поддерживать варианты использования в режиме реального времени, минуя существующие пакетные решения.
- Решения для потоковой обработки и аналитики, такие как Apache Kafka Streaming, Apache Flume, Apache Storm и Apache Spark Streaming, позволяют проводить анализ сообщений в режиме реального времени. Этот анализ может быть основан на правилах или включать расширенную аналитику для извлечения событий или сигналов из данных. Часто анализ объединяется с историческими данными для формирования закономерностей для прогнозирвоания и выработки рекомендаций.
- Платформы оповещения, такие как Graphite или Splunk, могут побуждать сотрудников к активным действиям, формируя приоритетность и срочность задач.
3. От предварительно настроенных решений до лучших в своем классе модульных платформ.
Чтобы масштабировать приложения, компаниям часто приходится выходить за рамки унаследованных экосистем от крупных поставщиков решений. Многие сейчас переходят к модульной архитектуре данных, в которой используются лучшие в своем классе компонентф. Зачастую это компоненты с открытым исходным кодом, которые при необходимости могут быть заменены новыми технологиями, не затрагивая другие части архитектуры данных.
Возможные концепции и компоненты
- Конвейер данных и интерфейсы на основе API упрощают интеграцию между разрозненными инструментами и платформами, защищая пользователей и специалосто группы обработки данных от сложности различных уровней архитектуры данных, ускоряя время выхода продукта на рынок и снижая вероятность возникновения новых проблем в существующих приложениях. Эти интерфейсы также позволяют упростить замену отдельных компонентов архитектуры при изменении требований.
- Инструментальные средства аналитики, такие как Amazon Sagemaker и Kubeflow, упрощают создание комплексных решений в высокомодульной архитектуре. Такие инструменты могут подключаться к большому количеству баз данных и сервисов, обеспечивая модульность архитектуры.
4. От двухточечного (peer-to-peer) до свободного доступа к данным.
Предоставление данных посредством API-интерфейсов может гарантировать, что прямой доступ к данным будет ограниченным и безопасным, одновременно предлагая гибкий и быстрый доступ к наборам данных. Это позволяет легко повторно использовать данные в разных сценариях.
Возможные концепции и компоненты
- Платформа управления API (часто называемая шлюзом API) необходима для создания и публикации ориентированных на данные API, реализации политик использования API, управления доступом, измерения использования API и измерения производительности. Такая платформа позволяет разработчикам и пользователям искать нужные им интерфейсы данных, использовать их, а не создавать свои интерфейсы. Шлюз API часто встроен как отдельное решение в концентратор данных, но может использовать и автономно за пределами концентратора.
- Платформа данных. Используется для «буферизации» транзакций и данных вне основных систем. По сути это централизованные платформы данных, такие как озеро данных или распределенная система данных, мыслимая как экосистема. Такие систем сетка данных, которая представляет собой экосистему. Такие платформы позволяют создавать специализированные хранилища данных, организовывать использование данных, контролировать и управлять рабочими нагрузками.
5. От корпоративного склада данных к доменной архитектуре данных.
Лидеры в области архитектуры данных перешли от центрального озера данных к проектам, ориентированным на предметную область. Это позволяет настраивать наборы данных их назначению, что сокращает время вывода новых продуктов и услуг на рынок. При таком подходе, хотя наборы данных могут по-прежнему находиться на одной и той же физической платформе, «владельцы продукта» перемещаются в каждую область бизнеса (например, в маркетинг, в продажи, в производство). Тем самым организуется бизнес-домен, как способ организации данных в легко потребляемом виде. Эти же данные легче использовать и потребителями других бизнес-доменов. Но такой подход требует тщательного проектирования структур данных, чтобы избежать фрагментации данных и неэффективности доступа к данным.
Возможные концепции и компоненты
- Инфраструктура данных как платформа предоставляет общие инструменты и возможности для хранения и управления данными с целью ускорения внедрения продуктов работы с данными.
- Методы виртуализации данных, которые зародились в нишевых областях, таких как данные клиентов, теперь используются на предприятиях для организации доступа к данным и интеграции распределенных массивов данных.
- Инструменты каталогизации данных обеспечивают корпоративный поиск данных, не требуя значительных усилий по подготовке и полного доступа к технологическим данным. Каталог содержит определения метаданных и сквозной интерфейс для доступа к данным.
6. От жестких моделей данных к гибким, расширяемым схемам данных.
Проприетарные модели данных, которые служат конкретным потребностям бизнес-аналитики, часто строятся в виде строго нормализованных схем с жесткими таблицами базы данных. Это поход применяется для устранения избыточности. Хотя этот подход остается стандартом, он порождает длительные циклы разработки баз данных и требует привлечения специалистов ИТ с глубокими знаниями системы управления базами данных. Также такой подход требует осторожности при необходимости внесения изменинй, поскольку любые изменения могут повлиять на целостность данных.
Чтобы получить большую гибкость и мощное конкурентное преимущество при изучении данных или поддержке расширенной аналитики, компании переходят на подходы, основанные на «упрощенной схеме» представления данных, используя денормализованные модели данных с меньшим количеством физических таблиц. Этот подход предлагает множество преимуществ: быстрое исследование данных, большую гибкость в хранении структурированных и неструктурированных данных и снижение сложности. При таком подходе не нужно вводить дополнительные уровни абстракции для доступа к сильно нормализованным таблицам.
Возможные концепции и компоненты
- Методы хранилища данных 2.0, такие как моделирование точек данных (data-point modeling), могут гарантировать, что модели данных являются расширяемыми, поэтому элементы данных могут быть добавлены или удалены не влияя на работу в целом.
- Графические (графовые) базы данных, базы данных типа NoSQL. Базы данных NoSQL в целом идеально подходят для цифровых приложений, требующих огромной масштабируемости и возможностей обработки в реальномо времени. Они также подходят для организации уровней данных, обслуживающих приложения ИИ, благодаря способности ИИ подключаться к неструктурированным данным. В частности, графические базы данных предлагают инструменты мощного и гибкого моделирования взаимосвязей в данных. Многие компании создают репозитории основных данных, используя графовые базы данных, чтобы приспособиться к изменяющимся информационным моделям.
- Технологические службы, такие как Azure Synapse Analytics, позволяют запрашивать данные на основе файлов, аналогичных реляционным базам данных, путем динамического применения структур таблиц к обработке данных файлов. Это дает пользователям возможность продолжать использовать общие интерфейсы, такие как SQL, при доступе к данным, хранящимся в файлах.
- Использование нотации объектов JavaScript (JSON) для хранения информации позволяет организациям изменять структуры баз данных без изменения моделей бизнес-информации.
С чего начать
Технологии обработки данных быстро развиваются. Не все архитектуры эффективные, многие - рискованные. Поэтому занчимым является способность быстро оценивать и развертывать новые технологии. Решающее значение имеют четыре практики:
- «Тестируй и учись» при построении архитектуры. Экспериментируйте с различными компонентами и концепциями. Например, вместо того, чтобы участвовать в длительных дискуссиях об оптимальных дизайнах, продуктах и поставщиках для определения «идеального» выбора с последующим длительным утверждением бюджета, руководители могут начать с меньших бюджетов и создать минимально жизнеспособные продукты или объединить существующие продукты с открытым исходным кодом. Промежуточный продукт позволяет продемонстрировать свою ценность, прежде чем расширяться и развиваться дальше.
- Создайте группы работы с данными, в которых команды инженеров данных и разработчиков моделей данных работают вместе со сквозной подотчетностью для построения архитектуры данных. Эти группы также работают над внедрением стандартных, повторяемых процессов разработки данных и функций для поддержки сформированных наборов данных, готовых для моделирования. Эти методы гибкой обработки данных могут помочь ускорить вывод на рынок новых услуг передачи данных.
- Инвестируйте в DataOps (улучшенный DevOps для данных), который может помочь ускорить проектирование, разработку и развертывание новых компонентов в архитектуре данных.
- Создайте культуру работы с данными, в которой сотрудники будут стремиться использовать и применять новые службы данных в рамках своих функциональных обязанностей. Одним из важных инструментов для достижения этого является обеспечение того, чтобы стратегия обработки данных была связана с бизнес-целями и артикулировалась высшим руководством. Это определяет важность культуры работы с данными.
По мере того, как данные, аналитика и искусственный интеллект становятся встроенными в повседневные операции большинства организаций, становится ясно, что для создания и развития предприятия, ориентированного на данные, необходим радикально иной подход к архитектуре данных. Конечно, для того чтобы стать более гибкими, устойчивыми и конкурентоспособными.
Графический материал
Перевод статьи
https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/how-to-build-a-data-architecture-to-drive-innovation-today-and-tomorrow
Комментариев нет:
Отправить комментарий