Минимальный объектный маппер для SQL пишется за два рабочих дня. Потому что в рамках любого отдельно взятого проекта используется от силы 10% от всей функциональности, которую с собой тащит комбайн типа Хибернейта. Остальное нафиг не нужно, но проблемы, типа описанной в посте, создаёт.
Я как бы не один год провёл в кровавом ынтерпрайзе, и писал их много раз, так что знаю, что советую =)
Просто не юзать в проде никаких general purpose средств для скаффолдинга чего бы то ни было. Вот так вот — совсем не юзать этот класс инструментов, включая любые «общие» ORM, от слова вообще.
Для быстрого прототипирования — не возбраняется. Они идеально для этого подходят, потому что пытаются охватывать все кейсы на свете, но при этом не заточены ни под один реальный кейс. Но для прода пишите минимальные имплементации, специализированные под ваши задачи, сами.
Четырёхкрылые «птицы» таки существовали — правда, в ином отряде динозавров (дромеозавриды; гуглить по ключевому слову «микрораптор»), нежели выжившие до сего дня.
Тю-ю-ю... ЯП вообще-то ни разу не про синтаксис (потому что подавляющее большинство из них имеют равномощный набор синтаксических конструкций, и отличаются только формой), а про семантику — в которой и заключается основная ценность.
Настоящий «язык» для программиста — это конкретные API и библиотеки, определяющие глаголы (функции, методы, процедуры, лямбды), существительные (объекты, хэндлы, указатели, и т.п.), и правила построения осмысленных предложений из них. Которые могут быть кардинально разными для одного и того же ЯП.
На T+00:47:00 что-то пошло не по плану — знатно бахнуло где-то рядом с движками. Видимо, утечки в кормовом отсеке пофиксили не до конца. Из-за этого один из хвостовых стабилизаторов, который задело осколками, опять хорошенько пригорел.
Но даже так эпическая бандура из нержавейки наконец-то выполнила всю программу.
Легко поверю, если дело было до начала 2010-х в Германии, Австрии, или той же Чехии. Там система нострификации существует очень давно.
А вот после, и особенно в иных странах — рекрутёры отдают явное предпочтение кандидатам с понятными дипломами. Что логично. Какой смысл заморачиваться с нострификацией, если можно просто взять человека с заведомо валидной корочкой? В конце концов, в 2017 году, когда я последний раз попытался прособеседоваться на сеньорскую позицию в зарубежный бигтех (в Нидерландах, Ирландии, и UK), мне прямо так открытым текстом и сказали: чел, тут у нас кандидаты после магистратуры, а у тебя по академическому эквиваленту непонятно что.
Так оно и есть. У меня куча знакомых и бывших коллег, закончивших вуз в середине 2000-х и позже, которые без каких либо проблем подтвердили свои дипломы в Европе. К ним у иностранных HR вообще никаких вопросов не возникает.
Я же, получивший в 2003 диплом специалиста, из-за него несколько раз получал от ворот поворот, потому что это филькина грамота, которую ещё подтверждать надо. По крайней мере, субподрядчикам Гугла и Амазона (куда я собеседовался), этим заниматься не захотелось.
Цель очевидна же — снова сделать дипломы российских вузов неконвертируемыми за рубежом. Чтобы как во времена развитого социализма, если получил местный диплом, то вот и работай в стране получения.
Болонская система предполагает эквивалентность уровней образования, как-никак. А нужно, чтобы было строго никак.
Из этого и рождаются лучшие решения, принятые совместно.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Датасет уже записан с партицироваем
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
ETL-скрипты у нас все на SQL, а обвязка для запуска ETL stages и сборки финальных отчётов — на питоне. Каждый проект это отдельный гитовый репозиторий, в котором лежит и то и другое. Общие вещи кочуют из проекта в проект, а что-то особенно полезное выносится в сборник best practices.
Короче, довольно хаотично, но аналитикам так удобнее, а я в их кухню не лезу. Моё дело инструменты предоставлять.
Касательно алгоритмики на Java — она довольно давно уже стабильная, последний раз я имплементировал что-то новое года 4 назад. И то не с питона, а прямо по вайтпейперу.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Это с какого перепугу в пять раз?
Минимальный объектный маппер для SQL пишется за два рабочих дня. Потому что в рамках любого отдельно взятого проекта используется от силы 10% от всей функциональности, которую с собой тащит комбайн типа Хибернейта. Остальное нафиг не нужно, но проблемы, типа описанной в посте, создаёт.
Я как бы не один год провёл в кровавом ынтерпрайзе, и писал их много раз, так что знаю, что советую =)
Не юзать Hibernate в проде.
Просто не юзать в проде никаких general purpose средств для скаффолдинга чего бы то ни было. Вот так вот — совсем не юзать этот класс инструментов, включая любые «общие» ORM, от слова вообще.
Для быстрого прототипирования — не возбраняется. Они идеально для этого подходят, потому что пытаются охватывать все кейсы на свете, но при этом не заточены ни под один реальный кейс. Но для прода пишите минимальные имплементации, специализированные под ваши задачи, сами.
Четырёхкрылые «птицы» таки существовали — правда, в ином отряде динозавров (дромеозавриды; гуглить по ключевому слову «микрораптор»), нежели выжившие до сего дня.
Тю-ю-ю... ЯП вообще-то ни разу не про синтаксис (потому что подавляющее большинство из них имеют равномощный набор синтаксических конструкций, и отличаются только формой), а про семантику — в которой и заключается основная ценность.
Настоящий «язык» для программиста — это конкретные API и библиотеки, определяющие глаголы (функции, методы, процедуры, лямбды), существительные (объекты, хэндлы, указатели, и т.п.), и правила построения осмысленных предложений из них. Которые могут быть кардинально разными для одного и того же ЯП.
На T+00:47:00 что-то пошло не по плану — знатно бахнуло где-то рядом с движками. Видимо, утечки в кормовом отсеке пофиксили не до конца. Из-за этого один из хвостовых стабилизаторов, который задело осколками, опять хорошенько пригорел.
Но даже так эпическая бандура из нержавейки наконец-то выполнила всю программу.
Не каждый год заходите? А как вы тогда комментируете что-нибудь почти каждый день? При помощи святого духа?
Субъективное восприятие отлично показывает, что все такие ограничения ни фига не работают.
Легко поверю, если дело было до начала 2010-х в Германии, Австрии, или той же Чехии. Там система нострификации существует очень давно.
А вот после, и особенно в иных странах — рекрутёры отдают явное предпочтение кандидатам с понятными дипломами. Что логично. Какой смысл заморачиваться с нострификацией, если можно просто взять человека с заведомо валидной корочкой? В конце концов, в 2017 году, когда я последний раз попытался прособеседоваться на сеньорскую позицию в зарубежный бигтех (в Нидерландах, Ирландии, и UK), мне прямо так открытым текстом и сказали: чел, тут у нас кандидаты после магистратуры, а у тебя по академическому эквиваленту непонятно что.
Так оно и есть. У меня куча знакомых и бывших коллег, закончивших вуз в середине 2000-х и позже, которые без каких либо проблем подтвердили свои дипломы в Европе. К ним у иностранных HR вообще никаких вопросов не возникает.
Я же, получивший в 2003 диплом специалиста, из-за него несколько раз получал от ворот поворот, потому что это филькина грамота, которую ещё подтверждать надо. По крайней мере, субподрядчикам Гугла и Амазона (куда я собеседовался), этим заниматься не захотелось.
Батенька, а вы вообще в курсе, что Болонский процесс как таковой начался только в 1999 году?
Ой да неужели. И сколько же вы своих дипломов советского образца смогли успешно нострифицировать в какой-нибудь Германии?
Цель очевидна же — снова сделать дипломы российских вузов неконвертируемыми за рубежом. Чтобы как во времена развитого социализма, если получил местный диплом, то вот и работай в стране получения.
Болонская система предполагает эквивалентность уровней образования, как-никак. А нужно, чтобы было строго никак.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
...и они, кстати, нахрен сейчас никому не нужны :( Потому что с рынка их берут только в стартапы на самом раннем этапе. Но какие сейчас стартапы?
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
ETL-скрипты у нас все на SQL, а обвязка для запуска ETL stages и сборки финальных отчётов — на питоне. Каждый проект это отдельный гитовый репозиторий, в котором лежит и то и другое. Общие вещи кочуют из проекта в проект, а что-то особенно полезное выносится в сборник best practices.
Короче, довольно хаотично, но аналитикам так удобнее, а я в их кухню не лезу. Моё дело инструменты предоставлять.
Касательно алгоритмики на Java — она довольно давно уже стабильная, последний раз я имплементировал что-то новое года 4 назад. И то не с питона, а прямо по вайтпейперу.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Батенька, я три года отсеньорил в епаме на банковских проектах, а потом мне как-то довелось поревьюить то, что пишут в ростелекоме для госов.
Так индусы пишут в разы лучше, чем то, на чём всякие сберы и госуслуги в этой стране сделаны.