Как спроектировать платформу данных в реальном времени (дизайн)

Большое количество данных

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

1. Сопутствующая концептуальная основа

1.1 Платформа данных реального времени с точки зрения современной архитектуры хранилища данных

Современные хранилища данных разрабатываются на основе традиционных хранилищ данных.По сравнению с традиционными хранилищами данных современные хранилища данных имеют как сходства, так и точки развития. Во-первых, давайте взглянем на модульную архитектуру традиционного хранилища данных (рис. 1) и современного хранилища данных (рис. 2):

Рис. 1. Традиционное хранилище данных

Рис. 2. Современное хранилище данных

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

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

Современное хранилище данных — это большая тема, здесь мы показываем его новые функции и возможности в виде концептуальных модулей. Во-первых, давайте взглянем на сводку Мелиссы Коутс на рисунке 3:

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

Основываясь на обзоре современных хранилищ данных Мелиссы Коутс и на нашем собственном понимании, мы также обобщаем и выделяем несколько важных возможностей современных хранилищ данных, а именно:

  • Данные в реальном времени (синхронизация в реальном времени и возможности потоковой передачи)

  • Виртуализация данных (виртуальное микширование и унифицированные сервисные возможности)

  • Демократизация данных (возможности визуализации и самонастройки)

  • Совместная работа с данными (мультиарендность, разделение труда и возможности совместной работы)

1) Данные в реальном времени (синхронизация в реальном времени и возможности потоковой передачи)

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

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

2) Виртуализация данных (виртуальные смешанные вычисления и унифицированные сервисные возможности)

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

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

Рис. 4 Виртуализация данных

(Все рисунки 1–4 взяты из статьи «Проектирование современного хранилища данных + озеро данных» — Мелисса Коутс, архитектор решений, BlueGranite)

3) Демократизация данных (визуализация и возможности самоконфинанже)

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

Для интерпретации демократизации данных вы также можете обратиться к следующим ссылкам:

Woohoo Forbes.com/sites/Bernard…

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

4) Совместная работа с данными (мультиарендность, разделение труда и возможности совместной работы)

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

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

1.2 Обработка данных в режиме реального времени с точки зрения типичной обработки данных

Типичная обработка данных может быть разделена на OLTP, OLAP, потоковую передачу, Adhoc, машинное обучение и т. д. Вот определение и сравнение OLTP и OLAP:

(Рисунок 5 взят из статьи «Реляционные базы данных не предназначены для смешанных рабочих нагрузок» — Мэтт Аллен)

С определенной точки зрения действия OLTP в основном происходят на стороне базы данных бизнес-транзакций, а действия OLAP в основном происходят на стороне базы данных анализа данных. Итак, как данные передаются из библиотеки OLTP в библиотеку OLAP? Если своевременность этого потока данных очень высока, традиционный метод пакетного ETL T+1 не может быть удовлетворен.

Мы называем процесс потока от OLTP к конвейеру данных OLAP, который относится ко всем каналам потока и обработки между производственной и конечной сторонами данных, включая извлечение данных, синхронизацию данных, потоковую обработку и хранение данных, запрос данных, и т.п. Могут быть очень сложные преобразования обработки данных (например, преобразование повторяющихся семантических разнородных источников данных с несколькими источниками в унифицированную звездную схему, преобразование подробных таблиц в сводные таблицы, объединение таблиц с несколькими сущностями в широкие таблицы и т. д.) . Как поддерживать возможности конвейерной обработки в реальном времени становится сложной темой, которую мы описываем как проблему «онлайн-конвейерной обработки» (OLPP).

Таким образом, платформа данных реального времени, обсуждаемая в этой статье, надеется решить проблему OLPP с точки зрения обработки данных и стать решением проблемы отсутствия передачи данных в реальном времени из OLTP в OLAP. Далее мы обсудим, как спроектировать такую ​​платформу данных в реальном времени на архитектурном уровне.

2. Схема архитектурного проектирования

2.1 Позиционирование и таргетинг

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

2.2 Общая архитектура проекта

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

Рисунок 6 Общая концептуальная архитектура модуля RTDP

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

Рис. 7 Общая идея дизайна

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

  • Единая платформа сбора данных

  • Единая стриминговая платформа

  • Платформа унифицированных вычислительных услуг

  • Единая платформа визуализации данных

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

1) Единая платформа сбора данных

Унифицированная платформа сбора данных может поддерживать как полное извлечение из различных источников данных, так и расширенное извлечение. Среди них добавочное извлечение бизнес-базы данных выберет чтение журнала базы данных, чтобы уменьшить давление чтения на бизнес-базу данных. Платформа также может единообразно обрабатывать извлеченные данные, а затем публиковать их на шину данных в едином формате. Здесь мы выбираем настраиваемый стандартизированный унифицированный формат сообщений UMS (Unified Message Schema) в качестве протокола уровня данных между унифицированной платформой сбора данных и унифицированной платформой потоковой обработки.

UMS поставляется с информацией о пространстве имен и информацией о схеме, которая представляет собой формат протокола сообщений с самопозиционированием и самоинтерпретацией.

  • Вся архитектура не должна полагаться на внешнюю платформу управления метаданными;

  • Сообщения отделены от физических носителей (здесь под физическими носителями понимаются такие темы, как Kafka Topic, Spark Streaming Stream и т. д.), поэтому несколько потоков сообщений могут быть распараллелены через физические носители, а также может поддерживаться свободный дрейф потоков сообщений.

Платформа также поддерживает многопользовательские системы и настраивает простые возможности обработки и очистки.

2) Единая стриминговая платформа

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

  • Поддержка визуализации/конфигурации/SQL-подхода для снижения порога разработки/развертывания/управления логикой потоковой передачи

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

  • Поддержка многопользовательской системы для достижения изоляции вычислительных ресурсов/ресурсов таблиц/ресурсов пользователей на уровне проекта.

3) Единая вычислительная сервисная платформа

Платформа унифицированных вычислительных услуг представляет собой реализацию виртуализации/объединения данных. Внутри платформа поддерживает вычисления push-down и Mixed-pull-вычисления из нескольких разнородных источников данных, а также внешний унифицированный сервисный интерфейс (JDBC/REST) ​​и унифицированный язык запросов (SQL). Поскольку платформа может унифицировать службу, она может создавать унифицированное управление метаданными/управление качеством данных/аудит безопасности данных/политику безопасности данных и другие модули на основе платформы. Платформа также поддерживает мультиарендность.

4) Единая платформа визуализации данных

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

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

2.3 Конкретные вопросы и соображения

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

1) Функциональные соображения

Функциональные соображения в основном обсуждают такой вопрос: может ли конвейер реального времени обрабатывать всю сложную логику ETL?

Мы знаем, что для движков потоковых вычислений, таких как Storm/Flink, данные обрабатываются для каждого элемента, для движка потоковых вычислений Spark Streaming — для мини-пакетов, а для офлайн-задач, выполняющихся в пакетном режиме, — для обрабатываемых данных за день. Таким образом, диапазон обработки — это одно измерение данных (измерение диапазона).

Кроме того, потоковая обработка ориентирована на добавочные данные.Если источник данных поступает из реляционной базы данных, то добавочные данные часто относятся к данным добавочного изменения (добавление, удаление, ревизия); относительная пакетная обработка ориентирована на данные моментального снимка (snapshot) . Таким образом, форма представления — это еще одно измерение (изменение измерения) данных.

Измененное измерение отдельного фрагмента данных может быть спроецировано и объединено в единый снимок, поэтому измененное измерение может быть объединено в измерение диапазона. Таким образом, существенное различие между потоковой обработкой и пакетной обработкой заключается в том, что диапазон данных и размеры, с которыми приходится сталкиваться, различны.Единица потоковой обработки — это «ограниченный диапазон», а единица пакетной обработки — «полный диапазон таблицы». Данные «полного диапазона таблиц» могут поддерживать различные операторы SQL, тогда как данные «ограниченного диапазона» могут поддерживать только некоторые операторы SQL. Конкретные условия поддержки следующие:

  • присоединиться:

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

✔ правое соединение: не поддерживается. Невозможно и неразумно каждый раз извлекать все данные таблицы поиска из поиска.

✔ межсоединение: поддержка. Может быть преобразован в левое соединение + фильтр, может поддерживать

✔ внешнее соединение: не поддерживается. Есть правильное соединение, так что это не разумно

  • союз: поддержка. Его можно применять для извлечения данных локального диапазона для операций агрегирования окон.

  • агг: не поддерживается. Вы можете использовать объединение для локального агрегирования окон, но оно не поддерживает операции агрегирования полных таблиц.

  • фильтр: поддержка. Никакой перетасовки, идеально подходит для этого.

  • карта: поддержка. Никакой перетасовки, идеально подходит для этого.

  • проект: поддержка. Никакой перетасовки, идеально подходит для этого.

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

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

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

Рис. 8. Эволюция архитектуры обработки данных

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

2) Вопросы качества

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

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

3) Вопросы стабильности

Эта тема включает, но не ограничивается следующими пунктами, вот простой способ справиться с этим:

  • Высокая доступность HA

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

  • Гарантия SLA

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

  • упругий антихрупкий

✔ Эластичное масштабирование ресурсов на основе правил и алгоритмов

✔ Поддержка обработки сбоев механизма действий, инициируемого событиями.

  • Мониторинг и раннее предупреждение

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

  • Автоматическая работа и обслуживание

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

  • Устойчивость к изменению метаданных восходящего потока

✔ Базовые бизнес-библиотеки требуют изменения метаданных совместимости.

✔ Live Pipeline обрабатывает явные поля

4) Соображения стоимости

Эта тема включает, но не ограничивается следующими пунктами, вот простой способ справиться с этим:

  • Расходы на оплату труда

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

  • стоимость ресурсов

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

  • Стоимость эксплуатации и обслуживания

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

  • цена проб и ошибок

Сокращение затрат на пробы и ошибки за счет поддержки гибкой разработки/быстрой итерации

5) гибкие соображения

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

6) Вопросы управления

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

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

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

Автор: Лу Шаньвэй

Источник: Технологический институт CreditEase.