Здравствуйте, Gt_, Вы писали:


Ох, вместо того, чтобы сказать "Спасибо, Максим, за просвещение" ты продолжаешь заниматься ребячеством и лезть в бутылку.
Через меня таких как ты, для которых "внутре ее неонка" и прочая магия, регулярно проходят десятки. Потом приходится переписывать поделки, чтобы снизить время процессинга с часов до секунд.

MVK>>Или нужно объяснить?
Gt_>о, давай. будет забавно посмотреть на потуги чудика который еще вчера считал, что спарк лишь передает запрос.
детальное объяснение ниже

Gt_>как же ноль, если их хватило постебаться над твоими базовыми познаниями и макнуть в твое "Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность".

В результате ты постебался сам над собой
Попробую опять на пальцах на простом примере, spark demystified.

Берем типовую аналитическую задачу: на входе скажем сотня миллиардов записей, на выходе тысяча с посчитанными агрегатами.
Есть две опции где 100 миллиардов записей превратяться в тысячу: spark и clickhouse

Эти две опции выливаются в три возможных сценария:
1) Reduce через расчет агрегатов происходит на стороне спарка. Кликхауз работает как хранилище.

Разбиваем триллион записей на бакеты по миллиарду, загружаем все это параллельно в спарковские таски, считаем агрегаты на стороне спарка.
Это будет самый ужасный по производительности вариант. Так как тебе нужно будет перекачать все терабайты из кликхауза на спарковские ноды, чтобы там посчитать агрегаты.

Для кликзауза это серия запросов вида:
select dim1, dim2, dim3, val1, val2, val3 from table where id between 1 and 1e9
select dim1, dim2, dim3, val1, val2, val3 from table where id between 1e9+1 and 2e9
...
select dim1, dim2, dim3, val1, val2, val3 from table where id between 99e9+1 and 100e9

Это сценарий, который ты описываешь, когда кликхауз рассматривается просто как "сторадж".
В этом случае данные действительно будут загружены в датафреймы (возможно кусочками), а потом к ним будут применены агрегаты на стороне спарка. Так спарк используют при работе с условными csv файлами в HDFS или гетерогенными источниками. Конечно, можно его так использовать и при работе с Clickhouse, но это как таскать ишака на себе вместо того, чтобы на нем ехать.


2) Расчет агрегатов делается в кликхауз, но spark делает параллелизацию.
Очевидно, что лучше чем первый вариант.
Для кликзауза это будет серия запросов вида.
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 1 and 1e9 group by dim1, dim2, dim3
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 1e9+1 and 2e9 group by dim1, dim2, dim3
...
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 99e9+1 and 100e9 group by dim1, dim2, dim3

Такое можно сделать или ручками, или через pushdown агрегатов, но второе возможно только для простых сценариев, так как спарк поддерживает только самые примитивные агрегаты. Ну и не все спарковские коннекторы в это умеют. Приличный кликхаузовский коннектор с поддержкой v2 появился, кстати, совсем недавно, но они еще не все фичи поддерживают.


3) Все делаем в кликхаузе. В этом случае спарк нам вообще не нужен.
Для кликзауза это простой запрос вида:
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table group by dim1, dim2, dim3

На 99.9% задач это будет самый быстрый вариант. Разница в производительности секунды/минуты vs часы. Собственно, Clickhouse и создавался, чтобы быстро решать такой класс задач. Поэтому да "спарк просто передаст запрос в кликхауз", любой другой вариант приведет к лишнему коду и просадке производительности. Более того, если уж ты правильно сложил данные в кликхауз, то потребность в спарке вообще отпадает, как я уже сказал на 99.9% задач, поэтому я тебе и написал, что спарк ничего не даст. А там где он действительно нужен, ты совсем не понимаешь даже, как оно должно работать.


------
Реальные боевые задачи, конечно, намного сложнее и практическое решение зависит от выбранной стратегии для работы с данными. Если расписывать, то получится серия статей, поэтому попробую написать ключевые тезисы.

Для работы с большими данными для задач аналитики условно можно (очень упрощенно) обозначить три стратегии:

1) Данные хранятся в различных источниках. Сюда попадает спарк, различные инструменты виртуализации данных типа Denodo. Из плюсов — быстрый сетап. Из минусов — все работает очень медленно. Задачи exploratory analytics, где важно оптимизировать цикл "гипотеза — проверка" решаются очень плохо.

2) Данные собираются в одной платформе заточенной под аналитические задачи (Clickhouse, Vertica, etc), где строятся плоские денормализованные представления для быстрого анализа. Из плюсов — если данные есть в платформе, то анализ делается с фантастической скоростью. Из минусов: 1) приходится ждать, когда данные появятся в платформе, 2) разные задачи требуют разного представления и использовать тот же кликхауз для анализа графов или работы с матрицами еще то извращение. Ну и join двух больших таблиц в Clickhouse или Vertica — это очень дорогое удовольствие, поэтому даже если данные есть, то не всегда можно легко построить поверх них аналитику.

3) Гибридный вариант, который чаще всего и встречается на практике. Наиболее востребованные данные собираются (тем же спарком) в нескольких базах, заточенные под разные аналитические задачи: time series, классический olap, анализ графов и так далее. При этом для данных, которые недоступны в аналитических платформах, можно быстро собрать ту же спарковскую джобу которая или создаст новое представление в аналитеческой платформе, или быстро выкатит результат. Из минусов — очень дорого. Из плюсов — гибкость и скорость решения. Плюс это позволяет на уровне платформ разделить роли дата инженера и дата аналитика. Первые отвечают за создание и поддержку различных представлений в аналитических платформах, а вторые пользуются этими платформами для анализа. Первые используют инженерный стек, например, scala, spark, kafka и вот это все, а вторые сидят в питонах, матлабе и Tableau. В моем случае используется гибридный вариант, хотя там много чего еще нужно строить и перестраивать.

------

Ну и для полноты картины, опишу тот самый 0.1% ситуаций, когда данные лежат в кликхаузе, но спарк может помочь.
1. Нужно сджойнить данные в кликхаузе с данными из другого источника.
2. Невозможно провести вычисления на стороне кликхауза. Несмотря на очень богатый набор функций для аналитики, есть задачи которые не решаются на уровне sql запроса.
3. Задача настолько memory intensive или cpu intensive, что выигрыш от переноса вычислений на вычислительный кластер превышает проигрыш от перекачки данных
4. Данные лежат в distributed таблицах и спарк знает о критериях шардирования/партицирования (это отдельный топик, я не буду его затрагивать по причине отсутствия опыта в оптимизации таких сценариев)

Типовая стратегия в таких ситуациях, особенно когда количество данных переваливает за терабайты — это постараться максимально редуцировать данные на стороне кликхауза. Возможно решения обычно такие:
1) Предварительная агрегация
2) Декомпозиция сложного вычисления на поддерживаемые кликхаузом
3) Семплинг


Gt_>лихорадочные попытки почитать хоть что-то из туториала похвальны, но уйти от насмешек уже не выйдет. особливо после заявления, что ты спарк смотрел.
Как бы спарк мой ежедневный инструмент уже лет как 8 На счет чтения туторилов — согласен, дело хорошее, чего и тебе желаю.

Gt_>но сначала, давай все же зафиксируем базис: до тебя дошло, что спарк сам строит план, сам выполняет все вычисление, ничего в клик не транслируется ?
Я надеюсь, что ты понял, что так оно не работает?
Видишь ли, мы с тобой тут в очень разных весовых категориях. Возможно, эффект даннинга-крюгера мешает тебе это увидеть, но это пройдет

Поэтому у нас в базисе пока:
1) У тебя очень ограниченное представление о том, для чего нужен spark и как он используется. Тебе знаком один сценарий использования и ты пытаешься его натянуть на все остальное.
2) Ты не понимаешь, что такое spark dataframe и не знаешь про rdd
3) Ты не знал, что спарк умеет генерить SQL (pushdown и pruning)
4) Для тебя новость, что spark написан на Scala. В противном случае советовать использовать решение написанное на умершем языке — это прям диверсия.
5) Видимо, ты даже плаваешь в понимании, что такое jvm (тут ты меня удивил очень сильно)
Поэтому я таки рассчитываю на слова благодарности за ликбез.

Ну и, кстати, со своей стороны, я был бы очень признателен, если бы ты ткнул меня носом в пробелы в моих знаниях или задал вопрос, который поставил бы меня в тупик.

Здравствуйте, Gt_, Вы писали:


Ох, вместо того, чтобы сказать "Спасибо, Максим, за просвещение" ты продолжаешь заниматься ребячеством и лезть в бутылку.
Через меня таких как ты, для которых "внутре ее неонка" и прочая магия, регулярно проходят десятки. Потом приходится переписывать поделки, чтобы снизить время процессинга с часов до секунд.

MVK>>Или нужно объяснить?
Gt_>о, давай. будет забавно посмотреть на потуги чудика который еще вчера считал, что спарк лишь передает запрос.
детальное объяснение ниже

Gt_>как же ноль, если их хватило постебаться над твоими базовыми познаниями и макнуть в твое "Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность".

В результате ты постебался сам над собой
Попробую опять на пальцах на простом примере, spark demystified.

Берем типовую аналитическую задачу: на входе скажем сотня миллиардов записей, на выходе тысяча с посчитанными агрегатами.
Есть две опции где 100 миллиардов записей превратяться в тысячу: spark и clickhouse

Эти две опции выливаются в три возможных сценария:
1) Reduce через расчет агрегатов происходит на стороне спарка. Кликхауз работает как хранилище.

Разбиваем 100 миллиардов записей на бакеты по миллиарду, загружаем все это параллельно в спарковские таски, считаем агрегаты на стороне спарка.
Это будет самый ужасный по производительности вариант. Так как тебе нужно будет перекачать все терабайты из кликхауза на спарковские ноды, чтобы там посчитать агрегаты.

Для кликзауза это серия запросов вида:
select dim1, dim2, dim3, val1, val2, val3 from table where id between 1 and 1e9
select dim1, dim2, dim3, val1, val2, val3 from table where id between 1e9+1 and 2e9
...
select dim1, dim2, dim3, val1, val2, val3 from table where id between 99e9+1 and 100e9

Это сценарий, который ты описываешь, когда кликхауз рассматривается просто как "сторадж".
В этом случае данные действительно будут загружены в датафреймы (возможно кусочками), а потом к ним будут применены агрегаты на стороне спарка. Так спарк используют при работе с условными csv файлами в HDFS или гетерогенными источниками. Конечно, можно его так использовать и при работе с Clickhouse, но это как таскать ишака на себе вместо того, чтобы на нем ехать.


2) Расчет агрегатов делается в кликхауз, но spark делает параллелизацию.
Очевидно, что лучше чем первый вариант.
Для кликзауза это будет серия запросов вида.
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 1 and 1e9 group by dim1, dim2, dim3
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 1e9+1 and 2e9 group by dim1, dim2, dim3
...
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table where id between 99e9+1 and 100e9 group by dim1, dim2, dim3

Такое можно сделать или ручками, или через pushdown агрегатов, но второе возможно только для простых сценариев, так как спарк поддерживает только самые примитивные агрегаты. Ну и не все спарковские коннекторы в это умеют. Приличный кликхаузовский коннектор с поддержкой v2 появился, кстати, совсем недавно, но они еще не все фичи поддерживают.


3) Все делаем в кликхаузе. В этом случае спарк нам вообще не нужен.
Для кликзауза это простой запрос вида:
select dim1, dim2, dim3, agg(val1), agg(val2), agg(val3) from table group by dim1, dim2, dim3

На 99.9% задач это будет самый быстрый вариант. Разница в производительности секунды/минуты vs часы. Собственно, Clickhouse и создавался, чтобы быстро решать такой класс задач. Поэтому да "спарк просто передаст запрос в кликхауз", любой другой вариант приведет к лишнему коду и просадке производительности. Более того, если уж ты правильно сложил данные в кликхауз, то потребность в спарке вообще отпадает, как я уже сказал на 99.9% задач, поэтому я тебе и написал, что спарк ничего не даст. А там где он действительно нужен, ты совсем не понимаешь даже, как оно должно работать.


------
Реальные боевые задачи, конечно, намного сложнее и практическое решение зависит от выбранной стратегии для работы с данными. Если расписывать, то получится серия статей, поэтому попробую написать ключевые тезисы.

Для работы с большими данными для задач аналитики условно можно (очень упрощенно) обозначить три стратегии:

1) Данные хранятся в различных источниках. Сюда попадает спарк, различные инструменты виртуализации данных типа Denodo. Из плюсов — быстрый сетап. Из минусов — все работает очень медленно. Задачи exploratory analytics, где важно оптимизировать цикл "гипотеза — проверка" решаются очень плохо.

2) Данные собираются в одной платформе заточенной под аналитические задачи (Clickhouse, Vertica, etc), где строятся плоские денормализованные представления для быстрого анализа. Из плюсов — если данные есть в платформе, то анализ делается с фантастической скоростью. Из минусов: 1) приходится ждать, когда данные появятся в платформе, 2) разные задачи требуют разного представления и использовать тот же кликхауз для анализа графов или работы с матрицами еще то извращение. Ну и join двух больших таблиц в Clickhouse или Vertica — это очень дорогое удовольствие, поэтому даже если данные есть, то не всегда можно легко построить поверх них аналитику.

3) Гибридный вариант, который чаще всего и встречается на практике. Наиболее востребованные данные собираются (тем же спарком) в нескольких базах, заточенные под разные аналитические задачи: time series, классический olap, анализ графов и так далее. При этом для данных, которые недоступны в аналитических платформах, можно быстро собрать ту же спарковскую джобу которая или создаст новое представление в аналитеческой платформе, или быстро выкатит результат. Из минусов — очень дорого. Из плюсов — гибкость и скорость решения. Плюс это позволяет на уровне платформ разделить роли дата инженера и дата аналитика. Первые отвечают за создание и поддержку различных представлений в аналитических платформах, а вторые пользуются этими платформами для анализа. Первые используют инженерный стек, например, scala, spark, kafka и вот это все, а вторые сидят в питонах, матлабе и Tableau. В моем случае используется гибридный вариант, хотя там много чего еще нужно строить и перестраивать.

------

Ну и для полноты картины, опишу тот самый 0.1% ситуаций, когда данные лежат в кликхаузе, но спарк может помочь.
1. Нужно сджойнить данные в кликхаузе с данными из другого источника.
2. Невозможно провести вычисления на стороне кликхауза. Несмотря на очень богатый набор функций для аналитики, есть задачи которые не решаются на уровне sql запроса.
3. Задача настолько memory intensive или cpu intensive, что выигрыш от переноса вычислений на вычислительный кластер превышает проигрыш от перекачки данных
4. Данные лежат в distributed таблицах и спарк знает о критериях шардирования/партицирования (это отдельный топик, я не буду его затрагивать по причине отсутствия опыта в оптимизации таких сценариев)

Типовая стратегия в таких ситуациях, особенно когда количество данных переваливает за терабайты — это постараться максимально редуцировать данные на стороне кликхауза. Возможно решения обычно такие:
1) Предварительная агрегация
2) Декомпозиция сложного вычисления на поддерживаемые кликхаузом
3) Семплинг


Gt_>лихорадочные попытки почитать хоть что-то из туториала похвальны, но уйти от насмешек уже не выйдет. особливо после заявления, что ты спарк смотрел.
Как бы спарк мой ежедневный инструмент уже лет как 8 На счет чтения туторилов — согласен, дело хорошее, чего и тебе желаю.

Gt_>но сначала, давай все же зафиксируем базис: до тебя дошло, что спарк сам строит план, сам выполняет все вычисление, ничего в клик не транслируется ?
Я надеюсь, что ты понял, что так оно не работает?
Видишь ли, мы с тобой тут в очень разных весовых категориях. Возможно, эффект даннинга-крюгера мешает тебе это увидеть, но это пройдет

Поэтому у нас в базисе пока:
1) У тебя очень ограниченное представление о том, для чего нужен spark и как он используется. Тебе знаком один сценарий использования и ты пытаешься его натянуть на все остальное.
2) Ты не понимаешь, что такое spark dataframe и не знаешь про rdd
3) Ты не знал, что спарк умеет генерить SQL (pushdown и pruning)
4) Для тебя новость, что spark написан на Scala. В противном случае советовать использовать решение написанное на умершем языке — это прям диверсия.
5) Видимо, ты даже плаваешь в понимании, что такое jvm (тут ты меня удивил очень сильно)
Поэтому я таки рассчитываю на слова благодарности за ликбез.

Ну и, кстати, со своей стороны, я был бы очень признателен, если бы ты ткнул меня носом в пробелы в моих знаниях или задал вопрос, который поставил бы меня в тупик.