Перейти к основному содержимому

Тест на готовность к работе с данными

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Всем

Наверняка в учёбе или работе вы сталкивались с необходимостью использовать Microsoft Excel и работать с таблицами.

Если да - как вам, тяжело было? Нравится?

Если нравится - однозначно, вы уже заложили фундамент и интерес к изучению данных. А вот если вам было крайне тяжело, значит придётся много чего подтянуть.

Давайте пробежимся по теме, чтобы проверить себя.

Сначала - краткий блиц:

  • чем данные отличаются от информации?
  • какой тип данных подойдёт для значения "123а"?
  • что такое булев тип данных (булево значение, Boolean)?
  • чем таблица отличается от списка?
  • из чего состоит таблица? Назовите минимум три компонента.
  • что такое запрос?
  • знаете ли вы, что такое база данных?
  • чем хранилище отличается от оперативной памяти?
  • знаете ли вы, что такое XML?

Если вы смогли легко и положительно ответить на вопросы выше - значит, как минимум с базой вы знакомы, и это хорошо.

Как проходить

Ответьте без подглядывания в разбор. В задачах с JSON и таблицами можно набросать ответ на бумаге или в редакторе. Если SQL в блоке 4 вызывает ступор — это сигнал начать с раздела "Основы баз данных", а не "плохой тест".

Что делать с результатом

Пройдите Навигатор новичка и профилей, чтобы сопоставить интерес к данным с другими направлениями (код, аналитика, интеграции, AI).

БлокТема
1Данные, информация, качество
2Структуры данных
3Операции: фильтр, join, группировка
4SQL и NoSQL — выбор и базовые запросы

1 — Данные и информация​

Вопросы​

  1. В логе сервера строка 2026-01-14T08:23:11Z | user_4582 | login_success — это данные или уже информация? Почему?
  2. Чем структурированные данные отличаются от неструктурированных? По одному примеру каждого.
  3. В колонке email встречаются N/A, - и пустые строки. Это проблема качества данных — какого именно (полнота, точность, согласованность)?
  4. Зачем фиксировать происхождение данных (data provenance): откуда файл, кто менял?
  5. Что даёт временная метка в потоке событий?

Задачи​

Задача 1.
Из фрагмента лога ниже выпишите только метки времени успешных входов (login_success):

2026-01-14T08:23:11Z | user_4582 | login_success
2026-01-14T08:25:03Z | user_4582 | page_view:/dashboard
2026-01-14T08:26:47Z | user_9103 | login_failed

Задача 2.
Текст: "Погода сегодня ясная, +5°C. Вчера +3°C. Завтра ожидается дождь."
Соберите таблицу (или JSON-массив) с полями дата, погода, температура — только из явных фактов в тексте.

Разбор: блок 1

Вопросы​

  1. Сырые данные; станут информацией после вопроса "сколько успешных входов за час?" и интерпретации.
  2. Структурированные — таблица, CSV, JSON с полями. Неструктурированные — свободный текст письма, фото без разметки.
  3. В первую очередь полнота (missing values); также согласованность формата.
  4. Проверка достоверности, аудит, воспроизводимость анализа, соответствие регламентам.
  5. Порядок событий, тренды, "что было до сбоя".

Задачи​

Задача 1.
2026-01-14T08:23:11Z

Задача 2.

[
  { "дата": "сегодня", "погода": "ясная", "температура": "+5°C" },
  { "дата": "вчера", "погода": null, "температура": "+3°C" }
]

Про "завтра" температура не указана — строку не выдумываем.

2 — Структуры данных​

Вопросы​

  1. Нужен мгновенный поиск пользователя по id в списке из 100 000 записей. Почему "голый" массив неудобен?
  2. Стек или очередь для кнопки "Отменить" в редакторе?
  3. Маршруты между городами (Москва → СПб, Москва → Казань…) — какая структура естественна?
  4. Что такое хеш-таблица на уровне идеи (без формул)?
  5. Почему выбор структуры влияет на скорость программы?

Задачи​

Задача 1.
Список пользователей:

[
  { "id": 101, "name": "Алиса" },
  { "id": 102, "name": "Борис" }
]

Предложите структуру для поиска по id за O(1) в среднем. Покажите вид данных.

Задача 2.
Связи — Москва → СПб, Москва → Казань, СПб → Хельсинки, Казань → Екатеринбург.
Запишите список смежности (граф).

Разбор: блок 2

Вопросы​

  1. Поиск в массиве — O(n); при частых запросах это дорого.
  2. Стек (LIFO): отменяется последнее действие.
  3. Граф (ориентированный), список смежности или матрица.
  4. Ключ → хеш → ячейка в массиве; быстрый доступ по ключу при хорошей хеш-функции.
  5. Разная сложность вставки/поиска/обхода; неверный выбор = тормоза и лишняя память.

Задачи​

Задача 1.
Словарь / Map: ключ id, значение — объект пользователя:

{
  "101": { "id": 101, "name": "Алиса" },
  "102": { "id": 102, "name": "Борис" }
}

Задача 2.

{
  "Москва": ["Санкт-Петербург", "Казань"],
  "Санкт-Петербург": ["Хельсинки"],
  "Казань": ["Екатеринбург"],
  "Хельсинки": [],
  "Екатеринбург": []
}

3 — Операции с данными​

Вопросы​

  1. Чем фильтрация отличается от агрегации?
  2. Inner join по user_id: заказы пользователя без заказов попадут в результат?
  3. Зачем переводят "широкую" таблицу (месяцы в колонках) в "длинную"?
  4. Что такое обогащение данных примером?
  5. Зачем хранить историю преобразований (lineage)?

Задачи​

Задача 1.
users = [{"id" — 1, "name" — "Алиса"}, {"id": 2, "name": "Борис"}]
orders = [{"user_id" — 1, "product" — "Книга"}, {"user_id": 1, "product": "Блокнот"}]

Соберите список заказов с именами (inner join).

Задача 2.
Таблица продаж:

2026-01-10 | Москва | 15000
2026-01-10 | СПб    | 12000
2026-01-11 | Москва | 18000

Сумма продаж по региону.

Разбор: блок 3

Вопросы​

  1. Фильтр отбирает строки; агрегация сворачивает много значений в одно (сумма, среднее…).
  2. Нет — только совпадающие ключи; у Бориса заказов нет → его не будет в inner join с заказами.
  3. Удобнее строить графики и SQL-запросы по одной колонке "месяц".
  4. Добавить к адресам координаты из справочника, к user_id — сегмент из CRM.
  5. Понять, откуда взялась цифра в отчёте; отладить ошибку ETL; пройти аудит.

Задачи​

Задача 1.

[
  { "user_id": 1, "product": "Книга", "name": "Алиса" },
  { "user_id": 1, "product": "Блокнот", "name": "Алиса" }
]

Задача 2.
Москва — 33000; СПб — 12000.

4 — SQL и NoSQL​

Вопросы​

  1. В реляционной БД где задаётся структура таблиц — в схеме или "в каждом документе своё"?
  2. Запрос "максимальная зарплата в каждом отделе" — нужна ли группировка или оконная функция?
  3. Документ MongoDB с вложенным массивом orders — это ближе к какой модели NoSQL?
  4. Почему для логов посещений (миллионы строк в день) часто выбирают колоночные или специализированные хранилища, а не "Excel на сервере"?
  5. Когда SQL предпочтительнее NoSQL в двух словах?

Задачи​

Задача 1.
Таблица employees (id, name, department_id, salary):

idnamedepartment_idsalary
1Алиса1090000
2Борис2085000
3Вера1095000

Напишите SQL: имя сотрудника с макс. зарплатой в своём отделе (допустим оконную функцию).

Задача 2.
События — user_id, timestamp, page_url, миллионы в день. Запросы: уникальные пользователи за день, топ страниц.
SQL или NoSQL — что выберете и одним абзацем почему?

Разбор: блок 4

Вопросы​

  1. В схеме (таблицы, типы, ограничения).
  2. Нужно разбить по department_id и взять max — GROUP BY + подзапрос или ROW_NUMBER() OVER (PARTITION BY ...).
  3. Документная модель.
  4. Массовая запись, аналитика по колонкам, масштабирование; Excel/один PostgreSQL без дизайна не выдержат объём.
  5. Транзакции, связи, сложные отчёты, строгая целостность (финансы, учёт).

Задачи​

Задача 1.

SELECT name, department_id, salary
FROM (
  SELECT name, department_id, salary,
         ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn
  FROM employees
) ranked
WHERE rn = 1;

Задача 2.
Часто колоночное хранилище (ClickHouse, BigQuery) или поток + агрегаты: много append-only записей, тяжёлые COUNT DISTINCT и GROUP BY по page_url. Классический SQL (PostgreSQL) тоже возможен с партициями по дате — ответ засчитывается, если обоснованы запись, объём и тип запросов.

Содержание