Материалы из Code of Architecture про базы данных и распределенные системы

В продолжении поста хочу поделиться материалами из клуба Code of Architecture
- Design Data-Intensive Applications (вот плейлист)
- Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4)
- Distributed Systems, 4th Edition (вот статья с ссылками на все выпуски и кратким саммари)
- Обсуждение white paper "Amazon Aurora" (статья с саммари)

Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:)

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

POSTGRES: The First Experience (POSTGRES: Первое знакомство)

Эта книга отлично подходит для начинающих знакомиться с популярной базой данных Postgres. Авторами книги являются Pavel Luzanov, Egor Rogov, Igor Levshin, причем Егор Рогов является еще и автором книги "PostgreSQL 15 изнутри", а про эту книгу я уже рассказывал. И хоть книга про внутрянку Postgres хороша, но она сложновата для старта, а сегодняшняя книга отлично для этого подходит. Она состоит всего из 175 страниц, что разделены на 12 глав, представленных ниже. Скачать книгу можно здесь: русская версия, английская версия

1. PostgreSQL — what is it all about? - рассказ про возникновение и развитие проекта postgres
2. What’s new in PostgreSQL 15 - changelog изменений в версии 15 по сравнению с 14 версией
3. Installation on Linux and Windows - простенькая инструкция про установку postgres, чтобы с ней можно было поиграться
4. Connecting to a server, writing SQL queries, and using transactions - пример работы с postgres через командную строку с выполнением DDL (Data Definition Language), DML (Data Manipulation Language), DCL (Data Control Language), TCL (Transaction Control Language) или по простому: create table, alter table, drop table, select, insert, delete, update, grant, revoke, begin/commit, rollback
5. Learning the SQL language on a demo database - демо на примере букинга отелей, покупки билетов, аэропортов и так далее. Эту демо-базу можно скачать и поиграть с запросами посложнее, включая функции агрегации, оконные функции, работу с массивами, рекурсивные запросы, а также работу с расширениями.
6. Using PostgreSQL with your application - глава с рассказом о том, как заводить пользователей для отдельных приложений. Дальше удаленными подключениями из программного кода (php, perl, python, java). Дальше идет рассказ о том как делать бекапы.
7. Minimal server setup - глава про настройки postgres и как они влияют на работу системы. Здесь на сцене появляются настройки: буфферов (shared_buffers), размера кеша (effective_cache_size), рабочей памяти (work_mem), настройки autovacuum, настройки костов для планировщика запросов (random_page_cost и seq_page_cost). Интересно, что в книге приводит настройка 1C.
8. About a useful pgAdmin application - глава про использование UI для конфигурирование postgres
9. Advanced features: full-text search, JSON format, foreign data wrappers - рассказ про дополнительные фичи, доступные в postgres, среди которых есть полнотекстовый поиск, который не сравнится с условным elastic, sphinx, но для части вещей подойдет. Другая крутая фича jsonb, которая позволяет использовать postgres как документо-ориентированную базу данных (залезая на террирторию MongoDB), причем мы можем индексировать поля внутри jsonb. Ну и финальная фича - это внешние интеграции через foreign-data wrapper.
10. Education and certification opportunities - здесь идет речь про обучение и сертификации, которые есть у компании Postgres Professionals и какие области они покрывают.
11. Keeping up with all updates - описание источников для получения дополнительной информации: mailing list, конференции
12. About the Postgres Professional company - описание компании Postgres Pro, вендора Postgres из России, в которой работают авторы этой книги

#Databases #DistributedSystems #Architecture #SoftwareArchitecture #Software

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023

Это крутое интервью от топовых специалистов
- Мартина многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад
- Jesse я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад
Оба участника превосходно шарят в теме разговора и их интересно слушать. Вот тут доступна расшифровка.

Ниже тезисно расскажу основные мысли
Мартин рассказывает про свою книгу "DDIA", котороя про основы работы с данными и широкий ландшафт технологических решений (на момент 10 лет назад, когда Мартин начинал писать книгу)
Мартин планирует написать второе издание книги, в котором он рассмотрим вопросы
- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше
- Закат Map-Reduce, чью поляну забрали cloud DWH с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой
Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

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

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

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

Дальше Мартин вспоминает про automerge, что я упоминал в начале и потом переходит на тему работы ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink).

Ну и напоследок участники дают советы
- Мартин: "I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there."
- Jesse: "There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to you", где приведены карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильных сторон и предпочтений, стоит выбрать свой путь.

#Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture

How Data & Software Eng. Teams Collaborate to Ensure Smooth Data Integrations • Sam Bail • GOTO 2023

Интересное выступление Sam Bail про коллаборацию команд, что отвечают за разработку софта и за аналитические данные:) Слайды этого выступления доступны здесь.

Сетап проблемы выглядит так

Product manager: We’re launching this awesome new feature next month! And we need analytics from day 1! Let’s GOOO!
Data team: HOLD ON! Lemme talk to the software engineering team first and see what their data architecture looks like…

А дальше доклад посвящен следующим темам и выстроен в виде важных вопросов, которые обычно задает Sam в очередном проекте
1. Logistics - нужны доки, нужны встречи и понятная зона ответственности, понятные коммуникации, ответы на вопросы: что мы планируем измерять и когда (уже в первый день, неделю, месяц, ...). Как сделать так, что команда разработки была в синке с аналитикой.
2. Infrastructure - где хостятся данные, какой там тип хранилища, могут наши ETL инструменты с этим справиться, нужен ли SSH туннель. Есть ли prod и dev инстансы, мы используем реплики для получения данных? Нужен ли нам доступ на запись? Что мы делаем с credentials (личные они или общие, как мы их шарим). Когда удастся получить доступ к данным? На dev или prod?
3. Data model - как выглядит схема данных, есть ли документация, кто поддерживает изменения в схеме и кто и как их коммуницирует? Как будет выглядеть data constraints enforcing (foreign key relationship, NULL values, default values, JSON schemas)? Как обрабатываются таймзоны в датах, валюты? Действительно ли мы сохраняем все, что хотим измерять?
4. Application and data flow - как и когда записи создаются и поля заполняются значениями? Какие действия вызывают модификации значений? Как события модификаций данных логируются (поле updated_at или отдельная таблица с событиями логирования)? Как будут обработаны удаления (hard или soft удаления)? Архивируются ли "старые" данные? Нужна ли миграция данных из старого приложения? Будут ли реалистичные тестовые данные, на которых можно будет разрабатывать? Будут ли тестовые данные в production среде?
5. Data contracts - как будут документированы договоренности из пунктов 1-4? И как мы будем обеспечивать их соблюдение в будущем не требуя слишком большого человеческого участия? Что из этого можно вынести в CI/CD и проверять на стороне производителе данных (а не как обычно на стороне потребителя)? Как нужно будет коммуницировать об изменениях и кого надо будет информировать об этом? Что делать, если что-то сломается? Как надо будет репортить о проблемах, а также какое SLA будет на фиксы?

Автор обобщает весь доклад тремя пунктами

- Integrating data from a new source into your data warehouse isn’t just “plug n play”
- There are an infinite number of questions to consider. You will probably miss something.
- The key is connection and context between teams.

А дальше, если все сделать правильно, то проблема из самого начала превращается в

Product manager: Look at this awesome new feature! And the dashboard to track all these cool metrics!
Data team: Well it’s not everything you asked and it was a bit bumpy getting there, but it works! Go team!

#Data #Software #SoftwareDevelopment #Engineering #Management #Leadership #Databases

AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой

1) Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности
- Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning.
- Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие)
2) Шардированная база поддерживается семантику вида read commited и repetable read
3) Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов
4) Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы
5) Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами.
6) В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты)
7) Пока эта limitless версия Aurora доступна через заявку на превью

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Amazon Aurora DSQL (Рубрика #Data)

Вернер Вогель, CTO Amazon, в своем keynote на re:Invent 2024 полчаса рассказывал про новые возможности базы Aurora, которая появилась порядка 10 лет назад, а теперь перещла в класс newSQL и стала по фичам напоминать Google Spanner, который как раз появился больше 10 лет назад. Вот какие фичи выделял Вернер
1) Serverless Architecture - для автоматического масштабирования под нужные нагрузки
2) High Availability - для одного региона 99.99% availability, для мультирегионального master-master сетапа 99.999%
3) PostgreSQL Compatibility - полная подддержка PostgreSQL
4) Performance - обещают 4х скорость по сравнению с другими похожими решениями, видимо, из мира newSQL. Я бы глянул на бенчмарки, чтобы понять с кем они сравнивались:)
5) Active-Active Multi-Region Operations - собственно, мультирегиональный вариант, который может принимать записи и реплицировать их в реальном времени (интересно глянуть насколько это быстро работает в мультирегиональном исполнении)
6) Zero Infrastructure Management - пользователям не надо думать об инфре (кроме как сколько это счастье будет стоить)
7) Innovative Transaction Processing - здесь Вернер пафосно рассказыва про аналог гуглового TrueTime, что был еще 10+ лет назад в Google Spanner. Теперь у Amazon есть свои спутники и атомные часы для микросекундной точности и все это называется Amazon Time Sync Service. Это и позволяет сделать распределенные транзакции с хорошими гарантиями консистентности:)

P.S.
Про Aurora я уже часто упоминал раньше
- Бонусный выпуск Code of Architecture по white paper "Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases"
- AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

#Databases #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership

Research Insights Made Simple #14 Review of"What goes around comes around ... and around" (Рубрика #Databases)

Этот выпуск посвящен обсуждению whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили половину статьи, успев разобрать общее впечатление от статьи и часть про модели данных и языки запросов. В итоге, получились следующие темы
- Введение и знакомство с гостей
- Общий обзор статьи
- Отличия российского и мирового контекста развития БД
- Обсуждение авторов статьи и их влияния на индустрию (Майкла Стоунбрейкера и Эндрю Павло)
- Эволюция моделей данных и языков запросов
- MapReduce (аля Hadoop и почему они уже leagcy)
- Системы KV и их ограничения
- Документно-ориентированные базы данных (MongoDB)
- Wide Column Family и Apache Cassandra
- Полнотекстовый поиск - Elasticsearch и встроенные возможности в RDBMS
- Векторные базы данных и семантический поиск
- Многомерные данные и array databases
- Графовые базы данных
- Заключение и анонс следующей темы

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

#Software #Engineering #Metrics #Databases #Architecture #Devops

Вакансия java разработчика в a/b платформу (Рубрика #Vacancy)

Что-то в последнее время я пишу только про позиции engineering менеджеров, но нам в компании требуются не только руко водители, но и крутые инженеры на сложные задачи. Сегодня я хотел рассказать про позицию java разработчика в a/b платформу в команду, что делает движок для обсчета всех метрик по экспериментам для всей компании. Круто, если этот инженер будет уровня senior и дополнительным плюсом будет глубокое знание Apache Spark.

Если говорить про a/b платформу, то это действительно важный для всей компании проект, который несет под себе инженерную сложность (про нее расскажу подробнее). Если говорить про a/b тесты, то есть классическая книга Рона Кохави "Доверительное a/b тестирование", про которую я рассказывал раньше. Если же говорить про историю a/b платформы, то она была у нас давно, но раньше их было много и они кусочно покрывали разные уровни тестов - когда я приходил в компанию порядка 9 лет назад, то уже тогда был прототип платформы DCO, которую мы с тех пор раскачали и использовали для экспериментов в вебе и мобильных приложениях. Пару лет назад мы решили закопать DCO и сделать новую платформу Hippo (я как-то показывал ее потенциальный логотип).

С тех пор платформа сильно выросла и научилась многому, но пришло время масштабировать ее на всю компанию и для этого надо сделать многое по расчету метрик, которые прошли следующий путь
- Все аналитики из продуктов считают метрики по экспериментам в своих python ноутбуках (легко ошибиться или получить результат, пытая данные под разными углами)
- Лаборатория экспериментальной статистики написала свои алгоритмы обсчета метрик для a/b экспериментов на таких же лабах, но для ограниченного набора метрик
- Инженерная команда metric store забрала эти python ноутбуки и перевела на Apache Airflow, где расчеты велись поверх Greenplum, где MPP база была нашим основным хранилищем данных для аналитических вычислений
- Инженерная команда metric store перевезла расчет этих метрик на новую архитектуру, где метрики считаются с помощью Apache Spark, а данные лежат уже внутри нашего Data LakeHouse (DLH)

По-факту, наша датаплатформа мигрировала на подход с DLH, который мы как-то разбирали с Колей Головым в подкасте Research Insights. Кстати, в ближайшее время будет серия подкаста с разбором того, как мы это делали с техническим директором датаплатформы. Плюс про a/b платформу тоже будет отдельный эпизод подкаста, где мы поговорим про то, что это такое, насколько она важна и сложна. Но если вы хотели решать сложные технические задачи уже сейчас, то можете писать мне в личку и мы обсудим варианты.

P.S.
Кстати, у меня уже есть эпизоды
- С руководителем этого отдела Андреем Цыбиным, где мы говорили про соседний продукт Statist (продуктовая аналитика)
- С лидом бекенда этого продукта Женей Козловым, где мы говорили как про бекенд Statist, так и в общем про инженерный подход к разработке

#Engineering #Software #Career #Vacancy #Databases #Fintech

Research Insights Made Simple #15 Review of"What goes around comes around ... and around" - Part II (Рубрика #Databases)

Этот выпуск продолжает обсуждение whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Здесь мы поговорили о том, как менялись архитектуры баз данных и почему, а также обсудили выводы авторов исследования о будущем баз данных. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили вторую половину статьи, куда входили следующие темы

- Введение и план обсудить эволюцию архитектур баз данных за 20 лет.
- Развитие архитектур реляционных и колоночных БД
- Появление и развитие облачных БД с разделением хранения и вычислений (масштабирование ресурсов, эластичность вычислений, объектное хранилище)
- Прорывы в OLTP-масштабировании (пример AWS Aurora)
- Data Lake House и гибридные движки (Parquet, Iceberg, разделение масштабирования воркеров и хранилища)
- Качество данных и подходы к хранению разных классов данных
- Изменение парадигмы ответственности за данные в компаниях (Data Mesh)
- NoSQL базы, CAP-теорема и консистентность (MongoDB, Cassandra, ACID в NoSQL)
- NewSQL базы (Google Spanner, CockroachDB, YDB) и сложность их эксплуатации
- Новые технологии и аппаратная поддержка БД
- Роль маркетинга в успехе технологий, опенсорс и пользовательский опыт
- Финальные выводы whitepaper и размышление о будушем баз данных

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

#Software #Engineering #Metrics #Databases #Architecture #Devops