Код довольно однообразен , например раздражает когда нужно для 10 метрик написать что-то типа (в синтаксисе кликзауз):
select
dim1,
dim2,
...
sumIf(metric0, isFinite(metric0)) as metric0,
...
sumIf(metric9, isFinite(metriс9)) as metric9
group by
dim1,
dim3,
...
Пока написал кастомные команды к ideavim, но хотелось бы чего-то более умного. В идеале доступа к ast и схеме базы, и манипуляций с ним.
Не очень пока понимаю, c какой стороны к этой задаче лучше подступиться, чтобы начать с малого и понемногу расширять количество тулов для повышения своей производительности.
Работаю в основном в JetBrains-овских продуктах.
Здравствуйте, MaximVK, Вы писали:
MVK>Пока написал кастомные команды к ideavim, но хотелось бы чего-то более умного. В идеале доступа к ast и схеме базы, и манипуляций с ним.
Если у вас Постгрес, посмотрите на EdgeQL
А вообще эту часть айти только ядерная война исправит, и то не 100%
Возможно вам поможет генерация через linq2db или JOOQ и какие-то самописные расширения.
У меня микс, Clickhouse, Oracle, Postgre, MySQL и экзотика в виде kdb (но это вообще отдельный мир).
Возможно, еще MS SQL приедет
Но пока в основном Oracle и Clickhouse.
С>Если у вас Постгрес, посмотрите на EdgeQL
Спасибо, посмотрю.
С>Возможно вам поможет генерация через linq2db или JOOQ и какие-то самописные расширения.
linq2db и jooq — это, имхо, про другое. Не очень понятно, как мне их приткнуть.
>А вообще эту часть айти только ядерная война исправит, и то не 100% да, пока все попытки это исправить приводили к еще большим проблемам
[]
С>>Возможно вам поможет генерация через linq2db или JOOQ и какие-то самописные расширения. MVK>linq2db и jooq — это, имхо, про другое. Не очень понятно, как мне их приткнуть.
писать (генерить) экспрешны в jooq а потом генерить из них sql
Здравствуйте, Константин Л., Вы писали:
КЛ>писать (генерить) экспрешны в jooq а потом генерить из них sql
Ну это прямо скажем еще то извращение будет. SQL получится так себе, особенно если используешь какие-то не совсем типовые диалекты.
Я сомневаюсь, что, например, jooq умеет в high order functions и arrays в Clickhouse.
Идея именно в том, чтобы удобнее и быстрее было писать сам SQL.
Здравствуйте, MaximVK, Вы писали:
MVK>По работе приходится очень много писать SQL кода.
Если речь про .NET, то сегодня писать SQL руками — это нонсенс. Тем более под разные диалекты SQL. linq2db и подобное всё это умеет и поддерживает в том числе всевозможные техники повторного использования кода.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>писать (генерить) экспрешны в jooq а потом генерить из них sql
MVK>Ну это прямо скажем еще то извращение будет. SQL получится так себе, особенно если используешь какие-то не совсем типовые диалекты.
во-первых, почему "получится так себе"? Во-вторых, если такой диалект поддерживается jooq, то это проблема не jooq. В общем, я не понял.
MVK>Я сомневаюсь, что, например, jooq умеет в high order functions и arrays в Clickhouse.
так проверь
MVK>Идея именно в том, чтобы удобнее и быстрее было писать сам SQL.
если запросы типовые, то зачем его вообще писать? нужно его генерить по схеме с помощью jooq
Здравствуйте, IT, Вы писали:
IT>Если речь про .NET, то сегодня писать SQL руками — это нонсенс.
Ну, я бы сказал не нонсенс, а удел только узких нишевых решений.
Для большинства энтерпрайза/веба linq2db решает 100 процентов задач весьма эффективно.
Здравствуйте, IT, Вы писали:
IT>Если речь про .NET, то сегодня писать SQL руками — это нонсенс. Тем более под разные диалекты SQL. linq2db и подобное всё это умеет и поддерживает в том числе всевозможные техники повторного использования кода.
linq2db я активно использовал, когда писал под .Net. Очень удобно.
Отвечаю сразу и IT и Константину (спасибо за комментарии!)
У меня сейчас другая задача.
Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения.
Максимум — это питонячий скрипт, который потом докручивает аналитику или ML.
С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей.
Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному.
Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
Update:
Из близкого к тому, что может как-то помочь — это питонячий dbt. Но это по сути темплейтер на стероидах: текстовые макросы + "компиляция". В кавычках, потому что как таковой компиляции (как MS SQL project) там, конечно, нет и близко. Но dbt закрывает лишь часть задач, и я все еще сильно сомневаюсь в том, чтобы его тащить в проект.
Отписался более подробно в треде с IT. Здесь отчету про jooq.
КЛ>во-первых, почему "получится так себе"? Во-вторых, если такой диалект поддерживается jooq, то это проблема не jooq. В общем, я не понял.
Я посмотрел, что умеет jooq. Не очень понятно в чем будет выигрыш, при условии что мне нет необходимости вызывать sql из java.
Бесспорно, полезная штука, если пилишь приложение, которому нужно ходить в базу, но для дата аналитических задач — только усложнит и удлинит процесс разработки.
КЛ>так проверь
Clickhouse поддержки нет на официальном сайте, но похоже идет работа в одном из форков.
КЛ>если запросы типовые, то зачем его вообще писать? нужно его генерить по схеме с помощью jooq
Я видимо плохо объяснил сценарий. Запросы аналитические, т.е. типовыми их не назовешь. Это не стандартный crud + проекции.
MVK>У меня сейчас другая задача. MVK>Нужно писать большое количество аналитических запросов и у меня нет необходимости вызывать этот sql код из приложения. MVK>Максимум — это питонячий скрипт, который потом докручивает аналитику или ML. MVK>С точки зрения кол-во строк кода 80-90% — это SQL скрипты, которые процессят относительно большие объемы, несколько миллиардов записей. MVK>Поэтому используются различные оптимизационные техники, так как один и тот же запрос можно написать очень по разному. MVK>Но так как SQL очень а) избыточен, б) плохо композируется, в) плохо поддерживает переиспользование, то приходится постоянно писать плюс/минус одинаковые куски кода, что раздражает. Code pilot помогает, но далеко не всегда ну и это не совсем то, что хотелось бы.
если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. там получиться в цикле добавление к датафрейму колоноки с метриками, новая метрика наследуется там от чего-то. как бонус сумасшедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
Gt_>если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark.
Нет, ооп совсем не нужен, более того он тут только мешать будет. Спарк уже есть, конечно, но для других задач, для этой он плохо подходит.
Gt_> там полчучиться в цикле добавление к датафрейму колонок с метриками, новая метрика наследуется там от чего-то.
В реальности на боевых задачах у тебя будет определена куча udf, которые спарк не сможет оттранслировать в clickhouse native functions и будет тащить в память все 100 миллиардов записей. spark clickhouse connector может в push down, но только для основных операций. Ну а умные оптимизации типа там с битмэпами можно вообще забыть.
Gt_>как бонус сумашедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
А каким тут это боком? Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность. Максимум, что он сможет это правильно раскидать запросы на кластер, но когда я последний раз туда смотрел, там все было кривовато с этим.
Спарк умеет в map reduce, конечно, но для этого у тебя данные должны по нескольким нодам быть разбросаны.
Но в целом, если данные лежат в каком-то паркете на S3 кластере, то спарк, конечно хорош. Ну или если есть зоопарк различных баз и файлов, и задачи хорошо ложатcя на map reduce. Ну и скала довольно выразительна для таких задач тоже.
Gt_>>если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark. MVK>Нет, ооп совсем не нужен, более того он тут только мешать будет. Спарк уже есть, конечно, но для других задач, для этой он плохо подходит.
именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Gt_>>как бонус сумашедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит. MVK>А каким тут это боком? Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность. Максимум, что он сможет это правильно раскидать запросы на кластер, но когда я последний раз туда смотрел, там все было кривовато с этим.
а зрение давно проверял ? ты явно не на спарк смотрел. спарк ничего не транслиует, спарк вычитывает в свой датафрейм и вся магия происходит в его jvm. клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
MVK>Но в целом, если данные лежат в каком-то паркете на S3 кластере, то спарк, конечно хорош. Ну или если есть зоопарк различных баз и файлов, и задачи хорошо ложатcя на map reduce. Ну и скала довольно выразительна для таких задач тоже.
scala умирает уже достаточно давно, может даже уже и не живая.
вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf.
[]
КЛ>>во-первых, почему "получится так себе"? Во-вторых, если такой диалект поддерживается jooq, то это проблема не jooq. В общем, я не понял. MVK>Я посмотрел, что умеет jooq. Не очень понятно в чем будет выигрыш, при условии что мне нет необходимости вызывать sql из java. MVK>Бесспорно, полезная штука, если пилишь приложение, которому нужно ходить в базу, но для дата аналитических задач — только усложнит и удлинит процесс разработки.
я не настаиваю, но джук умеет делать реюз и довольно безопасную генерацию
КЛ>>так проверь MVK>Clickhouse поддержки нет на официальном сайте, но похоже идет работа в одном из форков.
то, чего нет, допишешь raw sql
КЛ>>если запросы типовые, то зачем его вообще писать? нужно его генерить по схеме с помощью jooq MVK>Я видимо плохо объяснил сценарий. Запросы аналитические, т.е. типовыми их не назовешь. Это не стандартный crud + проекции.
типовые не в смысле crud etc., а в смысле похожи друг на друга
Мда, апломба много, а знаний ноль.
Ну поехали...
Gt_>именно тут спарк идеален, ты просто совсем нулевый как я погляжу.
Боюсь, что нулевый у нас тут ты, судя по тому что ты пишешь.
Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана?
Или нужно объяснить?
Gt_>а зрение давно проверял ? ты явно не на спарк смотрел.
спишем хамство на твою невоспитанность
Gt_>спарк ничего не транслиует,
Да ладно?!
Открываем документацию и внимательно читаем про то как работают push downs и pruning
Также внимательно изучаем спецификацию DataSource V2
Также открываем для себя df.explain() и с изумлением смотрим на pushedFilters, pushedAggregates и даже pushedJoins
Gt_>спарк вычитывает в свой датафрейм
Еще одна глупость. Спарк как раз и был построен, чтобы можно было загрузку данных абстрагировать от логики расчетов.
1) Задумчиво читаем про RDD. Dataframe — это абстракция более высокого уровня построенная поверх RDD. С более-менее боевыми задачами на одних датафреймах не уедешь.
2) Ознакомившись с RDD внимательно читаем про то, что такое dataframe и в качестве продвинутого топика про catalyst.
Если на пальцах то пайплайн такой:
1. строиться логический план
2. план оптимизируется
3. строится физический план (тут как раз появляются push downs)
4. генерация кода
5. запуск
6. сбор результатов
Датафрейм — это не контейнер для данных.
При создании датафрейма и описания трансформаций никакой загрузки данных не происходит.
Gt_>и вся магия происходит в его jvm.
Чего?! какой еще "его jvm"? у спарка нет никакого "своего jvm".
Можно говорить, что для спарка будет лучше — грааль или хотспот — и в каких случаях.
Ну и с магией — это в Хогвартс. В спарке инженерно все понятно.
Gt_>клик для спарка просто тупой сторидж, мало чем отличающийся от S3.
Ну это же полная ахинея. Я даже не понимаю, с какого конца начать, чтобы объяснить.
Это как сказать, что для спарка Oracle — это как HDD
Ну еще можно было бы сказать для спарк не делает разницы между, скажем, parquet файлом на S3 и Clickhouse. Это, конечно, тоже бред, но намного меньший.
В этом случае можно просто открыть доку по различным коннекторам и обнаружить, что они, внезапно, предоставляют разные возможности и спарк с ними будет работать по разному. Опять таки, отсылаю к чтению спеки по DataSource V2
Gt_>scala умирает уже достаточно давно, может даже уже и не живая.
Держите меня семеро. А ничего, что сам спарк написан на скале и скала рекомендованный язык для спарка?
Для простых задач можно выжить с pyspark-ом, но на более-менее серьезном процессинге альтернативы Scala уже не будет. Можно, конечно, на java, но это прямо скажем так себе язык для работы с data. Ну и почитай еще что Захария пишет.
Gt_>вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf
Ты сейчас комментируешь какие-то свои иллюзии, а не то, что я писал. У меня логика не живет в udf, но лишь по той причине, что спарком я пользуюсь на скале.
А вот в питоне есть pandas udf, которые построены поверх apache arrow и если udf можно векторизировать, то будет работать очень шустро.
Поэтому и тут ты тоже плаваешь.
Суммируя:
Так громко и с размаху сесть в лужу — это надо постараться.
Поэтому иди и тренируйся на заднем дворе. Буду вопросы — приходи.
Не благодари
MVK>По работе приходится очень много писать SQL кода.
к счастью код пишется один раз. не стоит из-за этого заморачиваться. особенно если это ваша работа.
MVK>Пока написал кастомные команды к ideavim, но хотелось бы чего-то более умного. В идеале доступа к ast и схеме базы, и манипуляций с ним.
DSL нужен самописный вам.
Здравствуйте, Разраб, Вы писали:
Р>к счастью код пишется один раз. не стоит из-за этого заморачиваться. особенно если это ваша работа.
Работа — это в первую очередь результат. Поэтому чем быстрее я его достигну, тем лучше я делаю свою работу.
Ну и меня всегда раздражает, когда делаешь что-то, что нутром чувствуешь можно сделать более эффективно.
В общем я в задумчивости
Р>DSL нужен самописный вам.
Да, возможно выльется все в свой dsl. Но тут как обычно, dsl несложно написать, но сложно придумать.
Поэтому я и пошел пока по пути написания разносортных и несистемных макросов с надеждой, что накопив критическую массу таковых у меня начнет вырисовываться какая-то система, которая возможно и выльется в dsl, а возможно во что-то другое.
как же ноль, если их хватило постебаться над твоими базовыми познаниями и макнуть в твое "Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность". лихорадочные попытки почитать хоть что-то из туториала похвальны, но уйти от насмешек уже не выйдет. особливо после заявления, что ты спарк смотрел.
MVK>Одна вот эта фраза выдает полную неграмотность в вопросе: "как бонус сумасшедшая параллельность, которую клик думаю любит". Ты понимаешь, что у тебя полная бредятина написана? MVK>Или нужно объяснить?
о, давай. будет забавно посмотреть на потуги чудика который еще вчера считал, что спарк лишь передает запрос.
но сначала, давай все же зафиксируем базис: до тебя дошло, что спарк сам строит план, сам выполняет все вычисление, ничего в клик не транслируется ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, MaximVK, Вы писали:
MVK>>По работе приходится очень много писать SQL кода.
IT>Если речь про .NET, то сегодня писать SQL руками — это нонсенс. Тем более под разные диалекты SQL. linq2db и подобное всё это умеет и поддерживает в том числе всевозможные техники повторного использования кода.
У кого нонсенс, а у нас это обыденное явление. Я бы давно на ddd перешел, но от меня это не зависит.
MVK>По работе приходится очень много писать SQL кода.
MVK>Код довольно однообразен , например раздражает когда нужно для 10 метрик написать что-то типа (в синтаксисе кликзауз): MVK>select MVK> dim1, MVK> dim2, MVK> ... MVK> sumIf(metric0, isFinite(metric0)) as metric0, MVK> ... MVK> sumIf(metric9, isFinite(metriс9)) as metric9 MVK>group by MVK> dim1, MVK> dim3, MVK> ...
Пока непонятно, в чём именно однообразие. Вот эти вот sumIf(xxx, isFinite(xxx)) as xxx? Ну, напишите свой микро-DSL, который будет metric0.SumF() раскрывать в sumIf(metric0, isFinite(metric0)) as metric0.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
