Эта статья взята с конференции Apache Flink China Meetup, которая состоялась в Чэнду 1 сентября.Юньсеобмена.
Добавить Автора
Организатор: Ли Зеджу (волонтер сообщества Flink China)
Вычитка: Юнь Се / Хань Фей (волонтер сообщества Flink China)
Знакомство с Флинком
Flink — это распределенный вычислительный движок, который можно использовать для пакетной обработки, то есть для обработки статических наборов данных и наборов исторических данных, а также для потоковой обработки, то есть для обработки некоторых потоков данных в реальном времени в реальном времени. время и генерировать данные в режиме реального времени в режиме реального времени. Результат данных; его также можно использовать для некоторых приложений, основанных на событиях. Например, Didi использует Flink CEP для мониторинга потока поведения пользователей и водителей в режиме реального времени, чтобы определить законно ли поведение пользователей или водителей.
В общем, Flink — это Stateful Computations Over Streams, то есть вычисление с сохранением состояния над потоками данных. Здесь есть два ключевых слова: одно — потоки.Флинк считает, что ограниченный набор данных — это частный случай неограниченного потока данных, поэтому ограниченный набор данных — это тоже разновидность потока данных, а поток событий — тоже разновидность потока данных. Все — это потоки, то есть Flink можно использовать для обработки любых данных, а также он может поддерживать пакетную обработку, потоковую обработку, ИИ, машинное обучение и многое другое. Еще одно ключевое слово — Stateful, то есть вычисления с отслеживанием состояния. Вычисления с отслеживанием состояния — это функция, которая в последние годы все чаще запрашивается пользователями. Приведите пример, чтобы проиллюстрировать значение статуса, например, количество UV, к которым обращался веб-сайт в день, тогда количество UV является статусом. Flink обеспечивает встроенную обработку консистентности состояния, то есть при сбое задачи ее состояние не будет потеряно, и оно не будет пересчитано, обеспечивая при этом очень высокую производительность.
Популярность Flink неотделима от многих его ярлыков, включая отличную производительность (особенно в области потоковых вычислений), высокую масштабируемость и поддержку отказоустойчивости.Это вычислительный движок с чистой памятью, который делает память Большое количество оптимизаций в управление, в дополнение к поддержке обработки даже во времени, поддержка заданий с большим состоянием (в Alibaba размер состояния задания превышает ТБ очень распространен), поддерживает однократную обработку.
Флинк краеугольный камень
Причина, по которой Flink так популярен, неотделима от его четырех наиболее важных краеугольных камней: контрольной точки, состояния, времени и окна.
Во-первых, это механизм Checkpoint, который является наиболее важной функцией Flink. Flink реализует распределенный согласованный моментальный снимок на основе алгоритма Чанди-Лампорта, обеспечивая тем самым согласованную семантику. Алгоритм Чанди-Лэмпорта был фактически предложен в 1985 году, но не получил широкого распространения, и Флинк развил этот алгоритм. Недавно в Spark реализована функция «Продолжить потоковую передачу». Цель этой функции — уменьшить задержку обработки. Он также должен обеспечивать такую непротиворечивую семантику. Наконец, используется алгоритм Чанди-Лампорта, который показывает, что алгоритм Чанди-Лампорта определенная степень в отрасли.
После предоставления согласованной семантики Flink также предоставляет набор очень простых и понятных API-интерфейсов состояния, чтобы упростить пользователям управление состоянием во время программирования, включая недавно добавленные ValueState, ListState, MapState. State API автоматически использует эту согласованную семантику.
Кроме того, Flink также реализует механизм водяных знаков, который может поддерживать обработку времени на основе событий или обработку на основе системного времени и может допускать задержку данных, задержку данных и неупорядоченные данные.
Кроме того, в потоковых вычислениях оконная обработка обычно выполняется до обработки потоковых данных, то есть в зависимости от типа окна, в котором выполняются вычисления. Flink предоставляет различные окна «из коробки», такие как скользящие окна, окна с прокруткой, окна сеанса и очень гибкие настраиваемые окна.
Flink API
Многоуровневый API Flink в основном имеет три уровня, как показано ниже:
Нижний уровень — это ProcessFunction, который может предоставлять очень гибкие функции.Он может получать доступ к различным состояниям и регистрировать некоторые таймеры.С помощью механизма обратного вызова таймера могут быть реализованы некоторые приложения, управляемые событиями.Выше находится API DataStream, а верхний уровень — это высокоуровневый API SQL/Table API.
Цель Флинка
Для чего можно использовать Flink? Оглядываясь назад на обмен предыдущими станциями Flink up, многие гости поделились некоторыми из своих практик, основанных на Flink в своих компаниях, включая Ctrip, Vipshop, Ele.me, Didi, Toutiao и т. д. Сценарии их приложений включают машинное обучение в реальном времени, статистический анализ в реальном времени, мониторинг аномалий в реальном времени и многое другое. Общим моментом этих практических случаев является то, что все они используются для задач реального времени.
Изменения в названии Flink
В первые дни Flink представил себя так: «Я являюсь унифицированным вычислительным движком с открытым исходным кодом для потоковой и пакетной обработки», что в то время было чем-то похоже на Spark. Позже Spark был изменен на длинный список слов с различными прилагательными: «Я распределенная, высокопроизводительная, высокодоступная и высокоточная система потоковых вычислений». Недавно Spark был изменен: «Я вычисляю поток данных с сохранением состояния».
Наблюдая за этим изменением, мы можем обнаружить изменение в фокусе сообщества Flink, то есть основное внимание сообщества теперь сосредоточено на создании своего механизма потоковых вычислений. Сначала прижиться в сфере потоковых вычислений, несколько лет возглавить других конкурентов, затем использовать силу сообщества для роста сообщества, а затем использовать силу сообщества для расширения своей экологии.
Alibaba Flink представилась так: «Flink — это унифицированный движок для обработки больших объемов данных». Этот «унифицированный движок» включает в себя потоковую обработку, пакетную обработку, искусственный интеллект, машинное обучение, графические вычисления и многое другое.
Перелистнуть прошлое и настоящее
Исторические изменения Flink High-Level API
В период Flink 1.0.0 две платформы Table API и CEP были впервые добавлены в хранилище, и у сообщества был большой спрос на SQL. SQL и Table API очень похожи, оба являются высокоуровневыми языками для обработки структурированных данных и могут совместно использовать большое количество контента при реализации. Поэтому в версии 1.1.0 сообщество провело серьезную реконструкцию всего нетабличного модуля на основе Apache Calcite, чтобы Table API и SQL совместно использовали большую часть кода и поддерживали его одновременно.
Во время Flink 1.2.0 Tumbling Window, Sliding Window и Session Window поддерживались в Table API и SQL.
В период Flink 1.3.0 впервые была введена концепция Dynamic Table, с помощью которой можно конвертировать потоки и пакеты друг в друга. Поток может быть таблицей или таблица может быть потоком, что является одной из основ объединения потока и пакета. Механизм ретракции является наиболее важной функцией динамической таблицы.На основе ретракции можно правильно реализовать многоуровневое приложение и многоуровневое соединение, а также обеспечить правильность семантики и результатов. В то же время эта версия поддерживает управляемость оператора КЭП.
Во время Flink 1.5.0 поддерживались операции соединения, в том числе оконное соединение и соединение без окна, а также была добавлена поддержка SQL CLI. SQL CLI предоставляет диалоговое окно, похожее на команду оболочки, для интерактивного выполнения запросов.
История Flink API
Во время Flink 1.0.0 был добавлен State API, а именно ValueState, ReductionState, ListState и т. д. State API в основном предназначен для удобства пользователей DataStream, упрощая управление состоянием.
Во время Flink 1.1.0 была обеспечена поддержка SessionWindow и поздней обработки данных.
Во время Flink 1.2.0 был предоставлен низкоуровневый API ProcessFunction. На основе ProcessFunction пользователи могут гибко реализовывать некоторые приложения, основанные на событиях.
Во время Flink 1.3.0 была реализована функция Боковые выходы. Как правило, вывод оператора имеет только один тип вывода, но иногда может потребоваться вывод другого типа, например, вывод некоторых аномальных данных и запаздывающих данных в виде побочного потока и передача их аномальному узлу для дальнейшего обработка.Боковые выходы.
В Flink 1.5.0 был добавлен BroadcastState. BroadcastState используется для хранения данных, передаваемых из восходящего потока.Данные во многих N параллельных состояниях BroadcastState на этом узле точно такие же, поскольку они передаются из восходящего потока. На основе этого состояния можно лучше решить сценарий неравного значения соединения. Например, «SLECECT * FROM L JOIN R WHERE L.a > R.b», написанное в запросе, означает, что нам нужно связать и вывести все данные в левой и правой таблицах, где A больше, чем B. В предыдущей реализации, поскольку нет эквивалентного условия для соединения, невозможно выполнить перетасовку KeyBy в соответствии с эквивалентным условием.Все данные могут быть собраны только на одном узле и обработаны на одном параллельном узле, и этот единственный Параллельные узлы станут узким местом всей работы. С помощью BroadcastState можно выполнить некоторые оптимизации: поскольку объем данных левой таблицы относительно велик, а объем данных правой таблицы относительно мал, поэтому выберите широковещательную рассылку правой таблицы и используйте левую таблицу для выполнения ключей перетасовать в соответствии с одним из его равномерно распределенных ключей. , перетасовать к нисходящим N узлам соединения, узел соединения будет хранить два состояния, левое состояние и правое состояние, левое состояние используется для хранения состояния левого потока данных, который является keyedState, потому что он основан на одном из его ключей. Состояние справа — это BroadcastState, а данные, хранящиеся в BroadcastState на всех узлах соединения, абсолютно одинаковы, поскольку они передаются из восходящего потока. Все keyedState обрабатываются одновременно, а затем объединение набора keyedState равно полному результату обработки левого потока данных. Таким образом реализуется масштабируемость узла соединения.Повышение параллелизма узла соединения позволяет лучше улучшить возможности обработки задания. Помимо сценариев неравного присоединения, BroadcastState также может эффективно решать динамические правила, такие как CAP.
В период Flink 1.6.0 предоставляется параметр State TTL и функция DataStream Interval Join. State TTL позволяет вам указать параметр TTL при подаче заявки на состояние и указать, как долго состояние должно быть автоматически очищено системой. До этой версии, если пользователь хочет реализовать эту операцию очистки состояния, ему необходимо использовать ProcessFunction для регистрации таймера, а затем использовать обратный вызов таймера, чтобы вручную очистить состояние. Начиная с этой версии, платформа Flink может решить эту проблему на основе TTL. Функция интервального соединения потока данных — это соединение с интервалом, например данные в пределах нескольких минут до и после соединения левого потока и правого потока.Это называется соединением с интервалом.
История Flink Checkpoint & Recovery
Механизм Checkpoint поддерживался Flink в первые дни и является очень важной функцией Flink.Сообщество Flink также усердно работало над повышением эффективности Checkpoint и эффективности его отзыва после перехода на FailOver.
В период Flink 1.0.0 была обеспечена поддержка RocksDB.До этой версии все состояния могут храниться только в памяти процесса.Всегда наступит день, когда эту память нельзя будет сохранить.Если ее нельзя сохранить , произойдет ООМ. Если вы хотите хранить больше данных и большее количество состояний, вам нужно использовать RocksDB. RocksDB — это файловая встроенная база данных, которая хранит данные на диске, но в то же время обеспечивает эффективные возможности чтения и записи. Так что с RocksDB нет такой вещи, как OOM. Во Flink 1.1.0 предоставляется чисто асинхронный снимок RocksDB. Предыдущая версия блокировала обработку основного потока данных синхронно при выполнении снапшота RocksDB, что сильно сказывалось на пропускной способности, то есть основной поток данных застревал каждый раз при возникновении контрольной точки. Чисто асинхронная обработка не блокирует поток данных, поэтому пропускная способность также повышается.
В период Flink 1.2.0 были введены концепции масштабируемых ключей и состояния работы, которые поддерживали масштабируемость состояния ключа и масштабируемость состояния оператора. Во время Flink 1.3.0 была введена более важная функция инкрементной контрольной точки. Только добавочные контрольные точки могут лучше поддерживать задания с очень большими состояниями. Внутри Alibaba это состояние ТБ очень распространено. Если состояние полного ТБ каждый раз сбрасывается на удаленную HDFS, эффективность будет очень низкой. Инкрементные контрольные точки отправляют на удаленный сервер для хранения только те состояния, которые были недавно добавлены в интервал контрольной точки.Данные, отправляемые каждой контрольной точкой, намного меньше, а эффективность повышается. В этой версии также представлено мелкомодульное восстановление.Когда мелкозернистое восстановление выполняет восстановление, иногда не требуется восстанавливать все задание, а может потребоваться только восстановление определенного подграфа в задании, что может улучшить восстановление эффективное.
Во время Flink 1.5.0 было введено восстановление локального состояния задачи. Поскольку на основе механизма контрольных точек состояние будет постоянно храниться в удаленном хранилище, таком как HDFS. При аварийном переключении данные необходимо снова загрузить с удаленного HDFS. Если состояние особенно велико, процесс операция загрузки будет очень долгой, что приведет к длительному восстановлению аварийного переключения. Механизм, предоставляемый восстановлением локального состояния задачи, гарантирует, что состояние задания не будет потеряно локально при сбое задания.При восстановлении его нужно восстанавливать только непосредственно локально, и нет необходимости загружать состояние с удаленного компьютера. Снова HDFS, поэтому она улучшена.Эффективность аварийного восстановления.
История среды выполнения Flink
История изменений Runtime очень важна.
В период Flink 1.2.0 была предусмотрена функция асинхронного ввода-вывода. Если задача должна часто запрашивать и получать доступ к внешнему хранилищу, например, запрашивать таблицу HBase, до этой версии каждая операция запроса блокировалась и часто блокировалась запросами ввода-вывода. При добавлении асинхронного ввода-вывода одновременно могут быть инициированы N асинхронных запросов, что повышает пропускную способность всего задания, и в то же время асинхронный ввод-вывод может обеспечить асинхронную семантику задания.
Во время Flink 1.3.0 был представлен модуль HistoryServer. Основная функция HistoryServer — архивировать статус задания и информацию после завершения задания, чтобы последующие разработчики могли провести углубленное расследование.
В период Flink 1.4.0 предоставляется семантическая гарантия end-to-end ровно один раз.Так называемый ровно один раз во Flink обычно относится к ровно одному самому движку Flink. Если вы хотите получить ровно один раз от ввода до обработки и вывода, всего сквозного целого, необходимо, чтобы компонент вывода имел функцию фиксации. В старой версии kafka функции фиксации не было, эта функция была доступна с недавней версии 1.1, поэтому Flink быстро реализовал end-to-end ровно один раз.
В период Flink 1.5.0 Flink впервые официально упомянул новую модель развертывания и модель обработки. Разработка новой модели велась давно, и эта новая модель обработки работает в Alibaba уже более двух лет.Внедрение этой модели внесло множество изменений во внутренний код Flink. можно сказать, что с момента создания проекта Flink одно из самых больших улучшений в изменениях среды выполнения. Короче говоря, одна из его особенностей заключается в том, что он может лучше динамически распределять ресурсы, динамически высвобождать ресурсы, улучшать использование ресурсов и обеспечивать более качественные рабочие места при использовании систем планирования, таких как YARN и Mesos. Наконец, в этом выпуске компания Flink провела базовый рефакторинг своего веб-сайта.
Рефакторинг сетевого стека Flink
Для измерения производительности в потоковых вычислениях используются две метрики: задержка и пропускная способность. Вообще говоря, если вам нужна более высокая пропускная способность, вы должны пожертвовать некоторой задержкой, а если вы хотите более низкую задержку, вы должны пожертвовать определенной пропускной способностью. Однако рефакторинг сетевого стека позволил добиться одновременного улучшения задержки и пропускной способности, что в основном связано с двумя его аспектами работы: первый — управление потоком на основе кредита, а другой — ввод-вывод на основе событий. Один для увеличения пропускной способности, а другой для уменьшения задержки.
Прежде чем вводить управление потоком, нам нужно представить существующий сетевой стек. TaskManager во Flink используется для управления ролью каждой задачи, основанной на процессах; задачи используются для выполнения пользовательского кода и основаны на потоках. При взаимодействии передачи данных между задачами необходимо установить сетевое соединение.Если TCP-соединение устанавливается между 2 секундами, TCP-соединение будет серьезно потрачено впустую, поэтому Flink устанавливает TCP-соединение между двумя диспетчерами задач.Соединение, которое то есть существует только одна связь между двумя процессами. Каждая задача разделяет TCP-подключения в виде TCP-каналов, поэтому во всем задании не будет слишком много TCP-подключений.
Флинк противодавление
Обратное давление означает, что когда производительность обработки задачи не может соответствовать скорости ввода, буфер на входе будет заполнен, а когда буфер на входе заполнен, чтение TCP будет приостановлено. После приостановки чтения TCP пул буферов на восходящем выходе будет накапливаться все больше и больше, потому что нисходящий поток в это время больше не потребляет. Когда буферный пул восходящего вывода также заполнен, канал TCP будет закрыт, и все внутренние каналы TCP также будут закрыты. В результате вышестоящая задача будет выполнять противодавление восходящему шаг за шагом.Это общий процесс противодавления.Поэтому предыдущий механизм противодавления Flink относительно примитивен и груб, потому что его контроль очень силен.Если производительность определенного Задача не справляется, все TCP-соединение будет отключено. Как показано ниже:
Хотя задача в правом нижнем углу не успевает за обработкой, указанная выше задача все еще может продолжать обрабатываться. Восходящие данные слева можно продолжать отправлять задаче в правом верхнем углу для обработки. Однако, поскольку все TCP-соединение теперь закрыто, задача в правом верхнем углу также не может получать данные, и общая пропускная способность фактически снижается. Чтобы оптимизировать эту функцию, необходимо добиться более тонкого управления потоком данных. В настоящее время все TCP-соединение закрыто. Мерой оптимизации является контроль TCP-канала. Когда задача не может быть обработана, только TCP-канал соответствующий задаче, остальные каналы TCP не затрагиваются. Оптимальным методом реализации является кредитное управление потоком.Основная идея управления потоком на основе кредита — потребление на основе кредитного лимита. Например, когда банк выдает ссуду, чтобы предотвратить слишком много безнадежных долгов, он будет оценивать кредитный лимит каждого человека, и когда ссуда выдается, ссуда не будет превышать лимит, который человек может выплатить. На основе этого метода, с одной стороны, он не может генерировать слишком много безнадежных долгов, а с другой стороны, он может полностью использовать средства банка. На этой идее основано управление потоком на основе кредита.Так называемый лимит кредита во Flink относится к количеству буферов, доступных нижестоящему потребителю. Как показано ниже:
Левая сторона рисунка относится к отправителю.Имеется четыре очереди вывода.Квадрат в каждой очереди представляет собой выходной буфер, то есть буфер, который должен быть брошен для последующей обработки. Справа находится сторона потребителя.Со стороны потребителя также есть четыре очереди.В этих четырех очередях также есть блоки Buffer.Эти блоки Buffer являются свободными буферами и готовы к приему данных, отправленных им восходящим потоком.
Так называемый кредит в упомянутом выше управлении потоком на основе данных относится к количеству буферов, доступных потребителю, которое представляет, сколько данных может быть потреблено в настоящее время.Потребитель сначала возвращает текущий кредит восходящему потоку, а производитель будет отправлять только кредит. Если кредитный лимит больше 0, нисходящий поток отправит его, а если кредитный лимит равен 0, данные больше не будут отправляться. Таким образом, коэффициент использования всей сети значительно улучшается, и не бывает так, что некоторые буферы остаются на сетевом канале в течение длительного времени. Управление потоком на основе кредита в основном имеет следующие два улучшения оптимизации: во-первых, когда определенная задача не может справиться с обработкой обратного давления, все задачи не будут зависать, что значительно повышает пропускную способность.Этот новый алгоритм управления потоком будет улучшен. на 20%; другой — ввод-вывод на основе событий. Когда Flink записывает данные на стороне сети, они переходят к одному блоку Write data in Buffer. 32 КБ. Когда блок буфера заполнен, он будет выведен в сеть, или, если поток данных медленный, нет возможности быстро его заполнить. Если он заполнен, он будет ждать тайм-аут, по умолчанию 100 миллисекунд, то есть, если буфер не был заполнен в течение 100 миллисекунд, Buffer также будет выведен в сеть. В настоящее время, если задержка Flink в предыдущей версии может быть в пределах 100 миллисекунд, в худшем случае это 100 миллисекунд, потому что ожидание отправки буфера занимает 100 миллисекунд. Если вы хотите получить более низкую задержку, текущий метод добавит буфер непосредственно в очередь вывода, но продолжит запись данных в блок буфера.Когда в сети есть емкость, блок буфера будет отправлен немедленно. если сеть сейчас тоже занята, то продолжаем заполнять этот Буфер, чтобы пропускная способность была лучше. Основываясь на этом алгоритме, задержка Flink почти идеальна, и видно, что ее кривая в основном составляет менее 10 миллисекунд, что также полностью использует пропускную способность сети и почти не влияет на пропускную способность.
об авторе
Предстоящие События
4 ноября открылся второй сезон китайского тура сообщества Apache Flink Meetup.
Технические специалисты из Ali, Huizhi, Cainiao, Kangaroo Cloud и Youzan покажут вам:
- Как расширить Flink SQL для реализации объединения потока и таблицы измерений
- Как повысить эффективность эксплуатации и обслуживания и снизить стоимость настройки через платформу
- Попытки пакетной обработки и машинного обучения во Flink
- Интеграция Apache RocketMQ с Apache Flink …………
Портал регистрации:woohoo.event.com/event/14632…