BA & SA | 10000 Interview questions

☀Объяснение:

«Импортировать Excel» — функциональное требование, но без брейкдауна (декомпозиции) нельзя спроектировать решение. Аналитик обязан разбить на подвопросы:

Максимальный размер файла: 1 МБ или 2 ГБ? Это влияет на потоковую обработку (chunked) vs загрузка в память.
Форматы: .xlsx, .xls, .csv? Разные парсеры.
Скорость: импорт за 5 секунд или 5 минут?
Обработка ошибок: при неверной строке — откат всего импорта или пропуск с логом?
Многопоточность: можно ли обрабатывать несколько файлов параллельно?

Реальный кейс: Один аналитик не спросил про размер, разработчик загружал файл целиком в память. При 500 МБ сервер упал с OOM. Переделали на потоковый импорт.

Вывод: Любое общее требование должно быть разбито на проверяемые компоненты. Это ключевая техника системного анализа.

№4843 категория вопросов: #REQUIREMENTS

☀Объяснение:

Что такое token bucket?
Это алгоритм, который контролирует скорость отправки запросов:
Корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, запрос задерживается или отклоняется.

Leaky bucket — аналогичен, но ограничивает не пиковую скорость, а среднюю.

Почему это должен делать клиент?
Если клиент превышает лимиты API, он получит HTTP 429 («Too Many Requests») и может быть заблокирован. Клиент сам должен ограничивать свою нагрузку, чтобы не перегружать внешний сервис и не терять запросы.

Реальный пример
Twitter API ограничивает 300 запросов на 15 минут. Клиентские библиотеки (например, Tweepy) содержат встроенный token bucket. Без него приложение поймает 429 и упадёт.

Что должен зафиксировать аналитик
Требование: «На стороне клиента реализовать ограничение частоты запросов в соответствии со спецификацией API (token bucket)».
Параметры: максимальная скорость, размер корзины, стратегия при переполнении (блокировка, очередь).
Обработка ошибок 429: увеличение задержки (exponential backoff).

Вывод: Rate limiting — обязанность не только провайдера API, но и клиента. Аналитик должен включать это требование в спецификации интеграций.

№4842 категория вопросов: #INTEGRATION

☀Объяснение:

Как работает асинхронная репликация
Мастер-сервер принимает транзакцию, подтверждает клиенту «успех» и потом отправляет изменения на реплику. Если мастер падает между подтверждением и отправкой, реплика не получает данные → потеря транзакций. Это допустимо в системах, где допустима микро-потеря (например, аналитика), но не в финансовых или критичных системах.

Синхронная репликация
Мастер отправляет данные на реплику, ждёт её подтверждения, и только после этого отвечает клиенту «успех». При падении мастера реплика уже имеет данные, и потери нет. Недостаток: задержка увеличивается, так как клиент ждёт ответа от реплики.
Пример из реальной жизни
В банковских системах (например, при переводе денег) используется синхронная репликация. В социальных сетях (лайки, просмотры) — асинхронная, так как пара потерянных лайков не критична.

Что должен зафиксировать аналитик
Допустимо ли RPO (Recovery Point Objective) больше нуля? Если нет — синхронная репликация.
Какая задержка допустима? Синхронная репликация медленнее.

Нужно ли распределение по географическим зонам? Тогда синхронная репликация может быть очень медленной.
Вывод: Для критичных к потере данных систем синхронная репликация обязательна. Аналитик должен указать это в требованиях к отказоустойчивости.

НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ

Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎

Тут мы собрали каналы для себя, которые реально помогают:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление

🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk

№4841 категория вопросов: #DBMS

Если коротко, то ИИ уже не будущее, а наше настоящее.
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.

Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.

Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
 
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа  
 
* Отписаться можно в любой момент. Остаться — тоже. ✔️

Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk

☀Объяснение:

Что такое CAP-теорема?
В 2000 году Эрик Брюер сформулировал, что в распределённой системе невозможно одновременно гарантировать три свойства:
Consistency (C) – все узлы видят одни и те же данные в один момент времени (нет устаревших копий).
Availability (A) – каждый запрос получает ответ (даже если некоторые узлы недоступны).
Partition tolerance (P) – система продолжает работать при разрыве связи между узлами (сетевом разделении).

При возникновении сетевого разделения система вынуждена выбирать между C и A:

CP‑система (например, HBase, MongoDB с настройкой по умолчанию) жертвует доступностью: при разделении блокирует запись, чтобы не нарушить согласованность.

AP‑система (например, Cassandra, CouchDB) жертвует строгой согласованностью: возвращает данные, которые могут быть устаревшими, но система остаётся доступной.

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

Финансовые транзакции – приоритет согласованности (CP). Даже если система временно недоступна, деньги не должны потеряться.
Лента новостей – приоритет доступности (AP). Лучше показать слегка устаревшие новости, чем вообще не открыть приложение.

Реальный кейс:
В Amazon при оформлении заказа применяется строгая согласованность (CP), а при просмотре каталога — eventual consistency (AP). CAP-теорема помогает объяснить такие архитектурные компромиссы заказчику.

Вывод:
Аналитик, знающий CAP-теорему, может аргументированно выбирать хранилище данных под бизнес-требования, понимая неизбежные компромиссы.

№4840 категория вопросов: #DBMS

☀Объяснение:

SCD Type 2 отслеживает полную историю изменений: при изменении атрибута текущая строка закрывается (end_date = now), и вставляется новая строка с новыми значениями и start_date = now. Для каждого заказа можно определить актуальный адрес на момент заказа, присоединив по дате между start_date и end_date.

Почему не Type 1 (перезапись) – потеря истории.
Type 3 (отдельная колонка «предыдущий адрес») – хранит только текущий и предыдущий адрес, но не полную историю.
Type 0 – вообще без изменений.

Реальный пример: В розничной сети SCD Type 2 используется для измерения «Клиент», чтобы видеть, по какому адресу был сделан каждый заказ несколько лет назад.

Вывод: Аналитик должен выбирать тип SCD в зависимости от того, нужна ли история, и как далеко нужно видеть прошлые состояния.

№4839 категория вопросов: #DBMS

☀Объяснение:

Проблема: если система удалила файл, а затем упала при обработке, данные потеряны навсегда. Решение: атомарное переименование (rename) — дешёвая и надёжная операция на большинстве файловых систем.

Алгоритм:
Заметить файл data.csv.
Переименовать в data.csv.processing (показывает, что файл взят в работу).
Обработать содержимое.
Если успех — удалить data.csv.processing.
Если ошибка — переименовать обратно в data.csv (или в data.csv.error для ручного разбора).

Почему это лучше, чем просто перемещать в failed – потому что переименование идемпотентно, и даже при падении в середине процесса файл не теряется.

Реальный пример: В банковской интеграции с партнёрами используется паттерн *.inprogressдля файлов, которые читаются в текущий момент.

Вывод: Аналитик должен закладывать в требования двухстадийную обработку для любых интеграций через файловые обменники.

№4838 категория вопросов: #INTEGRATION