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

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

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

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

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

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

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

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

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

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

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

#netflix #norules

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

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

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

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

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

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

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

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

#netflix #norules

​​🍉 Принес парочку интересных кейсов поведения оптимизатора 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

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

#ai

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

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

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

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

​​# 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

# 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

​​💡 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

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

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

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