Собсес Flashcards
1
Q
Был ли у вас опыт работы с ClickHouse?
A
Да, в ЮMoney хранили там логи и аналитику, прежде чем перейти на Greenplum, и я активно писал SQL-запросы, настраивал партиционирование и осуществлял выгрузки/загрузки для быстрой аналитики.
2
Q
Для каких целей вы использовали ClickHouse? (например, аналитика, отчётность)
A
Применял для быстрой аналитики веб-событий, логов, рекламных метрик; там, где нужны были мгновенные агрегации по большим объёмам, а полноценные витрины ещё не были построены в Greenplum.
3
Q
Использовался ли ClickHouse для построения витрин данных?
A
Полных «витрин» на ClickHouse не делали, держали в основном плоские таблицы для скоростной выборки, а полноценные Data Vault- или звёздные схемы перенесли в Greenplum.
4
Q
Как аналитики подключались к ClickHouse для работы с данными?
A
Некоторые заходили через clickhouse-client и SQL, другие пользовались Tableau-коннектором; иногда выгружали CSV и смотрели в Excel.
5
Q
Использовали ли вы какие-либо инструменты для визуализации данных из ClickHouse?
A
Да, тестировали Tableau (через нативный драйвер), а также некоторые коллеги пытались подключать Grafana, но основную визуализацию мы делали через Greenplum.
6
Q
Приходилось ли вам переносить данные в ClickHouse из других систем (например, Greenplum, Postgres, Kafka)?
A
В основном шёл обратный процесс (ClickHouse → Greenplum), но временами выгружали данные из PostgreSQL в CSV и заливали в ClickHouse для быстрой аналитики (Python-скрипт + clickhouse-client).
7
Q
С какими типами движков таблиц в ClickHouse вам приходилось работать?
A
В основном MergeTree и ReplicatedMergeTree, часто партиционировали по дате для ускорения запросов по диапазону дат.
8
Q
Использовали ли вы партиционирование в ClickHouse? Для чего?
A
Да, партиционировали по датам (месяц/день) в лог-таблицах, чтобы запросы на конкретные периоды обрабатывались быстрее и не сканировали весь объём.
9
Q
Приходилось ли вам оптимизировать запросы в ClickHouse для аналитических целей?
A
Да, изменял порядок сортировки (ORDER BY), устранял лишние подзапросы, настраивал подходящие агрегирующие функции (например, вместо DISTINCT считал GROUP BY), чтобы ускорить отчёт по логам.
10
Q
С какими особенностями колоночной СУБД (на примере ClickHouse) вы сталкивались при проектировании аналитических решений?
A
Нужно продумывать структуру и сортировку для каждой таблицы, помнить об отсутствии классических транзакций, учитывать, что сложные JOIN-ы и оконные функции могут работать иначе, чем в PostgreSQL.
11
Q
Использовался ли ClickHouse для оперативной аналитики (near real-time)?
A
Частично, в ЮMoney лог-данные заливались каждые 30–60 минут, что позволяло быстро смотреть активность пользователей почти в режиме online.
12
Q
Как часто обновлялись данные в ClickHouse для целей отчётности?
A
Для некоторых таблиц — раз в день, для логов/событий — от 30 минут до часа; зависело от критичности данных и загрузки сервера.
13
Q
Какие задачи, связанные с ClickHouse и аналитикой, вам запомнились или были наиболее интересными?
A
Перенос больших объёмов (сотни млн строк) в Greenplum и проверка корректности (md5-суммы), а также оптимизация агрегаций в лог-таблице для маркетинговых отчётов.
14
Q
С какими объемами данных приходилось работать в ClickHouse для аналитики?
A
До сотен миллионов строк в одной таблице, объёмы могли занимать десятки-сотни гигабайт, особенно по логам мобильного приложения и веб-трафика.
15
Q
Использовался ли SQL для работы с ClickHouse? Какие особенности SQL в ClickHouse вы знаете?
A
Да, работал через clickhouse-client, учитывал отсутствие классических транзакций, ограниченную поддержку подзапросов и использование специфических функций, например uniqExact.
16
Q
Как вы обеспечивали качество данных, используемых для аналитики в ClickHouse?
A
Сверял итоги с исходниками (суммы, счётчики), делал проверочные выборки после загрузки, писал Airflow DAG, который сигнализировал, если число строк в ClickHouse не совпадает с ожидаемым.
17
Q
Сравнивали ли вы ClickHouse с другими базами данных для аналитики (например, Postgres)? Почему был выбран ClickHouse?
A
Сравнивали; ClickHouse выигрывал в скорости простых агрегаций на больших объёмах. PostgreSQL при огромном числе строк мог сильно замедляться, а ClickHouse отлично справлялся с колоночным хранением.
18
Q
Использовался ли ClickHouse в связке с другими технологиями обработки данных (например, Spark, Hadoop, Airflow)?
A
Да, основная связка была с Airflow, где PythonOperators управляли загрузкой/выгрузкой. Hadoop/Spark больше практиковался в ББР Банке, но без прямой интеграции с ClickHouse.
19
Q
Каким образом данные из ClickHouse предоставлялись конечным пользователям (например, отчёты, дашборды, API)?
A
Либо SQL-запросы через clickhouse-client, либо выгрузки CSV, иногда подключение Tableau, реже формировали маленькие веб-API, которые дергали ClickHouse под капотом.
20
Q
Сталкивались ли вы с необходимостью агрегации данных в ClickHouse для отчётности?
A
Да, особенно по логам: считали число уникальных пользователей, количество событий, CTR по рекламе, группируя данные по дате и регионам.
21
Q
Строятся ли у вас витрины на DBT и перекладываются ли они в ClickHouse?
A
Нет, DBT не внедряли, а основные витрины мигрировали в Greenplum, в ClickHouse оставались лишь плоские структуры.
22
Q
Почему в компании используется PostgreSQL для аналитиков, а не колоночная база данных, такая как ClickHouse?
A
PostgreSQL был изначально для микросервисов, а для аналитики больших объёмов позже выбрали Greenplum. ClickHouse остался для быстрых лог-агрегаций, но не для всего аналитического стека.
23
Q
В чем плюс использования колоночных баз данных, таких как ClickHouse?
A
Высокая скорость при агрегирующих запросах, эффективная компрессия и чтение нужных столбцов, что особенно полезно при больших объёмах данных.
24
Q
Используется ли ClickHouse в вашей текущей или предыдущей работе?
A
В ЮMoney использовался, потом проект перешёл в Greenplum как основную DWH, а после моего ухода из компании новых проектов на ClickHouse у меня не было.
25
Приходилось ли вам строить витрины в ClickHouse?
Нет, только плоские аналитические таблицы; полноценные витрины (Data Vault, звёзды) развернули на Greenplum.
26
Используется ли ClickHouse для какой-либо аналитики в вашей практике?
Да, в ЮMoney анализировали логи, события, рекламные клики, пока не настроили полноценный DWH.
27
Сравнивали ли вы производительность ClickHouse с другими базами данных?
Да, например, с Greenplum. ClickHouse быстрее на простых агрегирующих запросах, Greenplum удобнее для сложных JOIN и Data Vault-моделей.
28
Каково ваше понимание колоночной организации данных и как это соотносится с Greenplum и ClickHouse?
Оба могут работать колоночно (ClickHouse изначально, Greenplum через AO/CO-таблицы). Колоночное хранение отлично для аналитических нагрузок и больших объёмов.
29
Доводилось ли вам переписывать SQL-запросы под синтаксис ClickHouse?
Да, приходилось адаптировать PostgreSQL-запросы: заменять оконные функции и CTE на более простые подходы, либо использовать функции ClickHouse (uniqExact, arrayJoin), также учитывал другие типы дат.
30
Работали ли вы с Greenplum?
Да, в ЮMoney Greenplum стал центральной MPP-СУБД для корпоративного DWH по Data Vault 2.0, где я занимался загрузками и оптимизацией запросов.
31
Был ли у вас опыт миграции на Greenplum?
Да, переносили данные из ClickHouse и PostgreSQL, настроили Data Vault, распределяя хабы и сателлиты по сегментам. Я участвовал в планировании, написании Airflow DAG-ов и SQL-скриптов.
32
Приходилось ли вам сравнивать Greenplum с Snowflake и Amazon S3?
Детального POC со Snowflake не делал, но S3 мы использовали как промежуточное или архивное хранилище, тогда как Greenplum выступал полноценной аналитической MPP-платформой.
33
Приходилось ли вам переписывать SQL-запросы для Greenplum с другой СУБД (например, Snowflake)?
Со Snowflake нет, но из ClickHouse и PostgreSQL да: заменял специфичные функции, учитывал особенности MPP, следил за дистрибуцией таблиц.
34
Сталкивались ли вы с необходимостью переписывать SQL-запросы для Greenplum из других диалектов SQL?
Да, например, в ClickHouse есть uniqExact, в Greenplum я заменял это на COUNT(DISTINCT), а оконные функции из PostgreSQL мог работать иначе с точки зрения распределения.
35
Какие были сложности при изучении или использовании Greenplum?
Нужно чётко понимать MPP-архитектуру, грамотно задавать дистрибуционные ключи, чтобы избежать больших motion, и уметь читать планы EXPLAIN для оптимизации.
36
Какова была ваша зона ответственности при работе с Greenplum?
Проектирование таблиц Raw/Business Vault, написание ETL/ELT-пайплайнов (Airflow), оптимизация тяжёлых запросов, настройка партиционирования и дистрибуции.
37
С какими проблемами вы сталкивались при работе с Greenplum в облаке (например, в Yandex Cloud)?
У нас был собственный кластер, но похожие проблемы — сетевые задержки, ограничение памяти сегментов, при больших загрузках приходилось дробить данные по дням.
38
Сталкивались ли вы с ситуацией, когда данные не помещались в Greenplum, и как вы это решали?
Да, при миграции крупной таблицы из ClickHouse разбивали выгрузку по датам, загружали порциями, освобождали старые партиции в случае неактуальных данных.
39
Из каких источников вы загружали данные в Greenplum?
Из ClickHouse, PostgreSQL (Debezium или batch-дампы), внешних рекламных API (через Python + Airflow), также частично из S3 (CSV/Parquet).
40
Занимались ли вы загрузкой данных в Greenplum?
Да, писал Airflow DAG, который скачивал файлы (TSV/CSV), проверял структуру, применял COPY/INSERT в нужные таблицы, иногда используя gpfdist.
41
Работали ли вы с витринами данных, построенными на Greenplum?
Да, в Business Vault формировали итоговые сателлиты, а затем Data Marts, куда BI-команда подключалась. Я помогал писать SQL-транформации и настроил партиционирование для фактов.
42
Имеете ли вы опыт работы с Greenplum для Data Vault?
Да, весь корпоративный DWH в ЮMoney строился на Data Vault 2.0 в Greenplum, я создавал хабы, линки и сателлиты, писал логику версионности.
43
Использовали ли вы DBT для работы с Greenplum?
Нет, мы остались на классических SQL-скриптах и Airflow, DBT не внедряли.
44
Знаете ли вы о проекте GreenGage и его связи с Greenplum?
Нет, в моих проектах не применялся, работали со стандартным Greenplum-дистрибутивом.
45
С чего вы начинаете оптимизацию запросов в Greenplum?
С EXPLAIN/EXPLAIN ANALYZE, проверяю наличие Redistribute/Broadcast Motion, смотрю план, анализирую, не нужно ли поменять дистрибуцию.
46
Как вы подходите к оптимизации SQL-запросов в Greenplum, если запрос медленный?
Смотрю EXPLAIN, избавляюсь от лишних DISTINCT, делаю правильную дистрибуцию, если нужно — разбиваю запрос на подшаги (CTE/временные таблицы).
47
Какие методы оптимизации запросов вы знаете?
Партиционирование больших таблиц, выбор ключей дистрибуции, замена DISTINCT на GROUP BY, локальные джойны (совпадающие дистрибуции), рефакторинг слишком сложных подзапросов.
48
Какие особенности Greenplum вы учитываете при оптимизации запросов?
Это MPP, каждая операция может тянуть данные между сегментами, нужно грамотно проектировать схему, чтобы минимизировать shuffle.
49
Что вы будете делать, если длинный запрос в Greenplum работает медленно?
Выполню EXPLAIN ANALYZE, определю узкое место (motion, join), перепишу запрос, поменяю дистрибуцию таблиц, возможно добавлю партиционирование или разобью логику на шаги.
50
Знаете ли вы про EXPLAIN и EXPLAIN ANALYZE для анализа выполнения запросов?
Да, это ключевой инструмент: смотрю, какие операции самые затратные, нет ли broadcast на большую таблицу, какая оценка времён.
51
Как вы избавляетесь от BROADCAST JOIN, MOTION, REDISTRIBUTION MOTION при оптимизации в Greenplum?
Настраиваю одинаковые дистрибуционные ключи, иногда реплицирую маленькие справочники, заменяю DISTINCT на GROUP BY, чтобы не гонять все данные по сегментам.
52
Использовали ли вы DISTINCT или GROUP BY для дедупликации данных в Greenplum? Почему?
Предпочитаю GROUP BY, так как оптимизатор MPP лучше распараллеливает группировку, а DISTINCT часто сводит все данные в один узел.
53
Почему в Greenplum рекомендуется использовать GROUP BY вместо DISTINCT для оптимизации?
DISTINCT может работать как global unique, что вызывает полный shuffle, а GROUP BY можно обработать сегментарно.
54
Приходилось ли вам настраивать партиционирование в Greenplum? Для чего это нужно?
Да, например, партиционировал таблицы фактов по датам, чтобы ограничивать сканирование только нужными партициями при запросах за конкретные периоды.
55
Какие стратегии распределения данных (дистрибуции) существуют в Greenplum?
Hash Distribution по полю, Random Distribution, Репликация (для маленьких таблиц), Master-only для крохотных служебных данных.
56
Зачем нужно распределять данные по колонкам и использовать дистрибутор в Greenplum?
Чтобы равномерно загружать сегменты и избегать «узких горлышек» при JOIN, а также уменьшать объём пересылок (motion).
57
Какие стратегии распределения данных вы знаете, применительно к таким системам, как Greenplum?
Hash distribution по JOIN-ключу, random distribution, реплицированная таблица (small reference) — в зависимости от размерности и сценариев JOIN.
58
Каково ваше понимание колоночной организации данных и как это соотносится с Greenplum и ClickHouse?
Оба позволяют колоночное хранение (ClickHouse изначально, Greenplum через AO/CO). Это даёт преимущества при аналитических запросах, где считывают множество строк, но не все столбцы.
59
Использовались ли Greenplum-специфические функции?
Да, gpfdist для загрузки, функции по работе с внешними таблицами. Также пользовался EXPLAIN (ANALYZE, DIST) для подробной информации о распределении.
60
Использовался ли PostgreSQL в качестве источника данных в ваших проектах?
Да, в ББР Банке и ЮMoney много микросервисов хранились в PostgreSQL, откуда мы потом тянули данные в DWH.
61
Каким образом вы подключались к PostgreSQL для получения данных?
В Airflow через PostgresHook, Python-скрипты (psycopg2), Debezium (Kafka Connect) для CDC, вручную через psql, когда нужно.
62
Использовали ли вы Debezium для отслеживания изменений в PostgreSQL?
Да, в ЮMoney, где мы подключались к WAL, Debezium формировал JSON-события (before/after), отправлял в Kafka, а дальше в Greenplum для near real-time.
63
С какими типами данных PostgreSQL вам приходилось работать?
Numeric/Decimal для денег, text/varchar для строк, timestamp, иногда JSONB для гибких полей у микросервисов (настройки пользователей).
64
Приходилось ли вам создавать таблицы в PostgreSQL?
Да, для рекламных сервисов в ЮMoney, создавал схему ads_reporting, таблицы ad_campaigns, ad_platforms, которые наполнялись через ETL-скрипты.
65
Выполняли ли вы SQL-запросы к PostgreSQL? Какие типы запросов (простые, сложные, с подзапросами, JOIN, оконные функции, оптимизация)?
Да, делал и простые SELECT, и сложные оконные функции, писал JOIN по нескольким таблицам. При необходимости оптимизировал, смотрел план выполнения.
66
Приходилось ли вам оптимизировать SQL-запросы для PostgreSQL?
Да, убирал лишние подзапросы, добавлял индексы по полям, которые часто используем в WHERE. Иногда менял структуру хранения, если запросы тормозили.
67
Использовались ли индексы в PostgreSQL в ваших проектах? Кластеризованные и некластеризованные?
Да, в основном B-Tree индексы на столбцы, по которым шли частые фильтры/сортировки, реже делал кластеризацию под конкретные запросы.
68
В каких случаях целесообразно использовать индексы в PostgreSQL?
Когда у нас часто повторяющиеся выборки по определённому столбцу, либо частые JOIN по ключу, и объёмы уже достаточно велики, чтобы full scan стал тормозом.
69
Работали ли вы с партиционированием таблиц в PostgreSQL?
В промышленном формате редко, чаще мы делали это в Greenplum, но знаю, что PostgreSQL поддерживает декларативное партиционирование по дате или другим полям.
70
Использовался ли PostgreSQL для хранения временных рядов (временных данных)?
Серьёзные временные ряды мы уносили в ClickHouse или Greenplum. PostgreSQL мог хранить небольшие исторические записи, но не как полноценное time-series решение.
71
Приходилось ли вам мигрировать данные из PostgreSQL в другие СУБД?
Да, в ЮMoney выгружали микросервисные таблицы (включая billing, transactions) в Greenplum через Debezium для near real-time, либо batch (Airflow SELECT + COPY).
72
Использовался ли PostgreSQL для создания витрин данных?
Нет, обычно витрины держали в DWH на Oracle (в ББР) или Greenplum (в ЮMoney), PostgreSQL — это больше OLTP/микросервисы.
73
Как вы оцениваете свой уровень владения SQL при работе с PostgreSQL?
Уверенный уровень: JOIN-ы, оконные функции, оптимизация, индексы — всё это делал регулярно.
74
Сравнивали ли вы PostgreSQL с другими базами данных, например, ClickHouse или Greenplum? В чем их отличия с вашей точки зрения?
PostgreSQL — универсальная реляционная СУБД для OLTP; ClickHouse и Greenplum — колоночные/MPP решения для масштабной аналитики.
75
Использовался ли PostgreSQL в связке с другими инструментами, такими как Kafka, Airflow, Python?
Да, Kafka + Debezium для CDC, Airflow PythonOperators (psycopg2) для batch-загрузок, всё активно применялось.
76
Приходилось ли вам настраивать мониторинг для PostgreSQL?
Глубоко нет, DevOps это делали. Я смотрел логи и pg_stat_activity при troubleshoot, при необходимости добавляли индексы.
77
Выгружали ли вы данные из PostgreSQL в S3?
Да, писали Python-скрипты (psycopg2 → pandas → CSV → boto3 upload), либо делали pg_dump → S3, чтобы использовать далее в Greenplum.
78
Использовался ли PostgreSQL в операционной деятельности или для аналитики?
В основном операционная (микросервисная) деятельность, хотя простую аналитику тоже иногда делали в рамках небольших запросов.
79
Сталкивались ли вы с ограничениями PostgreSQL при работе с большими объемами данных?
Да, при сотнях миллионов строк запросы заметно замедлялись, поэтому часть аналитики выносили в Greenplum/ClickHouse.
80
Каким образом журнал транзакций (WAL) в PostgreSQL использовался в ваших проектах (например, с Debezium)?
Debezium читал WAL (logical decoding), формируя события before/after, которые мы отправляли в Kafka для CDC.
81
Использовался ли PostgreSQL как промежуточное хранилище данных?
Иногда да, для временных таблиц при интеграции, но основное DWH всё равно было Oracle/Greenplum.
82
Работали ли вы с резервным копированием и восстановлением в PostgreSQL?
Администрированием занимался DevOps, но я знал, что pg_dump/pg_restore или физические бэкапы позволяют вернуть базу к нужному состоянию.
83
Настраивали ли вы коннекторы Debezium для PostgreSQL?
Да, создавал replication slot, прописывал конфиг (host, table.include.list), Debezium как Kafka Connect plugin, чтобы вылавливать изменения в реальном времени.
84
Использовался ли PostgreSQL в облачной среде?
Да, часть сервисов в ЮMoney жила в Yandex Cloud, но логика подключения и загрузки была той же.
85
Приходилось ли вам администрировать инстансы PostgreSQL (например, разворачивать, настраивать)?
Глубоко нет, конфиги и бэкапы делал DevOps, я лишь создавал схемы, таблицы, индексы под нужды ETL.
86
Работали ли вы с репликацией в PostgreSQL?
Да, logical replication через Debezium, physical replication на слейвы занимались DevOps.
87
Как вы обеспечивали стабильность работы коннекторов при использовании PostgreSQL как источника?
Следили за lag в Debezium, если коннектор падал, Airflow присылал алерты; могли вручную перезапустить слот. Ставили ретраи в случае временных сбоев.
88
Используется ли в вашей практике Hadoop для аналитики?
Да, в ББР Банке мы имели Hadoop-кластер, применяли Hive для SQL-доступа к логам, Spark (PySpark) для парсинга JSON, HDFS как data lake.
89
Каким образом аналитики получали доступ к данным в Hadoop? (например, DBU, JupyterHub)
Чаще всего через Hive (HiveQL) или Spark (spark-submit). Некоторым давали Zeppelin/Jupyter для интерактивной аналитики, но основа — Hive + SQL.
90
Имеете ли вы опыт работы с Hive в Hadoop?
Да, создавал внешние таблицы (EXTERNAL TABLE), прописывал схемы для JSON/CSV, чтобы аналитики могли запросить файлы из HDFS как обычную таблицу.
91
Что такое Hive Metastore?
Это сервис/база, где хранятся метаданные Hive: схемы, таблицы, типы, пути в HDFS, позволяющие интерпретировать файлы как реляционные таблицы.
92
Приходилось ли вам работать с уже предобработанными данными в Hadoop?
Да, Spark job иногда формировал Parquet-файлы, которые уже были очищены, и потом другие аналитики через Hive или Spark повторно обрабатывали эти Parquet.
93
Сталкивались ли вы с задачами MapReduce в Hadoop?
Напрямую писал MapReduce редко, мы преимущественно пользовались Spark, но теоретически знал о MapReduce, Yarn, работе shuffle.
94
За что отвечает MapReduce в архитектуре Hadoop?
Это базовый фреймворк распределённой обработки (Map -> Shuffle -> Reduce), над которым позже появился Spark как более быстрый вариант in-memory вычислений.
95
Какие вычисления может производить Hadoop (помимо Hive и Spark)?
Есть Pig, HBase, Flink, но в моём опыте основные вещи были Spark, Hive.
96
Что вы знаете о Yarn и его роли в Hadoop?
Yarn — диспетчер ресурсов кластера, распределяет CPU/память между job-ами (Spark, MapReduce) и отслеживает их выполнение.
97
За что отвечает Yarn и какие у него задачи?
Меняет стадии выполнения, выдаёт контейнеры под задачи, управляет очередями, балансирует нагрузку.
98
В чём ключевые отличия MapReduce от других технологий обработки больших данных, таких как Spark?
MapReduce каждый раз пишет результаты на диск, Spark обрабатывает данные в памяти (RDD, DataFrame), что ускоряет итеративные задачи.
99
Использовали ли вы Hadoop File System (HDFS) в своих проектах?
Да, в ББР Банке мы складывали туда логи мобильных и веб-приложений, JSON, CSV для дальнейшей обработки в Hive/Spark.
100
Из каких частей состоит HDFS?
NameNode (метаданные, управление), DataNode (хранение блоков), SecondaryNameNode (резерв метаданных), клиентские библиотеки, чтобы обращаться к системе.
101
За что отвечает NameNode в HDFS?
Хранит структуру файлов и блоков, отслеживает где какие блоки лежат на DataNode, обрабатывает операции (создание, удаление, перемещение).
102
С какими типами файлов вы работали в HDFS (помимо CSV)?
JSON, Parquet, текстовые логи. Parquet активно применяли в Spark для колоночного хранения и лучшей сжатости.
103
Работали ли вы с платформами, построенными на базе Hadoop, такими как Arena Data Hadoop (DApp)?
Нет, использовали vanilla Hadoop-дистрибутив с нужными компонентами (Hive, Spark).
104
Использовался ли Hadoop для хранения больших объёмов данных в вашем опыте?
Да, логи и системные события достигали сотен гигабайт. Мы партиционировали их по дате, чтобы управлять хранением.
105
Сравнивали ли вы Hadoop с другими системами хранения и обработки данных для аналитики?
Да, Hadoop подходит для полуструктурированных данных и больших batch job, тогда как MPP-базы (Greenplum, ClickHouse) больше про structured аналитические запросы.
106
Расскажите три основных компонента Apache Hadoop.
HDFS (хранилище), Yarn (диспетчер ресурсов), MapReduce (базовый механизм распределённой обработки).
107
Знаете ли вы, зачем нужно распределять колонки и учитывать их порядок (например, ключи для объединения) при работе с распределёнными системами, такими как Hadoop или Greenplum?
Чтобы сократить пересылку данных между узлами, уменьшить shuffle, упростить локальные JOIN.
108
Зачем в Greenplum (и аналогично в Hadoop) используется дистрибутив random?
Если нет ключа для hash-distribution, random позволяет равномерно раскидать данные по узлам, избегая перекосов.
109
Сравнивали ли вы Amazon S3 с другими решениями для хранения данных, такими как Snowflake и Greenplum?
Прямо не сравнивал со Snowflake, но S3 часто использовали как объектное хранилище/landing zone, а Greenplum — как основную MPP-СУБД.
110
Какие факторы могут влиять на выбор Amazon S3 в качестве хранилища данных?
Стоимость, масштабируемость, простота интеграции, требования к доступности, форматы файлов (CSV/Parquet), а также частота обращений.
111
Как оценивается скорость чтения данных из Amazon S3 по сравнению с другими хранилищами?
Обычно медленнее, чем локальное или MPP-хранилище, но для batch-выгрузок приемлемо, позволяет гибко масштабировать объёмы.
112
В каких ситуациях может возникнуть необходимость переноса данных в Amazon S3?
Когда нужно долговременное дешёвое хранение больших объёмов (архив логов), перенос промежуточных результатов между системами, интеграция с облачными сервисами.
113
Был ли у вас опыт использования Amazon S3 в связке со Snowflake?
Нет, Snowflake мы не применяли, но S3 часто служил landing для Greenplum и Spark.
114
Приходилось ли вам загружать данные из Amazon S3 в другие базы данных, например, Greenplum?
Да, через Python-скрипты (boto3) + Airflow, дальше копировали файлы и делали COPY в Greenplum.
115
Использовался ли Amazon S3 в ваших проектах для хранения данных, которые затем обрабатывались с помощью Spark?
Да, Spark мог забирать файлы из S3, если локальный HDFS был перегружен или если нужно было хранить «холодные» данные в облаке.
116
Выгружали ли вы данные из каких-либо баз данных (например, PostgreSQL) в Amazon S3?
Да, делали pg_dump → S3 для бэкапов, а также CSV-выгрузки из PostgreSQL через Python.
117
Использовали ли вы Amazon S3 как промежуточное хранилище данных в ваших ETL/ELT процессах?
Да, часто: сохраняли там сырые CSV/Parquet, потом Airflow DAG-ом подгружали в нужное DWH.
118
Приходилось ли вам настраивать процессы для работы с файлами, хранящимися в Amazon S3?
Да, писал PythonOperators в Airflow, которые проверяли наличие файла, скачивали, конвертировали, затем загружали в DWH.
119
Использовался ли Amazon S3 для хранения "сырых" данных перед их обработкой и загрузкой в хранилище?
Да, это классический сценарий: «Raw Zone» в S3, после проверки и преобразования — загрузка в Greenplum.
120
Работали ли вы когда-нибудь с Data Vault?
Да, в ЮMoney мы строили корпоративное хранилище по Data Vault 2.0 в Greenplum.
121
Что вам известно о Data Vault?
Это методология моделирования: Hub (бизнес-сущность), Link (связь), Satellite (атрибуты и история), позволяющая гибко расширять хранилище и хранить полную версионность.
122
Какие основные компоненты Data Vault вы знаете (например, хабы, ссылки, сателлиты)?
Hub, Link, Satellite; Hub хранит бизнес-ключи, Link — связи между хабами, Satellite — детальные поля с историей изменений.
123
Расскажите о структуре Data Vault (что такое хабы, сателлиты, линки и их назначение).
Hub — ядро сущности (клиент, продукт), Link — соединяет несколько хабов (клиент-продукт), Satellite содержит атрибуты и временные метки, что позволяет версионировать данные.
124
Сколько полей должно быть в хабах Data Vault?
Обычно суррогатный ключ (HashKey), бизнес-ключ (BusinessKey), LoadDate, RecordSource — то есть минимум 4 поля.
125
Что в Data Vault делится на хабы, линки и сателлиты?
Бизнес-сущности (хабы), отношения (линки) и детальные атрибуты с историей (сателлиты).
126
В курсе ли вы, что многие компании сейчас хотят перейти на Data Vault?
Да, это популярный подход к историзации и масштабированию DWH, я видел много запросов и у нас в ЮMoney это доказало гибкость.
127
Связаны ли текущие задачи компании с Data Vault?
В ЮMoney на тот момент — да, мы переходили с плоских таблиц/ClickHouse на DV2.0 в Greenplum.
128
В каком проекте в вашей компании используется методология Data Vault?
В ЮMoney корпоративный DWH выстраивался именно по DV2.0, охватывая все ключевые бизнес-процессы (транзакции, клиенты, рекламные кампании).
129
Приходилось ли вам работать с Greenplum для Data Vault?
Да, создавал структуры Raw/Business Vault, прописывал логику загрузки, оптимизировал запросы на Hub/Link/Satellite.
130
Каково ваше понимание Data Vault?
Это гибкая схема хранения, где данные разбиваются на сущности и связи, а все изменения версионируются в сателлитах. Легко расширять новые источники, не ломая старую модель.
131
Используется ли Data Vault в вашем текущем или предыдущем проекте?
В предыдущем (ЮMoney) — да, после ухода я не сталкивался с новыми проектами, где DV уже внедрён.
132
Приходилось ли вам работать с денормализованными структурами данных или "широкими" таблицами (One Big Table)?
Да, иногда делал OBT при быстром прототипировании: брали Excel + Oracle + CSV, склеивали в одну «широкую» таблицу для оперативного анализа.
133
В каких ситуациях, по вашему мнению, целесообразно использовать OBT вместо более сложных моделей?
Если проект небольшой, структура редко меняется, нужно быстро получить результат без сложных JOIN.
134
В каких типах задач или проектов методология One Big Table может быть наиболее эффективной?
В пилотных, разовых аналитических исследованиях или маленьких самописных отчётах, где нет комплексных исторических изменений.
135
Приходилось ли вам работать с проектами, где использовалась OBT? Какие задачи вы решали?
В ББР Банке для срочных сводок: брали данные из нескольких CSV, формировали «широкую» сводную таблицу, чтобы сделать BI-дашборд без полноценного DWH.
136
Сталкивались ли вы с необходимостью усложнять модель данных, которая изначально была построена по принципу OBT? Каковы были причины и как вы это делали?
Да, когда данные росли и появились требования к истории, пришлось переводить в Data Vault/звёздную схему, чтобы избежать дублирования и медленных JOIN.
137
Принимали ли вы участие в архитектурных решениях по выбору между OBT и другими подходами? Какие аргументы были за и против?
Да, OBT «за» — быстро стартовать, «против» — плохо масштабируется, трудно хранить историю, большие таблицы тормозят. Data Vault или классическая Kimball-схема гибче в долгосрочной перспективе.
138
Какие преимущества и недостатки у подхода One Big Table?
Преимущества — простота, скорость реализации. Недостатки — громоздкость при росте данных, проблемы с версионностью, потенциальное дублирование полей.
139
Какие проблемы могут возникнуть при работе с очень большими денормализованными таблицами?
Тормозные запросы (full scan), колоссальное дублирование данных, сложность внесения изменений.
140
Как OBT влияет на производительность запросов?
При больших объёмах запросы могут стать крайне медленными, так как всё лежит в одной таблице без нормализации.
141
Как хранение данных в OBT влияет на объем хранилища?
Увеличивается, так как данные часто дублируются по многим полям, которые при нормализации выносили бы в отдельные измерения.
142
Как можно обеспечить качество данных и производительность запросов в системе, построенной на OBT?
Строго контролировать формат входных данных, партиционировать, добавлять индексы (где возможно), но это всё временные меры, лучше переходить к более структурированной модели.
143
Сравнивали ли вы когда-нибудь One Big Table с Data Vault или другими методологиями? В чем их основные различия?
OBT упрощает старт, но плохо масштабируется; Data Vault позволяет историзировать и добавлять источники без «сноса» схем.
144
Какие преимущества и недостатки у OBT по сравнению с другими методологиями моделирования данных (например, Data Vault)?
Преимущество — быстрая разработка. Недостаток — трудное расширение, нет нормальной историзации, высокая избыточность.
145
Сталкивались ли вы с необходимостью оптимизировать затраты на хранение данных, учитывая различные требования к доступности и производительности?
Да, в ББР Банке часть логов уносили в Hadoop/HDFS, чтобы не держать всё в дорогом Oracle, а в ЮMoney — старые данные иногда выгружали в S3.
146
Имеете ли вы представление о том, что такое гибридное хранилище данных?
Да, это когда часть «горячих» данных лежит в быстром DWH (Greenplum/ClickHouse), а «холодные» — в дешёвом хранилище (HDFS/S3), чтобы балансировать стоимость и доступность.
147
Какие подходы или технологии могут использоваться для реализации гибридного хранения данных?
Могут быть многоуровневые пайплайны (Airflow), где данные, не используемые регулярно, переносятся из DWH в S3/HDFS, а при необходимости загружаются обратно.
148
В каких сценариях вы считаете целесообразным использовать гибридное хранение данных?
При огромных исторических объёмах, которые редко запрашиваются, когда невыгодно держать всё в дорогой MPP, но нужно иметь опцию вернуть данные при необходимости.
149
Какие факторы следует учитывать при проектировании системы гибридного хранения данных?
Частота запросов, SLA на доступ, стоимость хранения, сложность управления данными (метаданные, граничные кейсы).
150
Приходилось ли вам переносить данные между различными уровнями хранения (например, с быстрого на более дешевое) в зависимости от их актуальности или частоты использования?
Да, логи за 1+ год уносили в HDFS/S3, а актуальные оставляли в Greenplum/ClickHouse.
151
Как бы вы обеспечили баланс между стоимостью хранения и производительностью доступа к данным при использовании гибридного подхода?
Анализирую, какие данные часто нужны в отчётах (держу в DWH), а что редко запрашивается (выношу в «холод»), и даю механизм быстрой догрузки при необходимости исторического анализа.
152
Какие инструменты или технологии могут помочь в управлении гибридным хранилищем данных?
Airflow/Workflow для перемещения, Hive Metastore/S3 Catalog, MPP DWH (Greenplum), Spark для чтения с S3, плюс система метаданных и политики «охлаждения».
153
Был ли у вас опыт охлаждения данных с использованием гибридного хранилища?
Да, в ББР Банке часть старых логов переносили в HDFS, а в ЮMoney — в S3, снижая нагрузку на основное DWH.
154
Приходилось ли вам охлаждать данные, используя гибридное хранилище, при этом практически не теряя скорость чтения самих данных?
Полностью без потери скорости не обходилось, но для редко запрашиваемых данных это было оправдано, и при грамотной системе кэширования/предзагрузки потери минимизировались.
155
Сталкивались ли вы с работой с данными в формате JSON?
Да, в ББР Банке логи REST, в ЮMoney — рекламные API, микросервисы. Приходилось парсить, валидировать, грузить в DWH.
156
Приходилось ли вам использовать JSON для описания схем данных (например, в Avro)?
Avro не использовал, чаще работал с «чистым» JSON, хотя в Spark/Hive можно было подключить Avro, но у нас не было постоянного Avro-проекта.
157
Как вы обрабатывали JSON-данные из различных источников (например, из Kafka)?
Python-скрипты (json.loads), Spark (read.json), Debezium (Kafka) давал before/after поля JSON, я писал потребители, которые разбирали нужные ключи.
158
Использовали ли вы библиотеки или инструменты для работы с JSON в Python или других языках программирования?
Да, стандартный json в Python, requests для REST, иногда pandas для быстрой обработки.
159
Встречались ли вам задачи, связанные с преобразованием JSON-данных или валидацией их структуры?
Да, когда из внешних рекламных API приходили разные форматы. Делал проверку ключей, типов (дата, число), логгировал ошибки в отдельный CSV.
160
Как вы обеспечивали консистентность схем данных при работе с JSON?
Документировал ожидаемый формат, при загрузке делал валидацию (если нет ключа/тип не совпадает — пишу в лог ошибок), следил за версиями API.
161
Приходилось ли вам хранить JSON-данные в базах данных (например, в PostgreSQL)?
Да, в ЮMoney микросервисы иногда писали JSONB. При вытягивании в DWH я старался распаковать структуру по столбцам.
162
Как вы работали с вложенными JSON-структурами?
В Python иногда рекурсивно обходил, в Spark использовал explode при сложных массивных структурах. Старался нормализовать по мере возможностей.
163
Обсуждались ли на ваших проектах подходы к управлению изменениями в JSON-схемах?
Да, особенно когда API менялось, добавляли поле version, делали backward-совместимость, чтобы не ломать парсеры.
164
Как вы документировали JSON-схемы данных?
В Confluence описывал ключи, типы, примеры JSON, обязывал коллег следить за обновлениями при релизах.
165
Как физическое проектирование схемы данных (например, индексация, партиционирование) влияет на производительность запросов в OLTP и OLAP системах?
Сильно влияет, особенно при JSONB в PostgreSQL стоит делать GIN-индексы на ключевые поля, для OLAP лучше распаковать JSON в таблицы.
166
Сталкивались ли вы с необходимостью отслеживать историю изменений данных?
Да, классические SCD2 в Oracle DWH, а также Data Vault (хранение атрибутов в сателлитах).
167
Знакомы ли вы с подходом Slowly Changing Dimensions Type 2 (SCD2)?
Да, при обновлении записываем новую строку с актуальным значением, старую помечаем end_date или флагом, что она неактивна.
168
Как вы понимаете принцип работы SCD2?
Каждый раз при изменении измерения создаём новую версию, сохраняя историю — так можно в отчётах восстанавливать состояние на любую дату.
169
Приходилось ли вам реализовывать SCD2 в ваших проектах?
Да, в ББР Банке, где DWH построен по Кимбаллу, в таблицах измерений мы вели effective_start, effective_end, is_current.
170
Расскажите, как вы реализовывали отслеживание изменений в данных (например, используя флаги активности, даты начала и окончания записи).
Сравнивал поля входных данных с текущей версией, если менялись — «закрывал» старую (end_date=...), создавал новую (start_date=now), ставил active=1, а старой — active=0.
171
Как вы обрабатывали в ETL-процессе поступление обновлений для измерения типа SCD2?
В Informatica/Airflow делал lookup текущей записи, если поля отличались — менял end_date старой, вставлял новую.
172
Какие поля обычно используются для реализации SCD2? (Например, суррогатный ключ, естественный ключ, поля со значениями, флаг активности, дата начала, дата окончания).
Суррогатный ключ (dim_id), natural key (client_id), start_date, end_date, active_flag, набор атрибутов (name, address), load_dttm/record_source.
173
Какие могут быть преимущества и недостатки использования SCD2?
Плюс — полная история изменений, минус — рост объёма данных, усложнение запросов, нужно аккуратно поддерживать корректность end_date.
174
В каких случаях вы считаете целесообразным использовать SCD2?
Когда бизнесу важна историческая прослеживаемость (например, адрес клиента менялся, нужно видеть, какой был при оформлении кредита).
175
Как вы организовывали запросы к данным, чтобы получить как текущую, так и историческую информацию из SCD2-измерения?
Для актуальной версии фильтровал is_current=1, для истории JOIN по дате факта (between start_date and end_date) или по active_flag, если нужна конкретная временная точка.
176
Оцените ваш уровень владения Apache Airflow (полное соответствие, частичное соответствие, отсутствие навыков)?
Полное соответствие, я вёл проекты по миграции с Informatica и активно писал DAG-лопаты в ЮMoney.
177
Был ли у вас опыт работы с Airflow?
Да, большой: настройка, написание операторов, CI/CD, мониторинг. Переводил десятки ETL-процессов из Informatica в Airflow в ББР Банке.
178
Используется ли в вашей компании Airflow?
Да, в обеих (ББР Банк и ЮMoney) Airflow стал основным оркестратором ETL/ELT.
179
Вы считаете Airflow ETL-системой или скорее инструментом для шедулинга?
Это скорее оркестратор (scheduler), но мы используем его как ETL, так как много логики пишется в PythonOperators.
180
Опишите, как вы использовали Python в связке с Airflow?
В основном PythonOperator для вызова скриптов (парсинг CSV, вызов API, Debezium-обработка), плюс иногда BashOperator для более простых shell-команд.
181
Расскажите о вашем опыте написания DAG-ов в Airflow.
Переносил маппинги из Informatica: разбивал логику на шаги (extract, transform, load), настраивал зависимости (>>), расписание (cron), ретраи, оповещения. В ЮMoney делал DAG для сбора рекламных метрик (Google Ads, Яндекс.Директ) и загрузки их в Greenplum.
182
Каким образом вы тестировали код, который запускался в Airflow?
Локальные юнит-тесты (pytest) для Python-функций, airflow test для пробного запуска, а также dev-стенд, где прогоняли DAG целиком.
183
Расскажите своими словами, что такое фикстура в контексте pytest (инструмента, упомянутого рядом с Airflow)?
Фикстура — это способ передавать подготовленные объекты и окружение в тесты, чтобы не дублировать setup/teardown-код.
184
Использовали ли вы на практике механизм фикстур при тестировании в Airflow?
Да, когда тестировал Python-скрипты (парсер CSV) отдельно, фикстуры создавали временные файлы, имитировали окружение.
185
Расскажите о вашем опыте настройки DAG-ов в Airflow.
На уровне default_args указывал owner, retries, retry_delay, email_on_failure, schedule_interval (cron или @daily). Прописывал зависимости (task1 >> task2). Часто хранил конфиги в Variables, Connections.
186
Что вы знаете о параметрах, отвечающих за поведение задач после их выполнения или падения в Airflow?
depends_on_past, retries, retry_delay, email_on_failure, on_failure_callback — настраивал их для критических DAG-ов, чтобы автоматически перезапускать при сбоях.
187
Сталкивались ли вы с необходимостью переноса задач из других систем оркестрации (например, TeamCity) в Airflow?
Из TeamCity нет, но из Informatica — да. Приходилось вручную пересобрать логику трансформаций, расписание и ретраи.
188
Знаете ли вы, как распределяются задачи для выполнения в кластере Airflow?
Да, Airflow-сcheduler кладёт задачи в очередь, воркеры (CeleryExecutor, LocalExecutor) берут задачи, учитывая настройки pools и concurrency.
189
Расскажите о вашем опыте использования различных операторов Airflow (например, PythonOperator).
PythonOperator, BashOperator, EmailOperator, Sensors (FileSensor), ExternalTaskSensor. Иногда писал кастомные операторы (S3->DB загрузка).
190
Сталкивались ли вы с задачами, где требовалось настроить зависимости между задачами (tasks) в Airflow?
Конечно, многие DAG-ы были цепочками: сначала extract, потом transform, потом load, плюс синхронизация с ExternalTaskSensor.
191
Расскажите о вашем опыте мониторинга пайплайнов данных, запущенных в Airflow.
Глядел в UI (Gantt, Graph view), настраивал Slack/email-алерты, в случае падения задачи смотрел логи, при необходимости ручной перезапуск.
192
Участвовали ли вы в настройке CI/CD процессов для Airflow DAG-ов?
Да, держали DAG-и в Git, при пуше автотест на синтаксис, деплой на dev-стенд, затем после проверки — на prod, используя Jenkins/GitLab CI.
193
Как вы решали проблемы с техническим долгом в проектах, использующих Airflow?
Делали «рефакторинг-спринты», объединяли дублирующие скрипты в модули, выпиливали legacy-процессы, писали документацию в Confluence, чтобы упростить поддержку.
194
Сталкивались ли вы с необходимостью оптимизации DAG-ов в Airflow (например, для экономии ресурсов)?
Да, ограничивал concurrency, разбивал очень тяжёлые DAG на несколько, чтобы не перегружать воркеры, создавал пулы для ресурсоёмких задач.
195
Использовали ли вы Airflow для пакетной обработки данных?
Да, почти все кейсы были batch: загрузка CSV, запросы к API, преобразования и далее запись в DWH.
196
Приходилось ли вам использовать e-mail операторы в Airflow для оповещений?
Да, EmailOperator для важных ETL. При падении задачи Airflow шлёт письмо на указанный адрес.
197
Как вы настраивали расписание выполнения DAG-ов в Airflow?
Через параметр schedule_interval (cron или @daily/@hourly). Например, 0 7 * * * для ежедневного запуска в 7 утра.
198
Опишите ваш опыт работы с переменными в Airflow.
Использовал Airflow Variables для хранения путей, логинов, конфигов окружения, получал их через Variable.get("key").
199
Знакомы ли вы с концепцией XComs в Airflow?
Да, для передачи небольших данных между задачами в одном DAG. Но стараюсь не злоупотреблять XCom объёмными данными.
200
Сталкивались ли вы с необходимостью интеграции Airflow с другими сервисами?
Да, Slack-нотификации, Debezium/Kafka, REST API внешних систем, S3 и Hive hooks, Spark-submit оператор.
201
Расскажите о вашем опыте работы с сенсорами в Airflow. Какие вы писали сеносры?
FileSensor (ждёт появления файла), ExternalTaskSensor (ждёт завершения другого DAG). Это помогало синхронизировать процессы, зависящие от внешних условий.
202
Как вы обеспечивали стабильность и надежность пайплайнов, оркестрируемых с помощью Airflow?
Настраивал ретраи, оповещения, чётко прописывал зависимости. В прод-среде мы делали разделение DAG-ов, чтобы сбой одного не «калечил» весь Airflow.
203
Опишите ваш подход к обработке ошибок в Airflow DAG-ах.
При падении задача уходит в retry (если настроен). Если все ретраи исчерпаны — алерт в Slack/Email. Если причина — временный сбой, вручную перезапускал, иначе разбирал лог, правил код.
204
Знакомы ли вы с REST API Airflow?
Знаю, что есть API для управления DAG-ами и тасками, но в основном хватало CLI и UI.
205
Сталкивались ли вы с необходимостью резервного копирования и восстановления метаданных Airflow?
Метаданные хранятся в базе (PostgreSQL/MySQL). DevOps делали бэкапы; я лишь убедился, что при сбое можно откатить до последней сохранённой версии.
206
Какие стратегии развертывания Airflow вам известны?
Docker-compose (локальные тесты), CeleryExecutor (расширенное прод), KubernetesExecutor. У нас чаще CeleryExecutor с разными воркерами.
207
Приходилось ли вам работать с подDAG-ами в Airflow?
Да, SubDagOperator. Но сейчас чаще TaskGroup. SubDagOperator применял, когда логически сгруппированные задачи повторялись с разными параметрами.
208
Знакомы ли вы с концепцией триггеров в Airflow?
Поверхностно. В основном пользовался прямыми зависимостями (>>). Для меж-DAG зависимостей — ExternalTaskSensor.
209
Как вы управляли секретами и учетными данными в Airflow?
Airflow Connections (UI), иногда Vault. В Variables с шифрованием, указывая login/password, подключение к S3, DB.
210
Расскажите о вашем опыте работы с пулами в Airflow.
Pools ограничивают параллелизм для ресурсоёмких задач. Например, Spark pool: max 3 задачи одновременно, чтобы не перегружать кластер.
211
Сталкивались ли вы с задачами миграции между версиями Airflow?
Да, обновляли с 1.10 до 2.x, проверяли обратную совместимость DAG-ов, переписывали импорты, DevOps обновляли Docker-образы.
212
Каковы, по вашему мнению, преимущества и недостатки использования Airflow как оркестратора?
Плюсы — гибкость, pythonic, большое сообщество. Минусы — требует правильной конфигурации окружения, не идеален для real-time стриминга.
213
Приходилось ли вам интегрировать Airflow с Kafka?
Да, через PythonOperator (kafka-python) или Debezium/Kafka Connect API для чтения/записи событий, хотя чаще Spark-стрим брал эти топики.
214
Как вы использовали Python-скрипты в Airflow DAG-ах?
PythonOperator для парсинга CSV, вызова REST API, Debezium/Kafka чтения, консолидации данных, записи в DWH.
215
Знакомы ли вы с понятием идемпотентности задач в контексте Airflow?
Да, задача при повторных запусках не должна дублировать данные. Например, чистим staging или проверяем, какие записи уже загружены, перед тем как вставлять заново.
216
Как вы настраивали алерты и уведомления о статусе выполнения DAG-ов в Airflow?
Параметры email_on_failure, Slack webhook, on_failure_callback. Если задача упала, Airflow отсылал уведомление.
217
Сталкивались ли вы с ограничениями на запись в определенные директории при работе с Airflow на препроде?
Да, DevOps иногда давали ограниченные volume для tmp, поэтому хранили временные файлы в разрешённой папке или сразу в S3.
218
Расскажите о технической стороне работы с данными: какие источники данных использовались и какого они были типа?
Основные — CSV/Excel (маркетинг), REST API (JSON), Oracle/PostgreSQL, ClickHouse. В ЮMoney часто приходили рекламные выгрузки, в ББР — отчётные CSV.
219
Какие типы загрузок CSV-файлов вам приходилось реализовывать?
Ежедневные/еженедельные, разовые массовые. Иногда 8+ файлов разных форматов, которые нужно объединить.
220
Опишите весь процесс обработки данных при работе с CSV-файлами: что происходило с данными с момента их получения и как вы их получали?
Airflow DAG → скачиваем (FTP/S3/HTTP), проверяем структуру (число колонок, заголовки), парсим Python (csv/pandas), чистим и загружаем во временные таблицы DWH. Затем хранимки или SQL-допобработка.
221
Как вы забирали файлы (включая CSV) из источников?
PythonOperator с paramiko (SFTP), requests (HTTP), boto3 (S3). Сохранял локально или сразу стримил в staging-таблицу, если объём небольшой.
222
Приходилось ли вам извлекать данные из CSV-файлов?
Да, разбирал заголовки, приводил типы (даты, float), мог объединять несколько CSV в один DataFrame, далее загружал в DWH.
223
Какие преобразования данных вы выполняли при работе с CSV-файлами (например, извлечение определённых столбцов, замена значений, удаление лишних символов)?
Да, убирал BOM, проверял заголовки, заменял «N/A» на NULL, конвертировал запятую в точку для float, чистил пробелы.
224
Выполняли ли вы замену значений (replace) в данных из CSV?
Да, например «-» → NULL, «нет» → ‘N’, и т.д., чтобы сохранить единый формат в DWH.
225
Была ли реализована проверка качества или структуры данных при работе с CSV-файлами? Каким образом?
Да, мы сверяли количество колонок, формат дат, если не соответствовало схеме, файл помечался ошибочным, Airflow слал алерт.
226
Что происходило с данными из CSV-файлов дальше после загрузки?
Они оказывались в staging (Oracle/Greenplum), потом SQL-процедурами фильтровали, обогащали, вставляли в финальные таблицы/витрины или Data Vault.
227
Был ли у вас опыт преобразования CSV в другие форматы, например, в Avro?
Avro не особо, но CSV → Parquet для Spark делал, чтобы эффективнее дальше обрабатывать в Hadoop или на локальном кластере.
228
Использовали ли вы Python для написания скриптов, связанных с обработкой CSV-файлов?
Да, в основном pandas, csv-модуль, иногда потоки (io) для больших файлов, подключал всё к Airflow.
229
Сталкивались ли вы с необходимостью перемещать CSV-файлы между различными системами или узлами?
Да, часто. Например, FTP → локальный каталог → S3 → Greenplum, организовывал это через Airflow bash/python tasks.
230
Имеете ли вы опыт внедрения CDC (Change Data Capture)?
Да, в ЮMoney настроили CDC с PostgreSQL через Debezium, чтобы оперативно передавать транзакции в Kafka, а оттуда в DWH.
231
Для чего вы внедряли CDC в своих проектах?
Чтобы не ждать ночных batch-загрузок, а получать изменения (INSERT/UPDATE/DELETE) из микросервисных баз почти в реальном времени.
232
Почему вы выбрали Debezium для CDC?
Удобно интегрируется с Kafka, open-source, поддерживает PostgreSQL, отслеживает WAL. Легче настроить, чем писать свою логику logical replication.
233
Какие альтернативы Debezium существуют для CDC с Postgres?
StreamSets, встроенный logical replication + custom code, иногда Oracle GoldenGate (для Oracle), но Debezium подходит именно под PostgreSQL+Kafka.
234
Какую роль выполнял Debezium в ваших проектах?
Он читал WAL PostgreSQL, генерировал JSON «before/after» и публиковал в Kafka-топики, откуда мы брали их для Greenplum или antifraud.
235
Если вы упомянули Kafka и Debezium, что именно вы сделали с их помощью?
Настроил коннектор: прописал database.dbname, table.include.list, replication slot, формат json. Данные попадали в топики, дальше Spark или Airflow потребляли их.
236
Расскажите о своём опыте настройки Debezium для отслеживания изменений в базах данных (например, Postgres).
Выдал нужные права пользователю, включил wal_level=logical, создал replication slot, в конфиге Debezium указал нужные таблицы, формат (after/before), задействовал transforms=unwrap для упрощённого JSON.
237
Как вы настраивали подключение Debezium к Postgres?
Менял postgresql.conf (wal_level=logical), создавал пользователя с REPLICATION, replication slot (SELECT * FROM pg_create_logical_replication_slot), в property-файле Debezium указывал хост, port, dbname, user, password.
238
Какова была цель внедрения Debezium в ваших предыдущих проектах?
Обновлять DWH чуть ли не в реальном времени, например для antifraud (подозрительные транзакции) и свежих маркетинговых отчётов.
239
Сталкивались ли вы с необходимостью настройки потоковой передачи данных с помощью Debezium для оперативного выявления и реагирования на события (например, аварийные ситуации)?
Да, в antifraud проверяли необычные транзакции; если Debezium видел новое поступление, Spark стрим мог реагировать.
240
Опишите свой опыт настройки потоковой передачи данных с помощью Debezium для оперативного реагирования на события.
Коннектор Debezium → Kafka, далее Spark Streaming читал топик, при определённых паттернах отсылал алерт в Slack. Концепция near real-time, задержка до нескольких секунд.
241
Каким образом Debezium взаимодействует с Kafka?
Через Kafka Connect. Debezium — это коннектор, который публикует события в определённые топики.
242
Что конкретно вы делали, используя Kafka и Debezium?
CDC для PostgreSQL (транзакции, справочники), чтобы автоматически синхронизировать данные в Greenplum и в antifraud модуле.
243
Какие данные вы передавали через Kafka и Debezium?
INSERT/UPDATE/DELETE для таблиц transactions, users, products. Debezium отдавал JSON {before, after}, а Spark/Airflow подтягивали нужные поля.
244
Сталкивались ли вы с проблемами пропуска или синхронизации данных при использовании Kafka и Debezium?
Да, иногда offset сбивался при неаккуратном рестарте коннектора, нужно было перезапускать replication slot или обрабатывать дубли.
245
Опишите свой опыт использования Docker Compose для Debezium, Kafka и Postgres.
Для локальных тестов поднимал zookeeper, kafka, connect, postgres в одном docker-compose, проверял, что коннектор видит изменения, публикует топики.
246
Знакомо ли вам понятие Kafka Connect? Использовали ли вы Debezium в качестве коннектора?
Да, Debezium — это plugin для Kafka Connect, мы прописывали connector configs JSON через REST API Kafka Connect.
247
Debezium сам настраивается?
Нужно вручную указать параметры (host, slot, table include), но после запуска connector в целом работает самостоятельно, следя за WAL.
248
Был ли у вас опыт работы с Kafka?
Да, в ЮMoney для CDC (Debezium) и для обмена событиями между сервисами.
249
Использовали ли вы Kafka на предыдущем месте работы?
В ББР Банке нет, а в ЮMoney Kafka был ключевым стриминговым решением.
250
Работали ли вы со стримингом данных с использованием Kafka?
Да, настраивал Spark Streaming потребителей, а также Airflow tasks, которые забирали сообщения для пакетной загрузки.
251
Внедряли ли вы CDC (сбор данных об изменениях) в работу с использованием Kafka и Debezium? Что именно вы сделали?
Да, для PostgreSQL таблиц (transactions, users), Debezium писал JSON в топики, я их потреблял для обновления Greenplum и antifraud анализа.
252
Настраивали ли вы Kafka-коннекторы и публикацию?
Да, Debezium — типовой connector, плюс мы тестировали sink-коннектор для выгрузки в S3, но в основном писали кастомную логику в Spark.
253
Знакомо ли вам понятие Kafka Connect?
Да, это фреймворк для подключения источников/приёмников без написания кастомного кода. Debezium — один из source-коннекторов.
254
Использовали ли вы Debezium в качестве коннектора для Kafka?
Да, именно так получали CDC из PostgreSQL.
255
В чем конкретно заключалась ваша работа с Kafka? (например, мониторинг, оповещения, создание витрин данных)
Настраивал топики, раскладывал партиции, писал консюмеры (Spark), смотрел consumer lag, чтобы не отставали. Поддерживал Debezium-коннектор, проверял логи.
256
Знаете ли вы, как работает Kafka?
Да, брокеры/топики/партиции, продюсеры отправляют сообщения, консюмеры читают, offset сохраняется. Zookeeper (или internal quorum) хранит метаданные.
257
Настраивали ли вы когда-нибудь топики и партиции в Kafka?
Да, создавал топики через kafka-topics, задавал фактор репликации, количество партиций. Для высоконагруженных потоков делал 3–5 партиций.
258
Зачем нужны партиции в Kafka?
Для горизонтального масштабирования и параллельного чтения/записи, чтобы распределить нагрузку между брокерами и консюмерами.
259
Как данные попадают в партиции?
По ключу (hash) или round-robin, если ключ не задан.
260
Каким образом данные попадают в Kafka? (например, JSON с полями before и after)
Продюсер отправляет сообщение, Debezium формирует JSON (before/after) и публикует в топик.
261
Как вы фильтровали события, поступающие в Kafka?
На уровне Debezium (table.include.list), иногда в потребителе (Spark) скидывал нерелевантные типы операций. Например, оставлял только INSERT/UPDATE транзакций.
262
Считаете ли вы Kafka стабильной технологией?
Да, при корректном мониторинге и настройке брокеров. Главное следить за storage, lag, replication.
263
Почему вы выбрали Kafka для решения задачи?
Надёжная, масштабируемая система, подходящая для асинхронного обмена сообщениями и стриминга. Интеграция с Debezium удобна.
264
Какие преимущества Kafka вы видите?
Высокая пропускная способность, надёжность (репликация), гибкая интеграция (Connect, Streams), возможность масштабировать консюмеров.
265
Для чего нужна распределённая система, такая как Kafka?
Чтобы обрабатывать большие объёмы сообщений, не упираясь в один сервер, обеспечивать высокую доступность и параллельную консюмацию.
266
Представьте ситуацию: вы загружаете данные из Kafka в файловую систему (FM), кластер состоит из трёх узлов. Как распределяются данные? Хранятся ли они в одном месте или распределены между узлами? Как они обрабатываются?
Сообщения распределяются по партициям, каждая партиция хранится на одном брокере и реплицируется на других. Консюмер читает партиции параллельно, пишет файлы. Так данные в итоге распределены.
267
Сталкивались ли вы с проблемами при работе с Kafka?
Да, когда коннектор Debezium падал и offset сбивался, либо при большом backlog консюмер мог «утонуть» в сообщениях. Надо было масштабировать воркеры, чистить топики от старых данных.
268
Как вы мониторили работу Kafka?
Prometheus/Grafana метрики, consumer lag, zookeeper state, логи брокеров. Настраивали алерты, если lag превышал порог.
269
Как вы обеспечивали надёжность доставки сообщений в Kafka?
Acks=all, replication factor=3, надёжный storаge. При сбоях в сети консюмер сдвигал offset только после успешной обработки.
270
Есть ли у вас портфолио на GitHub, Kegel, Bitbucket?
Рабочие репозитории были приватными, публичного портфолио, к сожалению, нет, но могу показать учебные pet-проекты.
271
Использовали ли вы Docker Compose?
Да, часто для локальных тестов (Kafka, Debezium, Postgres), также для Airflow dev-стенда.
272
Использовали ли вы Docker Compose для запуска окружения с PostgreSQL, Clickhouse, Kafka, Debezium, Control Center, Zookeeper, пользовательским интерфейсом Debezium?
Да, поднимал всё в одном docker-compose.yaml, где каждая служба имела свой container. Удобно для тестовой среды.
273
Вы используете Docker Compose для сборки?
Иногда, но чаще Dockerfile + docker-compose для orchestration. CI/CD может собирать образы, а compose — запускать их вместе.
274
Пробовали ли вы запускать Docker Compose файл для изучения Spark?
Да, есть готовые docker-compose примеры, но в продакшене Spark был на кластерных узлах, а не в Compose.
275
Как с помощью Docker узнать, какие контейнеры сейчас запущены?
docker ps.
276
Как вы узнаёте, какие Docker контейнеры запущены?
Аналогично, docker ps или docker-compose ps.
277
Как вы качаете Docker образы?
docker pull , либо docker-compose pull, если прописано в yaml.
278
Как вы получаете Docker образы?
Из Docker Hub или внутреннего registry, при запуске docker-compose подтягиваются автоматически.
279
Как узнать, какие Docker образы доступны?
docker images или смотрю в Docker Desktop, если GUI.
280
Что произойдет, если в вашем docker-compose.yml отсутствует какой-либо image?
Попытается собрать через Dockerfile (если build указан) или выдаст ошибку, если нет build+image.
281
Что случится, если Docker образ отсутствует в вашем yaml-файле?
Либо собирается при docker-compose build, либо не запустится, если не задано.
282
В основном вы используете Docker Compose, а как смотрите образы?
docker images, docker-compose images, либо Docker Desktop.
283
Смотрите ли вы на Docker образы через Docker Desktop?
На локальной машине да, удобно смотреть размер, версии.
284
Что вы обычно смотрите по Docker образам в Docker Desktop?
Теги, слои, размер, чтобы понять, не слишком ли раздут образ, и проверить наличие нужной версии.
285
Как происходит перенос решения из среды разработки (dev) в предварительную среду (pre-prod)?
Код в Git, CI собирает образ/артефакт, раскатываем на pre-prod, запускаем тесты. При успешном прохождении идём в prod.
286
После тестирования на pre-prod, как происходит выход в production (prod)?
Ручное или автоматическое утверждение релиза, CI/CD pipeline деплоит на prod-кластер, обновляет нужные контейнеры/скрипты.
287
Что происходит, если артефакты не справляются во время раскатки?
Деплой прерывается, делаем откат (rollback) на предыдущую версию, анализируем логи, правим ошибки.
288
Что может произойти, если система CI/CD испытывает трудности при обработке большого количества артефактов во время развёртывания?
Очередь может «забиться», сборки тормозят, возможны таймауты, конфликты зависимостей.
289
Умирает ли CI/CD при большом количестве команд и артефактов?
Может сильно замедлиться, если нет достаточного числа агентов или оптимизации сборок.
290
Может ли производительность CI/CD системы снизиться при работе с большим количеством команд и артефактов?
Да, если не хватает ресурсов. Надо масштабировать runners/agents, кешировать зависимости.
291
Сталкивались ли вы с ситуациями, когда ваша система CI/CD работала медленно или испытывала проблемы с большим количеством команд и артефактов?
Да, когда параллельно много веток, сборки могли ждать. Решали увеличением агентов, оптимизацией пайплайна.
292
Сталкивались ли вы с медленной работой или проблемами в CI/CD-системах из-за большого количества изменений и артефактов?
Да, частично решали через распределённые runners и кеширование docker-слоёв, npm-packages и т.д.
293
Как бы вы решали проблемы с производительностью или сбоями в конвейере CI/CD при большом количестве изменений кода и артефактов?
Добавлял параллельные executors, настраивал кэш, разбивал монолитный pipeline на несколько, включал триггеры только при реальных изменениях в коде.
294
Какие подходы или решения вы бы использовали для устранения проблем с производительностью или сбоев в CI/CD при интенсивной разработке?
Распараллеливание, feature flags, оптимизация тестов (не гонять все тесты при малых изменениях), пайплайн с разделением (build, test, deploy).
295
Как вы обычно интегрируете свои локальные изменения в общую систему разработки?
Создаю ветку, пишу код, пушу в remote, открываю merge/pull request, CI запускает тесты, после ревью вливаю в dev/main.
296
Опишите путь вашего кода от локальной машины до основной ветки в репозитории.
Коммит → push feature-branch → CI запускается → code review → merge → автодеплой на dev/pre-prod → при проверке ок — прод.
297
Какие этапы или процессы проходит ваш код при интеграции в основную ветку?
Линтеры (flake8, eslint), юнит-тесты, сборка образов, интеграционные тесты, возможно security scan, затем merge, деплой.
298
Перенимали ли вы экспертизу по каким-либо DAGам?
Да, брал чужой DAG с API-загрузкой, разбирался, документировал, оптимизировал логику в PythonOperator.
299
Были ли у вас свои зоны ответственности за определенные DAGи?
Да, в ЮMoney я отвечал за DAG, который выгружает рекламные метрики в Greenplum, а также за некоторые CDC-интеграции.
300
Оптимизировали ли вы свою рутину, связанную с работой с DAGами (например, проверку скриптов)?
Да, сделал скрипт, который прогоняет flake8 и airflow lint перед коммитом, автоматизировал проверку синтаксиса.
301
Решали ли вы проблемы, связанные с ограничениями прав доступа для DevOps и необходимостью изменения подхода к решению задач в DAGах (например, прокидывание библиотек или внешняя нарезка файлов)?
Да, когда нужна была специальная Python-библиотека, договаривался с DevOps обновить Docker-образ Airflow, либо монтировать нужные файлы.
302
Занимались ли вы оптимизацией ресурсов (например, памяти) в DAGах, особенно при большом количестве задач?
Да, ограничивал max_active_runs, concurrency, создавал pool, чтобы тяжёлые задачи не забивали весь worker.
303
Предстоит ли перевод каких-либо процессов в целевые типы данных в рамках DAGов?
Было, например, в Greenplum перевод float -> numeric, писал дополнительный шаг, который конвертировал поля, обновлял структуру.
304
Есть ли планы по оптимизации SQL в контексте работы DAGов?
Регулярно рефакторил SQL, смотрел планы, добавлял партиционирование. Если DAG начинал работать дольше обычного, разбирался, где «просадка».
305
Требуется ли приводить в порядок документацию, связанную с DAGами или кодом, который в них используется?
Да, в Confluence описывали логику, входные/выходные данные, расписание. Были инициативы повысить покрытие docstring, чтобы новички быстрее понимали пайплайн.
306
Расскажите о своём самом большом провале. Что вы из этого вынесли?
Однажды неправильно оценил время миграции (вместо 2 часов заняло 12). Вывод: всегда делать пилотную выгрузку на части, проверять производительность заранее.
307
Какие три слова вас лучше всего описывают?
Внимательный, ответственный, командный.
308
Какое ваше слабое место, над которым вы сейчас работаете?
Улучшаю публичные выступления и презентацию сложных технических идей, стараюсь говорить короче и яснее.
309
За что вас критикуют коллеги?
Иногда могу «зарыться» в детали и потратить много времени на совершенствование кода, что не всегда критично.
310
Какой фидбек вы получали в последний раз? Вы с ним согласны?
Говорили, что хорошо документирую сложные процессы, но иногда долго отвечаю на мелкие запросы. Согласен, улучшаю тайм-менеджмент.
311
Назовите свое самое сильное качество как сотрудника.
Умение глубоко вникать в задачу и доводить её до конца, не бросая недоработанным.
312
Какие привычки вам помогают быть продуктивным?
Планирование задач утром, разбивка больших целей на мелкие, Pomodoro-техники, когда нужно сфокусироваться на коде.
313
Чем вы гордитесь в своей карьере?
Участием в двух масштабных миграциях (Informatica → Airflow и ClickHouse → Greenplum), которые значительно улучшили инфраструктуру данных.
314
Как вы реагируете на дедлайны, которые сдвигаются на вчера?
Пересматриваю приоритеты, пытаюсь выделить MVP, предупреждаю коллег о рисках, прошу помощи, если нужно.
315
Что вы делаете, когда не хватает информации для принятия решения?
Запрашиваю уточняющие детали у заказчиков, провожу короткие интервью, если срочно — делаю прототип/гипотезу, показываю, согласую.
316
Бывали ли ситуации, когда вы не справлялись? Как вы вышли из них?
Да, при перегрузке задач просил помощи коллег, декомпозировал работу. Руководству обосновывал, что потребуется дополнительное время/ресурсы.
317
Расскажите о случае, когда вы были перегружены. Как вы справлялись?
Составил чёткий список задач, расставил приоритеты (must-have, nice-to-have), часть делегировал, часть перенёс, чтобы не «сгореть».
318
Как вы действуете в конфликтной или токсичной команде?
Стараюсь не поддаваться негативу, выяснять конкретные причины, перевести в конструктив, если не выходит — эскалирую руководству.
319
Расскажите, как вы помогали младшему коллеге или стажёру.
Давал чёткие вводные, помогал разбираться в коде DAG-ов, проводил code review, объяснял, как пользоваться Airflow hooks и писать тесты.
320
Что для вас значит быть «командным игроком»?
Делать не только свою узкую задачу, но и помогать коллегам, делиться опытом, стремиться к общему успеху, а не только к личным достижениям.
321
Случалось ли вам вступать в конфликты с коллегами? Как вы их решали?
Да, при выборе ETL-инструмента. Обсудили аргументы, провели пилот, выбрали лучший вариант. Я не перешёл на личности, искал компромисс.
322
Представьте, что кто-то не выполняет свои задачи — как вы будете действовать?
Сначала уточню, что мешает (непонятно ТЗ, нет навыков?), помогу. Если человек не меняется, подключаю руководителя.
323
Как вы ведёте себя на командных митингах, если не согласны с решением?
Озвучиваю аргументы, стараюсь проанализировать плюсы/минусы. Если общее решение принято не в мою пользу, уважаю командный выбор.
324
Какой ваш самый сложный проект и почему?
Миграция с ClickHouse на Greenplum в ЮMoney: много разных таблиц, большой объём данных, Data Vault архитектура, короткие сроки.
325
Какие компромиссы вам приходилось принимать в проекте?
Не весь функционал переносили сразу, оставили часть процессов в старом виде, чтобы уложиться в сроки, доделывали потом.
326
Расскажите про случай, когда вы приняли неверное техническое решение. Что было дальше?
Начал выгружать данные одним потоком, всё затянулось. Оперативно переписал скрипт с параллельными батчами, время сократилось в 2 раза.
327
Какие ошибки вы допускали в прошлом, и как теперь делаете по-другому?
Недооценивал время тестирования больших объёмов. Теперь всегда делаю пилотный прогон на части данных, замеряю, прогнозирую масштабирование.
328
Случалось ли вам переписывать чей-то код? Какие чувства у вас это вызвало?
Да, немного переживал, стараясь не нарушать авторскую логику, но понимал, что нужно упорядочить и улучшить читаемость.
329
Как вы развиваетесь профессионально?
Читаю статьи, блоги, документацию, иногда курсы. Практикуюсь на pet-проектах, обсуждаю с коллегами, анализирую best practices.
330
Как вы выбираете, чему учиться дальше?
Смотрю, что востребовано (бигдата, стриминг, облака), где у меня пробелы, какие задачи могут появиться в будущем проекте.
331
Последняя статья или книга, которую вы прочли по теме Data Engineering?
Недавно читал статьи о Data Vault 2.0, оптимизации Greenplum, плюс технические заметки по Spark Structured Streaming.
332
Какие навыки вы хотите освоить в ближайшие 6 месяцев?
Углубиться в Kubernetes (K8s) для бигдата-развёртываний, изучить Flink для стриминга, улучшить навыки DataOps.
333
Что вы считаете важным для перехода от middle к senior?
Брать ответственность за архитектурные решения, уметь наставлять коллег, видеть системную картину, а не только кодовую.
334
Расскажите про случай, когда вы взяли на себя инициативу без указания сверху.
В ЮMoney увидел, что CSV-пайплайны можно ускорить, написал скрипт в Python, который проверял соответствие заголовков автоматически, уменьшил количество ручных проверок.
335
Вы предлагали что-то, что улучшило процесс или сэкономило ресурсы?
Предложил параллелить выгрузку таблиц при миграции, это уменьшило время с 12 до 5 часов, все оценили.
336
Были ли у вас случаи, когда вы кого-то обучали или координировали?
Да, помогал джунам освоить Airflow, показывал, как правильно писать ETL-скрипты, документировать задачи.
337
Что бы вы улучшили в текущей команде или проекте, если бы могли?
Больше единой документации, кодстайла, упорядочение naming таблиц, чтобы новички быстрее погружались.
338
Как вы реагируете на критику?
Стараюсь понять суть, если конструктив — учусь. Если просто негатив, пытаюсь разобраться, в чём реальная проблема.
339
Были ли ситуации, когда вы сменили своё мнение после обсуждения?
Да, коллега нашёл более оптимальный способ дистрибуции в Greenplum, признал его правоту, принял вариант.
340
Как вы адаптируетесь к новым процессам, даже если они неэффективны?
Сначала пробую соблюдать, затем даю фидбек, предлагаю улучшения. Если без вариантов — приходится следовать, чтобы не мешать команде.
341
Что вы делаете, если требования заказчика кажутся вам странными или неопределёнными?
Спрашиваю дополнительные детали, делаю прототип, согласовываю. Если всё равно нелогично, подаю аргументы и варианты.
342
Как вы определяете, какие задачи важнее?
Смотрю на бизнес-приоритет, дедлайны, риск, согласовываю с руководителем или product owner.
343
Как вы справляетесь с ситуацией, когда все задачи «важные»?
Иду к руководителю, просим расставить приоритет, показываю реальные оценки, чтобы не было иллюзий, что всё можно сделать одновременно.
344
Используете ли вы какие-то техники планирования? (Kanban, Pomodoro и т.д.)
Команда работала по Scrum, я иногда пользуюсь Pomodoro для фокус-сессий, Kanban-доски в Jira.
345
Как вы управляете контекстом при переключении между задачами?
Веду список в Jira, выставляю время «фокусной» работы, делаю короткие заметки, чтобы быстро вернуться к задаче после переключения.
346
Случалось ли вам презентовать технические решения нетехнической аудитории?
Да, рассказывал руководству про Airflow/Greenplum, старался упрощать термины, приводить аналогии.
347
Как вы объясняете сложные вещи простыми словами?
Использую метафоры (склады, полки для данных), упрощённые схемы, показываю примеры, избегая сугубо технического сленга.
348
Какой у вас подход к написанию документации?
Структурирую: цель, входные/выходные данные, шаги, формат. Добавляю скриншоты/схемы, чтобы коллеги могли понять без лишних вопросов.
349
Как вы ведёте переписку с заказчиком или бизнесом?
Чётко формулирую вопросы, фиксирую итоги в письмах, если возникает двусмысленность — уточняю созвоном, пишу summary.
350
Согласились бы вы с решением, которое идёт вразрез с вашими ценностями?
Если это не нарушает закон и этику, могу аргументировать, но если принципиально не согласен — эскалирую/выражаю позицию.
351
Как вы действуете, если видите, что кто-то нарушает политику безопасности?
Сообщаю руководству/службе безопасности, не покрываю. Это корпоративные правила, их важно соблюдать.
352
Что важнее — быстро сделать задачу или соблюсти архитектурные принципы?
Обычно баланс. Если это критично и разово, может быть «быстро». Но лучше не жертвовать архитектурой без крайней нужды, чтобы не создавать огромный техдолг.
353
Что бы вы делали, если поняли, что не можете закончить задачу в срок?
Сразу предупреждаю команду/лида, предлагаю MVP или дополнительные ресурсы, пересматриваем объёмы, чтобы минимизировать ущерб.
354
Каким проектом больше всего гордишься?
Миграцией Informatica → Airflow и ClickHouse → Greenplum, дали огромный прирост гибкости, снизили лицензионные затраты и ускорили разработку.
355
Есть управленческий опыт?
Формально нет должности тимлида, но координировал джунов, брал на себя лидерство в технических решениях.
356
Опиши свой самый большой провал
Когда некорректно спланировал время огромной выгрузки, заняло в 6 раз дольше. Решил, разбив процесс на параллельные части, извлёк уроки о необходимости пилотов.
357
Какие у тебя главные недостатки?
Иногда могу тратить слишком много времени на «дотачивание», и бываю излишне въедлив в мелочи.
358
Опиши ситуацию, когда на работе был конфликт
Конфликт по выбору ETL-инструмента, я топил за Airflow, коллега за SSIS. Провели пилот, продемонстрировал гибкость Python, решили остановиться на Airflow.
359
Что будешь делать, если не успеваешь сдать задачу в срок?
Сообщу о задержке как можно раньше, уточню, что действительно критично, возможно сокращу фичи до MVP, попрошу подмогу.
360
Что нравится и не нравится делать на работе?
Нравится проектировать DWH, писать оптимизации, улучшать процесс. Не люблю чрезмерную бюрократию и однообразную рутину (например, ручные проверки).
361
У вас есть параллельные процессы, собеседуетесь в других компаниях, активно ищете работу?
Если уволились – активно, есть ещё несколько процессов, пара офферов.
362
Какие зарплатные ожидания
Определи для себя конкретное число и скажи “рассматриваю от Х тыс рублей в месяц на руки”. Одинаковое число для “минимальной и комфортной”. Если смущаешься, напиши на стикере и читай первое время с него. Не поддерживаю игры и желание оттянуть до последнего. На ру рынке полезнее сходить на 10 собесов за неделю, чем перекидывать мячик все эти дни.
Если будут сопротивляться, скажи “готов(а) рассмотреть варианты и обсудить условия, но ожидания такие”. Ты знаешь себе цену.
Если неадекватно отреагируют – супер, рано выявили, можно смело прощаться.
Если все компании согласны идти дальше и/или очень много входящих заявок – поздравляю, резюме отлично написано, проси на 50 тыс больше. Знакомый так поднял за один выход на рынок с 200 до 420.
363
Почему уходите с текущего места работы (что не нравится)
В ЮMoney ввели обязательные офисные дни (3 раза в неделю), что мне неудобно, а хочу удалёнку или гибкий график.
364
Что ищете на новом месте (что важно и нравится)
Интересные задачи, крутой проект
давно хотелось углубить свои знания в технологии Y, у вас как раз есть такая
хочу изучить новую для себя доменную область/посмотреть как работают другие бизнесы в моей сфере
хочу попробовать себя в работе над продуктом/проектной деятельностью
365
Почему хотите попасть в нашу компанию
Мне нравится упоминать персональную привязанность, например “три года жил(а) рядом с магазином магнит и задумывался, а как там принимаются решения; буду рад(а) разобраться и помочь развить платформу данных”
Нравится продукт
Классные технологии
Суперский hr-brand
Понравилось описание резюме
Знаю, что у вас работает классный спец Вася Пупкин, хочу поближе к нему
Друзья посоветовали, работали раньше
Пока нет особых причин, но надеюсь что наладим контакт на собеседованиях и захочу попасть именно к вам
366
Как поддерживаете актуальность знаний, изучаете новое
Смотрю записи конференций, читаю статьи на хабре, общаюсь с профессиональным сообществом в тг чатах и с коллегами из прошлых работ.
