Полезное чтение про данные, технологии и не только։
Why I moved my dbt workloads to GitHub and saved over $65,000 [1] автор пишет о том что заменил облако dbt (продукт dbt cloud) на Github Actions и сэкономил много денег. Правда в комментариях ему пишут что мол автор, это же очевидно. Но про несколько важных выводом можно вспомнить։
1) Github - это теперь в первую очередь система управления разработкой и автоматизации задач и лишь во вторую хранилище кода. Как минимум с точки зрения бизнес модели.
2) Крупные инфраструктурные игроки могут достаточно легко подорвать бизнес open source сервисов вроде dbt, просто предлагая то же сильно дешевле. Кстати, пример с конфликтом лицензий Elastic тоже был из той же природы, когда Amazon давали аналогичный сервис значительно дешевле
The State of Data Testing [2] обзор состояния задач и подходов к тестированию данных. Автор сотрудник компании Datafold и текст в их блоге. Поскольку компания как раз на тестировании данных специализируется, то и акценты на их компетенциях. С другой стороны все перечисленные подходы действительно есть, а их data-diff [3] полезный продукт с открытым кодом для сравнения таблиц. Почему подходы не полны? Это всё та же ситуация с управляемыми и неуправляемыми источниками данных. Задачи корпоративной дата-инженерии чаще всего сводятся к работе с управляемыми источниками или в возможности воздействия на них в случаях ошибок в данных. Работа с общедоступными данными слишком часто означает ненадёжность источника, невозможность повлиять на качество данных привычными методами.
Ссылки:
[1] https://medium.com/@datajuls/why-i-moved-my-dbt-workloads-to-github-and-saved-over-65-000-759b37486001
[2] https://www.datafold.com/blog/the-state-of-data-testing
[3] https://github.com/datafold/data-diff
#data #readings #dataengineering #dataquality
Why I moved my dbt workloads to GitHub and saved over $65,000 [1] автор пишет о том что заменил облако dbt (продукт dbt cloud) на Github Actions и сэкономил много денег. Правда в комментариях ему пишут что мол автор, это же очевидно. Но про несколько важных выводом можно вспомнить։
1) Github - это теперь в первую очередь система управления разработкой и автоматизации задач и лишь во вторую хранилище кода. Как минимум с точки зрения бизнес модели.
2) Крупные инфраструктурные игроки могут достаточно легко подорвать бизнес open source сервисов вроде dbt, просто предлагая то же сильно дешевле. Кстати, пример с конфликтом лицензий Elastic тоже был из той же природы, когда Amazon давали аналогичный сервис значительно дешевле
The State of Data Testing [2] обзор состояния задач и подходов к тестированию данных. Автор сотрудник компании Datafold и текст в их блоге. Поскольку компания как раз на тестировании данных специализируется, то и акценты на их компетенциях. С другой стороны все перечисленные подходы действительно есть, а их data-diff [3] полезный продукт с открытым кодом для сравнения таблиц. Почему подходы не полны? Это всё та же ситуация с управляемыми и неуправляемыми источниками данных. Задачи корпоративной дата-инженерии чаще всего сводятся к работе с управляемыми источниками или в возможности воздействия на них в случаях ошибок в данных. Работа с общедоступными данными слишком часто означает ненадёжность источника, невозможность повлиять на качество данных привычными методами.
Ссылки:
[1] https://medium.com/@datajuls/why-i-moved-my-dbt-workloads-to-github-and-saved-over-65-000-759b37486001
[2] https://www.datafold.com/blog/the-state-of-data-testing
[3] https://github.com/datafold/data-diff
#data #readings #dataengineering #dataquality
Medium
Why I moved my dbt workloads to GitHub and saved over $65,000
What is dbt Cloud?
Интересное чтение про данные, технологии и не только։
- Writing Well: A Data Engineer’s Advantage [1] просто прекрасный совет который я могу повторять всем дата инженерам и разработчикам. Уметь писать тексты, документировать свою работу - это не софт скилл, это профессиональный левел ап.
- Here’s why your efforts to extract value from data are going nowhere [2] о том что если у данные у вас плохие то как ни старайся хорошего результата не будет и о том что кроме профессий data science и data engineering есть ещё профессия которой пока нет нормального названия, но по сути это люди которые производят данные. Их труд менее всего выпячивается, ценится и так далее. Значимость тексту придаёт и то что его автор Cassie Kozyrkov, Chief Decision Scientist в Google. Она там же активно продвигает The Data Cards playbook, о котором далее.
- The Data Cards Playbook [3] по-русски звучит как "карточки данных". Карточки данных - это структурированные резюме существенных фактов о различных аспектах наборов данных ML, необходимых заинтересованным сторонам на протяжении всего жизненного цикла проекта для ответственной разработки ИИ. Это сложный и концептуальный, но важный и интересный путь описания документации наборам данных для ИИ.
- Tabular Announcement [4] анонс стартапа Tabular предлагающего хранилище данных в виде таблиц Apache Iceberg и с поддержкой многих языков/инструментов запросов причём хранят данные в хранилище AWS S3 к которому пользователь даёт доступ, так что обещают отсутствие vendor lock-in. Кстати, отсутствие vendor lock-in часто звучит как преимущество в последнее время. Правда оно не распространяется на итоговое хранилище которое почти всегда AWS, Azure, GCS или Snowflake.
Ссылки։
[1] https://medium.com/@luukmes/writing-well-a-data-engineers-advantage-2fd08efaedb0
[2] https://towardsdatascience.com/heres-why-your-efforts-extract-value-from-data-are-going-nowhere-8e4ffacbdbc0
[3] https://sites.research.google/datacardsplaybook/
[4] https://tabular.io/blog/announcing-tabular/
#datatools #data #readings #dataengineering
- Writing Well: A Data Engineer’s Advantage [1] просто прекрасный совет который я могу повторять всем дата инженерам и разработчикам. Уметь писать тексты, документировать свою работу - это не софт скилл, это профессиональный левел ап.
- Here’s why your efforts to extract value from data are going nowhere [2] о том что если у данные у вас плохие то как ни старайся хорошего результата не будет и о том что кроме профессий data science и data engineering есть ещё профессия которой пока нет нормального названия, но по сути это люди которые производят данные. Их труд менее всего выпячивается, ценится и так далее. Значимость тексту придаёт и то что его автор Cassie Kozyrkov, Chief Decision Scientist в Google. Она там же активно продвигает The Data Cards playbook, о котором далее.
- The Data Cards Playbook [3] по-русски звучит как "карточки данных". Карточки данных - это структурированные резюме существенных фактов о различных аспектах наборов данных ML, необходимых заинтересованным сторонам на протяжении всего жизненного цикла проекта для ответственной разработки ИИ. Это сложный и концептуальный, но важный и интересный путь описания документации наборам данных для ИИ.
- Tabular Announcement [4] анонс стартапа Tabular предлагающего хранилище данных в виде таблиц Apache Iceberg и с поддержкой многих языков/инструментов запросов причём хранят данные в хранилище AWS S3 к которому пользователь даёт доступ, так что обещают отсутствие vendor lock-in. Кстати, отсутствие vendor lock-in часто звучит как преимущество в последнее время. Правда оно не распространяется на итоговое хранилище которое почти всегда AWS, Azure, GCS или Snowflake.
Ссылки։
[1] https://medium.com/@luukmes/writing-well-a-data-engineers-advantage-2fd08efaedb0
[2] https://towardsdatascience.com/heres-why-your-efforts-extract-value-from-data-are-going-nowhere-8e4ffacbdbc0
[3] https://sites.research.google/datacardsplaybook/
[4] https://tabular.io/blog/announcing-tabular/
#datatools #data #readings #dataengineering
Medium
Writing Well: A Data Engineer’s Advantage
How to write clear and concise emails as a data engineer
В рубрике интересного чтения про данные, технологии и не только։
- Reproducible Analytical Pipelines [1] методология построения воспроизводимых труб данных используемая командами правительства Великобритании. Например, с помощью такого подхода их статистическая служба сейчас создаёт так называемые быстрые индикаторы (fast indicators) в виде оперативных показателей реального времени с частотой обновления от 1 недели до 1 часа. [2]
- The Past, Present, and Future of Data Architecture [3] обзор современной архитектуры работы с данными, по сути краткое введение в Data Mesh. Мне многое нравится в этом подходе, data mesh дает акцент на хранении первичных данных и на систематизации/каталогизации данных, однако есть много усложняющих практических аспектов в том что все любят работать с данными и мало кто любит их документировать.
- How Ahrefs Saved US$400M in 3 Years by NOT Going to the Cloud [4] с одной стороны ничего нового, а с другой стороны очень конкретное напоминание что крупнейшие облачные сервисы - это очень удобно и очень дорого, если можно ими не пользоваться, то нужно ими не пользоваться.
Ссылки:
[1] https://analysisfunction.civilservice.gov.uk/support/reproducible-analytical-pipelines/
[2] https://dataingovernment.blog.gov.uk/2023/02/14/using-data-science-for-next-gen-statistics/
[3] https://medium.com/@diogo22santos/the-past-present-and-future-of-data-architecture-bd23dea0654b
[4] https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-by-not-going-to-the-cloud-8939dd930af8
#readings #data #dataengineering #uk #government
- Reproducible Analytical Pipelines [1] методология построения воспроизводимых труб данных используемая командами правительства Великобритании. Например, с помощью такого подхода их статистическая служба сейчас создаёт так называемые быстрые индикаторы (fast indicators) в виде оперативных показателей реального времени с частотой обновления от 1 недели до 1 часа. [2]
- The Past, Present, and Future of Data Architecture [3] обзор современной архитектуры работы с данными, по сути краткое введение в Data Mesh. Мне многое нравится в этом подходе, data mesh дает акцент на хранении первичных данных и на систематизации/каталогизации данных, однако есть много усложняющих практических аспектов в том что все любят работать с данными и мало кто любит их документировать.
- How Ahrefs Saved US$400M in 3 Years by NOT Going to the Cloud [4] с одной стороны ничего нового, а с другой стороны очень конкретное напоминание что крупнейшие облачные сервисы - это очень удобно и очень дорого, если можно ими не пользоваться, то нужно ими не пользоваться.
Ссылки:
[1] https://analysisfunction.civilservice.gov.uk/support/reproducible-analytical-pipelines/
[2] https://dataingovernment.blog.gov.uk/2023/02/14/using-data-science-for-next-gen-statistics/
[3] https://medium.com/@diogo22santos/the-past-present-and-future-of-data-architecture-bd23dea0654b
[4] https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-by-not-going-to-the-cloud-8939dd930af8
#readings #data #dataengineering #uk #government
dataingovernment.blog.gov.uk
Using Data Science for Next-Gen Statistics
As the 21st century progresses, using data effectively has become a priority for many organisations, including the Office for National Statistics (ONS). The ONS's unique focus, however, goes beyond just utilising data effectively. The organisations ultimate…
Из интересного про YTsaurus от Яндекса
- полноценный продукт для операций MapReduce, замена Hadoop'а для тех кто ещё его использовал
- внутри работа с ClickHouse, YDB и Apache Spark, ИМХО, интереснее всего использование ClickHouse, хотя и было бы интересно посмотреть на бенчмарки
- собственный аналог виртуальной файловой системы и хранилища метаданных Cypress
- собственные форматы хранения данных YSON и Skiff. YSON как замена JSON с несколькими дополнительными типами данных и Skiff как бинарный формат похожий на Protobuff.
- в опубликованном коде нет UI кроме командной строки и примеров кода, потенциальная возможность для стартапов по созданию онлайн сервисов с веб уи и настройкой под себя, как это со многими другими опен сорс продуктами по модели։ открытый код + облачная подписка? просто предположение
- особенность в том что он реально про данные большого объёма, условно от десятков терабайт, хотя в Success Stories приведены примеры с сотнями терабайт. Если работа идёт с меньшим объёмом данных, то скорее всего это будет overkill, а вот если объём и инфраструктура разумно велики, то надо пробовать.
По всем ощущениям продукт очень интересный, хочется в будущем увидеть более подробные его разборы на конкретных кейсах применения и сравнениями.
#opensource #datatools #dataops #dataengineering
- полноценный продукт для операций MapReduce, замена Hadoop'а для тех кто ещё его использовал
- внутри работа с ClickHouse, YDB и Apache Spark, ИМХО, интереснее всего использование ClickHouse, хотя и было бы интересно посмотреть на бенчмарки
- собственный аналог виртуальной файловой системы и хранилища метаданных Cypress
- собственные форматы хранения данных YSON и Skiff. YSON как замена JSON с несколькими дополнительными типами данных и Skiff как бинарный формат похожий на Protobuff.
- в опубликованном коде нет UI кроме командной строки и примеров кода, потенциальная возможность для стартапов по созданию онлайн сервисов с веб уи и настройкой под себя, как это со многими другими опен сорс продуктами по модели։ открытый код + облачная подписка? просто предположение
- особенность в том что он реально про данные большого объёма, условно от десятков терабайт, хотя в Success Stories приведены примеры с сотнями терабайт. Если работа идёт с меньшим объёмом данных, то скорее всего это будет overkill, а вот если объём и инфраструктура разумно велики, то надо пробовать.
По всем ощущениям продукт очень интересный, хочется в будущем увидеть более подробные его разборы на конкретных кейсах применения и сравнениями.
#opensource #datatools #dataops #dataengineering
Полезное чтение про данные, технологии и не только:
- Microsoft Intelligence platform data integration plan [1] план обновлений сервисов в Microsoft Intelligence platform на апрель-сентябрь 2023 года. Там много изменений полезных для тех кто пользуется их платформой
- Life after orchestrators [2] автор делится мыслями о том как работать с оркестраторами данных и без них. Автор рекламирует сервис Popsink [3], но сам пост содержит и вполне здравые мысли (не рекламу). Действительно оркестраторы нужны не везде и не всегда.
- Introducing Segment Anything: Working toward the first foundation model for image segmentation [4] - модель и данные по сегментации изображений от Meta AI, набор данных, кстати большой, более 11 миллионов изображений
- Datasets for Advancing AI Research [5] другие наборы данных для машинного обучения от Facebook. С ручной разметкой, большого объёма и тд. Не полноценный каталог данных, а интегрировано в их сайт по ИИ, но в целом оформлено неплохо и, главное!, это содержание.
- Data Modeling – The Unsung Hero of Data Engineering: An Introduction to Data Modeling (Part 1) [6] про моделирование данных в блоге Airbyte, хороший текст как вводный и явно с продолжением.
- Vicuna: An Open-Source Chatbot Impressing GPT-4 with 90%* ChatGPT Quality [7] просто какая-то эпидемия (шутка) языковых моделей которые делаются маленькими ресурсами и приближающимися по качеству к ChatGPT и GPT-4. Вот и свежий открытый продукт. Похож на Alpaca, обучали его ещё дешевле, всего за $300.
Ссылки:
[1] https://learn.microsoft.com/en-us/power-platform/release-plan/2023wave1/data-integration/
[2] https://stkbailey.substack.com/p/life-after-orchestrators
[3] https://www.popsink.com/
[4] https://ai.facebook.com/blog/segment-anything-foundation-model-image-segmentation/
[5] https://ai.facebook.com/datasets/
[6] https://airbyte.com/blog/data-modeling-unsung-hero-data-engineering-introduction
[7] https://vicuna.lmsys.org/
#readings #data #ai #datatools #machinelearning #dataengineering
- Microsoft Intelligence platform data integration plan [1] план обновлений сервисов в Microsoft Intelligence platform на апрель-сентябрь 2023 года. Там много изменений полезных для тех кто пользуется их платформой
- Life after orchestrators [2] автор делится мыслями о том как работать с оркестраторами данных и без них. Автор рекламирует сервис Popsink [3], но сам пост содержит и вполне здравые мысли (не рекламу). Действительно оркестраторы нужны не везде и не всегда.
- Introducing Segment Anything: Working toward the first foundation model for image segmentation [4] - модель и данные по сегментации изображений от Meta AI, набор данных, кстати большой, более 11 миллионов изображений
- Datasets for Advancing AI Research [5] другие наборы данных для машинного обучения от Facebook. С ручной разметкой, большого объёма и тд. Не полноценный каталог данных, а интегрировано в их сайт по ИИ, но в целом оформлено неплохо и, главное!, это содержание.
- Data Modeling – The Unsung Hero of Data Engineering: An Introduction to Data Modeling (Part 1) [6] про моделирование данных в блоге Airbyte, хороший текст как вводный и явно с продолжением.
- Vicuna: An Open-Source Chatbot Impressing GPT-4 with 90%* ChatGPT Quality [7] просто какая-то эпидемия (шутка) языковых моделей которые делаются маленькими ресурсами и приближающимися по качеству к ChatGPT и GPT-4. Вот и свежий открытый продукт. Похож на Alpaca, обучали его ещё дешевле, всего за $300.
Ссылки:
[1] https://learn.microsoft.com/en-us/power-platform/release-plan/2023wave1/data-integration/
[2] https://stkbailey.substack.com/p/life-after-orchestrators
[3] https://www.popsink.com/
[4] https://ai.facebook.com/blog/segment-anything-foundation-model-image-segmentation/
[5] https://ai.facebook.com/datasets/
[6] https://airbyte.com/blog/data-modeling-unsung-hero-data-engineering-introduction
[7] https://vicuna.lmsys.org/
#readings #data #ai #datatools #machinelearning #dataengineering
Docs
Overview of data integration 2023 release wave 1
Полезное чтение про данные, технологии и не только:
- 🌶 Hot Takes on the Modern Data Stack [1] - несколько интересных мыслей про современный стек данных, особенно актуально для тех кто работает с этими сервисами регулярно
- 🗄 How we made our reporting engine 17x faster [2] про ускорение системы отчётов в 17 раз через миграцию на движок BigQuery (облачный сервис Google). Любопытно, технические подробгости
- 💭 The new philosophers. How the modern data stack falls out of fashion. [3] у Benn Stancil размышления о том что развитие ИИ изменит существующий ландшафт продуктов по работе с данными и что к этому надо быть готовыми. Он же о том что Modern Data Stack и Generative AI плохо совместимые идеологии.
- 🗂 Using DuckDB with Polars [4] автор пишет про комбинацию этих двух новых инструментов, комбинация хорошая, надо брать
- 💰 Announcing Cybersyn’s $62.9M Series A [5] стартап Cybersyn по предоставлению доступа к открытым госданным через Snowflake поднял $62.9 инвестиций. Можно им только позавидовать, я для нашего сервиса Datacrafter всё ещё ищу инвестиции. Видимо надо делать сразу на маркетплейсы и не в России;) А Cybersyn стартап интересный, инвестиции для этого рынка большие.
Ссылки:
[1] https://mattpalmer.io/posts/hot-takes/
[2] https://medium.com/teads-engineering/how-we-made-our-reporting-engine-17x-faster-652b9e316ca4
[3] https://benn.substack.com/p/the-new-philosophers
[4] https://towardsdatascience.com/using-duckdb-with-polars-e15a865e48a3
[5] https://www.cybersyn.com/blog-series-a/
#opensource #startups #readings #data #dataengineering
- 🌶 Hot Takes on the Modern Data Stack [1] - несколько интересных мыслей про современный стек данных, особенно актуально для тех кто работает с этими сервисами регулярно
- 🗄 How we made our reporting engine 17x faster [2] про ускорение системы отчётов в 17 раз через миграцию на движок BigQuery (облачный сервис Google). Любопытно, технические подробгости
- 💭 The new philosophers. How the modern data stack falls out of fashion. [3] у Benn Stancil размышления о том что развитие ИИ изменит существующий ландшафт продуктов по работе с данными и что к этому надо быть готовыми. Он же о том что Modern Data Stack и Generative AI плохо совместимые идеологии.
- 🗂 Using DuckDB with Polars [4] автор пишет про комбинацию этих двух новых инструментов, комбинация хорошая, надо брать
- 💰 Announcing Cybersyn’s $62.9M Series A [5] стартап Cybersyn по предоставлению доступа к открытым госданным через Snowflake поднял $62.9 инвестиций. Можно им только позавидовать, я для нашего сервиса Datacrafter всё ещё ищу инвестиции. Видимо надо делать сразу на маркетплейсы и не в России;) А Cybersyn стартап интересный, инвестиции для этого рынка большие.
Ссылки:
[1] https://mattpalmer.io/posts/hot-takes/
[2] https://medium.com/teads-engineering/how-we-made-our-reporting-engine-17x-faster-652b9e316ca4
[3] https://benn.substack.com/p/the-new-philosophers
[4] https://towardsdatascience.com/using-duckdb-with-polars-e15a865e48a3
[5] https://www.cybersyn.com/blog-series-a/
#opensource #startups #readings #data #dataengineering
mattpalmer.io
Hot Takes on the Modern Data Stack
My take on the state of the modern data stack in 2023.
Пока мы тут обсуждаем кого ИИ лишит профессии, спешу сказать что разработчикам и инженерам не стоит надеяться на скорое исчезновение их профессий (что хорошо) и даже на то что ИИ очень сильно облегчит жизнь (что не так хорошо). Почему? Потому что большую часть инженеров и разработчиков что я знаю на реальных продуктах и проектах - это отладка и legacy, это разгребание накопленного непотребства, создание кривых подпорок из кривых подпорок и ещё много чего. За исключением очень редких уникальных случаев когда это не так. ИИ может лишить интересной работы по созданию чего-то абсолютно с нуля и ещё сильнее усложнить переход разработчиков из джунов в миддлы, потому что чуть ли не главные их отличия - это умение работать самостоятельно и самостоятельно вести отладку.
#ai #profession #dataengineering
#ai #profession #dataengineering
Про сжатие данных и о том почему я регулярно пишу что Parquet - это реально значимый формат хранения и обмена данными, важнее довольно многих.
Я приведу в пример данные с которыми я лично работал в аналитических задачах. У меня есть выгрузка слепка данных из российского реестра юридических лиц ЕГРЮЛ в виде 11 миллионов записей в которых 12 полей-признаков места организации, её типа, кода окопф, оквэд, кладр, статус ликвидации и тд. Без названий и без идентификаторов, данные нужны только для аналитической работы и построения кубов и срезов для BI. В общеё сложности - это 4.07ГБ. Не очень много когда один файл и много когда таких файлов десятки. С файлом нужно иметь возможность работать, загружать в СУБД или библиотеку вроде Pandas. Как сжать эти данные?
Самое очевидное - это сжать классическими архиваторами и хранить так. Gzip даёт сжатие до 337 МБ это примерно 8.3%, альтернативный Gzip'у архиватор LZ4 для быстрого сжатия и разжатия даёт компрессию до 340МБ это тоже примерно 8.3%, а LMA-архивация с помощь. XZ даёт 136МБ это примерно 3%, но она работает значительно медленнее. Все архиваторы проверялись в режиме максимального сжатия (ключ -9).
Так вот, а если этот же CSV файл преобразовать в parquet формат со сжатием, то итоговый файл получается размером в 109МБ, это примерно 2.7% от оригинального и, при этом, с ним весьма удобно работать с инструментами вроде Pandas при том что скорость преобразования значительно быстрее чем сжатие с помощью xz, к примеру. Во многом, похоже, это происходит из-заавтоматической идентификации типов полей и их преобразования.
Причём даже если повторить используемый в parquet трюк с колоночным сжатием, так просто такой результат повторить непросто. Например, у меня есть код который из CSV файла создаёт пучёк одноколоночных CSV файлов сжатие которых по отдельности должно быть лучше чем сжатие оригинального файла. Сжатые одноколоночные файлы дают дополнительное сжатие. GZIP файлы таких файлов занимают 221 МБ вместо 337 МБ. Аналогично для lz4 и только для xz размер общий файлов увеличивается до 139 МБ.
Конечно никто такие одноколочные файлы не делает, это трюк из давнего прошлого, я привожу его исключительно как иллюстрацию. Речь о том что Parquet файл значительно меньше и практичнее в общим случаях.
Отдельная история про сжатие данных для долгосрочного хранения и для сохранения интеграции с унаследованными системами. Тем не менее, имея выбор формата для хранения данных - Parquet это хороший выбор.
Для того чтобы он стал отличным ему нехватает только некоторых опций работы стандартными инструментами. Чтобы его можно было открыть в Excel, в браузере, в чтобы были аналоги grep/cat/awk/sed или csvkit и ещё много разных других инструментов. Тем не менее и сейчас его уже можно использовать.
#dataengineering #data #compression #parquet
Я приведу в пример данные с которыми я лично работал в аналитических задачах. У меня есть выгрузка слепка данных из российского реестра юридических лиц ЕГРЮЛ в виде 11 миллионов записей в которых 12 полей-признаков места организации, её типа, кода окопф, оквэд, кладр, статус ликвидации и тд. Без названий и без идентификаторов, данные нужны только для аналитической работы и построения кубов и срезов для BI. В общеё сложности - это 4.07ГБ. Не очень много когда один файл и много когда таких файлов десятки. С файлом нужно иметь возможность работать, загружать в СУБД или библиотеку вроде Pandas. Как сжать эти данные?
Самое очевидное - это сжать классическими архиваторами и хранить так. Gzip даёт сжатие до 337 МБ это примерно 8.3%, альтернативный Gzip'у архиватор LZ4 для быстрого сжатия и разжатия даёт компрессию до 340МБ это тоже примерно 8.3%, а LMA-архивация с помощь. XZ даёт 136МБ это примерно 3%, но она работает значительно медленнее. Все архиваторы проверялись в режиме максимального сжатия (ключ -9).
Так вот, а если этот же CSV файл преобразовать в parquet формат со сжатием, то итоговый файл получается размером в 109МБ, это примерно 2.7% от оригинального и, при этом, с ним весьма удобно работать с инструментами вроде Pandas при том что скорость преобразования значительно быстрее чем сжатие с помощью xz, к примеру. Во многом, похоже, это происходит из-заавтоматической идентификации типов полей и их преобразования.
Причём даже если повторить используемый в parquet трюк с колоночным сжатием, так просто такой результат повторить непросто. Например, у меня есть код который из CSV файла создаёт пучёк одноколоночных CSV файлов сжатие которых по отдельности должно быть лучше чем сжатие оригинального файла. Сжатые одноколоночные файлы дают дополнительное сжатие. GZIP файлы таких файлов занимают 221 МБ вместо 337 МБ. Аналогично для lz4 и только для xz размер общий файлов увеличивается до 139 МБ.
Конечно никто такие одноколочные файлы не делает, это трюк из давнего прошлого, я привожу его исключительно как иллюстрацию. Речь о том что Parquet файл значительно меньше и практичнее в общим случаях.
Отдельная история про сжатие данных для долгосрочного хранения и для сохранения интеграции с унаследованными системами. Тем не менее, имея выбор формата для хранения данных - Parquet это хороший выбор.
Для того чтобы он стал отличным ему нехватает только некоторых опций работы стандартными инструментами. Чтобы его можно было открыть в Excel, в браузере, в чтобы были аналоги grep/cat/awk/sed или csvkit и ещё много разных других инструментов. Тем не менее и сейчас его уже можно использовать.
#dataengineering #data #compression #parquet
Benn Stancil наиболее точно описал новый продукт от Microsoft как Microsoft builds the bomb [1] про их новый продукт Fabric. Для всех кто пользуется стеком Microsoft повседневно, особенно для компаний сидящих на их облачных продуктах - это находка. Причём я согласен с Беном что продукты у Microsoft могут быть очень далеки от идеала, но благодаря критической массе корпоративных клиентов и тому что именно у таких клиентов есть деньги и предпочтение унифицированным платформам, то у Fabric хорошее будущее. Остальные платформы (Google, AWS) могут пойти таким же путём и начать добивать Modern Data Stack состоящий из очень хороших, но фрагментированных инструментов.
Неспроста многие в последнее время говорят и пишут о том что профессия инженера-данных превращается в профессию инженера платформ работы с данными. Всё это, разумеется, не про российские реалии, а про мировую тенденцию.
Ссылки:
[1] https://benn.substack.com/p/microsoft-builds-the-bomb
#dataengineering
Неспроста многие в последнее время говорят и пишут о том что профессия инженера-данных превращается в профессию инженера платформ работы с данными. Всё это, разумеется, не про российские реалии, а про мировую тенденцию.
Ссылки:
[1] https://benn.substack.com/p/microsoft-builds-the-bomb
#dataengineering
benn.substack
Microsoft builds the bomb
What Fabric is, and what I want it to be.
Свежий State of Data Engineering report 2023 от LakeFS [1].
Не очень детальный, на мой взгляд, не тянущий на полноценный State of ... доклад, но содержащий полезные факты и тезисы и упоминания некоторых продуктов про которые я лично не слышал или когда-то видел, но не впечатлившись отложил на потом.
Отчет короткий поэтому прочитать его несложно в любом случае.
Ссылки:
[1] https://lakefs.io/blog/the-state-of-data-engineering-2023
#dataengineering #startups #reports
Не очень детальный, на мой взгляд, не тянущий на полноценный State of ... доклад, но содержащий полезные факты и тезисы и упоминания некоторых продуктов про которые я лично не слышал или когда-то видел, но не впечатлившись отложил на потом.
Отчет короткий поэтому прочитать его несложно в любом случае.
Ссылки:
[1] https://lakefs.io/blog/the-state-of-data-engineering-2023
#dataengineering #startups #reports