Meitu распределенный растровой практики: Naix

Этой статьей поделились гости 11-го выпуска Салона интернет-технологий Meitu.

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

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

Как технология, широко цитируемая различными фреймворками, принцип Bitmap на самом деле очень прост.

Бит есть бит, а Bitmap идентифицирует значение, соответствующее элементу, посредством битового бита (поддерживает два состояния 0 и 1).Проще говоря, Bitmap сам по себе является битовым массивом.

Вот простой пример, предположим, у вас есть 10 пользователей (идентификатор соответственно от 1 до 10), один день 1,3,5,7,8,9 система входа в систему, как простое представление состояния входа пользователя? Пользователям нужно только найти соответствующую позицию и установить ее.

Более того, если вам нужно проверить, вошел ли пользователь в систему в тот день, вам нужно только проверить, равно ли значение, соответствующее биту идентификатора пользователя, 1. И, подсчитав количество единиц в растровом изображении, вы можете узнать общее количество пользователей, вошедших в систему. Операции, уже поддерживаемые Bitmap (такие как AND, OR, ANDNOT и т. д.), могут сделать вычисления, такие как пересечение измерений, более удобными.

Вычислительная производительность Bitmap на его основном поле боя просто потрясающая. В Meitu ранняя статистика в основном основывалась на Hive. Основываясь на данных приложения Meitu, простой расчет удержания (то есть подсчет количества новых пользователей, которые все еще активны на следующий день) занимает около 139 секунд через Hive (используя оставленное соединение), в то время как Bitmap (расчет пересечения ) занимает около 139 секунд. ) занимает всего 226 миллисекунд, а Hive занимает примерно в 617 раз больше времени, чем Bitmap. Как показано на рисунке ниже, где Hive основан на кластере Hadoop с 4 узлами, Bitmap использует только один узел с одним процессом.

небольшое место для хранения

Поскольку Bitmap использует биты для идентификации состояния, данные сильно сжаты и занимают очень мало места для хранения. Предполагая, что существует 1 миллиард активных идентификаторов устройств (числовых типов), если вы используете обычный массив Int для хранения около 3,72 ГБ, Bitmap требуется всего около 110 МБ. Конечно, если вы хотите выполнять такие операции, как дедупликация и сортировка, бонус к производительности (например, потребление памяти и т. д.), получаемый за счет экономии места для хранения, также очень значителен.

У Meitu есть много приложений, таких как Meitu Xiuxiu, Beauty Camera, Meipai, Beauty Camera, Chao Selfie и т. д. Известные Meitu Xiuxiu и Meiyan Camera ежедневно пользуются десятками миллионов активных пользователей, а совокупное количество пользователей за всю историю достигло миллиардов.

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

Принцип Bitmap прост, но поддержка массивных данных и запросов только через сервисы Bitmap сложнее, чем можно себе представить. С 2015 года по настоящее время, от автономной версии к распределенной версии, от одного приложения к доступу к различным приложениям, от «небольших» данных небольшого количества показателей к текущим массивным данным и спросу, мы также встречаются в процессе практики Bitmap.Есть довольно много проблем, наиболее типичными из которых являются:

• Сотня растровых индексов T-уровня. Это порядок величины, который трудно поддерживать для одного узла, и обычно его необходимо решать с помощью внешнего хранилища или самостоятельно разработанного набора распределенных хранилищ данных;

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

• Как лучше выполнять многомерные кросс-вычисления в распределенном хранилище Bitmapи как это сделать в сценариях запросов с высокой степенью параллелизма.быстрый ответ

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

Имя Naix происходит от Dota, а техническая команда данных Meitu имеет различные проекты «серии Dota», такие как Kunkka, Puck, Arachnia и т. д. Причина, по которой распределенный Bitmap называется Naix, очень проста, а его омофония Next означает следующее поколение Bitmap.

Вся система Naix в основном разделена на три слоя, как показано ниже: внешние вызовов, узлы системы системы, зависимые внешние слои хранения.

Внешний слой вызова

Уровень внешнего вызова разделен на генератор и клиент tcp. Генератор — это инструмент, отвечающий за создание растровых изображений. Необработанные данные и обычные данные обычно хранятся в HDFS или другом носителе. Соответствующие текстовые данные или другие данные необходимо преобразовать в данные, связанные с растровыми изображениями, через узел генератора, а затем синхронизировать с система. Клиент TCP в основном отвечает за взаимодействие между клиентским приложением и распределенной системой.

слой основного узла

Уровень ядра узла в основном включает три типа:

• Главный узел, ядро ​​Naix, в основном управляет кластером и поддерживает его, например, добавление Bitmap, управление узлами и другие операции;

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

• Для узлов данных (основной узел хранения данных в Naix) мы используем Paldb в качестве основного хранилища данных для Bitmap.
  

Зависимый внешний уровень хранения

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

index group

Как показано на рисунке выше, индексная группа — это самая основная структура данных в Naix, похожая на базу данных в обычной базе данных, и в основном используется для изоляции различных предприятий. Например, в бизнесе Meitu Meitu Xiuxiu и Meipai — это две разные индексные группы. В каждой индексной группе может быть несколько индексов.Индекс похож на таблицу в обычной базе данных.Например,новые и активные растровые изображения принадлежат двум разным индексам.

index

В каждом индексе есть фиксированный атрибут времени. Поскольку данные Bitmap могут включать разные периоды времени, данные разных периодов времени помещаются в один и тот же индекс по форматированному времени. Индекс в соответствующий период времени включает в себя несколько измерений, таких как версия, канал, регион и т. д., каждое измерение включает разные значения измерения (например, v1.0.0, v1.2.0 и т. д.), и файл Bitmap, который мы см. для конкретного значения размера.

Управление информацией о данных словарь

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

Для необработанных данных Bitmap это обычно относится к записям, подобным Mysql, текстовым файлам HDFS и т. д. Роль генератора Naix заключается в преобразовании необработанных данных в данные, связанные с Bitmap, и синхронизации их с системой Naix.Генератор поддерживает Bitmap в различных сценариях. в виде плагинов Генерируется, а затем бизнес-сторона разрабатывает собственную бизнес-логику на основе плагина.

simple pluginЭто самый простой способ и первый плагин, который мы используем. В Meitu большая часть данных представляет собой необработанные данные HDFS.Соответствующие данные фильтруются через клиент Hive на сервер обработки, а затем преобразуются в данные Bitmap с помощью подключаемого модуля.

Из-за большого объема данных и сложного бизнеса Meitu на предыдущем этапе ежедневно генерировались данные почти по 3 часа. Если есть проблема в середине, а затем запустить снова, это неизбежно повлияет на другие статистические службы и вызовет серьезные последствия. Итак, мы разработалиmapreduce plugin, рассчитывая ускорить генерацию данных за счет распространения собственных преимуществ.

Практика показала, что использование плагина mapreduce может наконец сократить процесс генерации почти с 3 часов до примерно 8 минут (на основе тестового кластера с 4 узлами). Основываясь на характеристиках mapreduce, мы можем легко поддерживать непрерывную и высокую скорость генерации за счет расширения узла или настройки количества карт и уменьшения, когда объем бизнеса и данных продолжает расти.

Третий плагинbitmap to bitmap plugin, для растровых данных различных периодов времени пользователи могут настраивать с помощью предоставленного нами плагина и регулярно генерировать растровые изображения на основе растровых изображений в системе. Подобно растровым изображениям, таким как недели, месяцы и годы, этот плагин может генерировать периодические растровые изображения с помощью собственных растровых изображений (например, недели генерируются по дням, месяцы по неделям и т. д.), пользователям нужно только отправить план генерации, и в конечном итоге система будет периодически генерировать растровые изображения Автоматически генерировать результаты растровых данных.

Фрагментация

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

Дизайн шардинга дает много преимуществ:

• Проблема распределенного хранения 100 данных Т-уровня легко решается;

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

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

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

• Преодоление барьера int: обычно реализации Bitmap поддерживают только диапазон int, а с развитием бизнеса Meitu рост пользователей скоро превысит диапазон int. Используя метод сегментирования данных, путем смещения идентификатора в сегменте, сегменты можно легко накладывать друг на друга по горизонтали, чтобы поддерживать длину long.

replication

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

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

Оптимизации, связанные с фрагментацией пространства и файлов.

Оптимизация пространства и фрагментация файлов — наиболее важная часть работы с растровыми изображениями. Растровое изображение реализовано на основе длинного массива или другого цифрового массива, и его данные часто бывают слишком плотными или разреженными, с большим пространством для оптимизации. Большинство алгоритмов сжатия растровых изображений аналогичны выравниванию за счет сжатия пространства и уменьшения объема вычислений в Meitu Bitmap, EWAH (с использованием аналогичного RLE), продолжении RoaringBitmap, в настоящее время это Spark, Hive, Kylin, DRUID обычно используется в растровых изображениях. сжатие. Сравнение производительности EWAH и RoaringBitmap, проверенное в наших реальных бизнес-сценариях, экономия места на 67,3%, сохранение данных на 58%. В Query фактический тест сцены немного улучшен, но значительно улучшено потребление пространства и времени генерации.

Ранние Bitmap использовали файловое хранилище, и мы выполняли оптимизацию, подобную mmap, при чтении. Однако в повседневном бизнесе существует множество растровых изображений, разбитых по точным измерениям (например, на канале меньше новых пользователей), и операции сегментирования при обработке разбивают эти небольшие растровые изображения на более мелкие части. Использование блоков и инодов для небольших файлов крайне мало для самой операционной системы.Попробуйте решить проблему фрагментации небольших файлов, оптимизировав решение для хранения. В основном исследовались следующие схемы:

Redis

Сам Redis поддерживает работу с набором битов, но эффект от его реализации не соответствует ожиданиям. Предполагая простое хранилище битовых данных kv, взяв в качестве примера емкость данных 200T, каждая машина составляет 256G, и сохраняется резервная копия, для которой требуется около серверов 160. С ростом объема бизнеса стоимость будет постепенно увеличиваться;

HBase

В Meitu Big Data HBase используется во многих сценариях. Если для хранения данных Bitmap используется HBase, то не так много возможностей для оптимизации производительности чтения и записи, а зависимость от HBase слишком велика, поэтому ожидаемого эффекта добиться сложно;

RocksDB

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

PalDB

PalDB — хранилище kv только для чтения, разработанное linkedin.Официальная тестовая производительность примерно в 8 раз выше, чем у RocksDB и LevelDB, когда объем данных достигает определенного порядка. Производительность PalDB даже выше, чем у встроенных в Java HashSet и HashMap. Сам дизайн PalDB имеет свои преимущества и недостатки, его дизайн приводит к ограниченным сценариям использования, но в основном он соответствует сценариям использования Naix. PalDB имеет небольшой объем исходного кода, и мы также внесли простые корректировки, основанные на конкретных сценариях использования. После тестирования итоговое пространство для хранения экономится на 13%, а время запроса увеличивается более чем на 60% при использовании PalDB в реальных параллельных сценариях. Генератор занимает немного больше времени, но поскольку добавляется режим генератора mr, на воздействие можно не обращать внимания;

Процесс распределенных вычислительных узлов включает в себя фрагментацию, хранение данных и сценарии запросов, как мы находим соответствующие данные? Как его рассчитать?

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

Система Naix поддерживает запросы в общем виде: она поддерживает операторы ∩ ∪ - ( ) для комбинирования выражений, пользователи могут выбрать нужный Кортеж запроса и операторы для сборки выражений запроса в соответствии со сценариями использования.Конечно, мы также инкапсулируем запрос выражения Инструмент преобразования сборки Naix не имеет ничего общего с самим бизнесом, и пользователи могут выполнять различные операции запроса с помощью выражения сборки.

Вот несколько простых примеров:

• Простейшее позиционирование устройства или пользователя, например запрос, является ли определенный пользователь новым пользователем или активным пользователем в определенный день;

• Многомерный комбинированный анализ, например проверка удержания новых пользователей в канале Meipai vivo на следующий день;

• Многомерный локальный комбинированный перекрестный анализ (распространенные сценарии анализа данных), например, подсчет количества активных пользователей Meipai в версиях v6.0 и v8.0, соответствующих каналам Baidu и vivo в определенный день, который включает пересечение двух каналов и двух версий Всего 4 комбинированных запроса. Эта операция часто используется для анализа данных. Включая первые два, средний ответ этих простых операций запроса занимает всего несколько миллисекунд;

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

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

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

• Попробуйте различные оптимизации вычислений и постарайтесь повысить производительность запросов до более высокого уровня;

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