Практика TiDB в основном пакетном сценарии WeBank

Эта статья основана на рассказе Хуанга Вея, старшего архитектора баз данных WeBank, на PingCAP DevCon 2021 и в основном описываетПрактика применения TiDB в WeBank, включая предысторию выбора WeBank TiDB и архитектуры развертывания TiDB, а такжеПрименение основных пакетных сценариев займаи, наконец, поделились передовым опытом и планами на будущее, основанными на схеме оптимизации TiDB.

Преимущества продукта TiDB

С конца 2018 года, когда WeBank начал связываться с командой TiDB, до запуска в 2019 году TiDB продемонстрировал множество уникальных преимуществ при выборе базы данных.

TiDB совместим с протоколом MySQL, а также совместим с экологическими инструментами MySQL, такими как резервное копирование, восстановление, мониторинг и т. д. Будь то само приложение, эксплуатация и обслуживание или разработчики, стоимость и порог перехода с MySQL на TiDB низки. Для ТиБДСобственная архитектура разделения вычислений и хранения, пользователям не придется беспокоиться об ограничении емкости или производительности одной машины, и они могут в некоторой степени использовать TiDB в качестве большой MySQL. В то же время TiDBОсобенность строгой согласованности нескольких копий данныхЭто очень важно для финансовых сценариев, TiDB такжеАрхитектура развертывания, естественно поддерживающая несколько IDC, который может поддерживать архитектуру развертывания приложений для выполнения нескольких действий в одном городе. также,TiDB Работа сообщества открытого исходного кода также очень активна.Например, на платформе AskTUG вы можете увидеть методы решения типичных проблем многих пользователей, которые содержат много ценного опыта для справки, что может еще больше снизить порог использования пользователями TiDB.

Сейчас все больше и больше пользователей используют TiDB, будь то ведущий интернет-производитель или пользователь из финансовой индустрии.

Архитектура развертывания TiDB в WeBank

Могут ли функции TiDB соответствовать требованиям финансовых учреждений к архитектуре высокой доступности?

Это архитектура развертывания TiDB в WeBank.Как показано на рисунке, во-первых, TiKV выбирает три копии и развертывает их в трех центрах обработки данных в одном городе, чтобы достичь высокой доступности на уровне IDC, и в то же время развертывает набор копий в каждом IDC TiDB Server предоставляет VIP-услуги путем привязки к балансировщику нагрузки, чтобы приложения могли работать в режиме мультиактивного доступа. Эта архитектура также была протестирована и подтверждена реальными отказами уровня IDC.Все сети одного из IDC были отключены, и было замечено, что кластер может быстро восстанавливаться.Мы считаем, чтоTiDB может удовлетворить требования высокой доступности в финансовых сценариях.

Основные сценарии пакетного учета

Учет основного пакета кредитаЭто классический и очень важный сценарий в финансовой индустрии, и мы подключили его к TiDB. На следующем рисунке показана архитектура основного сценария пакетного приложения кредитов WeBank. В левой части много бизнес-единиц, что эквивалентно разделению данных пользователя на единицы. Данные каждой единицы могут быть разными, но архитектура и модель развертывания Это то же самое.Нижний уровень использует базу данных с одним экземпляром, и пакет запускается для каждой базы данных с одним экземпляром.И наконец, пакетный результат ETL отправляется на платформу больших данных для дальнейшего использования.Каковы узкие места или оптимизация точек этой архитектуры?

эточистая партияЭто означает, что существует большое количество пакетов записи, обновления и вычислений, а объем данных очень велик, на уровне 100 миллионов или более одного миллиарда.При быстром развитии бизнеса количество заимствованных данных, число пользователей и поток данных также увеличиваются.Если вы используете базу данных с одним компьютером для переноса нагрузки, она сначала будет ограничена верхним пределом производительности базы данных с одним компьютером, а выполнение пакета займет все дольше и дольше, и нагрузка на одномашинную базу данных была высокой раньше, а ввод-вывод и ЦП достигли 70% ~ 80%.Чтобы повысить эффективность пакетного запуска, рискованно увеличивать параллелизм приложения, потому что нагрузка на базу данных слишком высока, что может привести к задержке репликации мастера и резервной копии или невозможности быстрого переключения между ведущим и подчиненным, поэтому трудно повысить эффективность; очень сложно добавить поля или управление данными в миллиард- таблицы уровня или миллиарда.Хотя WeBank использует онлайн-инструменты DDL, такие как pt-online-schema-change, для ежедневного выполнения операций изменения таблицы, существует небольшая вероятность блокировки таблицы. Кроме того, с учетом использования ресурсов пакетная система и онлайн-система повторно используют одну и ту же базу данных на одном компьютере, поэтому, если пакетная задача вызывает высокую нагрузку, это, вероятно, повлияет на онлайн-транзакцию. Основываясь на этих фоновых проблемах, WeBank сделал обновление для оптимизации архитектуры с помощью TiDB.

Обновленная архитектура показана на рисунке ниже.Видно, что WeBank синхронизирует и агрегирует данные каждого бизнес-подразделения в TiDB в режиме реального времени с помощью инструмента DM, а затем пакетное приложение непосредственно выполняет пакетный расчет на основе TiDB, а затем передает результаты в базу данных.Платформа данных эквивалентна использованию горизонтальной масштабируемости TiDB для достижения горизонтального расширения эффективности пакетной обработки. Ранее традиционная архитектура MySQL master-slave требовала, чтобы сервер APP был развернут в том же IDC, что и главный узел MySQL, и если доступ к нему осуществляется через компьютерные комнаты, сетевая задержка будет относительно большой, что повлияет на время пакетной обработки. - потребление, поэтому другие приложения IDC Сервер находится в режиме ожидания, и будет определенная трата ресурсов, и все узлы TiKV в архитектуре TiDB могут читать и писать одновременно, поэтомуНесколько IDC могут запускать пакетные задачи одновременно, чтобы максимизировать использование ресурсов..

прирост стоимости

Использование TiDB в сценариях основного кредитного бизнеса WeBank обобщает три основных преимущества.

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

Линейное горизонтальное масштабирование. Требование WeBank заключается не только в повышении эффективности, но и в достижении горизонтального расширения, то есть эластичного масштабирования. Потому что с развитием бизнеса количество долговых расписок, включая количество пользователей, продолжает увеличиваться, и если есть горячие точки или другие узкие места, в будущем будет очень сложно продолжать улучшаться. На рисунке ниже показано сравнение потребления времени пакета.В случае начального ресурса он работает около 25 минут.Если количество данных удвоится, время увеличится до 50 минут.Если вы хотите уменьшить это время, то удвоить ресурсы, вы можете обнаружить, что время сокращается примерно до 26 минут, что показывает, что он имеет способность линейного расширения. Поэтому, помимо повышения эффективности, одним из преимуществ возможности линейного расширения является то, что с непрерывным развитием бизнеса объем заимствованных данных и объем заимствованных данных быстро увеличиваются.Эта архитектура не должна волноваться. о технических узких местах, которые могут возникнуть при быстром росте бизнеса, и бизнес может быть более сосредоточенным на самом продукте, это реальная ценность для бизнеса, которую приносит TiDB.

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

Оптимизация на основе TiDB

Вышеуказанные преимущества можно рассматривать как более очевидные, так какие же оптимизации сделал WeBank или с какими проблемами мы столкнулись?

Оптимизация схемы SQL. Из-за своей распределенной архитектуры TiDB имеет относительно более высокую задержку для одного запроса, чем MySQL, поэтому необходимо упаковать некоторые запросы, которые часто взаимодействуют с базой данных, чтобы свести взаимодействие к минимуму.Например, изменить несколько выборок на ins и вставить больше. метод для вставки нескольких значений и изменения нескольких обновлений для замены нескольких значений. Кроме того, поскольку все несколько единиц данных объединены в кластер TiDB, объем данных в одной таблице должен быть очень и очень большим.Если выполняется относительно неэффективный SQL, кластер легко вывести из строя.Например , существует риск OOM, поэтому особое внимание следует уделить аудиту и настройке SQL. Другим примером является проблема неточных планов выполнения в более ранних версиях.В версии 4.0 поддерживается привязка планов выполнения SQL, и некоторые высокочастотные SQL могут быть привязаны для более стабильной работы. Поскольку доступ WeBank к TiDB был относительно ранним, он в основном использует режим оптимистической блокировки, и приложение также сделало множество адаптаций.В настоящее время код для адаптации к режиму оптимистичной блокировки был объединен в общий модуль, который непосредственно используется при подключении новой системы.Просто используйте его. \
Горячие точки и оптимизация параллелизма приложений. Пользователи, которые больше используют TiDB, могут быть знакомы с проблемой горячих точек. Ранее мы упоминали эластичное масштабирование, но для эластичного масштабирования данные должны быть достаточно дискретными. Поэтому, когда WeBank подключился к TiDB на ранней стадии, он также обнаружил, что был похож на тот, который был в MySQL. Функция автоматического увеличения может иметь серьезные проблемы. Например, номер карты пользователя и номер долговой расписки также могут быть некоторыми непрерывными числами. Поэтому WeBank внес некоторые корректировки или оптимизации для этих двух областей, таких как изменение это автоматически случайным образом, Затем некоторые номера карт, в соответствии с его законом распределения данных, заранее вычисляют интервал распределения этих данных с помощью алгоритма, а затем используют область разделения, чтобы разбить функцию на предварительное разделение, так что каждый узел могут быть полностью использованы, когда большие пакеты записываются мгновенно.Кроме того, обработка кэша в приложении выполняется для небольших таблиц, которые изменяются с низкой частотой и обращаются к ним с высокой частотой, чтобы облегчить проблему горячего чтения. В дополнение к тому, что данные должны быть достаточно дискретными, приложение также должно быть оптимизировано для распределенного преобразования.Поскольку приложение является распределенным, узел App Master необходим для выполнения работы по сегментированию данных, а затем равномерного распределения задач сегментирования между Каждое приложение.Во время работы необходимо отслеживать статус и ход выполнения каждой сегментированной задачи, наконец, за счет совместной оптимизации данных и приложений достигается общая возможность горизонтального расширения. \
Синхронизация данных и оптимизация проверки данных. Это упомянутый выше способ, которым WeBank агрегирует данные различных бизнес-единиц через инструмент DM.Использовавшаяся на раннем этапе версия DM 1.0 не имеет функций высокой доступности, что фатально в финансовых сценариях. В версии DM 2.0 несколько функций, включая высокую доступность, совместимость с DDL в градациях серого и простоту использования, были запущены стабильно. Кроме того, это часть проверки данных.Поскольку это основной пакетный сценарий, синхронизация данных должна гарантировать, что данные не будут потеряны, что хорошо, поэтому приложение также включает логику контрольной суммы данных.Значение контрольной суммы каждого фрагмента записывается в таблицу, а затем синхронизируется с нижестоящей TiDB через DM. Наконец, приложение загружает каждый сегмент из TiDB во время пакетного запуска, а затем снова выполняет контрольную сумму соответствующего сегмента, а затем проверяет контрольные суммы восходящего и нисходящего потока. сравниваются, и благодаря такому механизму проверки обеспечивается непротиворечивость данных. \
Детализация ошибок и оптимизация восходящего плана. Раньше эта система была пакетной системой, основанной на MySQL. После перехода на TiDB некоторые сценарии сбоев могут показывать неожиданные явления, поэтому WeBank провел много упражнений на сбои. Во-первых, нужно смоделировать аномалию каждого узла компонента TiDB, чтобы убедиться, что приложение может В то же время, когда пакет прерывается, приложение также поддерживает непрерывный запуск точки останова, второй - перезапустить весь пакет Из-за возможности возникновения программных ошибок или непредвиденных проблем весь пакет должен для повторного запуска.Для быстрого восстановления перезапуска On-site в приложении разработаны функции быстрого резервного копирования и переименования флэшбека,третье упражнение для экстремальных сценариев.Например,предполагая,что библиотека TiDB становится недоступной в целом, WeBank объединил Dumpling и Lightning для выполнения быстрого резервного копирования и восстановления всего кластера.Сложности включают быстрое подтверждение точек восстановления для синхронизации DM, ручную предварительную встряску больших таблиц и т. д. Окончательный результат проверки соответствует требованиям корректности и своевременности. Поскольку эта архитектура включает в себя большой поток данных, было проведено много упражнений для сценариев сбоев и подготовки соответствующих СОП.

будущий план

WeBank начал исследования и POC в 2018 году и запустил первое приложение TiDB в 2019 году. В настоящее время приложение TiDB в WeBank охватывает кредиты, межбанковские операции, управление технологиями, базовые технологии и т. д. тестирование. Есть пять направлений планирования будущего:

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

2.Решение Persistence на основе Redis + TiKV.В основном это замена восходящего решения Redis + MySQL и использование естественных функций высокой доступности TiKV для создания постоянного решения.

3.Бюджетные приложения на основе дисков SAS.У WeBank есть много сценариев архивирования в банке, и объем данных особенно велик, потому что их нужно хранить в течение длительного времени из-за нормативных требований.Для таких сценариев с высокими требованиями к емкости хранилища, но низкочастотным доступом TiDB также будет выполнить несколько недорогих сценариев на основе дисков SAS.

4.Приложение TiDB на локализованной платформе ARM.В прошлом году WeBank уже запустил бизнес TiDB ARM.С тенденцией локализации в будущем эта область будет продолжать увеличивать инвестиции.

5.Оценка и применение TiFlash.TiFlash предоставляет возможности HTAP, особенно для таких сценариев, как управление рисками в режиме реального времени и упрощенный запрос AP, которые будут очень полезны.Это также ключевое направление планирования WeBank в будущем.