ζ༼Ɵ͆ل͜Ɵ͆༽ᶘ

Эволюция инфраструктуры данных

0 комментов
29.09.2022
9 мин чтения

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

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

В этой статье мы все же начнем с монолита, как делали это раньше.

Инфраструктура данных — это «место», где хранятся все виды данных, будь то структурированные данные, данные временных рядов или даже необработанные данные. Цель этих больших данных (а они действительно большие) — предоставить материал для анализа данных, бизнес-аналитики или машинного обучения.

Помимо внутреннего использования, также могут быть функции, ориентированные на пользователя, например, список рекомендуемых продуктов на веб-сайте электронной коммерции. Функция рекомендаций — это наиболее часто используемый клиентский сценарий для больших данных, таких как рекомендуемые продукты на веб-сайтах электронной коммерции и рекомендуемые видео на видеоплатформах, таких как Youtube. Все это результат анализа, агрегирования и компиляции после сохранения различных действий пользователя.

Ознакомившись с сегодняшней темой, приступим к работе.

Монолитная архитектура

Начнем с монолитной архитектуры.

Какой бы ни была служба, типичная монолитная архитектура — это служба в паре с базой данных. Весь анализ данных, бизнес-аналитика и машинное обучение выполняются непосредственно в этой базе данных.

Это самая простая практика, но она также является началом всех продуктов.

Почему мы показываем это в монолитном стиле?

Не лучше ли сделать больше?

Ну а если продукт умрет до того, как станет популярным, то монолита будет достаточно, чтобы сохранить полноценные функции. Чтобы избежать чрезмерного проектирования и резкого роста инвестиционных затрат, мы предпочитаем начинать с самых простых монолитов для проверки концепции.

Конечно, эта архитектура обязательно столкнется с проблемами. Есть три типичных проблемы

  1. Анализ влияет на производительность производства
  2. При внедрении микрослужб страдает текущий анализ базы данных каждой микрослужбы
  3. Выполнить кросс-сервисный анализ очень сложно

Различные анализы неизбежно отнимают много ресурсов базы данных, поэтому клиенты напрямую ощущают низкую производительность в это время.

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

Более того, даже если каждую услугу можно проанализировать по отдельности, мы не сможем легко получить глобальное представление, поскольку аналитика не зависит друг от друга.

Поэтому необходимо выполнить первую эволюцию!

Пакетная обработка

У нас две цели: во-первых, иметь независимое хранилище данных, чтобы оно не влияло напрямую на производственную среду, а во-вторых, иметь возможность выполнять кросс-сервисный анализ.

Для достижения этих целей мы создали централизованное хранилище данных, чтобы все данные можно было хранить в одном месте. Все анализы были перенесены из баз данных каждого сервиса в хранилище данных.

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

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

  1. Отсутствие реального времени
  2. Отсутствие схемы

Из-за периодических пакетных задач мы не можем проводить анализ в реальном времени. Если мы запускаем задачу раз в час, то данные, которые мы видим в хранилище данных, представляют собой снимок данных за предыдущий час.

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

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

Итак, давайте проведем вторую эволюцию!

Потоковая обработка

Для решения проблемы реального времени наиболее простой идеей является использование потоковой архитектуры.

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

Но есть ли способ решить проблему со схемой?

Ответ: да, через KCBQ.

Давайте подробнее рассмотрим внутреннюю архитектуру потоковой передачи.

Мы используем Debezium для регистрации изменений в каждой базе данных и отправки потоков в Kafka, а позже KCBQ подписывается на потоки Kafka и архивирует их в BigQuery.

Стоит отметить, что KCBQ может автоматически обновлять внутреннюю схему BigQuery (настройка должна быть включена, и должен использоваться формат AVRO).

На данном этапе у нас есть полный набор данных для анализа, и у нас достаточно данных для обработки для всех видов анализа данных, как в реальном времени, так и в пакетном режиме. Однако на предыдущем этапе нам удалось ускорить анализ за счет пакетной предварительной обработки для создания структурированных данных, и мы по-прежнему хотим сохранить эту возможность.

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

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

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


Интегрированная архитектура

У нас уже есть пакетная архитектура и потоковая архитектура, теперь давайте их правильно интегрируем.

Мы по-прежнему архивируем изменения из каждой базы данных в хранилище данных посредством потоковой передачи, но периодически используем пакетную обработку для предварительной обработки необработанных данных для анализа данных.

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

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

Итак, давайте далее посмотрим на внутренности потоковой архитектуры.

Фреймворк в основном такой же, как и предыдущий, но с новой ролью StreamAPI.

В StreamAPI не указана конкретная структура, можно успешно использовать родную библиотеку Kafka.

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

Поэтому я все же рекомендую использовать фреймворк для потоковой передачи, такой как Apache Flink или Apache Kafka Streams.

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

Однако эта архитектура не означает, что она сделана раз и навсегда.

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

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

Более того, когда все данные сбрасываются в хранилище данных, нам приходится шифровать или маскировать PII (идентифицирующую личность информацию), чтобы соответствовать законодательным требованиям, таким как GDPR.

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


Автоматизация (Платформа самообслуживания)

Поэтому необходимо создать полностью автоматизированный механизм для решения всех вопросов управления инфраструктурой данных.

Конечно, в идеале этот механизм автоматизации должен быть самообслуживанием, и один из самых успешных примеров — это Keystone от Netflix.

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

На уровне инфраструктуры для автоматизации установления настроек и мониторинга необходимо добиться полностью автоматизированного развертывания через IaC (Infrastructure as Code).

Чтобы решить проблему владения данными, существуют три элемента управления, связанные с разрешениями, которые также должны быть включены в IaC следующим образом.

  1. Управление доступом к удостоверениям, IAM
  2. Управление доступом на основе ролей, RBAC
  3. Список контроля доступа, ACL

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

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


Вывод

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

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

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

На самом деле, даже если мы получим автоматизированную платформу, эволюция еще не окончена.

Когда все виды бизнес-требований и все виды продуктов и услуг должны полагаться на один отдел инженеров данных, человеческие ресурсы столкнутся с узким местом. Как это решить?

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

Сетка данных рождается.

Однако существует множество различных подходов к реализации Data Mesh, и универсального архитектурного шаблона не существует.

1
Сегодня
День чистки зубов