#spark #тест @BigDataSchool_ru
Тест по фреймворку Spark.
Какие функции являются активационными для многослойного персептрона?
Тест по фреймворку Spark.
Какие функции являются активационными для многослойного персептрона?
Anonymous Quiz
29%
логистическая и линейная
0%
линейная и показательная
65%
логистическая и гиперболический тангенс
6%
показательная и логистическая
#spark #тест @BigDataSchool_ru
Тест по фреймворку Spark.
Какой метод отвечает за реализацию PageRank в Spark?
Тест по фреймворку Spark.
Какой метод отвечает за реализацию PageRank в Spark?
Anonymous Quiz
50%
pageRank()
0%
pages()
4%
pR()
46%
rank()
#spark #тест @BigDataSchool_ru
Тест по фреймворку Spark.
Какой класс отвечает за последовательность преобразований при обучении логистической ML-модели?
Тест по фреймворку Spark.
Какой класс отвечает за последовательность преобразований при обучении логистической ML-модели?
Anonymous Quiz
33%
Sequence
14%
SequenceLine
29%
PipeLine
24%
PipeSequence
#spark #тест @BigDataSchool_ru
Тест по основам Spark.
Какой класс отвечает за маркерную разметку?
Тест по основам Spark.
Какой класс отвечает за маркерную разметку?
Anonymous Quiz
32%
Marker
26%
MarkToken
32%
Tokenizer
11%
Token
#Spark #статьи
English SDK for Apache Spark и PySpark-AI: как это работает
Большие языковые модели (LLM, Large Language Model), основанные на генеративных нейросетях, применимы не только в чат-ботах и создании уникальных картинок.
Они также отлично комментируют программный код и даже могут написать скрипт по запросу пользователя. Впрочем, как показывает личный опыт, вероятность того, что это скрипт будет работать с первого раза без ошибок, пока еще мала: приходится исправлять и уточнять полученный от нейросети результат.
Однако, в целом ИИ-инструменты неплохо экономят время разработчика, подсказывая, в чем именно может быть причина ошибки или какую библиотеку следует использовать для решения конкретной задачи.
Примечательно, что это вполне по силам не только ИИ-продуктам, ориентированным на разработку, таким как Copilot от GitHub и OpenAI, но и нейросеткам общего назначения.
Англоязычный набор инструментов разработчика для Apache Spark (English SDK for Apache Spark) берет инструкции на английском языке и компилирует их в объекты PySpark, такие как DataFrames, чтобы реализовать следующие возможности:
✔️поиск в Интернете, используя предоставленное пользователем описание и включать выбранные веб-данные в код Spark-приложения;
✔️операции с DataFrame, включая преобразование, построение графиков и интерпретация на основе пользовательского англоязычного описания;
✔️пользовательские функции (UDF) – при использовании простого декоратора пользователю нужно предоставить строку документации, а LLM-модель сама завершит процесс создания UDF, позволяя разработчику сосредоточиться на определении функции;
✔️кэширование для повышения скорости выполнения запросов и получения воспроизводимых результатов. SparkAI хранит в памяти промежуточный кэш, который обновляется для LLM и результатов веб-поиска. Промежуточный кэш можно сохранить с помощью метода commit(). Поиск в кэше всегда выполняется как в промежуточном кэше в памяти, так и в постоянном кэше.
В работе English SDK используется PySpark-AI, Python-оболочка, которая использует модели генеративного языка для упрощения генерации кода PySpark.
Принимая инструкции на английском языке, он объединяет возможности Apache Spark с такими моделями, как GPT-4 и GPT-3.5. PySpark-AI принимает на вход англоязычные инструкции и выполняет их, позволяя пользователю сфокусироваться на обработке данных, а не на кодировании.
Далее разберем подробнее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/low-code-with-pyspark-ai-english-sdk-by-databricks.html
English SDK for Apache Spark и PySpark-AI: как это работает
Большие языковые модели (LLM, Large Language Model), основанные на генеративных нейросетях, применимы не только в чат-ботах и создании уникальных картинок.
Они также отлично комментируют программный код и даже могут написать скрипт по запросу пользователя. Впрочем, как показывает личный опыт, вероятность того, что это скрипт будет работать с первого раза без ошибок, пока еще мала: приходится исправлять и уточнять полученный от нейросети результат.
Однако, в целом ИИ-инструменты неплохо экономят время разработчика, подсказывая, в чем именно может быть причина ошибки или какую библиотеку следует использовать для решения конкретной задачи.
Примечательно, что это вполне по силам не только ИИ-продуктам, ориентированным на разработку, таким как Copilot от GitHub и OpenAI, но и нейросеткам общего назначения.
Англоязычный набор инструментов разработчика для Apache Spark (English SDK for Apache Spark) берет инструкции на английском языке и компилирует их в объекты PySpark, такие как DataFrames, чтобы реализовать следующие возможности:
✔️поиск в Интернете, используя предоставленное пользователем описание и включать выбранные веб-данные в код Spark-приложения;
✔️операции с DataFrame, включая преобразование, построение графиков и интерпретация на основе пользовательского англоязычного описания;
✔️пользовательские функции (UDF) – при использовании простого декоратора пользователю нужно предоставить строку документации, а LLM-модель сама завершит процесс создания UDF, позволяя разработчику сосредоточиться на определении функции;
✔️кэширование для повышения скорости выполнения запросов и получения воспроизводимых результатов. SparkAI хранит в памяти промежуточный кэш, который обновляется для LLM и результатов веб-поиска. Промежуточный кэш можно сохранить с помощью метода commit(). Поиск в кэше всегда выполняется как в промежуточном кэше в памяти, так и в постоянном кэше.
В работе English SDK используется PySpark-AI, Python-оболочка, которая использует модели генеративного языка для упрощения генерации кода PySpark.
Принимая инструкции на английском языке, он объединяет возможности Apache Spark с такими моделями, как GPT-4 и GPT-3.5. PySpark-AI принимает на вход англоязычные инструкции и выполняет их, позволяя пользователю сфокусироваться на обработке данных, а не на кодировании.
Далее разберем подробнее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/low-code-with-pyspark-ai-english-sdk-by-databricks.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Программируй на английском: ИИ-SDK для PySpark от Databricks
Как получать результаты обработки данных Apache Spark, адресуя ИИ бизнес-запросы на английском: PySpark-AI в English SDK от Databricks
#Airflow #spark #статьи
Spark Databrics vs Apache AirFlow: versus или вместе?
Впрочем, вопрос Spark Databrics vs Apache AirFlow можно рассматривать не как противопоставление этих технологий, а с точки зрения совместного использования.
Благодаря модульной структуре управления пакетами провайдеров, AirFlow отлично справляется с управлением рабочими процессами Databricks в контексте более крупного конвейера данных с использованием пакета провайдера Airflow Databricks. Этот пакет представляет собой набор классов Python, которые позволяют использовать AirFlow для управления заданиями Databricks.
Он предоставляет два оператора:
✔️DatabricksRunNowOperator для запуска существующего задания Databricks;
✔️DatabricksSubmitRunOperator для отправки нового задания в кластер Databricks.
Чтобы использовать пакет провайдера Databricks для AirFlow, необходимо создать соответствующее соединение Databricks в Airflow, указав учетные данные.
После создания подключения можно использовать операторы Databricks для запуска или отправки заданий в кластер.
Такой комбинированный подход позволяет извлечь выгоду из сильных сторон обеих платформ, создавая более мощное решение для оркестрации и обработки данных, чем каждая технология по отдельности.
Вместе они заполняют пробелы друг друга: AirFlow может запускать, планировать и отслеживать задания Databricks, гарантируя, что они выполняются в правильной последовательности и с обработкой любых сбоев. А Databricks может эффективно обрабатывать огромные объемы данных и выполнять их расширенную аналитику.
Таким образом, сочетание технологий обеспечивает бесперебойный сквозной конвейер данных, от приема и преобразования до аналитики и отчетности, с надежностью оркестрации AirFlow и мощью аналитического механизма Databricks.
@BigDataSchool_ru
https://bigdataschool.ru/blog/apache-airflow-vs-spark-databricks.html
Spark Databrics vs Apache AirFlow: versus или вместе?
Впрочем, вопрос Spark Databrics vs Apache AirFlow можно рассматривать не как противопоставление этих технологий, а с точки зрения совместного использования.
Благодаря модульной структуре управления пакетами провайдеров, AirFlow отлично справляется с управлением рабочими процессами Databricks в контексте более крупного конвейера данных с использованием пакета провайдера Airflow Databricks. Этот пакет представляет собой набор классов Python, которые позволяют использовать AirFlow для управления заданиями Databricks.
Он предоставляет два оператора:
✔️DatabricksRunNowOperator для запуска существующего задания Databricks;
✔️DatabricksSubmitRunOperator для отправки нового задания в кластер Databricks.
Чтобы использовать пакет провайдера Databricks для AirFlow, необходимо создать соответствующее соединение Databricks в Airflow, указав учетные данные.
После создания подключения можно использовать операторы Databricks для запуска или отправки заданий в кластер.
Такой комбинированный подход позволяет извлечь выгоду из сильных сторон обеих платформ, создавая более мощное решение для оркестрации и обработки данных, чем каждая технология по отдельности.
Вместе они заполняют пробелы друг друга: AirFlow может запускать, планировать и отслеживать задания Databricks, гарантируя, что они выполняются в правильной последовательности и с обработкой любых сбоев. А Databricks может эффективно обрабатывать огромные объемы данных и выполнять их расширенную аналитику.
Таким образом, сочетание технологий обеспечивает бесперебойный сквозной конвейер данных, от приема и преобразования до аналитики и отчетности, с надежностью оркестрации AirFlow и мощью аналитического механизма Databricks.
@BigDataSchool_ru
https://bigdataschool.ru/blog/apache-airflow-vs-spark-databricks.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Apache AirFlow vs Spark в Databricks для оркестрации рабочих процессов
Чем отличается оркестрация ETL-процессов в Databricks и Apache AirFlow: принципы работы, достоинства
#spark #статьи
Что такое SPIP и как подать свое предложение по улучшению фреймворка
В любом продукте помимо ошибок есть также предложения по улучшению.
В Apache Spark они называются SPIP — Spark Improvements Proposals. SPIP используется для значительных изменений, ориентированных на пользователя, или для сквозных изменений, а не для небольших постепенных улучшений.
По своей сути SPIP аналогичен требованиям к продукту, однако причиной его регистрации является не острая потребность, а гипотеза, что реализация этой фичи позволит улучшить пользовательский опыт.
Поскольку Apache Spark является проектом с открытым исходным кодом, активно развиваемым сообществом, предложить SPIP может любой пользователь, от разработчика до аналитика данных, главное – обосновать актуальность и выполнимость предлагаемого изменения, ответив на следующие вопросы:
1️⃣Что вы предлагаете? Здесь следует кратко, но точно и понятно сформулировать цели изменения в общепринятых терминах без жаргонизмов
2️⃣Какую проблему НЕ решает предложение? Ответ на этот вопрос позволит четче очертить границы и содержание SPIP.
3️⃣Как рассматриваемая проблема решается сегодня и каковы ограничения нынешней практики?
4️⃣Что нового в предложении и почему оно будет успешным?
5️⃣Каков эффект от реализации предложения?
6️⃣Каковы риски?
7️⃣Как много времени это займет?
8️⃣Каковы промежуточные и итоговые критерии проверки успешности реализации предложения?
Детально тему рассмотрим на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-spip-spark-improvements-proposals-in-2023.html
Что такое SPIP и как подать свое предложение по улучшению фреймворка
В любом продукте помимо ошибок есть также предложения по улучшению.
В Apache Spark они называются SPIP — Spark Improvements Proposals. SPIP используется для значительных изменений, ориентированных на пользователя, или для сквозных изменений, а не для небольших постепенных улучшений.
По своей сути SPIP аналогичен требованиям к продукту, однако причиной его регистрации является не острая потребность, а гипотеза, что реализация этой фичи позволит улучшить пользовательский опыт.
Поскольку Apache Spark является проектом с открытым исходным кодом, активно развиваемым сообществом, предложить SPIP может любой пользователь, от разработчика до аналитика данных, главное – обосновать актуальность и выполнимость предлагаемого изменения, ответив на следующие вопросы:
1️⃣Что вы предлагаете? Здесь следует кратко, но точно и понятно сформулировать цели изменения в общепринятых терминах без жаргонизмов
2️⃣Какую проблему НЕ решает предложение? Ответ на этот вопрос позволит четче очертить границы и содержание SPIP.
3️⃣Как рассматриваемая проблема решается сегодня и каковы ограничения нынешней практики?
4️⃣Что нового в предложении и почему оно будет успешным?
5️⃣Каков эффект от реализации предложения?
6️⃣Каковы риски?
7️⃣Как много времени это займет?
8️⃣Каковы промежуточные и итоговые критерии проверки успешности реализации предложения?
Детально тему рассмотрим на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-spip-spark-improvements-proposals-in-2023.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Что такое SPIP: 4 предложения по улучшению Apache Spark
Сегодня рассмотрим, какие улучшения Apache Spark опубликованы в 2023 году и как подать свое пре
#spark #статьи
4 недавних предложения улучшить Spark SQL
✳️Например, 30 августа 2023 года предложено добавить в PySpark возможность работать с хранимыми процедурами, которые расширяют стандартный ANSI SQL, позволяя многократно выполнять сложную логику обработки данных.
Это предложение направлено на расширение Spark SQL путем введения поддержки хранимых процедур, начиная с Python в качестве процедурного языка.
Также пользователи смогут сохранять эти процедуры в каталогах, например, Hive Metastore, для повторного использования в будущем.
✳️Еще одним полезным предложением в августе 2023 года стала идея повысить производительность запросов широковещательного хэш-соединения (BroadcastHashJoin) с помощью ключа соединения на стороне потока для столбцов без разделов. Поскольку ключи BroadcastHashJoin уже доступны до фактической оценки итератора потока, их можно передать в источник данных как SortedSet.
Для столбцов без разделов источники данных, такие как Iceberg, уже имеют максимальную/минимальную статистику для столбца, доступную на уровне манифеста, а для таких форматов, как Parquet, эта статистика есть различных уровнях хранения.
Переданный SortedSet можно использовать для сокращения использования диапазонов как на уровне драйвера (файлы манифестов), так и на уровне исполнителя при фактическом прохождении групп строк и пр.
Если данные хранятся в формате Columnar Batch, отфильтровать отдельные строки на уровне DataSource невозможно, даже при наличии ключей. Однако, на уровне сканирования (ColumnToRowExec) отфильтровать как можно больше строк все же возможно, если запрос включает вложенные соединения. Таким образом, можно сократить количество строк для соединения на более высоких уровнях, что ускорит выполнение многоуровневых вложенных запросов с оператором BroadcastHashJoin.
✳️С PySpark связано еще одно предложение по улучшению, поданное в июне 2023 года. Автор рекомендует создать Python API для источников данных, чтобы разработчики, использующие этот популярный язык программирования, могли создавать собственные источники данных.
✳️Также в июне этого же года подано предложение по реализации платформы тестирования PySpark-приложений, чтобы оптимизировать и упростить этот процесс с помощью базового PySpark-класса Test Base и специальных тестовых функций. Это позволит тестам совместно использовать сеансы Spark и автоматизировать проверку кода.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-spip-spark-improvements-proposals-in-2023.html
4 недавних предложения улучшить Spark SQL
✳️Например, 30 августа 2023 года предложено добавить в PySpark возможность работать с хранимыми процедурами, которые расширяют стандартный ANSI SQL, позволяя многократно выполнять сложную логику обработки данных.
Это предложение направлено на расширение Spark SQL путем введения поддержки хранимых процедур, начиная с Python в качестве процедурного языка.
Также пользователи смогут сохранять эти процедуры в каталогах, например, Hive Metastore, для повторного использования в будущем.
✳️Еще одним полезным предложением в августе 2023 года стала идея повысить производительность запросов широковещательного хэш-соединения (BroadcastHashJoin) с помощью ключа соединения на стороне потока для столбцов без разделов. Поскольку ключи BroadcastHashJoin уже доступны до фактической оценки итератора потока, их можно передать в источник данных как SortedSet.
Для столбцов без разделов источники данных, такие как Iceberg, уже имеют максимальную/минимальную статистику для столбца, доступную на уровне манифеста, а для таких форматов, как Parquet, эта статистика есть различных уровнях хранения.
Переданный SortedSet можно использовать для сокращения использования диапазонов как на уровне драйвера (файлы манифестов), так и на уровне исполнителя при фактическом прохождении групп строк и пр.
Если данные хранятся в формате Columnar Batch, отфильтровать отдельные строки на уровне DataSource невозможно, даже при наличии ключей. Однако, на уровне сканирования (ColumnToRowExec) отфильтровать как можно больше строк все же возможно, если запрос включает вложенные соединения. Таким образом, можно сократить количество строк для соединения на более высоких уровнях, что ускорит выполнение многоуровневых вложенных запросов с оператором BroadcastHashJoin.
✳️С PySpark связано еще одно предложение по улучшению, поданное в июне 2023 года. Автор рекомендует создать Python API для источников данных, чтобы разработчики, использующие этот популярный язык программирования, могли создавать собственные источники данных.
✳️Также в июне этого же года подано предложение по реализации платформы тестирования PySpark-приложений, чтобы оптимизировать и упростить этот процесс с помощью базового PySpark-класса Test Base и специальных тестовых функций. Это позволит тестам совместно использовать сеансы Spark и автоматизировать проверку кода.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-spip-spark-improvements-proposals-in-2023.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Что такое SPIP: 4 предложения по улучшению Apache Spark
Сегодня рассмотрим, какие улучшения Apache Spark опубликованы в 2023 году и как подать свое пре
#spark #статьи
Что такое checkpoint в Apache Spark и зачем он нужен
Чтобы приложение потоковой передачи было устойчиво к сбоям по внешним причинам, например, отказ JVM, Spark Streaming сохраняет промежуточные данные в отказоустойчивой системе хранения, чтобы использовать их для восстановления приложения, т.е. перезапуска драйвера. Для этого фреймворк использует механизм контрольных точек (checkpoint), который сохраняет состояние приложения в надежном хранилище, например, в распределенной файловой системе Hadoop (HDFS).
Контрольные точки – это механизм Spark Core, ядра фреймворка, которое используется для распределенных вычислений. Он позволяет перезапустить драйвер в случае сбоя с ранее вычисленным состоянием распределенных вычислений, описанным как файл RDD. Этот подход применялся в Spark Streaming — устаревшем модуле Spark для потоковой обработки на основе RDD API. Установление контрольных точек усекает происхождение RDD, подлежащего проверке, что использует Spark MLlib в итеративных алгоритмах машинного обучения, таких как ALS.
Таким образом, контрольные точки можно использовать для усечения логического плана датафрейма в итерационных алгоритмах, где план выполнения запроса растет экспоненциально. Через создание контрольной точки план разбивается на участки и сохраняется в файлах внутри каталога, установленного с помощью SparkContext.setCheckpointDir(). Контрольная точка набора данных в Spark SQL использует контрольную точку для усечения происхождения базового RDD для рассматриваемого Dataset или датафрейма.
Различают 2 вида контрольных точек в Spark:
✔️контрольная точка метаданных
✔️контрольная точка данных
Таким образом, локальная установка контрольных точек использует хранилище исполнителя для записи файлов контрольных точек, поэтому жизненный цикл исполнителя считается ненадежным. Надежная контрольная точка использует надежное хранилище данных (HDFS).
Таким образом, контрольные точки метаданных необходимы для восстановления после сбоев драйверов, а контрольные точки данных нужны для stateful-приложений, где выполняются преобразования с сохранением состояния.
Помимо этой классификации по объектам сохранения, контрольные точки также можно разделить по степени надежности каталога контрольных точек:
✔️Надежная контрольная точка, когда фактический RDD сохраняется в надежной распределенной файловой системе в каталоге, установленном с помощью метода setCheckpointDir(directory: String).
✔️Локальная контрольная точка, когда усеченный (неполный) граф происхождения RDD сохраняется в локальном хранилище исполнителя.
Однако, в этом случае восстановление после сбоев драйверов будет частичным, поскольку некоторые полученные, но необработанные данные могут быть утеряны. Впрочем, для многих сценариев это приемлемо.
Поскольку контрольная точка сохраняет данные на диске, усекая план выполнения запроса, ее можно применять для увеличения скорости его выполнения. Когда план запроса становится огромным, производительность резко снижается, поэтому можно добавить контрольные точки в некоторых стратегических точках конвейера данных. Например, при выполнении JOIN-операций: HashAggregate, ShuffleHashJoin, BroadcastHashJoin и SortMergeJoin.
Контрольная точка может быть активной или отложенной в зависимости от флага оператора eager. По умолчанию контрольная точка является активной и выполняется немедленно по запросу. Отложенная контрольная точка выполняется только при вызове действия.
Для использования контрольных точек необходимо указать ее каталог с помощью команды SparkContext.setCheckpointDir.
@BigDataSchool_ru
https://bigdataschool.ru/blog/checkpoints-in-spark-streaming.html
Что такое checkpoint в Apache Spark и зачем он нужен
Чтобы приложение потоковой передачи было устойчиво к сбоям по внешним причинам, например, отказ JVM, Spark Streaming сохраняет промежуточные данные в отказоустойчивой системе хранения, чтобы использовать их для восстановления приложения, т.е. перезапуска драйвера. Для этого фреймворк использует механизм контрольных точек (checkpoint), который сохраняет состояние приложения в надежном хранилище, например, в распределенной файловой системе Hadoop (HDFS).
Контрольные точки – это механизм Spark Core, ядра фреймворка, которое используется для распределенных вычислений. Он позволяет перезапустить драйвер в случае сбоя с ранее вычисленным состоянием распределенных вычислений, описанным как файл RDD. Этот подход применялся в Spark Streaming — устаревшем модуле Spark для потоковой обработки на основе RDD API. Установление контрольных точек усекает происхождение RDD, подлежащего проверке, что использует Spark MLlib в итеративных алгоритмах машинного обучения, таких как ALS.
Таким образом, контрольные точки можно использовать для усечения логического плана датафрейма в итерационных алгоритмах, где план выполнения запроса растет экспоненциально. Через создание контрольной точки план разбивается на участки и сохраняется в файлах внутри каталога, установленного с помощью SparkContext.setCheckpointDir(). Контрольная точка набора данных в Spark SQL использует контрольную точку для усечения происхождения базового RDD для рассматриваемого Dataset или датафрейма.
Различают 2 вида контрольных точек в Spark:
✔️контрольная точка метаданных
✔️контрольная точка данных
Таким образом, локальная установка контрольных точек использует хранилище исполнителя для записи файлов контрольных точек, поэтому жизненный цикл исполнителя считается ненадежным. Надежная контрольная точка использует надежное хранилище данных (HDFS).
Таким образом, контрольные точки метаданных необходимы для восстановления после сбоев драйверов, а контрольные точки данных нужны для stateful-приложений, где выполняются преобразования с сохранением состояния.
Помимо этой классификации по объектам сохранения, контрольные точки также можно разделить по степени надежности каталога контрольных точек:
✔️Надежная контрольная точка, когда фактический RDD сохраняется в надежной распределенной файловой системе в каталоге, установленном с помощью метода setCheckpointDir(directory: String).
✔️Локальная контрольная точка, когда усеченный (неполный) граф происхождения RDD сохраняется в локальном хранилище исполнителя.
Однако, в этом случае восстановление после сбоев драйверов будет частичным, поскольку некоторые полученные, но необработанные данные могут быть утеряны. Впрочем, для многих сценариев это приемлемо.
Поскольку контрольная точка сохраняет данные на диске, усекая план выполнения запроса, ее можно применять для увеличения скорости его выполнения. Когда план запроса становится огромным, производительность резко снижается, поэтому можно добавить контрольные точки в некоторых стратегических точках конвейера данных. Например, при выполнении JOIN-операций: HashAggregate, ShuffleHashJoin, BroadcastHashJoin и SortMergeJoin.
Контрольная точка может быть активной или отложенной в зависимости от флага оператора eager. По умолчанию контрольная точка является активной и выполняется немедленно по запросу. Отложенная контрольная точка выполняется только при вызове действия.
Для использования контрольных точек необходимо указать ее каталог с помощью команды SparkContext.setCheckpointDir.
@BigDataSchool_ru
https://bigdataschool.ru/blog/checkpoints-in-spark-streaming.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Контрольные точки в Apache Spark Streaming
Чтобы обеспечить отказоустойчивость потоковых приложений, Apache Spark использует механизм
#spark #статьи
Логирование системных метрик в приложении Apache Spark
Поскольку фреймворк Apache Spark изначально предназначен для создания высоконагруженных распределенных приложений пакетной и потоковой обработки больших объемов данных, он позволяет отслеживать системные события, предоставляя инструменты мониторинга.
Есть несколько способов мониторинга Spark-приложений: веб-интерфейсы, метрики и внешние инструменты.
Однако, использование этого графического интерфейса ограничено жизненным циклом самого Spark-приложения. По умолчанию информация о списке этапов и задачах планировщика, размерах RDD и использовании памяти, а также действующих исполнителях, доступна только во время работы приложения. Чтобы просмотреть веб-интерфейс постфактум, надо установить конфигурации spark.eventLog.enabled значение true перед запуском приложения. Это настроит фреймворк на регистрацию событий приложения в постоянное хранилище.
Также для просмотра ранее накопленных метрик можно обратиться к серверу истории, который позволяет просмотреть логи приложения после его завершения, отображая информацию о конфигурации фреймворка, заданиях, этапах, исполнителях и задачах, потоках выполнения DAG, потреблении ресурсов драйвера и исполнителя.
Долго работающие приложения Structured Streaming создают много событий в системных логах. Это приводит к увеличению размера лог-файла журнала событий, что требует большого количества ресурсов для воспроизведения каждого обновления на сервере истории. Также крупные задания, такие как сложные аналитические SQL-запросы, могут создавать большие журналы событий, которые занимают много дискового пространства и даже могут привести к ошибке нехватки памяти (OOM, OutOfMemory) при загрузке пользовательских интерфейсов.
Избежать этого поможет скользящее сжатие логов, о котором мы поговорим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/how-to-compact-spark-event-log-files.html
Логирование системных метрик в приложении Apache Spark
Поскольку фреймворк Apache Spark изначально предназначен для создания высоконагруженных распределенных приложений пакетной и потоковой обработки больших объемов данных, он позволяет отслеживать системные события, предоставляя инструменты мониторинга.
Есть несколько способов мониторинга Spark-приложений: веб-интерфейсы, метрики и внешние инструменты.
Однако, использование этого графического интерфейса ограничено жизненным циклом самого Spark-приложения. По умолчанию информация о списке этапов и задачах планировщика, размерах RDD и использовании памяти, а также действующих исполнителях, доступна только во время работы приложения. Чтобы просмотреть веб-интерфейс постфактум, надо установить конфигурации spark.eventLog.enabled значение true перед запуском приложения. Это настроит фреймворк на регистрацию событий приложения в постоянное хранилище.
Также для просмотра ранее накопленных метрик можно обратиться к серверу истории, который позволяет просмотреть логи приложения после его завершения, отображая информацию о конфигурации фреймворка, заданиях, этапах, исполнителях и задачах, потоках выполнения DAG, потреблении ресурсов драйвера и исполнителя.
Долго работающие приложения Structured Streaming создают много событий в системных логах. Это приводит к увеличению размера лог-файла журнала событий, что требует большого количества ресурсов для воспроизведения каждого обновления на сервере истории. Также крупные задания, такие как сложные аналитические SQL-запросы, могут создавать большие журналы событий, которые занимают много дискового пространства и даже могут привести к ошибке нехватки памяти (OOM, OutOfMemory) при загрузке пользовательских интерфейсов.
Избежать этого поможет скользящее сжатие логов, о котором мы поговорим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/how-to-compact-spark-event-log-files.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Журналирование событий в Apache Spark и сжатие лог-файлов
Когда журналирование событий может привести к OOM-ошибке, где отслеживать системные метрики Spark-приложения, зачем и как сжимать лог-файлы
#spark #статьи
Как настроить сжатие логов
Скользящее сжатие логов настраивается в файле spark-defaults.conf для следующих конфигураций:
✔️eventLog.rolling.enabled – чередование журнала событий в зависимости от размера лог-файла. Это означает регистрацию событий в новый лог-файл, когда текущий достиг максимального значения. По умолчанию этот параметр отключен);
✔️eventLog.rolling.maxFileSize – максимальный размер файла журнала событий до ее смены. По умолчанию этот параметр равен 128 МБ, а минимально возможный предел равен 10 МБ.
Также в файле конфигурации сервера истории spark-history-server.conf можно настроить параметр конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain, который указывает максимальное количество сохраняемых несжатых файлов журнала событий. По умолчанию все файлы журнала событий сохраняются. По умолчанию значение spark.history.fs.eventLog.rolling.maxFilesToRetain будет равно бесконечности, что означает, что все файлы журнала событий сохраняются. Установка меньшего значения приводит к сжатию старых лог-файлов. Минимально возможное значение этой конфигурации равно 1, т.е. только в несжатом состоянии будет только текущий лог-файл, куда ведется регистрация событий.
Настройка этих конфигураций позволит иметь несколько лог-файлов меньшего размера вместо одного огромного. Однако, общий размер всех журналов останется прежним. Кроме того, следует помнить, что обратной стороной преимущества сжатия является потеря качества данных.
В частности, при сжатии логов некоторые события не будут отображаться в пользовательском интерфейсе. Когда происходит сжатие, сервер истории перечисляет все доступные файлы журнала событий для приложения и рассматривает лог-файлы с индексом меньше, чем у того, который сохранен в качестве объекта сжатия.
Например, если Spark-приложение имеет 5 лог-файлов и конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain задано значение 2, то для сжатия будут выбраны первые 3 лог-файла.
После выбора целей для сжатия фреймворк анализирует их, чтобы выяснить, какие события можно исключить, и переписывает эти урезанные логи в один компактный файл, отбрасывая некоторые события. Обычно при сжатии исключаются события, указывающие на устаревшие данные.
Например, события для завершенного задания и связанные с ним события этапа или задачи, а также события для исполнителя, который завершается, события для завершенного выполнения SQL-запросов и связанные с ними события задания/этапа/задачи.
После завершения перезаписи исходные лог-файлы обычно удаляются. Сервер истории может не сжимать старые файлы журнала событий, если выясняется, сжатие не экономит достаточно много места. Как правило, сжатие эффективно для потоковой обработки, поскольку каждый микропакет запускает одно или несколько заданий, которые вскоре завершаются. Для пакетных запросов сжатие не дает большого эффекта, а потому применять его не рекомендуется.
Поскольку сжатие лог-файлов добавлено во фреймворк начиная с версии 3.0, эта функция пока еще не очень стабильна. Иногда сжатие может исключить больше событий, что приведет к излишне лаконичному отображению информации в пользовательском интерфейсе на сервере истории Spark.
Поэтому включать сжатие лог-файлов следует с осторожностью.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/how-to-compact-spark-event-log-files.html
Как настроить сжатие логов
Скользящее сжатие логов настраивается в файле spark-defaults.conf для следующих конфигураций:
✔️eventLog.rolling.enabled – чередование журнала событий в зависимости от размера лог-файла. Это означает регистрацию событий в новый лог-файл, когда текущий достиг максимального значения. По умолчанию этот параметр отключен);
✔️eventLog.rolling.maxFileSize – максимальный размер файла журнала событий до ее смены. По умолчанию этот параметр равен 128 МБ, а минимально возможный предел равен 10 МБ.
Также в файле конфигурации сервера истории spark-history-server.conf можно настроить параметр конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain, который указывает максимальное количество сохраняемых несжатых файлов журнала событий. По умолчанию все файлы журнала событий сохраняются. По умолчанию значение spark.history.fs.eventLog.rolling.maxFilesToRetain будет равно бесконечности, что означает, что все файлы журнала событий сохраняются. Установка меньшего значения приводит к сжатию старых лог-файлов. Минимально возможное значение этой конфигурации равно 1, т.е. только в несжатом состоянии будет только текущий лог-файл, куда ведется регистрация событий.
Настройка этих конфигураций позволит иметь несколько лог-файлов меньшего размера вместо одного огромного. Однако, общий размер всех журналов останется прежним. Кроме того, следует помнить, что обратной стороной преимущества сжатия является потеря качества данных.
В частности, при сжатии логов некоторые события не будут отображаться в пользовательском интерфейсе. Когда происходит сжатие, сервер истории перечисляет все доступные файлы журнала событий для приложения и рассматривает лог-файлы с индексом меньше, чем у того, который сохранен в качестве объекта сжатия.
Например, если Spark-приложение имеет 5 лог-файлов и конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain задано значение 2, то для сжатия будут выбраны первые 3 лог-файла.
После выбора целей для сжатия фреймворк анализирует их, чтобы выяснить, какие события можно исключить, и переписывает эти урезанные логи в один компактный файл, отбрасывая некоторые события. Обычно при сжатии исключаются события, указывающие на устаревшие данные.
Например, события для завершенного задания и связанные с ним события этапа или задачи, а также события для исполнителя, который завершается, события для завершенного выполнения SQL-запросов и связанные с ними события задания/этапа/задачи.
После завершения перезаписи исходные лог-файлы обычно удаляются. Сервер истории может не сжимать старые файлы журнала событий, если выясняется, сжатие не экономит достаточно много места. Как правило, сжатие эффективно для потоковой обработки, поскольку каждый микропакет запускает одно или несколько заданий, которые вскоре завершаются. Для пакетных запросов сжатие не дает большого эффекта, а потому применять его не рекомендуется.
Поскольку сжатие лог-файлов добавлено во фреймворк начиная с версии 3.0, эта функция пока еще не очень стабильна. Иногда сжатие может исключить больше событий, что приведет к излишне лаконичному отображению информации в пользовательском интерфейсе на сервере истории Spark.
Поэтому включать сжатие лог-файлов следует с осторожностью.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/how-to-compact-spark-event-log-files.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Журналирование событий в Apache Spark и сжатие лог-файлов
Когда журналирование событий может привести к OOM-ошибке, где отслеживать системные метрики Spark-приложения, зачем и как сжимать лог-файлы
#spark @BigDataSchool_ru
Тест по Spark
Какой метод отвечает за соединение Spark и реляционной СУБД?
Тест по Spark
Какой метод отвечает за соединение Spark и реляционной СУБД?
Anonymous Quiz
8%
retrieveConnection()
19%
getConnection()
32%
connect()
41%
jdbc()
#spark @BigDataSchool_ru
Тест по Spark
Какой класс отвечает за создание графовой структуры в Spark GraphX?
Тест по Spark
Какой класс отвечает за создание графовой структуры в Spark GraphX?
Anonymous Quiz
0%
FrameGraph
55%
GraphXFrame
26%
GraphFrame
19%
Graph
#spark #статьи
Где stateful-операторы Spark Structured Streaming хранят состояния?
Хотя Apache Spark Structured Streaming реализует потоковую парадигму обработки информации, он по-прежнему использует микропакеты, т.е. ограниченные наборы данных, с которыми выполняется операция.
Например, рассмотрим типовую задачу анализа данных в некотором временном окне, например, определить скользящее среднее количество запросов, поступивших из разных городов в течение 5 минут. Чтобы получить результат, необходимо знать не только данные в текущем микропакете, но и в предыдущих. Такие операции с данными называются stateful, а сами обрабатываемые при этом данные называются состоянием, которое необходимо сохранить.
В Spark Structured Streaming состояния хранятся в хранилищах состояний исполнителей, потребляя их ресурсы: память и дисковое пространство.
В Apache Spark есть две встроенные реализации провайдера хранилища состояний:
✔️распределенная файловая система Hadoop (HDFS), используемая по умолчанию. Здесь все данные на первом этапе MapReduce-вычислений сохраняются в памяти, а затем в файлах в файловой системе, совместимой с HDFS. В реализации HDFSBackedStateStore данные о состоянии хранятся в памяти JVM исполнителей, а большое количество объектов состояния создает нагрузку на память JVM, вызывая большие паузы в работе сборщика мусора (Garbage Collector).
✔️RocksDB – реализация на основе key-value БД, добавленная в Apache Spark с версии 3.2. Она позволяет избежать проблем с JVM при множестве ключей для stateful-операций, когда сборка мусора приостанавливается, вызывая большие различия во времени микропакетной обработки. Вместо хранения состояния в памяти JVM используется NoSQL-хранилище RocksDB для эффективного управления состоянием в собственной памяти и на локальном диске. При этом любые изменения этого состояния автоматически сохраняются структурированной потоковой передачей в указанное местоположение контрольной точки, обеспечивая полные гарантии отказоустойчивости.
Именно RocksDB рекомендуется использовать в качестве хранилища состояний для производственных рабочих нагрузок, поскольку со временем размер состояния обычно увеличивается и превышает миллионы ключей. Использование RocksDB позволяет избежать проблем с памятью, связанных с кучей JVM, или замедления работы из-за сборки мусора, что характерно для HDFS.
Как показали бенчмаркинговые тесты, проведенные дата-инженерами компании Databricks, stateful-операции, сохраняющие состояние в RocksDB, выполняются в несколько раз быстрее по сравнению с использованием HDFS.
Такая скорость достигается за счет адаптации внутренних механизмов RocksDB к особенностям Spark Structured Streaming, что мы рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/rocksdb-as-state-backend-in-spark-structured-streaming.html
Где stateful-операторы Spark Structured Streaming хранят состояния?
Хотя Apache Spark Structured Streaming реализует потоковую парадигму обработки информации, он по-прежнему использует микропакеты, т.е. ограниченные наборы данных, с которыми выполняется операция.
Например, рассмотрим типовую задачу анализа данных в некотором временном окне, например, определить скользящее среднее количество запросов, поступивших из разных городов в течение 5 минут. Чтобы получить результат, необходимо знать не только данные в текущем микропакете, но и в предыдущих. Такие операции с данными называются stateful, а сами обрабатываемые при этом данные называются состоянием, которое необходимо сохранить.
В Spark Structured Streaming состояния хранятся в хранилищах состояний исполнителей, потребляя их ресурсы: память и дисковое пространство.
В Apache Spark есть две встроенные реализации провайдера хранилища состояний:
✔️распределенная файловая система Hadoop (HDFS), используемая по умолчанию. Здесь все данные на первом этапе MapReduce-вычислений сохраняются в памяти, а затем в файлах в файловой системе, совместимой с HDFS. В реализации HDFSBackedStateStore данные о состоянии хранятся в памяти JVM исполнителей, а большое количество объектов состояния создает нагрузку на память JVM, вызывая большие паузы в работе сборщика мусора (Garbage Collector).
✔️RocksDB – реализация на основе key-value БД, добавленная в Apache Spark с версии 3.2. Она позволяет избежать проблем с JVM при множестве ключей для stateful-операций, когда сборка мусора приостанавливается, вызывая большие различия во времени микропакетной обработки. Вместо хранения состояния в памяти JVM используется NoSQL-хранилище RocksDB для эффективного управления состоянием в собственной памяти и на локальном диске. При этом любые изменения этого состояния автоматически сохраняются структурированной потоковой передачей в указанное местоположение контрольной точки, обеспечивая полные гарантии отказоустойчивости.
Именно RocksDB рекомендуется использовать в качестве хранилища состояний для производственных рабочих нагрузок, поскольку со временем размер состояния обычно увеличивается и превышает миллионы ключей. Использование RocksDB позволяет избежать проблем с памятью, связанных с кучей JVM, или замедления работы из-за сборки мусора, что характерно для HDFS.
Как показали бенчмаркинговые тесты, проведенные дата-инженерами компании Databricks, stateful-операции, сохраняющие состояние в RocksDB, выполняются в несколько раз быстрее по сравнению с использованием HDFS.
Такая скорость достигается за счет адаптации внутренних механизмов RocksDB к особенностям Spark Structured Streaming, что мы рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/rocksdb-as-state-backend-in-spark-structured-streaming.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
RocksDB как хранилище состояний для Apache Spark Structured Streaming
Где stateful-операторы хранят состояния, почему RocksDB лучше HDFSBackedStateStore и как Databricks адаптиров
#spark @BigDataSchool_ru
Тест по Spark
Что отвечает за соединение Spark и реляционной СУБД?
Тест по Spark
Что отвечает за соединение Spark и реляционной СУБД?
Anonymous Quiz
11%
исполнитель Spark
43%
RDBMS-драйвер
38%
Spark-драйвер
9%
ядро Spark
#spark #статьи
Что такое assert: конструкция тестирования
При разработке PySpark-приложения дата-инженер чаще всего оперирует такими структурами данных, как датафрейм.
Датафрейм (DataFrame) – это распределенная таблица, коллекция данных, сгруппированная в именованные столбцы аналогично реляционной таблице в Spark SQL. Обычно работа с данными в PySpark включает в себя применение преобразований, агрегаций и манипуляций к датафреймам. Чтобы протестировать полученный код в Apache Spark 3.5 были добавлены утилиты проверки равенства датафреймов. Они позволяют сверить данные с ожидаемыми результатами, помогая выявить неожиданные различия и ошибки на ранних этапах процесса анализа.
На текущий момент в PySpark есть следующие функции, которые можно использовать для тестирования написанного кода распределенного приложения:
✔️assertDataFrameEqual(actual, expected[, …]) – утилита для подтверждения равенства между фактическим и ожидаемым датафреймом или списками строк с дополнительными параметрами checkRowOrder, rtol и atol;
✔️assertSchemaEqual(actual, expected) – утилита для подтверждения равенства между фактической и ожидаемой схемами датафрейма;
✔️assertPandasOnSparkEqual(actual, expected[, …]) – утилитная функция для подтверждения равенства между фактическим объектом pandas-on-Spark и ожидаемым объектом pandas-on-Spark или pandas. О разнице между классическим API pandas и его реализации в PySpark мы ранее писали здесь и здесь.
Все эти функции основаны на понятии assert – конструкции, которая позволяет проверять предположения о значениях произвольных данных в произвольном месте программы, подавая сигнал об обнаружении некорректных данных, что может привести к сбою.
Assert завершает программу сразу же после обнаружения некорректных данных, давая разработчику возможность быстро определить ошибки и исправить их. Assert может отловить ошибки в коде на этапе компиляции или во время исполнения. Проверки на этапе компиляции можно заменить аналогичными синтаксическими конструкциями во время исполнения программы, например, try-except-finally.
В большинстве языков программирования позволяют отключить assert на этапе компиляции или во время выполнения программы, поэтому влияние этих конструкций на производительность итогового продукта незначительно.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/pyspark-dataframe-testing-with-assert-functions.html
Что такое assert: конструкция тестирования
При разработке PySpark-приложения дата-инженер чаще всего оперирует такими структурами данных, как датафрейм.
Датафрейм (DataFrame) – это распределенная таблица, коллекция данных, сгруппированная в именованные столбцы аналогично реляционной таблице в Spark SQL. Обычно работа с данными в PySpark включает в себя применение преобразований, агрегаций и манипуляций к датафреймам. Чтобы протестировать полученный код в Apache Spark 3.5 были добавлены утилиты проверки равенства датафреймов. Они позволяют сверить данные с ожидаемыми результатами, помогая выявить неожиданные различия и ошибки на ранних этапах процесса анализа.
На текущий момент в PySpark есть следующие функции, которые можно использовать для тестирования написанного кода распределенного приложения:
✔️assertDataFrameEqual(actual, expected[, …]) – утилита для подтверждения равенства между фактическим и ожидаемым датафреймом или списками строк с дополнительными параметрами checkRowOrder, rtol и atol;
✔️assertSchemaEqual(actual, expected) – утилита для подтверждения равенства между фактической и ожидаемой схемами датафрейма;
✔️assertPandasOnSparkEqual(actual, expected[, …]) – утилитная функция для подтверждения равенства между фактическим объектом pandas-on-Spark и ожидаемым объектом pandas-on-Spark или pandas. О разнице между классическим API pandas и его реализации в PySpark мы ранее писали здесь и здесь.
Все эти функции основаны на понятии assert – конструкции, которая позволяет проверять предположения о значениях произвольных данных в произвольном месте программы, подавая сигнал об обнаружении некорректных данных, что может привести к сбою.
Assert завершает программу сразу же после обнаружения некорректных данных, давая разработчику возможность быстро определить ошибки и исправить их. Assert может отловить ошибки в коде на этапе компиляции или во время исполнения. Проверки на этапе компиляции можно заменить аналогичными синтаксическими конструкциями во время исполнения программы, например, try-except-finally.
В большинстве языков программирования позволяют отключить assert на этапе компиляции или во время выполнения программы, поэтому влияние этих конструкций на производительность итогового продукта незначительно.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/spark/pyspark-dataframe-testing-with-assert-functions.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Сравнение датафреймов в Apache Spark на примере PySpark-кода
Что такое assert, зачем это нужно в тестировании и отладке, как это применяется для сравнения датафреймов PySpark: примеры функций Spark
#Spark #SQL #DataFrame
8️⃣Источники данных Apache Spark
❓Какие источники исходных данных поддерживает Apache Spark для пакетной и потоковой обработки, обеспечивая отказоустойчивые вычисления в большом масштабе средствами SQL и Structured Streaming.
Источники данных Apache Spark SQL и структурированной потоковой передачи
Будучи фреймворком для создания распределенных приложений обработки больших объемов данных, Apache Spark может подключаться к разным источникам этих данных, в зависимости от используемого API.
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-data-sources.html
Курсы: https://bigdataschool.ru/courses/apache-spark-core
https://bigdataschool.ru/courses/apache-spark-for-data-engineer
https://bigdataschool.ru/courses/apache-spark-graphframe
https://bigdataschool.ru/courses/apache-spark-machine-learning
https://bigdataschool.ru/courses/apache-spark-sql
https://bigdataschool.ru/courses/apache-spark-structured-streaming
Наш сайт: https://bigdataschool.ru/
8️⃣Источники данных Apache Spark
❓Какие источники исходных данных поддерживает Apache Spark для пакетной и потоковой обработки, обеспечивая отказоустойчивые вычисления в большом масштабе средствами SQL и Structured Streaming.
Источники данных Apache Spark SQL и структурированной потоковой передачи
Будучи фреймворком для создания распределенных приложений обработки больших объемов данных, Apache Spark может подключаться к разным источникам этих данных, в зависимости от используемого API.
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-data-sources.html
Курсы: https://bigdataschool.ru/courses/apache-spark-core
https://bigdataschool.ru/courses/apache-spark-for-data-engineer
https://bigdataschool.ru/courses/apache-spark-graphframe
https://bigdataschool.ru/courses/apache-spark-machine-learning
https://bigdataschool.ru/courses/apache-spark-sql
https://bigdataschool.ru/courses/apache-spark-structured-streaming
Наш сайт: https://bigdataschool.ru/
#Spark #Databricks #Lakeguard
Изоляция приложений Apache Spark в одной среде Databricks с Lakeguard
Проблемы управления данными в мультиарендной среде или как Databricks решил изолировать клиентские приложения Apache Spark на общей виртуальной машине Java друг от друга и от самого фреймворка (драйвера и исполнителей). Знакомство с Lakeguard на базе каталога Unity.
Проблемы управления данными в мультитенантной среде
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-apps-isolation-with-lakeguard-databricks.html
Курсы: https://bigdataschool.ru/courses/apache-spark-for-data-engineer https://bigdataschool.ru/courses/data-architecture https://bigdataschool.ru/courses/practice-data-architecture
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Изоляция приложений Apache Spark в одной среде Databricks с Lakeguard
Проблемы управления данными в мультиарендной среде или как Databricks решил изолировать клиентские приложения Apache Spark на общей виртуальной машине Java друг от друга и от самого фреймворка (драйвера и исполнителей). Знакомство с Lakeguard на базе каталога Unity.
Проблемы управления данными в мультитенантной среде
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-apps-isolation-with-lakeguard-databricks.html
Курсы: https://bigdataschool.ru/courses/apache-spark-for-data-engineer https://bigdataschool.ru/courses/data-architecture https://bigdataschool.ru/courses/practice-data-architecture
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Spark #SQL #Dynamic #Partition #Pruning
Динамическое сокращение разделов в Spark SQL
Что такое Dynamic Partition Pruning в Spark SQL, как работает этот метод оптимизации пакетных запросов, зачем его использовать в задачах аналитики больших данных, и каким образом повысить эффективность его практического применения.
Что такое Dynamic Partition Pruning и зачем это нужно в Spark SQL
Параллельная обработка данных в Apache Spark обеспечивается благодаря их разделению. Каждый раздел обрабатывается отдельным процессом (исполнителем). Поэтому можно сказать, что раздел в Spark является единицей параллелизма. Однако, слишком большое количество разделов приводит к потере параллелизма, поскольку 1 исполнитель Spark может обрабатывать только 1 раздел в единицу времени.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Динамическое сокращение разделов в Spark SQL
Что такое Dynamic Partition Pruning в Spark SQL, как работает этот метод оптимизации пакетных запросов, зачем его использовать в задачах аналитики больших данных, и каким образом повысить эффективность его практического применения.
Что такое Dynamic Partition Pruning и зачем это нужно в Spark SQL
Параллельная обработка данных в Apache Spark обеспечивается благодаря их разделению. Каждый раздел обрабатывается отдельным процессом (исполнителем). Поэтому можно сказать, что раздел в Spark является единицей параллелизма. Однако, слишком большое количество разделов приводит к потере параллелизма, поскольку 1 исполнитель Spark может обрабатывать только 1 раздел в единицу времени.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Photon #SQL #Spark #Databricks
Photon: новый векторизованный движок запросов Spark SQL от Databricks
Зачем Databricks выпустила новый движок выполнения запросов Spark SQL для ML-приложений, как он работает и где его настроить: возможности и ограничения Photon Engine.
Преимущества Photon Engine для ML-нагрузок Spark-приложений
Чтобы сделать Apache Apark еще быстрее, разработчики Databricks выпустили новый движок выполнения запросов — Photon Engine. Это высокопроизводительный механизм запросов, который может быстрее запускать Spark SQL и выполнят вычисления над датафреймами, снижая общую стоимость рабочей нагрузки.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Photon: новый векторизованный движок запросов Spark SQL от Databricks
Зачем Databricks выпустила новый движок выполнения запросов Spark SQL для ML-приложений, как он работает и где его настроить: возможности и ограничения Photon Engine.
Преимущества Photon Engine для ML-нагрузок Spark-приложений
Чтобы сделать Apache Apark еще быстрее, разработчики Databricks выпустили новый движок выполнения запросов — Photon Engine. Это высокопроизводительный механизм запросов, который может быстрее запускать Spark SQL и выполнят вычисления над датафреймами, снижая общую стоимость рабочей нагрузки.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"