Откуда я беру интересные whitepapers (Рубрика #RnD)

Я люблю изучать научные статьи и уделяю этому много времени. Меня часто спрашивают где я их нахожу и я постоянно отвечают, что самые интересные статьи есть на сайтах bigtech компаний
1) Google Research. Основные области исследований Google включают машинное обучение, алгоритмы, квантовые вычисления, вычислительные системы, а также исследования в области науки, общества и ответственных технологий.
2) Amazon Science. В Amazon фокусируются на машинном обучении, компьютерном зрении, обработке естественного языка, квантовых вычислениях, автоматизации логистики и устойчивом развитии.
3) Meta Research*. Исследования охватывают искусственный интеллект, дополненную и виртуальную реальность, обработку естественного языка и социальные взаимодействия.
4) Mircosoft Research. Microsoft фокусируется на следующих областях: искусственный интеллект, машинное обучение, квантовые вычисления, компьютерное зрение, безопасность, взаимодействие человека и компьютера и технологии для социальных благ.
5) Netflix Research. Основные направления у Netflix сфокусированы на нужных для них темах: персонализация контента, оптимизация потоковой передачи, анализ данных и улучшение качества контента с использованием NLP и компьютерного зрения

Также есть общие библиотеки крупных ассоциаций
1) ACM Digital Library (ACM - Association for Computing Machinery)
2) IEEE Publications (IEEE - Institute of Electrical and Electronics Engineers)

P.S.
Я уже как-то рассказывал про свое увлечение whitepapers
1) Мое выступление на Techlead Conf "Как RnD появляется в крупных IТ-компаниях"
2) Новогодный выпуск "Code of Architecture" по white paper «Google's Hybrid Approach to Research»
3) Перечень изученных и разобранных за 1+ год whitepapers
4) Мой подкаст "Research Insights Made Simple" с разбором whitepapers (пока 5 эпизодов, что доступны на Youtube, Yandex Music)

P.P.S.
Meta - это запрещенная в России организация.

#Whitepaper #Architecture #Management #Science

Code of Leadership #25 - Interview with Anastasia Kabishcheva about group dynamics and BART Model (Рубрика #Management)

В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта. Настя работала в разных ИТ-компаниях в качестве менеджера проектов и портфельного менеджера проектов, пересобирала команды для проектов заказной разработки, а сейчас заканчивает магистратуру по психоанализу в Вышке и пишет диссертацию на тему профессиональной идентичности продакт менеджеров. Кстати, эпизод доступен и в Ya Music.

За время выпуска мы успели обсудить следующие темы

- Что такое групповая динамика и чем ее знание может быть полезно
- Что такое идентичность человека / компании и как это связано с корпоративной культурой
- Как работают культурные принципы и причем здесь антропология
- Что такое модель BART и как она может помочь руководителю
- Что такое модель Такмана и как она связана с BART
- Как связано лидерство и алгоритм консенсуса Raft
- Как думать о политике внутри компании в парадигме теории игр, шахмат, го, ...
- Как изучить групповую динамику на практике

Дополнительные материалы

0. Сайт Анастасии "Soulcoaching"
1. Конференция про психоаналитические техники работы с бизнесом (10 декабря 2024) - Промокод для подписчиков канала - ENERGY50 (скидка на билет 50%)
2. Конференция GRC онлайн
3. Книга «Бессознательное в организации» (Гирнальзик, Катуржевский, Ломер)
4. Книга "Личность и групповая динамика" (Стейпли)
5. Вопросы для каждого блока модели BART
6. Канал про офлайн конференции GRC
7. Фреймворк SPACE на тему developer productivity
8. Книга "The corporate tribe"
9. Эпизод "Code of Leadership" с разбором книги "5 пороков команды"
10. Интервью "How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024"

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking

100 мерный арбуз или пару слов про определение успеха (Рубрика #Management)

Чуть раньше я уже рассказывал про научную статью "Assessing IT Project Success: Perception vs. Reality", что была посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope в виде всех заранее определенных фичей.

The project is completed on time and on budget, with all features and functions as initially specified.

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

1) Представим, что у нас одномерный арбуз, а это просто отрезок на линии и его центр точка слева. Причем давайте договоримся, что крайние крайние десять процентов отрезка справа - это корочка. Тогда мякотью будет 90% нашего арбуза
2) Теперь перейдем в двухмерное пространство и здесь арбузом будет круг с радиусом R, причем дальние от центра 10% этого радиуса занимает корочка. Количество арбуза (в двухмерном пространстве это площадь) теперь квадратично зависит от радиуса и получается, что мякоти всего 0.9*0.9 = 81%
3) В привычном трехмерном пространстве арбуз - это шар, количество арбуза (здесь это объем) кубически зависит от радиуса и получается, что мякоти 0.9*0.9*0.9 = 0.729 ~ 73%
4) Продолжая эти размышления мы доходим до 100 мерного арбуза, где мякоти будет уже в гомеопатических количествах, а точнее 0.9^100 = 0.000027 ~ 0.0027%
5) Если же расслабить требования к каждому из критериев в этом стомерном пространстве и сделать так, чтобы мы считали любое отклонение меньше 1% по любому из критериев нормальным, то мы получим мякоти гораздо больше, а точнее 0.99^100 ~ 36,6% (то есть успех будет в 36.6% случаев)

По итогам этих размышлений об арбузах видно, что изначальное определение успеха проекта от Standish Group

The project is completed on time and on budget, with all features and functions as initially specified.

Имело мало смысла и способствовало только нагнетанию страха о том, как плохо управляются IT проекты.
В новом исследовании "Assessing IT Project Success: Perception vs. Reality" с этой точки зрения все сделано гораздо лучше - авторы отделяют оценку успеха по 7 критериям, использую шкалу Лайкерта, а также отдельно спрашивают про глобальный успех проекта. Это позволяет им отслеживать отдельные корреляции между глобальным успехом и остальными критериями.

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

#Management #Math #Leadership #SystemDesign #CriticalThinking

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

Сто лет недосказанности: Квантовая механика для всех в 25 эссе (Рубрика #PopularScience)

На прошлой недели я решил почитать что-то легкое и ненапряжное ... и снял с полки эту свежую книгу Алексея Семихатова, лекции которого я с большим удовольствием смотрел на ПостНауке. С тех пор Алексей успел написать две научно-популярные книги "Все, что движется" в 2023 и "Сто лет недосказанности" в 2024 году. Начал я с конца, а точнее со второй книги, в которой автор на пальцах изложил ключевые принципы квантовой механики и ее разнообразные интерпретации. В книге 25 отдельных эссе, которые связаны одной нитью, которая ведет нас как нить Ариадны от вопроса "из чего сделаны вещи" к стандартной модели элементарных частиц, проходя через все основные промежуточные станции, навроде молекул и атомов, электронов и фотонов, уравнений Шредингера и Дирака, горячих дискуссий Бора и Эйнштейна относительно верности копенгагенской интерпретации и так далее. Если говорить про основные моменты, которые осветил автор, то это

1) Принципы квантового мира: автор обсуждает особенности квантовой реальности, которая плохо дружит с человеческой интуицией. Он объясняет, как квантовые законы формируют мир вокруг нас, включая существование атомов, взаимодействие света и вещества, а также процессы, лежащие в основе работы Солнца
2) Эволюция квантовых систем: автор рассматривает правила, по которым развиваются квантовые системы во времени (тут появляется уравнение Шредингера и его кошка), а также роль вероятностей в этих процессах (тут отрабатывает правило Борна). Интересно рассматривается коллапс волновой функции при наблюдении
3) Интерпретации квантовой механики: Семихатов исследует различные подходы к пониманию квантовой реальности — от гипотезы параллельных вселенных до вопросов о разрывах в восприятии. Эти интерпретации очень интересны с точки зрения философии (мне особенно понравился кьюбизм, который напомнил мне солипсизм по своему подходу)
4) Переход к макромиру: В книге объясняется, как привычная нам реальность возникает из чуждого ей квантового мира. Семихатов показывает, что классические законы физики не могут объяснить многие явления без учёта их квантовой природы
5) Спин и его значение: спин электрона проходит через всю книгу, автор описывает его как квантовую меру вращения, и при помощи этого свойства проще всего демонстрируется фундаментальная квантовая природа нашего мира. Для измерения направления спина используется прибор Штерна — Герлаха, который появившись в одной из первых глав дальше упоминается постоянно:)

Итого, книга мне очень понравилась - я прочитал ее буквально на одном дыхании за пяток вечеров. Думаю, что она мне бы пригодилась для наглядной визуализации концепций, изложенных Ландау и Лифшицев в их знаменитой серии, которые я читал лет 20 назад, когда изучал теорфиз на Физтехе:) Особенно, это верно, если учесть, что в книге Алексея Семихатова нет ни одной формулы:)

#PopularScience #Physics #History

Манюня (Рубрика #Kids)

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

А вообще книга наполнена теплым юмором и, читая ее детишкам, я сам часто улыбаюсь:)

#ForKids #ForParents #Humor

Архитектурная ката от клуба { между скобок } (Рубрика #Architecture)

Несколько недель назад Гриша Скобелев, основавтель клуба { между скобок } (@backend_megdu_skobkah) собрал людей для участия в архитектурной кате. А в группу экспертов он позвал несколько человек, включая меня. Задача была в проектировании масштабируемой и отказоустойчивой системы поддержки клиентов, работающей через чат. Фокус был в том, чтобы разобраться а как обеспечить связь клиента и оператора поддержки в режиме реального времени с минимальными задержками. Сейчас стала доступна запись этой каты

Полезные ссылки:
- ArchDays - конференция по архитектуре, где я в программном комитете
- Объединение ИТ-Архитекторов
- Канал Игоря Антонова про разработку
- Хорошее видео про event storming
- Про микросервисы от Сергея Баранова

#Architecture #DistributedSystems #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part I (Рубрика #Architecutre)

В 2020 году Adam Gluck написал интересный пост про редизайн микросервисной архитектуры Uber и переход на DOMA. А потом Адам уволился и пошел пилить свой стартап, но к делу это не относится:) Если вернуться к статье, то Адам описал стадии эволюции архитектуры

1) Монолитная архитектура (примерно 2012-2013), где было 2 больших сервиса и набор проблем: риски доступности, опасные деплои, poor separation of concerns, плохой execution изменений в бизнес-логике. Эти проблемы возникли при росте от десятков инженеров к сотням
2) При решении этих проблем ребята пошли в микросервисную архитектуру ради: общесистемной надежности, separation of concerns, ясной ответственности и владения (ownership), скорости разработки (developer velocity). Ребята на начальных этапах получили все запланированное, но при росте команды до тысяч инженеров возник распределенный монолит
3) С 2018 года шла работа над новой концепцией под названием DOMA (Domain-oriented microservice architecture), в которой ребята решили, что микросервисы - это просто i/o-bound библиотеки, а микросервисная архитектура - это большое распределенное приложение, то для его архитектуры можно использовать стандартные подходы
- Domain-driven design - про эту концепцию интереснее всего читать у Влада Хононова в книге "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
- Clean architecture - лучше всего изучить книгу Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь
- Service-oriented architecture - это предтеча микросервисной архитектуры:)
И на выходе получаться принципы для дизайна крупных распределенных систем в больших организациях.

Основные принципы DOMA такие

1) Вместо ориентации на отдельные микросервисы надо ориентироваться на их коллекции, что организованы вокруг доменов
2) На самом деле домены тоже объединяются в коллекции, которые называются уровнями. Уровни определяют то, какие зависимости могут быть у микросервисов внутри домена. Базовое правило - это то, что микросервисы из верхних уровней могут зависеть только от микросервисы с нижних уровней. Авторы называют это слоенным дизайном. Для меня он напоминает семиуровневую модель OSI (технологии часто развиваются по кругу)
3) Домены предоставляют чистые интерфейсы (clean interfaces), которые являются единой входной точкой в коллекцию. Такие входные точки называются gateways
4) Зависимостями между доменами быть не может - ни по коду, ни по моделям данных. Для того, чтобы сделать доступным включение логики из одного домена в другой (например, для кастомной валидации или мета контекста) авторы предоставляют точки расширения внутри доменов

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

1) Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2) Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3) Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4) Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5) Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

Окончание обзора в следующем посте.

#DistributedSystems #Architecture #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part II (Рубрика #Architecutre)

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

Третьим архитектурным принципом является gateway. Он достаточно стандартен с точки зрения технической реализации, но на уровне домена он позволяет обеспечить за счет четкого котракта уменьшение сложности для взаимодействующих с доменом, а также более простые миграции внутри самого домена. Четвертый элемент - это точки расширения предлагают две возможности: расширение логики и расширение модели данных. Логические расширения реализованы через возможность подключения плагинов с интерфейсами определяемыми для каждого сервиса самостоятельно (приводится пример с кейсом, когда водитель выходит на линию и дополнительными проверками, что ему можно это делать). А данные можно расширять через добавление к core-модели данных произвольных опций. Также команды внутри доментов могут придумывать и другие точки расширения.

На выходе авторы получили
1) Снижение сложности: благодаря объединению 2200 микросервисов в 70 доменов DOMA упрощает управление зависимостями и обслуживание системы (за счет доменов и слоев)
2) Улучшенная масштабируемость и гибкость: архитектура позволяет осуществлять независимую разработку и развертывание доменов, сохраняя гибкость для будущих миграций (за счет gateways)
3) Улучшенный опыт разработчиков: структурированный подход снижает когнитивную нагрузку на разработчиков, позволяя быстрее разрабатывать функции и упрощать устранение неполадок (за счет понятных API и точек расширения)
4) DOMA доказала свою эффективность в управлении крупномасштабными operations в Uber

Напоследок автор рекомендует использовать стартапам монолиты, средним по размеру организациям микросервисы, а большим идти в сторону дома (DOMA)

Итого, это интересная статья от ребят из Uber из 2020 года. Если сейчас поискать дополнительную информацию, то кажется, что этот подход до сих пор используется Uber. Ради интереса я поискал whitepapers от Uber на тему DOMA и не нашел ни одной - Uber не Google, чтобы писать научные статьи:)

#DistributedSystems #Architecture #SystemDesign #Engineering #Software

ЦЕХ 4 - Урок #24 "Продающие тексты. Эксперт — Алена Лепилина" (Рубрика #Writing)

В очередном уроке разбирался пример создания продающих текстов:) Я сразу вспомнил книгу "Пиши, сокращай", о которой я рассказывал раньше. Экспертом урока была Алёна, что работает с текстами более 16 лет, руководит командой контента и редактирует курсы. Алёна рассказывает о важности текстов и их влиянии на аудиторию. Основные тезисы урока
1) Пирамида аудитории - про это рассказывали подробно во втором уроке
2) Для написания своей книги:
- Выделите свои смыслы и идеи, которые лежат на поверхности.
- Работайте над книгой, пока не найдете новые идеи.
- Продвигайте книгу, показывая её любой аудитории.
3) Для книги стоит составить контент план и дальше использовать разные площадки, правильно подбирая tone of voice в зависимости от площадки
4) В продающих текстах важно выстроить отношения с читателем, а не просто втюхать книгу. Для этого лучше не обещать больше того, что есть в книге:)
5) Можно писать про книги посты, подборки или гайды. Также можно писать трейлеры к книгам (внезапно по аналогии с трейлерами к фильмам)
6) Важно, чтобы текст к книге выщывал эмоции у читаталей, но не надо ими манипулировать и учитывать жанровую специфику
- Нон-фикшн: упор на пользу и практичность.
- Художественная литература: создание атмосферы и избегание спойлеров.
- Детская литература: учет формата и возраста читателя.
7) При написании текстов важен ритм и ясность. Длину предложений стоит чередовать, а также не надо перегружать читателя деталями, надо быть кратким и понятным
😍 Истории лучше сопровождать иллюстрациями
9) Тексты должны быть уникальными и интересными.Важно удивлять аудиторию и вдохновлять её. Важно писать нестандартно и оригинально.
10) Можно проявлять креативность в текстах, но не надо забывать проверять факты (делать фактчекинг)
11) Редактировать тексты стоит безжалостно - надо дорабатывать текст до момента, пока он не станет интересным и полезным. Можно привлекать внешнего редактора (так каксамому часто сложно резать написанный текст)
12) Чтобы писать хорошие тексты, надо много читать других авторов и профессионально развиваться в этой области
13) Полезно иметь сильный личный бренд - это помогает продвигать книгу
14) Стоит использовать аналитику для оценки эффективности текстов

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ
23. Продвижение автора. Личный кейс

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Коллеги из AI Центра продолжают радовать большими языковыми моделями на русском языке - теперь вышла T-Pro, которая по бенчмаркам хороша. Отдельно стоит отметить, что новая модель T-Pro выложена в opensource как и T-Lite и обе можно скачать с Hugging Face.

Запустили open-source модели на 7 и 32 миллиарда параметров

Сегодня мы выложили в открытый доступ две большие языковые модели на русском языке: T-Pro на 32 млрд параметров и обновленную T-Lite на 7 млрд параметров. Они построены на базе моделей Qwen 2.5 и дообучены на русский язык.

T-Pro заняла второе место по бенчмарку MERA среди всех моделей, включая проприетарные, и первое место среди открытых. А T-Lite стала лучшей русскоязычной open-source моделью в классе «до 10 миллиардов параметров» по ряду индустриальных бенчмарков.

🎄Скачать модели можно с huggingface.

Больше подробностей — совсем скоро ;)

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

Big Data is Dead (Рубрика #Data)

Этот пост Jordan Tigani вышел почти два года назад в блоге компании MotherDuck, которая является материнской для DuckDB. Сам Jordan был одним из инженеров, что стояли у основ Google BigQuery, а потом он отвечал за ее продуктовое развитие, а значит знает о чем говорит. Ну а компания MotherDuck пытается сделать облачную версию DuckDB, интересную аналитическую in-process базу данных, про которую рассказывали в докладе "DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 ", который я уже разбирал. Но если возвращаться к самой статье, то основной посыл Джордана в том, что эпоха «больших данных» как доминирующей концепции завершилась. Суть в том, что большинство организаций на самом деле не работают с огромными объемами данных, и акцент должен сместиться с размера данных на получение практических инсайтов. Ключевыми идеями статьи являются

1) Рассмотрение хайпа больших данных через призму реальности: нарратив о том, что компании перегружены огромными объемами данных, не оправдался для большинства организаций. Хотя объемы данных растут, развитие аппаратного обеспечения и технологий баз данных опережает эти темпы, делая традиционные системы достаточными для многих задач.
2) У большинства компаний умеренный объем данных: анализ клиентских данных Google BigQuery показывает, что большинство организаций управляют относительно небольшими наборами данных, часто менее 1 терабайта. Даже крупные предприятия редко генерируют или обрабатывают действительно огромные массивы данных, а типичные рабочие нагрузки затрагивают лишь небольшую часть хранимой информации.
3) Разделение compute и storage: современные облачные архитектуры разделяют хранение и вычислительные ресурсы, позволяя масштабировать их независимо. Это привело к росту объема хранилищ при тех же вычислительных потребностях, так как аналитика чаще сосредоточена на актуальных или агрегированных данных, а не на исторических архивах.
4) Экономические и практические ограничения: обработка больших объемов данных дорогостоящая и зачастую избыточная. Такие технологии, как колоночное хранилище, отсечение разделов и сжатие данных, сокращают объем обрабатываемой информации, что соответствует экономическим стимулам минимизировать затраты.
5) Данные как источник риска: хранение большого количества неиспользуемых данных может создавать риски, включая проблемы с соблюдением нормативных требований (например, GDPR), юридическую ответственность и операционные сложности из-за «старения» старых наборов данных.
6) Спад популярности систем для больших данных: традиционные монолитные базы данных (например, MySQL и Postgres) демонстрируют рост популярности, тогда как масштабируемые системы вроде NoSQL стагнируют. Количество рабочих нагрузок, требующих распределенных систем, сократилось благодаря значительному увеличению возможностей одиночных машин.

Напоследок Джордан предлагает компаниям оценивать свои реальные потребности в работе с данными вместо того, чтобы следовать маркетинговым нарративам о «больших данных». Большинство организаций могут извлечь выгоду из инструментов для управления данными меньшего масштаба вместо инвестиций в системы для гипотетически огромных массивов информации. Кстати, одним из таких инструментов может быть и DuckDB (это читается между строк).

P.S.
В продолжении темы можно изучить
1) Статью "What Goes Around Comes Around... And Around..." Майкла Стоунбрейкера, создателя Postgres, и Эндрю Павло, исследователя баз данных, про развитие СУБД за последние 20 лет. У меня есть краткий обзор в трех частях: 1, 2 и 3
2) Выступление от создателя DuckDB "A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024" и мое краткое саммари
2) Подкаст "Research Insights #6 с Колей Головым про дата платформы"
3) Подкаст "Code of leadership #22 с Димой Аношиным про data engineering"

#Database #Architecure #Software #Data #SystemDesign #Engineering

Quantum Computing Inches Closer to Reality After Another Google Breakthrough (Рубрика #Physics)

Интересная статья вышла на этой неделе в New York Times, в которой рассказывается про последние достижения Google в области квантовых вычислений. Суть в том, что Google заявляет о достижении "квантового превосходства", так как их квантовый компьютер на чипах Willow решил синтетическую задачу за минуты, а классическим суперкомпьютерам на архитектуре фон Неймана потребовались бы септиллион лет (10^24 лет). Звучит конечно круто, но так как задача синтетическая, то пользы от нее можно не ждать, но при этом достижении ребята из Google смогли преодолеть проблему коррекции ошибок. Суть в том, что квантовые компьютеры состоят из квантовых битов или кубитов, которые изолированы от окружающей среды и заморожены до сверхнизких температур. Вычисление представляет собой последовательное измерение функции Шредингера для системы из всех кубитов, чтобы в конце прийти к состоянию, где наиболее вероятным состоянием при измерении будет то, что дает правильный ответ. Вся эта машинерия может очень интересно сбоить, поэтому в процесс надо встраивать коррекцию ошибок, которая в этом компьютере ребят преодолела некоторый порог, который приближает всю эту конструкцию к практическому применению. В общем, по всем характеристикам это крутое событие, что усилит конкуренцию между технологическими гигантами, каждый из которых делает свои квантовые компьютеры. В интересное время мы живем.

P.S.
Рекомендую почитать книгу Алексея Семихатова "Сто лет недосказанности: Квантовая механика для всех в 25 эссе", про которую я рассказывал недавно.

#PopularScience #Physics #Software #Architecture #Engineering

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Enabling efficient analysis of biobank-scale data with genotype representation graphs (Рубрика #Data)

Наткнулся тут в рассылке от ACM (Association of Computing Machinery) на новость, что отлично демонстрирует то, что большие данные уже не такие большие:) Собственно, в генетике данных было всегда много после того, как ученые научились расшифровывать геном. Но эти данные надо было уметь где-то хранить и быстро лопатить для того, чтобы извлекать инсайты. И теперь ученые-исследователи из Корнелла разработали новый метод сжатия данных, который позволяет хранить большие геномные наборы данных на локальных компьютерах. Раньше эти данные весили сотни террабайт, а теперь они жмутся в гигабайты. Этот метод, названный Genotype Representation Graph (GRG), описан в статье, опубликованной 5 декабря 2024 года в Nature Computational Science. GRG использует графы для представления генотипов, что позволяет компактно и интуитивно кодировать информацию о геномах, а также выполнять вычисления без необходимости разжатия данных. Это делает анализ биобанковских данных более эффективным и менее затратным. В отличие от традиционных матричных представлений, GRG фиксирует связи между индивидами через общие мутации в их геномах. Метод был разработан для решения проблемы роста объема данных, который теперь может достигать петабайтов из-за увеличения доступности полногеномных последовательностей. GRG обеспечивает масштабируемость и точное представление данных, позволяя проводить сложные анализы, которые ранее были недоступны из-за высокой вычислительной стоимости.

Исследование уже привлекло внимание научного сообщества, и другие ученые начали тестировать метод на различных наборах данных. Работа поддержана грантом Национального института здравоохранения США.

#Data #Math #Software #Whitepaper

Evolution of software architecture with the co-creator of UML (Grady Booch) (Рубрика #Architecture)

Интересная серия подкаста с Гради Бучем, на книгах которого я учился в самом начале карьеры:) Гради придумал объектно-ориентированное проектирование и "метод Буча", который был предтечей UML. Дальше он вместе с Rumbaugh и Jacobson стал создателем языка UML (Unified Modeling Language), а также основал компанию Rational Rose, которую 20 лет назад купил IBM. Сразу после покупки Rational Гради стал Fellow внутри IBM и, судя по разговору в подкасте, именно это ни один раз его спасало от увольнения (как я понял Fellow нельзя так просто взять и уволить). В следующем году Гради исполнится уже 70 лет, но он бодр и полон сил.
Сам подкаст затрагивает следующие основные темы
1) Эволюция разработки ПО: разработка программного обеспечения - это история повышения уровня абстракции, где современные фреймворки и облачные сервисы стали ключевыми архитектурными решениями.
2) Роль архитектора изменилась: теперь архитектор решает системные проблемы и управляет более абстрактными уровнями системы.
3) Гради Буч примерно 20 лет назад получил предложение от Билла Гейтса стать Chief Architect всего Microsoft, но он отказался и сосредоточился на работе в IBM, в частности, в области искусственного интеллекта (помогал делать IBM Watson).
4) UML был создан для описания систем на разных уровнях абстракции и впоследствии стал стандартом. Несмотря на это, со временем его использование уменьшилось из-за сложности, которая появилась в версии 2+. Кстати, я действительно помню, как сложность скачком увеличилась и UML начали двигать от визуализации архитектуры в сторону языка прогаммирования, из которого можно генерить код на обычных языках
5) Среди современных вызовов есть следующие
- В bigtech компаниях иногда используют формальные методы для описания алгоритмов распределенных систем - это нужно для сложных случаев
- AI и LLM сейчас на коне, но Гради отмечает их потенциальные ограничения и опасности.
6) Эволюция архитектуры произошла из-за распределенных систем, которые потребовали новых методов обмена сообщениями между частями системы. А современные архитектурные решения часто зависят от предварительно созданных компонентов и API, что снижает риски и затраты на создание систем.
7) Напоследок Гради дает совет, что начинающим инженерам-программистам не стоит бояться экспериментировать и учиться новому.

#DistributedSystems #Architecture #Software #SystemDesign