Платформа функций реального времени Ctrip на основе Flink

Автор: Лю Кан

Эта статья взята с конференции Flink Meetup, состоявшейся в Шанхае 26 июля, а сообщением поделился Лю Канг. В настоящее время он занимается разработкой платформ, связанных с жизненным циклом модели, в отделе платформ больших данных. Сейчас он в основном отвечает за разработка платформы для вычисления признаков модели в реальном времени на основе flink. Знаком с распределенными вычислениями, имеет богатый практический опыт и глубокое понимание развертывания, эксплуатации и обслуживания модели, а также имеет определенное понимание алгоритма модели и обучения.

Основное содержание этой статьи следующее:

Основываясь на текущем статусе разработки функций реального времени в компании, объясните историю разработки, цели и статус-кво платформы функций реального времени.
Причины выбора Flink в качестве вычислительного движка платформы
Практика Flink: репрезентативные примеры использования, разработка для совместимости с Aerospike (носитель данных платформы) и обнаруженные подводные камни.
Текущие эффекты и планы на будущее

1. Основываясь на текущей ситуации с разработкой функций реального времени в компании, объясните предысторию разработки, цели и статус-кво платформы функций реального времени.

1. Разработка, эксплуатация и сопровождение оригинальной функции реального времени;

1.1. Выберите платформу вычислений в реальном времени: В соответствии с требованиями индекса производительности проекта (задержка, пропускная способность и т. д.) выберите существующую платформу вычислений в реальном времени: Storm Spark flink

1.2 Основной процесс разработки и обслуживания:

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

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

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

2. Болезненные моменты разработки оригинальной функции в реальном времени

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

3. Основываясь на болевых точках сортировки, определите цели платформы

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

4. Архитектура системы функциональной платформы

Текущая архитектура представляет собой стандартную лямбда-архитектуру, а автономная часть состоит из spark sql + dataX. Сейчас используется система хранения KV Aerospike.Основное отличие от redis в том, что в качестве основной памяти используется SSD.Мы протестировали производительность чтения и записи большинства сценариев на том же уровне данных, что и redis.

Часть в реальном времени: используйте flink в качестве вычислительного движка и расскажите, как его используют пользователи:

Регистрация источников данных: в настоящее время поддерживаемыми источниками данных в реальном времени являются Kafka и Aerospike.Если данные в Aerospike являются автономной функцией или функцией реального времени, настроенной на платформе, они будут автоматически зарегистрированы. Источник данных Kafka должен загрузить соответствующий файл schemaSample.
Вычислительная логика: выражается через SQL
Определите вывод: определите таблицу выходных данных Aerospike и тему Kafka, которая может потребоваться, ключ, используемый для отправки данных обновления или вставки.

После того, как пользователь выполнит вышеуказанные операции, платформа записывает всю информацию в конфигурационный файл json. На следующем шаге платформа отправляет файл конфигурации и ранее подготовленный файл flinkTemplate.jar (содержащий функции flink, необходимые для всех платформ) в yarn и запускает задание flink.

5. Отображение функций платформы

1) Отображение функций платформы - регистрация источника данных

2) Редактирование объектов в реальном времени — основная информация

3) Редактирование объектов в реальном времени — выбор источника данных

4) Редактирование функций в реальном времени - расчет SQL

5) Редактирование объектов в реальном времени — выберите вывод

2. Причины выбора Flink

Давайте поговорим о причинах, по которым мы выбрали flink в качестве этой функциональной платформы.

Разделено на три измерения: максимальная задержка, отказоустойчивость, зрелость функции sql.

Задержка: Storm и flink — это чистая потоковая передача с минимальной задержкой в миллисекунды. Механизм чистой потоковой передачи Spark представляет собой непрерывный режим, который также может достигать минимальной задержки в миллисекундах.
Отказоустойчивость: Storm использует режим подтверждения XOR и поддерживает atLeastOnce. Дублирование сообщений не устранено. Spark обеспечивает ровно один раз через контрольную точку и WAL. Flink делает ровно один раз через контрольную точку и точку сохранения.
Зрелость SQL: в текущей версии Storm SQL все еще находится на экспериментальной стадии и не поддерживает агрегацию и объединение. Теперь Spark может предоставлять большинство функций, но не поддерживает различение, ограничение и упорядочение агрегированных результатов. SQL-запрос, предоставляемый flink теперь в версии сообщества, не поддерживает отдельные агрегаты.

3. Практика флинка

1. Практический пример

2. Совместимая разработка: в настоящее время flink не поддерживает чтение и запись для Aerospike, поэтому требуется дополнительная разработка.

3. Встречающаяся яма

4. Текущий эффект платформы и планы на будущее

Текущий эффект: период запуска функции в реальном времени был сокращен с первоначального среднего значения в 3 дня до 5 дней до часового уровня. будущий план:

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

Следующий план — описать развертывание модели и обучение модели с помощью sql или DSL.

Для получения дополнительной информации, пожалуйста, посетитеВеб-сайт китайского сообщества Apache Flink