![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Интересная задача
Dec. 8th, 2023 01:53 pmНа работе стоит задача высчитывать автоматически число циклов ковша экскаватора во времени (метрика продуктивности).
Что дано:
- в среднем каждые 5 минут эксакаватор, на котором установлена система датчиков, посылает в облако бинарный tag-файл, в котором содержатся показания датчиков от времени. В этом файле каждая отдельная запись показаний приборов ("событие") представлена строкой. События генерируются с частотой примерно 5 Hz (5 строк в секунду).
У меня есть user defined function, небольшая процедура исполняющая "бизнес-логику":
- я беру эти самые записи;
- детектирую интервалы, в которых происходят колебания ковша;
- для каждого интервала фильтрую частоты по мощности, оставляя лишь k самых мощных;
- подсчитываю число пиков оставшихся гармоник.
Есть проблема: tag-файлы поступают в хранилище не по очереди; может даже так случиться, что вчерашний файл приходит только сегодня.
Я спроектировал ETL-процесс в MS Azure:
- tag-файлы поступают в blob-хранилище;
- триггер-функция (function app) реагирует на поступление каждого нового файла в хранилище и конвертирует его в читабельный формат;
- далее содержимое файлов отправляется в хаб;
- откуда оно записывается в озеро данных;
- из озера данные поступают в Databricks Delta Live Table процесс, который формирует бронзовый, серебряный и золотой слои данных, в процессе чего выполняется моя UDF-процедура;
- результат выполнения пользовательской процедуры записывается в золотую таблицу, которую можно заносить в регулярные автоматически генерируемые файлы отчетов.
Трудность в том, что из-за запаздывания поступления данных стоит проблема пересчета интервалов и циклов в них. Пусть, например, только что поступивший tag-файл, заполняет дыру между двумя вчерашними интервалами. Вследствие того, что я считаю циклы только целиком, исходя лишь из пиков главных гармоник, я отбрасываю неполные циклы, которые могут иметь место в начале и в конце интервалов колебаний ковша. По этой причине и требуется пересчет в данном случае, начиная с предшествующего интервала и кончая последующим.
Задача многократно облегчается, если UDF-процедура выполняется всего один раз на каждый tag-file. В этом случае мне всё равно, запаздывают мои данные или нет, и никаких пересчётов производить не нужно. Для этого мне потребуется лишь изменить UDF-процедуру для учёта неполных циклов. Тогда каждый tag-file потребуется просчитать лишь однажды, а результаты подсчёта можно будет сразу записывать в базу.
Кстати, финтифлюшки типа Azure Data Explorer и Databricks стоят очень дорого. На моей подписке я потратил почти 10 килобаксов за последние десять месяцев.
Что дано:
- в среднем каждые 5 минут эксакаватор, на котором установлена система датчиков, посылает в облако бинарный tag-файл, в котором содержатся показания датчиков от времени. В этом файле каждая отдельная запись показаний приборов ("событие") представлена строкой. События генерируются с частотой примерно 5 Hz (5 строк в секунду).
У меня есть user defined function, небольшая процедура исполняющая "бизнес-логику":
- я беру эти самые записи;
- детектирую интервалы, в которых происходят колебания ковша;
- для каждого интервала фильтрую частоты по мощности, оставляя лишь k самых мощных;
- подсчитываю число пиков оставшихся гармоник.
Есть проблема: tag-файлы поступают в хранилище не по очереди; может даже так случиться, что вчерашний файл приходит только сегодня.
Я спроектировал ETL-процесс в MS Azure:
- tag-файлы поступают в blob-хранилище;
- триггер-функция (function app) реагирует на поступление каждого нового файла в хранилище и конвертирует его в читабельный формат;
- далее содержимое файлов отправляется в хаб;
- откуда оно записывается в озеро данных;
- из озера данные поступают в Databricks Delta Live Table процесс, который формирует бронзовый, серебряный и золотой слои данных, в процессе чего выполняется моя UDF-процедура;
- результат выполнения пользовательской процедуры записывается в золотую таблицу, которую можно заносить в регулярные автоматически генерируемые файлы отчетов.
Трудность в том, что из-за запаздывания поступления данных стоит проблема пересчета интервалов и циклов в них. Пусть, например, только что поступивший tag-файл, заполняет дыру между двумя вчерашними интервалами. Вследствие того, что я считаю циклы только целиком, исходя лишь из пиков главных гармоник, я отбрасываю неполные циклы, которые могут иметь место в начале и в конце интервалов колебаний ковша. По этой причине и требуется пересчет в данном случае, начиная с предшествующего интервала и кончая последующим.
Задача многократно облегчается, если UDF-процедура выполняется всего один раз на каждый tag-file. В этом случае мне всё равно, запаздывают мои данные или нет, и никаких пересчётов производить не нужно. Для этого мне потребуется лишь изменить UDF-процедуру для учёта неполных циклов. Тогда каждый tag-file потребуется просчитать лишь однажды, а результаты подсчёта можно будет сразу записывать в базу.
Кстати, финтифлюшки типа Azure Data Explorer и Databricks стоят очень дорого. На моей подписке я потратил почти 10 килобаксов за последние десять месяцев.
