Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)

В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.

Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития

Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.

Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.

Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.

Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/

Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.

#Database #Architecure #Software #Data #SystemDesign #Management

Черная пятница в издательстве «Питер» (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 40% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг и докупил на этой распродаже еще книг

Новые купленные книги
- Производительность систем - интересная книга о производительности от Brendan Gregg, крутого эксперта, который одновременно много сделал для внедрения eBPF, о чем можно узнать из документалки
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач
- Продвинутые алгоритмы и структуры данных - книжка о самых необходимых алгоритмах решения сложных задач программирования в области анализа данных, машинного обучения и графов. Хочу подтянуть свои знания алгоритмов
- Ненормальные личности. Учение о психопатах - решил почитать про ненормальность от Ганнушкина
- Об уме вообще - книга Павлова (хозяина знаменитой собаки из экспериментов), который писал интересно о работе мозга

Книги, что я уже успел прочитать
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.

Книги, что мне еще предстоит прочитать
- Data mesh в действии - интересная тема о переходе от DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:)
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга
- Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо".
- Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее
- Грокаем функциональное программирование - интересно почитать просто про функциональщину
- Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники
- Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5
- Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление.

#Sales

How to Make the World Add Up (Ложь, наглая ложь и статистика) - Part II (Рубрика #Math)

Продолжая рассказ про книгу Тима Харфорда "How to Make the World Add Up", закончу списком оставшихся правил:

4. Чтобы увидеть всю картину, отступите на шаг назад. Важно уметь видеть информацию в контексте, тогда утверждения вида "случился еще один ужасный инцидент" могут заслонять тенденцию, что "в целом количество инцидентов снизилось":) То есть нам необходимы сравнения и контекст, чтобы понять как тезисы согласуются между собой.
5. Узнайте предысторию. Когда мы видим интригующие результаты исследований, то это часто связано с эффектом публикации (publication bias). Если смотреть шире, то нам нужно определить источник статистических данных и изучить, а все ли данные были учтены.
6. Спросите, кого не хватает. Надо всегда задавать себе вопрос, а все ли группы людей были учтены в исследованиях и если не все, то как бы поменялось исследование. В большинстве старых классических психологических исследованиях участниками были студенты колледжей, а не репрезентативная выборка всего населения. Одновременно, там не хватало даже студенток, которых можно было относительно легко привлекать к исследованиям, но об этом как-то не думали раньше. Про это подробнее можно прочитать в посте про "Опрос, что изменил опросы"
7. Требуйте прозрачности от компьютера. Этот пункт особенно актуален в наше время, когда у нас много больших данных и сложных алгоритмов. Важно не бояться задавать неудобные вопросы о том, что это за данные и как именно работает алгоритм. Интересно, что условный perplexity.ai сразу вместе со сгенерированным ответом дает ссылки на источники, откуда он брал информацию. Это не всегда спасает от галлюцинаций, но вы хотя бы можете сделать факт-чекинг.
8. Цените краеугольный камень статистики. Автор предлагает ориентироваться на официальную статистику, особенно в тех странах, где ей не принято манипулировать в угоду политическому курсу.
9. Помните, что дезинформация тоже бывает привлекательной. Если вам показывают красивую визуализацию, график или дашборд, то надо не стесняться и задавать вопросы о том, а что стоит за такой красотой:)
10. Не бойтесь изменить свое мнение. Автор говорит о том, что надо уметь менять свое мнение при появлении нового опыта или доступной информации. То есть надо рефлексировать относительно того, а не заблуждаемся ли мы, настаивая на старой точке зрения.
11. Золотое правило. Сохраняйте любознательность. В общем, автор предлагает копать глубже и задавать больше вопросов. Он выдвигает гипотезу, что любознательность можно прокачивать ...

Я не знаю можно ли прокачивать любознательность, но у меня она с детства была где-то на уровне 10 из 10. Помню как я доставал родителей, воспитателей, тренеров и учителей своими вопросами "А почему все работает именно так":) Походу, любознательность действительно дает хорошие плоды. Развивайте любознательность у себя и своих детей и изучайте с интересом мир вокруг вас!

P.S.
В своей книге автор упоминает и другие книги про статистику
1) Как лгать при помощи статистики (How to Lie with Statistics) - книга, где на пальцах объясняется как врут с помощью статистики. Собственно, автор книги зарабатывал на жизнь тем, что тасовал данные, убеждая в том числе, что курение не приводит к раковым заболеваниям
2) Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать
3) The Tyranny of Metrics (Тирания показателей) - эта интересная книга, название которой идет наперекор стандартному подходу к измерению всего и вся:) Она напоминает по структуре научную статью и классно описывает проблемы, которые во многом рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой".

#Math #Management #Statistics

Зачем заниматься темой developer productivity в большой компании - D-Day (Рубрика #Management)

В выходные я выступал на конференции D-Day, что оффлайн проводится в Тирасполе.Я рассказывал про тему developer productivity: зачем заниматься этой темой, как это принято делать в индустрии, как мы подходим к этому в Т-Банке. В конце я порекомендовал такой набор источников для более глубого знакомства с темой.

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
😍 Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Сегодня я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для хороших менеджеров.

Доклад будет состоять из 4х частей, которые описаны ниже, причем фокус будет на третьем пункте, а точнее навыках и умениях помимо hard skills, что помогали лично мне расти на протяжении всей карьеры

1) Зачем нам нужны soft skills
- В современном мире процессы разработки становятся все сложнее, зона ответственности IC (individual contributor) все увеличивается и включает system design, operation, data, security, ... (подробнее в моем рассказе о современном SDE и SDLC)
- Для борьбы с этой сложностью обычно применяют разные абстракции, например, для инфры это IaaS -> PaaS -> SaaS -> ...(подробнее в моем рассказе об облачных технологиях для Финтех Школы)
- Мы все живем в комплексном и хаотичном мире (complex и chaotic из фреймворка Cynefin)

2) Как расти в таких условиях
- Для инженеров есть две стандартные дороги: индивидуального контрибьютора или менеджера. В обоих, с какого-то уровня надо уметь проявлять лидерство. Условно, до middle+ IC можно дорасти только на хардах, а вот дальше ...(подробнее здесь)
- Например, в T есть матрица для инженера вида: scope, impact, complexity, leadership, improvement. По этой матрице оцениваются достижения инженеров в Т-рост (подробнее в отдельном посте)
- Т-рост - это процесс, по которому проходят повышения в Т. Инициатором является сам сотрудник, который готовит заявку на повышение с учетом своих достижений, упирая на то, что он закрыл оси вышеуказанной матрицы, а также прикладывает артефакты, которые это доказывает

3) Какие навыки и умения помогут проявлять лидерство и расти в таких условиях
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)
- Важность любопытства и желание копать глубже, чтобы действительно разобраться как что-то работает (или скорее что не работает)

4) Важность hard skills как базы для дальнейшего роста (пи... не мешки ворочать)
Если вы раскачаете софт скиллы с отсутствующей базой в виде hard skills, то это будет шатким фундаментом, который может рухнуть в произвольный момент. А в некоторые компании без них в принципе не попасть - например, у нас для инженеров есть интервью по программированию, языку разработки и system design. Такой набор эффективно отсеивает мастеров разговорного жанра.

P.S.
Запись выступления будет и потом я поделюсь ей в этом канале.

#Leadership #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

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

В продолжение рассказа про эту статью 2024 стоит поговорить про разные подходы к системной архитектуре, которые развивались в последние два десятилетия. Эти архитектуры отражают изменения в software (менялись типы приложений и их требования), а также изменения в hardware, а точнее изменения в параметрах аппаратного обеспечения (мощность CPU, скорость оперативной памяти, разные типы дисков, скорость сети и так далее).

1. Колоночные системы (columnar systems)
Эти системы стали стандартом де-факто в мире аналитических баз данных. Суть в том, что там запросы часто обращаются только к небольшому числу атрибутов таблиц. Колоночное хранение данных позволяет читать только нужные данные, а также лучше сжимать их благодаря однородности значений. Кроме того, можно добиться ускорения выполнения запросов за счет векторизованной обработки данных. Примерами таких баз данных являются Vertica, Amazon Redshift, Google BigQuery, Clickhouse, DuckDB.

2. Облачные базы данных (cloud databases)
Эти базы данных предоставляются в облаках, в которые было модно перевозить свою инфраструктуру. Такие базы обеспечивали масштабируемость и эластичность, что позволяло клиентам динамически изменять ресурсы. Восход этих баз данных связан с тем, что за последние 20 лет скорость сети увеличивалась гораздо быстрее, чем скорость диска, поэтому использование NAS (network attached storage) стало привлекательной альтернативой для стандартного устройства хранения. Собственно, основные вендоры в качества NAS используют объектные хранилища (например, AWS S3). Такая архитектура приводит к тому, что у нас разделяется compute и storage и мы имеем такие преимущества
- Можно обеспечить эластичность на уровне отдельных запросов
- Вычислительные ноды можно отправить на другие задачи, если DBMS не полностью утилизируется
- Можно переместить вычисления прямо на ноды хранения данных - подход называется "pushing the query to the data" и он показывает себя лучше, чем стандартный "pulling the data to the query".
Интересно, что два первых подхода называются serverless computing и в мир DBMS их принесла Snowflake. А среди популярных облачных баз данных есть
- Google Spanner - рекомендую интересный whitepaper
- Amazon Aurora - рекомендую интересный whitepaper, который мы даже как-то разбирали в выпуске подкаста "Code of Leadership", а также рекомендую глянуть рассказ с AWS Re:Invent 2023 о том, как они завезли туда шардирование

3. Озера данных (Data Lakes) и Lakehouses
Облачные платформы разожгли интерес к тому, чтобы отказаться от монолитов в аналитике и перейти к data lakes, где данные как есть загружались в объектные хранилища (S3 like). То есть тут был отход от стандартных ранее ETL (extract-transform-load) к ELT (extract-load-transform). После загрузки, прямо поверх данных выполнялись вычисления при помощи движков lakehouse, минуя стандартные DBMS (типа Greenplum). Собственно lakehouse - это комбинация из data warehouse и data lake:) Данные в data lake хранятся в бинарном виде: Parquet, ORC (optimized row columnar), а для обмена данных in-memory можно использовать формат Apache Arrow. В каждом облаке есть managed data lake сервисы, а также есть отдельные варианты в виде Databricks, Dremio, PrestoDB, Trino.

4. NewSQL-системы
В 2010х годах появился этот класс систем, чтобы совместить ACID транзакции из RDBMS и масштабируемость NoSQL решений. Одним из первых представителей стал уже упоминавшийся Google Spanner. По-факту, тут было 2 типа систем in-memory и стандартные disk-oriented. Часть стартапов ставили на больший спрос на in-memory подходы, но ставка не сыграла. На смену этим подходам пришли распределенные и транзакционные SQL RDBMS навроде TiDB, CockroachDB и думаю, что можно туда добавить YDB с их Calvin-транзакциями. Эти системы подходят для приложений, требующих как высокой производительности, так и строгой консистентности данных.

В продолжении окончание разбора статьи.

#Architecture #Software #DistributedSystems