Озеро данных должно быть неизменным :
Важно, чтобы все данные, помещенные в озеро, имели четкое происхождение по месту и времени. Каждый элемент данных должен иметь четкое представление о том, из какой системы он поступил и когда были получены данные. Озеро данных, таким образом, содержит историческую запись. Это может быть связано с подачей доменных событий в озеро, что естественным образом сочетается с системами источников событий. Но это также может происходить от систем, выполняющих регулярный сброс текущего состояния в озеро - подход, который ценен, когда исходная система не имеет каких-либо временных возможностей, но вам нужен временной анализ ее данных. Следствием этого является то, что данные, помещаемые в озеро, являются неизменными, наблюдение, которое однажды заявлено, не может быть удалено (хотя оно может быть опровергнуто позже), следует также ожидать ContradictoryObservations.
Есть ли какие-либо исключения из правила, где может считаться хорошей практикой перезапись данных в озере данных? Полагаю, нет, но некоторые товарищи по команде имеют другое понимание.
Я думаю, что происхождение и прослеживаемость данных необходимы в случае кумулятивного алгоритма, чтобы иметь возможность воспроизвести конечное состояние. Что, если конечное состояние не зависит от предыдущих результатов? Прав ли кто-то, если он говорит, что неизменность озера данных (источник событий) в озере данных необходима только для кумулятивных алгоритмов?
Например, у вас есть ежедневная загрузка таблиц A и B при полной нагрузке, впоследствии Расчет таблицы C. Если пользователь интересуется только последним результатом C, есть ли причины сохранять историю (получение событий на основе разбиения даты) для A, B и C?
Еще одной проблемой может быть соответствие ACID - возможно, ваш файл поврежден или частично записан. Но предположим, что мы обсуждаем случай, когда последние состояния A и B можно легко восстановить из исходных систем.