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

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

Как донести свою инициативу до потенциального ЛПР? Для этого тренируем упражнение "Разговор в лифте". У вас 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.

На день космонавтики

64 года назад мы достигли многого. Мы вывели человека за пределы его колыбели и нюхнули свободы взрослого мира.

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

Упражнение с глобусом

Если взять в руки школьный глобус с диаметром 30 см, на какой высоте летал Гагарин и какая высота орбиты МКС? 1 сантиметр. Это уже для нас Космос!

А Луна? Луна на расстоянии 9 метров. Это уже соседняя квартира.

А Марс? Порядка 5 километров! 3 автобусные остановки или час пешком.

Ближайшая потенциально обитаемая планета? Очень повезло, она в ближайшей же звездной системе - это Проксима Центавра B, на ней может быть жидкая вода. Расстояние? Да забудьте - там 900 тысяч километров!

Теперь представьте поход на 23 раза обогнуть экватор в то время, как мы нормально освоили только 1 сантиметр этого пространства! Эволюционно мы на уровне инфузорий, которые и путешествуют за свою жизнь на несколько сантиметров. Теперь Илон предлагает нам приложить титанические усилия для эволюции, ну, в простейшую гидру, которая может теоретически утопать на 5 км от места своего рождения и выжить. А до звезд все еще нужен разум и реактивный самолет.

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

Но. Давайте в этот день праздновать. У нас есть важное отличие от инфузорий, оно в том, что мы способны осмыслить внутри себя самый дальний поход. Мы способны измерить, оценить, подсчитать, составить план. Мы даже способны вообразить задачи на сотни поколений вперед, где давно уже не будет никаких нас.

Люди на каноэ

Когда-то на берегу Тихого океана люди спустили на воду каноэ из тростника и поплыли в неизвестность. Они не знали, сколько плыть, не знали, есть ли там вообще пригодная земля. Неизвестно, сколько их сгинуло. Но известно, что все, даже самые удаленные, острова в океане на пол-Глобуса оказались заселены.

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

Почему мы хотим покорить Космос? Да потому что он, Космос, есть!

Выступаю на Arenaday 2025

Ровно через неделю, 22 апреля состоится большая ежегодная конференция Аренадата - ArenaDay 2025.

Совместно с архитекторами Аренадаты мы подготовили доклад об эффективном обеспечении отказоустойчивости кластеров ArenaDB.

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

Какие темы раскроем
⁃ Как перестать бояться отказов и начать использовать данные в реальных бизнес-процессах. И причем тут резервная площадка.
⁃ Что может предложить облако для отказоустойчивости данных
⁃ Как организовать ADB DR без кратного роста расходов на инфраструктуру данных
⁃ Как автоматизировать переключение между площадками с помощью сервисов облака
⁃ Как составить детальный DR-план, организовать DR-учения и не бояться отказов
⁃ Как переиспользовать вторую площадку для других задач: Dev/Test окружений, песочниц для разработчиков, сервинга данных для ML и LLM.

No system is safe. Даже самые крутые ЦОДы от ведущих мировых и российских компаний иногда падают. Даже самые безопасные системы ловят вирусов-шифровальщиков.

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

22 апреля, вторник, Секция «Гибридное хранилище», 16:30