Тема «версионирование аналитических схем» поддерживает конкретное продуктовое решение. Единица «версии схем» — контролируемое изменение структуры и семантики события во времени. Вопрос «версии схем»: как менять трекинг без поломки исторических данных, потребителей и расчётов. Методика «версии схем» согласует определения, данные и действия. Владелец «версии схем» отвечает за итоговую формулу.
Контекст и цель
Контур «версии схем» начинается с будущего решения. Для «версии схем» назовите субъект и период. Реакция на изменение «версии схем» задаётся заранее. Единица «контролируемое изменение структуры и семантики события во времени» отделяет результат от активности команды. Такой порядок защищает «версии схем» от декоративной отчётности.
Основание «версии схем»: Snowplow различает совместимые и ломающие изменения схем. основание
Основание «версии схем»: JSON Schema описывает структуру и границы JSON. основание
Основание «версии схем»: Snowplow применяет схемы для проверки событий. основание
Основание «версии схем»: RFC 3339 унифицирует представление даты — в разборе «Версионирование событий и аналитических схем» — и времени. основание
Источники поддерживают принципы «версии схем». Локальные фильтры выбирает команда «версии схем». Полнота событий проверяется для «версии схем» отдельно. Стоимость ошибки также входит в решение «версии схем».
Рабочая модель
Формула «версии схем»: patch сохраняет смысл и совместимость; minor добавляет совместимые возможности; major меняет обязательные поля или семантику и требует миграции. Модель «версии схем» содержит шесть самостоятельных частей. Каждая часть «версии схем» имеет владельца и пример.
-
Идентификатор схемы. В «версии схем» элемент «идентификатор схемы» задаёт границу. Пара «идентификатор схемы — номер версии» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
-
Номер версии. В «версии схем» элемент «номер версии» задаёт границу. Пара «номер версии — совместимость полей» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
-
Совместимость полей. В «версии схем» элемент «совместимость полей» задаёт границу. Пара «совместимость полей — семантическое изменение» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
-
Семантическое изменение. В «версии схем» элемент «семантическое изменение» задаёт границу. Пара «семантическое изменение — потребители данных» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
-
Потребители данных. В «версии схем» элемент «потребители данных» задаёт границу. Пара «потребители данных — план миграции и завершения старой версии» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
-
План миграции и завершения старой версии. В «версии схем» элемент «план миграции и завершения старой версии» задаёт границу. Пара «план миграции и завершения старой версии — идентификатор схемы» проверяется на эпизоде. Исключения «версии схем» записываются до расчёта.
Конфликт вокруг «идентификатор схемы» блокирует модель «версии схем». Определение «версии схем» исправляется до публикации. Усреднение «версии схем» не решает смысловой конфликт.
Данные и расчёт
Паспорт «версии схем» фиксирует числитель и знаменатель. Субъект «версии схем» указывается отдельно. Для «контролируемое изменение структуры и семантики события во времени» задаётся источник времени. Часовая зона «версии схем» входит в контракт. Дедупликация «версии схем» описывает повторные события.
Ручная сверка «версии схем» использует реальные истории. Агрегат «версии схем» сравнивается с транзакционным источником. Компоненты «номер версии», «совместимость полей» и «семантическое изменение» сохраняются отдельно. Разложение «версии схем» показывает продуктовый сдвиг или дефект сбора.
Период «версии схем» следует естественному циклу. Календарная неделя подходит не всегда. Причина периода «версии схем» документируется. Дата пересмотра «версии схем» также фиксируется.
Интерпретация и решения
Правила чтения «версии схем» записываются заранее. После результата правила «версии схем» не переписываются.
-
Переименование поля считается ломающим изменением. В «версии схем» правило связано с «идентификатор схемы». Владелец «версии схем» указывает действие и срок реакции.
-
Изменение смысла при том же имени запрещено. В «версии схем» правило связано с «номер версии». Владелец «версии схем» указывает действие и срок реакции.
-
Новое необязательное поле не переписывает историю. В «версии схем» правило связано с «совместимость полей». Владелец «версии схем» указывает действие и срок реакции.
-
Временная зона и формат времени фиксируются контрактом. В «версии схем» правило связано с «семантическое изменение». Владелец «версии схем» указывает действие и срок реакции.
-
Каждый major получает отдельное правило объединения данных. В «версии схем» правило связано с «потребители данных». Владелец «версии схем» указывает действие и срок реакции.
Изменение «версии схем» сначала проходит техническую проверку. Релиз «версии схем» исключается первым. Затем «версии схем» сверяется с трафиком и задержкой. Гипотезы «версии схем» формулируются после проверки.
Практический пример
Событие order_completed сначала содержит только сумму. Новая модель добавляет валюту как обязательное поле и меняет трактовку скидок. Команда выпускает major-версию, пишет обе схемы месяц, сверяет отчёты и только затем прекращает старый поток.
В примере «версии схем» восстанавливаются реальные истории. Поток «версии схем» проверяется по «идентификатор схемы». Затем изучаются «совместимость полей» и «потребители данных». Агрегат «версии схем» сверяется с операционной системой.
Итог примера — правило решения «версии схем». Правило «версии схем» различает эксперимент и исправление данных. Дополнительное исследование назначается отдельно. Дашборд «версии схем» остаётся каналом доставки сигнала.
Порядок внедрения
Внедрение «версии схем» делится на короткие шаги. Каждый шаг «версии схем» оставляет контрольный результат.
-
Классифицировать предлагаемое изменение. Шаг «классифицировать предлагаемое изменение» уточняет «идентификатор схемы». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
-
Найти отчёты и модели-потребители. Шаг «найти отчёты и модели-потребители» уточняет «номер версии». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
-
Создать новую схему. Шаг «создать новую схему» уточняет «совместимость полей». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
-
Поддержать период двойной записи. Шаг «поддержать период двойной записи» уточняет «семантическое изменение». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
-
Сверить версии на одном трафике. Шаг «сверить версии на одном трафике» уточняет «потребители данных». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
-
Закрыть старую версию после миграции. Шаг «закрыть старую версию после миграции» уточняет «план миграции и завершения старой версии». В модели «версии схем» результат проверяют три роли. Переход «версии схем» сохраняется в журнале.
Первый расчёт «версии схем» повторяется независимым запросом. Расхождение «версии схем» разбирается по фильтрам. Время «версии схем» и идентификаторы сверяются далее. Версии «версии схем» проверяются отдельно.
Критерии качества
Определение «версии схем» готово при следующих условиях:
-
Правила версий записаны. Критерий «правила версий записаны» проверяет «идентификатор схемы». Подтверждение «версии схем» хранится запросом или событием.
-
Изменение имеет владельца. Критерий «изменение имеет владельца» проверяет «номер версии». Подтверждение «версии схем» хранится запросом или событием.
-
Известны все потребители. Критерий «известны все потребители» проверяет «совместимость полей». Подтверждение «версии схем» хранится запросом или событием.
-
Двойная запись ограничена по времени. Критерий «двойная запись ограничена по времени» проверяет «семантическое изменение». Подтверждение «версии схем» хранится запросом или событием.
-
История остаётся интерпретируемой. Критерий «история остаётся интерпретируемой» проверяет «потребители данных». Подтверждение «версии схем» хранится запросом или событием.
-
Схемы доступны машинной валидации. Критерий «схемы доступны машинной валидации» проверяет «план миграции и завершения старой версии». Подтверждение «версии схем» хранится запросом или событием.
Критерии «версии схем» оцениваются совместно. Формула «версии схем» не исправляет плохие данные. Точный поток «версии схем» бесполезен без решения.
Ограничения применимости
Перед публикацией «версии схем» укажите ограничения:
-
Часть внешних инструментов игнорирует версии. Ограничение «часть внешних инструментов игнорирует версии» меняет вывод «версии схем». В ответ добавляется «номер версии» или качественное исследование.
-
Долгая двойная запись увеличивает стоимость. Ограничение «долгая двойная запись увеличивает стоимость» меняет вывод «версии схем». В ответ добавляется «совместимость полей» или качественное исследование.
-
Не все семантические изменения видны в структуре. Ограничение «не все семантические изменения видны в структуре» меняет вывод «версии схем». В ответ добавляется «семантическое изменение» или качественное исследование.
-
Старые клиенты могут отправлять устаревшие события. Ограничение «старые клиенты могут отправлять устаревшие события» меняет вывод «версии схем». В ответ добавляется «потребители данных» или качественное исследование.
-
Миграция производных таблиц требует отдельного плана. Ограничение «миграция производных таблиц требует отдельного плана» меняет вывод «версии схем». В ответ добавляется «план миграции и завершения старой версии» или качественное исследование.
Крупное ограничение отменяет общий итог «версии схем». Несколько представлений «версии схем» честнее одного числа. Ложная определённость «версии схем» опаснее сложности.
Вывод
Практика «версии схем» начинается с единицы «контролируемое изменение структуры и семантики события во времени». Затем «версии схем» связывает формулу, события и проверки. Реакция «версии схем» назначается владельцу. Ручная сверка предшествует автоматизации.
Минимум «версии схем»: ответить на вопрос «как менять трекинг без поломки исторических данных, потребителей и расчётов». Далее проверяется формула «patch сохраняет смысл и совместимость; minor добавляет совместимые возможности; major меняет обязательные поля или семантику и требует миграции». Ограничения «версии схем» записываются до регулярного review.
