Состоялся релиз 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 лет, но и на себя в них — например, автор заметил, что он любит давать советы.

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

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