Комментарии 13
Наконец-то нормальная статья для хабра соотв. уровня, а не очередной хлоу_ворлд или реклама канала. Плюсую!
*Написанная для отчетности по гранту
одно другому не мешает. или вы думаете, что все гранты должны тупо проедаться без реального выхлопа?
я вот вполне себе (то есть нам) нормальный продукт написал.
Да нет, просто забавно видеть это в тэгах. Ну и ещë очень интересно, почему и с какой целью коммерческой компании, которая занимается вот этим:
эти данные покупаем в «сыром» виде, каким-то образом «готовим», а потом перепродаём конечному потребителю
вообще выдают гранты. Но это вопрос не к вам, а к тем, кто их выдает.
я что-то не догоняю причин вашего негодования.
грант был выдан с конкретной темой: «разработка инструмента для ETL». цель достигнута, инструмент успешно разработан. более того, выложен в открытый доступ: https://github.com/PastorGL/datacooker-etl — кто угодно может брать и пользоваться.
а бизнес-модель конторы, в которой он внедрён, это дело только самой конторы. вы вообще в курсе, как и на что выдаются гранты?
вы вообще в курсе, как и на что выдаются гранты?
Я-то как раз в курсе, потому что всю жизнь работаю в науке и R&D, и сам руковожу и руководил НИР и НИОКР по грантам в некоммерческих научных учреждениях. Поэтому мне и непонятно, зачем и почему выдают гранты коммерческой компании на еë хоздеятельность, направленную на получение прибыли. Говоря простым языком, это примерно то же самое, что выдавать Пятерочке гранты на продажу круассанов.
тогда должны знать, что гранты выдают очень разные фонды (коммерческие, некоммерческие, государственные, частные, и т.д.) на совершенно разных условиях (например: разработка продукта с нуля, коммерциализация существующего продукта, поддержка инновации, внедрение технологии, и т.п.).
вообще, никому не советую делать далеко идущих conjectures на основе неполной информации. вы ведь понятия не имеете, какие именно вводные были у нас (а раскрывать их я, конечно же, не буду — не имею права). но покритиковать очень хочется, да?
Спасибо за столь интересную статью! Такую проблему я решал с использованием dataframe api df.repartition(keys).write.partitionBy(keys). Чем этот подход уступает подходу, описанному в статье?
а вы почитайте исходники dataframe api, сразу станет понятно.
если кратко, то это «подход №1» со всем его оверхедом.
Ознакомился с исходниками версии 3.2, ничего общего в подходом 1 не увидел. Вы сами читали?
Любой write это конечный метод, который материализует весь датасет. Результатом после него будут файлы в ФС, и чтобы продолжить работать с выдернутой порцией данных, вам придётся заново прочитать их с диска. Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет. И если нужно продолжить обрабатывать все куски, то вдобавок они столько же раз будут прочитаны с диска заново. От подхода №1 это мало чем отличается.
В подходе №2 вы можете продолжить обработку выбранного куска без его явной материализации. Точнее, хоть всех кусков, хоть некоторых. В том-то и вся суть, что его можно использовать посередине процесса, а не только в самом конце, причём столько раз, сколько требуется, и без оверхеда.
Читать исходники недостаточно, их надо ещё понимать в связке с решаемой задачей.
Значит, нам, как промежуточному звену, в процессе надо порезать датасет как минимум по
широте+долготе(наложив некий фенсинг для каждого из целевых муниципалитетов), и потом ещё подням недели(либо по каждому по отдельности, либо по рабочим/выходным) + почасовые интервалы. «Как минимум», потому что некоторые клиенты хотят ещё сильнее раздробить данные, вплоть до первой буквыхеша ID пользователя(который представляет из себя 16-ричную строку), или наложить ещё какие-нибудь особенные способы разбиения.
А результат этого где будет храниться?
Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет.
Датасет уже записан с партицироваем, для получения нужной порции достаточно прочитать нужные партиции
А результат этого где будет храниться?
Если вы не знаете, где и как спарк хранит промежуточные данные, то вам стоит это выяснить. Что касается окончательного результата, то куда надо, туда мы его и пишем. В том формате, который нужен. Не обязательно в паркет, и не обязательно в файлы даже. Да и результат этот не один, потому что ETL у нас не линейный, а разветвлённый.
Датасет уже записан с партицироваем
Только если у вас одно и то же партиционирование. В нашем случае исходный датасет готовится сразу для нескольких потребителей, и у каждого свой набор правил нарезки, то бишь, промежуточный датасет порождает множество результирующих со своими правилами группировки. Плюс, нам часто нужно писать во внешнее хранилище не полностью все партиции, а только те куски, которые нужны конкретному потребителю. И делать это максимально эффективно, чтобы себестоимость не улетала в небеса.
Вы решаете отдалённо похожую, но намного более простую задачу. Везёт вам.
Иногда приходится¹ копаться² в кишках³ Apache Spark