Apache Kylin отказоустойчивость

Question

Apache Kylin выглядит как отличный инструмент, который заполнит потребности многих ученых-ученых. Это также очень сложная система. Мы разрабатываем внутреннее решение с точно такой же целью - многомерный OLAP-куб с низкой задержкой запросов. Среди многих вопросов, о которых я сейчас беспокоюсь, речь идет о отказоустойчивости. С большими объемами входящих транзакционных данных куб должен быть инкрементно обновлен, а некоторые из кубоидов обновляются в течение длительного периода времени, например, с указанием значения времени в масштабе года. За такой длительный период некоторая часть сложной системы, как правило, терпит неудачу, и как система гарантирует, что все необработанные транзакционные записи агрегируются в кубоиды ровно один раз, не больше, не меньше? Даже у каждой из частей есть свой механизм отказоустойчивости, это не значит, что они будут играть вместе автоматически. Для простоты мы можем предположить, что все входные данные сохраняются в HDFS другим процессом и могут быть «воспроизведены» любым способом, который вы хотите восстановить из любого прерывания, добровольного или принудительного. Каковы соображения отказоустойчивости Килина, или это не проблема?

Answer 1

Примечания: Я являюсь соучредителем и коммиттером Apache Kylin.

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

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

Поместит эту идею в наш архив и обновит список рассылки Kylin dev, если у нас будет более понятная подсказка для этого позже.

Спасибо.

Answer 2

Имеются ошибки данных и системные сбои.

Отказоустойчивость данных: Kylin разделяет куб на сегменты и позволяет перестраивать отдельный сегмент без воздействия на весь куб. Например, предположим, что новый ежедневный сегмент строится ежедневно и объединяется в недельный сегмент в выходные дни; еженедельные сегменты сливаются в ежемесячный сегмент и т. д. Когда в течение недели возникает ошибка данных (или какое-либо изменение), вам нужно перестроить сегмент только одного дня. Для дальнейшего изменения данных потребуется перестраивать недельный или месячный сегмент.

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

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

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

(Я также являюсь соавтором и сторонником Apache Kylin. :-)