Comments 13
Спасибо за статью. Отметил для себя полезные моменты.
А можно ли мониторить ещё количество прочитанных и записанных строк, как это принято в ETL инструментах? Возможно, с разбивкой на стейджи.
Попробуйте проанализировать лог приложения spark. Информация о разбивке на стейджи и количеству байт там есть. Насчёт сбора количества строк и прочих метрик: стоит через metrics.properties подключить Gpahite. Например, по динамике использованной памяти и памяти на драйвер там есть метрики
[0-9]*.jvm.heap.used
[0-9]*.jvm.heap.used
На самом деле у спарка есть своя подсистема мониторинга и измерения (основанная на известном пакете dropvizard metrics). Кроме того, есть чуть более базовые вещи, такие как аккумуляторы. Вы вполне можете любые свои метрики собирать, включая и количество строк (надо при этом только понимать, что строки как правило проходят через параллельную обработку, т.е. через executors, поэтому инструмент должен эти статистики передавать куда-то (драйверу)).
Мониторинг логов Spark силами Spark SQL — просто демонстрация того, что такое вполне под силу Spark SQL.
Спасибо за статью, позвольте пару вопросов.
1. Можно ли использовать spark sql как и другую СУБД через драйвер jdbc?
2. Если Spark без подсказки не знает, что данные распределены неравномерно, можно ли включить какую-то статистику распределения данных, как это работает в таких MPP СУБД как Teradata или Greenplum?
1. Можно ли использовать spark sql как и другую СУБД через драйвер jdbc?
2. Если Spark без подсказки не знает, что данные распределены неравномерно, можно ли включить какую-то статистику распределения данных, как это работает в таких MPP СУБД как Teradata или Greenplum?
1) Я лично не подключал Spark SQL через JDBC, но пишут, что это возможно, если поднять Thrift Server
habr.com/ru/company/wrike/blog/275567
2)
Например, на странице jaceklaskowski.gitbooks.io/mastering-spark-sql/spark-sql-cost-based-optimization.html
рекомендуют вызывать для перекошенных столбцов сбор статистики командой
ANALYZE TABLE COMPUTE STATISTICS FOR COLUMNS,
включать режим spark.sql.cbo.enabled=true и пользоваться собранной статистикой.
Но у меня на практике это не взлетело.
habr.com/ru/company/wrike/blog/275567
2)
Например, на странице jaceklaskowski.gitbooks.io/mastering-spark-sql/spark-sql-cost-based-optimization.html
рекомендуют вызывать для перекошенных столбцов сбор статистики командой
ANALYZE TABLE COMPUTE STATISTICS FOR COLUMNS,
включать режим spark.sql.cbo.enabled=true и пользоваться собранной статистикой.
Но у меня на практике это не взлетело.
>1) Я лично не подключал Spark SQL через JDBC, но пишут, что это возможно, если поднять Thrift Server
Насколько я понимаю, Hue примерно так и делает. А возможно что и Hive умеет подключать спарк в качестве движка (никогда, впрочем, не вникал в детали, но такая переменная set hive.execution.engine=spark у Hive есть). Т.е. дальше просто штатный Thrift от Hive, который уже запускает запрос на исполнение через Spark.
P.S. Если совсем честно, не вижу большого смысла использовать спарк через JDBC. Это соединение будет бутылочным горлышком.
Насколько я понимаю, Hue примерно так и делает. А возможно что и Hive умеет подключать спарк в качестве движка (никогда, впрочем, не вникал в детали, но такая переменная set hive.execution.engine=spark у Hive есть). Т.е. дальше просто штатный Thrift от Hive, который уже запускает запрос на исполнение через Spark.
P.S. Если совсем честно, не вижу большого смысла использовать спарк через JDBC. Это соединение будет бутылочным горлышком.
Продвинутым бизнес пользователям может быть полезно. Чтоб не переливать данные, а подключить какое-нибудь Tableau или Spotfire через Jdbc и что-то там анализировать.
Ну гипотетически — да, возможно конечно, с ограничениями.
Но практически, у нас вот на реально загруженном кластере это выглядит так — вы запускаете запрос, там где-то в ярне стартует приложение (spark), которому тупо не дают ресурсы — потому что они заняты.
Ну и потом — через JDBC все однопоточно, следовательно отдать по jdbc что-то в Tableau — этого чего-то должно быть все-таки немного. То есть, спарк-то переварит и терабайт, и десяток — но вот отдать терабайт кому-то для анализа уже вряд ли.
Кластер для этого должен быть например отдельный, специально предназначенный и настроеный. А иначе ответа можно будет ждать часами, и не потому что спарк вовсе. В моей практике обычно получалось, что проще сделать специально для таких потребителей витрину, и даже выкинуть ее в реляционную СУБД, и пусть они уже там со своими инструментами делают что хотят.
Кстати, насколько я понимаю, это именно фича Hive — потому что если посмотреть на скриншот, который выше по ссылке приведен, habr.com/ru/company/wrike/blog/275567, то там видно, что драйвер-то — он от Hive. Не от спарка.
Но практически, у нас вот на реально загруженном кластере это выглядит так — вы запускаете запрос, там где-то в ярне стартует приложение (spark), которому тупо не дают ресурсы — потому что они заняты.
Ну и потом — через JDBC все однопоточно, следовательно отдать по jdbc что-то в Tableau — этого чего-то должно быть все-таки немного. То есть, спарк-то переварит и терабайт, и десяток — но вот отдать терабайт кому-то для анализа уже вряд ли.
Кластер для этого должен быть например отдельный, специально предназначенный и настроеный. А иначе ответа можно будет ждать часами, и не потому что спарк вовсе. В моей практике обычно получалось, что проще сделать специально для таких потребителей витрину, и даже выкинуть ее в реляционную СУБД, и пусть они уже там со своими инструментами делают что хотят.
Кстати, насколько я понимаю, это именно фича Hive — потому что если посмотреть на скриншот, который выше по ссылке приведен, habr.com/ru/company/wrike/blog/275567, то там видно, что драйвер-то — он от Hive. Не от спарка.
>2. Если Spark без подсказки не знает, что данные распределены неравномерно, можно ли включить какую-то статистику распределения данных, как это работает в таких MPP СУБД как Teradata или Greenplum?
Понимаете, без посказки никто не знает. Сбор статистики есть везде, и он, что характерно, стоит ресурсов. Та же команда ANALYZE — она занимает существенное время. Самое лучшее, что вы можете сделать — это чтобы другое приложение, которое запишет когда-то новые данные, в процессе их формирования эти статистики подсчитало. Попутно, так сказать.
Понимаете, без посказки никто не знает. Сбор статистики есть везде, и он, что характерно, стоит ресурсов. Та же команда ANALYZE — она занимает существенное время. Самое лучшее, что вы можете сделать — это чтобы другое приложение, которое запишет когда-то новые данные, в процессе их формирования эти статистики подсчитало. Попутно, так сказать.
Большое спасибо за статью. Вставлю свои 5 копеек про мониторинг.
1. Если у Вас Cloudera (судя по скриншотам у автора она), можно глянуть, сколько CPU/памяти выделяется но не используется в «Cluster Utilization Reports» (есть поле «unused capacity» для CPU и памяти), или можно по REST API смотреть/получать эти же данные (метрики unused_memory_seconds, unused_vcore_seconds).
2. У YARN есть свой REST API. Если есть доступ, можно его использовать в скриптах вместо «yarn application -list» и «yarn application -status»
1. Если у Вас Cloudera (судя по скриншотам у автора она), можно глянуть, сколько CPU/памяти выделяется но не используется в «Cluster Utilization Reports» (есть поле «unused capacity» для CPU и памяти), или можно по REST API смотреть/получать эти же данные (метрики unused_memory_seconds, unused_vcore_seconds).
2. У YARN есть свой REST API. Если есть доступ, можно его использовать в скриптах вместо «yarn application -list» и «yarn application -status»
Спасибо за статью.
Sign up to leave a comment.
Практика использования Spark SQL, или Как не наступить на грабли