Снова про Polars.
Очень рекомендую подкаст для свободных слушателей на английском о том, как библиотека построена с точки зрения Rust сообщества:
Spotify: https://open.spotify.com/episode/7CrTW3a3X2Kd2q6at3LsJW?si=xqIHROIlTKut5fYCKcda_Q
Self-hosted: https://rustacean-station.org/episode/ritchie-vink/

Вот пока слушал подкаст еще раз вдохновился всем объяснить почему polars круто и быстро.

Polars — это такая попытка взять лучшее из Spark и Pandas. Если грамотно спроектировать пайплайн на Polars, то можно обрабатывать данные без смены технологии до тех пор, пока они помещаются на физическую машину. Представьте: вытянуть кучу данных из S3-хранилища, выполнить сложные преобразования и вернуть их обратно, как на Spark, но при этом дебажить и экспериментировать с пайплайном можно так же быстро, как на Pandas. В итоге, это еще и работает быстрее, чем Pandas.

Достигается все известным трюкам, просто вынесенным в Python-интерфейс и выполняемым локально, а не на далекой и сложной для дебага JVM в облаке с множеством уровней доступа и доступ-привратниками Data Lake, которые тайно молятся Adeptus Mechanicus уже пять поколений.

Первый кирпичик — это ленивое вычисление (lazy evaluation). В Pandas для выполнения одной операции условно есть два пути: использовать исключительно Python-движок (так никто не делает, но можно), что, конечно, медленно. Второй вариант — конвертировать данные в Cython и обрабатывать их с его помощью. Для этого нужно сначала выести строгие типы данных, сконвертировать данные в них, подобрать нужный кусочек Cython-кода, выполнить вычисления, а затем сконвертировать данные обратно в Python-объекты и вернуть результат. Автоматически и без головной боли, но надо так делать для каждой операции, а их у нас в пайплайне могут быть сотни.

Ленивое вычисление позволяет уменьшить этот оверхед на конверсии данных туда и обратно. Сначала мы описываем все преобразования в пайплайне, затем по этому пайплайну строится граф вычислений, который компилируется в Rust и исполняется. Вдобавок, прямо из коробки идут два дополнительных преимущества: до компиляции граф можно оптимизировать и распараллелить на многопоточность с помощью очередей. Это позволяет выполнить меньше операций, а время выполнения сделать быстрее, потому что в среднем можем больше вычислительных ресурсов эффективно утилизировать в единицу времени.

Второй кирпичик — это стриминг (streaming). Предположим, данных стало существенно больше или ресурсов стало меньше. Классический пример: вам на Kaggle дали 250 ГБ таблиц для расчета фичей для вашего ML. У вас есть 32 ГБ ОЗУ, так что все эти таблицы вместе в память не влезут. Обычно решение выглядит так: мы считаем одну группу фич, сохраняем их в памяти для финального этапа (или пишем в CSV), и, ловко оперируя gc.collect() и del, выбрасываем ненужные промежуточные куски из памяти Python. Получается неудобно и костыльно.

Стриминг позволяет сделать что-то подобное, но интеллектуально и автоматически. Polars строит индекс по таблицам и разбивает все данные на части, не загружая их полностью в память. Затем вычисляет связи между этими батчами и оптимизирует граф их взаимодействий так, чтобы в самом "широком по памяти" месте графа использовать не более доступной памяти, но при этом обрабатывать каждый батч как можно быстрее. И только после этого читает каждый индексированный батч данных с диска, обрабатывает его и выполняет вычисления до конца пайплайна. А если вдруг где-то не хватит места, то Polars может притормозить и дампнуть какой-нибудь батч на диск, чтобы обработать прочие. Это можно сравнить с тем, как если нужно выкопать яму, вместо попытки сразу сдвинуть тонну песка, можно впятером быстро перекидать его лопатами. Только представьте, как это шикарно дружится с Parquet!

Если представить не можете, ставьте 🤔️️️️️️. Напишу пост про Parquet и станет сильно понятнее

Сергей Фиронов завел свой канал. Если вы не в курсе кто это, вам тем более надо подписаться

https://news.1rj.ru/str/abacabadabacaba404

BeVIT на ваших эпл часах? А может лучше на роботе пылесосе?

Эпл добавил neural engine в часы и обещают инференсить dense transformers

Все, преза кончилась. Весь шитпост спрячу в первый пост. Спасибо, что были с нами

История с продвижением математики вперед с помощью ML пока не закончилась

Скоро будет онлайн-доклад от известного математического физика Сергея Гукова , где они решили один из вопросов в теории групп , который стоял 39 лет с помощью МЛ

https://news.1rj.ru/str/sberlogabig/514

Apache Parquet: как Twitter и Cloudera развивали дата инжиниринг

Apache Parquet начинался как совместный проект Twitter (ныне X) и Cloudera — компании, известной своими дистрибутивами Hadoop и инструментами для работы с ним. Многие, кто работал с Hadoop, вероятно, сталкивались с Cloudera и пользовались их решениями. Например, в Сбербанке используют их софт для обработки больших данных (Сбер за рекламу не платил, а мог бы).

Теперь давайте наглядно сравним Parquet с традиционным CSV-файлом, чтобы понять его преимущества. Возьмем простой пример CSV:

Имя, Пол, Год рождения, Вес, Рост, Дата записи
Владимир, М, 1954, 74, 179, 01/01/2024
Борис, М, 1931, 88, 187, 01/01/2024
None, М, None, 77, 178, 02/01/2024
Валерия, Ж, 1950, 150, 168, 02/01/2024

1. Колоночный формат
Первая ключевая особенность Parquet — это колоночное хранение данных. В CSV данные хранятся построчно, и для вычисления среднего значения, скажем, веса, вам нужно пройти по каждой строке, извлекая из нее данные. Это требует времени, особенно для больших наборов данных.

Parquet же хранит данные по колонкам. Сначала записываются все значения первой колонки, затем второй, и так далее. Например, для расчета среднего роста нужно считать только колонку с ростом, не затрагивая остальные данные. Это заметно ускоряет обработку.

Более того, в Parquet применяется метод сжатия RLE (Run Length Encoding), что эффективно для хранения повторяющихся значений и пропусков. Например:

Имя: (Владимир, [0]), (Борис, [1]), (Валерия, [3])
Пол: (М, [0, 1, 2]), (Ж,[3])

Таким образом, можно обрабатывать большие объемы данных быстрее и с меньшими затратами памяти. Библиотеки вроде Polars, благодаря колоночному формату, не будут загружать лишние данные при ленивых вычислениях, что делает их работу еще эффективнее.

Типизация данных, схемы и партиционирование
Каждый Parquet-файл сопровождается схемой, которая описывает структуру данных: какие есть поля, их типы, и где начинается блок с данными. Так как данные типизированы, можно сэкономить место. Например, колонку "Пол" можно хранить в виде числовых значений, а в схеме — просто словарь, который сопоставляет числа с реальными значениями ("М" и "Ж"). Помните, в CSV каждый символ весит минимум байт!

Теперь представим, что наш CSV-файл содержит миллиард строк. Это около 100 ГБ данных, что вполне помещается на обычный компьютер, но работать с таким файлом будет неудобно. Чтобы оптимизировать работу с большими данными, применяют партиционирование. Это разделение файла на несколько частей по какому-то признаку — например, по дате записи.

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

Parquet — это мощный инструмент для работы с большими объемами данных благодаря колоночному хранению, эффективным алгоритмам сжатия и возможностям партиционирования. Для задач, связанных с большими данными, Parquet сильно удобнее и быстрее, чем традиционный CSV. Используя такие библиотеки как Polars и Spark, можно значительно ускорить обработку данных и снизить затраты на вычисления. А еще можно каждый день дописывать новую партицию за день и не менять структуру файлов и избежать дублирования

Обожаю датавиз, особенно функциональный. У кого-нибудь есть пины на пинтересте с красивыми дашбордами?
Одно из самых крутых, что я видел- это вот это резюме:

Глупый телеграм пережимает, вот вам оригинал:
https://www.linkedin.com/posts/astratoanalytics_datadna-dataviz-datadna-activity-7003783958660292608-da5X?utm_source=share&utm_medium=member_desktop

Безумно красивая визаулизация опыта и плотность инофрмации на пиксель. А еще визуальная метафора роста крутая, хотя там не только рост на самом деле
Единственная проблема, что в резюме вложено непропорционально больше времени, чем потратит на него хоть какой-то рекрутер

Да в смысле вам не нравится. Объяснитесь!

ЖДЕМ ЗАВТРА


(а честнее 00:00 по гринвичу сегодня)

ВЫСТУПАЕМ НА НИПСЕ В ЭТОМ ГОДУ