#hdfs

Learn how Harley Davidson Financial helps riders finance their dreams with custom loans, insurance, and credit options tailored for motorcyc

Зачем делать моментальные снимки состояния распределенной файловой системы Apache Hadoop, почему не стоит создавать снапшоты HDFS в корневом каталоге и как найти оптимальную частоту сохранения состояния больших данных.Как устроен механизм снапшотов в HDFSЧтобы повысить надежность системы, ее состояние необходимо периодически сохранять. Для баз данных и файловых систем эта операция реализуется с помощью механизма снапшотов (snapshot) – моментальных снимков текущего состояния системы на конкретный момент времени. В отличие от бэкапа – резервной копии всего объема данных, который создается долго и предполагает блокировку изменений, чтобы гарантировать консистентность данных, моментальный снимок фиксирует мгновенное состояние хранимых объектов, не создавая их полную и независимую копию. Эта технология позволяет организовать целостное резервное копирование большого объёма данных без блокировки мутации данных, если делать бэкап с зафиксированного снапшота. Также снапшоты позволяют защитить систему от ошибок пользователя и обеспечить аварийное восстановление в случае критического сбоя, откатившись к зафиксированному рабочему состоянию.Идея снапшотов в распределенной файловой системе Apache Hadoop реализована очень эффективно: снимок создает мгновенно, независимо от размера и глубины поддерева каталога, фиксируя список блоков и размер файла для указанного поддерева. При этом дополнительные копии блоков HDFS не создаются: моментальный снимок фиксирует список блоков и размер файла без фактического копирование данных, в отличие от процедуры создания бэкапа.Само создание моментального снимка всегда требует одинаковых усилий, поскольку создается только запись каталога таблицы снапшотов и его состояния на тот момент. Однако, удаление моментального снимка HDFS требует обхода всего поддерева бинарного поиска для каждого файла или каталога со сбором блоков, которые будут удалены. Это приводит к накладным расходам и может потребовать большого объема памяти для сбора блоков. Вычислительная сложность определения отличий между 2-мя разными снапшотами также зависит от количества файлов и каталогов в пути сравнения, изменений и сделанных снимков. Определить эти различия позволяет команда snapshotDiff. Если запустить ее с опцией -update, можно переместить вычисленную разницу в указанный целевой каталог.Создание снапшотов не влияет на регулярные операции HDFS: изменения записываются в обратном хронологическом порядке, поэтому прямой доступ к текущим данным не блокируется. Данные снапшота вычисляются путем вычитания изменений из текущих данных. Чтобы разрешить создание снапшота в каком-либо каталоге HDFS, администратор должен разрешить эту возможность, установив конфигурацию snapshottable. Каталог с такой настройкой может одновременно хранить 65 536 снимков без ограничений на количество каталогов таблиц снапшотов.Однако, если в каталоге таблицы снапшотов уже есть моментальные снимки, такой каталог нельзя удалить или переименовать до удаления снимков. Вложенные каталоги таблиц снапшотов не допускаются, т.е. каталог не может snapshottable, если какой-либо из его предков или потомков имеет эту настройку включенной.Разобравшись с основами работы механизма снапшотов в HDFS, далее рассмотрим лучшие практики его использования.ТОП-5 советов по работе с моментальными снимками распределенной файловой системы Apache HadoopНе рекомендуется создавать моментальные снимки в корневом каталоге файловой системы, который включает папку с временными данными (tmp) и корзину, где содержится множество ненужных файлов. Эти файлы будет невозможно фактически удалить, если они содержатся в снапшотах.Поэтому не следует делать снапшоты HDFS слишком часто. Лучше создавать моментальные снимки только при необходимости, например, только после завершения заданий и высоких рабочих нагрузок, чтобы избежать записи файлов tmp. Также следует регулярно удалять ненужные снимки.Рекомендуется установить единые политики моментальных снимков для всей файловой системы, несмотря на разное содержание каталогов HDFS. Если в разных проектах будет разное время удаления собственных снапшотов, есть вероятность случайно удалить не тот снимок, что приведет к сложной реструктуризации внутренних данных. В свою очередь, откат назад с его восстановлением может быть долгим, поскольку зависит от количества операций и промежуточных снимков между исходным и текущим состояниями, как было отмечено ранее. Поэтому рекомендуется создавать снимки в каталогах проекта и каталогах пользователей.Чтобы процедура сравнения не занимала слишком много времени, лучше вычислять разницу между снашпотами, когда она не слишком велика, т.е. между сравниваемыми снимками прошло не слишком много времени. Поэтому рекомендуется вычислять для вновь созданных снимков, время создания которых не слишком отличается. По аналогичной причине не следует запускать сравнение снимков в snapshottable-каталоге, который может включать в себя временные файлы.При удалении нескольких снимков лучше удалять их по мере обновления, т.е. от самого старого к самому новому, поскольку удаление снапшотов в случайном порядке может привести к сложной реструктуризации внутренних данных. Определить порядок создания моментальных снимков поможет команда lsSnapshot . Затем можно отсортировать выходные данные по идентификатору моментального снимка. Если самый старый снимок файловой системы больше не нужен, его следует немедленно удалить: это поможет освободить место, но не приведет к потере данных.Освойте администрирование и эксплуатацию Apache Hadoop для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:- Основы Hadoop- Администрирование кластера Hadoop- Hadoop для инженеров данныхИсточники1. https://blog.cloudera.com/hdfs-snapshot-best-practices/2. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsSnapshots.html3. https://docs.cloudera.com/runtime/7.2.0/data-protection/topics/hdfs-using-hdfs-snapshots.html

В этой статье для дата-инженеров и разработчиков распределенных приложений рассмотрим, какие механизмы обеспечения информационной безопасности поддерживает Apache Spark и как организовать безопасное взаимодействие Spark-приложения с хранилищами данных в экосистеме Hadoop.Безопасная работа Spark-приложений с сервисами HadoopМногие технологии Big Data изначально оптимизированы для хранения и аналитики больших объемов данных с высокой производительностью и надежностью. Информационной безопасности не уделялось столько внимания. В частности, в Apache Spark многие функции безопасности, такие как проверка подлинности, по умолчанию не включены. Поэтому при развертывании кластера, открытого для доступа извне, важно предотвратить запуск неавторизованных приложений. Spark поддерживает несколько типов развертывания, каждый из которых поддерживает разные уровни безопасности, причем ни один из них не является безопасным по умолчанию. Исторически так сложилось, что кластер Spark и его сервисы обычно развертываются не в общедоступной сети, а в корпоративном пространстве. Поэтому доступ к узлам и портам, используемым сервисами Spark, должен быть ограничен исходными узлами, которым необходим доступ к этим службам.Обычно приложения Apache Spark работают с данными, хранящимися в корпоративном озере, основанных на компонентах экосистемы Hadoop, таких как распределенная файловая система HDFS или NoSQL-СУБД Hive и HBase. Поэтому важно обеспечить безопасное взаимодействие Spark-приложения с этим хранилищами данных. Например, Spark поддерживает отправку приложений в средах, использующих защищенный протокол Kerberos для проверки подлинности компьютерной сети. Kerberos использует локальную форму идентификации с помощью билетов (ticket), предоставляемых сервером аутентификации. Любой билет зашифрован и имеет область действия (realm), покрывающие набор нужных сервисов. Для использования билета необходимо несколько уровней дешифрования, что исключает отправку конфиденциальных данных по сети. В большинстве случаев Spark использует учетные данные текущего вошедшего в систему пользователя при аутентификации в службах, поддерживающих Kerberos. Такие учетные данные можно получить, войдя в настроенный центр распространения ключей (KDC, Key Distribution Center), например, с помощью kinit – инструмента получения и кэширования билетов выдачи билетов Kerberos.Кроме того, при взаимодействии с Hadoop-сервисами Spark-приложению необходимо получить токены делегирования, чтобы нелокальные процессы могли пройти аутентификацию. При использовании файловой системы Hadoop (HDFS или WebHDFS) Spark получит соответствующие токены для службы, в которой размещается домашний каталог пользователя. Токен HBase будет получен, если HBase находится в пути к классам приложения, а в конфигурации HBase включена проверка подлинности Kerberos ( hbase.security.authentication=kerberos). Аналогично будет получен токен Hive, если Hive находится в пути к классам, а конфигурация включает URI для удаленных служб хранилища метаданных, т.е. определен параметр hive.metastore.uri. Если приложению необходимо взаимодействовать с другими защищенными файловыми системами Hadoop, их URI должны быть явно предоставлены Spark во время запуска. Это делается путем их перечисления в конфигурации spark.kerberos.access.hadoopFileSystems.Spark также поддерживает пользовательских поставщиков токенов делегирования с помощью механизма служб Java. Реализации org.apache.spark.security.HadoopDelegationTokenProviderможно сделать доступными для Spark, перечислив их имена в соответствующем JAR-файле метаданных в каталоге META-INF/services. Поддержка токена делегирования в настоящее время поддерживается только в режимах YARN и Mesos. Можно вручную исключить обновление токена делегирования Kerberos в планировщике ресурсов, который пока поддерживается только на YARN. Долго работающие приложения могут столкнуться с проблемами, если время их выполнения превышает максимальное время жизни токена делегирования, настроенное в службах, к которым ему необходимо получить доступ. Spark поддерживает автоматическое создание новых токенов для таких приложений в YARN и Kubernetes (в клиентском и кластерном режимах) и в Mesos при использовании клиентского режима. Эту функцию можно включить, используя таблицу ключей keytab, чтобы приложение поддерживало действительный вход в систему Kerberos, который можно использовать для получения токенов делегирования на неопределенный срок.При использовании таблицы ключей в кластерном режиме она будет скопирована на компьютер, на котором запущен драйвер Spark. В случае YARN это означает использование HDFS в качестве промежуточной области для keytab. Поэтому настоятельно рекомендуется, чтобы YARN и HDFS были защищены хотя бы шифрованием. Вместо этого также можно использовать кэш билетов, установив параметр spark.kerberos.renewal.credentials в значение ccache. При этом для аутентификации будет использоваться локальный кэш билетов Kerberos. Spark будет обновлять билет в течение срока его действия, но после истечения срока его действия необходимо будет приобрести новый билет с помощью уже упомянутой утилиты kinit. Пользователь должен поддерживать обновленный кэш билетов, который может использовать Spark. Расположение кэша билетов можно настроить, установив переменную среды KRB5CCNAME.При развертывании Spark-приложений в Kubernetes, токены делегирования для аутентификации нелокальных процессов хранятся в секретах, которые совместно используются драйвером Spark и его исполнителями. Чтобы отправить задание Kerberos, следует определить переменную окружения: HADOOP_CONF_DIR или spark.kubernetes.hadoop.configMapName и обеспечить видимость KDC внутри контейнеров. Если необходимо использовать удаленный каталог HADOOP_CONF, который содержит файлы конфигурации Hadoop, следует установить в конфигурации spark.kubernetes.hadoop.configMapName уже существующий ConfigMap.Тонкости аутентификацииВ настоящее время Apache Spark поддерживает аутентификацию для каналов RPC с использованием общего секрета. Аутентификацию можно включить, установив параметр конфигурации spark.authenticate. Точный механизм, используемый для создания и распространения общего секрета, зависит от развертывания. Обычно секрет определяется в конфигурации spark.authenticate.secret. Если один и тот же секрет используется всеми приложениями и системными службами (демонами) Spark, это ограничивает безопасность таких развертываний, особенно в многопользовательских кластерах. Сервер отправки REST и MesosClusterDispatcher не поддерживают аутентификацию. Поэтому следует убедиться, что весь сетевой доступ к REST API и MesosClusterDispatcher (порты 6066 и 7077 соответственно по умолчанию) ограничен хостами, которым доверено отправлять задания.При развертывании Spark-приложений под управлением YARN создание и распространение общего секрета выполняется автоматически: каждое приложение использует уникальный общий секрет. В случае YARN эта функция зависит от включенного шифрования YARN RPC для безопасного распределения секретов.В Kubernetes фреймворк также автоматически генерирует секрет аутентификации, уникальный для каждого приложения. Секрет распространяется на поды-исполнители с использованием переменных среды. Это означает, что любой пользователь, который может перечислить модули в пространстве имен, где запущено Spark-приложение, также может видеть свой секрет аутентификации. Администратор Kubernetes должен настроить правила контроля доступа, чтобы обеспечить безопасность аутентификации приложения. В качестве альтернативы можно монтировать секреты аутентификации, используя файлы и секреты Kubernetes, которые пользователь монтирует в свои поды. При использовании файлов фреймворк не будет монтировать эти файлы в контейнеры – разработчику придется сделать это самостоятельно. При этом следует убедиться, что секретные файлы безопасно развернуты в контейнерах и что секретный файл драйвера согласуется с секретным файлом исполнителей.Включение аутентификации для веб-интерфейсов осуществляется с помощью фильтров сервлетов javax. Необходим фильтр, который реализует нужный метод проверки подлинности. Изначально Spark не предоставляет встроенных фильтров для этого. Однако, фреймворк поддерживает управление доступом к пользовательскому интерфейсу при наличии фильтра проверки подлинности. Каждое приложение может быть настроено с собственными отдельными списками управления доступом (ACL) на просмотр пользовательского интерфейса приложения и изменение, включая уничтожение заданий в работающем приложении.ACL-списки можно настроить для пользователей и для групп, используя в качестве входных данных списки, разделенные запятыми, чтобы предоставить нужные привилегии сразу нескольким пользователям или группам. Это удобно при работе в общем кластере: знак *, добавленный к определенному ACL, означает, что все пользователи будут иметь соответствующую привилегию. По умолчанию в списки управления доступом добавляется только пользователь, подавший заявку. Членство в группе устанавливается с помощью настраиваемого поставщика сопоставления групп, который настраивается с помощью конфигурации spark.user.groups.mapping.В YARN просмотр и изменение ACL-списков предоставляются службе YARN при отправке приложений и контролируют, кто имеет соответствующие привилегии через интерфейсы YARN.Аутентификация для веб-интерфейса сервера истории включается так же, как и для обычных приложений, с использованием фильтров сервлетов. Сервер истории использует те же параметры для настройки поставщика сопоставления групп, что и обычные Spark-приложения. В этом случае провайдер сопоставления групп будет применяться сервером истории ко всем серверам пользовательских интерфейсов, а конфигурации отдельных приложений будут игнорироваться.Конфигурация SSL в Apache Spark организована иерархически. Пользователь может настроить параметры SSL по умолчанию, которые будут использоваться для всех поддерживаемых коммуникационных протоколов, если они не будут перезаписаны настройками, специфичными для протокола. Так можно указать общие настройки для всех протоколов, не отключая возможность настройки каждого из них по отдельности. Наконец, Apache Spark можно настроить для включения заголовков HTTP, чтобы предотвратить такие уязвимости как межсайтовый скриптинг (XSS), межфреймовый скриптинг (XFS), MIME-Sniffing, а также обеспечить строгую транспортную безопасность HTTP.Шифрование и логированиеApache Spark поддерживает шифрование на основе AES для подключений RPC. Шифрование AES использует библиотеку Apache Commons Crypto, доступ к которой настраивается в конфигурации Spark. Существует также поддержка шифрования на основе SASL, которое считается устаревшим, но по-прежнему используется в операциях перетасовки до Spark 2.2.0. Также Spark поддерживает шифрование временных данных, записываемых на локальные диски. Сюда относятся shuffle-файлы, spill-эффект и блоки данных, хранящиеся на диске для кэширования и широковещательных переменных. Выходные данные, созданные приложениями с помощью saveAsHadoopFile или saveAsTable, а также временные файлы, явно созданные пользователем, шифруются по-другому.Если Spark-приложения ведут журнал событий, то следует вручную создать spark.eventLog.dir - каталог, в который попадают журналы событий. Чтобы защитить файлы журналов, права доступа к каталогу должны быть установлены на drwxrwxrwxt. А владелец и группа каталога должны соответствовать суперпользователю, на котором работает сервер истории Spark. Это позволит всем пользователям записывать в каталог, но исключит возможность непривилегированным пользователям читать, удалять или переименовывать файл журнала, если он не принадлежит им. Файлы журнала событий будут созданы Spark с такими разрешениями, что только пользователь и группа имеют доступ для чтения и записи. Аналогичные действия следует выполнить для каталога, в который попадают журналы драйверов spark.driver.log.dfsDir, если приложения сохраняют журналы драйверов в клиентском режиме с включенной конфигурацией spark.driver.log.persistToDfs.enabled.Узнайте больше про использование Apache Spark для разработки приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:- Основы Apache Spark для разработчиков- Анализ данных с Apache Spark- Потоковая обработка в Apache Spark- Машинное обучение в Apache Spark- Графовые алгоритмы в Apache SparkИсточники1. https://spark.apache.org/docs/latest/security.html#spark-security-things-you-need-to-know2. https://bestprogrammer.ru/izuchenie/kerberos-za-5-minut-znakomstvo-s-setevoj-autentifikatsiej