Многопользовательская реализация с Apache Kudu

Question

Я внедряю систему больших данных с использованием Apache Kudu. Предварительные требования следующие:

1. Поддержка Multi-Tenancy
2. Клиентский интерфейс будет использовать драйверы Apache Impala JDBC для доступа к данным.
3. Клиенты будут писать Spark Jobs на Kudu для аналитических случаев использования.

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

Путь:

Каждая таблица будет иметь столбец tenantID, и все данные всех арендаторов будут храниться в одной таблице с соответствующим tenantID.

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

CREATE VIEW IF NOT EXISTS cust1.table AS SELECT * FROM table WHERE tenantid = 'cust1';

Customer1 получит доступ к таблице cust1.table для доступа к данным cust1 с помощью драйверов JDBC Impala или из Spark. Customer2 получит доступ к таблице cust2.table для доступа к данным cust2 и так далее.

Вопросы:

1. Является ли это приемлемым способом реализации мультитенантности или есть лучший способ сделать это (может быть с другими внешними службами)
2. Если реализовано таким образом, как я могу ограничить customer2 от доступа к cust1.table в Kudu, особенно когда клиент будет писать свои собственные рабочие места для аналитических целей.

Answer 1

У нас была встреча с ребятами из Cloudera, и вот ответ, который мы получили на вопросы, которые я разместил выше

Вопросы:

1. Является ли это приемлемым способом реализации мультитенантности или есть лучший способ сделать это (может быть с другими внешними службами)
2. Если реализовано таким образом, как я могу ограничить customer2 от доступа к cust1.table в Kudu, особенно когда клиент будет писать свои собственные рабочие места для аналитических целей.

ответы:

1. Как отметил Самсон в комментариях, на данный момент у Kudu нет ни политики доступа, ни политики полного доступа. Поэтому предлагается использовать Impala для доступа к Kudu.

   Поэтому вместо того, чтобы иметь каждую таблицу со столбцом TenantID, каждая таблица арендаторов создается отдельно. Эти таблицы Куду отображаются в Impala как внешние таблицы (предпочтительно в отдельных базах данных Impala).

   Затем доступ к этим таблицам контролируется с помощью Sentry Authorization в Impala.

2. Для доступа к Spark SQL также предлагался сделать видимыми только таблицы Imapala, а не напрямую обращаться к таблицам Куду. Затем требования аутентификации и авторизации снова обрабатываются на уровне Impala, прежде чем Spark Jobs получат доступ к нижним таблицам Kudu.