Root, ведущая технологическая компания в сфере автострахования, была основана на простой идее: цена автострахования должна отражать то, как люди действительно водят автомобиль. Мы также твёрдо верили в то, что нужно встречать клиентов там, где они уже находятся, через мобильный опыт. В 2015 году, на раннем этапе стартапа, мы разработали систему сбора данных, которая могла надёжно определять поведение при вождении и измерять местоположение, скорость, ускорение и другие сигналы во время поездок.
Чтобы быстро запустить MVP, мы сделали самое простое, что могли: сериализовали каждую поездку в JSON-файл и сохраняли его в S3. Затем эти файлы обрабатывались нижестоящими системами в признаки риска, которые можно было использовать в наших моделях скоринга и ценообразования. Стоит отметить, что это было вполне разумным решением для стартапа на ранней стадии, который всё ещё пытался доказать соответствие продукта рынку. Проблема заключалась в том, что первоначальное решение оказалось настолько надёжным, что мы так и не нашли времени пересмотреть дизайн и допущения, пока далеко не переросли свой первоначальный масштаб.
К 2020 году система разрослась до поддержки более миллиарда поездок, охватывающих несколько петабайт данных, при этом накапливая существенные ежегодные расходы на хранение. Кроме того, технический долг был повсюду: схемы разошлись между клиентами Android и iOS; эффективный запрос данных был почти невозможен; нижестоящие системы обработки были тесно связаны с точной структурой сырых полезных нагрузок поездок. Даже поиск конкретной поездки требовал обращения к метаданным, хранящимся в таблице базы данных внутри нашего основного страхового приложения. Затраты на хранение были серьёзной проблемой, но более важной была архитектурная проблема. Наша модель данных и проектирование системы сделали телематические данные всё более труднодоступными, сложными для обработки и развития в масштабе.
К этому моменту стало ясно, что необходимы большие перемены. Однако мы столкнулись с огромной проблемой: нужно было и представить, как будет выглядеть новое состояние, и заручиться поддержкой всей организации для реализации этих изменений.
Мы начали с определения нескольких архитектурных принципов:
- Телематика должна вести себя как независимая платформа, а не как деталь реализации, встроенная внутрь страхового приложения.
Телематика должна вести себя как независимая платформа, а не как деталь реализации, встроенная внутрь страхового приложения.
- Нижестоящие системы должны потреблять стабильные, чётко определённые данные, а не специфичные для источника полезные нагрузки.
Нижестоящие системы должны потреблять стабильные, чётко определённые данные, а не специфичные для источника полезные нагрузки.
- Хранилище должно быть оптимизировано для крупномасштабной обработки и аналитики, а не только для приёма данных.
Хранилище должно быть оптимизировано для крупномасштабной обработки и аналитики, а не только для приёма данных.
- Затраты должны быть снижены за счёт лучшего представления данных, сжатия и стратегий секционирования.
Затраты должны быть снижены за счёт лучшего представления данных, сжатия и стратегий секционирования.
Как только мы сформулировали эти принципы, мы смогли начать набрасывать дизайн как новой системы, так и новой модели данных.
Очевидно, телематика должна быть отдельной сущностью от основного страхового приложения и владеть как хранением, так и обработкой. Хотя могло быть заманчиво включить сбор данных в эти границы, важно было учесть, что если телематическая платформа Root действительно собирается стать поставщиком для страхового бизнеса, нам может понадобиться собирать данные из альтернативных источников (например, из других мобильных приложений или автомобилей). Поэтому сбор данных был оставлен за пределами системы, но была введена новая важная концепция: «каноническое преобразование».
Для каждого вышестоящего источника данных мы определяли шаг канонического преобразования:
C_source(X_source) → Y_canonical
C_source(X_source) → Y_canonical
Каждый источник мог поддерживать свою собственную нативную схему, но нижестоящие системы взаимодействовали бы только с каноническим представлением. Это позволяло телематической платформе, а не отдельным потребителям, владеть эволюцией схемы и совместимостью с течением времени.
Что касается модели данных, мы выбрали Parquet, который обеспечивал как более богатые типы данных, так и колоночный доступ для эффективных запросов. Мы также смогли устранить некоторую избыточность в наших полезных нагрузках данных, сократив набор измерений датчиков до минимального уникального представления.
Мы сохранили S3 в качестве базового уровня хранения, но ввели выделенный уровень индексации и запросов, чтобы нижестоящим системам больше не требовалось напрямую знать структуру хранения или пути к объектам. Поездки были сгруппированы в более крупные секционированные наборы данных Parquet, чтобы уменьшить накладные расходы на мелкие файлы, снизить затраты и значительно улучшить производительность аналитических запросов. (Мы углубимся в детали реализации в следующем посте.)
Ни одно из вышеперечисленных проектных решений не было прорывным, но вместе они составили настоящий сдвиг парадигмы как в проектировании систем, так и в моделировании данных. Технические проблемы даже не были самым большим препятствием. Хотя у нас было чёткое техническое направление, нам всё ещё нужна была более широкая поддержка других руководителей в том, что это стоящая инвестиция, учитывая отсроченную окупаемость и риски миграции. Аргумент, который в конечном счёте нашёл отклик, касался не столько затрат на хранение, сколько стратегической гибкости, необходимой системе.
Телематические данные были одним из ключевых отличий Root, однако окружающая инфраструктура становилась всё более хрупкой и сложной для развития. Добавление новых источников данных, обеспечение крупномасштабных экспериментов или поддержка новых аналитических рабочих процессов требовали преодоления многолетних неявных допущений, встроенных в хранилище, обработку и нижестоящие системы.
Другими словами, один из наших самых ценных активов постепенно становился операционно недоступным. Канонические данные дали нам путь, чтобы обратить эту тенденцию вспять.
Даже при наличии сильного архитектурного направления реализация оставалась чрезвычайно сложной. Миграция требовала от нас:
- создать конвейер канонического преобразования для устаревших данных поездок
создать конвейер канонического преобразования для устаревших данных поездок
- перепроектировать нижестоящую обработку для эффективного потребления нового формата
перепроектировать нижестоящую обработку для эффективного потребления нового формата
- проверить, что миграция была без потерь,
проверить, что миграция была без потерь,
- и убедиться, что предсказательная способность наших моделей скоринга осталась неизменной.
и убедиться, что предсказательная способность наших моделей скоринга осталась неизменной.
Всё это должно было произойти без прерывания работы существующей системы. Или, иными словами: нам нужно было построить Ferrari, управляя Civic.
К счастью, нам удалось проверить и конвейер преобразования, и логику нижестоящей обработки на меньших наборах данных перед началом полной миграции. Этот итеративный процесс тестирования оказался бесценным. В нескольких случаях он выявлял небольшие, но значимые расхождения (вплоть до пропущенного знака минуса в преобразовании данных датчика), которые могли незаметно изменить поведение нижестоящих моделей в масштабе.
Даже при наличии всесторонней валидации, когда настало время начинать полную миграцию исторических данных, неизбежно возник момент напряжения. Годы накопленных телематических данных должны были быть извлечены из архивного хранилища, преобразованы в канонический формат и обработаны заново с использованием нового конвейера, после чего устаревшие данные подлежали окончательному удалению. В этот момент корректность перестала быть теоретической.
Финальным этапом проверки было сравнение прогнозных результатов между устаревшей и канонической системами в масштабе. Когда результаты совпали с ожиданиями, это стало огромным облегчением для всей команды. На итоговой презентации график с финальными метриками производительности даже вызвал праздничный эмодзи от нашего CTO. Мы успешно перестроили фундамент платформы (включая достижение реальной экономии затрат, как показано ниже), не пожертвовав целостностью базовых моделей.
С чисто операционной точки зрения проект превзошёл наши ожидания, как видно из годовых показателей затрат:
Но эти цифры на самом деле не отражают всей картины.
В исходной архитектуре для достижения «приемлемой» стоимости хранения требовалось агрессивно архивировать подавляющее большинство исторических данных в Glacier Deep Archive. Хотя технически данные сохранялись, большая их часть становилась операционно недоступной. Проведение крупномасштабного анализа исторических поездок было громоздким, дорогостоящим и часто непрактичным.
В новой системе, даже после сокращения затрат на хранение примерно в 4 раза, все исторические данные о поездках стали немедленно доступными для запросов через стандартные аналитические инструменты. То, что раньше требовало специализированной операционной поддержки, теперь можно было выполнять с помощью простых SQL-запросов.
Улучшения в области вычислений были, пожалуй, ещё более значительными. До миграции стоимость обработки была настолько высокой, что лишь часть исторических поездок оценивалась с использованием наших новейших конвейеров извлечения признаков и скоринга. По сути, мы годами накапливали недоиспользуемые телематические данные, ожидая более масштабируемую модель обработки.
Каноническая платформа фундаментально изменила это уравнение. Мы смогли обработать 100% исторических поездок с использованием наших новейших алгоритмов, при этом значительно сократив вычислительные затраты. Что ещё важнее, исследователи и специалисты по данным теперь могли экспериментировать на полном историческом наборе данных, а не на тщательно ограниченных подмножествах. Одна исследовательская инициатива, откладывавшаяся годами из-за вычислительных затрат, была завершена уже через месяц после миграции данных. Изменение инфраструктуры действительно расширило круг вопросов, которые мы могли задавать.
Оглядываясь назад, проект подтвердил несколько уроков о крупномасштабных системах и долгоживущей инфраструктуре.
Во-первых, архитектуры стартапов почти всегда перерастают свои исходные допущения. Более важным решением является выбор правильного времени для таких изменений. Если действовать слишком рано, вы рискуете создать избыточно сложную архитектуру для будущего, которое может никогда не наступить. Если действовать слишком поздно, техническая сложность и организационная инерция становятся значительно труднее преодолимыми. В нашем случае мы почти наверняка ошиблись в сторону слишком долгого ожидания (хотя, вероятно, это более безопасная ошибка для компании на ранней стадии, сосредоточенной на поиске соответствия продукта рынку).
Миграция также подтвердила важную реальность инфраструктурной работы: одних улучшений производительности никогда недостаточно. Крупномасштабные миграции данных также требуют доказательства корректности. В нашем случае валидация в малом масштабе была необходима, но в конечном счёте недостаточна. Некоторые гарантии можно было установить только после завершения полной миграции и работы новой платформы с полным историческим набором данных.
Самое главное — проект изменил наше отношение к доступности данных. Эффективность хранения и вычислений важна, но доступность не менее важна. Данные, которые технически сохранены, но запрос к которым затруднён, можно считать несуществующими. Сделав исторические телематические данные широко доступными через стандартные аналитические инструменты, мы значительно расширили виды исследований и экспериментов, которые организация могла проводить. Этот сдвиг позволил нам отвечать на совершенно новые классы вопросов, которые ранее были слишком дорогими или обременительными для изучения.
В конечном счёте мы достигли цели по экономии затрат, успешно создав долговечную платформу для будущего телематики в Root.
В нашей следующей статье мы более подробно расскажем о том, как мы спроектировали каноническую модель данных и мигрировали миллиарды файлов общим объёмом в несколько петабайт без потерь и без прерывания работы нижестоящих систем.
