#hadoop_stack — Public Fediverse posts

Пишем движок SQL на Spark. Часть 8: CREATE FUNCTION

В предыдущих сериях ( 1 • 2 • 3 • 4 • 5 • 6 • 7 • Ы ) рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL, заточенный на задачи подготовки и трансформации наборов данных, и работающий как тонкая прослойка поверх Spark RDD API. Штука получилась довольно продвинутая, с поддержкой императивщины типа циклов/ветвлений/переменных, и даже с поддержкой пользовательских процедур. И в плане этой самой императивщины расширяемая: может импортировать функции из Java classpath, равно как и операторы выражений. То есть, если необходимо, можно написать функцию на Java, или определить новый оператор, и использовать потом в любом выражении на SQL. Круто? Ещё как круто. Но как-то однобоко. Если в языке у нас поддерживаются функции, то почему бы не дать нашим пользователям определять их самостоятельно? Вот прямо через CREATE FUNCTION ? Тем более, что вся необходимая для этого инфраструктура уже вовсю присутствует. Да и процедуры на уровне интерпретатора у нас уже поддерживаются ведь… Функция для затравки.

https://habr.com/ru/articles/915964/

#etl #apache_spark #java #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #никто_не_прочитает_эту_статью #написанную_для_отчётности_по_гранту

Иногда приходится¹ копаться² в кишках³ Apache Spark

¹ …просто потому, что другого варианта добиться необходимого результата тупо не существует. ² и да, довольно-таки глубоко. ³ нет, серьёзно! Давайте рассмотрим следующий бизнесовый кейс. Дано: реально большие данные. Очень много датасетов по много терабайтов каждый, — в сумме объём тянет на петабайты. Лежат в облаке, но это не важно. Важно, что мы эти данные покупаем в «сыром» виде, каким-то образом «готовим», а потом перепродаём конечному потребителю. Требуется: при подготовке каждого из датасетов разделить его согласно значениям одного или нескольких полей, составляющих его записи, на несколько. И это одна из особенно часто встречающихся в нашем процессе операций. Довольно-таки сложный, продвинутый ETL у нас. Поясню на типичном примере.

https://habr.com/ru/articles/913244/

#кейс #etl #apache_spark #java #pipeline_automation #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #никто_не_прочитает_эту_статью #написанную_для_отчётности_по_гранту

Искусство ETL. Пишем собственный движок SQL на Spark [часть 7]

В предыдущих сериях ( FAQ • 1 • 2 • 3 • 4 • 5 • 6 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных. В данной части поговорим о том, как добавить в собственный диалект SQL поддержку процедур. Например, -- library.tdl

CREATE PROCEDURE dwellTimeByMode(@signals, @target, @outPrefix,
@modes = ['pedestrian', 'non_pedestrian', 'car', 'bike'],
@groupid='cell10') AS BEGIN
LOOP $mode IN $modes BEGIN
SELECT * FROM $signals INTO "{$signals}/{$mode}" WHERE mode=$mode;

CALL dwellTime(@signals_userid_attr=userid,
@target_userid_attr=userid,
@target_grouping_attr=$groupid
) INPUT signals FROM "{$signals}/{$mode}", target FROM $target
OUTPUT INTO "{$outPrefix}/{$mode}";

ANALYZE "{$signals}/{$mode}";
ANALYZE "{$outPrefix}/{$mode}";
END;
END;

--- ... --- ... --- ... ---

-- script.tdl

CALL dwellTimeByMode(@signals=$this_month, @target=$population, @outPrefix=$this_month); Нафига это надо? Ну, допустим, у нас уже есть некоторое количество SQL ETL кода, наработанного за время эксплуатации инструмента в продакшене, и становится заметно, что значительная часть скриптов на разных проектах совпадает, и из раза в раз повторяется. Логично было бы вынести все эти совпадающие куски в библиотеку, чтобы держать в одном месте, да и вызывать с какими надо параметрами, когда надо. Вот прям как на примере выше.

https://habr.com/ru/articles/838034/

#etl #apache_spark #java #pipeline_automation #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #никто_не_прочитает_эту_статью #написанную_для_отчётности_по_гранту

Искусство ETL. Пишем собственный движок SQL на Spark [часть 6]

В предыдущих сериях ( FAQ • 1 • 2 • 3 • 4 • 5 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных. В данной части поговорим о том, как добавить в выражения SQL поддержку функций. Например, SELECT
MAX(score1, score2, score3, score4, score5) AS max_score,
MIN(score1, score2, score3, score4, score5) AS min_score,
MEDIAN(score1, score2, score3, score4, score5) AS median_score,
score1 + score2 + score3 + score4 + score5 AS score_sum
FROM raw_scores INTO final_scores
WHERE ABS(score1 + score2 + score3 + score4 + score5) > $score_margin; — тут у нас функции MAX , MIN и MEDIAN принимают любое количество аргументов типа Double и возвращают Double , а ABS только один такой аргумент. Вообще, кроме общей математики, в любом уважающем себя диалекте SQL как минимум должны быть функции для манипуляций с датой/временем, работы со строками и массивами. Их мы тоже обязательно добавим. В classpath, чтобы движок мог их оттуда подгружать. До кучи, ещё и операторы типа >= или LIKE , которые у нас уже были реализованы, но хардкодом, сделаем такими же подключаемыми. Предупреждение о сложности материала Уровень сложности данной серии статей в целом высокий. Базовые понятия в тексте совсем не объясняются, да и продвинутые далеко не все. Однако, эта часть несколько проще для ознакомления, чем предыдущие. Но всё равно, понимать её будет легче, если вы уже пробежались по остальным хотя бы по диагонали.

https://habr.com/ru/articles/808483/

#etl #apache_spark #java #pipeline_automation #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #любите_ли_вы_твёрдую_НФ?