предисловие

Журналы поведения пользователей на стороне клиента всегда были известны своим большим объемом.Обычно можно просматривать сотни миллионов, миллиарды или даже десятки миллиардов журналов в день.Когда дело доходит до сбора журналов на стороне клиента, нам нужно говорить о своевременности и точности сбора логов. Для хранения массивных лог-данных хороши как обычная система hadoop, так и популярный в последнее время ClickHouse.Преимущества и недостатки также находятся в центре нашего обсуждения. Анализ массивных данных — вечная тема, в этом плане ClickHouse вроде дал почти идеальное решение, но дело в том, что если вы хотите использовать его в своем проекте, то для достижения комплексного понимания его характеристик ваши цели основная предпосылка. В следующей статье мы вместе изучим эту тему.

---

1. Как быстро собрать массивные бревна

Чтобы добиться быстрого хранения массивных данных, мы должны сначала решить проблему посадки данных в случае высокой параллелизма и высокой пропускной способности, в этом отношении Nginx — лучший выбор. Обрабатывающая способность одного сервера Nginx с основной конфигурацией может легко достигать 10000+/с; в соответствии с этой вычислительной мощностью один сервер может обрабатывать: 3600 с в день.24h10000 = почти миллиард данных. После обработки также необходимо использовать какие технологии мы специально разобрали ниже.

1. Анализ архитектуры

2. Что умеет Nginx

- обратный прокси

- балансировки нагрузки

- HTTP-сервер (разделение на динамический и статический)

- форвардный агент Это его главная роль в коллекции журнала, используйте его, чтобы делать то, что мы делаем?

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

3. Что делать с файлами, на которые попал Nginx?

В современных интернет-технологиях трудно не говорить о kafka, когда речь идет о больших данных.После того, как данные входят в kafka, наша обработка данных становится гладким делом. Здесь мы используем знаменитую FileBeta для отправки данных из файлов данных, собранных Nginx, в kafka в квазиреальном времени. Следующий план, похоже, прошел гладко.

Во-вторых, применение ClickHouse в сфере хранения данных

1. Запись данных ClickHouse

1. Механизм таблиц MergeTree: для этого механизма таблиц это самый мощный механизм таблиц ClickHouse, ни один из которых таковым не является. Но это не отдельный человек, это серия. Известна как серия MergeTree.

2. Возможности движка таблиц MergeTree

Основная идея семейства двигателя Mergetree:

(1) Пакетная запись.

(2) Фрагменты данных объединяются в фоновом режиме по определенным правилам.

Главная особенность:

(1) Сохраненные данные сортируются по первичному ключу.

(2) Автоматически создавать разреженные индексы для быстрого поиска данных.

(3) разрешающий раздел (указать ключ раздела).

(4) В случае одного и того же набора данных и одного и того же набора результатов некоторые секционированные операции в Clickhouse будут выполняться быстрее, чем обычные операции.

(5) Когда в запросе указан ключ раздела, ClickHouse автоматически перехватывает данные раздела, что увеличивает производительность запроса.

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

Clickhouse поддерживает запрос (выбор) и добавление (вставка), но напрямую не поддерживает обновление (обновление) и удаление (удаление).

Вставка: MergeTree не является LSM-деревом, поскольку не содержит «memtable» и «log»: вставленные данные записываются непосредственно в файловую систему. Это делает его пригодным только для пакетной вставки данных, а не для очень частой вставки одной строки; одна вставка в секунду — это хорошо, а тысяча в секунду — нет. Если у вас есть много контента, который вы хотите вставить, вы можете использовать механизм буфера, который делает буферизованные данные в ОЗУ и периодически сбрасывает их в другую таблицу.

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

Например, мы должны производить 100 000 данных в секунду, то мы будем помещать его за один раз. Если мы производим только один данные в секунду (тогда нам не понадобится кликиус ... (:!)

2. Обновление данных Clickhouse

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

1. Clickhouse реализует UPDATE и DELETE через варианты ALTER.

Мутации — это вариант запроса ALTER, который позволяет изменять или удалять строки в таблице. Мутации подходят для операций, которые изменяют много строк в таблице (операции с одной строкой также подходят).

Эта функция находится на стадии тестирования и доступна с версии 1.1.54388. Функции обновления MUTATIONS доступны с версии 18.12.14, а механизм MrgeTree поддерживает Mutations. Существующие таблицы готовы к мутации (без преобразования), но после применения первой мутации к таблице формат метаданных будет несовместим с предыдущей версией сервера и возврат к предыдущей версии невозможен.

Команда выглядит следующим образом: ALTER TABLE [db.]table DELETE WHERE filter_expr;

ALTER TABLE [db.]table UPDATE column1 = expr1 [ …] WHERE filter_expr;

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

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

INSERT также частично видоизменены — данные, вставленные в таблицу до совершения мутации, будут изменены, данные, вставленные позже, не будут изменены. Обратите внимание, что мутации никоим образом не препятствуют выполнению операций INSERT.

Сама мутация выполняется асинхронно с использованием настроек файла конфигурации системы. Чтобы отслеживать ход мутаций, вы можете использовать таблицу system.mutations. Успешно отправленные мутации продолжат выполняться, даже если сервер ClickHouse будет перезапущен. Как только мутация зафиксирована, ее нельзя откатить, но если она по какой-то причине застряла, ее можно отменить с помощью KILL MUTATION.

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

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

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

2. Если вы не хотите использовать мутацию, в конце концов, мутация не является атомарной и накладные расходы высоки, другой лучший выбор — использовать ReplacingMergeTree вместо MergeTree.

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

Например: (1) Создайте таблицу:

CREATE TABLE event_log.users (

`id` Int64,

`first_id` String,

`second_id` String,

`insert_date` DateTime DEFAULT now()

) ENGINE = ReplacingMergeTree(insert_date)

PRIMARY KEY id

ORDER BY id

SETTINGS index_granularity = 8192;

Вставьте в эту таблицу два фрагмента данных с одинаковым id. Когда ClickHouse автоматически выполнит операцию оптимизации, он очистит первый фрагмент данных, вставленный в соответствии с insert_date, и сохранит только данные, вставленные позже.

(2) Операция обновления таблицы:

在新的数据需要更新主键相同的旧数据时，我们首先用select 。 . . where id = fix_id(固定的主键id)查询出来老的数据信息，按照新数据传入的新字段更新查询结果，并执行insert 语句。接下来等待optimize自动执行就可以了。

(3) Если вам нужно убедиться, что запрашиваемые данные являются новыми данными, вы можете добавить FINAL к запросу, но это снизит эффективность запроса, и мы можем использовать его соответствующим образом в приложении проекта.

Суммировать

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