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.
К счастью, мы смогли проверить как конвейер преобразования, так и логику последующей обработки на меньших наборах данных перед началом полной миграции. Этот итеративный процесс тестирования оказался бесценным. В нескольких случаях он выявил крошечные, но существенные расхождения (такие тонкие, как отсутствующий знак минус в преобразовании датчика), которые могли бы незаметно изменить поведение модели в масштабе.
Даже при наличии обширной проверки, момент начала полной исторической миграции был неизбежно напряженным. Годы накопленных телематических данных должны были быть извлечены из архивного хранилища, преобразованы в канонический формат и повторно обработаны с использованием нового конвейера, после чего устаревшие данные подлежали окончательному удалению. С этого момента правильность перестала быть теоретической.
Последним этапом проверки было сравнение прогнозных результатов между устаревшей и канонической системами в масштабе. Когда результаты совпали, как и ожидалось, это принесло огромное коллективное облегчение. В итоговой презентации график, демонстрирующий финальные показатели производительности, даже вызвал праздничный эмодзи от нашего технического директора. Мы успешно перестроили фундамент платформы (включая достижение вполне реальной экономии средств, как показано ниже), не жертвуя целостностью базовых моделей.
С чисто операционной точки зрения проект превзошел наши ожидания, что видно по годовым показателям затрат:
Но они не отражают всей картины.
В рамках исходной архитектуры достижение «приемлемых» затрат на хранение требовало агрессивного архивирования подавляющего большинства исторических данных в Glacier Deep Archive. Хотя технически эти данные сохранялись, большая их часть стала операционно недоступной. Проведение крупномасштабного анализа исторических поездок было громоздким, дорогим и зачастую непрактичным.
В новой системе, даже после снижения затрат на хранение примерно в 4 раза, все исторические данные о поездках стали доступны для запросов через стандартные аналитические инструменты. То, что раньше требовало специализированной операционной поддержки, теперь можно было выполнить с помощью простых SQL-запросов.
Улучшения в вычислительных мощностях были, пожалуй, еще более значительными. До миграции затраты на обработку были настолько высоки, что лишь малая часть исторических поездок оценивалась с использованием наших новейших конвейеров извлечения признаков и скоринга. Мы фактически накопили годы неиспользуемых телематических данных в ожидании более масштабируемой модели обработки.
Каноническая платформа фундаментально изменила это уравнение. Мы смогли обработать 100% исторических поездок, используя наши новейшие алгоритмы, при этом значительно сократив вычислительные затраты. Что еще более важно, исследователи и специалисты по анализу данных теперь могли экспериментировать с полным историческим набором данных, а не с тщательно ограниченными подмножествами. Одна исследовательская инициатива, которая откладывалась годами из-за вычислительных затрат, была завершена всего через месяц после миграции данных. Изменение инфраструктуры действительно расширило круг вопросов, которые мы могли задать.
Оглядываясь назад, проект закрепил несколько уроков о крупномасштабных системах и долгоживущей инфраструктуре.
Во-первых, архитектуры стартапов почти всегда перерастают свои первоначальные предположения. Более важным решением является определение того, когда наступает подходящее время для их обновления. Если начать слишком рано, вы рискуете переусложнить систему для будущего, которое может никогда не наступить. Если начать слишком поздно, как техническая сложность, так и организационная инерция становятся значительно труднее для преодоления. В нашем случае мы почти наверняка ошиблись в сторону слишком долгого ожидания (хотя, вероятно, это была более безопасная ошибка для компании на ранней стадии, сосредоточенной на поиске соответствия продукта рынку).
Миграция также подтвердила важную реальность в отношении инфраструктурных работ: одного повышения производительности никогда не бывает достаточно. Крупномасштабные миграции данных также требуют доказательства правильности. В нашем случае мелкомасштабная проверка была необходима, но в конечном итоге недостаточна. Некоторые гарантии могли быть установлены только после завершения полной миграции и работы новой платформы с полным историческим набором данных.
Самое главное, проект изменил наше представление о доступности данных. Эффективность хранения и вычислений важна, но доступность не менее важна. Данные, которые технически сохранены, но сложны для запроса, по сути, не существуют вовсе. Сделав исторические телематические данные широко доступными через стандартные аналитические инструменты, мы значительно расширили виды исследований и экспериментов, которые могла проводить организация. Этот сдвиг позволил нам отвечать на совершенно новые классы вопросов, которые ранее было слишком дорого или обременительно исследовать.
В конечном итоге мы достигли нашей цели по экономии средств, успешно создав долговечную платформу для будущего телематики в Root.
В нашей следующей статье мы подробнее расскажем о том, как мы спроектировали каноническую модель данных и перенесли миллиарды файлов общим объемом в несколько петабайт без потерь и без прерывания работы последующих систем.
