Практика OPPO для хранения данных в реальном времени на основе Apache Flink

Эта статья взята из публикации Чжан Цзюня, руководителя отдела исследований и разработок платформы больших данных OPPO, на сайте Flink Forward Asia. OPPO строит хранилище данных в режиме реального времени на основе Apache Flink, а общий объем обработки данных за один день превышает 10 триллионов с пиковым значением около 300 миллионов в секунду. Содержание этой статьи разделено на следующие четыре аспекта:

строительный фон
Дизайн высшего уровня
практика посадки
перспективы на будущее

Об авторе: Чжан Цзюнь, руководитель отдела исследований и разработок платформы больших данных OPPO, руководит строительством центра обработки данных OPPO, охватывающего все звенья «доступ к данным — управление данными — разработка данных — применение данных». Он окончил Шанхайский университет Цзяотун со степенью магистра в 2011 году.Последовательно работал в Morgan Stanley и Tencent.У него богатый опыт исследований и разработок в области систем данных.В настоящее время он занимается строительством хранилищ данных, вычислениями в реальном времени и OLAP. двигателя направления.Он также является вкладчиком в сообщество открытого исходного кода Flink.

1. История строительства

О мобильном интернет-бизнесе OPPO

Все думают, что OPPO — это компания мобильных телефонов, но вы можете не знать, что OPPO также занимается бизнесом, связанным с мобильным Интернетом. В декабре 2019 года OPPO выпустила собственную настраиваемую мобильную операционную систему ColorOS 7.0. В настоящее время, включая зарубежные рынки, ColorOS имеет более 300 миллионов активных пользователей в день. В ColorOS встроено множество мобильных интернет-сервисов, включая магазины приложений, облачные сервисы, игровые центры и т. д., а ежедневная активность этих сервисов достигла десятков миллионов.

Архитектура данных как ядро

Для поддержки этих мобильных интернет-сервисов OPPO создала архитектуру данных с хранилищами данных в качестве ядра, как показано на рисунке ниже. Я считаю, что синяя часть на рисунке должна быть знакома каждому. Эта часть в основном представляет собой некоторые компоненты с открытым исходным кодом, от доступа к данным до интерактивных запросов на основе хранилища данных, обработки данных и затем приложения данных. Приложения в основном делятся на три аспекта:

Во-первых, импортировать данные в ES, чтобы сделать некоторые пользовательские теги и адресную доставку толпы.
Второй — импортировать данные в MySQL или Kylin для отчетов BI.
Третий — поместить данные в Redis или HBase в качестве сервисного интерфейса.

За последние несколько лет внутренняя архитектура данных OPPO, основанная на хранилищах данных, постепенно начала развиваться.

Архитектура данных с хранилищем данных в качестве ядра

Однако с развитием бизнеса и постоянным расширением масштабов данных спрос OPPO на хранилища данных в реальном времени становится все сильнее и сильнее. Требования OPPO к хранилищам данных в режиме реального времени можно разделить на два измерения, а именно бизнес-измерение и платформенное измерение.

Для бизнес-измерения все больше и больше необходимо выполнять точные операции, и все больше и больше необходимо извлекать ценность данных, поэтому, будь то отчеты в реальном времени, метки в реальном времени или интерфейсы в реальном времени, реальные -Требуются временные возможности.
Для измерения платформы также требуется режим реального времени. Поскольку общий масштаб данных становится все больше и больше, обычно традиционный режим обработки данных «T + 1» делает нагрузку на службу очень высокой рано утром. Если нагрузку всего кластера можно равномерно распределить на 24 часа в сутки, эффективность использования всего кластера будет выше. Таким образом, даже с точки зрения планирования задач, импорта пользовательских меток и т. д., если аномалии данных могут быть обнаружены очень своевременно, для платформы требуется много возможностей в реальном времени.

2. Дизайн верхнего уровня

Текущее состояние хранилищ данных в реальном времени

В настоящее время масштаб хранилища данных OPPO в режиме реального времени таков, что Flink достиг более 500 узлов, а Kafka — более 200 узлов. В измерении метаданных существует более 500 представлений базы данных в реальном времени и около 300 заданий в реальном времени. С точки зрения масштаба данных, общий объем обработки данных в день превышает 10 триллионов, а пиковое значение составляет около 300 миллионов в секунду.

Хранилище данных в реальном времени VS автономное хранилище данных

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

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

Плавная миграция из автономного хранилища в режим реального времени

При наблюдении за базовой логикой можно вывести структуру верхнего уровня. OPPO надеется, что разработанное хранилище данных в режиме реального времени сможет обеспечить плавный переход от автономного режима к режиму реального времени.Как вы использовали и разрабатывали автономные хранилища данных в прошлом, и теперь вы хотите разрабатывать и использовать хранилища данных в реальном времени. Вообще говоря, при разработке продукта или платформы его можно разделить на два уровня, а именно низкоуровневую реализацию и высокоуровневую абстракцию. Для базовой реализации могут быть разные технологии, от Hive до Flink, от HDFS до Kafka. Предполагается, что в верхней абстракции он будет прозрачным для пользователя.

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

Первая абстракция — это структура хранилища данных, которую можно разделить на разные предметные области и уровни в соответствии с разными структурами.
Вторая абстракция — это режим разработки хранилища данных, который в основном представляет собой режим разработки SQL+UDF.
Третья абстракция — управление С точки зрения управления хранилище данных — это не что иное, как управление его авторитетом, родословной и качеством данных.

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

Интегрированная офлайн-ссылка для доступа в режиме реального времени

Прежде всего, я представлю интегрированную ссылку доступа в режиме реального времени в автономном режиме.Данные OPPO собираются с мобильного телефона во внутреннюю службу сбора данных OBus.После сбора они равномерно попадают в Kafka, а затем задачи Flink SQL может упасть в HDFS и Kafka одновременно. Flink может разделить канал данных.Для компаний мобильной связи, таких как OPPO, отчеты о многих приложениях передаются по одному и тому же каналу, поэтому канал данных должен быть разделен, прежде чем данные попадут в хранилище данных.Согласно разным предприятиям Сделайте некоторое разделение с помощью атрибутов , в дополнение к некоторым преобразованиям формата. Другая часть функции заключается в реализации мониторинга данных, потому что очень важной проблемой при помещении данных в HDFS является проблема осведомленности о разделах, например, как автономные задачи ETL узнают, что раздел закончился.

Подход OPPO основан на согласовании разных сквозных данных, поэтому необходимо полностью записывать, сколько фрагментов данных получено и сколько фрагментов данных было записано на уровне Flink SQL, а затем сделать согласование данных с предыдущим OBus.Если результат сравнения находится в определенном диапазоне, можно записать успешный файл, чтобы можно было запустить внутреннюю задачу ETL.

Преимущества использования Flink SQL:

Во-первых, Flink SQL может обеспечить сквозную согласованность, будь то от Kafka к Kafka или от Kafka к HDFS, чтобы обеспечить сквозную согласованность данных, что очень важно для каналов доступа.
Во-вторых, Flink SQL обладает мощными возможностями предварительной обработки данных.В прошлом OPPO использовала Flume в канале доступа к данным, но производительность обработки данных этих компонентов трудно улучшить, поэтому для повышения производительности необходимо добавить много машин. После использования Flink возможности обработки данных значительно улучшились.
В-третьих, можно использовать набор кода для реализации данных, попадающих в HDFS и Kafka, что значительно снижает затраты на обслуживание.

Автономный интегрированный процесс управления в режиме реального времени

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

Автономная интегрированная среда разработки в реальном времени

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

Иерархическое разделение хранилищ данных реального времени

Как показано на рисунке ниже, это многоуровневая структура хранилища данных OPPO в режиме реального времени.После поступления с уровня доступа все данные будут поддерживаться Kafka.Доступ к данным помещается в Kafka для реализации уровня ODS, а затем Flink SQL используется.После очистки данных они переходят на уровень DWD.Некоторые операции агрегирования реализуются с использованием Flink SQL в середине, а затем они достигают уровня ADS.И, наконец, они импортируются в ES и другие системы в соответствии с различным бизнес-использованием сценарии. Конечно, некоторые из этих уровней измерения находятся в MySQL или Hive.

SQL доминирует в мировой архитектуре данных

Что касается недавнего развития области хранилищ данных, одним из интересных моментов является то, что архитектура данных, будь то в автономном режиме или в режиме реального времени, постепенно превратилась в архитектуру, в которой SQL доминирует в мире. Будь то автономное хранилище данных или хранилище данных в реальном времени, будь то доступ, запросы, разработка или бизнес-системы, это способ написания SQL на нем.

Три, практика посадки

Я поделился с вами дизайном верхнего уровня практики хранилища данных OPPO в реальном времени. Конечно, эта часть не была полностью реализована. Далее я поделюсь с вами существующей практикой OPPO.

SQL разработка и внедрение управления метаданными

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

Здесь нужна система метаданных и система разработки.Необходимо иметь возможность создавать таблицы в реальном времени в системе метаданных и создавать задания в реальном времени и писать SQL в системе разработки.Будь то создание таблицы или задания, он должен иметь возможность сохраняться в MySQL.

Затем разверните компоненты во Flink и загрузите их из MySQL.

Для таблиц каталог Flink можно расширить, загрузить из MySQL через каталог, а затем преобразовать в таблицу данных, выраженную внутри Flink.
Для вакансий OPPO использует платформу с открытым исходным кодом Google.Благодаря реализации магазина вакансий задание может быть загружено из источника данных, такого как MySQL, отправлено в среду таблицы Flink для компиляции задания и, наконец, определено как график задания, а затем отправить его в YARN.Этот процесс является основой, которая поддерживает хранилище данных OPPO в реальном времени.

Оптимизация избыточного потребления Тематическая проблема Кафки

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

Однако проблема, вызванная этим, заключается в том, что несколько SQL-запросов выполняются в одном задании, и будет создано несколько источников данных, а несколько источников данных будут многократно использовать Kafka, что делает кластер Kafka очень напряженным.Причина в том, что коэффициент записи и операции чтения многих машин Kafka сильно отличаются, и задание SQL может много раз читать темы Kafka. И это не обязательно, потому что для той же работы Kafka нужно потреблять только один раз, а затем данные можно переваривать и распространять внутри Flink.

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

Автоматизация каналов передачи данных в реальном времени

Отчет онлайн-аналитики в реальном времени — очень распространенный сценарий.Для отчетов в реальном времени часто требуются три ссылки:

Первая ссылка предназначена для аналитиков данных, чтобы написать SQL для обработки данных;
Вторая ссылка — подсчитать или очистить от таблицы данных, а затем записать в Kafka, а затем ввести данные в Druid через персонал платформы по исследованиям и разработкам;
Последняя ссылка заключается в том, что пользователям необходимо перейти в систему BI для просмотра отчета, поэтому им необходимо импортировать таблицу из Druid в систему BI.

Три канала обработки данных, импорта данных и представления данных в приведенной выше ссылке относительно разделены, поэтому для вмешательства в этот вопрос необходимы три разные роли, поэтому OPPO надеется открыть канал передачи данных в реальном времени. OPPO автоматизировала канал передачи данных в реальном времени, как показано на рисунке ниже, и абстрагировала таблицу Kafka.Для пользователей это таблица, используемая для отображения BI.Таблица Kafka должна определять, какие измерения и какие индикаторы, которые самое основное определение поля для отображения отчета.

Когда вышеуказанные задачи будут выполнены, вся линия передачи данных в реальном времени может быть сериализована автоматически. После того, как пользователь закончил писать SQL, он может автоматически определить таблицу отчета, которую необходимо импортировать в Druid, а также индикаторы и измерения, и может автоматически импортировать данные из Druid в систему BI. Таким образом, пользователям нужно написать только один SQL, а затем они смогут увидеть отчет в системе BI.

Мониторинг задержки каналов передачи данных в реальном времени

Ранее OPPO также отслеживала задержку канала передачи данных в одной точке.Из рисунка ниже видно, что существует как минимум три уровня тем Kafka, и для каждой темы есть мониторинг задержки. Пользователей беспокоит не суть, а аспект, то есть задержка отчета с окончательными данными.

Поэтому OPPO также внедрила полный мониторинг задержек: от канала доступа до потребления Kafka на каждом уровне ситуация с задержкой суммируется, и исследуется родственная связь таблицы Flink SQL на каждом уровне. При таком кровном родстве из таблицы Друида можно вывести, к какой ссылке ранее была подключена, а затем суммируется общая задержка, чтобы можно было отразить задержку общей ссылки.

Многопользовательское управление каналами передачи данных в реальном времени

Управление несколькими арендаторами также очень важно для каналов передачи данных в реальном времени. В основе практики OPPO в этой части лежат два момента:

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

4. Перспективы будущего

Упрощенная разработка SQL

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

Выразительные возможности: хотя Flink SQL постоянно развивается в сторону стандартного SQL, некоторые сценарии по-прежнему неудовлетворительны, например, выполнение статистики по нескольким окнам в одном SQL, поэтому необходимо улучшить выразительные возможности Flink SQL.
Тип соединения: В настоящее время появляется все больше и больше приложений хранилищ данных в реальном времени, поэтому также необходимо расширять больше соединителей, таких как приемники, такие как Redis.
Шаблон разработки: Google открыл исходный код шаблона потока данных, потому что этот метод является обычным, когда пользователи выполняют статистику, сводки и т. д. Таким образом, для пользователей эти общие операции могут быть включены в шаблоны, чтобы избежать повторного написания SQL.
Спецификации разработки: это также проблема, которую OPPO наблюдала в онлайн-практике.Многие аналитики данных пишут SQL с низкой производительностью.Когда разработчики выявляют проблемы, они часто обнаруживают, что SQL написан неправильно, и требуется только небольшая оптимизация.Производительность могут быть улучшены, поэтому эти возможности необходимо заложить в систему в будущем.

Более подробное планирование ресурсов

В настоящее время OPPO использует YARN для планирования кластера Flink, а планирование YARN основано на размерах VCore и памяти. При работе в сети обнаруживается, что загрузка процессора на одних машинах высокая, а на других очень низкая. Это связано с тем, что сложность и вычислительная интенсивность обработки разных SQL различаются. Если VCore по-прежнему выделяется, как и раньше, что в результате утилизация ресурсов разная.Поэтому в будущем необходимо рассмотреть возможность добавления SQL в планирование ресурсов, и постараться избежать перекоса ресурсов.

Автоматическая настройка параметров

Для аналитиков данных все знают, что во Flink есть несколько расширенных конфигураций. Помимо написания SQL, есть много других знаний, таких как параллелизм операций, фон состояния, интервал уровня воды и т. д., но пользователям часто сложно освоить настройку этих сложных параметров, поэтому OPPO надеется настроить эти сложные параметры в будущем. Эти параметры настраиваются автоматически путем понимания распределения данных и тонкостей SQL.

Автоматическая настройка масштабирования

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