Разработка BI инструмента. Часть 1. Формирование модели
Вступление
Данный опыт для меня будет сколь новым, столь интересным и познавательным. Поэтому в цикле следующих статей я планирую описывать шаги, контрольные точки а также интересные наблюдения с которыми столкнулся в процессе разработки.
Формирование структуры проекта
Итак, первоначальная схема у меня сформировалась следующая:
На вид довольно элементарно и даже канонично, теперь же постараюсь описать основную бизнес-логику:
В Базе BigData планируется хранить массивные данные сессий исследований над пациентом. Это могут быть результаты ЭКГ, ЭЭГ, замеры движений глаз и т.п. Вот пример такой структуры с результатами электроокулографии левого и правого глаза:
Размер такой таблицы напрямую зависит от длительности сессии и может варьироваться от 150 тыс. до 1 млн. строк. Также стоит учитывать что измерения могут проводится параллельно и в одной сессии могут быть как данные с ЭЭГ, так и с ЭКГ. Несомненно потребуется возможность параллельного чтения и анализа этих данных для установления взаимного влияния друг на друга.
В структурной базе бэкенда, помимо основных данных приложения, будут храниться записи о доступных сессиях, их времени начала и конца, типе, статусе, а также краткой сводной информации, например о среднем артериальном давлении за всю сессию или найденных отклонениях.
Между этими двумя базами понадобится спроектировать провайдер, выполняющий функции ETL. Возможно в ходе разработки, он будет выделен в отдельный сервис.
На стороне клиента необходимо реализовать функционал взаимодействия с сессиями, построения графиков, диаграмм, фильтрации, группировки и прочего. Помимо этого, не будет лишним, если решение будет кроссплатформенным с возможностью формирования отчетов через веб-приложение и их будущего просмотра в мобильной версии.
Фронтенд и бэкенд будут взаимодействовать посредством RestAPI. Однако в этой области планирую провести сравнение и анализ gRPC.
Список инструментов
Думаю теперь пора нарастить скелет мышцами в виде стека инструментов которыми буду решать задачу. Постараюсь описать, и в будущих очерках сравнить с другими и оценить правильность тот или иных выборов.
БД для BigData
В данной категории из всего списка доступных СУБД решил сузить круг до двух претендентов:
MongoDB
ClickHouse
Обе базы имеют множество преимуществ и работают совершенно по-разному, поэтому детально сравнивать их сейчас будет не совсем корректно.
С одной стороны MongoDB выглядит более простым и развитым решением, которое имеющим объемную документальную базу и обширное комьюнити, что несомненно упростит и ускорит процесс разработки.
С другой стороны колоночная CliсkHouse является отличным выбором для аналитической БД с превосходной скоростью чтения и привычным SQL. Однако мне известно немного и в следующих статьях планирую провести ее анализ и сравнение с MongoDB в рамках моей задачи.
БД для бэкенда
PostgreSQL
Из-за уже имеющегося опыта работы с данной БД и из-за того что она является не просто реляционной, а объектно-реляционной, позволит формировать более гибкие и структурированные запросы. Также поддержка большого количества типов данных, включая массивы и json не будет лишней. Ну и конечно наличие хорошей документации.
Бэкенд
Django
Не являясь веб-разработчиком и плохо зная javascript решил выбрать бэкенд на языке программирования к которому привык больше всего. Выбор был между двумя самыми популярными Django и Flask. Остановился на первом в связи с наличием структуры MVC и поддержкой нескольких баз данных. Явных перевесов в рамках текущего проекта пока не нашел. Обе системы по-своему гибкие и для решения задачи имеют место. А информация о том что на Django стоят такие гиганты как YouTube или Instagram сыграла в пользу этого бэкенда.
Фронтенд
Flutter
Опять же не являясь веб-разработчиком и плохо зная HTML + CSS пришел к выводу, что Flutter наиболее оптимальный вариант для меня. Несмотря на относительно небольшой возраст, язык Dart довольно приятен в использовании и работа на нем после Python не ощущается тяжелой. Кроссплатформенность SDK Flutter является одним из ключевых преимуществ. Сам интерфейс прописывается в коде, что делает грань между логикой и дизайном почти незаметной в результате чего решение ощущается более целостным и органичным. А при необходимости интерфейс с легкостью разбивается на отдельные модули. Ну а собственный графический движок и активное развитие платформы также немаловажный показатель.
Итоги
В результате анализа моя схема приобретает обрастает деталями и приобретает следующий вид:
