Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - Part II - (Рубрика #Management)

Продолжая рассказ про темные данные, которые я начал в прошлом посте, в этом я хотел рассказать про классы темных данных, которые выделяет Дэвид Хэнд, член Британской академии, президент Королевского статистического общества.

1) Данные, о которых мы знаем, что они отсутствуют - это "известные неизвестные", которые возникают, когда мы знаем, что в данных есть проблемы, скрывающие значения, которые могли быть записаны
2) Данные, о которых мы не знаем, что они отсутствуют - это "неизвестные неизвестные". Тут мы даже не знаем, что нам не хватает каких-то данных. В книге рассказывает про катастрофу Challenger, где принимающим решения не хватало информации о поведении уплотнительных колец при холодной погоде, но они об этом и не знали
3) Выборочные факты - к таким проблемам приводит плохой набор критериев для включения в выборку или ошибочное применение разумных критериев. Также сюда можно отнести p-hacking, который состоит в проведении большого количества статистических тестов, но рассказе только о тех, что были успешны
4) Самоотбор - этот вариант является подтипом предыдущего типа темных данных, а именно выборочных фактов. Он проявляется, когда людям дают самим решать что включать в результаты опроса, а что нет. У отсутствующих данных могут быть системные отличия от тех, что все-таки были внесены.
5) Неизвестный определяющий фактор - тут старая как мир история про то, что корреляция не является причинно-следственной связью. Тут же автор вспоминает про парадокс Симпсона
6) Данные, которые могли бы существовать (контрфактуальные данные) - это данные, которые мы смогли бы увидеть, если бы предприняли какие-то другие действия или наблюдали бы за происходящим при других условиях.
7) Данные, меняющиеся со временем - одни данные могут перестать регистрироваться за пределами периода наблюдений, другие - потому что изменилась природа. В итоге, время может скрывать данные разными путями.
😍 Неверно определяемые данные - определение данных может меняться со временем, чтобы лучше соответствовать своему предмету и назначению. Это может вызывать проблемы в интерпретации временных рядов, так как сам характер данных меняется.
9) Обобщение данных - здесь идет речь о том, когда мы вместо данных сохраняем какие-то их параметры: среднее, медиану, средне-квадратичное отклонение и так далее. Так мы теряем часть информации из данных
10) Ошибки измерения и неопределенность - этот тип данных про погрешность измерений, а также при конвертации данных из разных форматов.
11) Искажение обратной связи и уловки - этот тип данных возникает, когда собранные значения начинают влиять на исходный процесс. Есть примеры с раздуванием оценок и пузырями на рынке акций. Плюс можно вспомнить квантовую физику, где само измерение влияет на состояние системы:)
12) Информационная ассиметрия - этот тип данных возникает, когда у разных участников взаимодействия существуют свои наборы данных. Акерлоф, Спенс и Стиглиц в 2001 году получили Нобелевскую премию по экономике за работы по исследованию рынков с ассиметрией информации (они исследовали рынок подержанных автомобилей "лимонов")
13) Намеренно затемненные данные - здесь речь про предумышленный отбор определенных фактов для скрытия информации и манипуляции фактами для обмана или мошенничества
14) Фальшивые и синтетические данные - такие данные создаются искусственно, например, для мошенничества. Интересно, что сделать качественные синтетические данные сложно, но реально при помощи симуляции процессов.
15) Экстраполяция за пределы ваших данных - данные обычно используются для построения моделей. Эти модели нормально работают в границах тех данных, что мы видели. А вот выходя за границы мы получаем эту проблему с экстраполяцией. Тут опять приводится пример с шаттлом Challenger.

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

#Management #Data #Math #Statistics

Проводим архитектурное ревью продуктовой фичи - Максима Педченко - Яндекс Go Product Engineering Meetup (Рубрика #Architecture)

Хороший доклад от Максима Педченко из Yandex, в котором он рассказал зачем проводить архитектурное ревью и даже показал на +/- реальном примере как оно выглядит. Забавно, что пример был из домена реферальных программ, а проще говоря как сделать фичу с промокодами, которыми пассажир сможет делиться со своими друзьями. Эта фича обычно направлена на активацию механики сарафанного радио, когда ты customer acquisition cost несешь не на рекламу, а раздаешь его тому, кто рекомендует сервис и тому, кто пользуется рекомендацией и становится новым клиентом. В управлении маркетинговых технологий, что входит в мой юнит есть сервисы на эту тему и они называются BAF (Bring a Friend) и они приносят значимую часть новых клиентов.
Но если возвращаться к самому докладу, то в нем неплохо описана проблематика + приведен алгоритм архревью продуктовой фичи
- Появление идеи проекта
- Проверка гипотезы
- Задача на полноценную разработку (с стандартными НФТ по надежности, безопасности, и так далее)
- Создание RFC/ADR с описанием изменений и дальше ревью по стандартному флоу вопросов. В самом докладе станадартный список был в конце выступления и звучал примерно так
-- Какую продуктовую проблему решает проект
-- Какое место занимает решение в системе
-- Какие фолбеки предусмотрены внутри и снаружи
-- Какая ожидается нагрузка
-- С какими компонентами взаимодействует фича
А в примерах ревью разбирались реальные фичи, поэтому вопросы были в их контексте и они были такими
-- Сколько пользователей (ожидаемая нагрузка)
-- Как масштабироваться (scalability)
-- Можно ли сделать оптимальнее (performance)
-- Что с отказами и 500x (отказоустойчивость)
-- Могут ли быть гонки (что делать для обеспечения консистентности данных при паралелльных/асинхронных запросах)
-- Как сделать удобнее для пользователя (некоторые оптимальные решения с точки зрения прямо ломают UX в corner cases, а значит надо сделать чуть сложнее, но удобнее для пользователя)
-- Идемпотентность вызовов (включая идемпотентность во времени) - если так проектировать, то проще обеспечить надежность системы, так как условные ретраи будут безопасными
- Под конец автор замечает, что ревью не должно длиться бесконечно и когда-то мы должны остановиться и сказать good enough, а потом пойти реализовывать спроектированное решение. Иначе мы можем бесконечно крутиться в цикле paralysis of analysis. Условно говоря, лучшее - это враг хорошего:)
- Для условных экспериментальных фичей такое сложное ревью можно не делать, так как это может быть слишком дорого для эксперимента. Причем дороговизна с одной стороны за счет траты времени инженеров, а с другой стороны за счет замедления lead time изменений. Но если мы делаем уже что-то на долгосрок, то там архревью принесет много пользы на долгом горизонте.
- Для того, чтобы архревью работало надо описать его цели и правила, а также зафиксировать SLA по его проведению (например, сроки в которое оно должно быть пройдено и получен ответ)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

Вакансия "Аналитик-исследователь в области статистики и A/B-тестирования в Т-Банк" - (Рубрика #HR)

Последнее время я достаточно много рассказываю про работу с данными, проведением экспериментов и построение a/b платформы. И это все не просто так - мы создаем a/b платформу на всю компании, а также у нас есть лаборатория прикладной статистики, которой руководит Роман Филев (@simbaizdolgopi). Сейчас Рома ищет в свою лабораторию аналитиков для того, чтобы разрабатывать и внедрять SOTA методы проверки гипотез, пионерить лучшие практики и катить их через единую платформу принятия решений (А/Б-платформа, платформа продуктовой аналитики и тд). А еще эти ребята часто десантируются в продуктовые команды для помощи в сложных ситуациях в этой области.

В обязанности аналитиков будут входить
- Исследование и применение современных математических и статистических методов в А/В-тестировании
- Коммуникация с бизнес-подразделениями для точной формализации бизнес-задач
- Разработка и совершенствование методов А/В-тестирования
- Распространение лучших практик A/B-тестирования через участие в образовательных проектах и выступления на профильных конференциях

Для успешного выполнения обязанностей нужны следующие теоретические знания
-> Теория вероятностей и статистика:
-- Прочное владение базовыми курсами
-- Вдумчивое понимание проверки статистических гипотез, включая ошибки I и II рода и интерпретацию p-value
-- Опыт работы с основными статистическими критериями, в том числе Z/T/U-тестами и критериями Колмогорова-Смирнова, Андерсона-Дарлинга
-- Знание предельных теорем, включая Закон больших чисел (ЗБЧ), Центральную предельную теорему (ЦПТ) и теорему Донскера-Прохорова
-> A/B-тестирование:
-- Глубокое понимание статистической механики A/B-тестирования, с умением связывать тесты с проверкой гипотез
-- Навыки определения размеров выборки, работы с множественной проверкой гипотез и ratio-метриками
-- Осведомленность о современных подходах ускорения A/B-тестирования, таких как снижение дисперсии и последовательная проверка гипотез
-> Теория метрик:
-- Понимание различных видов метрик и принципов их выбора
-- Знакомство с подходами к созданию иерархии метрик

Минимально с точки зрения практики нужно
- Иметь уровень middle аналитика в SQL и Python
- Иметь опыт работы с click, gp, superset, а также с инструментами визуализации и системами управления проектами (Jira/Confluence)

Если вам понравилась вакансия, то пишите в личку Роме (@simbaizdolgopi) и уточняйте детали.

P.S.
Кстати, я уже рассказывал про книги на тему статистики, которые были бы полезны такому инженеру
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании
- Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать

#Vacancy #Statistics #Data #Analytics

Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023 (Рубрика #Architecture)

Интересный доклад про описание архитектуры от Романа и Валентина на последнем ArchDays. Суть доклада в том, чтобы показать как это документирование устроено в строительной компании "Самолет", где и так многое завязано на информационном моделировании BIM (Building Information Model) для отображения архитектуры зданий, который построили и строит компания "Самолет". Компания решила пойти дальше и стать поистине девелоперской компанией и, в итоге, получилась гетерогенная архитектура предприятия, связанная с автономностью команд, отсутствием единого понимания стратегической цели. Потом в компании появились архитекторы, которые занялись решением этих проблем с помощью документации архитектуры и кажется, что у них это получилось достаточно неплохо. Если говорить про сам рассказ из доклада, то
- Сначала был попытка использовать plantuml для построения диаграмм
- Потом была попытка использовать structurizr для того же
- Потом все пришло к использованию Dochub, про который говорится, что это уже не просто картинки и документация, а целый "цифровой двойник"
- Дальше идет рассказ о том, что умеет Dochub: расширяемая метамодель, визуализации (plantuml), подключаемые плагины
- Потом заходит речь про внедрение инструмента и описание первых двух уровней из C4 Model (system и container уровней)
- В общем, в "Самолете" инструмент прижился и его используют для управления архитектурой и дальше есть планы от этого инструмента двигаться в сторону кода и инфры - условно выдавать доступы или ресурсы только если все качественно задокументированно в Dochub. Кстати, это хорошая мотивация для команд поддерживать эту документацию в актуальном состоянии, особенно если это получится автоматизировать:)

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

И этому архитектору 2.0 поможет фреймворк SEAF (Sber Enterprise Architecture Framework), который Роман кратко презентует в последние 10 минут этого выступления. Про него я расскажу в отдельном посте, который будет по мотивам другого выступления Романа, где он почти час рассказывает только про SEAF.

P.S.
На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать
- Архитектура как код - Роман Пионтик - ArchDays 2022
- Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022
- Материалы к моему докладу "Architecture at T-Bank: how we design our solutions"
- Раз архитектура — «as Code», почему бы её не покрыть тестами?!
- Проводим архитектурное ревью продуктовой фичи

#Architecture #Software #SoftwareArchitecture #Management #Processes

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

Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023 (Рубрика #Architecture)

Интересный доклад от Кирилла, в котором он продолжает тему про архитектурный репозиторий, которую он поднял на ArchDays 2022. В этом продолжении идет речь о том, как сделать архитектурные диаграммы актуальными и основные мысли доклада следующие
- Кирилл начинает с постановки проблемы неактуальных схем и выделяет 4 момента:
-- По неактуальной схеме невозможно принимать решения
-- К неактуальной схеме низкое доверие у всех участников процесса разработки
-- Сложно анализировать состояние системы тем, кому это нужно делать (аудиторы, участники процесса разработки)
-- Такие схемы не помогают и во время operations - техподдержка и SRE не могут их эффективно использовать
- Для решения проблемы заводим архитектурный репозиторий, где с помощью C4 Model и подходов из DDD описываем свои сервисы (компоненты, из которых состоит наша система). Причем список компонентов должен вестись централизованно, чтобы мы могли их однозначно идентифицировать и переиспользовать внутри наших схем
- Для того, чтобы архитектурный репозиторий актуализировался автоматически нам требуется завязаться на наши конфигурационные данные о наших сервисах:
-- Описание самого сервиса - в Sber Market это app.toml (конфигурация в формате TOML). Кстати, данные из этого файла используются для пополнения каталога сервисов, что используется для описания в архрепо
-- Конфигурацию и зависимости сервиса - этот файл values.yaml используется для деплоя сервисов в production, поэтому он содержит актуальные параметры или сервис просто не будет работать как задумывалось в проде. Ну а для архитектуры можно использовать файлы из разных сервисов можно построить граф зависимостей для сервисов.
-- Описание базы данных - в Sber Market это structure.sql, который содержит схему базы данных и может использоваться для составления ER-диаграмм.

В итоге, построение архитектурных диаграмм выглядит примерно так:
- Чтение файлов app.toml, values.yaml, structure.sql
- Преобразование данных из файлов к объектной модели
- Построение графа взаимосвязей для разных сервисов
- Рендеринг схем для всех сервисов - внутри сервиса есть ER-диаграммы, а также container диаграммы, на которые подтягиваются как сервисы в которые мы стучимся, так и те, что ходят к нам (они подтягиваются из values.yaml потребителей)
- Сохранение схемы
- Отображение схемы

В общем и целом, именно такой подход мне кажется правильным движением в сторону архитектуры как код:
- Использование стандартного тулинга для документации архитектуры
- Сама информация о сервисах и их взаимосвязах не заполняется руками, а тянется из системы, что является источником истины и определяет как наши сервисы задеплоены в реальности
- Поверх накручиваются тесты для контроля архитектурной целостности, что гоняются в пайплайнах (fitness functions из книги "Building evolutionary architecture")

P.S.
На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать
- Архитектура как код - Роман Пионтик - ArchDays 2022
- Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022
- Материалы к моему докладу "Architecture at T-Bank: how we design our solutions"
- Раз архитектура — «as Code», почему бы её не покрыть тестами?!
- Проводим архитектурное ревью продуктовой фичи
- Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

Архитектура приложения и ошибки проектирования - Рустам Ахметов - Joker 2022 (Рубрика #Architecure)

Интересный доклад от Рустама Ахметова на тему архитектуры того, как можно организовывать свой код приложений. Автор подошел к снаряду основательно и сделал обзор всех распространенных вариантов архитектуры, делая отсылки к оригинальным статьям, где про них в первый раз вспоминали. Собственно автор сначала говорит о том, что хорошая архитектура и структура кода помогает нам бороться со сложностью. А это значит, что новички на проекте, открыв IDE, легко смогуть понять как он устроен и как наносить пользу без долгого изучения, а как же тут принято раскладывать код по папкам:)

Основные мысли доклада следующие
- Horizontal Design - это привычная всем слоенная архитектура. Так писали код уже давно и там было обычно деление на presentation tier, app tier, database tier. Этот подход был доминирующим долгое время, он доминирует и сейчас, но постепенно он вобрал в себя плюсы из других подходов. Кстати, иногда tiers было больше трех:) Например, в 2003 году появилась книга "Domain-Driven Design" Рика Эванса и начал появляться еще отдельный doaimn layer
- Vertical design - этот подход появился еще в девяностые годы и нужен был для масштабирования команды, чтобы отдельные подкоманды могли автономно работать. В итоге, внутри монолитного приложения появлялись отдельные изолированные модули внутри приложения (модули делились по доменам или функциям). Это был прообраз микросервисов. Кстати, сейчас популярна становится vertical slice architecture, про которую я уже как-то рассказывал при разборе выступления "Designing for change with Vertical Slice Architecture - Chris Sainty" с NDC. Этот подход хорош для небольших приложений
- Hexagonal - в 2005 году эту архитектуру предложил Alistair Cockburn. Суть была в том, чтобы внешние абстракции хорошо уметь в отдельных модулях. Здесь новинка в том, чтобы изолировать бизнес-логику от внешних интеграциях. Но как это организовать на уровне кода Алистер не показал.
- Onion - луковичная архитектура была описана в 2008 году Jeffrey Palermo, который взял примерно ту же идею, что и hexagonal architecture, но показал как это сделать на уровне приложения и сделать не круговой, а разложить по слоям: отдельные папки для взаимодействий, отдельная папка для бизнес-логики, отдельная папка для объектной модели данных
- Clean Architecture - предложил в 2012 Uncle Bob (Robert Martin), который попытался объединить hexagonal и onion и отделить бизнес-логику от внешних зависимостей, куда вошли и фреймворки. В общем, идея стала популярной, но догматизм Uncle Bob мешает воспринимать его серьезно.

Дальше автор рассмотрел современную hexagonal architecture from Netflix, которая с точки зрения автора похожа скорее на современную слоенную архитектуру:) В жизни автор предлагает этот шестиугольник от Netflix превратить в слои примерно так: input -> adapter -> app core (service layer) -> adapter -> output.

Дальше автор показывает демки того, как все виды архитектур выглядят в коде и какие они имеют преимущества и недостатки. Все выглядит достаточно наглядно, поэтому рекомендую демку к просмотру.

#Architecture #SoftwareArchitecture #SystemDesign #Engineering