paint-brush
Платформа данных One Off to One: проектирование платформ данных с возможностью масштабирования [часть 2] к@luluc
1,160 чтения
1,160 чтения

Платформа данных One Off to One: проектирование платформ данных с возможностью масштабирования [часть 2]

к jarrid.xyz
jarrid.xyz HackerNoon profile picture

jarrid.xyz

@luluc

Actionable Data Security

5 мин read2024/12/09
Read on Terminal Reader
Read this story in a terminal
Print this story
tldt arrow
ru-flagRU
Прочтите эту историю на русском языке!
en-flagEN
Read this story in the original language, English!
tr-flagTR
Bu hikayeyi Türkçe okuyun!
de-flagDE
Lesen Sie diese Geschichte auf Deutsch!
es-flagES
Lee esta historia en Español!
fr-flagFR
Lisez cette histoire en Français!
ja-flagJA
この物語を日本語で読んでください!
rw-flagRW
Soma iyi nkuru muri Kinyarwanda!
mn-flagMN
Энэ түүхийг монгол хэлээр уншаарай!
tg-flagTG
Ин қиссаро бо забони тоҷикӣ хонед!
ay-flagAY
¡Aka sarnaqäw aymar arun ullart’apxam!
lt-flagLT
Skaitykite šią istoriją lietuvių kalba!
ka-flagKA
წაიკითხეთ ეს ამბავი ქართულად!
RU

Слишком долго; Читать

Представляем структуру архитектуры платформы данных, которая позволяет организациям систематически проектировать и внедрять масштабируемые решения по работе с данными в распространенных бизнес-сценариях.
featured image - Платформа данных One Off to One: проектирование платформ данных с возможностью масштабирования [часть 2]
jarrid.xyz HackerNoon profile picture
jarrid.xyz

jarrid.xyz

@luluc

Actionable Data Security

0-item
1-item

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Opinion piece / Thought Leadership

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Guide

Guide

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.


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


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


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


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

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

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


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

image

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


image

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

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


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

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

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

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


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

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

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

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


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

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

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

L O A D I N G
. . . comments & more!

About Author

jarrid.xyz HackerNoon profile picture
jarrid.xyz@luluc
Actionable Data Security

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В...

Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
X REMOVE AD