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

напиши впереди

кашель,вместе сВзрыв объема данныхиТребования к данным в режиме реального временистановится все выше и выше,а такжеРазвитие технологий больших данных заставляет предприятия постоянно модернизировать и совершенствовать свои решения.,Архитектура хранилища данных также постоянно развивается.,прошли следующие процессы соответственно：Ранний классический номерной склад Архитектура > Автономная архитектура больших данных > Lambda > Kappa > Гибридная архитектура.

p.s. Если примеры в таблице неуместны, поправьте меня.

Lambda

Принцип лямбда-архитектуры

LambdaАрхитектура Основная идея состоит в том, чтобы разделить систему больших данных на три уровня.：Batch Layer,Speed Слой и сервировка Слой. Среди них Батч Уровень отвечает за хранение набора данных и предварительный запрос полного набора данных. Скорость Уровень в основном отвечает за расчет дополнительных данных и генерацию данных в реальном времени. Views。Serving Уровень используется для ответа на запросы пользователей. Он будет выполнять пакетную обработку. Просмотры и режим реального времени Результаты представлений объединяются для получения окончательного результата и возвращаются пользователю, как показано ниже.

Недостатки архитектуры Lambda

Lambda Архитектура решает проблему вычислений в реальном времени при больших объёмах данных, но сама Архитектура имеет и определённые недостатки.

• Живите с пакетным расчет Проблемы с калибром данных, вызванные противоречивыми результатами：Из-за партиии Расчет в реальном времениизэто две вычислительные платформыипрограмма расчета,Результаты расчетов часто отличаются,В тот день я часто вижу число и смотрю на него как на данные.,На следующий день я посмотрел вчерашние данные, и они изменились.
• Пакетный расчет невозможно завершить в пределах вычислительного окна: в эпоху Интернета вещей,Объем данных становится все больше и больше,Часто оказывается, что ночью окно длится всего 4 или 5 часов.,Восполнить данные, накопленные более чем за 20 часов в течение суток, уже невозможно.,Обеспечение своевременной доступности данных перед утренним выходом на работу стало головной болью для каждой команды, занимающейся большими данными.
• Проблемы сложности при разработке и сопровождении: Lambda Архитектура должна быть двух разных API（application programming интерфейс (Application Programming Interface), одна и та же бизнес-логика программируется дважды: один раз для Пакетный расчетизETLсистема,Потоковая система для потоковых вычислений. Для одной и той же бизнес-задачи были созданы две базы кода.,У каждого есть разные уязвимости. Такую систему на самом деле очень сложно поддерживать.
• Большое серверное хранилище. Типичная конструкция хранилища данных генерирует большое количество таблиц промежуточных результатов, что приводит к быстрому расширению данных и увеличению нагрузки на серверное хранилище.

Kappa

Принцип архитектуры каппы

Основные идеи Kappa Архитектура включают в себя следующие три пункта:

• Используйте Kafka или аналогичную распределенную систему очередей для сохранения данных. Вы можете сохранять данные столько дней, сколько вам нужно.
• Когда требуется полный пересчет, экземпляр потокового вычисления перезапускается, данные считываются с начала для обработки и выводятся в новое хранилище результатов.
• Когда новый экземпляр будет завершен,Остановите старый экземпляр Stream Compute.,И выложите некоторые результаты старого удаления.

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

Сравнение преимуществ и недостатков архитектуры Lambda и архитектуры Kappa.

краткое содержание

• Lambda объединяет полный объем исторических данных и дополнительных данных в реальном времени и выводит их.
• Два потока Kappa сотрудничают при выводе, и запросы каждый раз используют последний результат обработки потока.

Редактору есть что сказать

В настоящее время многие решения для инкрементальной пакетной обработки в квазиреальном времени также могут отвечать требованиям реального времени с точки зрения стабильности и производительности. на эксплуатацию и техническое Он также показал лучшие результаты в обслуживании. Например, решение квазиреального времени «kudu» (хранилище) + «impala» (вычисления) может реализовывать инкрементальные обновления и запросы olap десятков миллионов данных с превосходной производительностью.

Портал серии хранилищ данных: https://blog.csdn.net/weixin_39032019/category_8871528.html.