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


Kanal geosi va tili: Germaniya, Ruscha


Сутра:
1. Kaggle решат
2. Соревы обозреват
3. Gold фармить
4. Социальност
Канал о пути к Kaggle competitions Master, баварских сосисках и пиве, которым обливаешься в процессе
https://www.kaggle.com/asimandia
Для вопросов: @dimitriy_rudenko

Связанные каналы  |  Похожие каналы

Kanal geosi va tili
Germaniya, Ruscha
Statistika
Postlar filtri


Обновил превьюшку в тг. Вы вот знали, что тг один раз генерит превью для ссылки и потом не обновляет, пока не попросишь специального бота это сделать? В смысле старое превью моей ссылки на кэггл не обновлялось больше года :0
@WebpageBot


Прошел калибровку на 409 ранг


Сутра:
1. Kaggle решат
2. Соревы обозреват
3. Gold фармить
4. Социальност

Канал о пути к Kaggle competitions Master Grandmaster, баварских сосисках и пиве, которым обливаешься в процессе

https://www.kaggle.com/asimandia

Для вопросов: @dimitriy_rudenko


ВЫСТУПАЕМ НА ПРИВАТНОМ НИПСЕ


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


ЖДЕМ ЗАВТРА


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


GreySnow is following you


Во-вторых, теперь можно наконец-то нормально устанавливать пакеты через специальный интерфейс Package manager.

Представьте, теперь не надо создавать датасеты с source кодом и устанавливать все в ноутбук через магические команды jupyter. Самое полезное- это то, что теперь можно устанавливать пакеты в Code Competitions, когда код должен быть отправлен в ноутбуке, у которого нет доступа к интернету. Теперь код из Package Manager выполнится и установит нужные пакеты заранее и с интернетом. Кстати поддерживается только pip, никакого вам poetry и uv

Я очень давно ждал эту штуку, и теперь буду со всей силы ждать возможность качать данные не из tar.gz архива, а через что-нибудь с поддержкой разбивки частей архива и rsync или даже может быть с торрентов, потому что качать террабайт данных со скорость 5мб/сек одним большим куском- очень больно и слишком 2011. Тем более с текущей надежностью серверов с данными на каггле.

https://www.kaggle.com/discussions/product-feedback/532336tart


На Kaggle случилось два апдейта.

Во первых, следуя за гитом и прочими платформами выкатили награды и бейджи:

Награды это какие-то ДОСТИЖЕНИЯ.
Например за то, что я был хостом соревнования Инстамарта (Сбермаркета (Купера)) на стажировку, я получил от Kaggle награду. Еще вот Сергею Фиронову дали ачивку за топ 100.

Бейджи дают за более доступные штуки:
Возраст акаунта
Стрики логинов
Форк ноутбуков
etc

Жду сториз и удаление стены!

Полный список бейджей


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


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

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


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


adapt compete evolve or die dan repost
оверфит начинается с головы, а ощущается гораздо ниже


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




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


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

20 ta oxirgi post ko‘rsatilgan.