Anscombe's Quartet

2020-04-01 01:15:41 Давненько не писал ничего нового, ибо занимался очередной сменой места работы (что вполне успешно получилось, к слову говоря). В связи с внезапно образовавшимся свободным временем решил плотно заняться изучением относительно нового фреймворка под названием Apache Arrow. Кратко говоря, Arrow - это мультиязычная (на момент времени самыми зрелыми являются API для C++, Java, Python) платформа для работы с данными в памяти.

Ее идея довольно проста - при операциях с большими данными, и в особенности при передаче этих данных через процессы (скажем, Spark-to-Python), современные библиотеки накладывают довольно приличный overhead на сериализацию и десериализацию данных в памяти.

Скажем, если вы хотите применить кастомный UDF в PySpark поверх parquet-файлов в S3, ваши данные пройдут приблизительно следующий путь:
- Java-based Spark прочитает эти данные из S3 и сериализует из в Kryo-формате в памяти
- Java-based Spark сериализует (если она сериализуема, иначе вылезут ошибки сериализации) Python-функцию и прокинет ее на ноды
- Java-based Spark отправит данные на ноды для обсчета
- Данные из локального Java-based Spark процесса будут переданы в Python-based Spark процесс, и каждая запись пройдет полный путь сериализации и де-сериализации
- Python-based Spark процесс обсчитает данные и (после очередной сериализации) вернет их в Java-process

Как видно из этого описания, в процессе будет происходить куча неоптимальных операций сериализации и десериализации.

Создатель библиотеки Pandas, Wes McKinney, а так же многие другие основные контрибьюторы из таких проектов как Apache Hadoop, Apache Spark и Apache Cassandra, очевидно, не могли быть удволетворены таким перерасходом ресурсов и совершенными при имплементации текущего решения архитектурными ошибками, что собственно и послужило стартовой точкой для разработки Apache Arrow.

Пользователи PySpark уже могли сталкиваться с первыми результатами, которые дает использование Apache Arrow, если они использовали pandasUDF API.

Для меня же главный интерес представляет Arrow Flight RPC - это имплементация GRPC-сервера для передачи данных в виде flight-ов - по сути, байтовых массивов Arrow с отличной сериализацией и скоростью передачи. Такой подход позволяет ускорять процесс передачи данных между различными системами в разы.

Почитать про сам Apache Arrow можно на официальном сайте - https://arrow.apache.org/
А конечным пользователям Spark будут интересна оптимизация python-based UDF с помощью Arrow - https://spark.apache.org/docs/latest/sql-pyspark-pandas-with-arrow.html Открыть/Комментировать

2020-02-17 11:38:42 Надо правда признать, что Delta Lake - не единственный spark-related формат для хранения данных с update/delete возможностями, ведь помимо него есть так же ACID ORC и Iceberg.

Ситуация чем-то напоминает борьбу между parquet и orc форматами - похожие идеи, но разные имплементации.

Отличный сравнительный обзор по этим файловым форматам сделал мой коллега Michal Gancarski на Spark AI Summit 2019:
https://databricks.com/session_eu19/acid-orc-iceberg-and-delta-lake-an-overview-of-table-formats-for-large-scale-storage-and-analytics Открыть/Комментировать

2020-02-10 13:46:38 Databricks делает все большую ставку на Delta, по сути предлагая ее как новый золотой стандарт формата хранения для больших данных.

Сложно придумать более разумный подход в эпоху GDPR и потребности в удалениях или апдейтах данных прямо в больших датасетах на диске.
По сути своей, основная идея такова - зачем нам поднимать сложные в поддержке и использовании масштабируемые БД (Scylla, Cassandra, HBase) или переплачивать за их аналоги (DynamoDB / Aerospike)?

Куда проще писать в одно большое S3-like хранилище, а с помощью Delta-формата можно получить +- набор необходимых возможностей - Update / Delete операции. Использование S3-like API напрямую открывает практически неограниченные возможности по масштабированию (причем как у облачных провайдеров, так и on-premises), а Delta формат добавляет удобство потоковой записи и чтения.

Из очевидных минусов конечно скорость данного решения - subsecond latency в таком случае можно не ожидать, очевидно что практически любое KV хранилище для апдейтов по ключу будет работать быстрее. Однако там, где нет таких требований (например в BI-аналитике, или поставке данных для ML-приложений), и минутные задержки не являются критическим блокером, можно воспользоваться всеми удобствами этого формата.

https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html Открыть/Комментировать

2020-01-12 20:49:27 Очень детальный и подробный пост о том, как читать данные из Kafka с помощью Spark Structured Streaming и затем писать их в Delta-формат.
Вообще интересно как data engineering потихоньку мигрирует из строго-типизированных пайплайнов на Scala в упрощенные ноутбуки, в основном написанные на Python.


https://keestalkstech.com/2019/11/streaming-a-kafka-topic-to-a-delta-table-on-s3-with-spark-structured-streaming/ Открыть/Комментировать

2019-12-17 12:59:39 Команда Delta Lake (формат для update-delete операций поверх parquet, где update/delete механизмы работают за счет системы метаданных) выпустила свежий релиз версии 0.5.0. Одна из безусловно крутых особенностей delta - это возможность in-place удаления строк (чего обычный parquet не умеет), что сильно помогает при необходимости делать GDPR-compliant хранилище.

В версии 0.5.0 добавились две крутые фичи - в первую очередь, delta теперь поддерживает manifest-файлы, которые сильно облегчают работу с этим файловым форматом через Presto и Amazon Athena. Вторая фича пока экспериментальная, но уже выглядит довольно многообещающе - теперь таблицы в delta-формате можно запрашивать через Snowflake и Redshift Spectrum.

https://delta.io/news/delta-lake-0-5-0-released/ Открыть/Комментировать

2019-11-25 00:20:00 Lightbend (одна из ключевых компаний, поддерживающих и развивающих Scala, по совместительству создатели фреймворка Akka), выпустила в релиз новый фреймворк под названием Cloudflow. Этот фреймворк стремится занять нишу стриминговой обработки данных, предлагая разработчикам возможность писать стриминговые приложения на базе Spark, Flink или Akka Streams, а затем развертывать их как набор связанных сервисов в Kubernetes.
В целом, кажется что индустрия по обработке больших данных вновь обращает свой взор именно на потоковую обработку - Flink получил новую жизнь благодаря инвестициям от Alibaba, Spark активно анонсирует новые стриминговые возможности (включая subsecond latency) в готовящейся 3.0.0 версии, а теперь вот и Lightbend подоспел на огонек с новым фреймворком:
https://www.lightbend.com/blog/cloudflow-released-lightbends-newest-open-source-project Открыть/Комментировать