https://vutr.substack.com/p/datahub-the-metadata-platform-developed
Хороший вводный пост про то, как устроен и эволюционировал DataHub (это который каталог данных).
У автора, на самом деле, оч неплохой блог и интересные посты, глубже, чем стандартная писака в инторнетах, с погружением в детали. Полистайте его блог, там много интересного.
@ohmydataengineer - канал "🕯 Труба Данных" который делится интересным блогом про датку
Хороший вводный пост про то, как устроен и эволюционировал DataHub (это который каталог данных).
У автора, на самом деле, оч неплохой блог и интересные посты, глубже, чем стандартная писака в инторнетах, с погружением в детали. Полистайте его блог, там много интересного.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
DataHub: The Metadata Platform Developed at LinkedIn
How did LinkedIn manage the data catalog at scale?
🔥5👍3💩3❤1
https://xtable.incubator.apache.org
Наплодили форматов разных для таблиц, кто это будет все вместе собирать? Iceberg, Hive, Hudi, Delta Lake и так далее.
У Apache теперь появился X Table, тулза чтобы синхронизировать метаданные среди этого всего зоопарка.
@ohmydataengineer - канал "🕯 Труба Данных" который держит обещание и не пишет про Iceberg (почти).
Наплодили форматов разных для таблиц, кто это будет все вместе собирать? Iceberg, Hive, Hudi, Delta Lake и так далее.
У Apache теперь появился X Table, тулза чтобы синхронизировать метаданные среди этого всего зоопарка.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
xtable.incubator.apache.org
Apache XTable™ (Incubating)
Apache XTable™ (Incubating) is a cross-table interop of lakehouse table formats Apache Hudi, Apache Iceberg, and Delta Lake. Apache XTable™ is NOT a new or separate format, Apache XTable™ provides abstractions and tools for the translation of lakehouse table…
🔥9👍4💩4🥱2❤1
В качестве пятничного юмора вашему вниманию представляется экспонат "Полочка" или что такое мутации в Clickhouse на больших объемах 😁
@ohmydataengineer
@ohmydataengineer
💩17😢7🔥3
https://dataengineeringcentral.substack.com/p/10-billion-row-challenge-duckdb-vs
Забавная статья о том, как сравнивали на одной машинке DuckDB, Polars и Daft и что из этого вышло. Первый так вообще какое-то время назад был из каждого утюга, но в итоге я пока не видел ни одного хорошо нагруженного production-ready решения. А в статье выше решение из коробки жиденько обделалось с датасетом на 16 гигов из Parquet. Причем в прошлом году, кажется, я читал пост этого же автора, с DuckDB были все те же проблемы с ООМ.
Конечно, тест можно было бы провести и поглубже, ну как минимум не один раз (для сравнения). Ну да ладно.
(По работе, возможно, предстоит потрогать Rust, поэтому и смотрю на статьи, связанные с обработкой данных и Растом)
Upd: в личные сообщения принесли дополнение к статье (by @dnbnero)
Статья немного странная.
Плюс когда стал перепроверять у себя - либо я что-то делаю не так, либо в статье заблуждение/ошибка/обман. Даже если брать сжатый parquet, строка в среднем весит 52 байта, что при 10 млрд записей никак не 16гб. А в оригинале утилита выдаёт несжатые файлы...
И в комментариях без меня написали, что зря ctas использовали в duckdb - он умеет запросы напрямую в с3 и паркеты запускать
@ohmydataengineer - канал "🕯 Труба Данных" напоминает, что модное и молодежное - не всегда... (ну вы поняли)
Забавная статья о том, как сравнивали на одной машинке DuckDB, Polars и Daft и что из этого вышло. Первый так вообще какое-то время назад был из каждого утюга, но в итоге я пока не видел ни одного хорошо нагруженного production-ready решения. А в статье выше решение из коробки жиденько обделалось с датасетом на 16 гигов из Parquet. Причем в прошлом году, кажется, я читал пост этого же автора, с DuckDB были все те же проблемы с ООМ.
Конечно, тест можно было бы провести и поглубже, ну как минимум не один раз (для сравнения). Ну да ладно.
(По работе, возможно, предстоит потрогать Rust, поэтому и смотрю на статьи, связанные с обработкой данных и Растом)
Upd: в личные сообщения принесли дополнение к статье (by @dnbnero)
Статья немного странная.
Плюс когда стал перепроверять у себя - либо я что-то делаю не так, либо в статье заблуждение/ошибка/обман. Даже если брать сжатый parquet, строка в среднем весит 52 байта, что при 10 млрд записей никак не 16гб. А в оригинале утилита выдаёт несжатые файлы...
И в комментариях без меня написали, что зря ctas использовали в duckdb - он умеет запросы напрямую в с3 и паркеты запускать
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
10 billion row challenge. DuckDB vs Polars vs Daft.
... just for fun.
👍9💩4❤3
https://vutr.substack.com/p/i-spent-6-hours-learning-apache-arrow
Долго для вас хранил мяготку, никому не отдавал, но пришло время - мне оч нравится этот блог и как статьи пишет автор в нем. Погружается достаточно глубоко в детали и очень все доступно поясняет. Как пример - как работает Apache Arrow.
Потыкайте в его блог, там еще очень много всяких интересных чтив.
@ohmydataengineer - канал "🕯 Труба Данных" не прячет от вас крутые блоги и статьи и не переписывает их своими словами
Долго для вас хранил мяготку, никому не отдавал, но пришло время - мне оч нравится этот блог и как статьи пишет автор в нем. Погружается достаточно глубоко в детали и очень все доступно поясняет. Как пример - как работает Apache Arrow.
Потыкайте в его блог, там еще очень много всяких интересных чтив.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
I spent 6 hours learning Apache Arrow: Overview
Why do we need a standard memory format for analytics workload?
❤26👍9💩3
https://www.uber.com/en-BG/blog/d3-an-automated-system-to-detect-data-drifts/
Статья 2-х годовалой давности, но все также интересная. О том как Uber работает с Data Drift для своих ML моделей.
@ohmydataengineer - канал "🕯 Труба Данных" это коротко и интересно.
Статья 2-х годовалой давности, но все также интересная. О том как Uber работает с Data Drift для своих ML моделей.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍3💩1
https://github.com/ClickHouse/ClickHouse/pull/71542
Я обещал ничего не рассказывать про Iceberg какое-то время, но такого обещания не было про Clickhouse.
Однако новость выше не могу пропустить!🔥
Clickhouse в процессе добавления поддержки Iceberg каталога (на скриншоте пример чтения из Apache Polaris)
@ohmydataengineer - канал "🕯 Труба Данных" не нарушает своих обещаний!.
Я обещал ничего не рассказывать про Iceberg какое-то время, но такого обещания не было про Clickhouse.
Однако новость выше не могу пропустить!
Clickhouse в процессе добавления поддержки Iceberg каталога (на скриншоте пример чтения из Apache Polaris)
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17💩3❤2👍2
https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-s3-tables-apache-iceberg-tables-analytics-workloads/
Ну что я могу поделать, если уже и Amazon подкидывает мне новости, которые я обещал не рассказывать? AWS выкатывает специальные Amazon S3 Tables бакеты, с нативной и встроенной поддержкой Apache Iceberg
По словам провайдера - specifically optimized for analytics workloads, resulting in up to 3x faster query throughput and up to 10x higher transactions per second compared to self-managed tables
@ohmydataengineer - канал "🕯 Труба Данных" все-таки иногда нарушает своих обещаний!.
Ну что я могу поделать, если уже и Amazon подкидывает мне новости, которые я обещал не рассказывать? AWS выкатывает специальные Amazon S3 Tables бакеты, с нативной и встроенной поддержкой Apache Iceberg
По словам провайдера - specifically optimized for analytics workloads, resulting in up to 3x faster query throughput and up to 10x higher transactions per second compared to self-managed tables
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Amazon
Announcing Amazon S3 Tables – Fully managed Apache Iceberg tables optimized for analytics workloads - AWS
Discover more about what's new at AWS with Announcing Amazon S3 Tables – Fully managed Apache Iceberg tables optimized for analytics workloads
❤13💩4👍2🔥2
Forwarded from Время Валеры
Интересные времена, оказывается разбивать данные на партиции в момент их заливки уже немодно, согласно Progressive Partitioning for Parallelized Query Execution in Google’s Napa
Внедрили динамическое партицирование для каждого запроса, потому что:
* Гранулярность партиций сильно зависит от конкретного запроса.
* Фиксированные партиции не справляются с перекошенным распределением данных и динамическими нагрузками.
Система использует прогрессивное партицирование, уточняя границы партиций итеративно до тех пор, пока не будет достигнута оптимальная гранулярность для запроса. Это позволяет балансировать между качеством разбиения и производительностью.
Как это работает?
1. Данные хранятся в LSM деревьях, где каждый апдейт добавляется в виде дельты (таких дельт в системе может быть тысячи).
2. Дельта - это иммутабельные (неизменяемые) снапшоты, и они образуются, когда данные из памяти (memtable) сбрасываются на диск. Вдобавок они отсортированы по ключам. Дельты попадают сначала в Level 0, где данные остаются отсортированными, но разные дельты могут перекрываться по ключам. Компактизация со временем переносит данные на следующий уровень, устраняя дублирование и перекрытия.
3. В каждой дельте есть свой B Tree индекс, позволяющий эффективно работать с широкими диапазонами ключей и выбирать нужную гранулярность в рамках дельты.
4. Min/max информация о ключах хранится как отдельные метаданные, позволяя быстро отфильтровать ненужные дельты еще до обхода B Tree.
5. Вместо того чтобы полагаться на статическое разбиение, система динамически партицирует данные в момент выполнения запроса.
В чем плюсы?
Быстрая запись: данные просто записываются в неизменяемые файлы (дельты), без затрат на реструктуризацию.
Эффективное чтение: запросы динамически получают оптимальные партиции, что минимизирует перекос нагрузки.
Масштабируемость: иерархическая структура B-деревьев и организация дельт позволяют LSM-деревьям работать с петабайтами данных и миллиардами запросов.
Этот подход помогает Google масштабировать свои хранилища, оставаясь гибкими и эффективными даже под нагрузкой в миллиарды запросов в день.
Интересно и неожиданно - не думал что партицирование будет динамическим, но логично.
Внедрили динамическое партицирование для каждого запроса, потому что:
* Гранулярность партиций сильно зависит от конкретного запроса.
* Фиксированные партиции не справляются с перекошенным распределением данных и динамическими нагрузками.
Система использует прогрессивное партицирование, уточняя границы партиций итеративно до тех пор, пока не будет достигнута оптимальная гранулярность для запроса. Это позволяет балансировать между качеством разбиения и производительностью.
Как это работает?
1. Данные хранятся в LSM деревьях, где каждый апдейт добавляется в виде дельты (таких дельт в системе может быть тысячи).
2. Дельта - это иммутабельные (неизменяемые) снапшоты, и они образуются, когда данные из памяти (memtable) сбрасываются на диск. Вдобавок они отсортированы по ключам. Дельты попадают сначала в Level 0, где данные остаются отсортированными, но разные дельты могут перекрываться по ключам. Компактизация со временем переносит данные на следующий уровень, устраняя дублирование и перекрытия.
3. В каждой дельте есть свой B Tree индекс, позволяющий эффективно работать с широкими диапазонами ключей и выбирать нужную гранулярность в рамках дельты.
4. Min/max информация о ключах хранится как отдельные метаданные, позволяя быстро отфильтровать ненужные дельты еще до обхода B Tree.
5. Вместо того чтобы полагаться на статическое разбиение, система динамически партицирует данные в момент выполнения запроса.
В чем плюсы?
Быстрая запись: данные просто записываются в неизменяемые файлы (дельты), без затрат на реструктуризацию.
Эффективное чтение: запросы динамически получают оптимальные партиции, что минимизирует перекос нагрузки.
Масштабируемость: иерархическая структура B-деревьев и организация дельт позволяют LSM-деревьям работать с петабайтами данных и миллиардами запросов.
Этот подход помогает Google масштабировать свои хранилища, оставаясь гибкими и эффективными даже под нагрузкой в миллиарды запросов в день.
Интересно и неожиданно - не думал что партицирование будет динамическим, но логично.
👍24💩2❤1
Помните, какое-то время назад просил заполнить опрос, на каких специалистов в публичном поле и каналы / блоги вы подписаны? Так вот NEWHR выпустили рейтинг и список.
В этом году ни в какие топы я не попал 😁, а в топе есть пара новых имен.
Если вам интересно посмотреть на полные рейтинги и списки экспертов из исследования можно тут.
@ohmydataengineer - канал "🕯 Труба Данных" вне всяких рейтингов!
В этом году ни в какие топы я не попал 😁, а в топе есть пара новых имен.
Если вам интересно посмотреть на полные рейтинги и списки экспертов из исследования можно тут.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
💩6👍4😢4
Пора подводить итоги 2024!
Вот тут год назад писал про свои цели. Посмотрим, что ж из этого вышло:
✔️ Рост каналов @ohmydataengineer и @career_works
Второй канал я удалил, потому что он что-то совсем меня не зажигал в течении года. Материалов копилось много, а обрабатывать их совершенно не было сил. Ну а Труба Данных выросла до 3600+, исполнив цель минимум. Так что можно сказать успех.
✔️ Полноценный релиз Data Catalog, Data Contracts и удалить Jenkins
Каталог появился, дата контракты тоже, да и на Airflow с Jenkins пошел полным ходом.
⚠️ Карьерные консультации
Продолжало идти само по себе. Но есть несколько хороших кейсов (+800 евро net в месяц на вакухе в Европе или +150 тыс. руб. net в России). В индивидуальных консультациях тоже все идет как идет. Не могу сказать, что цель провалена, но и что я достиг того, что планировал.
❌ Substack и материалы на английском языке
Так и не нашел смысла начать писать на английском языке. Точнее смысл то был, но цель снова не легла в душу, поэтому я ее всячески откладывал и прокрастинировал. В итоге удалил Substack так и не написав ни одной статьи.
❌ Выступление на конференции
Что-то в этом году не было ни сил, ни тем выступать. Также, к сожалению, не стало в живых Маши, моего постоянного куратора на SmartData и я не смог отойти от этого. BigData Londong тоже прошла мимо.
С точки зрения выполнения целей ставлю себе "почти удовлетворительно" - хотелось бы больше, масштабней, но не удалось. Однако почти все "неуспехи" удалось проработать с психологом или с ментором, поэтому следующий год должен быть обязательно продуктивней!
@ohmydataengineer
Вот тут год назад писал про свои цели. Посмотрим, что ж из этого вышло:
Второй канал я удалил, потому что он что-то совсем меня не зажигал в течении года. Материалов копилось много, а обрабатывать их совершенно не было сил. Ну а Труба Данных выросла до 3600+, исполнив цель минимум. Так что можно сказать успех.
Каталог появился, дата контракты тоже, да и на Airflow с Jenkins пошел полным ходом.
Продолжало идти само по себе. Но есть несколько хороших кейсов (+800 евро net в месяц на вакухе в Европе или +150 тыс. руб. net в России). В индивидуальных консультациях тоже все идет как идет. Не могу сказать, что цель провалена, но и что я достиг того, что планировал.
Так и не нашел смысла начать писать на английском языке. Точнее смысл то был, но цель снова не легла в душу, поэтому я ее всячески откладывал и прокрастинировал. В итоге удалил Substack так и не написав ни одной статьи.
Что-то в этом году не было ни сил, ни тем выступать. Также, к сожалению, не стало в живых Маши, моего постоянного куратора на SmartData и я не смог отойти от этого. BigData Londong тоже прошла мимо.
С точки зрения выполнения целей ставлю себе "почти удовлетворительно" - хотелось бы больше, масштабней, но не удалось. Однако почти все "неуспехи" удалось проработать с психологом или с ментором, поэтому следующий год должен быть обязательно продуктивней!
@ohmydataengineer
Please open Telegram to view this post
VIEW IN TELEGRAM
❤27👍12💩3
https://clickhouse.com/blog/a-simple-guide-to-clickhouse-query-optimization-part-1
Чем меньше SLA, тем быстрей должен работать Clickhouse, реальность моей текущей работы.
Поэтому приходится читать много про всякие оптимизации.
А тут и сам Clickhouse подвез прекрасную стартовую статью для этого. Просто следуйте за ходом мыслей в статье при анализе плана запроса и применяйте в своей работе.
Ах да, мое любимое, каждый раз забываю 🤪 - An easy rule of thumb for determining which columns are good candidates for LowCardinality is that any column with less than 10,000 unique values is a perfect candidate.
@ohmydataengineer - канал "🕯 Труба Данных" продолжает любить Clickhouse!
Чем меньше SLA, тем быстрей должен работать Clickhouse, реальность моей текущей работы.
Поэтому приходится читать много про всякие оптимизации.
А тут и сам Clickhouse подвез прекрасную стартовую статью для этого. Просто следуйте за ходом мыслей в статье при анализе плана запроса и применяйте в своей работе.
Ах да, мое любимое, каждый раз забываю 🤪 - An easy rule of thumb for determining which columns are good candidates for LowCardinality is that any column with less than 10,000 unique values is a perfect candidate.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
ClickHouse
A simple guide to ClickHouse query optimization: part 1
A beginner-friendly guide to spotting slow ClickHouse queries and applying basic optimization tips.
👍22🔥7💩2👎1🥱1
https://www.newsletter.swirlai.com/p/memory-in-agent-systems
Спустя почти год перерыва Swirl вернулся со своими статьями про ML, ML&Data Ops и AI. Достаточно доступным языком про эту тему пишет, с наглядными картинками.
Поговаривают в соцсеточках, что в этом году оч модно у бизнеса будут AI Agents, которые, как обычно обещают, заменят нас всех и мы пойдем грузить вагоны. Как пример - хорошая статья про то, как работает память у AI Agents.
@ohmydataengineer - канал "🕯 Труба Данных" продолжает расширять горизонты контента!
Спустя почти год перерыва Swirl вернулся со своими статьями про ML, ML&Data Ops и AI. Достаточно доступным языком про эту тему пишет, с наглядными картинками.
Поговаривают в соцсеточках, что в этом году оч модно у бизнеса будут AI Agents, которые, как обычно обещают, заменят нас всех и мы пойдем грузить вагоны. Как пример - хорошая статья про то, как работает память у AI Agents.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Swirlai
Memory in Agent Systems
In this article I outline my thoughts on implementation of memory in GenAI systems.
❤5👍4🔥3💩1
Возвращение легендарной рубрики на телеканале @ohmydataengineer!
"Пусть данные говорят сами за себя!"
"Пусть данные говорят сами за себя!"
🔥17😢2💩2👍1
https://arch.dev/blog/2025-the-dawn-of-the-ai-data-team/
Бла-бла-бла, AI всех заменит, подходы меняются, меняйся или умри.
Пожалуйста, не поддавайтесь этой истерике, в самой статье ж прям написано: The Foundation Remains Critical
Ничего ульра-прорывного именно в data engineering с появлением AI пока не произошло, вы ничего не пропустили.
Copilot и другие умные автокомплиты - это да. Вот это стоит взять на вооружение.
@ohmydataengineer - канал "🕯 Труба Данных" на страже хайпожорства!
Бла-бла-бла, AI всех заменит, подходы меняются, меняйся или умри.
Пожалуйста, не поддавайтесь этой истерике, в самой статье ж прям написано: The Foundation Remains Critical
Ничего ульра-прорывного именно в data engineering с появлением AI пока не произошло, вы ничего не пропустили.
Copilot и другие умные автокомплиты - это да. Вот это стоит взять на вооружение.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Matatika
Looking for Arch? | Matatika
Arch has now shutdown. Matatika is the new home of Meltano.
🔥17❤4👍3💩2🥱1
https://www.jetbrains.com/lp/devecosystem-2024/
Ежегодный очень большой отчет/исследования про языки программирования от JetBrains.
Все как обычно - TypeScript подъедает JavaScript, Rust все также всеми очень любим и все хотят на него переехать.
В базах данных правда нет разделения на OLAP / OLTP, поэтому самый популярный - MySQL, а у того же Snowflake или Clickhouse по 3% всего
AWS в 3 раза больше ближайшего конкурента, который оказывается Azure, а не GCP.
Почти 50% (или всего лишь 50%, не знаю как отреагировать) пользуются регулярно каким-то AI в разработке (Copilot, ChatGPT).
@ohmydataengineer - канал "🕯 Труба Данных" это больше чем просто канал про данные!
Ежегодный очень большой отчет/исследования про языки программирования от JetBrains.
Все как обычно - TypeScript подъедает JavaScript, Rust все также всеми очень любим и все хотят на него переехать.
В базах данных правда нет разделения на OLAP / OLTP, поэтому самый популярный - MySQL, а у того же Snowflake или Clickhouse по 3% всего
AWS в 3 раза больше ближайшего конкурента, который оказывается Azure, а не GCP.
Почти 50% (или всего лишь 50%, не знаю как отреагировать) пользуются регулярно каким-то AI в разработке (Copilot, ChatGPT).
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
JetBrains: Developer Tools for Professionals and Teams
Software Developers Statistics 2024 - State of Developer Ecosystem Report
Explore key software developer statistics for 2024 in the State of Developer Ecosystem Report. Trends, insights, and tools shaping the developer world
👍16💩5🥱1
https://www.getdbt.com/blog/dbt-labs-acquires-sdf-labs
dbt купили себе какой-то sdf.
Впервые слышу про эту штуку и так сразу и не скажу, что она делает. Но в англоязычном интернете все очень рады, говорят, что dbt будет работать "в 10 раз быстрей". Чему там правда работать быстрей, если основную нагрузку выполняет база.... Ну да ладно, мб я тупой.
@ohmydataengineer - канал "🕯 Труба Данных" который не в курсе что такое SDF!
dbt купили себе какой-то sdf.
Впервые слышу про эту штуку и так сразу и не скажу, что она делает. Но в англоязычном интернете все очень рады, говорят, что dbt будет работать "в 10 раз быстрей". Чему там правда работать быстрей, если основную нагрузку выполняет база.... Ну да ладно, мб я тупой.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
dbt Labs
dbt Labs acquires SDF Labs to advance analytics engineering | dbt Labs
dbt Labs has acquired SDF Labs to enhance analytics engineering solutions. Learn how this partnership strengthens the modern data stack.
👍20🥱7👎3💩2
https://www.qlik.com/us/news/company/press-room/press-releases/qlik-acquires-upsolver-to-deliver-low-latency-ingestion-and-optimization-for-apache-iceberg
Новость один в один как предыдущая
Qlik купил Upsolver.
Шо, кто, зачем, как....
Вот иногда читаешь новости, и даже не понял, что произошло.
@ohmydataengineer - канал "🕯 Труба Данных" который все еще не в курсе всех новостей!
Новость один в один как предыдущая
Qlik купил Upsolver.
Шо, кто, зачем, как....
Вот иногда читаешь новости, и даже не понял, что произошло.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
Qlik
Qlik Acquires Upsolver to Deliver Low-Latency Ingestion and Optimization for Apache Iceberg | Qlik Press Release
The acquisition expands Qlik’s end-to-end Data Integration platform for open lakehouses, delivering real-time data, optimization, and cost savings
💩7👎2🔥1🥱1
https://howqueryengineswork.com
Оч приятное и комфортное чтиво про то, как работают query engine (ну то есть вот та фигня, которая планирует и исполняет ваш запрос к базенке).
Описано все в общих словах, но достаточно детально.
@ohmydataengineer - канал "🕯 Труба Данных" предлагает вам написать свой движок запросов!
Оч приятное и комфортное чтиво про то, как работают query engine (ну то есть вот та фигня, которая планирует и исполняет ваш запрос к базенке).
Описано все в общих словах, но достаточно детально.
@ohmydataengineer - канал "
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18💩2❤1👍1