Если он сам разбирается в связях 1:М или M:M, он таки выдумывает запросы, что бы это ни значило. Просто его API - он не настолько гибкий (ну если не считать написания SQL самому) чтобы он их выдумал не просто правильно, но и всегда эффективно.
Вы знаете, ужасные монолиты таки наверное существовали. Скажем, возьмем то, что называлось J2EE. Вот где-то до версии 3 создание модулей в этом фреймворке было сделано ужасно неудобно. Но даже в этом случае модули все равно всегда были, их можно было по отдельности деплоить, обновляя часть функциональности, запускать и останавливать.
Ну т.е. я могу в принципе представить, что кто-то, кто застал это краешком, считает что это и есть монолит, и что монолит это что-то ужасное. В то время как уже году к 2005 появились фрейморки и другие инструменты, которые сняли лишнюю когнитивную нагрузку с разработчиков, и модули стало писать если не совсем легко, то хоть быстро.
Остановите. Я бы с удовольствием на это посмотрел, только этого не будет скорее всего.
У меня был замечательный опыт, когда реализация задачи, выраженная тремя строками кода (задача тоже была сформулирована несложно и кратко) через три месяца в проме чуть не вызвала убытки. После чего приняли решение реализацию откатить, а аналитики ушли на подумать на еще три месяца.
Потому что вам выше сказали - в больших легаси системах никто не знает, где отвалится жопа, если на пузе отвинтить гайку. В моем случае были задействованы четыре системы в двух сетевых зонах, соединенные примерно тремя шинами. Каждая с логикой. И вы можете сколько угодно залезать в код этих семи систем (шины - они тоже системы), только вы все равно не поймете бизнес логики, которая находится в шести системах из семи.
Ну то есть, я бы в целом скорее согласился с изложенными в вашем тексте мыслями, но в данной ветке комментариев вас пытаются убедить, что не всегда так можно. Иногда никто не видит системы в целом, нет такого архитектора в компании.
Ну да, согласен. Но это не отменяет того факта, что автор пытается что-то объяснить по аналогии, при том что аналогии эти он берет из области, которую знает недостаточно хорошо. Да и вообще, если это пишется для начинающих, желающих изучить питон. Поможет ли им аналогия с java, которую они скорее всего тоже не знают, или только запутает?
Кроме того, выделение памяти не имеет в общем случае отношения к статической типизации. Тип-то вполне может быть статически известен, а память таки не выделена. Ну и про указатели ничего не сказано - а нужно.
Некоторые языки программирования, такие как Java, требуют указания типов переменных при их объявлении. При этом резервируется определенный объем памяти.
java уже много-много релизов как (с JDK 10, т.е. уже лет 6 как) не требует указания типов переменных при объявлении. И при этом никакой объем памяти (возможно) не резервируется.
С одной стороны, автор вроде бы пишет про питон, а в java не специалист. С другой стороны, когда я (специалист в java, и не очень специалист в питоне) пишу что-то про питон, я обычно это проверяю. Именно потому, что каждый день с этим не работаю.
Мораль - автор не удосуживается факт чекингом. Пытаясь упростить описание для начинающих, выбрасывает существенные вещи. Не советую.
Это вы просто привыкли. В реальности практически все языки, на которых можно писать хранимые процедуры - достаточно старые, и не самые удобные на сегодня, как инструменты для написания кода. И всяких странных ограничений из прошлого они тащат с собой прилично.
Если исходные данные в базе и результат в базе
В том-то и дело, что так бывает, но далеко не всегда. А как только у вас исходные данные - какой-нибудь поток из кафки, и несколько разных баз, и еще приложения с их API, и т.п. И что значит, не брать обработку изображений, если это большой кусок интересных и нужных задач (особенно если ИИ и итд включить)?
И попробуйте вот такое написать на T-SQL? Вам сразу приходится тащить другой язык, скажем c# или java или питон, а как только вы его притащили - писать на нем сильно проще, чем на том, что умеет типовая СУБД.
Ну то есть, эти оптимизации - они на уровне кода функции, скажем так? Т.е. это не оптимизация нашего плана, в виде скажем проталкивания предикатов (потому что предикат в форме Catalyst Expression все равно не сильно-то протолкнешь). Хотя в теории, если оптимизатор знает структуру выражения, то он его может попытаться пропихнуть и в JDBC источник, и в паркет (с ограничениями, разумеется).
этот факт делал нецелесообразным "обертывания" существующих функций в Catalyst Expression
Ну погодите, каталист же вряд ли многое понимает о нашем/вашем Java коде. И уж тем более о коде функций, которые взяты из существующих классов. Да и какие физические оптимизации ему даст это знание? Ну т.е. какие свойства выражений каталист позволяют применять к ним те оптимизации, которые нельзя применять к UDF, и что это за оптимизации?
мне кажется это устареет с широким внедрением Connect. По-моему они даже бросили его поддерживать уже. Да собственно, последний спарк там 3.2, он не то чтобы старый, мы на таком и работаем, но далеко не самый последний.
Насколько я помню - нет. Но - спарк 3.4 привнес Spark Connect - это API, сделанный с целью поддержать другие языки. Сами авторы ничего кроме стандартных Java Scala и Python c R не поддержали, но написать реализацию вроде можно. Для JVM based Scala 3 - уж наверняка. Т.е. у вас будет Dataset, скажем просто.
Ну как бы, в коде очень редко есть ответы на вопросы "нахрена". Сам код обычно является ответом на то, что он делает, но почему решение то а не другое - в коде не написано (как и самого другого решения обычно нет - оно осталось в голове у того, кто писал). При достаточно глубоком копании это все всплывет, во-первых, а во-вторых, чтобы хорошо разобраться, тоже нужно прилично времени потратить - и уже непонятно, не проще ли было самому написать задание?
Не, погодите. Вы говорите про вариант, когда у вас есть работа, и речь идет о повышении. А я говорю о варианте, когда у вас нет опыта и работы, и речь о том, чтобы опыта набраться. Оба варианта могут иметь место, но они оба разные.
Не, ну у молодых и начинающих могут быть варианты. Если вас взяли с двадцатой попытки в приличное место, деньги для вас возможно не будут самым важным, опыт получить может оказаться важнее. Но для человека с опытом ответ "денег" если не единственный, то самый ожидаемый точно.
Если он сам разбирается в связях 1:М или M:M, он таки выдумывает запросы, что бы это ни значило. Просто его API - он не настолько гибкий (ну если не считать написания SQL самому) чтобы он их выдумал не просто правильно, но и всегда эффективно.
Вы знаете, ужасные монолиты таки наверное существовали. Скажем, возьмем то, что называлось J2EE. Вот где-то до версии 3 создание модулей в этом фреймворке было сделано ужасно неудобно. Но даже в этом случае модули все равно всегда были, их можно было по отдельности деплоить, обновляя часть функциональности, запускать и останавливать.
Ну т.е. я могу в принципе представить, что кто-то, кто застал это краешком, считает что это и есть монолит, и что монолит это что-то ужасное. В то время как уже году к 2005 появились фрейморки и другие инструменты, которые сняли лишнюю когнитивную нагрузку с разработчиков, и модули стало писать если не совсем легко, то хоть быстро.
Во многих случаях - да, невозможно. Во всяком случае быстрого простого способа выхода нет.
Остановите. Я бы с удовольствием на это посмотрел, только этого не будет скорее всего.
У меня был замечательный опыт, когда реализация задачи, выраженная тремя строками кода (задача тоже была сформулирована несложно и кратко) через три месяца в проме чуть не вызвала убытки. После чего приняли решение реализацию откатить, а аналитики ушли на подумать на еще три месяца.
Потому что вам выше сказали - в больших легаси системах никто не знает, где отвалится жопа, если на пузе отвинтить гайку. В моем случае были задействованы четыре системы в двух сетевых зонах, соединенные примерно тремя шинами. Каждая с логикой. И вы можете сколько угодно залезать в код этих семи систем (шины - они тоже системы), только вы все равно не поймете бизнес логики, которая находится в шести системах из семи.
Ну то есть, я бы в целом скорее согласился с изложенными в вашем тексте мыслями, но в данной ветке комментариев вас пытаются убедить, что не всегда так можно. Иногда никто не видит системы в целом, нет такого архитектора в компании.
Ну да, согласен. Но это не отменяет того факта, что автор пытается что-то объяснить по аналогии, при том что аналогии эти он берет из области, которую знает недостаточно хорошо. Да и вообще, если это пишется для начинающих, желающих изучить питон. Поможет ли им аналогия с java, которую они скорее всего тоже не знают, или только запутает?
Кроме того, выделение памяти не имеет в общем случае отношения к статической типизации. Тип-то вполне может быть статически известен, а память таки не выделена. Ну и про указатели ничего не сказано - а нужно.
java уже много-много релизов как (с JDK 10, т.е. уже лет 6 как) не требует указания типов переменных при объявлении. И при этом никакой объем памяти (возможно) не резервируется.
С одной стороны, автор вроде бы пишет про питон, а в java не специалист. С другой стороны, когда я (специалист в java, и не очень специалист в питоне) пишу что-то про питон, я обычно это проверяю. Именно потому, что каждый день с этим не работаю.
Мораль - автор не удосуживается факт чекингом. Пытаясь упростить описание для начинающих, выбрасывает существенные вещи. Не советую.
По-моему, вот ваш случай: https://issues.apache.org/jira/browse/SPARK-29497
Я знаю. Мне пришлось 3.5 года совмещать :)
Так я не говорю что он маленький. Я скорее утверждаю, что других задач становится все больше.
Это вы просто привыкли. В реальности практически все языки, на которых можно писать хранимые процедуры - достаточно старые, и не самые удобные на сегодня, как инструменты для написания кода. И всяких странных ограничений из прошлого они тащат с собой прилично.
В том-то и дело, что так бывает, но далеко не всегда. А как только у вас исходные данные - какой-нибудь поток из кафки, и несколько разных баз, и еще приложения с их API, и т.п. И что значит, не брать обработку изображений, если это большой кусок интересных и нужных задач (особенно если ИИ и итд включить)?
И попробуйте вот такое написать на T-SQL? Вам сразу приходится тащить другой язык, скажем c# или java или питон, а как только вы его притащили - писать на нем сильно проще, чем на том, что умеет типовая СУБД.
так чтобы можно было обратно пришить/приклеить?
Ну то есть, эти оптимизации - они на уровне кода функции, скажем так? Т.е. это не оптимизация нашего плана, в виде скажем проталкивания предикатов (потому что предикат в форме Catalyst Expression все равно не сильно-то протолкнешь). Хотя в теории, если оптимизатор знает структуру выражения, то он его может попытаться пропихнуть и в JDBC источник, и в паркет (с ограничениями, разумеется).
>Берем на школьной скамье, и начинаем учить.
Это план не универсальный. Не у всех есть время на такое.
Ну ради объективности, улицы в Зеленограде таки есть, и есть дома на них. А есть дома без улиц, только с номерами.
Ну погодите, каталист же вряд ли многое понимает о нашем/вашем Java коде. И уж тем более о коде функций, которые взяты из существующих классов. Да и какие физические оптимизации ему даст это знание? Ну т.е. какие свойства выражений каталист позволяют применять к ним те оптимизации, которые нельзя применять к UDF, и что это за оптимизации?
мне кажется это устареет с широким внедрением Connect. По-моему они даже бросили его поддерживать уже. Да собственно, последний спарк там 3.2, он не то чтобы старый, мы на таком и работаем, но далеко не самый последний.
Насколько я помню - нет. Но - спарк 3.4 привнес Spark Connect - это API, сделанный с целью поддержать другие языки. Сами авторы ничего кроме стандартных Java Scala и Python c R не поддержали, но написать реализацию вроде можно. Для JVM based Scala 3 - уж наверняка. Т.е. у вас будет Dataset, скажем просто.
Ну как бы, в коде очень редко есть ответы на вопросы "нахрена". Сам код обычно является ответом на то, что он делает, но почему решение то а не другое - в коде не написано (как и самого другого решения обычно нет - оно осталось в голове у того, кто писал). При достаточно глубоком копании это все всплывет, во-первых, а во-вторых, чтобы хорошо разобраться, тоже нужно прилично времени потратить - и уже непонятно, не проще ли было самому написать задание?
Не, погодите. Вы говорите про вариант, когда у вас есть работа, и речь идет о повышении. А я говорю о варианте, когда у вас нет опыта и работы, и речь о том, чтобы опыта набраться. Оба варианта могут иметь место, но они оба разные.
Не, ну у молодых и начинающих могут быть варианты. Если вас взяли с двадцатой попытки в приличное место, деньги для вас возможно не будут самым важным, опыт получить может оказаться важнее. Но для человека с опытом ответ "денег" если не единственный, то самый ожидаемый точно.