Comments 10
У нас тоже есть большое желание писать ETL на SQL и делать аналитику на SQL. Но мы не стали ничего изобретать и используем Snowflake. Мне кажется это настолько удобно, что даже читерство
Вопрос к автору. А не могли бы Вы пояснить ваши мотивы, почему понадобилось писать собственный движок? Вот мне обычно хватает типового Spark SQL (хотя, когда приходилось писать для кластера на устаревшем Spark 2, то многих удобных функций не хватало, например, для работы с полями-массивами, и я дописывал свои, замещающие те, что уже есть в Spark 3 или хотя бы в Spark 2.4.0). Я читал часть 1 и Ваши аргументы на эту тему в самом начале. И если я не ошибаюсь, то это делалось для особого рода аналитиков, которые "мы привыкли к этому диалекту SQL и хотим, чтобы у нас было все удобно и как нам хочется"? Не так? Мне кажется, тут дилемма - если аналитики так себе и не понимают базовый универсальный SQL и не могут разобраться в Spark SQL, то они все равно будут Вас теребить постоянно, чтобы вы помогли им составить запрос, какой бы диалект ни использовался, и какой бы инструмент умнейший Вы им ни написали бы, все равно это будет, вас не разгрузят от рутины. А если аналитики хорошие, да покажите им Spark SQL, и они сами все сделают. Что я понял не так?
Прочитайте предыдущую статью с FAQ https://habr.com/ru/articles/762862/
Если останутся ещё вопросы, я на них с удовольствием отвечу.
(БТВ, если вам всего хватает в имеющихся инструментах, вам остаётся только позавидовать. В реальной жизни кейсы намного разнообразнее, чем вам кажется. В качестве подсказки — в бизнесе деньги решают всё. Иногда весьма неочевидный путь ОЧЕНЬ сильно дешевле.)
Спасибо, почитал. Как и все предыдущие части материала. По-прежнему мне кажется, что реализация диалекта заточена под удобство реализации конкретного спектра задач. Я так понял, у вас есть достаточно обширный набор паттернов высокоуровневой обработки данных - стандартные DWH, витрины и прочее, специфическое для вашей фирмы, сильно повторяющиеся в разных задачах, только с разными входными данными? Очень хорошо, если для вашей фирмы это оптимально. У меня задачи очень широкие и обработка данных идет чуть не в каждой задаче нестандартно - ну вот такой у меня генеральный заказчик, он же мой работодатель. Каждая новая задача использует приемы из предыдущих задач разве что по-минимуму самые базовые - очень сложные и неповторяющие связи данных из источников разного типа, с постоянно переменными требованиями. У аналитиков, знаете ли, очень богатая фантазия, а мне эту фантазию нужно реализовать в код, да еще чтобы работал оптимально. И в принципе, я вижу в SparkSQL практически все функции, какие нам знакомы в любом движке DB, юнионы, джойны, оконные функции и так далее, только под капотом все работает несколько иначе, а иногда - совсем иначе. Ну да это все поэтическими словами о прозе жизни. А вопрос конкретно такой - вы сделали еще одну прослойку между базовыми сущностями Spark и потребителем. Даже если ее не делать - все время нужно следить за оптимальным выполнением, не всегда полагаясь на интеллект Catalyst (он не все умеет оптимизировать). Еще одна прослойка - она не маскирует ли дополнительно базовый слой абстракций Spark, заставляя изучить помимо еще одного API (это не самое сложное, я понимаю) еще один набор приемов оптимизации выполнение уже поверх вашей абстракции? Не усложнилась ли оптимизация выполнения? Или вы это как-то учли и выработали собственные приемы, работающие уже с вашими абстракциями? Если да - не могли бы вы написать еще одну-две части материала - продолжение с примерами, как оптимзировать выполнение поверх вашего движка? Мне кажется, что SparkSQL все же прост и понятен в достаточной степени. Конечно, мне приходится работать и со старыми кластерами, например, где Spark 2.3.2 - вот на них приходилось дописывать логику, которой не хватало. Но на Spark 3 и выше ее уже столько добавлено, что мне еще не попадалось задач, для которых мне не хватило функций на новых версиях.
Очень сложно парсить ваши комментарии :\
Вы бы хоть между отдельными вопросами перевод строки ставили. Но я попробую расчленить и ответить. Не обессудьте, если неправильно их пойму.
Да, у нас есть набор хорошо упакованных и параметризованных алгоритмов, которые могут работать с похожими данными из разных источников.
Мы не занимаемся аналитикой над данными в сыром виде, и вообще я много раз подчёркиваю, что задачи повторить SparkSQL изначально не стояло (да и зачем такой ерундой заниматься?). Аналитика вся производится над данными, которые уже подготовлены, и в инструменты аналитиков я лично не лезу. Что у них там кроме pandas, не моё дело.
У нас нет отдельного слоя абстракции, который надо было бы изучать. Есть простая система типов, и это всё, что есть user-facing.
Нечего оптимизировать. В отличие от аналитических БД с декларативными SQL, где ты пишешь ЧТО хочешь получить, и оптимизатор сам тебе выбирает КАК (и где чаще всего зарыта собака), в ETL процессах ты непосредственно пишешь КАК тебе надо получить ЧТО-то, а оптимизатора у тебя нет от слова совсем.
Примеры вряд ли будут показательными, они очень уж сильно завязаны на конкретные бизнес-кейсы нашего проекта. Большая часть из них вообще под NDA. Мы же продаём услугу по аналитике тем, кто не умеет ею заниматься...
Причём тут ETL?
Кастомный парсер SQL диалекта, коих уже вагон, будет +1.
При том, что инструмент, построенный вокруг интерпретатора данного диалекта, используется для ETL.
И много ли вы знаете кастомных парсеров, которые, например, геометрические объекты и произвольный JSON поддерживают прямо в базовом синтаксисе?
Впрочем, предыдущие статьи вы, очевидно, даже не пытались читать.
Не-не. Кастомные парсеры просто так не пишут. Если автору статьи это было нужно, значит речь идет не о простой проекции диалектов один-в-один, а под конкретные наборы боевых задач фирмы, компонуя что-то более низкого уровня в несколько более высокий. Тут я с автором согласен - надо, значит, надо. Однако, не считаю такой подход универсальным и нужным для всех. Считаю функционал SparkSQL достаточно богатым, а если где-то чего-то не хватает, всегда можно его кастомно расширить добавив собственные функции, где это нужно. Но не целый парсер. Ну разве что, автору нужен был именно парсер - но это все же считаю узкоспециализированным и фирмоориентированным подходом. Кстати, вовсе не ругаю - безусловно интересный опыт и полезный в чем-то. Кому-то, может быть, именно такой расширенный подход будет и оптимален. Во всяком случае любопытно, и читать было интересно и полезно, хотя сам бы я не стал затрудняться, с моей колокольни это избыточная трата усилий.
Искусство ETL. Пишем собственный движок SQL на Spark [часть 6]