Публикации на Google Research

Последние пару дней я активно готовился к своему докладу про RnD и изучал страничку research.google/pubs/, чтобы посмотреть какие white papers появлялись у Google и когда.
В итоге, я составил список ключевых документов с фокусом на сервисы и инфраструктур (исключая ML), которым решил поделиться

- 2003 год - The Google File System - про распределенную файловую систему от Google
- 2004 года - MapReduce: Simplified Data Processing on Large Clusters - про концепцию параллельной обработки в формате MapReduce (по мотивам появился Hadoop)
- 2006 год - Bigtable: A Distributed Storage System for Structured Data - про распределенную NoSQL базу (по мотивам BigTable и Amazon DynamoDB появилась Cassandra)
- 2006 - The Chubby lock service for loosely-coupled distributed systems - про сервис распределенных локов, которые можно использовать вместо встраивания консесуса в сами сервисы
- 2007 - Engineering Reliability into Web Sites: Google SRE - про роль SRE в обеспечении надежности
- 2010 - Dapper, a Large-Scale Distributed Systems Tracing Infrastructure - про трассировку в распределенных системах (open source последователи Zipkin, Jaeger, OpenTelemetry)
- 2012 - Spanner: Google's Globally-Distributed Database - про NewSQL базу данных с масштабированием как у NoSQL и ACID транзакциями, под капотом TrueTime для точного определения времени, что нужно для определения порядка транзакций (open source последователи Cockroach DB)
- 2013 - Omega: flexible, scalable schedulers for large compute clusters - про окрестратор рабочих нагрузок (наследник Borg, но менее удачный)
- 2015 - Large-scale cluster management at Google with Borg - про оркестратор рабочих нагрузок, что предшествовал Omega и в итоге оказался более удачным и пережил ее
- 2015 - TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems - про фреймворк для машинного обучения, который сразу был выпущен в open source
- 2016 - Borg, Omega, and Kubernetes - про сравнение двух внутренних и одного публичного (K8s) оркестратора нагрузок (Kubernetes изначально тоже сделал Google)
- 2016 - Ubiq: A Scalable and Fault-tolerant Log Processing Infrastructure - про обработку логов на масштабе
- 2017 - Spanner, TrueTime and the CAP Theorem - про CAP теорему и Spanner от создателя CAP-теоремы, Eric Brewer, что к этому моменту уже давно работал в Google
- 2018 - Advantages and disadvantages of a monolithic repository: a case study at google - про монорепозиторий Google и как он помогает им в разработке
- 2019 - Zanzibar: Google’s Consistent, Global Authorization System - про ReBAC систему авторизации, что завязана на отношения между сущностями (мы этот white paper как-то уже обсуждали в Code of Architecture)
- 2020 - Monarch: Google's Planet-Scale In-Memory Time Series Database - про time-series базу данных
- 2020 - Scaling PageRank to 100 Billion Pages - про масштабирование ключевого алгоритма на графах (Page Rank) на супер масштабы
- 2020 - Autopilot: Workload Autoscaling at Google Scale - про автомасштабирование рабочих нагрузок в облаках
- 2022 - Deployment Archetypes for Cloud Applications - интересное исследование про виды deployments
- 2023 - A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google - интересный документ про архитектурные процессы в Google на примере репроектирования системы Monarch, про которую был white paper от 2020 года

Если суммировать мои мысли про Google и создание ими статей, то видно, что они первыми писали про многие сложные штуки, но вот open source решений поначалу они не создавали, и у них появлялись open source аналоги. И эти аналоги были несовместимы с внутренними инструментами Google, что мешало получать помощь от коммьюнити. Значимыми исключениями с точки зрения открытости являются: Android, Chrome, Kubernetes, TensorFlow.

#RnD #WhitePaper #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #DistributedSystems #SystemDesign #SystemEngineering

Improving software flow

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

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

CAP Theorem

Знаменитой CAP теореме исполнилось 25 лет, поэтому хотелось что это такое, зачем она и как появилась. Про это есть отличная статья от Eric Brewer, автора теоремы, который написал ее больше 10 лет назад, которую хотелось вспомнить, так как она хороша:)
Начнем с самого утверждения теоремы (цитата из статьи выше)

The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:
- consistency (C) equivalent to having a single up-to-date copy of the data;
- high availability (A) of that data (for updates); and
- tolerance to network partitions (P).

Дальше надо вспомнить про ее появление
- 25 лет назад, осенью 1998 года была сформулирована CAP теорема
- в 1999 году она была опубликована в статье "Harvest, Yield, and Scalable Tolerant Systems" в ACM
- в 2000 представлена на Симпоузиуме "Symposium on Principles of Distributed Computing" (презентация здесь)
- в 2002 доказана формально (где консистентность из теоремы превратилась в линеаризуемость)
Потом теорема пошла в массы и превратилась в условные "выберите 2 свойства из трех: C, A, P", что является сильным упрощением по трем причинам, что указывает Эрик в уже упоминавшейся статье:
1. Из-за редкости partition нет смысла выбирать между C и A (про это подробнее в следующий раз при обсуждении PACELC Theorem)
2. Решение о C или A принимается не единоразово для всех компонентов и всех данных, а на другом уровне гранулярности и может зависеть от типа операции или данных
3. C, A, P - это не бинарные свойства, а скорее непрерывные - availability от 0 до 100%, уровни консистентности тоже бывают разные и даже partitions имеют нюансы:)

В итоге, Эрик говорит о том, что в отсутствии разделения системы мы можем выбирать A или C, а во время проблем у нас должен быть понятный алгоритм
- определения, что случился partition
- перехода в явный partition режим, в котором часть операций может быть лимитирована
- запуска процесса восстановления консистентности и компенсации ошибок, что возможно были в рамках partition

Потом Эрик рассказывает про связь акронимов ACID, BASE и CAP
- BASE расшифровывается как Basic Availability, Soft state и Eventually consistency. Первые два из свойств помогают достигать доступности при разделении системы на части
- ACID расшифровывается как Atomicity, Consistency, Isolation, Durability. Этот акроним знают многие, кто работал с реляционными базами данных, но как я писал выше Consistency из CAP и из ACID - это про разное и это добавляет сложности в понимании:)

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

Конечно можно попробовать повторно выполнить операцию (retries), но это просто откладывает принятие решение на некоторое время. Таким образом, с прагматической точки зрения разделение — это ограничение по времени (таймаут), который мы закладываем в свое общение. А из этого следует несколько последствий
1. Не существует глобального понятия partition, поскольку некоторые узлы могут обнаружить partition, а другие — нет.
2. Те узлы, что обнаружили partition входят в режим partition-mode, собственно ту часть, где нам надо выбирать между C и A
В итоге, проектировщики системы выставляют time bounds так, чтобы соответствовать целевым скоростям ответа системы на запросы, а чем жестче эти time bounds, тем выше вероятность попадания в partition mode, причем даже просто при медленной сети, но без реального ее разделения.

В приведенной выше статье есть еще много интересных мыслей про scope консистентности и как это соотносится с датацентрами, как явно управлять процессами перехода в partition mode и восстанавливаться после partition. Очень рекомендую ее к прочтению.

#Software #Architecture #DistributedSystems #SystemDesign

Как я получаю информацию, чтобы быть в теме IT и не только

Недавно ко мне прилетел примерно такой вопрос от моего коллеги, Вовы Коноплева, CTO нашего банка для юрлиц, который ведет свой канал @konoplevthoughts
Мне вопрос понравился и я решил ответ на него превратить в отдельный пост, где я расскажу про свои источники информации

1) Книги
Я отслеживаю важные книги по интересным мне темам. Для этого я ориентируюсь на новинки на платформе
- Сайт онлайн-платформы O’Reilly, где есть книги разных издательств, а также видео и курсы
- Сайт издательства Питер, где интересно отслеживать новинки, а потом читать их неисковерканные в английском варианте
- Сайт издательства ДМК Пресс, где интересно отслеживать новинки и их даже можно покупать и читать (например, тут я писал про последнюю купленную партию книг из ДМК насчет статистики)
- Сайт издательства МИФ, где я покупаю много книг, но редко какие из них посвящены IT, так как это не профильная тема для МИФ
Отдельно отмечу, что меня интересуют книги как по IT, так и по современной науке, но обычно в формате научно-попуплярной литературы. Это позволяет мне поддерживать знания в актуальном состоянии.

2) Whitepapers
Я люблю читать важные whitepapers на темы, что меня задевают: архитектура , менеджмент, распределенные системы. Для этого у меня есть тоже набор источников
- Сайт ACM (Association for Computing Machinery) - сайт ассоциация вычислительной техники, старейшей и наиболее крупной международной организации в компьютерной области. На этом сайте есть куча whitepapers. Отдельно отмечу, что вступление в ряды членов ACM позволяет здорово сэкономить на доступах: само членство стоит 99$, за 75$ можно получить доступ к уже упоминавшейся выше платформе O'Reilly, Skillsoft Percipio и Pluralsight, а еще за 99$ к ACM Digital Library. В итоге, 273$ в год дают бандл, что стоит дешевле в 2 раза, чем доступ к O'Reilly отдельно
- Сайт Google Research, где есть куча интересных whitepapers, например, я уже публиковал такую подборку
- Сайт Amazon Science, где тоже много отличных материалов, например, "Dynamo: Amazon’s highly available key-value store" 2007 года, "Amazon Redshift and the case for simpler data warehouses" 2015 года, "Amazon Aurora: Design considerations for high throughput cloud-native relational databases" 2017 года, "Amazon DynamoDB: A scalable, predictably performant, and fully managed NoSQL database service" 2022 года
- Сайт Meta Research (запрещенной в России Meta), где тоже куча интересного материала

3) Telegram каналы
Приведу тут не весь список каналов, а тот, из которого я частенько узнаю что-то новое
- Сиолошная (@seeallochnaya) - здесь я читаю понятные тексты про LLMs и все, что с ними связано. По этим текстам мне кажется, что я неплохо все понимаю
- gonzo-обзоры ML статей (@gonzo_ML) - здесь я узнаю про whitepapers и понимаю, что пока не слишком хорошо во всем этом разбираюсь:)
- Инжиниринг Данных (@rockyourdata) - здесь я узнаю про современный ландшафт технологий работы с данными, но с фокусом на западных SaaS решениях и примесью on-prem решений
- Архитектура ИТ-решений (@it_arch) - отсюда я узнаю про интересные статьи на тему архитектуры и проектирования
- DDDevotion (@dddevotion) - тут я черпаю новости относительно DDD и той же архитектуры и проектирования

4) Популярные ресурсы на тему IT
- Сайт консультантов Thought Works и конкретно их выпуски про техрадары
- Сайт InfoQ и их ежемесячные рассылки по архитектуре

5) Каналы в Youtube
- Канал конференции goto, где есть записи с конференций крутых спикеров, многие из которых являются популярными авторами
- Канал конференции NDC, где тоже есть крутые выступления

6) Обучающие платформы
- Leetcode, где можно практиковать написание кода
- Edx - ресурс с крутыми университетскими курсами (я его использовал активно раньше)
- Coursera - ресурс с крутыми университетскими курсами (я его использовал активно раньше)
- Stepik - российский ресурс с хорошими курсами

#SelfDevelopment #Education #Software #Architecture #Management #Leadership

dbt — ядро современной платформы данных - Евгений Ермаков - SmartData 2023 (Рубрика #Architecture)

Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает.

Основные моменты следующие:
- Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют
- Архитектура базируются на трех китах:
-- Data lakehouse
-- Процессы в соответствии с подходом data mesh
-- Современный технологический стек
- До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens
- После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow)
- Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT
- Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам
- Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source()
- Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental
- Настройки хранятся в dbt_project.yaml и profiles.yaml
- dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ...
- dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json
- Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу
- Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных
- Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями
- У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:)
- Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида:
-- Монолитный - один dbt проект на всю компанию
-- Микросервисный - отдельные dbt проекты на каждый домен
-- Layered - отдельные dbt проекты по уровням
-- Смешанный - анархия, где проекты создаются кто как хочет
Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям).
Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow.

В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно.

#Data #Datamesh #DWH #Processes #Management

What Goes Around Comes Around... And Around... Part I (Рубрика #Data)

Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.

Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.

С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных

Начнем с разбора существующих data models и query languages:

1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.

2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.

3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.

4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)

5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.

6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.

7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.

8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).

Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.

В продолжении поста будет про архитектуру баз данных.

#Data #Architecture #Software #DistributedSystems

Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms (Рубрика #Data)

И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm

За время подкаста мы обсудили темы
- Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой
- Как можно строить платформы данных (централизованно, гибридно и децентрализованно)
- Как выглядят принципы федерализации данных (аля data mesh) в теории
- Во что этот подход превращается на практике
- Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году
- Что не так с классическими базами данных (Postgres и иже с ним)
- Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...)
- Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике
- Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов
- Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute
- Что такое medalion architecture
- Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения

Дополнительные материалы
- Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы"
- Статья из периода работы в Manychat: 1 и 2
- Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov"
- Запись "DataVault / Anchor Modeling / Николай Голов"
- Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009
- Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019

#Data #Datamesh #Processes #Management #Architecture

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

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

#AI #Software #Engineering #Architecture #Agents

Краткий обзор платформы данных Т-Банка (Рубрика #Data)

Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны

1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным

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

#Data #Database #Architecture #Software #Engineering #PlatformEngineering