[ ] ICYMI Читать Часть 1 Немасштабируемая платформа данных Сегодня многие платформы данных строятся снизу вверх, начиная со сбора данных, которые «могут пригодиться позже», и постепенного объединения решений по мере возникновения потребностей. Такой подход неизбежно приводит к фрагментированной реализации, растущим затратам и техническому долгу. Проектирование систем данных требует специализированных знаний в области моделирования данных, распределенных систем, безопасности и соответствия требованиям. Большинство компаний просто не могут позволить себе выделенные команды по инфраструктуре данных на начальном этапе и вынуждены создавать и адаптировать свои системы данных по мере их роста. Однако путь развития существующих систем может быть довольно сложным. Командам часто приходится выбирать между длительными миграциями с сохранением нескольких дублирующих систем или дорогостоящим полным переключением системы. Решение Netscape переписать свой браузерный движок в 1997 году стоило им их браузерного бизнеса и доминирования на рынке в пользу Internet Explorer, поскольку они не могли конкурировать с быстрым выпуском функций Internet Explorer, что в конечном итоге привело к снижению их доли рынка. Многие компании начинают с индивидуальных решений и переходят на платформы поставщиков по мере роста; однако даже в масштабе, когда компании могут позволить себе платформы поставщиков, они все равно могут не соответствовать своим сценариям использования, и внутренние пользователи должны адаптироваться к новым рабочим процессам. Многие компании в конечном итоге создают индивидуальные решения поверх платформ поставщиков по мере своего дальнейшего масштабирования. Внутренние инфраструктурные команды теперь должны поддерживать свои исходные системы, управлять платформами поставщиков и поддерживать индивидуальные реализации поверх этих платформ — одновременно обучая пользователей работе с различными инструментами и занимаясь безопасностью и интеграцией между несколькими системами. Из-за отсутствия планирования и органического прогресса по мере масштабирования бизнеса то, что изначально было более дешевым решением, становится значительно более дорогим и сложным в эксплуатации. Разработка платформ данных, которые могут масштабироваться с ростом бизнеса, сегодня более достижима, чем раньше. За последнее десятилетие многие организации установили четкие шаблоны использования данных — продуктовые команды нуждаются в данных о поведении пользователей, маркетинговые команды отслеживают эффективность кампаний, финансовые команды отслеживают показатели доходов, а команды безопасности анализируют шаблоны угроз. Эти общие варианты использования хорошо известны с точки зрения того, какие данные им нужны и как быстро они им нужны. Вместо того чтобы обнаруживать требования посредством дорогостоящих миграций и модернизации решений поставщиков, можно создать платформу данных, которая может устойчиво масштабироваться с точки зрения затрат и операционной эффективности. Проектирование платформ данных По своей сути платформа данных может быть определена двумя фундаментальными компонентами: какие данные вам нужны (модели данных) и как быстро они вам нужны (требования к задержке). Даже при нечетко определенном варианте использования понимание этих двух компонентов позволяет нам систематически выводить механизм сбора данных и потребности в инфраструктуре. Возьмем, к примеру, обнаружение риска мошенничества. Обычно риск мошенничества требует трех компонентов данных: идентификация, транзакция и управление случаями. Каждый компонент данных может быть сопоставлен с инфраструктурой на основе потребностей в задержке. Проверка личности и транзакций требует потоковой обработки для обнаружения мошенничества в реальном времени, обработка базы данных обрабатывает текущий мониторинг и оповещения, а озера данных поддерживают более длительные задачи, такие как анализ шаблонов и обучение моделей. Модели данных Модель данных определяет, как данные должны быть организованы и стандартизированы. Она определяет набор полей и их характеристики — формат, тип и правила для каждого поля. Схемы позволяют обнаруживать данные, в то время как определения отдельных полей определяют политики управления и требования соответствия. Четко определенные модели данных обеспечивают стандартизированный сбор и обработку данных в рамках всей организации. Возьмем в качестве примера данные пользователей — маркетингу они нужны для отслеживания кампаний, службе поддержки клиентов — для управления кейсами, командам по продуктам — для поведенческой аналитики, а командам по рискам — для обнаружения мошенничества. Без общей модели данных пользователей каждая команда создает собственную версию профилей пользователей и логики отслеживания. В конечном итоге команды создают сложные интеграции для разрешения и согласования данных пользователей между системами. Общая модель данных, служащая единым источником истины, упрощает сбор и реализацию данных, в то время как согласованные стандарты значительно упрощают управление безопасностью и соответствием. Определение всеобъемлющих моделей данных часто бывает сложным для отдельных команд, поскольку они обычно сосредоточены на своих непосредственных потребностях. Маркетинговые команды сосредоточены на областях, связанных с кампаниями, в то время как команды по рискам сосредоточены на атрибутах проверки личности. Без целостного представления о том, как одни и те же данные выполняют различные функции, команды часто создают неполные или узконаправленные модели данных, которые требуют дальнейшей обработки и интеграции между системами. Требования ко времени Требования ко времени определяют, насколько быстро данные должны быть обработаны и предоставлены. Окна обработки варьируются от реального времени (секунды) для немедленных решений до почти реального времени (минуты) для мониторинга и пакетной обработки (часы) для аналитики и приложений AI/ML. Эти требования ко времени соответствуют определенным вариантам инфраструктуры — потоковая передача для реального времени, базы данных для почти реального времени и озера данных для пакетной обработки. Без фреймворка команды по продуктам часто создают избыточную инфраструктуру для схожих нужд — одна команда может использовать Kafka, а другая — MSK для потоковой передачи, или одна команда может выбрать DynamoDB, а другая — Cassandra для баз данных. Это создает ненужную сложность, поскольку команды поддерживают несколько систем с дублирующими элементами управления безопасностью и интеграциями. Стандартизируя компоненты инфраструктуры, продуктовые команды больше не нуждаются в развертывании собственной инфраструктуры, а команды платформы могут сократить операционные издержки, поддерживая меньше систем. Эта стандартизация также обеспечивает лучший контроль безопасности, оптимизированную интеграцию, упрощенную наблюдаемость и оптимизированные затраты. Общая платформа данных Структура архитектуры платформы данных позволяет нам систематически получать спецификации сбора данных, требования к инфраструктуре, средства управления безопасностью и возможности интеграции. Это напрямую решает проблему сложности и спирали затрат, с которой сегодня сталкиваются многие организации. Вместо того чтобы создавать отдельные системы, которые команды платформы с трудом поддерживают, последовательная структура упрощает управление безопасностью, соответствием, интеграцией и затратами в масштабах всей организации. Без последовательной реализации командам платформы постоянно приходится выбирать между поддержанием существующих систем, выполнением дорогостоящих миграций или созданием новых функций. Команды платформы в конечном итоге тратят большую часть своего времени на поддержание разрозненных систем и обработку миграций вместо предоставления критически важных для бизнеса возможностей. Подход, основанный на фреймворке, позволяет организациям масштабировать свои платформы данных без разрушительных миграций. Небольшие организации могут начать с необходимых компонентов и расширяться по мере роста, а более крупные организации могут стандартизировать свои существующие системы один раз без постоянного переписывания. Далее следует В части 3 мы обсудим, как можно реализовать эту структуру на практическом уровне. Мы рассмотрим, как можно собрать общие компоненты платформы данных, такие как потоковая передача, базы данных, хранилище данных и озеро данных, для поддержки различных бизнес-кейсов с согласованными средствами безопасности и контроля соответствия. По мере роста организаций этот модульный подход позволяет группам масштабировать отдельные компоненты независимо, сохраняя при этом стандартизированные интерфейсы и элементы управления, устраняя необходимость в постоянных миграциях. С четкой структурой архитектуры платформы данных организации могут создавать приложения данных, которые растут вместе с их бизнесом, а не ограничивают его. серии «One Off to One Data Platform»
![featured image - Платформа данных One Off to One: проектирование платформ данных с возможностью масштабирования [часть 2]](https://hackernoon.imgix.net/images/a-bump-of-numbers-scatter-atop-a-scale-p0147e74ie60vwfjj5lggl1e.png?auto=format&fit=max&w=3840)
