Как разработать стандартный пакет SQL для надежного потокового процесса?

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

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

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

• Изменяющиеся во времени отношения
• Семантика времени события
• Контроль материализации

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

• Apache Spark:
  Этот декларативный API, созданный на основе механизма выполнения и оптимизатора Spark SQL, на самом деле является API набора данных Spark. Обычно программы набора данных выполняются на конечных потоках данных. Потоковая передача для Dataset API широко известна как структурированная потоковая передача . Запросы структурированной потоковой передачи оцениваются с помощью механизма выполнения микропакетов, который обрабатывает потоки данных небольшими партиями и находит гарантии отказоустойчивости.
• KSQL:
  Он построен на потоках Kafka, которые представляют собой среду обработки потоков, разработанную в рамках проекта Apache Kafka. KSQL - это декларативная оболочка, которая охватывает потоки Kafka и разрабатывает индивидуальный синтаксис типа SQL для объявления потоков и таблиц. Он больше ориентирован на семантику материализованного представления.
• Apache Flink:
  Он состоит из двух реляционных API-интерфейсов: API таблиц стилей LINQ и SQL. Он использует представление общего логического плана и оптимизированный кальцит Apache для запросов от обоих реляционных API. Затем выполнение происходит как пакетный или потоковый процесс.
• Луч Apache:
  Он специально разработан с учетом оптимизации объединения луча для ограниченной и неограниченной обработки данных. Он использует подмножество семантики для выполнения потоков данных.
• Кальцит Apache:
  Это популярный потоковый анализатор SQL в Flink SQL и Beam SQL. Он анализирует, оптимизирует и поддерживает семантику потоковой обработки.

  Теперь давайте рассмотрим три новых подхода к потоковой передаче SQL.

• Изменяющиеся во времени отношения:
  В данной методике основное внимание уделяется элементу «Время» . Всякий раз, когда мы имеем дело с потоковыми отношениями, мы должны учитывать относительные временные отношения, которые меняются во времени. В этом случае мы можем использовать изменяющееся во времени отношение (TVR), которое представляет собой тип отношения, содержание которого изменяется с течением времени.

  TVR могут быть закодированы или материализованы разными способами, особенно как последовательность классических отношений или как последовательность операций «INSERT» и «DELETE». Эти два кода двойственны друг другу и соответствуют таблицам и потокам. Хотя двойственность кодов может быть проблемой, мы намерены использовать ее как преимущество.

  
  
  
  

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

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

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

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

• Контроль материализации:
  Этот подход обеспечивает контроль над тем, как отношения отображаются при материализации строк. В первом подходе мы можем использовать журналы изменений потока, которые фиксируют различия между элементами между двумя версиями отношения, а затем используют последовательность кодирования INSERT и DELETE для изменения TVR.

  Другой подход - « Задержка материализации » - этот подход используется путем моделирования таблиц и потоков как TVR, и в результате получается отношение TVR.

Пример, основанный на тесте NEXmark для запросов к потокам данных:

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

Запрос на CQL: