Code of Leadership #50 - Interview with Sergey Mikhalev about Odnloklassniki, VK, T-Bank and Data Platform (Рубрика #Data)

В очередном выпуске подкаста ко мне пришел интересный гость, Сергей Михалев, который работает техническим директором data platform в Т-Банке. До этого Сергей успел приложить руку к дата платформам Одноклассников и ВКонтакте. В этом видео мы успели с Сергеем обсудить его карьерный путь, который всю дорогу был связан с большими данными. Заодно мы обсудили как само это понятие менялось во времени и как выглядит state of the art сейчас, а также почему мы в Т-Банке переезжаем с Greenplum (mpp база данных) на более модный и молодежный подход с DLH (data lake house) и как имплементирует федеративный подход с data mesh, а также как поверх всего этого работает a/b платформа. А если быть точнее, то список тем, что мы успели обсудить за 2 часа приведен ниже

- Введение и знакомство с гостем
- Ранние годы, образование и профессиональный выбор
- Начало карьеры, оптимизация БД, миграции данных и рост до тимлида
- Рост компетенций
- Работа в «Одноклассниках» над дата инфраструктурой
- Инженерная и экспериментальная культура «Одноклассников»
- Важность данных и много a/b экспериментов как признак зрелого продукта
- Развитие дата-платформы в «Одноклассниках» и переход на позицию технического директора дата-платформы всего VK
- Переход в Т-банк и обсуждение культуры работы с данными, принятой в Т
- Уровень инженерной культуры, дежурства, обработка логов, AB-тесты, интерфейсы для экспериментов.
- Архитектура Greenplum, параллельность, ограничения, расширение кластеров
- Обеспечение надежности, риски при переключениях, резервная система. Ограничения Greenplum
- Новая архитектура дата-платформы с разделением compute и storage
- Новая парадигма работы с данными: внедрение дата контрактов
- Федерализация дата инженеров и передача ответственности в сами продуктовые команды
- Сервисы и дата-продукты, пайплайны, взаимодействие в экосистеме
- Форматы работы: офис против удалёнки
- Баланс работы и личной жизни
- Будущее IT и потенциал биомедицины
- Советы по саморазвитию и поддержанию мотивации
- Завершение и благодарности

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Databases #Architecture #Devops #Management #Career #Architecture #DistributedSystems #SystemDesign #Leadership

InBetween 2025 (Рубрика #Management)

Этой осенью пройдет первая менеджерская конференция InBetween от JUG.RU, которая ориентирована на middle менеджеров, застрявших между стратегией и тактикой. Для того, чтобы понять о чем она я позвал в свой подкаст "Code of Leadership" Лешу Федорова, со-основателя компании JUG.RU и идейного вдохновителя этой конференции. Сам выпуск будет чуть позже, а пока я поделюсь своим пониманием этой конференции, для чего я до общения с Лешей изучил все доклады, что будут на конференции. Если кратко, то это конференция не только и не столько для IT руководителей, а скорее для всех менеджеров, которые оказались между стратегическими целями топ-менеджмента и ежедневными задачами команд и которых интересуют темы вроде

- Как принимать ключевые решения, когда данных недостаточно?
- Где полагаться на цифры, а где - на интуицию?
- Как объяснить «прыжок веры» совету директоров?

- Как не развалить команду, меняя подход к проектам?
- Что делать, если никто не берет ответственность?
- Как координировать команды с разными целями?
- Как быстро адаптировать планы, если ситуация поменялась?
- Как каскадировать изменения на команду?

Организаторы так видят себе целевой портрет участника
- Менеджеры сложных проектов - те, кто отвечает за результат, но не контролирует все ресурсы
- Продуктовые менеджеры с несколькими командами - те, кто координируют разные направления с разными целями
- Руководители многофункциональных подразделений - те, кто управляют людьми из разных специализаций
- Генеральные и операционные директора - те, кто превращают стратегию в набор конкретных действий
- HR-директора, CPO и CMO - те, кто отвечают за результат своего направления

На конференции выступят управленцы из крупных российских компаний (преимущественно tech компаний, что объясняется нетворком организаторов)
- Юлия Зыкова (Циан) — как менять модель монетизации в условиях неопределенности
- Елизавета Колесникова (Яндекс) — расшифровка туманных пожеланий от руководства
- Андрей Зарубин (Райффайзен Банк) — перегруппировка команд на оперативном уровне
- Илья Балахнин (Paper Planes) — что делать, когда стратегические сессии не работают
- Алексей Кирпичников (Контур) — управление 80 продуктами без полномочий
- и другие

Онлайн часть конференции уже была и включала три доклада «Между стратегией и тактикой», «Как неправильная работа с KPI разрушает стратегию» и «Полезный проектный офис за 30 минут». А оффлайн часть мероприятия пройдет 8 сентбяря в Москве в пространстве "Весна", куда я тоже загляну по приглашению организаторов.

#Management #Leadership #Engineering #Processes #Project #ProductManagement #Metrics

Реорганизация Meta AI Labs: Структурный поворот к суперинтеллекту (Рубрика AI)

Недавно читал заметку Александра Ванга "Superintelligence is coming", из которой видно, что Meta (запрещенная в России организация) провела крупнейшую реорганизацию своих подразделений искусственного интеллекта в истории компании, объединив все AI-команды под новой структурой Meta Superintelligence Labs (MSL). Эта четвертая реорганизация за последние шесть месяцев направлена на ускорение достижения "суперинтеллекта". Новая схема становится централизованной, где прямое управление сосредоточено у 28-летнего Александра Ванга, который ранее был CEO Scale AI. Он был привлечен Meta в рамках сделки стоимостью $14,3 млрд и теперь он возглавил MSL в качестве Chief AI Officer (а помните я шутил раньше про роль CAIO). Если говорить про ключевые направления, то их четыре и вот они

1) TBD Lab, которым руководит непосредственно Ванг и которое сфокусировано на обучении и масштабировании больших моделей и разработки "omni" модели, чтобы это не значило. По-факту, от этой лабы мы ждем новых LLama моделей, которые будут получше, чем провальная четверка
2) FAIR, которым руководят Роб Фергус + Янн ЛеКун (Chief Scientist), которые теперь отчитываются Вангу. Эта лаба занимается фундаментальными исследованиями и будет инновационным движком MSL. Если ранее между FAIR и генеративным AI-подразделением Meta было относительно мало взаимодействия, то теперь исследования FAIR будут напрямую интегрироваться в масштабные запуски моделей, проводимые TBD Lab.
3) Products & Applied Research, которой руководит Нат Фридман в прошлом из GitHub, который тоже отчитывается Вангу. Тут цель проста - интегрировать AI в продукты Meta, а также вести прикладные исследования. Команда объединяет ранее разрозненные группы, работавшие над Assistant, Voice, Media, Trust, Embodiment и Developer pillars. Это обеспечивает более тесную связь между продуктовыми исследованиями и разработкой продуктов.
4) MSL Infra, которой руководит Апарна Рамани, который тоже отчитывается Вангу, а также развивает инфру под AI проекты

Интересно, что
- Теперь в этой структуре два главных ученых (chief scientists): Янн ЛеКун (FAIR) и Шенцзя Чжао (общий для MSL). ЛеКун сохраняет фокус на долгосрочных исследованиях и "построении следующих AI-парадигм", в то время как Чжао, соавтор ChatGPT, устанавливает исследовательскую повестку для всей лаборатории.
- В рамках реорганизации Meta ликвидировала команду AGI Foundations, созданную всего в мае 2025 года. Это уже вторая крупная AI-команда, расформированная компанией в этом году - ранее была ликвидирована GenAI division после прохладного приема Llama 4. Сотрудники AGI Foundations распределены между продуктовыми, инфраструктурными командами и FAIR, но не в TBD Lab.

Если говорить шире, то эта реорганизация является ответом на отставание Meta в конкурентной гонке. Постоянные реорганизации контрастируют со стабильностью конкурентов, которые сталкиваются с меньшими организационными потрясениями Для усиления компания активно переманивала таланты, предлагая пакеты компенсации до $100 млн, а в одном случае - до $1,5 млрд. Компания привлекла более 50 исследователей и инженеров от конкурентов, однако эта кампания завершилась заморозкой найма в AI-подразделении в августе 2025 года, что сигнализирует о необходимости консолидации после периода интенсивного расширения.

Подход Meta строится на том, чтобы предлагая высококачественные модели бесплатно, стремится коммодитизировать уровень foundational моделей и подорвать бизнес-модели конкурентов, которые монетизируют доступ к своим моделям через API. Ведь основная монетизация самой Meta происходит через увеличенное вовлечение пользователей и данные, генерируемые на ее платформах. Интересно будет посмотреть насколько сработает их стратегия и что родит MSL, ведь прошлых заход с 4 ламой был слабее, чем все ожидали от таких вложений.

#AI #ML #Software #Economics #Engineering #Management #Leadership #Future

Apache Iceberg: What It Is and Why Everyone's Talking About It (Рубрика #Data)

Отличное короткое выступление Тима Берглунда VP Developer Relations в Confluent про Apache Iceberg и почему про него так много говорят. Если упрощать, то Apache Iceberg - это открытый формат аналитических таблиц, принесший ACID-ранзакции и эволюцию схемы в мир «сырого» дата-лейка. В этом видео Тим помимо Iceberg еще рассказывает про TableFlow от Confluent, что является автоматической материализацией Kafka-топиков в Iceberg-таблицы. Вот основные тезисы Тима

1. Он начинает с рассказа про эволюцию подходов по работе с данными
- Data warehouse (DWH) : с 1990-х, ночной ETL, строгая схема, отчёты на следующий день
- Data lake: с 2010-х, сначала Hadoop, затем S3/Blob; схема on read, ELT-паттерн, масштаб до петабайт
- При переходе к data lakes потерялось: строгая схема, транзакционность и согласованность при параллельных записях
2. Проблемки в data lakes были примерно такие
- Отсутствие метаданных на уровне файлов - это приводило к долгим directory-list операциям в S3; непредсказуемым SQL-запросам
- Нет ACID-транзакций - это приводило к «грязным» данным при частичных перезаписях, race conditions
- Сложная эволюция схемы - получались «zombie»-колонки, а также сложные перекатка партиций вручную
3. Но тут на помощь пришел подход с Apache Iceberg, который принес слои, что решили предыдущие проблемы. Эти слои выглядят так по мере увеличения уровня абстракции
- Data Files (Parquet/Avro/ORC) - неизменяемые фрагменты данных.
- Manifest Files - JSON-файлы, перечисляющие конкретные Data Files плюс статистику колонок (min/max, null-count).
- Manifest List - набор manifest-ов для одной операции добавления/удаления файлов
- Snapshots - атомарные состояния таблицы; каждый snapshot указывает на конкретный Manifest List, тем самым формируя точку во времени
- Metadata File (metadata.json) - хранит список всех snapshot-ов, схему, сорт-ордера.
- Catalog - внешний сервис (Hive Metastore, JDBC-DB, REST-каталог) сопоставляет имя таблицы с текущим Metadata File
4. Такая схема обеспечивает следующие свойства и механизмы, что решают указанные выше проблемы
- ACID-транзакции - обеспечивается посредством copy-on-write + optimistic concurrency, а дает это безопасные параллельные INSERT/DELETE
- Time Travel - обеспечивается посредством чтения по snapshot-ID или timestamp, а дает аудит и reproducible query
- Schema evolution - обеспечивается посредством полнотекстовыъ JSON-метадатанных; идентификаторов колонок, а не их порядка, а дает это возможность добавление/переименование колонок без перезаписи
- Hidden Partitioning - обеспечивается это посредством вычислимых трансформ (bucket, truncate, day), что спрятаны от пользователей, а дает fast scans без manual-фильтров
- Row-level Deletes - обеспечивает посрдеством V2 spec: delete deltas с позиционными ссылками, а дает GDPR-delete и upsert-паттерны
5. Если говорить про физическую реализацию, то
- Iceberg сам по себе - НЕ сервер. Это спецификация + библиотеки (Java, Python, Spark, Flink, Trino, Hive)
- Метаданные и данные - обычные файлы в объект-сторидже; каталог - «плагин» (Hive Metastore, AWS Glue, REST).
- Отказоустойчивая схема без rename/list операций - важно для S3, GCS.

Часть про TableFlow от Тима я рассказывать не буду, так как мне самым важным было рассказать про часть про Apache Iceberg.
Если подводить итоги, то
- Iceberg решает три исторические боли data lakes - ACID-транзакции, управляемая эволюция схемы, консистентные snapshot-ы.
- Архитектура основана на простых JSON/Parquet-файлах и внешнем каталоге; никакого «Iceberg-сервера» не требуется.
- Экосистема растёт: Netflix перешёл на «Iceberg-only» lake (≈1 EB); Databricks покупает Tabular, чтобы конвергировать Delta↔️Iceberg.
- Iceberg становится де-факто стандартом открытых табличных форматов, а в ближайшие годы data-платформы будут сходиться к унифицированному lakehouse-стеку, где Iceberg играет роль «общего языка» между потоковыми системами и батч-аналитикой

#Data #Dateabases #PlatformEngineering #Software #Architecture #Engineering #DistributedSystems