Освежаем статистику.

Без статистики никуда. Даже продактов уже спрашивают на собесах, что такое p-value и как правильно интерпретировать результаты АВ-теста.

По крайней мере, я спрашиваю. 😄

В репосте обзор на книгу. И там же в канале более научпопная "Статистика и Котики".

Данные как "секретный соус" b2b сервиса

На днях смотрел интервью, которое заставило меня задуматься. Оно было не про данные, я бы более того сказал: основная тема диалога довольно далека от ИТ и всех этих наших дата-дривенов.

Разговор был про бизнес в области доставки еды. Кроме всех знакомых сервисов Яндекса и Сбербанка существует множество более мелких агрегаторов. Это и естественно: крупный поставщик работает с крупными сетями, мелкий и региональный - с местными более мелкими или нишевыми. На видео ребята из небольшого регионального агрегатора доставки Чиббис.

А заставило меня задуматься вот что. Вот у нас есть агрегатор доставки. Его основной клиент - ресторатор, это B2B-сервис в чистом виде. Как сделать клиенту агрегатора хорошо?

Ребята открыли то что они называют "Академией Чиббис". Дело в том, что средний ресторатор не слишком искушен в вопросах управления своим предприятием. Там очень много молодых и начинающих предпринимателей, для которых это первый бизнес в жизни. В то же время агрегатор кровно заинтересован в том, чтобы у них все получилось, и их клиент-ресторан не разорился в первый год.

Вот примеры инсайтов Академии, которыми поделились владельцы.

Ты закрываешься слишком рано. Пик заказов приходится на вечер, в 9 вечера заказы вполне себе еще идут. Закрывать кухню в 10-11 вечера, а не в 9 вполне экономически эффективно.

У тебя неправильные промо. Ты лучше вместо скидки в 500р рублями дай блюдо в подарок за 500р. Для клиента это по-прежнему подарок ценностью в 500р, но для ресторана это затраты в районе 150-200. Плюс согласно исследованиям ретеншена и вовлеченности, клиенты, привлеченные подарком, остаются дольше и приносят больший CLTV.

Я ловлю себя на мысли: это же по сути сервисный data-driven!

Сами герои это назвали их "секретным соусом". Ну знаете, когда все бургеры одинаковые, но один вот чем-то лучше. Вот так - ненавязчивая сервисная аналитика - серкетный соус b2b продукта.

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

В конце концов, поднимите опенсорсный BI (SuperSet, DataLenz) и берите деньги на отрисовку дашбордов в нем!

Интервью тут.

Преподносим аналитическую инициативу правильно

Все мы хотим получить проекты поинтереснее и посложнее! (Мы ведь все хотим?)

Как донести свою инициативу до потенциального ЛПР? Для этого тренируем упражнение "Разговор в лифте". У вас 1 минута: объясните высокому ЛПРу как ваша инициатива поможет ему решить его проблемы. Просто, да?

Неиссякаемая сложность простоты. Что нужно для успеха?
1. Понимать, о чем именно болит голова у этого конкретного Директора.
2. Иметь компетенции для решения задач.
3. Иметь репутацию человека, способного взять на себя решение задач такой сложности и довести ее до конца.
4. Уметь рассказать за 1 минуту и пользу, и общий ход решения, и нужные вам для этого ресурсы, развеять риски и типовые возражения.
5. Иметь под рукой более детальный план, чтобы отправить на стол Директору, пока история не остыла.

Берем и тренируем ваши рассказы на тему "У нас так плохо с продажами. Давай я сделаю комплексный дашборд по отработке лидов". "Я знаю, как по показателям спрогнозировать в середине квартала риски невыполнения плана". "Чат-бот на опенсорсной LLM-ке улучшит показатели саппорта, у меня как раз есть демо-стенд!"

Но будьте готовы что
1. Ваше предложение не сработает с первого раза. И через полгода вы скажете: а помните, я предлагал вот это и вот так. Предложение еще в силе.
2. Предлагаемое вами решение находится на чьей-то полянке, и со стороны владельца полянки можно встретить организованное сопротивление инициативе. Будьте готовы поделиться с другими достигнутыми успехами и даже полностью отдать их - все ради п.3 "Репутация".
3. Вы просто не угадали с потребностями и моментом.

Мы аналитики. Нередко ЛПР плохо понимают, что могут данные в части улучшения процессов. Инициативы в наших головах возникают часто, но мало кто умеет их правильно презентовать. Если научиться делать правильно, будет эффект "А что так можно было??" и вы будете ее (со-)автором.

Тренируйте (дома перед зеркалом) упражнение "Разговор в лифте". Имейте загашничек из хороших идей, актуальных для разных ЛПРов. Держите их при себе до подходящего момента.

Типы кокосовых менеджеров

Задача - сбить с пальмы кокос. Как решают задачу разные менеджеры.

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

Второй тип - кадровый
Подводит инженера к пальме. Тот трясет пальму - кокос не падает. Менеджер говорит: тряси сильнее. Исполнитель трясет сильнее - кокос не падает. Инженер увольняется за андерперформанс, в кадры заводят поиск на позицию Сениор Трасильщика Пальм с опытом работы с кокосами. Менеджер ходит по конференциям и жалуется на нехватку нужных специалистов на рынке труда.

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

Четвертый тип - исследователь
Уходит в исследование рынка кокосов и мирового опыта трясения кокосов. Приходит к выводу, что кокос сейчас незрелый, а когда созреет - упадет либо сам, либо от легкой тряски. Ставит в календарь встречу по добыче кокосов через месяц. Идет заниматься другими делами.

Пятый тип - технологичный
Уходит с командой инженеров в трехлетний НИОКР по конструированию пальмотрясительной машины. Машина позволит трясти до 10 000 пальм одновременно с возможностью гибкого масштабирования до 1 млн. Требует для работы компактный ядерный реактор на высокообогащенном уране. Полученный опыт (аналогов-нет) докладывается на конференциях.
(Дядя менеджера, по совместительству директор завода реакторов, дарит племяннику новую БМВ)

Какой ваш тип?

С какими типами вы сталкивались?

В четверг 27 марта буду выступать на Data+AI 2025.

Про лейкхаусы.

Мой доклад в 12:55

Lakehouse одним слайдом.

На самом деле, вся идея в том, что мы берем развитие технологий SWE и привносим их в мир данных.

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

Но сказать намного проще, чем сделать. Потребовало многих лет и нескольких технологичных новаций, чтобы история начала складываться в целостный подход.

И это тоже оказывается Лейкхаус. 😳

Интересный вопрос от подпичика.

Мое мнение - тип хранилища не так важен. Может быть и HDFS, может быть и корпоративная SAN блочка.

Важнее - возможность разделить и независимо управлять сторажем и компьютом.

Важнее - мультисервисный доступ к данным. N кластеров Trino/Hive и K кластеров Spark могут читать и писать в один датасет. Это "лейковость".

Важнее - (квази)транзакционность и ACID-ность записи. Это "варехаусность".

Тип контейнеризации (k8s, nomad, yarn), формат данных (iceberg, parquet), набор сервисов (Trino или Impala, Kafka или Flink), тип хранилища (блочка, объектное, hdfs) - более гибкие вопросы.

Есть более удобные и менее удобные сервисы. В будущем появятся новые (замена Spark на что-то более легковесное?).

Ответ на вопрос - если в хадуп добавить S3 протокол и даже Iceberg Catalog туда посадить - нет это не будет DLH. Все равно в этой парадигме нельзя(трудно) сделать N отдельных кластеров компьюта, K отдельных метасторов и гибко ими управлять.

Плейлист хороших видео про Лейкхаусы

1.
Вебинар - Поднимаем Lakehouse на основе Trino.

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

2.
Доклад от Димы Зуева на VK Data Meetup - Роль Trino в Т-Банке

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

3.
Владимир Озеров о том как на самом деле работает Iceberg Catalog

Просто о сложном. Как оно работает.

3 сценария развития дата офиса и зачем нам DLH в каждом из них.

Все хорошо, мы развиваемся

Главный вызов - рост челенжа. Это только кажется, что при росте объема данных с 20 до 100 ТБ мы прирастаем всего в 5 раз. На самом деле у нас больше аналитиков, а это больше потоков нагрузки. Новые аналитики привносят новые датасеты, которые надо джойнить со старыми и проверять на качество.
Бизнес собрал все низковисящие фрукты и стал задавать сложные вопросы, а это рост сложности и перекрученности среднего запроса. А еще обязательно попросят обновлять данные не 1 раз в день, а максимум через 5 минут с прода они были.

Надо ли говорить, что старая MPP система может не справиться, а заливать все бюджетами может не получиться. Нужно технологическое решение, чтобы эффективно и без огромных бюджетов "съедать" все возрастающие требования.


Все плохо, мы экономим

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


Все идет как идет

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

Спасибо всем, кто слушал онлайн и в зале.

Обсудим в комментах

Аптаймы

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

Интересно, есть ли ETL пайплайн, который работает ну хотя бы с 2015-го? 10 лет.

Рекорд, который я видел своими глазами, - 1100 успешных дневных запусков подряд. 3,5 года.

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

Хороший годный митап от коллег.

Всем привет! 24 апреля в Москве в офисе Лемана Тех пройдет очередной митап по технологиям Trino и Apache Iceberg! Также будет доступна онлайн-трансляция.

В программе:
- Доклад от Лемана Тех про миграцию на Trino
- Доклад от Азбуки Вкуса про использование каталога Nessie
- Круглый стол про проблемы внедрения lakehouse с инженерами T-Банк, S7 Airlines, Лемана Тех и Кверифай Лабс

Регистрация по ссылке: https://cedrusdata.timepad.ru/event/3299844/

Хозяйке на заметку

Отраслевые тесты для OLAP

Коллеги, поделитесь, какие вы используете тесты для изменения перформанса OLAP? Есть ли что-то кроме TPC-DS?

Есть у меня мой "авторский" на данных блокчейна Ethereum. Но к нему надо больше запросов написать как минимум и какой-то раннер прикрутить еще. Зато там данных много: Ehereum это около 6 ТБ данных транзакций, а Polygon 20 уже.

Подлинная революция

Пока мы тут про лейкхаусы, в российском ИТ случилась настоящая революция.

1С научился хранить файлы в S3.