Where is data, Lebowski

😎😁 А какие у вас рабочие мемы ?
.
#meme

​​️⃣ Сортировка, не всё хорошо, что упорядочено!

При создании таблицы указывается набор полей по которым данные будут отсортированы и по которым создадутся индексы.

ORDER BY (param1, param2, ...., paramN)

А что здесь-то интересного:
- кол-во (можно же и 1 и 100500)
- выбор самих параметров (а чего выбирать-то? типы, категории, время, ...)
- взаимное расположение (что за чем должно следовать)

А что выбрать:
- обычно выбирают те, поля по которым таблица чаще всего фильтруется (у нас же индексы есть)

Кол-во полей:
- в пределах разумного, 3-5. Большое кол-во замедляет вставку + вызывает фоновый процесс мержей (нагружает CPU).

Хороший алгоритм для заполнения ORDER BY есть у altinity

Как расположить:
- дока говорит, что следует располагать поля по уменьшению кардинальности (то есть поля с меньшим кол-вом уникальных значений должны быть левее, например, пол, ос, страна и др) - это верно, тк при использовании такой фильтрации кол-во читаемых данных уменьшается минимум на 50%
- altinity добавляет: поля наиболее часто используемые при фильтрации следует располагать левее (например, дата)

Возникает противоречение: уникальных дней больше чем значений пола, но по дате фильтруются чаще -> в общем случае рекомендация будет такой:
сначала располагаем, что по чему чаще фильтруемся, далее в порядке уменьшения кардинальности, то есть для примера выше

ORDER BY (report_date, gender, ....)

На самом деле работать может и любая другая комбинация (gender, country, report_date, ...) или еще хуже (gender, country, ...., report_date) - главным критерием является
взаимное распределение значений, иными словам:
- за каждый день отчета есть все значения пола и все страны и их распределения между днями не различаются, то вариант с датой, указанной первой - ваш выбор 👍
- а вот если распределение день ото дня различается, то надо ресерчить - готовых решений нет.

Можно предложить визуальный пример: данные в файлах сортируются сначала по одному первому атрибуту, после по 2 и тд и при
одной и тоже фильтрации WHERE dt = '2025-10-06' and main = 'Clouds' будет прочитано разное кол-во строк:

!clickhouse-notes-order-by.png


Выбирайте правильное партиции и верный ORDER BY - и эффективные запросы не заставят себя ждать😉

#clickhouse
#order_by

​​💡 Sort (partition) me, if you can


Разрываем осеннюю непогоду 🍁 заметками про Clickhouse: немного наюнсов, связанных PARTITION BY и ORDER BY

Чуть-чуть тема затронута в посте О-Optimization, там дан инструмент для поиска
неоптимальности при запросах в Clickhouse.

Зачем все эти BY:
- PARTITION BY - ключ партицирования = физическое разделение данных на дисках, то данные для
разных партиций хранятся отдельно, это даёт 2 положительных эффекта:
- Partition pruning - техника, которая при построении плана запроса позволяет пропускать не нужные партции (которые не содержат запрашиваемых данных) -> меньше данных -> выше эффективность запроса
- обновление данных - возможно управлять сразу всей партицией (удалять DROP, обновлять\заменять\перемещать REPLACE/MOVE)
- ORDER BY:
- побочный эффект - данные отсортированы в указанном порядке -> некоторые агрегаты, join, оконки будут работать быстрее
- skipping indexes (скипающие индексы) - при построении плана запроса позволяют пропускать гранулы (блоки строк) -> меньше данных -> выше эффективность запроса

Подробности в доке partitions, а нас будут интересовать детали, которые никто и нигде не напишет,
если только шепотом расскажет 🤫
.
Выше показано, что и PARTITION и ORDER могут быть использованы для эффективной фильтрации данных в запросах, но порой можно
сильно споткнуться на этом:
- партиции есть, а запрос долгий
- индекс есть, а запрос долгий
- и даже поля из партиций и индексов используются в WHERE, а всё равно долго

В предыдущем посте показано как узнать о неоптимальности своего запроса = сравнить два вывода:

explain estimate select * from your_table
vs
explain estimate select * from your_table where ..... -- ваши условия

Если цифры в обоих случаях идентично, то что-то явно идет не так....
.

1️⃣ Поле партицирования: то, да не то!

Задать выражение для партиций можно множеством способов, например:
- года (toYYYY(..) или toStartOfYear)
- месяца (toYYYYMM(..) или toStartOfMonth)
- недели
- дни (можно явно report_date, можно неявно toDate(report_date))

Некоторые преобразования линейные (не меняют тип данных в зависимости от типов до и после, например, toDate или toStartOfWeek, по факту транкейт даты)
нелинейные (меняют тип данных, но смысл остается тем же, например, toYYYYMM).

Выбор поля партиционирования и выражения для него влияют на использование механизма Partition pruninng или нет: для нелинейных преобразований механизм не будет использован ☝️
Например, ddl:

PARTITION BY toYYYYMM(report_date)

Пользовательские запросы любых видов используются фильтрацию report_date или иные преобразования будут неэффективны, например:

select *
from your_table
where toDate(report_date) >= ....
-- toStartOfWeek(date) = ....
и тд

Хотя с точки зрения пользователя может наблюдаться явное непонимание, особенно когда фильтрация явно указывается по году (report_date >= toDate('2025-01-01'')).

Второй распространенный кейс (из области мисскоммуникаций): выражение в партиции использует datetime + в самой таблице есть явное поле date:

PARTITION BY toDate(report_datetime)

Пользователь может совершать логическую ошибку: использование report_date (партиции же по дням).

☝️ Описанное выше протестировано локально на clickhouse-server:25.9.2.1 и проблемы описанные с нелинейными преобразованиями не удалось вопроизвести, хотя есть рабочий r&d (для версии 24.3), подтверждающий, что
нелинейные преобразования отключают Partition pruning. Одно можно сказать точно:
- использование при фильтрации преобразования аналогично указанному в DDL даёт 100% гарантию эффективной фильтрации ✅

#clickhouse
#partition_by

# Refreshable materialized view (продолжение)

Ну как мне всё это мониторить 🖥

Для просмотра статуса по RMV существует системная таблица system.view_refreshes, дает представление:
- какие RMV есть
- последний успешный рефреш
- следующий рефреш
- ошибки
- и др.

Ошибки всегда интересно:
- удаляем таблицу-приемник _v2
- принудительно рефрешим cdc.openweathermap_raw_refreshmv_v2
- смотрим в мониторинг

SELECT exception
FROM system.view_refreshes
where view = 'openweathermap_raw_refreshmv_v2';

-- Code: 390. DB::Exception: Table openweathermap_raw_v2 doesn't exist.

Бинго 😎.

Вот такой новый функционал Clickhouse, следующим шагом ожидаем cron по расписанию ? (и Airflow уже больше не нужен 😉).
Признавайтесь используете: MV и\или RMV ?

#clickhouse
#refreshable_materialized_view

​​# Refreshable materialized view

.
💣 Что еще за Refreshable MV ?

Ранее были рассмотрены materialized view:
- MV 1
- MV 2

Clickhouse MV - аналог из мира реляционных СУБД - триггеры, некий код который запускается в момент вставки блока данных в таблицу. Обычно MV выполняеют роль
первичного processing данных (фильтрация некорректных значений, преобразование структуры (например из JSON -> FLAT) и др) со вставкой в целевую таблицу.

Начиная с версии Clickhouse 23.12 функционал MV расширили (скорее не расширили, а подвезли новый функционал 🚀):
- Refreshable materialized view (RMV) - это материализованные представления из мира реляционных субд, но с присущей Clickhouse изюминкой refreshable -> у них есть cron,
то есть они могут запускаться по расписанию - и это открывает отличные возможности по построению пайплайнов обработки.

За подробностями в доку 🧐
.
Для рассмотрения MV у нас был pipeline (переходим по ссылкам выше), кратко:
- python код который запускал запрос в Clickhouse, сам python код запускался каждые 5 минут Airflow (подошел бы и cron)

Брюки превращаются, брюки превращаются....:

CREATE MATERIALIZED VIEW cdc.openweathermap_raw_refreshmv
REFRESH EVERY 1 minute APPEND -- магия здесь 🧙‍♀️
TO cdc.openweathermap_raw -- приемная таблица осталась прежней
AS
SELECT record_timestamp,
     record_value
FROM (
SELECT toDateTime(now(), 'Europe/Moscow') AS record_timestamp, *
FROM url('https://api.openweathermap.org/data/2.5/weather?lat=%(lat)s&lon=%(lon)s&appid=%(appid)s&units=metric',
  JSONAsString, 'record_value String')
);

Пайплан стал проще (выкинули шедулер Airflow или cron, не выкинули, конечно, а его расположение переместилось внутрь Clickhouse):
RMV выполняет запрос каждую минуту (EVERY 1 minute) и добавляет данные в целевую таблицу APPEND.

Из возможностей:
- задание интервала выполнения (EVERY X <interval>)
- без указания таблицы-приемника нельзя
- APPEND \ без указания - добавляете записи в таблицу или перезаписываете данные в таблице

Интересен второй сценарий (перезапись данных), создаем RMV (без APPEND) и таблицу-приемник с _v2 (cdc.openweathermap_raw_refreshmv_v2, cdc.openweathermap_raw_v2)
и лезем в лог запросов system.query_log:

select type
  , event_date
  , event_time
  , query
  , tables
  , query_kind
  , ql.used_privileges 
from system.query_log ql 
where event_date >= today()
and hasAny(['cdc.openweathermap_raw_refreshmv_v2'], tables)
and type = 'QueryFinish'
order by event_time desc
limit 1

Что интересного:
- выполняемый запрос:

INSERT INTO cdc..tmp.inner_id.26366163-063f-4761-a990-ce80bd4253cf
...

Ага, Clickhouse вставляет данные во временную таблицу, но как данные по падают в целевую ??

- список прав для выполнения запроса немного проясняет что происходит под капотом

SELECT, DROP TABLE ON cdc._tmp_replace_f572fcd715528ac1_vyyrigbhb769007a
INSERT, CREATE TABLE ON cdc..tmp.inner_id.26366163-063f-4761-a990-ce80bd4253cf
SELECT, INSERT, CREATE TABLE, DROP TABLE ON cdc.*
TABLE ENGINE ON MergeTree
CREATE TEMPORARY TABLE ON .
INSERT(record_timestamp, record_value) ON cdc..tmp.inner_id.26366163-063f-4761-a990-ce80bd4253cf

Очень интересно, но ничего не понятно 🙃, на этом копание пока остановим, примерный сценарий:
- пересоздание временной таблицы
- вставка во временную таблицу
- replace данных в целевой таблице

Для любого сценария существует команда принудительного обновления:

SYSTEM REFRESH VIEW <rmv_name>;

#clickhouse
#refreshable_materialized_view

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

Не имею глубоких знаний в области рекомендашек, но на вскидку, как это можно сделать:
- наиболее частые действия (покупки, просмотры и тд)
- поиск ассоциативных правил ( когда товары покупают вместе, пиво+подгузники)
- поиск чего-то схожего или ближайшего ( меры бывают разные, например, косинусное расстояние)

Умную статью можно найти у ЯОбразования
.
На скрине пример рекомендашек в одной из магазинов ( по цветовой гамме, думаю разгадаете). Интересным показался наглядный пример несовершенства системы: клубника 🍓 -> яблоко 🍎. Из этого можно сделать прикидки какие фичи использует алгоритм

#recsys #наблюдение

📊Визуал/дизайн должен быть полезным
.
Не могу больше держать в себе, парочка примеров из реальной жизни, которые больше мешают:
1⃣ Black theme, которая ломает всё🤪
Если вы счастливый пользователь Airflow 2.10.x, то успели оценить возможность переключиться на темную тему, если нет, то пример цветовой схемы на скрине. Есть ощущение, что темный цвет просто наложен поверх, что меняет привычные цвета статусов тасок до неузнаваемости и неразличимости. А еще при перезагрузки страницы, сначала мелькает стандартная белая тема🤷‍♂
.
2⃣ QR на молоке: как думаете он для оплаты молока или даст вам ссылку на рекламу нового продукта? Путаюсь каждый раз
.
А какие примеры есть у вас?
#наблюдения

☕ Следующая, еда по рецепту deepseek

#ai

​​🍉 Принес парочку интересных кейсов поведения оптимизатора Greenplum - GPORCA

1️⃣ Плевать я хотел на тип данных

Дано:
1. Таблица партицированная по полю с типом timestamp

PARTITION BY RANGE (date)
    (
        START ('2025-01-01'::timestamp) INCLUSIVE
        END ('2026-01-01'::timestamp) EXCLUSIVE
        EVERY (INTERVAL '1 day')
    )

При таком отборе дат, оптимизатор отказывается делать Partition Selector:



wh

ere date >= date_trunc('month', date)

ps

: date_trunc('month', date) не меняет тип, он остается timestamp

Но вот так, отлично работает 🤷‍♂️:



where

 date >= date_trunc('month', date)::date



2️⃣

Упс, это вьюха

Дано:
1. Вьюха, объединяет через union all несколько таблиц
2. Каждая таблица партицирована по одному и тому же полю, допустим date

Partition Selector не работает:



where da

te >= '2025-01-01'::date
and data < '2025-02-01'::date


Но вот 

так, отлично взлетает:



where date

between '2025-01-01'::date and '2025-02-01'::date


При этом, 

на исходных таблицах оба варианта работают идентично, где логика, GPORCA?


#work #case #greenplum

​​🚫Разрешение без разрешения: красивая история

В любом бизнесе испокон веков присутствует элемент азарта. В 1962 году Фредерик Смит подготовил для семинара в Йельском уникверситете работу, где описал службу срочной курьерской доставки.

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

К счатью, Смит бы независимым предпринимателем, и там сама йельская работа стала заделом для службы Fedex, которую он основал в 1971 году. Кроме того, Смит был человеком азартным: когда некий банк отказался выдать остро необходимый кредит никому неизвестной компании, Смит взял последние 5000$ и поехал в Лас-Вегас. Он выиграл 27000$ в блек-джек и 24 из них потратил на топливо для перевозок.

Netflix не отправляет своих сотрудников в казино, но все же старается отчасти привить им авантюрный дух Фреда Смита.

Из воспоминаний:

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

Захотелось сыграть 🪙😉?

#netflix #norules

🚫Разрешение без разрешения

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

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

- N - компетентный сотрудник?
- Он способен принимать взвешенные решения?
- Могут ли его усилия положительно повлиять на работу компании/команды в целом?
- Достаточно ли он талантлив, чтобы работать в нашей команде?

Если вы ответили нет хотя бы на один вопрос, N необходимо уволить😳 (слишком резко), но если по всем пунктам да, отойдите в сторонку и дайте N самостоятельно принять решение.

Когда начальник отказывается от роли "последней инстанции", производительность растет, а инновационные процессы ускоряются.
.
Из одного разговора:

...Google, Amazon, Spotify, Airbnb, Netflix. Мы понятия не имеем, почему эти компании так быстро развиваются и перестраиваются. В общем, не знаю, что они пьют там у себя в Netflix, но нам нужно пить тоже самое, заключил он, подняв бокал

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

Естественно, не все идеи ваших сотрудников будут удачными, вероятнее всего при такой парадигме, ошибок станет больше.

В Netflix родился несложный алгоритм, которого могут придерживаться все сотрудники при наличии авантюрной идеи:
1️⃣ Найти несогласных или социализировать идею
2️⃣ Для большого проекта используй пробный шар
Этап похож на АВ тест или пробный запуск для небольшой доли аудитории с меньшим риском
3️⃣ Собери информацию и сделай ставку
Анализ информации с п1-2 и выбор решения
4️⃣ Выиграешь отпразнуй. Проиграешь - поделись опытом.
Выигрыш: показать, желательно публично, как вы рады, что сотрудник довел дело до конца, невзирая на ваши сомнения. Нужно послать четкий сигнал: "Вы были правы, я ошибался". Тогда сотрудники поймут, что спорить с начальством не только можно, но иногда иногда необходимо.

Проигрыш: Нет необходимости раздувать скандал или вздыхать "Я же знал, что этим кончиться". Следует использовать следующий алгоритм:
- какие уроки можно извлечь из проекта
- не раздувайте скандал
- попросите поделиться опытом

#netflix #norules

Как это ты пойдешь гулять, а спросить Разрешения😈


#netflix #norules

Продолжаем мемное настроение! 😎


#мем #пятничный_мем

А как вы дорабатываете свои инструменты?

#мем #пятничный_мем

🤑 Предлагай больше всех
.
Второе правило про деньги и, кажется, самое рискованное 😉

1️⃣ Первая часть его восходит к основному "постулату" Netflix - концентрация таланта (работников меньше, но они наикрутейщие специалисты) -> Плати как рок-звездам\Плати рыночный максимум:

первоклассный разработчик приносит компании не в 10 раз больше прибыли, чем на него тратиться, а примерно раз в 100. ... Билл Гейтс в своих оценках идет еще дальше: программист высочайщей квалификации стоит в десять тысяч раз больше обычного программиста

Это правило широко распространено в индустрии информационных технологий, но Netflix решил рааспространить его дальше. После некоторых измышлений все должности были разделены на операционные и креативные.

На операционной должности (мойщик окон, водитель) лучший сотрудник стоит раза в 2 больше рядового. Мороженщик-виртуоз, пожалуй, вдвое быстрее наполняет стаканчик...На счету первоклассного водителя вполовину меньше аварий, чем у среднестатистического шофера. Однако прибавочная стоимость, которую может добавить один мороженщик или один водитель единице своей продукции, имеет предел. Так что сотрудникам на операционных должностях можно платить среднюю зарплату, и компания будет функционировать вполне успешно.
... в Netflix от большинсвта сотрудников требуются творческие, нестандартные решения. На любой креативной должности профессионал высочайщего класса ценится как минимум в десят раз выше рядового сотрудника...

Весьма полезными следствиями правила являются:
- минимизация штата
- управление таким штатом профессионалов становиться эффективнее


2️⃣ Премии мешают гибкости

долго старались сформулировать критерии успешной работы и увязать их со схемой выплат.

на собрании я поздравил Лесли с тысячами новых пользователей, ... и уже собирался объявить, что ей полагается премия, как она меня перебила:
- Да, Рид, это здорово. Моя команда отлично поработала. Но кол-во новых подписок - это уже не та величина, которую нужно замерять. Это для нас больше не актуально.

Из разговора с Лесли я уяснил: система поощрительных выплат основана на слепой вере в то, что мы способны предвидеть будущее и в любой момент готовы поставить задачу, которая надолго сохранит акутальность

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

Результаты получились удивительными:
- группа со средним значением справилась с задачами не хуже и не лучше тех у кого выплаты были небольшие
- но группа с высоким вознаграждением показала худшие результаты во всех категориях заданий

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

Отказ от поощрительных выплат позволяет поднять базовую зарплату и оставить в компании самых мотивированных сотрудников, что повышает концентрацию таланта. Однако ничто не увеличивает её эффективней, чем достойные зарплаты, которые со временем еще больше растут, оставаясь самыми привлекательными на рынке труда -> здесь замыкается кольцо Плати рыночный максимум

Ну что, идеи Netflix не кажутся вам уже безумными🙃

#netflix #norules

И снова деньги, теперь правило про оплату труда🔥

#netflix #norules

​​💰 Смета дорожных расходов
.
Мне понравились некоторые части правила, которые можно переложить в целом на работу и взаимодействие с коллективом:

1️⃣ Обоснование выбора

Прежде чем тратить деньги, представьте, что вас вызывают ... к непосредственному начальнику и просят объяснить, почему вы выбрали именно этот рейс, эту гостинницу, этот тарифный план. Если вы с легкостью можете сформулировать, чем ваш выбор полезен для компании, значит всё в порядке - оплачивайте покупку, не спрашивая официального дозволения. Но если возникают затруднения, обойдитесь без этой траты, спросите совета у руководителя или купите что-нибудь подешевле

2️⃣ Свобода, скорость, экономия

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

Исключая дорожные расходы можно сказать: сотрудник должен иметь возможность самостоятельно выбрать как ему решать задачу, но иметь возможность обосновать свой выбор. Жесткие правила игры убивают творческий полет мысли 🚀

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

#netflix #norules