Поиск

Spark-beyond the classic ETL

Перспективы развития Apache Spark.

Прототип Spark’а был создан в 2009 году; 2010 год – Spark стал open source проектом; 2013 год – коммерческий продукт компании DataBricks; 2014 год – top level Apache проект; а начиная с 2016 появляется возможность широкого коммерческого использования Spark (версия 2.0, т.е. появление DataFrames / DataSets). Такая яркая и стремительная история успеха – пожалуй редкость даже для стэка big data технологий.


Spark Example


Оценить элегантность текущего функционала (spark v.2.3) можно на примере Structured Streaming модуля. Предположим где-то в облаках у нас есть папка, куда периодически копируются лог-файлы json стркутуры. И надо нам налету данные отETLить (т.е. распарсить, преобразовать и сохранить например в hdfs’е в parquet формате). Скальско-спарсксий срипт будет выглядеть примерно так:


val rawRecords = spark.readStream
.option("maxFilesPerTrigger", "100")
.schema(cloudTrailSchema)
.json(cloudTrailLogsPath)

val cloudTrailEvents = rawRecords
  .select(explode($"Records") as "record")
  .select(unix_timestamp($"record.eventTime", "yyyy-MM-dd'T'hh:mm:ss").cast("timestamp") as "timestamp", $"record.*")

val streamingETLQuery = cloudTrailEvents
  .withColumn("date", $"timestamp".cast("date")) 
  .writeStream
  .format("parquet")
  .option("path", parquetOutputPath)
  .partitionBy("date")
  .trigger(ProcessingTime("10 seconds"))
  .option("checkpointLocation", checkpointPath)
  .start()

Все! Т.е., да, конечно, я сознательно «вынес за скобки» такие детали как import’ы, объявление структуры данных cloudTrailSchema, инициализацию переменных cloudTrailLogsPath и parquetOutputPath, но основная логика “ завернута” DataFrame переменные:

  • rawRecords – входной поток файлов

  • cloudTrailEvents – результат преобразований

  • streamingETLQuery – результирующий поток в виде «паркетной» таблицы (sql% select * from parquet.`$parquetOutputPath`).

Если же для кого-то «файловый поток» не достаточно релевантный пример real-time ETL’я, то вот вариант чтения сообщений топика “data-tweets” из Kafka broker’а:

 val data_stream = spark   
   .readStream 
   .format("kafka") 
   .option("kafka.bootstrap.servers", "localhost:9092") 
   .option("subscribe", "data-tweets") 
   .option("startingOffsets","latest") 
  .load() 

UI or scripted ETL


При всем разнообразии существующих ETL решений, классифицировать их можно по 2 основным критериям:

  1. UI для формирования ETL логики (либо скрипты, либо стрелки и квадратики);

  2. Архитектура процессирования ETL’я – т.е. где будут выполняться преобразования данных (либо свой App, либо внешний Engine – DB, Hadoop, Spark, etc.).

Вопрос абсолютно не праздный – что лучше: строчки кода либо «квадратики»; наличие своего engine или его отсутствие. Потому как от первого пункта зависит скорость реализации задачи в части разработки, а от второго – скорость самого преобразования данных. Выражаясь более формально – оба пункта, серьезно влияют на основные критерии эффективность использования ETL инструмента:

  • простота (низкий уровень экспертизы и, как следствие, низкая стоимость ресурсов);

  • функциональность (отсутствие ограничений по типам источников/потребителей, структуре данных и логике преобразований);

  • скорость реализации business-case’ов (чем выше скорость, тем меньше общее время выполнение проекта и ниже его стоимость).

Возвращаясь к Spark’у, получаем следующую проекцию по обоим критериям:

  • UI – это скрипт на одном из языков программирования (Scala, Python, Java, …);

  • Архитектура – собственный ETL engine, работающий в кластере.


Я помню, как все начиналось...


И, казалось бы, ни чего нового – все как обычно развивается по спирали… Давным-давно, когда молодые и курчавые Инмон с Кимбалом еще только начинали «рисовать» свои звездочки и снежинки, первопроходцам ETL’я приходилось всю логику реализовывать в пакетах и процедурах базы данных, а оркестрировать с помощью линуксового крона. Потом пришла эра удивительно ярких и разнообразных «квадратиков» и стрелочек и в эйфории общей легкости и простоты казалось, что бородатых админов и прыщавых дэвов вообще скоро уволят, а всю ETL и BI логику будут кодить аналитики (а возможно даже и сами бизнеса напрямую!). Но вмешалась суровая действительность – толи бизнеса и аналитики оказались ленивыми, толи «квадратики» со «стрелочками» оказались не такими простыми как на первый взгляд… В общем, админов, а особенно дэвов начали дергать за штанины и умолять, что бы те разобрались во всей этой новомодной (на тот момент) красоте. Потом всем раздали новые «лычки» и бонусы, освоили бюджеты, реализовали какое-то количество DI проектов (с разной степенью успешности) … И наступил период некоторого декаданса – когда вроде ни чего особенного нового не происходит: задачи понятны и выполнимы, а результаты прогнозируемы, но в воздухе уже явно носился терпкий запах перемен. Если честно, то да – это был не запах, а отголоски новых битв товарищей по цеху, уже ощутивших на себе прелесть больших данных и анекдотичность ситуации когда: «боец держи кирпич, им надо сбить вражеский самолет». Т.е. например: движком базы данных надо было распарсить XML, а если не получалось, то просто сохранить в BLOB – пусть потом джависты парсят и формируют 3NF.. Хотя были и еще более казуистические случаи… А дальше все происходило очень сумбурно – с неимоверной быстротой начали появляться новые технологии, инструменты, подходы, решения – их стало так много, что ни кто за исключением самих разработчиков этих решений не понимал для чего это надо, что с этим делать и когда наконец пофиксят, хоть мало-мальски, существующие баги, коих как вшей у бездомной суки… Период ренессанса длился достаточно долго, лет 7, и он еще не закончен, но уже на исходе: все ненужное, как пена, осело. Из нового, которое, как мне кажется, обязательно надо взять на вооружение DI-related специалисту: Data Lake (как паттерн), HDFS, Hive (как полезный рудимент), Spark, ML алгоритмы и чего-то для streaming’а (flume, kafka, nifi).


Выводы

Классический ETL (даже в режиме квадратиков и стрелочек) подразумевал наличие экспертизы у дэва как минимум в следующем: SQL, скрипты файловой системы, возможно java-script, возможно python и иногда Java. Кроме того, сложность реализации обработки потоковых данных заставляла «выносить за скобки» разработку close to real time ETL'я. В этом контексте Spark «замахнулся» достаточно широко – дать возможность разработчику, использую функциональное программирование, и достаточно лаконичное описание бизнес логики в виде (например) спарко-скальских скриптов реализовывать все возможные задачи ETL’я «в одном месте», причем для каких угодно типов источников/приемников данных (реляционные, неструктурированные, потоковые, файловые, терабайтные и килобайтные, и всякие разные другие). И что самое интересное – пока все получается даже очень неплохо… А кроме того у Spark’а уже есть достаточное количество очень полезных доп. модулей – ML, GraphX, etc., но об этом в след. раз.


На этом все, see you soon…

Tel: +380677640202
Email: ceo@cubodrom.com

Address: 65000 Odessa, Ukraine ln. Botanicheskiy 6, office 34

  • LinkedIn Basic Black
  • Facebook Basic Black