Запрети мне псевдолейблить

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, можно значительно ускорить обработку данных и снизить затраты на вычисления. А еще можно каждый день дописывать новую партицию за день и не менять структуру файлов и избежать дублирования

История с продвижением математики вперед с помощью ML пока не закончилась Скоро будет онлайн-доклад от известного математического физика Сергея Гукова , где они решили один из вопросов в теории групп , который стоял 39 лет с помощью МЛ https://t.me/sberlogabig/514

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

Синематик видео очень классно перекликаются с возможностью послать видео в 911. Представляю как будут убедительно и профессионально выглядеть бомжи с ножами на этих видосах из архива полиции

Челы которым портировать торч и на Neural Engine и на iPhone GPU такие: FUUUUUUUUUUUUU...

Надеюсь сейчас представят айпад и он в виде щита капитана америка будет

Представляю как американцы будут с фоторужьями встречать грабителей и сразу слать в 911 видео огабления себя

РЕКЛАМА ВАРТАНДЕРА В ПРЕЗЕНТАЦИИ ЖДЕМ КАМЕО МОРГЕНШТЕРНА

Ура, эппл изобрели даггеротипию на афоне со своими Spatial Photo

Теория: эпл пролобировали посадку Дурова, чтобы он помог им убирать стену из уведомлений и переключить все на алгоритмическую ленту

Переписывание текста по запросу приведет к тому, что мы будем читать в 5 раз больше ненужного текста Генерация эмоджи будет использована только для рекламы ноготочков и кальянных. Скриньте

Приватный ЛЛМ на айфоне. Быстрее скорее. Скоро и правда будут подслушивать вас, чтобы продавать рекламу лучше

Все: У нас телефон без кнопок, это революция Apple: у нас теперь 4 кнопки, ват это революция

Надеюсь на аирподс про теперь можно слушать оздоровительный фонк в два раза здоровее

Надеюсь на AirPods можно будет хотя бы SD запускать

BeVIT на ваших эпл часах? А может лучше на роботе пылесосе? Эпл добавил neural engine в часы и обещают инференсить dense transformers

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

Снова про 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 и станет сильно понятнее

Сколько стоит политическая позиция админа