Легко поверю, если дело было до начала 2010-х в Германии, Австрии, или той же Чехии. Там система нострификации существует очень давно.
А вот после, и особенно в иных странах — рекрутёры отдают явное предпочтение кандидатам с понятными дипломами. Что логично. Какой смысл заморачиваться с нострификацией, если можно просто взять человека с заведомо валидной корочкой? В конце концов, в 2017 году, когда я последний раз попытался прособеседоваться на сеньорскую позицию в зарубежный бигтех (в Нидерландах, Ирландии, и UK), мне прямо так открытым текстом и сказали: чел, тут у нас кандидаты после магистратуры, а у тебя по академическому эквиваленту непонятно что.
Так оно и есть. У меня куча знакомых и бывших коллег, закончивших вуз в середине 2000-х и позже, которые без каких либо проблем подтвердили свои дипломы в Европе. К ним у иностранных HR вообще никаких вопросов не возникает.
Я же, получивший в 2003 диплом специалиста, из-за него несколько раз получал от ворот поворот, потому что это филькина грамота, которую ещё подтверждать надо. По крайней мере, субподрядчикам Гугла и Амазона (куда я собеседовался), этим заниматься не захотелось.
Цель очевидна же — снова сделать дипломы российских вузов неконвертируемыми за рубежом. Чтобы как во времена развитого социализма, если получил местный диплом, то вот и работай в стране получения.
Болонская система предполагает эквивалентность уровней образования, как-никак. А нужно, чтобы было строго никак.
Из этого и рождаются лучшие решения, принятые совместно.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Датасет уже записан с партицироваем
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
ETL-скрипты у нас все на SQL, а обвязка для запуска ETL stages и сборки финальных отчётов — на питоне. Каждый проект это отдельный гитовый репозиторий, в котором лежит и то и другое. Общие вещи кочуют из проекта в проект, а что-то особенно полезное выносится в сборник best practices.
Короче, довольно хаотично, но аналитикам так удобнее, а я в их кухню не лезу. Моё дело инструменты предоставлять.
Касательно алгоритмики на Java — она довольно давно уже стабильная, последний раз я имплементировал что-то новое года 4 назад. И то не с питона, а прямо по вайтпейперу.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Не очень понятна причина такой тряски. Вполне обычная энтерпрайзная лапша, даже с некоторыми довольно остроумными находками. (Ну, разве что WS и RS в одних и тех же бинах смешивать действительно не стоит. Но я лично и похуже вещи в продакшене видал.)
И тот факт, что в столь разных серверах, имплементирующих все эти J### стандарты по-своему, такое густо намазанное высокоуровневой метой безобразие заводится с минимальной доводкой, должен радовать, и очень даже сильно. Работает ведь? Ну так в чём проблема? Обычно всё-таки вендорлок куда сильнее выражен.
А что касается бытового расизма в отношении индусов, то вас он совсем не красит.
тогда должны знать, что гранты выдают очень разные фонды (коммерческие, некоммерческие, государственные, частные, и т.д.) на совершенно разных условиях (например: разработка продукта с нуля, коммерциализация существующего продукта, поддержка инновации, внедрение технологии, и т.п.).
вообще, никому не советую делать далеко идущих conjectures на основе неполной информации. вы ведь понятия не имеете, какие именно вводные были у нас (а раскрывать их я, конечно же, не буду — не имею права). но покритиковать очень хочется, да?
грант был выдан с конкретной темой: «разработка инструмента для ETL». цель достигнута, инструмент успешно разработан. более того, выложен в открытый доступ: https://github.com/PastorGL/datacooker-etl — кто угодно может брать и пользоваться.
а бизнес-модель конторы, в которой он внедрён, это дело только самой конторы. вы вообще в курсе, как и на что выдаются гранты?
Не каждый год заходите? А как вы тогда комментируете что-нибудь почти каждый день? При помощи святого духа?
Субъективное восприятие отлично показывает, что все такие ограничения ни фига не работают.
Легко поверю, если дело было до начала 2010-х в Германии, Австрии, или той же Чехии. Там система нострификации существует очень давно.
А вот после, и особенно в иных странах — рекрутёры отдают явное предпочтение кандидатам с понятными дипломами. Что логично. Какой смысл заморачиваться с нострификацией, если можно просто взять человека с заведомо валидной корочкой? В конце концов, в 2017 году, когда я последний раз попытался прособеседоваться на сеньорскую позицию в зарубежный бигтех (в Нидерландах, Ирландии, и UK), мне прямо так открытым текстом и сказали: чел, тут у нас кандидаты после магистратуры, а у тебя по академическому эквиваленту непонятно что.
Так оно и есть. У меня куча знакомых и бывших коллег, закончивших вуз в середине 2000-х и позже, которые без каких либо проблем подтвердили свои дипломы в Европе. К ним у иностранных HR вообще никаких вопросов не возникает.
Я же, получивший в 2003 диплом специалиста, из-за него несколько раз получал от ворот поворот, потому что это филькина грамота, которую ещё подтверждать надо. По крайней мере, субподрядчикам Гугла и Амазона (куда я собеседовался), этим заниматься не захотелось.
Батенька, а вы вообще в курсе, что Болонский процесс как таковой начался только в 1999 году?
Ой да неужели. И сколько же вы своих дипломов советского образца смогли успешно нострифицировать в какой-нибудь Германии?
Цель очевидна же — снова сделать дипломы российских вузов неконвертируемыми за рубежом. Чтобы как во времена развитого социализма, если получил местный диплом, то вот и работай в стране получения.
Болонская система предполагает эквивалентность уровней образования, как-никак. А нужно, чтобы было строго никак.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
...и они, кстати, нахрен сейчас никому не нужны :( Потому что с рынка их берут только в стартапы на самом раннем этапе. Но какие сейчас стартапы?
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
ETL-скрипты у нас все на SQL, а обвязка для запуска ETL stages и сборки финальных отчётов — на питоне. Каждый проект это отдельный гитовый репозиторий, в котором лежит и то и другое. Общие вещи кочуют из проекта в проект, а что-то особенно полезное выносится в сборник best practices.
Короче, довольно хаотично, но аналитикам так удобнее, а я в их кухню не лезу. Моё дело инструменты предоставлять.
Касательно алгоритмики на Java — она довольно давно уже стабильная, последний раз я имплементировал что-то новое года 4 назад. И то не с питона, а прямо по вайтпейперу.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Батенька, я три года отсеньорил в епаме на банковских проектах, а потом мне как-то довелось поревьюить то, что пишут в ростелекоме для госов.
Так индусы пишут в разы лучше, чем то, на чём всякие сберы и госуслуги в этой стране сделаны.
Не очень понятна причина такой тряски. Вполне обычная энтерпрайзная лапша, даже с некоторыми довольно остроумными находками. (Ну, разве что WS и RS в одних и тех же бинах смешивать действительно не стоит. Но я лично и похуже вещи в продакшене видал.)
И тот факт, что в столь разных серверах, имплементирующих все эти J### стандарты по-своему, такое густо намазанное высокоуровневой метой безобразие заводится с минимальной доводкой, должен радовать, и очень даже сильно. Работает ведь? Ну так в чём проблема? Обычно всё-таки вендорлок куда сильнее выражен.
А что касается бытового расизма в отношении индусов, то вас он совсем не красит.
а вы почитайте исходники dataframe api, сразу станет понятно.
если кратко, то это «подход №1» со всем его оверхедом.
тогда должны знать, что гранты выдают очень разные фонды (коммерческие, некоммерческие, государственные, частные, и т.д.) на совершенно разных условиях (например: разработка продукта с нуля, коммерциализация существующего продукта, поддержка инновации, внедрение технологии, и т.п.).
вообще, никому не советую делать далеко идущих conjectures на основе неполной информации. вы ведь понятия не имеете, какие именно вводные были у нас (а раскрывать их я, конечно же, не буду — не имею права). но покритиковать очень хочется, да?
я что-то не догоняю причин вашего негодования.
грант был выдан с конкретной темой: «разработка инструмента для ETL». цель достигнута, инструмент успешно разработан. более того, выложен в открытый доступ: https://github.com/PastorGL/datacooker-etl — кто угодно может брать и пользоваться.
а бизнес-модель конторы, в которой он внедрён, это дело только самой конторы. вы вообще в курсе, как и на что выдаются гранты?
одно другому не мешает. или вы думаете, что все гранты должны тупо проедаться без реального выхлопа?
я вот вполне себе (то есть нам) нормальный продукт написал.