А причем тут Spark SQL? Если знать что под капотом творится, какая разница на чем писать? А если не знаешь, то и на Python/Scala хрень можно написать. Что за высокомерие?
Тем более что SQL более понятен аналитикам, бизнесу его дешевле поддерживать, поэтому я чаще всего на проектах слышу от бизнеса требование код писать на SQL. В 99% случаев можно спокойно им обойтись. А для остальных редких случаев можно почитать spark internals, либо в исходники залезть.
Что от статьи, что от первых комментариев несёт каким-то высокомерием и пижонством, особенно про собеседования. Все вокруг тупые, один вы Д'артаньян
Небольшое замечание: собираете результаты с помощью функции toPandas() может быть конкретно вы в вашем случае, но это далеко не самая широко используемая функция. Это ещё pandas должен быть установлен. По умолчанию используется родная функция collect()
Какой-то странный довод для аргументации архитектуры системы/хранилища. Может разработчик всё-таки не будет что-то там делать "на глаз", "на память" и т.д. и т.п. Или может он просто хреновый разработчик?
Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
Да, давайте расскажите нам о способах оптимизации запроса для SQLite на таблице из 5 строк. Оптимизация запросов на сферических в вакууме примерах абсолютно бесполезный труд.
Мое мнение - оптимизацией запроса нужно заниматься когда это действительно нужно. Это зависит от множества факторов таких как: конкретная СУБД, конкретные данные, модель данных, индексы, паралеллизм, оптимизатор в субд, план запроса и т.д. и т.п. А до тех пор пока такой задачи не стоит - а у нас тут нет ничего, только задачка в вакууме - нужно писать как можно проще и понятнее.
Right join - абсолютно бесполезная вещь, которая только сбивает с толку. Нет такого right join который бы нельзя было бы заменить на left join. Поэтому принято использовать left join - он более интуитивно понятен. Погуглите различные "SQL style guide" от топовых компаний, в них зачастую вообще явный запрет на использование right join.
В 3.1. я бы не стал использовать подзапрос и right join. Писать rigth join - вообще плохой тон. Это решается проще и читается легче:
select c.name as contractor, sum(op.summa) as summa
from operation op
left join contractor c on c.id_contr = op.id_contr
group by c.name
order by 1 nulls last
Тут англоязычных то ресурсов мало, а вы хотите на русском. На английском рекомендую аналог leetcode только для SQL: https://www.stratascratch.com/
И советую сразу учиться форматировать SQL-код, если уж вы выносите их на всеобщее обозрение - ваши запросы плохо читаются.
Сейчас в самом простом блокноте есть плагины и подсветка синтаксиса. Я сам пишу SQL в SublimeText. И мне тоже не нужны монструозные IDE для этого. Так что это такой себе аргумент.
Объясните мне, зачем в 21 веке, когда есть миллион разных IDE, которые умеют подсвечивать SQL-код, писать служебные слова в Upper-case? Я помню так писали, когда не было нормальных IDE. Но сейчас то зачем??? Когда я вижу такой код, мне сразу вспоминается мой 386 комп и BASIC.
Всю статью можно свести к одной фразе автора:
и дальше можно не читать
Hadoop, Cloudera, Hortonworks - это точно статья из 2025 года?
Как может человека претендующего на архитектора напугать код на C++? Либо вы пишете ерунду, либо выросло такое поколение архитекторов.
Всю статью можно заменить одной ссылкой ss64.com
Какой ещё NoSQL? Вы бы хоть почитали сначала что это за СУБД, прежде чем писать статьи.
А причем тут Spark SQL? Если знать что под капотом творится, какая разница на чем писать? А если не знаешь, то и на Python/Scala хрень можно написать. Что за высокомерие?
Тем более что SQL более понятен аналитикам, бизнесу его дешевле поддерживать, поэтому я чаще всего на проектах слышу от бизнеса требование код писать на SQL. В 99% случаев можно спокойно им обойтись. А для остальных редких случаев можно почитать spark internals, либо в исходники залезть.
Что от статьи, что от первых комментариев несёт каким-то высокомерием и пижонством, особенно про собеседования. Все вокруг тупые, один вы Д'артаньян
Небольшое замечание: собираете результаты с помощью функции toPandas() может быть конкретно вы в вашем случае, но это далеко не самая широко используемая функция. Это ещё pandas должен быть установлен. По умолчанию используется родная функция collect()
Вы назвали Apache Spark узкоспециализированным навыком, востребованным только в считанных компаниях или я ошибаюсь?
Какой-то странный довод для аргументации архитектуры системы/хранилища. Может разработчик всё-таки не будет что-то там делать "на глаз", "на память" и т.д. и т.п. Или может он просто хреновый разработчик?
Под windows пока лучше чем связка Conemu + Far не нашёл
Сейчас бы судить об экономике по производству вооружения. То что людям жрать нечего - это ерунда, главное что снарядов много.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
Да, давайте расскажите нам о способах оптимизации запроса для SQLite на таблице из 5 строк. Оптимизация запросов на сферических в вакууме примерах абсолютно бесполезный труд.
Планы где? В какой СУБД и на какой версии? На каких данных? В задачах не указано ничего кроме условия задачи. Какой может быть план?
Мое мнение - оптимизацией запроса нужно заниматься когда это действительно нужно. Это зависит от множества факторов таких как: конкретная СУБД, конкретные данные, модель данных, индексы, паралеллизм, оптимизатор в субд, план запроса и т.д. и т.п. А до тех пор пока такой задачи не стоит - а у нас тут нет ничего, только задачка в вакууме - нужно писать как можно проще и понятнее.
Right join - абсолютно бесполезная вещь, которая только сбивает с толку. Нет такого right join который бы нельзя было бы заменить на left join. Поэтому принято использовать left join - он более интуитивно понятен. Погуглите различные "SQL style guide" от топовых компаний, в них зачастую вообще явный запрет на использование right join.
В 3.1. я бы не стал использовать подзапрос и right join. Писать rigth join - вообще плохой тон. Это решается проще и читается легче:
Тут англоязычных то ресурсов мало, а вы хотите на русском. На английском рекомендую аналог leetcode только для SQL: https://www.stratascratch.com/
И советую сразу учиться форматировать SQL-код, если уж вы выносите их на всеобщее обозрение - ваши запросы плохо читаются.
Константы != Служебные слова.
Второе встречается гораздо чаще.
Напомните, в каком языке до сих пор принято писать служебные слова в верхнем регистре?
Сейчас в самом простом блокноте есть плагины и подсветка синтаксиса. Я сам пишу SQL в SublimeText. И мне тоже не нужны монструозные IDE для этого. Так что это такой себе аргумент.
Мой вопрос был к тем, кто аргументирует это так, цитирую: "чтобы служебные слова сразу бросались в глаза".
В других языках давно от такого отошли, с развитием IDE.
Никто конечно вам не запрещает, если так нравится.
Как по мне - это неудобно и некрасиво.
Объясните мне, зачем в 21 веке, когда есть миллион разных IDE, которые умеют подсвечивать SQL-код, писать служебные слова в Upper-case? Я помню так писали, когда не было нормальных IDE. Но сейчас то зачем??? Когда я вижу такой код, мне сразу вспоминается мой 386 комп и BASIC.