Комментарии 10
Может быть, не SQL тогда?
Ну, на самом деле API Dataset-ов — вполне себе замена SQL, по его возможностям. Поэтому я бы возможно захотел именно такого. Не язык — а API. Сама же ваша идея более чем интересная. Более того, по-моему я какое-то расширение спарка для геометрий видел, которое примерно на такой же идее и было основано — метаязык поверх датасетов спарка.
Насмотревшись, что и как аналитики пишут на питоне (а на чём их ещё можно заставить писать?), я не могу согласиться с вашим пожеланием.
Питон язык отличный, не требующий программистского мышления, но он слишком высокоуровневый. За одним неосторожным обращением к свойству там легко может такая цепочка событий развернуться, что кластер будет просто стоять колом какое-то время. И если нужно каждый день инджестить сотню терабайт даты, то писать процессы на питоне — это верная смерть, какой бы крутой очередная кастомная обёртка над Dataset или Dataframe ни была.
По крайней мере, если ты не контора, которая железом закидывает код любой степени неоптимальности. То есть, крупняк какой-нибудь, типа телекомов. Ну, у них действительно есть такие инструменты, которые дают именно API. Но толку-то — это всё плохо отчуждаемые инструменты.
Поэтому мой выбор — ограниченный и заточенный под одну конкретную задачу диалект SQL, на котором заведомо что попало не напишешь. Впрочем, в следующий частях местами будет и что попало :)
Не понял вообще, при чем тут питон? Я вообще не про него. Я говорю, что вместо языка, диалекта SQL, для моих задач мне бы подошел специализированный API примерно такого же назначения, как у вас. Т.е. DSL. Поверх API Spark, которое в принципе эквивалентно SQL. То есть, решение сделать именно язык (с парсером и пр.) — оно совершенно не однозначное. Хотя вам наверное так лучше.
А зачем делать что-то «в принципе эквивалентное SQL», если можно сделать прям самый настоящий SQL?
И если речь не о питоне, то о каком API? API ведь к языку привязано, не бывает сферического API в вакууме без указания языка. Даже если имеется в виду проекция одних и тех же методов некой объектной модели, в разных языках они никогда не будут эквивалентными. Так что я не очень понимаю, чего именно вы хотите. И для кого.
Я вот на запросы своих аналитиков ориентируюсь, с моего проекта.
На самом деле ответ простой — ваши пользователи аналитики, и им проще SQL-подобный язык. Мои пользователи разработчики, и им удобнее DSL над API Spark Dataset. Который по сути эквивалентен SQL. Ну вот смотрите, что вы писали:
Spark SQL бесполезен без статически типизированной схемы данных. Рантайму даже для сериализации заранее нужна информация о типах, а для эффективного процессинга требуется либо доступ к Hive Metastore, либо его эмуляция в том или ином виде. Либо необходимо озаботиться ещё каким-нибудь способом инференса схемы в рантайме, если она неизвестна до запуска процесса — то есть, нужен внешний обвязочный код не на SQL.
Вот у меня этот вывод схемы в рантайме есть. И у меня есть эта самая информация о типах, аж две штуки (потому что у меня задача — часть репликации реляционной БД в хадуп, и два набора типов на каждую таблицу). И мы над каждой таблицей проделываем некий набор операций, которые записаны например на Java. И в нашем случае их вполне можно было бы оформить как вот очень похожий на ваше решение (не идентичный ему) язык, но в нашем случае — не SQL-подобный для аналитиков, а DSL для Java/Scala, для разработчиков.
И если речь не о питоне, то о каком API?
Spark Dataset API. Он очень близок для всех языков, которые поддерживает. То есть, код на Java, Scala, питоне — практически одинаковый, если не пишется — то понимается всеми одинаково. А полная эквивалентность им и не нужна.
Ну и замечательно, что ваши пользователи разработчики, и им удобно писать на Java. Повезло вам. Мне нет, мои пользователи жабу умеют только читать, и то со словарём.
Есть такая поговорка: кому поп, кому попадья, а кому свиной хрящик. В разных обстоятельствах для решения одной и той же задачи применимы разные подходы.
Но процессы ETL — не аналитические, в норме в них не происходит разбора данных на уровне полей записи для последующей хитрой агрегацией и схлопывания в некий показатель. В них обычно набор данных потребляется целиком, а записи в 99% случаев просто итерируются в духе «возьми всё оттуда, профильтруй, и перебутыль в другое местоположение, сменив формат». То есть, манипуляции, происходящие с данными ещё до их анализа, либо уже после него.
Очень странный тезис. У нас в ETL бывает и "разбор данных на уровне полей записи", и хитрая агрегация, и схлопывание, и еще много чего. А уж стратегий инкремента едва ли не больше, чем источников, потому что каждый источник стремится изобрести свою. И все это прекрасно работает на Spark SQL в Проме. Иногда, конечно, бывает нужна процедурная обвязка, но весьма редко.
Поручитесь, что ваш кейс типичный, и ваши практики универсально переносятся на любой другой ETL процесс в мире?
Нет, конечно. Я этого и не утверждал. Но он достаточно массовый, чтобы оспорить исходный тезис.
Вряд ли вы сможете подтвердить «достаточную массовость» статистикой. Сколько вообще %% от кол-ва ETL должно покрываться каким-то одним способом, чтобы массовость считалась «достаточной»?..
Есть такое когнитивное искажение, когда умелый пользователь молотка все проблемы считает гвоздями. Но мир вообще-то несколько разнообразнее.
Искусство ETL. Пишем собственный движок SQL на Spark [часть 1 из 5]