Перейти к содержанию
В рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVI
SmartyDevs
Данные · 03

Хранилища, рассчитанные под работу.

Snowflake, BigQuery, Redshift, ClickHouse и open-стек lakehouse. Размерены, смоделированы и оценены под масштаб, на котором вы сейчас — и масштаб, к которому идёте.

§ 01The problem

Какую проблему решаем

Большинство решений по хранилищу принимаются рано, между делом, и становятся очень дорогими для пересмотра. Не то хранилище, не то моделирование, не те паттерны доступа — а счёт растёт вместе с данными. Проектируем хранилища вокруг ваших реальных паттернов запросов с дисциплиной стоимости, которую большинство команд развивает только после первого шестизначного сюрприза.

§ 02Capabilities

Что собираем

  • 01Выбор хранилища: Snowflake, BigQuery, Redshift, ClickHouse, Postgres
  • 02Lakehouse на объектном хранилище с Iceberg или Delta
  • 03Dimensional-моделирование со star- и snowflake-схемами
  • 04Стратегии партиционирования, кластеризации и материализации
  • 05Контроль доступа и per-team data-marts
  • 06Мониторинг стоимости с per-query атрибуцией
  • 07Миграция между хранилищами без простоя
  • 08Оптимизация запросов на существующих хранилищах
  • 09Федеративный запрос между хранилищами там, где подходит
§ 03Deliverables

Что получаете

  • Production-хранилище с задокументированным моделированием и паттернами доступа
  • Мониторинг стоимости с per-team атрибуцией
  • Runbook миграции между хранилищами
  • Отчёт об оптимизации — часто с материальной экономией
§ 04Stack

Стек, к которому тянемся

Snowflake · BigQuery · Redshift
ClickHouse · DuckDB
Iceberg · Delta · Hudi
Postgres · Citus
Trino · StarRocks
dbt · SQLMesh
§ 05Ideal for

Подходит

  • Компаниям, чей счёт за хранилище становится материальным
  • Командам, переросшим аналитические запросы на Postgres
  • Дата-командам, рассматривающим миграцию Snowflake → BigQuery (или наоборот)
  • Организациям, внедряющим open-lakehouse рядом с облачным хранилищем
§ 06Process

Как идёт проект

  1. 01

    Аудит запросов

    Понимаем реальную нагрузку — паттерны запросов, требования к латентности, траекторию роста.

  2. 02

    Дизайн

    Выбор хранилища, моделирование, партиционирование, паттерны доступа — записаны с trade-off'ами.

  3. 03

    Реализация или миграция

    Строим новое или мигрируем существующее. Cutover с параллельной работой до момента, когда уверенность набрана.

  4. 04

    Оптимизация и мониторинг

    Дашборды стоимости, проходы оптимизации запросов, передача on-call.

§ 07Engagement

Как сотрудничать

01

Warehouse-аудит

1 — 2 недели

Аудит стоимости и производительности с приоритизированными рекомендациями.

02

Warehouse Build

6 — 12 недель

Greenfield-хранилище с моделированием, доступом и дисциплиной стоимости.

03

Warehouse Migration

8 — 16 недель

Переезд из одного хранилища в другое с параллельной работой и задокументированным cutover.

§ 08Common questions

Frequently asked.

01Snowflake или BigQuery?

Оба прекрасны. BigQuery для Google-native стеков и ad-hoc аналитики. Snowflake для всего остального, особенно multi-cloud. ClickHouse там, где латентность доминирует над стоимостью. Cost-model'им на вашей реальной нагрузке до рекомендации.

02Нужен ли lakehouse?

Если у вас материальные затраты на хранение, смешанные структурированные / неструктурированные данные или вы хотите независимость от вендора — да. Для большинства компаний managed-хранилище — правильный ответ на годы.

Есть задача, которую стоит решить как следует?

Напишите, какой результат нужен. Мы честно скажем, во что это обойдётся — письменно, в течение недели.

Начать разговор