Apache Kudu против InfluxDB на данных временных рядов для быстрой аналитики

Question

Как Apache Kudu сравнивается с InfluxDB для данных датчика IoT, которые требуют быстрой аналитики (например, робототехники)?

Куду недавно выпустил v1.0 У меня есть несколько конкретных вопросов о том, как Куду справляется со следующим:

1. Sharding?
2. Политики хранения данных (хранение данных для определенного количества точек данных или времени и последующее агрегирование / удаление данных)?
3. Существуют ли функции объединения / агрегирования (например, преобразование данных с интервалом в 1 с в данные с интервалом в 1 мин)?
4. Есть ли поддержка непрерывных запросов (то есть материализованных представлений данных - запрос для просмотра 60 секунд на постоянной основе)?
5. Как данные хранятся между диском и памятью?
6. Можно ли индуцировать регулярные временные ряды из нерегулярных (преобразование данных о нерегулярных событиях в регулярные временные интервалы)?

Также есть ли другие сильные и слабые стороны между Kudu и InfluxDB?

Answer 1

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

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

Что касается ответов на ваши вопросы.

1) Kudu хранит данные в планшетах и ​​предлагает два способа разделения данных: разделы диапазона и разделение на основе хэша

2) Нет. Хотя, если данные были структурированы с разделением по диапазонам, удаление планшета должно быть эффективной операцией (аналогично тому, как InfluxDB удаляет целые осколки при удалении данных).

3) Механизмы запросов, которые работают с Kudu, могут делать это, например, Impala или Spark.

4) Импала имеет некоторую поддержку взглядов

5) Данные хранятся в столбчатом формате, аналогичном формату Parquet, однако большое преимущество Куду состоит в том, что Kudu позволяет столбчатым данным изменяться, что очень сложно в современных паркетных файлах.

6) Хотя я уверен, что вы можете получить искру или импалу, чтобы сделать это, это не встроенная функция.

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