Цель очевидна же — снова сделать дипломы российских вузов неконвертируемыми за рубежом. Чтобы как во времена развитого социализма, если получил местный диплом, то вот и работай в стране получения.
Болонская система предполагает эквивалентность уровней образования, как-никак. А нужно, чтобы было строго никак.
Из этого и рождаются лучшие решения, принятые совместно.
Булшит какой-то.
Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
А если каждый раз вместо принятия оптимального решения, основанного на опыте, надо заниматься доказательством того, что твой опыт никуда не подевался, то нафига вообще в таком случае эксперту у вас работать? Это уже не корпоративная культура, а сектантство.
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Датасет уже записан с партицироваем
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
ETL-скрипты у нас все на SQL, а обвязка для запуска ETL stages и сборки финальных отчётов — на питоне. Каждый проект это отдельный гитовый репозиторий, в котором лежит и то и другое. Общие вещи кочуют из проекта в проект, а что-то особенно полезное выносится в сборник best practices.
Короче, довольно хаотично, но аналитикам так удобнее, а я в их кухню не лезу. Моё дело инструменты предоставлять.
Касательно алгоритмики на Java — она довольно давно уже стабильная, последний раз я имплементировал что-то новое года 4 назад. И то не с питона, а прямо по вайтпейперу.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Не очень понятна причина такой тряски. Вполне обычная энтерпрайзная лапша, даже с некоторыми довольно остроумными находками. (Ну, разве что WS и RS в одних и тех же бинах смешивать действительно не стоит. Но я лично и похуже вещи в продакшене видал.)
И тот факт, что в столь разных серверах, имплементирующих все эти J### стандарты по-своему, такое густо намазанное высокоуровневой метой безобразие заводится с минимальной доводкой, должен радовать, и очень даже сильно. Работает ведь? Ну так в чём проблема? Обычно всё-таки вендорлок куда сильнее выражен.
А что касается бытового расизма в отношении индусов, то вас он совсем не красит.
тогда должны знать, что гранты выдают очень разные фонды (коммерческие, некоммерческие, государственные, частные, и т.д.) на совершенно разных условиях (например: разработка продукта с нуля, коммерциализация существующего продукта, поддержка инновации, внедрение технологии, и т.п.).
вообще, никому не советую делать далеко идущих conjectures на основе неполной информации. вы ведь понятия не имеете, какие именно вводные были у нас (а раскрывать их я, конечно же, не буду — не имею права). но покритиковать очень хочется, да?
грант был выдан с конкретной темой: «разработка инструмента для ETL». цель достигнута, инструмент успешно разработан. более того, выложен в открытый доступ: https://github.com/PastorGL/datacooker-etl — кто угодно может брать и пользоваться.
а бизнес-модель конторы, в которой он внедрён, это дело только самой конторы. вы вообще в курсе, как и на что выдаются гранты?
Принципы профилирования за 25 лет не поменялись, а профайлер сейчас прямо в браузер встроен. Последний раз я такое делал под IE7 (надо было отображать/фильтровать/сортировать табличку на 10к ячеек), тогда приходилось цепляться из вижуалстудии, было неудобно.
Я почти 10 лет занимался веб-разработкой. Правда, начинал ещё с Perl/CGI. Такие очень древние технологии, когда для ускорения бэка приходилось писать поначалу модули на сях, а для фронта — аплеты на допотопной жабе. Потом какое-то время у меня был хайлоад на оракле, далее — всякий и разный жабоэнтерпрайз в нескольких вариациях, а последние лет 8 я занимаюсь биг датой. Нормальной такой, с петабайтами геоданных.
«Необычным» программистом я себя при этом не считаю. Ну знаю два десятка языков и пять разных платформ, но это ведь наживное. Написать прошивку для станка? Хм, если такая задача вдруг возникнет, то почему нет? Для роутеров и фотоаппаратов я прошивки собирал... справлюсь, думаю.
Батенька, а вы вообще в курсе, что Болонский процесс как таковой начался только в 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 — кто угодно может брать и пользоваться.
а бизнес-модель конторы, в которой он внедрён, это дело только самой конторы. вы вообще в курсе, как и на что выдаются гранты?
одно другому не мешает. или вы думаете, что все гранты должны тупо проедаться без реального выхлопа?
я вот вполне себе (то есть нам) нормальный продукт написал.
Надо будет — решу конечно. В чём сложность-то?
Принципы профилирования за 25 лет не поменялись, а профайлер сейчас прямо в браузер встроен. Последний раз я такое делал под IE7 (надо было отображать/фильтровать/сортировать табличку на 10к ячеек), тогда приходилось цепляться из вижуалстудии, было неудобно.
Я почти 10 лет занимался веб-разработкой. Правда, начинал ещё с Perl/CGI. Такие очень древние технологии, когда для ускорения бэка приходилось писать поначалу модули на сях, а для фронта — аплеты на допотопной жабе. Потом какое-то время у меня был хайлоад на оракле, далее — всякий и разный жабоэнтерпрайз в нескольких вариациях, а последние лет 8 я занимаюсь биг датой. Нормальной такой, с петабайтами геоданных.
«Необычным» программистом я себя при этом не считаю. Ну знаю два десятка языков и пять разных платформ, но это ведь наживное. Написать прошивку для станка? Хм, если такая задача вдруг возникнет, то почему нет? Для роутеров и фотоаппаратов я прошивки собирал... справлюсь, думаю.
Пруфы-то легко гуглятся, но пока вы придерживаетесь механистических взглядов, они вам никак не помогут :)