Практика и применение Flink в Meituan

Flink

Автор: Лю Дишань

Эта статья подготовлена ​​на основе встречи Flink Meetup, состоявшейся в Пекине 11 августа, на которой поделился гость Лю Дишань (присоединился к платформе данных Meituan в 2015 году. Стремится создать эффективную и простую в использовании вычислительную платформу в реальном времени, исследуя решения корпоративного уровня). для приложений реального времени в различных сценариях и едином сервисе).

Статус и предыстория вычислительной платформы Meituan в реальном времени

архитектура платформы реального времени

На приведенном выше рисунке представлена ​​краткая архитектура текущей вычислительной платформы Meituan в реальном времени. Нижний уровень — это уровень кэша данных.Вы можете видеть, что все данные журнала Meituan Test собираются в Kafka через единую систему сбора журналов. Как крупнейший уровень передачи данных, Kafka поддерживает большое количество онлайн-сервисов Meituan, в том числе офлайн-вытягивание и некоторые сервисы обработки в реальном времени. Над слоем кэша данных находится слой движка, а слева от этого слоя — движок вычислений в реальном времени, который мы предоставляем в настоящее время, включая Storm и Flink. Ранее Storm был развернут в автономном режиме. Из-за текущей операционной среды Flink Meituan выбрала режим On YARN. В дополнение к вычислительному движку мы также предоставляем некоторые функции хранения в реальном времени для хранения промежуточных состояний, результатов расчетов, размерных данные и т. д. В настоящее время к этому типу хранилища относятся Hbase, Redis и ES. Над вычислительной машиной находится слой, который имеет тенденцию меняться, и этот слой в основном предназначен для студентов, которые разрабатывают данные. Разработка данных в реальном времени сталкивается со многими проблемами, например, гораздо сложнее отлаживать и оптимизировать программы, чем при разработке обычных программ. На уровне платформы данных вычислительная платформа реального времени, предоставляемая Meituan для пользователей, может не только размещать задания, но также выполнять настройку, диагностику, мониторинг и оповещение, а также функции извлечения данных и управления разрешениями в реальном времени. В дополнение к предоставлению вычислительной платформы в реальном времени для студентов, занимающихся разработкой данных, Meituan сейчас также занимается созданием центра метаданных. Это также является предпосылкой того, что мы хотим использовать SQL в будущем. Центр метаданных является важной частью системы потоковой передачи в реальном времени. Мы можем понимать его как мозг в системе реального времени. Он может хранить схему и мета данных. Верхний уровень архитектуры — это бизнес, поддерживаемый нашей текущей вычислительной платформой в реальном времени, которая не только включает в себя запросы в реальном времени и поиск онлайн-журналов бизнеса, но также охватывает очень популярное машинное обучение в реальном времени. Машинное обучение часто включает в себя сценарии поиска и рекомендаций.Две наиболее примечательные особенности этих двух сценариев: во-первых, будут генерироваться массивные данные в реальном времени, во-вторых, достаточно высокое количество запросов в секунду трафика. В настоящее время вычислительная платформа в реальном времени должна выполнять некоторую работу по извлечению функций в реальном времени, чтобы реализовать сервис рекомендаций по поиску приложения. Другая категория — это более распространенные сценарии, в том числе агрегация функций в реальном времени, Zebra Watcher (который можно считать службой мониторинга), хранилища данных в реальном времени и т. д.

Выше приведена краткая архитектура текущей вычислительной платформы Meituan в реальном времени.

Статус платформ реального времени

Статус-кво вычислительной платформы Meituan в реальном времени заключается в том, что рабочая нагрузка достигла почти 10 000, масштаб узлов кластера исчисляется тысячами, количество сообщений в небе достигло триллионов, а количество сообщений в пике периоды могут достигать 10 миллионов в секунду.

Болевые точки и проблемы

Meituan столкнулся с некоторыми болевыми точками и проблемами, прежде чем исследовать и использовать Flink:

  • Проблема точности вычислений в реальном времени: до исследования и использования Flink крупномасштабные операции Meituan разрабатывались на основе Storm.Основной вычислительной семантикой Storm является At-Least-Once, которая фактически оказывает некоторое влияние на обеспечение правильности. Проблема в том, что Шторм был без гражданства до Трайдента. Хотя Storm Trident обеспечивает точную разработку, которая поддерживает состояние, она основана на отправке серийных пакетов, поэтому при возникновении проблем производительность обработки может быть небольшим узким местом. Кроме того, Trident основан на микропакетной обработке, которая не отвечает относительно высоким требованиям с точки зрения задержки, поэтому не может удовлетворить некоторые услуги, требующие относительно больших задержек.

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

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

  • Высокая стоимость разработки и отладки: в кластере из почти 1000 узлов было выполнено около 10 000 заданий. Механизм распределенной обработки и способ написания кода вручную приводят к высоким затратам на разработку и отладку для студентов, изучающих разработку данных. Когда дело доходит до обслуживания, затраты на эксплуатацию и техническое обслуживание также относительно высоки.

Флинк исследует проблемы

В контексте вышеупомянутых болевых точек и проблем Meituan изучает Flink с прошлого года, уделяя особое внимание следующим четырем аспектам:

  • Вычислительная мощность ExactlyOnce

  • Возможности управления состоянием

  • Окно/присоединение/обработка времени и т. д.

  • SQL/TableAPI

Практика Flink в Meituan

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

Практика стабильности

Практика обеспечения стабильности — изоляция ресурсов

1. Рассмотрение изоляции ресурсов: по сценарию, по бизнесу

  • Пиковый период отличается, и время работы и обслуживания отличается;

  • Различные требования к надежности и задержке;

  • Сценарии применения имеют разную важность;

    2. Стратегия изоляции ресурсов:

  • теги YARN, узлы физически изолированы;

  • Изоляция автономного DataNode и узла вычислений в реальном времени;

Практика стабильности — интеллектуальное планирование

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

Практика стабильности — отказоустойчивость

1. Сбой узла/сети

  • JobManagerHA

  • Автоматически подтягиваться

В отличие от Storm, вы знаете, что Storm очень прост и груб, когда сталкивается с исключением, например, если возникает исключение, у пользователя может не быть стандартизированной обработки исключения в коде, но это не имеет значения, потому что воркер перезапустится. задание. Оно будет продолжать выполняться, и это гарантирует семантику At-Least-Once. Например, исключение тайм-аута сети может не сильно повлиять на него, но Flink отличается тем, что имеет очень высокую устойчивость к исключениям. Строго, в то время считалось, что например произойдет сбой узла или сети.Тогда проблема одной точки JobManager может быть узким местом.Если JobManager зависнет, то влияние на всю работу может быть необратимым, поэтому При рассмотрении высокой доступности другой вариант заключается в рассмотрении некоторых заданий, вызванных факторами эксплуатации и обслуживания.Кроме того, могут быть некоторые пользовательские задания, для которых не включена функция CheckPoint, но если это вызвано сбоем узла или сети. Если он зависает, Я надеюсь, что во внутреннем слое платформы будут реализованы некоторые автоматические стратегии подтягивания для обеспечения стабильности работы задания.

2. Восходящая и нисходящая отказоустойчивость

  • Повторная попытка исключения FlinkKafka08

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

3. Аварийное восстановление

  • Мультирум

  • горячий резерв

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

Платформизация Flink

Платформа Flink — управление заданиями

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

Платформа Flink — мониторинг и оповещение

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

Платформа Flink — настройка и диагностика

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

  • Обеспечьте бизнес поиском журналов, отфильтрованным по условиям

  • Предоставьте запрос бизнес-метрик с настраиваемым интервалом времени

  • Предоставляет настраиваемые оповещения для бизнеса на основе журналов и показателей.

Кроме того, я только что упомянул, что при разработке заданий в реальном времени настройка и диагностика являются сложной болевой точкой, то есть пользователям не составляет труда просматривать распределенные журналы, поэтому также предоставляется унифицированное решение. Это решение в основном предназначено для журналов и метрик. Оно будет сообщать некоторые журналы и метрики на уровне движка. Затем оно будет собирать эти исходные журналы и метрики в Kafka через унифицированную систему сбора журналов. В будущем вы можете обнаружить, что у Kafka есть два даунстрима.С одной стороны, это синхронизация данных из журналов в ES.Цель - войти в центр журналов, чтобы сделать какой-то выбор журнала.Данные записываются в OpenTSDB как будут запрашиваться агрегированные данные. С одной стороны, это отображение запроса Метрики, а с другой стороны, он включает в себя некоторые связанные тревоги, которые фактически выполняются.

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

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

В ПОРЯДКЕ

Чтобы адаптироваться к этим двум типам MQ, были сделаны разные вещи.Для онлайн-MQ ожидается одна синхронизация и несколько потреблений, чтобы не влиять на онлайн-бизнес.Для производства Kafka это offline Kafka, выполнить некоторую маскировку адресов и некоторые базовые настройки, включая некоторое управление разрешениями, а также сбор индикаторов.

Применение Flink в Meituan

Далее вы узнаете о двух реальных случаях использования Flink в Meituan. Первая — это Petra, Petra — это фактически агрегированная система индикаторов реального времени, фактически единое решение для компаний. Его основные бизнес-сценарии - это статистика на основе бизнес-времени, и рассчитываются некоторые показатели в реальном времени.Если требование - низкая задержка, у него есть еще один, потому что он ориентирован на общий бизнес, потому что бизнес может быть У каждого будет свое различные измерения.Каждый бизнес может включать в себя компьютерный зал канала приложений, а также другие измерения, которые являются уникальными для каждого бизнеса их соответствующих приложений, и эти измерения могут включать в себя больше.Другой заключается в том, что это может быть бизнес.Необходимо рассчитать некоторые составные показатели, такие как наиболее распространенный коэффициент успешности транзакций, ему может потребоваться рассчитать количество успешных платежей и коэффициент количества размещенных заказов. Во-вторых, унифицированное агрегирование индикаторов может по-прежнему быть ориентировано на систему, такую ​​как какая-то сторона B или некоторые системы мониторинга в сегменте R, тогда обращение системы к системе индикаторов означает, что я надеюсь, что агрегирование индикаторов может быть Наиболее реалистичный. Наиболее точный и работающий в режиме реального времени может давать некоторые результаты, а данные гарантируют, что нижестоящая система действительно может отслеживать текущую информацию. Картинка справа — это пример, который я показываю как метрику. Видно, что другие на самом деле аналогичны только что упомянутым, то есть включают в себя результаты агрегирования некоторых показателей различных аспектов бизнеса.

Агрегация показателей Petra в реальном времени

1. Бизнес-сценарии:

  • На основе рабочего времени (время события)

  • Мультисервисные измерения: например, приложения, каналы, компьютерные залы и т. д.

  • Расчет составного показателя: например, показатель успешных транзакций = количество успешных платежей / количество размещенных заказов.

  • Низкая задержка: вывод результатов второго уровня

2. Гарантия точности Exactlyonce

  • Механизм FlinkCheckPoint

3. Перекос данных при расчете размеров

  • Хэш ключа точки доступа

4. Допуск к поздним данным

  • Настройки окна и компромиссы между ресурсами

При использовании Flink в качестве системы обзора индикаторов в реальном времени мы фокусируемся на этих аспектах. Первый аспект — это точные расчеты, в том числе использование механизмов FLink и CheckPoint, чтобы гарантировать, что я могу выполнять расчеты без потерь и больших объемов. Во-первых, унифицированные метрики поступают в модуль предварительной агрегации. некоторые агрегации инициализации и почему они разделены на предварительную агрегацию и полную агрегацию в основном для решения одного типа проблем, включая вопрос, заданный студентом только что, который является проблемой перекоса данных.Например, в Когда горячая точка K, текущее решение состоит в том, чтобы выполнить некоторую буферизацию посредством предварительной агрегации, чтобы максимально рассредоточить K, а затем агрегировать полные модули агрегации для агрегации. На самом деле это может решить только часть проблемы, поэтому мы также будем считать, что оптимизация производительности включает в себя исследование производительности хранилища состояний. Следующие слова по-прежнему включают допуск к запоздалым данным, потому что при агрегировании индикаторов, возможно, только что упоминалось, что некоторые составные индикаторы должны быть включены, поэтому данные, от которых зависят соответствующие индикаторы, могут поступать из разных потоков, даже если они поступают из одного и того же источника. поток, это может быть Когда сообщается о каждых данных, могут быть поздние поступления. В это время необходимо допускать задержку ассоциации данных. С одной стороны, можно установить допуск запаздывания, а с другой с другой стороны, можно установить длину окна, но на самом деле в реальном сценарии приложения на самом деле есть еще одно соображение, то есть в дополнение к максимально возможному увеличению времени мы также должны учитывать реальные вычисления. стоимость, поэтому в этом отношении также были сделаны некоторые компромиссы, то индикаторы в основном после полной агрегации, результаты агрегации будут записаны обратно в Kafka, модуль синхронизации данных будет записан в OpenTSDB и, наконец, в графану для отображения индикаторы, с другой стороны, это может быть применено к модулям, синхронизированным через пакеты Facebook, для синхронизации. Перейдите к системе сигнализации, чтобы сделать некоторые индикаторы, и сигнал тревоги на основе индикаторов.

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

Платформа машинного обучения MLX

Второй тип приложения - это сценарий машинного обучения, Сценарий машинного обучения может зависеть от данных о функциях в автономном режиме и данных о функциях в реальном времени. Один основан на извлечении признаков в существующей автономной сцене, после пакетной обработки поток передается в автономный кластер. Другой — режим ближней линии.Данные из режима ближней линии — это существующие унифицированные журналы, переданные из системы сбора журналов.После обработки Flink они включают ассоциацию потоков и извлечение признаков, а затем модель обучается и передается. учебный кластер, учебный кластер будет создавать функции P, а также функции Delta, и, наконец, на эти функции будет влиять онлайн-сервис обучения. Это относительно распространенный сценарий.Например, сравнение является распространенным и относительно распространенным сценарием.В настоящее время основная часть приложения может включать в себя поиск, рекомендацию и некоторые другие сервисы.

перспективы на будущее

В будущем это может быть завершено, и ожидается, что мы сделаем еще несколько вещей в этих трех аспектах.Я также упомянул об управлении состоянием.Первый из них - это унифицированное управление состоянием, такое как унифицированное управление Sql.Я надеюсь есть унифицированное управление.Конфигурация, чтобы помочь пользователям выбрать некоторые желаемые точки отката. Другой — оптимизация производительности большого состояния, потому что, например, при выполнении двухпотоковой ассоциации данных о трафике мы также сталкиваемся с некоторыми узкими местами в производительности. о статусе RocksDB После сравнения производительности я обнаружил, что все еще есть большие различия в производительности, поэтому я надеюсь, что на основе RocksDBBackend мы сможем попытаться сделать больше оптимизаций для улучшения производительности обработки заданий. Второй аспект — Sql.Слово Sql должно заключаться в том, что каждый бит — это направление, в котором каждая компания может действовать в настоящее время, потому что ранее были некоторые исследования Sql, в том числе предоставление некоторых представлений Sql на основе Storm, но это может быть для предыдущих слов Могут быть некоторые недостатки в выражении семантики, поэтому я надеюсь, что Flink может решить эти аспекты, а также некоторые оптимизации конфигурации, включая параллелизм Sql, включая некоторые оптимизации запросов Sql, я надеюсь сказать, что во Flink В будущем мы сможем оптимизировать больше вещей, чтобы действительно включить Sql в производственную среду.

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

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

Категории