Qiniuyun: платформа больших данных на основе Go

Pandora — это кодовое название команды Qiniu по работе с большими данными и всей серии продуктов.Наша цель — предоставить простую, открытую и эффективную универсальную платформу для работы с большими данными.

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

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

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

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

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

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

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

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

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

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

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

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

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

Если во время предварительной выборки данных нет, заснуть на 1 с, а затем получить данные, так как? (Последующие действия) Если данных нет, время ожидания будет удвоено до 32 с. Если данные будут извлечены во время процесса, время ожидания будет сброшено до 1 с. Этот механизм эффективно снижает количество запросов к базовому хранилищу.

Мы оптимизировали протокол передачи данных между службой экспорта и logdb. Сначала использовался Json, но его производительность сериализации и десериализации была низкой, а загрузка ЦП в нижестоящей системе была очень высокой, что сказывалось на общей производительности службы.

После исследования мы изменили формат Json на Protobuf. Было замечено, что потребление полосы пропускания сократилось почти наполовину, пропускная способность была улучшена, а потребление ресурсов ЦП также сократилось более чем наполовину.

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

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

Golang RPC используется для связи между мастером и сервером. Сервер сообщает о пульсе, чтобы доказать, что он активен, и сообщает о состоянии выполненных задач. Мастер периодически выдает задачи серверу, а сервер управляет своими собственными задачами, чтобы решить, какие задачи выполнять, а какие отбрасывать.

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

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

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

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

Он обрабатывает более 100 миллиардов точек данных и сотни терабайт данных каждый день. Задержка онлайн-экспорта составляет менее 1 минуты, меньше ручного вмешательства. Расширение второго уровня, система визуального мониторинга в режиме реального времени, простая в использовании система сигнализации и автоматическое создание ежедневных онлайн-отчетов.

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

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

Golang прост в использовании и быстро начинает работать. Снизьте умственную нагрузку программистов и сосредоточьтесь на бизнесе. Более простая и эффективная модель параллелизма, естественно, поддерживает написание распределенных сервисов, и у нас есть богатые библиотеки, которые мы можем вызывать. Qiniu — одна из первых компаний в Китае, которая начала практиковать язык го.Внутренние RPC и кэш-система компании на основе golang были отшлифованы до очень зрелого уровня.

На сегодня это все, всем спасибо!