Data Engineering / reposts & drafts
35 subscribers
227 photos
22 videos
40 files
557 links
Download Telegram
Про DLH и Trino. Статьи и вебинар 11.02

Привет!

Собрали пятничный #дайджест про Data Lakehouse и Trino. Читайте статьи и приходите на наш вебинар.

🔹 Нужна ли нам Lakehouse архитектура?

🔹 Быстрая обработка данных в data lake с помощью SQL

🔹 Платформа данных в хранилище Магнит OMNI

🔹 Как устроен massively parallel processing (MPP) в Trino

🔹 Почему Trino такой быстрый: динамические фильтры

🔹 Почему Trino такой быстрый: архитектура оптимизатора SQL-запросов

Вебинар «Поднимаем Data Lakehouse на основе Trino в облаке»

11 февраля в 17:00 мы разберем, что такое Data Lakehouse. Узнаем, как эта архитектура объединяет преимущества DLH и DWH, чтобы упростить управление, удешевить хранение и ускорить анализ данных из различных источников в одном месте.

На примере в лайв-режиме покажем различия в стоимости и скорости работы DLH и DWH.

Ведущий — Алексей Белозерский, руководитель группы BigData Services VK Cloud.

Подробности и регистрация

Хорошего чтения и приятных выходных!

👉🏻 Подписаться на телеграм-канал «Данные на стероидах»

#дайджест #ликбез #Data #AI
DataLakehouse 11.02.pdf
1.8 MB
Всем привет!

Презентация со вчерашнего вебинара.
Всем ли нужно заниматься данными?

Нередко заказчики спрашивают что-то подобное. Что, прямо в каждой компании должен быть стек обработки [больших] данных?

Сложилась аналогия.

Всем ли нужно заниматься спортом?
Нет, не всем. Можно прожить вообще без этого и быть довольным.

Ведет ли занятие спортом к улучшению жизни?
Разумеется, ведет!

Требует ли занятие спортом дополнительных вложений денег/времени/сил?
Конечно, требует.

Вот вам и уравнение. И с данными точно так же.
Про Trino — статьи и видео

Привет!

На вебинаре во вторник мы рассказали про Trino.

Смотрите вебинар

Самое время вспомнить наш летний дайджест, посвященный этой теме.

Статьи на русском

🔹 Почему Trino такой быстрый: динамические фильтры

🔹 Почему Trino такой быстрый: архитектура оптимизатора SQL-запросов

🔹 Как устроен massively parallel processing (MPP) в Trino

🔹 Обращаемся к Apache Hive через Trino: архитектура движка и принцип действия коннектора

Статьи на английском

🔹 Trino versus Apache Spark

🔹 Deploy MinIO and Trino with Kubernetes

🔹 The Best Data Transformation Tools for Trino

🔹 Use Trino with Dataproc

🔹 Enabling Highly Available Trino Clusters at Goldman Sachs

🔹 Trino Architecture

Видео

🔹 Как пересесть на Trino после Vertica: реальный кейс Авито

🔹 Роль Trino в Тинькофф: использование встроенных возможностей, собственные доработки и future work

🔹 Как устроено выполнение SQL-запросов в Presto/Trino

🔹 Trino Fest 2024 — 13 докладов

👉🏻 Подписаться на телеграм-канал «Данные на стероидах»

#дайджест #ликбез #trino
Запустили первый в России облачный Data Lakehouse

VK Cloud стала первой в России облачной платформой с возможностью построить корпоративный Data Lakehouse.

Data Lakehouse работает на управляемых облачных сервисах VK Cloud:

🔹 Cloud Storage — S3-совместимое объектное хранилище собственной разработки,

🔹Cloud Trino — высокопроизводительный SQL-движок на базе Kubernetes.

Cloud Trino позволяет сократить время на ETL-процессы, ускорить обработку сырых данных, легко построить Self-Service-аналитику и получить ценные инсайты в реальном времени.

Преимущества для пользователей VK Cloud:


🔹 современный стек для работы с крупными проектами,

🔹 оплата только за фактически потребленные ресурсы,

🔹 нет необходимости покупать лицензии.

Узнать подробнее
Три статьи и один вебинар про хранение данных

Привет!

По традиции собрали несколько полезных тематических материалов, которые вышли на Хабре на этой неделе.

🔹 Как не утонуть в данных: выбираем между DWH, Data Lake и Lakehouse

🔹 Как устроен T-RAID — RAID-массив в СХД TATLIN

🔹 Трансформация платформы данных: от пары кубов до хранилища > 30 Тб и 1000 ETL-процессов

В продолжение темы хранения данных делимся записью вебинара «Используем S3 на максимум. Как построить эффективное и устойчивое объектное хранилище».

🔹 Смотрите запись в нашем паблике.

👉🏻 Подписаться на телеграм-канал «Данные на стероидах»

#дайджест #ликбез
Про Trino — статьи и видео

Привет!

На вебинаре во вторник мы рассказали про Trino.

Смотрите вебинар

Самое время вспомнить наш летний дайджест, посвященный этой теме.

Статьи на русском

🔹 Почему Trino такой быстрый: динамические фильтры

🔹 Почему Trino такой быстрый: архитектура оптимизатора SQL-запросов

🔹 Как устроен massively parallel processing (MPP) в Trino

🔹 Обращаемся к Apache Hive через Trino: архитектура движка и принцип действия коннектора

Статьи на английском

🔹 Trino versus Apache Spark

🔹 Deploy MinIO and Trino with Kubernetes

🔹 The Best Data Transformation Tools for Trino

🔹 Use Trino with Dataproc

🔹 Enabling Highly Available Trino Clusters at Goldman Sachs

🔹 Trino Architecture

Видео

🔹 Как пересесть на Trino после Vertica: реальный кейс Авито

🔹 Роль Trino в Тинькофф: использование встроенных возможностей, собственные доработки и future work

🔹 Как устроено выполнение SQL-запросов в Presto/Trino

🔹 Trino Fest 2024 — 13 докладов

👉🏻 Подписаться на телеграм-канал «Данные на стероидах»

#дайджест #ликбез #trino
Forwarded from 🔋 Труба данных (Simon Osipov)
https://github.com/databrickslabs/dqx

Databricks выложили в опенсорс DQX - фреймворк для DQ поверх pyspark датафреймов.
Больше фреймворков богу фреймворков.

Даже мотивация для этого фреймворка какая-то хлюпкая
Current data quality frameworks often fall short in providing detailed explanations for specific row or column data quality issues and are primarily designed for complete datasets, making integration into streaming workloads difficult.


@ohmydataengineer - канал "🕯Труба Данных" не верит в очередной фреймворк
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🔋 Труба данных (Simon Osipov)
https://clickhouse.com/blog/json-bench-clickhouse-vs-mongodb-elasticsearch-duckdb-postgresql

Вы будете кидать 💩, но я опять про Clickhouse
Огромная статья с технической мяготкой про 1 Billion JSON Challenge и насколько новый нативный тип JSON в клике работает быстрей и эффективней по памяти и стораджу по сравнению с другими базами данных.


@ohmydataengineer - канал "🕯Труба Данных" в очередной раз про одно и то же!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🔋 Труба данных (Simon Osipov)
https://www.gable.ai/data-contracts-book

ГигаЧад и O'Reilly выкатывают в открытый доступ (правда надо оставить емейл) первую версию книжки про дата контракты.
Как по мне, хайп на эту штуку прошел и чет даже не сильно зудит это применять. Но, возможно, вы что-то подчерпнете для себя!

@ohmydataengineer - канал "🕯Труба Данных" в сомнения про дата контракты
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🔋 Труба данных (Simon Osipov)
https://vutr.substack.com/p/8-minutes-to-understand-presto

Большая пояснительная статья про работу Presto (ну и в целом Trino работает похожим образом). Все еще сильно советую подписаться на этого парня, он хорошие статьи пишет

@ohmydataengineer - канал "🕯Труба Данных", который ничего умного в этот раз не придумал.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🔋 Труба данных (Simon Osipov)
https://www.pracdata.io/p/open-source-data-engineering-landscape-2025

Все вы помните огромные картинки, на которых 17 миллионов логотипов сервисов для данных. Вот эта статья - одна из таких, но тут главная особенность - здесь ТОЛЬКО open source решения, и причем в адекватном количестве. С понятными пояснениями, почему тот или иной инструмент попал в список.

Как всегда, читать эту картинку нужно следующим образом "А что еще есть на рынке в этой сфере кроме X?"


@ohmydataengineer - канал "🕯Труба Данных" и ставшие уже классическими landscapes картинки!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🔋 Труба данных (Simon Osipov)
https://debezium.io/blog/2025/02/01/real-time-data-replication-with-debezium-and-python/

Говорим Debezium, подразумеваем Kafka как точка, в которую у нас льются эвенты CDC. Казалось бы, самое стандартное и классическое решение, проверенное сотнями разных сетапов.
А вот нет, оказывается можно и без Kafka.

Debezium + CDC + Python + dlt → Real-time PostgreSQL replication

@ohmydataengineer - канал "🕯Труба Данных" удивлен новым подходам!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных (Dmitry)
Практически каждый проект в инжиниринге данных начинается с package manager (пакетный менеджер), как правило для Python.

С одной стороны у всех цель одна, а с другой стороны “кто в лес, кто по дрова”.

Мне попались 3 хорошие статьи от Dagster на эту тему (про сам Dagster там нет), в которых хорошо рассказывают как это работает и как сделать удобно и красиво.

Python Packages: a Primer for Data People (part 1 of 2)
Python Packages: a Primer for Data People (part 2 of 2)
Best Practices in Structuring Python Projects

Вообще там 11 частей, в каждом посте будут ссылки на все части, например есть и другие полезные:
High-performance Python for Data Engineering
Write-Audit-Publish in data pipelines
Breaking Packages in Python
CI/CD and Data Pipeline Automation (with Git)
Factory Patterns in Python
Type Hinting in Python
Environment Variables in Python

Если вы еще на “вы” со всеми этими менеджерами, зависимостями или не очень понимаете, что творится у вас на работе в репозитории, то будет полезно ознакомиться.
Forwarded from 5 minutes of data
Modern Data Stack: Где баланс между мощью и простотой?

Автор статьи на moderndata101 поднимает важный вопрос:
современные инструменты для работы с данными превратились в сложный «пазл»,
который мешает компаниям сосредоточиться на главном - извлечении ценности из данных.

Более 70% респондентов вынуждены использовать более 5-7 различных инструментов или работать с 3-5 поставщиками для различных задач. Около 10% используют более 10 инструментов, что показывает растущую сложность ландшафта данных.

Проблемы текущих data-стеков:
1. Фрагментация инфраструктуры
Раньше хватало SQL-базы и BI-инструмента. Сейчас компании используют десятки узкоспециализированных решений, которые слабо интегрируются друг с другом. Результат — «лоскутное» решение, где данные теряются на стыке систем.

2. Экономические и временные затраты:
Каждый новый инструмент - это:
• Лицензии,
• Обучение сотрудников,
• Настройка интеграций,
• Постоянные доработки под меняющиеся требования.
Команды тратят 60% времени на поддержку инфраструктуры вместо анализа.

3. Зависимость от экспертов:
Сложные стеки требуют узких специалистов, которых не хватает на рынке. Уход такого сотрудника может парализовать процессы.

4. Снижение гибкости:
Добавление новых источников данных или изменение ETL-процессов превращается в многонедельный проект из-за нагромождения технологий.

Что предлагает автор?
• Консолидация вместо фрагментации
Платформы, которые объединяют сбор, трансформацию, хранение и визуализацию данных (например, Databricks или Google BigQuery). Чем меньше «точек соприкосновения» между инструментами, тем ниже риски ошибок.
• Стандартизация процессов
Унификация форматов данных, API и протоколов (как в случае с Apache Arrow или Parquet). Это снижает порог входа для новых сотрудников и упрощает масштабирование.
• End-to-end решения
«Бесшовные» платформы, где данные перемещаются между этапами без ручных преобразований. Например, Snowflake с поддержку ML-моделей или Looker.


Сложность - не всегда признак продвинутости.

@data_whisperer
Forwarded from DataJourney
Немного истории Greenplum

В продолжение новости про документацию GP. Порой, в поисках доки или каких-то решений в поисковике можно попадать на разные сайты или на мертвые ссылки, которые вроде бы должны описывать то или иное поведение. А все по той причине, что история владения Greenplum сложна:

2005 год, компания Greenplum Software выпускает продукт Bizgres – СУБД, основанную на коде PostgreSQL, которая умеет в колоночное хранение и горизонтальное масштабирование;
2010 год, компанию поглощает компания EMC (ныне Dell EMC), продукт сохраняет название компании и теперь называется Greenplum Database;
2012 год, из EMC выходит компания Pivotal, которая продолжает разработку, а продукт теперь называться Pivotal Greenplum Database;
2013 год, Pivotal презентует вариант Greenplum с хранением данных файловой системе Hadoop, который называет Hawq;
2015 год, Pivotal выкладывает код Greenplum DB и Hawq в OpenSource;
2019 год, компанию Pivotal поглощает компания VMware, продукт теперь называется VMware Greenplum;
2020 год, VMware презентует VMware Tanzu Greenplum – вариант Greenplum для разворачивания в облаке;
2022 год, Broadcom анонсирует крупную сделку и покупает VMware целиком по рыночной стоимости;
2024 год, Broadcom закрывает код Greenplum (github)

Что будет дальше? А дальше все в тумане. Ближе всего к нам есть Greenplum от Аренадаты, но это уже не OpenSource.
Forwarded from DataJourney
Кто такой Apache Iceberg

В последнее время вокруг всё больше и больше информации про озера данных и какое-то слово «Iceberg», которое позволяет строить такие хранилища. До ознакомления с вопросом, я ошибочно полагал, что Iceberg - это просто новый формат файла по аналогии с Parquet или Avro, которй предлагает какие-то новые фичи, которых не было до него.

На самом же деле, Iceberg - это некий протокол, который описывает договоренность по укладке файлов в хранилище, чтобы потом эти файлы можно было удобно с хранилища поднимать и выполнять к ним запросы. При этом сами файлы, которые физичеки находятся на диске, имеют уже знакомые форматы: Parquet, Avro или ORC. Рядом с файлами данных лежат статистики - отдельные файлы, в которых описано их содержимое: максимумы, распределения, количество и т.п.

Команда Iceberg написала реализацию протокола для некоторых движков (вот, например, jar для Apache Spark 3), что позволило достаточно комформтно начать работать работать с новым форматом на имеющихся инсталяциях этих самых движков. По сути, администратору нужно добавить пару библиотек и дать доступ к бакету S3, чтоб начать использование.

Пощупать Iceberg локально в связке со с Spark можно с помощью Docker и нехитрой инструкции из официальной документации: https://iceberg.apache.org/spark-quickstart/