Исследование и практика G7 в вычислениях в реальном времени

Автор: Чжан Хао

Краткая информация о бизнесе G7

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

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

Бизнес-сценарии G7 — это типичные сценарии IoT:

данные датчика
Много видов данных
плохое качество данных
Низкая задержка данных
Большой объем данных

Среди них причиной низкого качества данных является то, что вся цепочка будет очень длинной.Данные о транспортном средстве, собранные с датчика, передаются на внутренний сервер через оператора сети, а затем данные анализируются, mq, фильтруются. , называемый сторонним интерфейсом, бизнес-обработкой, хранилищем, весь процесс очень долгий, что приводит к дублированию данных и отсутствию данных в процессе передачи. Другой момент заключается в том, что сценарии IoT требуют очень малой задержки в передаче данных, например, при входе и выходе из зоны тревоги.Когда транспортное средство входит в определенное электронное ограждение, должна срабатывать тревога.В это время необходимо генерировать событие тревоги. быстро, обычно не более 30 секунд, в противном случае время слишком велико.Нет смысла вызывать полицию после того, как транспортное средство проехало определенную зону электронного ограждения. С другой стороны, объем данных также очень велик, сейчас каждый день генерируется более 2 млрд точек траектории, а объем данных, генерируемых каждый день, составляет более 10 млрд. Требования к производительности вычислений очень высоки.

Расчет и выбор в реальном времени

Из приведенного выше сценария мы можем понять, что в сценарии IoT G7 требуется вычислительный механизм в реальном времени с малой задержкой и высокой скоростью обработки. Вначале некоторые из наших архитектур были основаны на лямбда-архитектуре, например, расчет точек траектории, который будет использовать вычислительный механизм в реальном времени для расчета данных в реальном времени.Эти данные имеют низкую задержку, но данные не очень точны. , Кроме того, его необходимо вычислять снова в пакетах в автономном режиме.Данные копирования обычно более точны и могут использоваться для восстановления данных в реальном времени. Недостатки этого метода также очевидны: во-первых, программе необходимо поддерживать два набора кодов: программа реального времени и программа офлайн, во-вторых, данные в реальном времени неточны, а задержка точных данных слишком велика. Позже мы были приятно удивлены, обнаружив Kappa — архитектуру, основанную на обработке данных в реальном времени.

Архитектура Kappa подчеркивает характер данных в реальном времени.Чтобы обеспечить характер данных в реальном времени, рекомендуется отбрасывать некоторые данные со слишком большой задержкой.Вся логика расчета только в расчете в реальном времени , Весь расчет имеет только один набор логики, а данные получаются из MQ.После того, как уровень обработки данных рассчитан и обработан, он, наконец, попадает на уровень хранения данных, чтобы обеспечить функции запроса внешних данных. По сравнению с архитектурой Lambda архитектура Kappa больше подходит для области IoT.

Для архитектуры Kappa мы сравнили основные отраслевые фреймворки для потоковых вычислений в реальном времени:

Сравниваются основные среды потоковых вычислений: Storm, Storm Trident, Spark Streaming, Google Cloud Dataflow и Flink. Spark Streaming и Storm Trident на основе микропакетов имеют высокую задержку, что не подходит для нашего сценария с этой точки зрения. Задержка Storm очень низкая, но согласованность данных хотя бы один раз, механизм отказоустойчивости сложнее, а управление потоком будет более дрожащим.Эти аспекты не подходят. Среди них гарантия согласованности Flink (версия 1.4 также поддерживает сквозную согласованность), относительно низкая задержка, относительно небольшие накладные расходы на механизм отказоустойчивости (на основе распределенного моментального снимка Chandy-Lamport) и управление потоком. относительно элегантный (передача данных между операторами основан на очередях блокировки распределенной памяти), логика приложения и отказоустойчивость разделены (операторская обработка и распределенная контрольная точка моментальных снимков), исходя из вышеизложенного, мы считаем, что flink больше подходит для сценария IoT.

Пример бизнес-приложения G7 Текущие сценарии применения Flink в G7 в основном включают три аспекта:

вычисления в реальном времени
ETL в реальном времени
Статистический анализ

Использование трех описанных выше сценариев описано ниже.

вычисления в реальном времени

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

Бизнес-модель сигнализации усталости

Это большой экран G7, запущенный G7 для клиентов, в котором часть, связанная с риском, рассчитывается на основе усталости.

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

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

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

Бизнес-процесс

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

Потоковая модель

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

Этот процесс тоже наступил на немало ям, и у нас тоже есть кое-какой опыт:

Операторное выражение должно быть максимально простым.
Каждый оператор максимально связан, а связь между операторами минимальна.
Операторы разбросаны, а производительность асинхронности + многопоточности лучше
Установите степень параллелизма каждого операторского блока отдельно для лучшей производительности
Хэш и баланс выбираются в зависимости от ситуации: используйте хеш только для перераспределения данных, где требуются keyby и valuestate. Максимально используйте баланс в других местах, а параллелизм восходящего и нисходящего потоков одинаков, задачи будут конкатенированы в поток, и производительность ввода-вывода будет выше без прохождения через сеть.
Используйте асинхронный ввод-вывод для вызова интерфейса dubbo, zuul, db, hbase и других внешних интерфейсов.

ETL в реальном времени

В некоторых сценариях данные просто собираются, обрабатываются и сохраняются, то есть ETL в реальном времени, включая сбор данных из Kafka в HDFS, DB, HBase, ES, Kafka и т. д. Эту часть работы можно абстрагировать в Flink’s выражение оператора: Источник -> Преобразование -> Приемник.

Эта часть обычно может быть кодом, таким как FlinkKafkaConumser, MapFunction, JDBCAppendTableSink. следующее:

Статистический анализ

Некоторые сценарии требуют некоторого статистического анализа в режиме реального времени, например, подсчет общего количества транспортных средств, общего количества водителей, событий усталости, событий входа и выхода, количества перфокарт, событий выключения зажигания и т. д. в городах по всей стране в регионе. последний час. В этом сценарии обычно можно использовать Flink SQl для анализа в реальном времени, функцию sql+window (фиксированное окно, скользящее окно). Код примерно такой:

Разработка и состояние платформы вычислений в реальном времени

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

Glink в основном состоит из следующих частей:

Распределенная файловая система HDFS. Он используется для хранения данных контрольной точки/точки сохранения, сгенерированных в задачах flink, хранения и распространения отчетов о задачах, сторонних зависимых пакетов, временных данных, сгенерированных во время выполнения задачи, и т. д.;
Платформа унифицированных вычислительных ресурсов Yarn. Он используется для обеспечения единой платформы распределенных вычислительных ресурсов, отправки задач, планирования задач, выполнения задач и функций изоляции ресурсов. В настоящее время все задачи flink представляют собой унифицированное управление вычислительными ресурсами через пряжу;
Инструмент для мониторинга производительности AMP. Используйте Cat of Dianping с открытым исходным кодом и на этой основе выполните вторичную разработку и назовите ее «Система Тяньшу». Он может предоставить программы, занимающие 95, 99 строк, среднее время, максимальное время, мониторинг Java GC, мониторинг потоков, информацию о стеке и т. Д .;
Мониторинг и управление кластером. Мониторинг машинных ресурсов использует zabbix для обеспечения процессора, памяти, дискового ввода-вывода, сетевого ввода-вывода, количества подключений и контроля обработки. Мониторинг и управление ресурсами кластера использует Ambari с открытым исходным кодом для обеспечения автоматической установки, настройки, общих задач кластера, памяти, ресурсов процессора, пространства hdfs, мониторинга размера ресурсов пряжи и оповещения;
Сигналы мониторинга задач. Используйте генератор отчетов statsD, предоставленный flink, для передачи данных в базу данных временных рядов InfluxDB, рисуйте поток обработки задачи, сканируя данные Infludb, и сигнализируйте, отслеживая, что порог потока ниже ожидаемого значения;
Диагностическая отладка. Используя зрелую систему запросов журналов es+logstash+kibana, собирая журналы каждого узла и записывая их в es, вы можете запрашивать ключевую информацию в kibana, чтобы получить память журнала и предоставить подсказки для диагностики и настройки программ;
Прикладной уровень приложения Flink. Специально разработанные приложения flink обычно решают сценарии ETL, статистического анализа и бизнес-вычислений в реальном времени;
Платформа управления и контроля задач Glink. Следующие функции инкапсулированы для обеспечения унифицированного управления задачами и функциями управления эксплуатацией и обслуживанием.

Демонстрация вычислительной платформы в реальном времени — управление задачами

Демонстрация вычислительной платформы в режиме реального времени — ведение журнала и мониторинг производительности

Представлены некоторые функции платформы:

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

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

Среда разработки Glink-Framework

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

Glink-Framework предоставляет следующие пакеты:

Упростите файл pom и уменьшите количество зависимостей и конфигураций плагинов;
Интеграция трехсторонних вызовов: dubbo, zuul;
Интеграция со сторонними базами данных: mysql, redis;
Управление несколькими средами;
управление версиями зависимостей;
Инструменты для мониторинга кода: checkstyle, pmd, findbugs.

Путь сотрудничества между платформой и бизнес-стороной BP

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

Ступай на яму

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

Слишком большой параллелизм приводит к тому, что выравнивание барьера занимает больше времени, а время выравнивания подзадачи с параллелизмом 28 превышает 50 с;
Valuestate не может использоваться совместно операторами;
коннектор flink1.3 kafka не поддерживает увеличение раздела;
В сочетании с spring возникает проблема сопоставления обработчиков;
Есть проблема, что программа не может нормально запуститься из-за конфликта пакетов хаупа и исключения нет;

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

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

Некоторые операторы программы, работающей в сети, терпят неудачу, поскольку время выравнивания барьера превышает 50 с, что приводит к сбою времени ожидания контрольной точки программы. Для этой задачи у нас две стратегии настройки.Одна - минимизировать степень параллелизма, то есть минимизировать поток потоков в оператор.Если он находится в пределах 4-х барьеров, время выравнивания относительно невелико. Другой способ — использовать семантику по крайней мере один раз, чтобы заменить семантику ровно один раз, так что выравнивание барьера не будет выполняться во время контрольной точки, а данные будут проверены сразу и отправлены вниз по течению, когда данные поступят к оператору. В настоящее время наше решение состоит в том, чтобы различать в соответствии с различными бизнес-сценариями.Если использование гарантии данных хотя бы один раз может удовлетворить потребности бизнеса, попробуйте использовать семантику хотя бы один раз. Если он не поддерживается, уменьшите параллелизм, чтобы уменьшить количество и время данных, выровненных по барьеру.

Доход платформы

Благодаря недавнему строительству платформы преимущества «снижения затрат и повышения эффективности» в основном отражены в следующих аспектах:

Улучшено использование ресурсов. В настоящее время при мониторинге всего кластера средняя загрузка ЦП составляет около 20 % в случае смешанного развертывания, а загрузка ЦП в некоторых вычислительных службах с интенсивным использованием ЦП будет выше;
Повышение эффективности разработки. Например, для разработки программы сбора ETL при традиционной разработке требуется около 1 дня для сбора данных, преобразования и сохранения их в хранилище, а разработка простой программы ETL с использованием платформенного подхода может быть завершена в течение 1 часа. ;
Объем обработки данных большой. Среднесуточный объем обработки данных составляет более 8 миллиардов;
Охват бизнеса широкий. Платформа запустила более 30 предприятий и, как ожидается, превысит 100+ в течение этого года. Обслуживание всех направлений бизнеса компании, платформы IoT, EMS, FMS, интеллектуальных трейлеров, корпоративных решений, SaaS, аппаратных отделов и т. д.

будущий план

При будущем планировании flink мы в основном сосредоточимся на цели «снижения затрат и повышения эффективности, а также на предоставлении единой вычислительной платформы», в основном уделяя внимание следующим аспектам: 1. Более тщательная изоляция ресурсов. Текущая изоляция ресурсов использует стандартный метод изоляции пряжи только для изоляции памяти.В будущем пряжа+cgroup должна использоваться для изоляции памяти и ЦП. Кроме того, мы рассмотрим использование метки узла пряжи для полной изоляции на уровне машины и разделим разные типы машинных ресурсов для разных предприятий.Например, задачи с высокой загрузкой ЦП соответствуют машинам с интенсивным использованием ЦП, а задачи с высокой нагрузкой ввода-вывода соответствуют машинам с более высокой производительностью. ИО;

Улучшено удобство использования платформы. Платформа включает в себя выпуск кода, отладку, отладку, мониторинг, устранение неполадок и комплексное решение проблем;
Уменьшить код. При использовании функции Flink SQL+UDF часто используемые методы и функции инкапсулируются, а бизнес максимально выражается в SQL для повышения эффективности разработки. Кроме того, будет также рассмотрена поддержка сопоставления с образцом CEP.В настоящее время многие службы могут поддерживаться динамическим CEP;
Универсальные подмости. Непрерывная разработка на Glink-Framework, предоставление большего количества источников, приемников, инструментов и т. д., бизнес-инкапсуляция и упрощение разработки;

Эта статья является выдержкой из технического сообщения Ю Чжанхао на «Оффлайн-встрече сообщества Flink China · Chengdu Station».

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