FunData — эволюция архитектуры системы больших данных для киберспорта

На ранней стадии разработки проекта, согласно теории MVP (Minimum Viable Product), мы быстро запустили первую версию системы FunData (схема архитектуры представлена ​​на рисунке 1). Система в основном состоит из двух модулей: Master и Slave.

Функции Мастер-модуля следующие:

• Регулярно вызывайте API Steam, чтобы получить идентификатор игры и основную информацию.

• Распределите задачи анализа игры на подчиненные узлы через очередь сообщений в памяти.

• Записывайте ход анализа игры и определяйте статус каждого ведомого узла.

Функции ведомого модуля следующие:

• Отслеживайте сообщения очереди и получайте задачи (задачи в основном состоят из анализа видео, анализ видео относится к ясности проекта github (https://github.com/skadistats/clarity) и манте (https://github.com/dotabuff/manta))

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

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

1. Добавление новых полей данных требует перестроения индекса БД.Таблица данных имеет сотни миллионов строк.Время построения слишком велико и таблица заблокирована на долгое время.

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

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

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

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

фигура 11.0 Схема архитектуры ETL

Прежде чем приступить к проектированию и преобразованию архитектуры 2.0, мы попытались использовать метод холодного хранения для снижения нагрузки на систему за счет переноса данных (схема архитектуры показана на рис. 2). Из-за большого объема данных в таблице данных требуется много времени для одновременного выполнения нескольких задач переноса данных.Процесс очистки данных также вызовет перестроение индекса.Запуск решения не кардинально решить проблему.

фигура 2решение для холодного хранения

Опираясь на опыт системы 1.0, при проектировании архитектуры 2.0 мы рассматриваем основные характеристики, которыми должна обладать новая архитектура системы данных с трех аспектов: ремонтопригодность, масштабируемость и стабильность:

• Уточнена детализация задач обработки данных, поддерживается высокая параллельная обработка (в день по всему миру проходит 1,2 миллиона матчей DOTA2, анализ видео занимает относительно много времени, а последовательная обработка приведет к серьезному накоплению задач)

• распределенное хранилище данных

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

изображение 3Общая схема архитектуры 2.0ETL

Система 2.0 выбирает Google Cloud Platform для создания всей системы данных ETL и использует PubSub (аналог Kafka) в качестве шины сообщений.Задачи уточняются в несколько тем для мониторинга и обработки разными работниками. Таким образом, с одной стороны, уменьшается сцепление разных задач, что предотвращает обработку исключений одной задачей и прерывание других задач, с другой стороны, задачи передаются на основе шины сообщений, а масштабируемость различных задачи с данными становятся лучше, и он может быстро масштабироваться по горизонтали, когда производительности недостаточно.

С точки зрения детализации задач (как показано на рисунке 3) обработка данных делится на две части: базовая обработка данных и высокоуровневая обработка данных. Базовые данные, то есть подробная информация об игре (KDA, данные об уроне и ремонте и т. д.) и данные анализа видео (данные об убийстве Рошана, данные о типе урона и тепловой карте разделения героев и т. д.) запускаются Супервайзером, получающим Steam данные и очищаются воркерами, после чего сохраняется в Google Bigtable, высокоуровневые данные, то есть многомерные статистические данные (такие как данные героев, реквизита и командных боев), срабатывают после анализа видео и агрегируются через поток данных GCP и собственные аналитические узлы (рабочие), наконец, сохраненные в MongoDB и Google Bigtable.

Согласно подробной архитектуре Leauge-ETL (как показано на рисунке 4), исходный единственный подчиненный узел разделен на 4 подмодуля, а именно: модуль анализа данных лиги, модуль анализа видео лиги, модуль агента базы данных анализа/добычи данных. и модуль мониторинга анализа лиги.

1. Модуль анализа данных лиги отвечает за извлечение видеофайлов (получение соли, метафайлов и файлов повторов) и анализ основных игровых данных.

2. Модуль анализа видео лиги отвечает за анализ игрового видео и отправляет проанализированные данные в PubSub.

3. Агент Analysis/Mining Data DB отвечает за получение данных анализа видео и их запись в Bigtable пакетами.

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

В то же время все модули выбирают Golang для рефакторинга и используют его «врожденную» возможность параллелизма для повышения производительности интеллектуального анализа данных и обработки данных всей системы.

Рисунок 4Лига-ETL Архитектура

Как было сказано выше, в архитектуре 1.0 мы используем MySQL для хранения большого количества игровых данных и данных анализа видео. В сценарии высокого параллелизма больших данных разработка всего приложения MySQL становится все более и более сложной.Если оно не может поддерживать частые изменения схемы, при проектировании архитектуры необходимо разумно учитывать время подбазы данных и подбазы данных. -table, а данные подбазы данных достигают определенного порядка.Сталкивался с проблемами масштабируемости.

Ссылаясь на Google Bigtable (подробности см. в разделе «Большая таблица: распределенная система хранения структурированных данных») и HBase экосистемы Hadoop (рис. 5), как на распределенную и масштабируемую систему хранения больших данных, Bigtable и HBase могут хорошо работать вместе. -время чтения и записи данных, что больше подходит для уровня данных и сложности системы данных FunData.

Рисунок 5Экосистема Hadoop

В модели данных Bigtable и HBase находят часть данных (ячейку) через RowKey, имя столбца и отметку времени. (Рисунок 6)

(rowkey:string,columnfamily:columnstring,timestamp:int64)→value:string

Изображение 6индекс данных

Например, в системе данных FunData RowKey данных матча строится в виде hash_key+match_id, потому что match_id DOTA2 увеличивается последовательно (значение не является уникальным в приращениях), а согласованный алгоритм хеширования добавляется перед каждый match_id.hash_key может предотвратить проблему горячих точек с одним компьютером в распределенном хранилище, улучшить возможности балансировки нагрузки данных всей системы хранения, добиться лучшего сегментирования и обеспечить масштабируемость последующих узлов данных.

(Как показано на рисунке 7) Сначала мы задаем несколько значений ключа в качестве префикса RowKey в хеш-кольце. Когда match_id получен, значение ключа, соответствующее match_id в узле хеш-кольца, получается с помощью согласованного алгоритма хэширования. , и, наконец, значение ключа и match_id объединяются для создания RowKey.

RowKey=Hash(MatchID)+MatchID=Key_n+MatchID

Рисунок 7Последовательный хэш строит RowKey

Использование временной метки удобно для многократной записи данных одного и того же RowKey и столбца при агрегировании данных.HBase/Bigtable имеет собственную стратегию GC, которая будет очищать просроченные данные временной метки и брать последний узел времени при чтении. данные могут быть.

У вас может возникнуть вопрос. Bigtable и HBase можно использовать только как индексы первого уровня. После добавления hash_key в RowKey вы не можете использовать row_range для пакетного чтения или пакетного запроса в соответствии с измерением времени. В процессе использования Bigtable и HBase вторичный индекс необходимо настроить в бизнесе. В реальном сценарии, когда наши работники обрабатывают данные каждой игры, они также создают индекс по временной метке-RowKey и сохраняют его в MySQL.Когда требуется пакетный запрос на основе времени, сначала запросите индексную таблицу, чтобы получить список RowKey. , а затем Получить соответствующий список данных.

С точки зрения чтения и записи данных Bigtable/HBase также сильно отличается от MySQL. Как правило, MySQL использует кеш запросов, и кеш будет недействителен при обновлении схемы. Кроме того, кеш запросов защищен глобальной блокировкой. Когда кешируется большой объем данных, если кеш запросов недействителен, стол будет заблокирован.

Как показано на рисунке 8, на примере HBase, при чтении данных клиент сначала находит RegionServer, на котором находится RowKey, через zookeeper.После того как запрос на чтение достигает RegionServer, RegionServer организует операцию сканирования и, наконец, объединяет результаты запроса. и возвращает данные. Поскольку операция запроса может включать в себя несколько серверов регионов и несколько регионов, поиск данных выполняется одновременно и LRUBlockCache HBase, запрос данных не будет полностью заблокирован.

Рисунок 8HBase-архитектура

Основываясь на новой архитектуре хранилища, наше измерение данных расширилось от одной игры до игроков, героев, лиг и т. д. (Рисунок 9)

Рисунок 9измерение данных

Выше мы упоминали, что очередь сообщений In-Memory используется для передачи данных в архитектуре 1.0.Поскольку данные очереди в памяти не хранятся постоянно и сильно связаны с модулем Master, потеря данных произойдет после обновления узла Master. или возникает ненормальная паника, и время восстановления будет отложено. Поэтому в архитектуре 2.0 в качестве шины сообщений используется сторонняя очередь сообщений, чтобы обеспечить развязку «восходящих и нисходящих» узлов системы, которые можно итеративно обновлять несколько раз, исторические сообщения становятся отслеживаемыми, а облачные накопление сообщений на основе платформы также становится визуальным (рис. 10).

Рисунок 10Мониторинг данных

Слой API данных системы 1.0 не слишком сильно проектировался и оптимизировался в архитектуре для достижения быстрого запуска.Он использует доменные имена для достижения балансировки нагрузки и использует уровень ORM, созданный DreamFactory с открытым исходным кодом, для использования своего интерфейса RESTful для данных. доступ. Архитектура столкнулась с множеством проблем во время разработки и использования:

1. Слой API развернут в облаке Alibaba Cloud в Китае, и доступ к данным должен быть через океан.

2. API, предоставляемый уровнем ORM, получает полные данные поля таблицы, и степень детализации данных велика.

3. Нет кеша, чтобы иметь дело с сценариями с высоким трафиком (такими как Кубок Эпицентра 2017 и ESL), сервис часто недоступен

4. Агрегация данных нескольких БД размещена на уровне API, а производительность недостаточна.

5. Затраты на обслуживание обновлений службы высоки, и каждое обновление должно сначала удалить машину из доменного имени.

В ответ на вышеуказанные проблемы мы реконструировали уровень API данных версии 1.0 с двух точек зрения. (Как показано на рисунке 11)

Рисунок 11Новая архитектура API данных

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

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

Кроме того, чтобы обеспечить стабильность внутренних трансокеанских каналов доступа, мы построили прокси-уровень данных в компьютерном зале Alibaba Cloud в Северной Америке и использовали зарубежные выделенные линии для повышения скорости доступа.

После подключения к распределенной системе хранения уровень API внешних данных также разделяется в соответствии с измерением расширенных данных, и несколько API данных предоставляют внешние услуги.Например, данные, такие как игровые данные и расписания лиг, имеют большой объем доступа, который должны быть связаны с героями, людьми и реквизитом.Данные разделены, чтобы аномалия интерфейса игры/события не повлияла на все недоступные данные.

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

В техническом разделении этой статьи мы введем процесс эволюции архитектуры платформы данных Фундата, проанализируйте недостатки старой системы с точки зрения архитектуры, а также какие технические и архитектурные средства решают в новой системе. Поскольку Fundata пошли на 10 апреля, более 300 технологических разработчиков подали заявку на API-ключ. Мы также сосредотачиваемся на быстром итеративном развитии новых точек данных, таких как статистика лиги, данные в прямом эфире и т. Д.