Эта статья представляет собой контент, которым поделились гости 11-го выпуска Салона интернет-технологий Meitu. Официальный аккаунт ответит на «Платформу больших данных Meitu», чтобы получить PPT. Нажмите, чтобы прочитать исходный текст, чтобы посмотреть полное воспроизведение видео.
В настоящее время применение больших данных в различных отраслях становится все более и более обширным: операции ориентированы на операционные результаты на основе данных, продукты ориентированы на коэффициенты конверсии на основе анализа данных, разработка на основе данных для измерения эффектов оптимизации системы и т. д. У Meitu более дюжины приложений, таких как Meipai, Meitu Xiuxiu и Meiyan Camera. Каждое приложение на основе данных будет выполнять персональные рекомендации, поиск, анализ отчетов, защиту от мошенничества, рекламу и т. д. Сравниваются общие потребности бизнеса в данных. , Все более и более широко используется.
Таким образом, бизнес-опыт технической группы данных Meitu в основном отражается во многих направлениях бизнеса и широком спектре приложений. Это также одна из основных причин, по которой мы создали платформу данных.движимый бизнесом.
Рисунок 1
Вот несколько примеров приложения данных Meitu. Как показано на рисунке 1, первое изображение слева — это платформа визуализации данных DataFace, разработанная Meitu, которая поддерживает бизнес-стороны для свободного перетаскивания для создания визуальных отчетов, что удобно для эффективного представления данных и последующего анализа; второе изображение является приложением Meipai Домашняя страница, популярная персонализированная рекомендация, основанная на используемых данных о поведении, рекомендует список видео, которые могут понравиться и заинтересовать пользователей; третья основана на данных пользователя о мошенничестве, анти-обман в соответствии с определенным модели и стратегии, а также эффективное суждение, фильтрация мошеннического поведения пользователей. Кроме того, он имеет широкий спектр приложений, включая поиск, эксперименты A/B, отслеживание каналов, рекламу и т. д.
В настоящее время у Meitu 500 миллионов активных пользователей в месяц, и эти пользователи ежедневно генерируют около 20 миллиардов единиц поведенческих данных.Общая величина относительно велика: кластерные машины достигают тысяч, а общий объем исторических данных составляет петабайты.
У Meitu много бизнес-направлений, и каждое бизнес-направление широко использует данные, а общий масштаб пользователей относительно велик Все вышеперечисленные факторы подталкивают нас к созданию соответствующей платформы данных, чтобы стимулировать рост этих предприятий и использовать их более эффективно.
Общая архитектура платформы данных Meitu
На рис. 2 показана общая архитектура нашей платформы данных. В части сбора данных мы строим систему журналов сервера сбора Arachnia, которая поддерживает клиентский SDK, интегрированный с каждым приложением, и отвечает за сбор данных клиента приложения, в то же время есть интеграция данных (импорт и экспорт) на основе DataX; платформа сканера Mor поддерживает разработку настраиваемых задач для сканирования данных общедоступной сети.
фигура 2
Уровень хранения данных в основном выбирает различные решения для хранения в соответствии с бизнес-характеристиками.В настоящее время в основном используются HDFS, MongoDB, Hbase, ES и т. д. Что касается обработки данных, текущие офлайн-вычисления в основном основаны на Hive&MR, потоковые вычисления в реальном времени — это Storm, Flink, и есть еще одна растровая система собственной разработки Naix.
Что касается разработки данных, мы создали набор платформ, таких как мастерская данных, распределение шины данных и планирование задач. Часть визуализации данных и приложений в основном создает серию платформ приложений данных на основе потребностей пользователей, в том числе: экспериментальную платформу A / B, платформу отслеживания продвижения канала, платформу визуализации данных, портрет пользователя и так далее.
В правой части рисунка 2 показаны некоторые основные службы, от которых может зависеть каждый компонент, включая географическое положение, управление метаданными, уникальную идентификацию устройства и многое другое.
Блок-схема базовой архитектуры данных показана на рисунке 3. Типичная лямбда-архитектура начинается со сбора левого источника данных.Arachnia и AppSDK сообщают данные сервера и клиента сборщику прокси-сервиса соответственно и записывают данные путем анализа данных. Для kafka поток в реальном времени будет проходить через уровень распределения данных, а конечный бизнес использует данные kafka для вычислений в реальном времени.
изображение 3
В автономном режиме служба ETL будет отвечать за сброс данных из Kafka в HDFS, а затем разнородные источники данных (такие как MySQL, Hbase и т. д.) в основном основаны на DataX и Sqoop для импорта и экспорта данных и, наконец, записи данных через hive, kylin, spark и другие вычисления, различные уровни хранения и, наконец, подключение к бизнес-системе и нашей собственной платформе визуализации через унифицированный внешний API.
Поэтапная разработка платформ данных
Создание платформы данных корпоративного уровня в основном делится на три этапа:
В начале базовое использование бесплатных сторонних платформ, этот этап характеризуется возможностьюБыстрая интеграцияИ посмотрите некоторые статистические показатели приложения, но и недостатки очевидны,нет необработанных данныхЗа исключением тех основных показателей, которые предоставляются третьими лицами, другой анализ, рекомендации и т. д. не могут быть достигнуты. Итак, есть процесс от 0 до 1, так что у нас есть данные, которые мы можем использовать сами;
После того, как данные будут доступны, из-за вспышки бизнес-направлений и спроса необходимоПовышение эффективности разработки, позволяя большему количеству людей участвовать в разработке и использовании данных, а не только персоналу, занимающемуся исследованиями и разработками данных, поэтому он предполагает открытие возможностей хранения данных и вычислений для различных бизнес-направлений, а не держание их в своих руках;
После того, как данные будут открыты, бизнес-сторона спросит, может ли задача данных выполняться быстрее, может ли она быть произведена за секунды и может ли она быть более оперативной; как добиться большей экономии ресурсов при удовлетворении бизнеса.
Сейчас Meitu находится в переходном периоде между вторым и третьим этапами.Постоянно совершенствуя открытие данных, она также постепенно повышала эффективность запросов и анализа и начала думать о том, как оптимизировать затраты. Далее мы сосредоточимся на практике и идеях оптимизации нашей платформы на двух этапах: от 0 до 1 и открытия данных.
от 0 до 1
От 0 до 1 разрешается от сбора данных до окончательных готовых к использованию данных. Эволюция сбора данных показана на рисунке 4. От начала использования бесплатных сторонних платформ, таких как umeng и flurry, до быстрого использования rsync для синхронизации журналов с сервером для хранения и расчета, а затем до быстрой разработки позже Простой скрипт на Python поддерживает бизнес-сервер для отчетов журналов, и, наконец, мы разработали серверную систему сбора журналов Arachnia и клиентский AppSDK.
Рисунок 4
Сбор данных является источником данных и является относительно важным звеном во всей линии передачи данных. Он требует большего внимания: являются ли данные полными, поддерживают ли данные отчетность в режиме реального времени, стандартизированы ли и точны ли скрытые точки данных, и затраты на техническое обслуживание и управление. Поэтому наша система сбора журналов должна соответствовать следующим требованиям:
Он может интегрировать управление и обслуживание, включая мониторинг автоматического развертывания, установки, обновления и удаления агента, оперативного изменения конфигурации и задержки;
С точки зрения надежности, хотя бы один раз должно быть гарантировано;
Meitu теперь имеет несколько IDC и должна иметь возможность поддерживать сбор и агрегирование данных нескольких IDC в центр обработки данных;
Минимизируйте потребление ресурсов и постарайтесь не влиять на бизнес.
Основываясь на вышеуказанных требованиях, мы не использовали лоток, писец и флюид, и, наконец, решили разработать систему сбора Arachnia самостоятельно.
Рисунок 5
На рис. 5 представлена упрощенная схема архитектуры Arachnia, которая централизованно управляется через системный мозг. Модуль puppet в основном используется для агрегирования метрик Агента в одном IDC, передачи переадресованных метрик или настройки команды горячего обновления. Агент-сборщик в основном отвечает за эксплуатацию и обслуживание платформы, которая отвечает за установку и запуск, перетаскивание из мозга в конфигурацию и начало сбора и передачи данных сборщику.
Тогда посмотрите на практическую оптимизацию Арахнии, первая гарантия надежности хотя бы один раз. Многие системы используют метод WAL для записи данных, по которым не удается создать отчет, и повторной попытки и повторного создания отчета, чтобы избежать потери отчета. Наша практика заключается в удалении WAL и добавлении координатора для равномерного распределения и управления состоянием tx.
Изображение 6
Перед началом сбора от координатора будет отправлен txid, после получения сигнала источник начнет сбор и отправит данные на приемник, после отправки подтвердит tx, чтобы сообщить координатору, что он зафиксирован. Координатор проверит и подтвердит, а затем отправит сигнал фиксации источнику и приемнику для обновления статуса. Наконец, после завершения tx источник обновит ход сбора данных до постоянного уровня (по умолчанию используется локальный файл). . Если есть проблема на первых 3 шагах, данные не будут успешно отправлены и не будут повторены; если следующие 4 шага не пройдены, данные будут повторены, а tx будет воспроизведен.
В соответствии с приведенной выше гарантией надежности хотя бы один раз, некоторым деловым сторонам требуется уникальность, и мы поддерживаем создание уникального идентификатора для каждого журнала. Другая основная практика системы сбора данных заключается в уникальном расположении файла и назначении уникального MsgID каждому журналу, чтобы деловая сторона могла очистить журнал позже, когда журнал дублируется на основе MsgID.
Мы использовали имя файла в начале, но позже обнаружили, что имя файла будет изменено многими деловыми сторонами, поэтому оно будет изменено на inode, но inode linux будет переработан и использован повторно, и, наконец, содержимое inode и заголовка файла хешируется как идентификатор файла. И MsgID однозначно подтверждается идентификатором агента, идентификатором файла и смещением.
После того, как данные переданы, сборщик отвечает за синтаксический анализ протокола и отправку данных в Kafka.Так как же Kafka попадает в HDFS? Первый взгляд на обращение Meitu:
Поддержка распределенной обработки;
Он включает в себя больше бизнес-линий и, следовательно, имеет множество форматов данных, поэтому он должен поддерживать сериализацию нескольких форматов данных, включая json, avro, специальные разделители и т. д.;
Он поддерживает повторный запуск при сбое загрузки данных из-за сбоя машины, проблем с обслуживанием и т. д., и он должен иметь возможность повторного запуска относительно быстро, потому что после этого сбоя он повлияет на использование данных в последующих бизнес-линиях;
Поддержка настраиваемой стратегии разделов HDFS, может поддерживать относительно гибкую и различную конфигурацию разделов для каждой бизнес-линии;
Поддержка обработки специальной бизнес-логики, в том числе: проверка данных, фильтрация истечения срока действия, фильтрация тестовых данных, внедрение и т. д.;
Основываясь на вышеуказанных болевых точках, реализация службы данных Meitu от Kafka до HDFS показана на рисунке 7.
Рисунок 7
Основываясь на характеристиках Kafka и MR, для раздела каждой темы kafka соберите inputsplit маппера, а затем запустите процесс маппера для обработки и использования данных kafka этого пакета.После анализа данных, обработки бизнес-логики, проверки и фильтрация, и, наконец, в соответствии с правилами раздела Landed для записи в целевой файл HDFS. После успешной посадки обработанная на этот раз метаинформация (включая тему, раздел, начальное и конечное смещения) будет храниться в MySQL. В следующий раз, когда оно будет обработано снова, сообщение будет прочитано со смещения в конце последней обработки, и будет получен новый пакет потребления данных.
После реализации базовых функций неизбежно столкнется с некоторыми проблемами, например, уровни данных разных бизнес-тем отличаются, что приведет к тому, что задача будет ждать маппера с наибольшим объемом данных партиций и наибольшим временем обработки. конец до того, как вся задача может быть завершена. Так как же решить эту проблему? В системном проектировании существует негласный принцип: долгосрочное разделение должно быть объединено, долгосрочная интеграция должна быть разделена, и мы приняли аналогичную идею для проблемы перекоса данных.
Рисунок 8
Во-первых, разделы с меньшим объемом данных объединяются в один входной раздел, чтобы один преобразователь мог обрабатывать данные разделов нескольких предприятий и, наконец, записывать несколько файлов.
Рисунок 9
Кроме того, разделы с большими объемами данных могут быть разделены на сегменты, которые поровну разделены на несколько преобразователей для обработки одного и того же раздела, что обеспечивает более сбалансированную обработку преобразователей и может лучше справляться с внезапным увеличением объема бизнеса.
Помимо проблемы перекоса данных, существуют также различные причины сбоя дампа данных в HDFS, такие как проблемы с диском kafka, время простоя узла кластера hadoop, сбой сети, внешние разрешения на доступ и т. д. Если файл HDFS не закрыт , файл поврежден и т. д., и данные необходимо перезапустить. Тогда наши временные разделы данных в основном в днях.Использование исходного метода может привести к повреждению файла с детализацией по дням, и синтаксический анализ не может быть прочитан.
Рисунок 10
Мы используем двухэтапный метод обработки: программа отображения 1 сначала записывает данные во временный каталог, а программа отображения 2 добавляет данные из временного каталога Hdfs в целевой файл. Таким образом, в случае сбоя mapper1 вы можете напрямую перезапустить пакет без повторного запуска данных за весь день; в случае сбоя mapper2 вы можете напрямую объединить данные из временного каталога, чтобы заменить окончательный файл, уменьшив процесс повторной детализации ETL за день.
При распределении и подписке данных в режиме реального времени данные, записываемые в kafka1, в основном представляют собой полный объем данных для каждого бизнеса, но большинство предприятий со стороны спроса сосредотачиваются только на определенном событии и небольшой категории данных, а не на любых бизнес, который потребляет полный объем обработки данных, поэтому для решения этой проблемы мы добавили шину данных распределения в реальном времени.
Рисунок 11
Databus поддерживает бизнес-сторону для настройки правил распределения для записи данных в нижестоящий кластер kafka, что удобно для бизнес-стороны для подписки и обработки нужных данных, а также поддерживает меньшую степень детализации повторного использования данных.
Рисунок 12
На рис. 12 показана реализация шины данных, основная часть которой реализует топологию шины данных на основе Storm. Databus имеет два носика, один поддерживает извлечение полной суммы и новых правил, а затем обновляет болт нижестоящего дистрибутива для обновления правил кеша, а другой — носик, потребляемый из kafka. Distributionbolt в основном отвечает за синтаксический анализ данных, сопоставление правил и отправку данных в нижестоящий кластер kafka.
открытые данные
После получения необработанных данных и возможности разработки данных в автономном режиме и в режиме реального времени требования к разработке данных резко возрастут, и группа исследований и разработок данных будет перегружена. Поэтому мы открываем возможности обработки и хранения данных с помощью платформы данных, давая бизнес-партнерам возможность разрабатывать данные.
Реализация управления метаданными, планирования задач, интеграции данных, планирования задач DAG, визуализации и т. д. не будет описываться по отдельности, в основном это практический опыт Meitu в области стабильности после открытия данных.
Открытость данных и стабильность системы любят и убивают друг друга: с одной стороны, после открытости это уже не работа научно-исследовательского персонала с фондами данных и часто сталкивается с незаконными задачами данных, высоким потреблением ресурсов и т. д. стабильность кластеров вычислений и хранения доставила много хлопот, с другой стороны, именно из-за открытости данных мы должны повысить стабильность системы.
Для многих ресурсоемких и незаконных задач мы сначала рассматриваем,Может выполнить некоторую проверку на уровне HiveSQL., лимит. На рис. 13 показан весь процесс разбора и компиляции HiveSQL в исполняемый MR:
Рисунок 13
Сначала разберите грамматику на основе Antlr, сгенерируйте AST, а затем выполните семантический анализ.На основе AST будет сгенерирован объект JAVA QueryBlock. После создания логического плана на основе QueryBlock выполните логическую оптимизацию и, наконец, сгенерируйте физический план.После физической оптимизации он окончательно преобразуется в исполняемую задачу MR.
После того, как мы создадим QueryBlock на этапе семантического разбора, мы заставим его выполнять множество проверок утверждений, в том числе: недопустимые операции, ограничения условий запроса, проверку и суждение о высоком потреблении ресурсов и т. д.
Вторая практика с точки зрения стабильности, в основном дляоптимизация кластера,включают:
Мы полностью обновили кластеры Hive и Hadoop. Основная причина в том, что некоторые проблемы были исправлены в более низкой версии и некоторые патчи сообщества были объединены, и они исправлены в новой версии; другая причина заключается в возможностях и оптимизации производительности новой версии. Мы обновили Hive с 0,13 до 2,1 и Hadoop с 2,4 до 2,7;
Оптимизация развертывания HA для Hive. Мы разделили HiveServer и MetaStoreServer и развернули несколько узлов по отдельности, чтобы избежать взаимного влияния при объединении в одном развертывании службы;
Ранее механизм выполнения был в основном On MapReduce, и мы также выполняем миграцию Hive On Spark и постепенно переключаем онлайн-задачи с Hive On MR на Hive On Spark;
Вытяните внутреннюю ветку, чтобы исправить ошибки или объединить функции патчей сообщества для некоторых проблем, возникающих в обычное время;
Заключительная часть практики с точки зрения стабильности платформыПовышение разрешений, безопасность, для предотвращения несанкционированного доступа к кластеру, данным, атакам и т.д. Есть две основные части увеличения разрешений: доступ к API и кластеризация.
Рисунок 14
API Server : Как упоминалось выше, у нас есть OneDataAPI, который предоставляет унифицированный API для различных бизнес-систем для доступа к данным. В связи с этим дополнительно реализована служба унифицированного аутентификационного центра сертификации.Бизнес-система должна получить доступ к центру сертификации, чтобы получить токен, а затем получить доступ к OneDataAPI.После проверки OneDataAPI центром сертификации разрешается законный доступ к данным, бизнес-система от возможности произвольного доступа ко всем индикаторам данных.
кластер: в настоящее время он в основном основан на Apache Ranger для унификации различных кластеров, включая Kafka, Hbase, Hadoop и т. д., для управления авторизацией и обслуживанием кластера;
Выше приведены некоторые методы и оптимизации, которые Meitu применила для стабильности платформы после создания платформы данных и открытия ее для различных направлений бизнеса.
Затем делается краткий обзор процесса построения платформы данных.
Прежде всего, прежде чем создавать платформу данных, мы должны сначалаУзнать о бизнесе, чтобы увидеть, является ли общий объем бизнеса относительно большим, является ли бизнес-направление относительно широким и не слишком ли велик спрос, чтобы серьезно повлиять на нашу производительность. Если ответ «да», вы можете как можно скорее рассмотреть возможность создания платформы данных, чтобы более эффективно и быстро повысить эффективность разработки и применения данных. Если у вас небольшой бизнес и низкий спрос, вам не обязательно настраивать большие данные или создавать полную платформу данных, чтобы быстро выполнить приоритетную задачу поддержки бизнеса.
В процессе строительства платформы необходимо ориентироваться наСосредоточьтесь на качестве данных и стабильности платформыНапример, сосредоточьтесь на целостности, своевременности и уникальной идентификации набора источников данных, а также оптимизируйте и практикуйте стабильность платформы, чтобы обеспечить стабильную и надежную платформу для бизнеса.
После повышения эффективности анализа и принятия решений и постепенного расширения масштаба необходимо провести оптимизацию и подумать о затратах и ресурсах.