Состоялся релиз Polars 2.0
Polars — Python-библиотека для работы с данными и популярная альтернатива pandas. В версии 2.0 улучшили производительность, расширили поддержку SQL и добавили новый тип данных.

Если подробнее: 
🔵Вызовы collect() к LazyFrame по умолчанию обрабатываются потоковым движком, чтобы снизить потребление памяти и ускорить работу. Это самое большое изменение и главная причина, почему эту версию назвали 2.0: из-за нее часть старых запросов может поломаться. 
🔵Обработка данных с выгрузкой на диск (out-of-core processing) будет включаться по умолчанию при использовании более чем 80% оперативной памяти. Сейчас эта возможность доступна для сортировок, оконных функций и некоторых других операций. Для join и group_by обещают добавить позже. 
🔵Polars 2.0 теперь еще лучше работает с SQL и, судя по результатам (почти всех) бенчмарков, обрабатывает запросы быстрее DuckDB и DataFusion. 
🔵Добавился новый тип данных Map — словарь Python, связывающий ключи со значениями. Позволяет получать значение по ключу, проверять наличие ключа, получать список ключей или значений и так далее. В Polars 1.0 для этого приходилось использовать более сложную и неудобную конструкцию.
🔵Polars стал строже к ошибкам — он быстрее их вылавливает и сообщает об этом пользователю. По словам разработчиков, это изменению особенно актуально в эпоху ИИ-кодинга.

В общем, новых функций не завезли и главная задача релиза — отказаться от некоторых устаревших решений и сделать Polars быстрее и удобнее без радикальных изменений. Команда проекта надеется, что выпуск версии 2.0 будет для пользователей скучным и пройдет без потрясений, но гайд по переходу на всякий случай подготовила.

4 уровня ИИ-осведомленности
Еще в апреле Андрей Карпаты (автор термина «вайбкодинг», если забыли) писал о том, как растет разница в понимании возможностей ИИ. Те, кто пользуется бесплатными версиями для простых задач, и те, кто пользуется платными моделями для работы и научной деятельности, говорят про ИИ на разных языках. 

Сейчас разрыв только вырос, и это больше не две разных группы, а резко сужающаяся воронка. По его прикидкам, она выглядит так: 
🔵~75% или 6 млрд людей с ИИ почти не сталкивались.
🔵~20% или 1-2 млрд — «казуалы», которые используют бесплатные продукты, с ИИ в общем знакомы, но глубоко в тему не погружены. Эти люди просят ChatPGT написать письмо, и больше им ничего особо не надо. 
🔵~0,2% или или 20 млн — профессионалы, которые активно используют ИИ для работы и видят, как он быстро он меняется и каковы его возможности. Они с помощью ИИ решают за несколько дней задачи, которые раньше отняли бы у них недели или месяцы. 
🔵~0,00006% или 5000 — это люди на самом острие ИИ-науки, у которых есть доступ к самым передовым системам. Они имеют дело с «роями» из множества агентов, решающих сложнейшие задачи, на которые у специалистов ушли бы годы.  

Движение по воронке обуславливается сложностью задач, уровнем доступа и тем, что во всех сферах ИИ одинаково полезен. Он наиболее востребован в программировании и математике, именно потому что именно там он показывает лучшие (и наиболее измеримые) результаты.

Получается, что сегодня ИИ — это одновременно и глуповатый чатбот, и стремительно развивающаяся, меняющая мир технология. 

А на каком уровне вы?

PostgreSQL 19 откладывается на ноябрь 
Новая версия должна была выйти в конце сентября/начале октября, но дату релиза сдвинули на 19 ноября. Также решили откатить почти 10 ранее анонсированных функций. Их перенесут, скорее всего, в PostgreSQL 20.

Почему так получилось, рассказал у себя в блоге один из главных контрибьюторов проекта Питер Айзентраут. Частично, конечно, в сложившейся ситуации можно обвинить человеческий фактор и банальные ошибки в коде, но повлияли и другие причины: 
🔵ИИ нашел множество багов — намного больше, чем тестировщики выловили бы своими силами. Среди них были и серьезные архитектурные дефекты, и пограничные случаи, которые постепенно всплывали бы на протяжении лет после релиза. Даже при том, что часть их починить относительно легко, в целом объем работы получился слишком большой.
🔵Vulnpocalypse («апокалипсис уязвимостей», найденных в софте благодаря ИИ) отвлек часть разработчиков от работы над Postgres. Из-за этого многие баги были обнаружены так поздно. Если бы у команды было больше времени и ресурсов, они могли исправить часть недочетов и, возможно, им не пришлось бы откатывать так много функций сразу. 

В общем, это был амбициозный релиз, который подвел неудачный тайминг. Но несмотря на эти сложности PostgreSQL 19 обещает быть интересным и привнесет несколько интересных новшеств — пусть и меньше, чем планировалось изначально (pg_plan_advice, кстати не порезали!).

Clickhouse на больших объемах данных: опыт основателя Tinybird
Tinybird — аналитическая платформа для разработчиков. Один из ее создателей поделился опытом, как он развернул и 5 лет поддерживал кластер Clickhouse, где хранились и обрабатывались петабайты данных, и не сошел с ума. 

В двух постах (первый, второй) он рассказал про архитектуру, хранение и загрузку данных, обновление и тестирование. 

Несколько любопытных мыслей:
🔵Традиционный подход к работе с большими данными предполагает деление кластера на шарды, но автор считает, что с этим лучше не спешить и не усложнять архитектуру. Tinybirds долго обходились без шардирования: увеличивали мощность отдельных серверов и добавляли реплики, когда росла нагрузка. 

🔵ClickHouse поддерживает zero-copy replication: реплики могут обращаться к данным, которые хранятся в других репликах, не копируя их. Хотя это экономит место в хранилище, в опен-сорсном ClickHouse этот подход реализован не слишком удачно и часто приводит к ошибкам или потере данных. Tinybird используют модифицированный вариант zero-copy replication, который разработали сами. Всем остальным автор рекомендует следить за сохранностью данных либо выбрать другой подход к хранению.

🔵Чтобы научиться обновлять кластер без критических ошибок, потери данных и падения производительности, команде проекта понадобилось 4 года. Это сложный процесс, который за один раз не построишь.

🔵Чтобы эффективно использовать ClickHouse (и заодно избежать неприятных сюрпризов во время обновления), надо читать исходный код.

Согласны с его выводами? 👀

20 лет отношений через призму данных
Если бы вам нужно было на графиках отобразить свою жизнь, как бы выглядел ваш дашборд? 

В этом посте от 2014 года автор показывает жизнь как таблицу, где каждая клеточка — это год, месяц или неделя. Пост старй, вы наверняка видели раньше эти таблички хотя бы раз. Один разработчик и инженер тоже их видел, и они ему не понравились. Он решил сделать свою версию, отражающую не число прожитых дней, а то, чем они были наполнены: эмоциями и общением с людьми.

🔵Он собрал историю чатов и активности из разных соцсетей и мессенджеров за 20 лет, очистил от совсем уж бессмысленных сообщений и классифицировал: с кем разговаривал, о чем, какая была эмоциональная окраска у диалога. С классификацией помогали LLM, но даже с их участием работы было много.
🔵Данные вывел на графики, по которым стало видно, как эволюционировали отношения с разными людьми: снижалась или росла частота сообщений, менялось фоновое настроение и даже словарный запас. У близких людей он часто похожий за счет общих интересов, шуток и выражений, которые в ходу в их круге общения. Но если они отдаляются со временем, то и словарный запас меняется и в нем становится меньше пересечений. 
🔵Частота, длина и содержание сообщений тоже отражают изменения в отношениях Например, с одним другом формат общения перешел от постоянных коротких переписок в течение дня к редким, но более содержательным диалогам несколько раз в месяц.

Зачем это все было надо? 
Во-первых, это было интересный челлендж — структурировать 1.2 млн сообщений из нескольких разных источников. 

Во-вторых, это была возможность не только посмотреть на свои отношения с людьми за 20 лет, но и на себя в них — например, автор заметил, что он любит давать советы.

Ну а в-третьих, это показало, из чего на самом деле складывается жизнь, кроме стандартной череды событий «родился, учился, женился». 

Стали бы так заморачиватся? Какие метрики и данные вы выбрали бы для себя — тоже отношения или что-нибудь другое?

Как SQLite учили работать в распределенных системах
SQLite — пример для нас всех. Это маленькая и легкая СУБД, которая создавалась изначально для небольших проектов и мобильных приложений, но потенциал у нее огромный и использовать ее можно где угодно, было бы желание. 

Например, в распределенных системах. Автор rqlite вспомнил, как создал свой проект и что было после него. 
🔵В 2014 году ему понадобилось создать небольшое реляционное хранилище для кластерной системы. Он решил взять SQLite и прикрутить к ней протокол консенсуса Raft. В это системе В кластере был лидер, через которого новые записи принимались и реплицировались на остальные узлы. Запись должно было принять большинство, если какой-то узел не мог этого сделать, он изолировался. Так появился rqlite — один из первых проектов такого плана, но не последний. 
🔵В 2017 компания Canonical разработала dqlite. Задача была похожей, а главное отличие было в способе использования. Если rqlite — это самостоятельный сервер БД, который запускается вместе с приложением, то dqlite — это встраиваемая библиотека.
🔵В 2021 году Litestream выбрали другой подход: не пытаться превратить SQLite в полноценную распределенную базу, а найти способ восстановить данные, если сервер выйдет из строя. Их решение — сохранять WAL SQLite в Amazon S3. 
🔵В 2022 появилась cr-sqlite, где записи независимо вносятся на несколько узлов, а потом синхронизируются. В libSQL разработчики вообще переписали движок СУБД и за счет этого сильно расширили функционал. Из этого проекта потом выросла Turso, которую купили Supabase. 
🔵Логичным следующим этапом стали облачные сервисы — например, Cloudflare D1.

В итоге можно сделать два ключевых вывода:
🔵Нет единого правильного способа создать распределенную систему. Подход зависит от задач и главной проблемы, которую вы хотите решить: например, обеспечить надежность, как в rqlite, или быстрое восстановление, как сделали Litestream.  
🔵За 12 лет проекты с распределенной SQLite прошли путь от open source-решений до платных облачных сервисов от больших корпораций. Видимо, это неизбежно происходит со всеми идеями в IT.

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

Депрессивные визуализации все растущего разрыва между богатыми и бедными — это неустаревающая классика. Инфографик на эту тему уже немало и рисовать не перестанут, наверное, никогда, но смотреть на них всегда интересно.

🔜 Сайт dreamagainusa — очередной пример, который показывает, как недостижимо далек даже относительно успешный и состоятельный американец от настоящего богатства. Чтобы увидеть вершину графика, где расположился 1% самых богатых людей страны, придется долго и упорно скроллить наверх — за это время как раз можно прочувствовать всю несправедливость этого разрыва.

Разыгрываем 3 билета на Матемаркетинг’26!
🔵 Как ИИ меняет работу аналитиков, маркетологов и продактов?
🔵 Как посчитать, сколько людей на самом деле используют ИИ в работе в вашей компании?
🔵 Как контролировать и проверять работу ИИ и можно ли ему вообще доверять?

Эти и другие вопросы обсудят на Матемаркетинге’26. Это одна из крупнейших технических конференций для аналитиков, продактов и маркетологов в РФ. В этом году посетителей ждут 100+ докладов, мастер-классов и разборов кейсов от спикеров из VK, Avito Tech, Сбера, Magnit Tech, ИТ-холдинга Т1, UIS, Лемана Тех, UX Rocket и других компаний.

Конференция пройдет 26 и 27 ноября в Москве, онлайн-день — 17 ноября. Подробности смотрите на сайте.

🔜 Билеты уже в продаже, но у вас есть шанс попасть на Матемаркетинг’26 бесплатно! Мы разыгрываем 3 билета — 2 онлайн и 1 офлайн для тех, кто в эти даты будет в Москве.

Чтобы принять участие, надо подписаться на канал и написать комментарий под этим постом: «Хочу онлайн-доступ» или «Хочу офлайн-билет» + рассказать, какие темы докладов вам наиболее интересны. 6 ноября мы выберем победителей с помощью рандомайзера.