От данных к применению больших моделей: 25 ноября в Ханчжоу прошла конференция Yuanchuang, на которой были обменяны советами по разработке.

Автор | Вунань

Введение

Уровень журнала PV, передаваемый ежедневно центром регистрации, может достигать сотен миллиардов. Избыточные данные журнала могут быть сокращены в процессе отчетности, что может снизить сложность и стоимость последующей обработки данных, повысить точность и качество данных, а также улучшить поддержку. Эксплуатация и оптимизация бизнес-систем. В этой статье представлена практика оптимизации UBC SDK для упаковки дублирования журналов. Оптимизируя базу данных, процессы и механизм управления, он эффективно снижает уровень дублирования журналов с трехтысячных до десятитысячных.

Полный текст составляет 8525 слов, расчетное время чтения — 22 минуты.

01 Введение

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

1.1 История дедупликации журналов

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

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

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

1. Дублирование пакета: SDK отправил данные, но не получил результат.Сервер разместился на диске, но пакет в итоге не удалился.Весь лог в пакете сообщается повторно.

2. Дублирование журналов. Один журнал вводится в несколько пакетов и передается на сервер вместе с каждым пакетом.

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

1.2 Знакомство с UBC SDK

UBC (User Behavior Collection) SDK, то есть SDK для сбора данных о поведении пользователей, отвечает за сбор, упаковку, составление отчетов и другие функции журналов управления терминалами. Он записывает данные о поведении пользователей и загружает их на сервер центра журналов. Это источник канала передачи данных центра регистрации.

1.2.1 Тип точки

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

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

1.2.2 Механизм управления

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

1. Поэтапная асинхронная обработка . Чтобы обеспечить эффективность и стабильность отчетности, SDK внутренне разбивает весь процесс на несколько этапов и передает их потокам задач и потокам отправки для асинхронного планирования и выполнения.

2. Постоянное хранение журналов и пакетов . Чтобы гарантировать, что журналы не будут потеряны, SDK сохранит журналы в SQLite, сохранит журналы в файлах при отправке и неоднократно попытается отправить их до успешного завершения.

3. Несколько моментов запуска отчетов : чтобы принять во внимание пропускную способность и своевременность отчетов, SDK будет запускать отчеты журналов в разные моменты времени, например, запуск сразу же, когда происходит управление в реальном времени, запуск, когда управление не в реальном времени достигает отчета. период, переключение между фронтальной и серверной частью или отчет о невыполненных данных при восстановлении сети и т. д.

Архитектура основного модуля UBC SDK показана на рисунке ниже:

картина

Основной процесс управления, хранения и отправки журналов UBC показан на рисунке ниже:

картина

02 Средства позиционирования

2.1 Трудности позиционирования и методология

При устранении проблем с дублированием журналов на конечной стороне возникают следующие трудности:

1. Существует множество бизнес-сторон, использующих UBC.Разные сценарии запуска в разных точках различны, и возникающие проблемы также различны.Невозможно понять методы вызова всех сервисов.

2. Дублирование журналов в основном вызвано маловероятными аномальными событиями, которые тесно связаны с локальной средой пользователя, версией системы и производителем, и проблему трудно воспроизвести.

3. UBC SDK — это доступ к данным, который влияет на всю систему. Любые изменения в процессе отчетности могут вызвать колебания существующих данных и повлиять на бизнес-статистику.

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

картина

2.2 Инструменты позиционирования

2.2.1 Идентификация онлайн-журнала

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

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

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

UUID журнала : UUID (Universally Unique Identifier) — это 128-битная строка, которая может гарантировать, что объект или событие будет однозначно идентифицирован глобально, то есть журнал может быть однозначно идентифицирован на одном и том же устройстве для регистрации и отслеживания. Изменения могут вызвать колебания существующих данных и повлиять на бизнес-статистику.

Журналы, неоднократно сообщаемые в TC-Box, можно найти через UUID журнала. Однако, чтобы определить, является ли это дубликатом пакета или дубликатом журнала, необходимо оценить его на основе информации об упаковке. Существует две основные идентификационные информации пакета. :

1. Пакет md5 : MD5 (алгоритм дайджеста сообщений 5) — это широко используемая криптографическая хэш-функция, которая может получать данные любой длины и генерировать хеш-значение фиксированной длины. UBC вычисляет значение md5 на основе содержимого пакета в качестве идентификатора пакета.

2. Время создания пакета : временная метка упаковки на уровне миллисекунд. Поскольку значение md5 одинаково при одинаковом содержимом пакета, если один и тот же пакет данных упаковывается несколько раз, он не может быть идентифицирован с помощью md5, поэтому в качестве идентификационного идентификатора для повторной упаковки необходимо использовать md5+createtime.

Помимо идентификационной информации, для принятия решений необходима и другая информация, например:

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

2.appv : номер версии приложения во время управления. При оценке эффекта оптимизации необходимо уменьшить влияние отложенных отчетов о старых версиях.

3.process : выполнить идентификатор упакованного процесса и имя процесса.Если в экземпляре UBC одновременно существует несколько процессов, может произойти дублирование из-за небезопасности процесса.

4. триггер : время срабатывания упаковки. В нормальных обстоятельствах разные моменты времени отправки отчетов имеют разную частоту. Ненормальная частота появления отчетов также может помочь обнаружить проблемы.

5.db_sync : режим синхронизации SQLite, который можно использовать для проверки исключений, вызванных методами обратной записи пользовательской базы данных.

2.2.2 Аномальный мониторинг

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

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

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

2.2.3 Управление бизнесом

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

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

03 Атрибуция и решение повторяющихся проблем

3.1 Проблемы, связанные с базой данных

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

картина

В этой ссылке много логических ветвей, а стратегии выполнения управления в реальном времени и не в реальном времени различны:

После запуска RBI не в реальном времени сначала записывается кэш, а затем записывается база данных.После достижения времени отчетности база данных запрашивается пакетно, и запускается отчетность;
Управление в реальном времени сначала записывается в файл, чтобы вызвать отчет. Если запись файла не удалась, он записывается в базу данных. При записи файла к базе данных будет отправлен запрос на добавление пакета управления не в реальном времени.

картина

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

Процесс упаковки — это процесс «пакетного переноса журналов из базы данных в файлы». Подробности шагов, показанных в синем поле, показаны на рисунке ниже.

картина

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

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

3.1.1 Повреждение базы данных

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

(1) Атрибуция проблемы

Характеристики данных

Количество PV, о которых сообщают пользователи за один день, огромно: серьезные случаи достигают миллионов (среднее количество PV, о которых сообщает один пользователь за один день, составляет около 2000).
Большинство журналов, о которых сообщают пользователи, являются повторяющимися, и один и тот же журнал будет упакован несколько раз.
Интервал между повторными упаковками очень короткий, холодного запуска не происходит.
Большинство повторяющихся пакетов имеют одинаковый md5, но разное время создания, а условием срабатывания является превышение лимита количества элементов.

Причина предположения

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

дальнейший анализ

Мы рассмотрели код удаления сообщаемых данных и изначально исключили некоторые влияющие факторы:

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

Дальнейший анализ двух слоев try-catch в коде выявил проблему:

Try-catch внутреннего уровня: выполнение нескольких SQL-запросов, установка флага успеха транзакции после успеха и установка флага результата в значение true.
Try-catch внешнего уровня: отправьте транзакцию и подсчитайте результаты удаления.

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

картина

поддержка атрибуции

Чтобы определить причину исключения, мониторинг исключений SQL уточняется, и все стеки исключений, зафиксированные в классе DatabaseHelper, записываются.
Получены аномальные данные мониторинга повторяющихся пользователей и обнаружено большое количество исключений SQL. Стек выглядит следующим образом: Исключение повреждения базы данных SQLiteDatabaseCorruptException произошло во время db.endTransaction, что подтверждает результаты анализа кода.

аварийный стек

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

окончательное присвоение

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

(2)План оптимизации

Для решения этой проблемы требуется двухэтапная оптимизация с обеих сторон:

1. Исправить результаты выполнения транзакции базы данных и сбросить результаты, если во время отправки транзакции возникает исключение;

2. Перестройте базу данных, если она повреждена. Удалите файл базы данных и прикрепленные к нему файлы -journal, -shm, -wal. Файл базы данных будет создан заново при повторном открытии базы данных.

оценка риска

1. UBC обеспечивает высокую своевременность отчетности. Большинство данных можно сообщить и удалить из базы данных в течение 1 минуты. Поэтому в базе данных обычно сохраняется только несколько фрагментов данных. Прямое удаление потерянных данных находится в пределах допустимого диапазона.

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

3. Риск реконструкции базы данных относительно высок, поэтому экспериментальный метод целевого распределения AB используется для подтверждения его эффективности и отсутствия других эффектов перед постепенным увеличением объема.

Эффект оптимизации

1. На ранней стадии эксперимента экспериментальное переключение было направлено на пользователей с большим количеством повторных отчетов, и все они были успешно исправлены, а частота повторений после исправления вернулась к 0.

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

3. После оптимизации проблемы повреждения базы данных уровень дублирования рынка упал до менее чем двухтысячных, снижение примерно на 0,07 процентных пункта, что составляет около 35% от уровня до оптимизации.

3.1.2 Ошибка записи файла WAL

(1) Атрибуция проблемы

Характеристики данных

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

Причина предположения

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

дальнейший анализ

Начиная с Android 9.0, режим WAL (ведение журнала упреждающей записи) SQLite включен по умолчанию. В режиме WAL SQLite записывает операции изменения в файл WAL. Когда система простаивает или когда транзакция фиксируется, будет выполнена операция контрольной точки, а затем файл WAL будет записан обратно в файл базы данных на диске. . SQLite использует этот механизм, чтобы избежать частых операций записи на диск и повысить производительность записи и параллелизм базы данных.
Когда операция модификации записывается в файл WAL, а файл WAL записывается обратно в файл базы данных, он сначала проходит процесс записи в буфер диска, а затем выполняет операцию fsync для сброса на диск. Ключ к тому, можно ли восстановить транзакции после системного исключения, заключается в том, успешно ли файл WAL выполняет fsync.
Существует два основных часто используемых режима синхронизации WAL: PRAGMA Schema.synchronous = NORMAL | FULL. Разница между ними заключается в том, что NORMAL возвращает результат фиксации до того, как будет выполнена fsync при записи файла WAL, тогда как режим FULL фактически записывает WAL-файл на диск.Результат возвращается позже.

картина

В официальной документации SQLite упоминается: В НОРМАЛЬНОМ режиме отправка транзакций может быть отменена при отключении питания или сбое системы.

картина

поддержка атрибуции

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

2. Принесите и сообщите информацию о режиме синхронизации базы данных. Было проверено, что все режимы базы данных пользователей с такими повторяющимися проблемами являются НОРМАЛЬНЫМИ.

окончательное присвоение

1. SQLite пользовательского устройства использует НОРМАЛЬНЫЙ режим WAL.После записи транзакции удаления в буфер диска WAL и до синхронизации буфера с диском происходит отключение питания или сбой системы.

2. Транзакция была признана успешной и о ней сообщалось, но файл WAL не был записан. Поэтому данные в файле диска не были удалены, и удаление не может быть выполнено снова после восстановления системы. Сообщенные данные все еще существуют.

(2)План оптимизации

В зависимости от причины дублирования можно вывести решение этой проблемы, то есть обеспечить запись операции на диск как можно быстрее после завершения операции с базой данных.Существует три метода выполнения: (1) Turn выключить режим WAL; (2) Установить режим синхронизации на FULL; (3) Вручную выполнить контрольную точку.

После сравнения и тестирования нескольких решений на стороне Android, наконец, было получено компромиссное решение: гарантируется только надежность транзакции базы данных «Удалить упакованные данные». Когда режим синхронизации НОРМАЛЬНЫЙ, контрольная точка срабатывает вручную после удаления данных, запуская Запись файла WAL. Введите файл DB и убедитесь, что SQLite по крайней мере завершил операцию fsync файла WAL. Время, необходимое для выполнения контрольной точки, в основном такое же, как и время, необходимое для выполнения транзакции, а снижение производительности находится в пределах допустимого диапазона.

Чтобы гарантировать, что транзакции полностью записываются в режиме WAL на стороне iOS, помимо установки режима синхронизации NORMAL, вам также необходимо включить опцию fullfsync, чтобы строго гарантировать, что порядок записи соответствует порядку отправки. После тестирования и оценки снижение производительности оказалось больше, чем польза от оптимизации частоты повторений, и в конце концов мы решили не выполнять эту оптимизацию.

Эффект оптимизации

Сбой записи WAL составляет около 70% проблем дублирования с длинным хвостом в новой версии.
Согласно экспериментальным данным на стороне Android, за один час экспериментальная группа сократила количество повторных упаковок в 200+ раз по сравнению с контрольной группой.

3.2 Связанные с процессом

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

Эта проблема одновременного запуска упаковки за короткий промежуток времени естественным образом приводит к другому вопросу: безопасен ли поток UBC. Однако, как показано в разделе 1.2.2, внутри UBC есть только две очереди. Чтение базы данных и упаковка являются однопоточными операциями. Теоретически проблем с параллелизмом потоков не будет.

Поэтому мы обратили внимание на вопросы безопасности процессов на стороне Android:

1. В дополнение к основному процессу приложение Baidu также имеет несколько подпроцессов, таких как небольшие программы и мультимедиа.Различные процессы будут вызывать API управления.

2. Чтобы обеспечить скорость запуска, UBC использует метод инициализации с отложенной загрузкой.Одноэлемент UBC будет инициализирован только тогда, когда текущий процесс не имеет экземпляра UBC.

3. Если бизнес-сторона вызывает API в неосновном процессе, UBC передаст IPC в основной поток для выполнения, чтобы гарантировать, что только основной процесс имеет одноэлементный элемент UBC в жизненном цикле. Если в этом процессе возникнет проблема, это может привести к инициализации другого экземпляра UBC в дочернем процессе.

Когда два процесса одновременно имеют одиночные элементы UBC, может возникнуть небезопасность процесса, как показано на рисунке ниже.

картина

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

2. Последовательность выполнения операций удаления приведет к тому, что последующая операция удаления вернет номер удаления 0, поскольку данные не существуют, но отчет не будет завершен из-за выдачи исключения.

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

3.2.1 Сбой IPC приводит к появлению нескольких экземпляров UBC

(1) Атрибуция проблемы

Характеристики данных

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

Причина предположения

Эти два процесса имеют экземпляры UBC соответственно, одновременно отслеживают системные события и читают пакеты базы данных.

дальнейшее присвоение

Пообщавшись с бизнес-стороной multi-process framework, мы разобрались в причинах возникновения двух единичных случаев UBC и повторной упаковки:

1. Если возникает ошибка, когда многопроцессная структура IPC переходит от дочернего процесса к основному процессу, в дочернем процессе запускается управление сбоями IPC.

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

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

картина

поддержка атрибуции

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

(2)План оптимизации

В ответ на эту проблему после оценки воздействия наконец была выполнена двухэтапная оптимизация:

1. Когда подпроцесс ограничивает упаковку, запускаются интерфейсное переключение и восстановление сети, неосновной процесс не выполняет процесс упаковки;

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

Эффект оптимизации

После оптимизации этой проблемы уровень дублирования рынка упал до менее чем одной тысячной, что составляет снижение примерно на 0,04 процентных пункта, что составляет около 33% от уровня до оптимизации.

3.2.3 Неверное решение процесса приводит к множественным случаям UBC

(1) Атрибуция проблемы

Характеристики данных

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

Причина предположения

Существует два экземпляра UBC, и одновременно вводятся и запускают упаковку RBI A и B. Два экземпляра UBC работают одновременно, и оба RBI C в базе данных запрашиваются и упаковываются для отчетности.

дальнейшее присвоение

Объединив производительность данных и результаты оптимизации проблемы сбоя IPC, проблема заключается не в одновременном сообщении невыполненных данных, вызванных сбоем IPC, а в одновременности нескольких процессов, запущенных RBI. Таким образом, основным подозрением является оценка процесса.

картина

Для определения основного процесса используется метод, предоставляемый многопроцессной структурой.Логика определения того, соответствует ли имя текущего процесса имени пакета, является основным процессом и получения текущего имени процесса:
Чтение записей памяти → Получить из системного файла /proc/self/cmdline → Получить из ActivityManager
Если предыдущие методы не смогли его получить, используйте имя пакета в качестве имени процесса.
Имя пакета обычно совпадает с именем основного процесса. Если имя пакета используется в качестве имени процесса в дочернем процессе, это приведет к ошибке определения, тем самым инициализируя еще один синглтон UBC в дочернем процессе, вызывая повторяющиеся проблемы с упаковкой.

поддержка атрибуции

Пользователь дважды упаковал процесс с одним и тем же именем, но с разными идентификаторами процесса, что соответствует выводу анализа кода.

(2)План оптимизации

В качестве управленческого SDK UBC не следует уделять слишком много внимания логике оценки процесса. Поэтому необходимо способствовать обновлению многопроцессной структуры и увеличить количество способов получения имени процесса:

В Android API 28 добавлен новый метод для получения имен процессов Application.getProcessName(), который не требует отражения и IPC и может использоваться в качестве избыточного метода оценки имен процессов.

картина

Эффект оптимизации

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

3.3 Относится к механизму управления

3.3.1 реальный журнал

(1) Атрибуция проблемы

Reallog — это особый тип управления. Он не кэшируется после управления. Он выполняет только операцию запроса ввода-вывода. Он переносит исторические данные об ошибках и сообщает об этом непосредственно в память. После сбоя отчет записывается в базу данных. .

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

картина

Как показано на рисунке выше, управление типами Reallog будет независимо упаковываться и сообщаться, а флаг reallog=1 будет перенесен в URL-адрес. Используйте этот идентификатор для проверки повторяющихся данных, что доказывает проблему дублирования, вызванную Reallog.

(2) План оптимизации

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

картина

Оценка дела:

Как особый тип управления, Reallog не может быть настроен через центр журналов. Его используют лишь очень немногие бизнес-стороны. Это управление, которое не соответствует стандартам центра.
После нескольких раундов оптимизации своевременности текущий 97-й процентиль своевременности обычного управления в реальном времени составляет около 0,5 минуты, что достаточно для удовлетворения потребностей деловых кругов.

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

Эффект оптимизации

Около 10% проблем с длинным хвостом дублирования в новых версиях вызваны Reallog.
После того, как Reallog будет отключен от сети, дублирование этого типа на обоих концах больше не будет, и это не повлияет на использование связанных бизнес-сторон.

04 Резюме и перспективы

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

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

--КОНЕЦ--

Рекомендуем к прочтению

Baidu ищет модель глубокого обучения в бизнесе и практику оптимизации

Масштабная практика Wenshengtu: раскрываем историю поиска Baidu инструментов для рисования AIGC!

Практика применения больших моделей в области обнаружения дефектов кода

Поддержка практики реконструкции кода OC с помощью сценариев Python (2): элементы данных обеспечивают генерацию кода для путей доступа к данным модуля.

Поговорите с InfoQ о высокопроизводительной поисковой системе Baidu с открытым исходным кодом Puck