Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что 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 я занимаюсь биг датой. Нормальной такой, с петабайтами геоданных.
«Необычным» программистом я себя при этом не считаю. Ну знаю два десятка языков и пять разных платформ, но это ведь наживное. Написать прошивку для станка? Хм, если такая задача вдруг возникнет, то почему нет? Для роутеров и фотоаппаратов я прошивки собирал... справлюсь, думаю.
Слава богу, за 25 лет мне ни разу не доводилось заниматься тупой обезьяньей работой. Всё время какой-нибудь R&D, интерпретаторы, контейнеры, и прочая дичь. Значит, никакие ИИ не для меня, так и буду продолжать руками писать... точнее, головой :)
Абстрактное мышление ни в какой кремний запихнуть нельзя.
Вы бы хоть матчасть для начала изучили, а именно, какие конкретно части мозга активируются при обдумывании тех или иных понятий. Если изучите, сильно удивитесь. Потому что никакого абстрактного мышления не существует.
Когда думаешь о наборе текста на клавиатуре, задействуются ровно те же самые нейроны, которые двигают твоими пальцами. Просто слегка иначе. Когда думаешь о счётных множествах, то те же нейроны, которые реагируют на что-то большое в поле зрения. Просто чуть по-другому. И так вообще со всем.
Человеческое сознание всего лишь побочный артефакт нашего wetware. Повезло вот миллион лет назад предкам людей получить пару мутаций в энергетическом обмене, которые позволяют поддерживать альтернативный режим работы мозга помимо его прямой функции — управления триллионами клеток тела.
Механисты, которые не знают, что в настоящем человеческом мозге между двумя соседними нейронами могут быть тысячи синапсов, причём совершенно разных — как по скорости реакции, так и по медиаторным молекулам, которые бывают как стимулирующие, так и тормозные, — просто понять не могут, что повторить его в софте физически невозможно.
А ведь даже один синапс это ещё и объём + время. И сколько вокселей надо, чтобы в точности его смоделировать? А потом помножить на параллельную обработку, причём честно параллельную — ведь каждый нейрон уже сам по себе как независимое процессорное ядро со своим тактовым интервалом.
И в мозге их чуть более чем дофига, да ещё и конфигурация самого wetware меняется всё время. Никакими квинтиллионами параметров такое не замоделить. Но кажется, что вот-вот, что ещё чуть-чуть... Ну, пускай кажется, что ли.
Один мой вузовский препод (ох и мерзкий же был дядька) любил повторять, что большинство начинающих программистов было бы рациональнее заменить дрессированной макакой. (25 лет назад ИИшенок ещё в продакшене не было, так что да, действительно, хорошо выдрессированная под типовые задачи макака вероятно казалась ему лучше бестолкового студента.)
Вот только помимо типовых задач, которые раньше копировались со стековерфлоу, а теперь пишутся бредогенерилками (обученными на том же самом выхлопе стековерфлоу по большей-то части), есть нетиповые. Решений для которых в обучающих выборках нет.
А если нет качественно обучающей выборки, то никакая языковая модель ничего полезного по неизвестному ей контексту не напишет. Так уж они устроены.
тяжело и глупо игнорировать тот факт, что агенты, MCP тулы, промпт инженеринг, индексирование с RAG и т.д. очень сильно улучшают продуктивность
Прям так и хочется как в Википедии поставить [кому?] [когда?] и прочие метки.
В вашем-то случае может и помогает, если вы натренировали их на всей кодовой базе дотнета, и собственно для дотнета и используете. Для автоматизации написания перекладывалок из джейсонов в постргю тоже, наверное, неплохо такие тулы подойдут. Но вот только стоит заняться чем-то более редким, полезность их уменьшается экспоненциально.
Хмм, позвольте возразить, но «тимлид» в энтерпрайзе это чисто менеджерская должность. Программировать на ней получается разве что программистов в аутлуке.
Должность выше сеньорской, в которой помимо технического менеджмента дозволяется залазить непосредственно в код, называется «техлид». И совершенно иные вводные.
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что 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 я занимаюсь биг датой. Нормальной такой, с петабайтами геоданных.
«Необычным» программистом я себя при этом не считаю. Ну знаю два десятка языков и пять разных платформ, но это ведь наживное. Написать прошивку для станка? Хм, если такая задача вдруг возникнет, то почему нет? Для роутеров и фотоаппаратов я прошивки собирал... справлюсь, думаю.
Пруфы-то легко гуглятся, но пока вы придерживаетесь механистических взглядов, они вам никак не помогут :)
Слава богу, за 25 лет мне ни разу не доводилось заниматься тупой обезьяньей работой. Всё время какой-нибудь R&D, интерпретаторы, контейнеры, и прочая дичь. Значит, никакие ИИ не для меня, так и буду продолжать руками писать... точнее, головой :)
Абстрактное мышление ни в какой кремний запихнуть нельзя.
Вы бы хоть матчасть для начала изучили, а именно, какие конкретно части мозга активируются при обдумывании тех или иных понятий. Если изучите, сильно удивитесь. Потому что никакого абстрактного мышления не существует.
Когда думаешь о наборе текста на клавиатуре, задействуются ровно те же самые нейроны, которые двигают твоими пальцами. Просто слегка иначе. Когда думаешь о счётных множествах, то те же нейроны, которые реагируют на что-то большое в поле зрения. Просто чуть по-другому. И так вообще со всем.
Человеческое сознание всего лишь побочный артефакт нашего wetware. Повезло вот миллион лет назад предкам людей получить пару мутаций в энергетическом обмене, которые позволяют поддерживать альтернативный режим работы мозга помимо его прямой функции — управления триллионами клеток тела.
Никакая модель с такой задачей не справится.
Механисты, которые не знают, что в настоящем человеческом мозге между двумя соседними нейронами могут быть тысячи синапсов, причём совершенно разных — как по скорости реакции, так и по медиаторным молекулам, которые бывают как стимулирующие, так и тормозные, — просто понять не могут, что повторить его в софте физически невозможно.
А ведь даже один синапс это ещё и объём + время. И сколько вокселей надо, чтобы в точности его смоделировать? А потом помножить на параллельную обработку, причём честно параллельную — ведь каждый нейрон уже сам по себе как независимое процессорное ядро со своим тактовым интервалом.
И в мозге их чуть более чем дофига, да ещё и конфигурация самого wetware меняется всё время. Никакими квинтиллионами параметров такое не замоделить. Но кажется, что вот-вот, что ещё чуть-чуть... Ну, пускай кажется, что ли.
Один мой вузовский препод (ох и мерзкий же был дядька) любил повторять, что большинство начинающих программистов было бы рациональнее заменить дрессированной макакой. (25 лет назад ИИшенок ещё в продакшене не было, так что да, действительно, хорошо выдрессированная под типовые задачи макака вероятно казалась ему лучше бестолкового студента.)
Вот только помимо типовых задач, которые раньше копировались со стековерфлоу, а теперь пишутся бредогенерилками (обученными на том же самом выхлопе стековерфлоу по большей-то части), есть нетиповые. Решений для которых в обучающих выборках нет.
А если нет качественно обучающей выборки, то никакая языковая модель ничего полезного по неизвестному ей контексту не напишет. Так уж они устроены.
Прям так и хочется как в Википедии поставить [кому?] [когда?] и прочие метки.
В вашем-то случае может и помогает, если вы натренировали их на всей кодовой базе дотнета, и собственно для дотнета и используете. Для автоматизации написания перекладывалок из джейсонов в постргю тоже, наверное, неплохо такие тулы подойдут. Но вот только стоит заняться чем-то более редким, полезность их уменьшается экспоненциально.