Супермаркет Cyft

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

В Cyft мы обрабатываем данные о сотнях тысяч бенефициаров, каждый с годами клинической истории, в безопасной среде, соответствующей требованиям HIPAA. Затем мы получаем результаты передовых моделей машинного обучения и десятки отчетов, отслеживающих прогресс клинических бригад, при этом имея дело с беспорядочными данными о здравоохранении. Нам нужна была среда, способная работать во всех наших проектах, чтобы мы:

  • Храните грязные аналитические записные книжки отдельно от потока данных, но все же в месте, которое имеет смысл с потоком.
  • Воспользуйтесь преимуществами оптимизации Spark для длинных тонких таблиц, чтобы быстро обрабатывать данные, а не грубо форсировать их на наших экземплярах графических процессоров, но сохраните возможность запускать модели глубокого обучения на графических процессорах, если это имеет смысл.
  • Иметь согласованную структуру, в которую любой член команды может перейти из другого проекта и знать, как ориентироваться. Таким образом, наращивание объемов продаж может сосредоточиться на вещах, которые действительно уникальны для разных проектов.
  • Вовлекайте как наших специалистов по данным, так и инженеров от супа до орехов. Нет никаких предположений, сделанных на пустом месте, и каждый может проследить за тем, откуда произошли события.
  • Сделайте повторное использование кода простым и очевидным. Если вы что-то выясняете в одном проекте, становится очевидным, где это должно развиваться в следующем. Упрощение работы с предыдущими работами означает, что мы становимся лучше с каждым проектом.
  • Позвольте членам команды с разным опытом и знаниями погрузиться в атомарные разделы.
  • Выполните все аспекты использования данных для улучшения здравоохранения, включая анализ, моделирование и отчетность.

Лучшая метафора окружающей нас среды - это супермаркет. Мы организуем все данные по разным «проходам» - либо сырые ингредиенты, либо еще несколько готовых продуктов (разработка функций). Проходы длинные и тощие (что и распределенные гроздьями вроде). Проходы объединены в один «супермаркет». Из этого централизованного файла мы можем извлечь различные «тележки» для разных когорт и моделей. Сам супермаркет не меняется для разных вариантов использования, и после того, как мы заполнили полки, мы можем продолжать делать покупки там.

Вот наша общая структура:

  1. Глотать
  2. Проверка и исследование
  3. Право на участие
  4. События
  5. Проходы
  6. Профилирование
  7. Супермаркет
  8. Тележки
  9. Модели Spark
  10. Приготовление еды (тензор)
  11. Модели глубокого обучения
  12. Анализ
  13. Развертывание
  14. Доставка
  15. Составление отчетов

Для этой работы мы используем экземпляры Spark и GPU. Подавляющая часть конвейерной обработки данных происходит на Spark, поэтому мы можем воспользоваться преимуществами распределенного кластера. Обработка, которая могла бы занять несколько часов на экземпляре GPU с прямым перебором, может выполняться гораздо эффективнее в распределенном кластере, особенно с учетом того, что этот кластер можно масштабировать во время высокого спроса, а затем возвращать обратно. С другой стороны, распределенные кластеры испытывают трудности с поддержкой методов глубокого обучения, поскольку эти алгоритмы плохо распределяются. Запуск только кластера серьезно ограничил бы наши возможности моделирования, в то время как запуск только больших экземпляров графического процессора был бы дорогостоящим и трудоемким. Возможность передавать данные между двумя мирами позволяет нам использовать преимущества обоих миров.

Чтение файлов

  1. Глотать
  2. Проверка и исследование

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

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

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

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

Здесь многие конвейеры очищают свои данные, но не мы. На ранних этапах взаимоотношений и процесса мы обнаружили, что предположения об очистке данных часто оказываются неверными. Если есть проблемы, мы хотели бы иметь контрольный журнал, и при всех сложностях загрузки некоторые предположения очистки могут быть трудными для анализа. Сохраняем очистку данных на этапе обработки данных (см. Ниже).

Право на участие

3. Право на участие

Какой человек имеет право на какую услугу и в какие дни? Эта на первый взгляд простая таблица образует основу для всех остальных таблиц, поскольку сообщает нам, на каких людях мы можем моделировать и когда. Например, когда люди переходили на этот план медицинского страхования и прекращали его, когда участники имеют право на участие в определенных программах, а когда - нет? На этом этапе обычно требуется много обсуждений с командами по обработке данных, чтобы убедиться, что никто не считает нужным, когда этого делать не должно, и наоборот. Однако оно того стоит, потому что именно такие детали заставляют наши модели работать в реальном мире.

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

Обработка данных

4. События

5. Проходы

6. Профилирование

Здесь мы начинаем разбивать все уникальные данные и структуры в единый формат. Мы помещаем обычно широкие данные в длинные тонкие таблицы, которые Spark обрабатывает эффективно. В разделе «Мероприятия» мы обязательно извлекаем информацию о различных клинических событиях, таких как госпитализация и визиты в отделение неотложной помощи. Другие проходы представляют собой сочетание других функций прямо из набора данных, а также наших «проходов с готовой едой», где наши собственные библиотеки обрабатывают стандартизованные теперь точки данных и возвращают более значимые функции. Например, вместо почтового индекса получите средний доход, плотность населения и средний уровень использования системы здравоохранения. Вместо названия препарата узнайте, что это за препарат. Иногда это называется разработкой функций, если вы предпочитаете такую ​​номенклатуру. Здесь также происходит вся очистка данных.

Как только данные будут представлены в этом более стандартизированном формате, мы можем погрузиться в раздел «Профилирование», еще один раздел анализа. У клиницистов есть предположения об их населении, а люди в аналитических группах знают, как выглядят их числа. Теперь, когда данные представлены в согласованном формате, это самый простой этап в нашем процессе для выполнения общей аналитики и количественного анализа, чтобы убедиться, что мы соответствуем их ожиданиям. Таким образом, мы не переходим к моделированию с неверными данными или неверным предположением о том, как эти данные должны обрабатываться. У каждой организации есть свой набор крайних случаев. Здесь мы также проводим весь предварительный анализ потенциальных функций, чтобы увидеть их распределение и то, как мы могли бы наилучшим образом использовать их в наших моделях.