Что такое обработка данных

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

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

Обработка данных бывает разных типов: пакетная (batch), в реальном времени (real-time) и потоковая (stream processing).

В пакетной обработке большие объёмы данных обрабатываются одновременно, обычно ночью или в периоды низкой нагрузки.

В реальном времени данные обрабатываются сразу по мере поступления.

Основные шаги обработки данных:

I. Сбор данных
Первый шаг — собрать данные. Это можно сделать через опросы, сенсоры, веб-скрейпинг или API.

II. Очистка данных
Сырые данные часто содержат ошибки, дубли и пропуски. Очистка данных это поиск и исправление этих проблем, чтобы данные были точными и согласованными.

III. Преобразование данных
После очистки данные нужно привести в формат, удобный для анализа. Это может включать агрегацию данных, конвертацию типов или нормализацию.

IV. Анализ данных
После преобразования данные анализируются с помощью статистики или машинного обучения, чтобы выявить закономерности и инсайты.

V. Визуализация данных
Визуализация это представление обработанных данных в наглядной форме (графики, диаграммы, карты). Это помогает заинтересованным сторонам легко понимать и интерпретировать результаты.

👉 @BackendPortal

Сегодня отмечается День программиста!

256-й день года выбран не случайно:

Дата праздника объясняется расчетом: 2 (двоичная система исчисления) в степени 8 (количество битов в байте). То есть 2^8= 256. Поэтому в обычный год день программиста 13 сентября, а в високосный — 12 сентября

С праздником, коллеги! ☺️

👉 @BackendPortal

Да, CDN снижает задержки за счёт кэширования контента ближе к пользователям, но есть интересная оптимизация, которую они используют, чтобы ещё сильнее уменьшить latency

TCP страдает от slow start -> когда устанавливается новое TCP-соединение, оно сразу не работает на полной пропускной способности. Вместо этого оно стартует консервативно с небольшого количества сегментов и удваивает их каждый RTT, пока не обнаружит перегрузку.

Этот ramp-up может занимать несколько итераций, прежде чем достигнет оптимальной пропускной способности, что проблематично для latency-sensitive приложений. Это серьёзная проблема для CDN, потому что даже несколько лишних RTT на масштабе большого количества пользователей обходятся дорого.

CDN решают это с помощью persistent connection pools к origin-серверам. Вместо того чтобы создавать новое соединение для каждого запроса пользователя, они поддерживают пул долгоживущих соединений между edge-узлами и origin-серверами.

Интересная часть —> это pre-warming в периоды низкой нагрузки.

CDN периодически отправляют небольшие объёмы данных (например, health check или запросы на валидацию кэша) по этим idle-соединениям. Это поддерживает TCP congestion window на максимуме и предотвращает её уменьшение из-за простоя.

Небольшой расчёт, чтобы показать эффект.

Если поддерживать congestion window разогретой, она работает на 64KB вместо 4KB. Это исключает задержку 3–7 RTT, которая возникла бы в противном случае.

Для соединения с RTT 50 мс это экономит 150–350 мс latency - а это очень значимо на масштабе веба.

Надеюсь, вам было интересно. И, как всегда, копайте глубже. 🪰

👉 @BackendPortal

SQLZap это прям находка

sqlzap.com — это онлайн-платформа для тренировок SQL-запросов в браузере. Что-то вроде интерактивного тренажёра

Идеально чтобы натаскать руку (как Leetcode, только для SQL)

👉 @BackendPortal

Как TikTok справляется с миллионами коротких видео в реальном времени?

TikTok использует микросервисную архитектуру, где разные функции (загрузка видео, лента, комментарии, рекомендации) разбиты на независимые сервисы.

Когда вы открываете TikTok, ваш запрос проходит через балансировщики нагрузки и API-шлюзы, которые мгновенно направляют вас к нужному сервису.

Видео хранятся в распределенном облачном хранилище и доставляются через глобальные CDN (Content Delivery Networks). Это обеспечивает быструю загрузку ленты с минимальной буферизацией вне зависимости от вашего местоположения.

Ядро TikTok работает на ключевых сервисах (API). Сервис аутентификации управляет логинами и аккаунтами, сервис профилей пользователей хранит вашу активность, а сервис ленты формирует персонализированный список видео.

Знаменитая «For You Page» работает через сервис рекомендаций, который использует AI и машинное обучение для ранжирования и подбора видео. Отдельный сервис поиска помогает быстро находить тренды и авторов.

За кулисами TikTok обрабатывает огромные объемы данных. Поведение пользователей, лайки, время просмотра и взаимодействия постоянно поступают в модели машинного обучения, чтобы рекомендации обновлялись в реальном времени.

Базы данных специализированы: одни — для аккаунтов пользователей, другие — для метаданных видео, третьи — для аналитики.

Система спроектирована с учетом высокой доступности и отказоустойчивости, что позволяет TikTok работать стабильно даже при сбоях отдельных сервисов.

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

Технический стек TikTok:

🔸Frontend: React, Node.js, TypeScript
🔸Backend: Golang, Python, Java, Scala
🔸API-коммуникация: gRPC, GraphQL
🔸Mobile: Swift (iOS), Kotlin (Android)
🔸Базы данных: MySQL, Redis, Cassandra, TiDB
🔸Messaging: Apache Kafka, Pulsar
🔸Обработка данных: Apache Flink, Hadoop, Spark, Hive
🔸Безопасность: собственная IAM, слои шифрования, мониторинг трафика
🔸Хранилище видео: распределенное облако + глобальный CDN (собственный CDN ByteDance)
🔸DevOps: Kubernetes, Docker, Prometheus, Grafana, Chaos Testing
🔸Машинное обучение: TensorFlow, PyTorch, собственные AI-фреймворки ByteDance

👉 @BackendPortal

Каждый разработчик в растущем e-commerce сталкивался с этим вопросом:

Как масштабировать процесс создания заказов во время флеш-распродажи?

Есть 4 варианта.
Работает только один.

Разберём по порядку:

I. Синхронное создание заказа

. Запрос блокируется.
. Запись в БД в "горячем" пути.
. Ложится под нагрузкой.
. Не масштабируется.

II. Асинхронная обработка через очередь ✅

. Принимаем заказ.
. Кладём его в очередь.
. Быстро возвращаем ответ.
. Обрабатываем позже.

Это развязывает API и нагрузку:

. Масштабируется.
. Переживает пиковые всплески.
. Даёт контроль.
. Работает, потому что очередь берёт удар на себя.

III. Централизованный сервис заказов

. Один большой сервис.
. Один большой bottleneck.
. Код проще, проблемы те же.
. Разваливается на масштабе.

IV. Сплошные микросервисы

. Вносит задержки, координацию и новые точки отказа.
. Всё ещё не сглаживает пиковую нагрузку.
. Инструмент не для этой задачи.

Компромиссы (они всегда есть):

I. Eventual consistency.
II. Нужна идемпотентность (и так критично).
III. Нужно мониторить состояние очереди.
IV. Требуются компенсирующие транзакции.
V. Очередь сама по себе не решает всё.

👉 @BackendPortal

Клиентское кэширование в HTTP работает так

Сервер может отдавать два типа ресурсов — статические и динамические. Статические данные не меняются между запросами, поэтому их можно кэшировать на стороне клиента с помощью специальных HTTP-заголовков.

Когда клиент впервые делает GET-запрос к ресурсу, локальный кэш проверяет его наличие. Если ресурса нет, запрос уходит на сервер. Сервер в ответе указывает, что данные можно закэшировать -> заголовок Cache-Control задаёт время жизни ресурса, а ETag определяет его конкретную версию. Кэш сохраняет ответ и возвращает его клиенту.

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

Если ресурс в кеше устарел, кэш отправляет новый запрос на сервер с условным заголовком, например If-None-Match, где указывает сохранённую версию. Если сервер имеет новую версию, он возвращает её. Если изменений не было, он отвечает кодом 304 Not Modified, и клиент продолжает использовать локальные данные.

👉 @BackendPortal

Вопрос по системному дизайну

Как убедиться, что реплика синхронизирована с мастером и что данные корректны?
Мастер отправляет репликам логические операции, которые они применяют по порядку:

{"op": "add", "id": "apple"}
{"op": "add", "id": "apple"}
{"op": "remove", "id": "orange"}

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

Требования:

• Проверка должна работать за O(delta), где delta — это набор применённых изменений
• Проверка состояния должна занимать минимально возможное количество памяти

Дополнительно:

• Должна быть поддержка операций удаления
• Может ли система определить, где произошло расхождение?
• Может ли она определить, когда произошло расхождение?

👉 @BackendPortal

Как backend-разработчику в 2025 году оставаться востребованным

Изучи эти 11 навыков

I. Проектирование API — REST, GraphQL, gRPC.
II. Аутентификация и авторизация — OAuth2, JWT, OpenID Connect, Passkeys.
III. Базы данных — SQL, NoSQL, шардинг, индексы, оптимизация запросов.
IV. Кэширование — Redis, CDN, стратегии edge-кэширования.
V. Событийно-ориентированные системы — Kafka, Pulsar, стриминговые пайплайны.
VI. Конкурентность и асинхронность — реактивное программирование, структурированная конкуренция.
VII. Распределённые системы — микросервисы, service mesh, eventual consistency.
VIII. Безопасность — HTTPS, шифрование, zero trust, OWASP top 10.
IX. Обсервабилити — логирование, трассировка, метрики, OpenTelemetry.
X. Облако и деплоймент — Docker, Kubernetes, serverless, GitOps.
XI. Интеграция ИИ — LLM API, векторные базы данных, retrieval-augmented системы.

Хватит прыгать с одного языка на другой.

👉 @BackendPortal

Консистентность «read-your-writes» означает, что любая запись, сделанная в базу данных, сразу становится доступной для чтения тем же клиентом.

Звучит очевидно, но бывают ситуации, когда это правило не выполняется, особенно при работе на больших масштабах.

На сервере с одной нодой это легко гарантировать при использовании последовательных транзакций.

В среде с primary и replica всё сложнее. Во многих базах данных все записи и часть чтений обрабатываются на primary, а большая часть чтений выполняется на репликах. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает данные в базу и тут же пытается их прочитать с реплики, но записи там ещё нет.

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

Если используется асинхронная или полусинхронная репликация, чтения на реплики лучше направлять только тогда, когда консистентность «read-your-writes» не критична.

👉 @BackendPortal

Как работает ветвление по Gitflow?

👉 @BackendPortal

Кэшировать или не кэшировать?

Это вопрос, с которым бэкендер сталкивается каждый день.

Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.

Вот небольшой фреймворк, чтобы принимать решение правильно:

I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?

👉 @BackendPortal

Бесплатный прирост производительности для full table scan в Postgres 17

Смотри, Postgres как и большинство баз данных работает с фиксированными по размеру страницами. В таком формате хранится всё, включая индексы и данные таблиц. Размер страницы 8КБ, каждая страница содержит строки или индексные кортежи плюс фиксированный заголовок. По сути, страницы это просто байты в файлах, которые читаются и кешируются в buffer pool.

Например, чтобы прочитать страницу 0, вызывается read с offset 0 и длиной 8192 байта. Чтобы прочитать страницу 1, выполняется ещё один системный вызов read с offset 8193 и длиной 8192. Страница 7 это уже offset 57 345 и так далее.

Если таблица занимает 100 страниц в файле, то для full table scan мы сделаем 100 системных вызовов. У каждого вызова есть накладные расходы

Фича в Postgres 17 в том, что теперь можно объединять I/O. Можно задать, сколько операций объединять. Технически можно просканировать всю таблицу за один системный вызов. Это не всегда хорошая идея, и я ещё расскажу почему.

Также здесь добавили vectorized I/O с помощью системного вызова preadv, который принимает массив офсетов и длин для рандомных чтений.

Основная сложность это не читать лишнего. Допустим, я делаю seq scan и ищу конкретное значение. Я читаю страницу 0, нахожу результат и выхожу. Дальше читать не нужно. А с этой фичей я могу прочитать сразу 10 страниц за один вызов, вытащить их содержимое в shared buffers и только потом обнаружить, что результат был уже на первой странице. В итоге я зря потратил диск, память и пропускную способность.

Балансировать это будет непросто.

Важно понимать, что настоящий Postgres делает системный вызов в ядро, чтобы прочитать по 8К за раз. При этом ядро можно настроить на read ahead. В этом случае оно будет читать немного больше и кешировать данные в файловом кеше.

👉 @BackendPortal

Ваша софтверная архитектура всегда так же сложна, как и ваша организация

Слышали про Закон Конвея? Это теория, сформулированная компьютерным учёным Мелвином Конвеем в 1967 году. Она гласит:

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

Другими словами, структура софтверной системы часто определяется структурой и паттернами коммуникации внутри команды, которая её разрабатывает.

Из-за этого архитектура может оказаться неоптимальной для решаемой задачи — команда невольно начинает ставить свои организационные ограничения выше потребностей системы.

Например:

- организация с небольшими распределёнными командами скорее всего придёт к модульной (сервисной) архитектуре,

- а организация с крупными коллокированными командами — к монолитной архитектуре.

В широком смысле можно даже сказать, что именно HR во многом определяет архитектуру софта. 🤙

Чтобы обойти это ограничение, используют манёвр обратного Конвея (Inverse Conway Maneuver). Суть его в том, что архитекторы, инженеры и лиды вовлекаются в проектирование организационной структуры. Такой подход повышает шансы на более удачную архитектуру.

Тем не менее, многие компании игнорируют закон Конвея и живут в уверенности, что оргструктура и архитектура системы — вещи независимые. В итоге это оборачивается неприятными сюрпризами.

А теперь к вам, каков ваш опыт столкновения с Законом Конвея? 👧

👉 @BackendPortal