[ ICYMI Читать Часть 1 Немасштабируемая платформа данных ]

Сегодня многие платформы данных строятся снизу вверх, начиная со сбора данных, которые «могут пригодиться позже», и постепенного объединения решений по мере возникновения потребностей. Такой подход неизбежно приводит к фрагментированной реализации, растущим затратам и техническому долгу. Проектирование систем данных требует специализированных знаний в области моделирования данных, распределенных систем, безопасности и соответствия требованиям. Большинство компаний просто не могут позволить себе выделенные команды по инфраструктуре данных на начальном этапе и вынуждены создавать и адаптировать свои системы данных по мере их роста.

Однако путь развития существующих систем может быть довольно сложным. Командам часто приходится выбирать между длительными миграциями с сохранением нескольких дублирующих систем или дорогостоящим полным переключением системы. Решение Netscape переписать свой браузерный движок в 1997 году стоило им их браузерного бизнеса и доминирования на рынке в пользу Internet Explorer, поскольку они не могли конкурировать с быстрым выпуском функций Internet Explorer, что в конечном итоге привело к снижению их доли рынка. Многие компании начинают с индивидуальных решений и переходят на платформы поставщиков по мере роста; однако даже в масштабе, когда компании могут позволить себе платформы поставщиков, они все равно могут не соответствовать своим сценариям использования, и внутренние пользователи должны адаптироваться к новым рабочим процессам. Многие компании в конечном итоге создают индивидуальные решения поверх платформ поставщиков по мере своего дальнейшего масштабирования. Внутренние инфраструктурные команды теперь должны поддерживать свои исходные системы, управлять платформами поставщиков и поддерживать индивидуальные реализации поверх этих платформ — одновременно обучая пользователей работе с различными инструментами и занимаясь безопасностью и интеграцией между несколькими системами. Из-за отсутствия планирования и органического прогресса по мере масштабирования бизнеса то, что изначально было более дешевым решением, становится значительно более дорогим и сложным в эксплуатации.

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

Проектирование платформ данных

По своей сути платформа данных может быть определена двумя фундаментальными компонентами: какие данные вам нужны (модели данных) и как быстро они вам нужны (требования к задержке). Даже при нечетко определенном варианте использования понимание этих двух компонентов позволяет нам систематически выводить механизм сбора данных и потребности в инфраструктуре.

Возьмем, к примеру, обнаружение риска мошенничества. Обычно риск мошенничества требует трех компонентов данных: идентификация, транзакция и управление случаями.

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

Модели данных

Модель данных определяет, как данные должны быть организованы и стандартизированы. Она определяет набор полей и их характеристики — формат, тип и правила для каждого поля. Схемы позволяют обнаруживать данные, в то время как определения отдельных полей определяют политики управления и требования соответствия.

Четко определенные модели данных обеспечивают стандартизированный сбор и обработку данных в рамках всей организации. Возьмем в качестве примера данные пользователей — маркетингу они нужны для отслеживания кампаний, службе поддержки клиентов — для управления кейсами, командам по продуктам — для поведенческой аналитики, а командам по рискам — для обнаружения мошенничества. Без общей модели данных пользователей каждая команда создает собственную версию профилей пользователей и логики отслеживания. В конечном итоге команды создают сложные интеграции для разрешения и согласования данных пользователей между системами. Общая модель данных, служащая единым источником истины, упрощает сбор и реализацию данных, в то время как согласованные стандарты значительно упрощают управление безопасностью и соответствием.

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

Требования ко времени

Требования ко времени определяют, насколько быстро данные должны быть обработаны и предоставлены. Окна обработки варьируются от реального времени (секунды) для немедленных решений до почти реального времени (минуты) для мониторинга и пакетной обработки (часы) для аналитики и приложений AI/ML. Эти требования ко времени соответствуют определенным вариантам инфраструктуры — потоковая передача для реального времени, базы данных для почти реального времени и озера данных для пакетной обработки.

Без фреймворка команды по продуктам часто создают избыточную инфраструктуру для схожих нужд — одна команда может использовать Kafka, а другая — MSK для потоковой передачи, или одна команда может выбрать DynamoDB, а другая — Cassandra для баз данных. Это создает ненужную сложность, поскольку команды поддерживают несколько систем с дублирующими элементами управления безопасностью и интеграциями.

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

Общая платформа данных

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

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

Далее следует

В части 3 серии «One Off to One Data Platform» мы обсудим, как можно реализовать эту структуру на практическом уровне. Мы рассмотрим, как можно собрать общие компоненты платформы данных, такие как потоковая передача, базы данных, хранилище данных и озеро данных, для поддержки различных бизнес-кейсов с согласованными средствами безопасности и контроля соответствия. По мере роста организаций этот модульный подход позволяет группам масштабировать отдельные компоненты независимо, сохраняя при этом стандартизированные интерфейсы и элементы управления, устраняя необходимость в постоянных миграциях. С четкой структурой архитектуры платформы данных организации могут создавать приложения данных, которые растут вместе с их бизнесом, а не ограничивают его.