Еще пара примеров по Apache Hive и Spark: безопасный доступ и реализация SCD

Автор Категория , ,
Еще пара примеров по Apache Hive и Spark: безопасный доступ и реализация SCD

В этой статье для разработчиков распределенных приложений Apache Spark, администраторов SQL-on-Hadoop и дата-аналитиков рассмотрим особенности аутентификации удаленного пользователя, а также отслеживание измененных данных в таблицах Apache Hive. Читайте далее, зачем ограничивать доступ к keytab-файлу в кластерах с поддержкой защищенного протокола Kerberos, а также как реализовать отслеживание медленно меняющихся измерений в Hive-таблицах с помощью Apache Spark.

Имперсонализация доступа к Hive через Kerberos

Напомним, Apache Hive считается наиболее популярным инструментом стека SQL-on-Hadoop, позволяя обращаться к данным, хранящимся в HDFS или HBase с помощью SQL-подобных инструкций на языке HiveQL. Так разработчики распределенных приложений могут заменить MapReduce-операции на Jаvа более простыми запросами, которые знакомы каждому аналитику.

Рассмотрим один из типичных кейсов, когда внешнее приложение запрашивает данные из Apache Hive. Часто такое приложение использует шаблон аутентификации пользователя через службы единого входа (Single Sign-On, SSO) – технологии, при которой пользователь переходит из одной системы в другую без повторной аутентификации [1].

Реализация этой идеи в защищенном протоколе Kerberos, который стал стандартом де-факто в области Big Data, предполагает, что после успешной первичной аутентификации центр распределения ключей (Key Distribution Center, KDC) выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). Далее при обращении к отдельным ресурсам, пользователь предъявляет TGT и получает от центра распределения ключей удостоверение для доступа к конкретному сетевому ресурсу (Service Granting Ticket, TGS) [2]

Таким образом, в контексте приложения, которое обращается к данным Apache Hive, есть только идентификатор авторизованного пользователя. При этом на практике многие корпоративные приложения в кластере с Kerberos используют метод имперсонализации – проксирование с применением прав доступа другого авторизованного пользователя. Это достигается за счет создания супер-пользователя Hive (hivesuperuser), а само приложение использует его keytab – файл таблицы ключей, содержащий пары имен субъектов Kerberos и зашифрованные ключи, полученные из пароля Kerberos [1]. Этот файл может использоваться для идентификации в Kerberos без запроса пароля. Также для доступа к данным Hive внешнее приложение использует прокси JDBC с пользователем, вошедшим в систему. Про подключение удаленного сервера с Hive к приложению Spark через JDBC мы писали здесь.

Поскольку в файле keytab хранятся зашифрованные пароли, следует ограничить доступ к нему, чтобы читать его могли только субъекты, которые идентифицируются в приложении. Это важно, т.к. любой пользователь с правами чтения keytab может запустить команду в области Kerberos от имени субъекта, содержащегося в файле [4].

Для определения списка хостов, с которых разрешены запросы прокси, следует настроить свойство Hadoop hadoop.proxyuser. hivesuperuser.hosts, указав список IP-адресов, диапазоны IP-адресов в формате CIDR и/или имена хостов. При этом следует помнить, при работе кластер в безопасном режиме, суперпользователь должен иметь учетные данные Kerberos, чтобы иметь возможность выдавать себя за другого пользователя. При этом он не может использовать собственные токены делегирования, чтобы избежать угрозы подключения прокси-пользователя к сервису с привилегиями суперпользователя. Также следует задать свойство hadoop.proxyuser.hivesuperuser.groups, чтобы указать список групп HDFS, которые можно имперсонализировать [1].

CDC для медленно меняющихся данных

Отслеживание измененных данных (Сhange Data Cap, CDC) – довольно популярный подход к интеграции данных в разных информационных системах, основанный на идентификации, регистрации и доставке изменений в источниках во внешние места назначения. Технически это реализуется с помощью табличных триггеров, отметок времени или номеров версий в строках таблиц СУБД, сканирования лог-файлов или обработки событий. Одна из разновидностей этого подхода, механизм отслеживания медленно меняющихся измерений (Slowly Changing Dimensions, SCD) активно используется в хранилищах данных и OLAP-кейсах, что подходит для Apache Hive.

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

Предположим, эти базовые данные хранятся в таблицах Hive (снапшоты и исторические данные) в формате Parquet. Необходимо сравнить входящие данные с существующими, идентифицировать изменившиеся записи и отразить эти изменения в Hive-таблицах. Это можно реализовать с помощью простого Spark-приложения, которое работает по следующему принципу [5]:

  • определение изменяющихся данных, отделяя список столбцов без изменений, от тех, которые изменились, поскольку Parquet является столбцовым (колоночным) форматом;
  • вычисление MD5-хэша входящих данных и сравнение его с хэшем MD5 существующих данных, чтобы определить обновленные записи. Сохранение кэша может повысить производительность, но ограничить некоторые функции при добавлении дополнительных столбцов в список неизменившихся.
  • выполнение внешних соединений – left join для идентификации вставленных и right join для удаленных записей. Использование широковещательных соединений (broadcast joins) будет эффективно при небольшом объеме входящих данных.

Исходный код реализации этих шагов представлен в источнике [6]. Разумеется, этот кейс не является универсальным, поскольку SCD бывает 4-х типов, в зависимости от процедур изменения данных. В частности, тип 0 предполагает только создание новых записей, а 3-ий использует добавление новых столбцов-атрибутов, хранящих предыдущее значение для поддержания историчности. Выбор SCD-типа определяется бизнесу-потребностями, например, 3-ий тип подходит для отслеживания ограниченного перечня параметров, 2-ой – полностью обеспечивает сохранение историчности, 1-ый просто актуализирует значения имеющихся данных, а 0-ой добавляет новые [7].

Все эти случаи можно реализовать в Apache Hive средствами Spark. Как это сделать практически, а также другие полезные примеры администрирования и эксплуатации Apache Hive со Spark для разработки распределенных приложений и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://vibushanan.medium.com/hive-user-impersonation-25142ea1f868
  2. https://ru.wikipedia.org/wiki/Технология_единого_входа
  3. https://www.ibm.com/docs/ru/elm/7.0.3?topic=clients-scripted-authentication
  4. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Superusers.html
  5. https://medium.com/@akashmehta10/change-data-capture-cdc-using-spark-hive-big-data-beca5afd669f
  6. https://github.com/akashmehta10/cdc_pyspark_hive
  7. https://ru.wikipedia.org/wiki/Медленно_меняющееся_измерение