Н
соломоново решение. а уж как там стейж организован вообще никого не интересует
Size: a a a
2020 June 10
VS
получается просто следующее: вы разбили на под этапы ETL/ELT, чтобы их упростить как в сопровождении, так и в разработке
VS
вам легче внести данные в rawDV и при этом отдельно проще внести данные из rawDV в BDV
VS
что-то похожее на "микросервис", как нынче любят говорить
VS
вопрос только, сколько времени это будет работать, и какой процент данных в BDV нужен готовым asap
VS
если у вас требование, чтобы весь BDV был готов, то распиливать нет смысла, а если требование всего лишь по паре сущностей, то распил позволит более точечно разделить нагрузку загрузки данных на каждом слое
VS
моя практика говорит о том, что целиком BDV требуется гораздо позже, нежели какие-то срочные сущности
A
если исходить в моем вопросе из того, что raw dv вырождается в stage (просто хранит данные немного по-другому разложенные, в отличие от источника). то мы все-равно уже храним данные в stage (первоначальном) в том формате, в котором они приехали из источника. Не получается тут трансформация ради транформации? Ведь никакой прикладной пользы data vault stage, вроде бы не дает, кроме "унифицированной" модели
A
Владислав, и спасибо большое за развернутый ответ)
VS
Alexander
если исходить в моем вопросе из того, что raw dv вырождается в stage (просто хранит данные немного по-другому разложенные, в отличие от источника). то мы все-равно уже храним данные в stage (первоначальном) в том формате, в котором они приехали из источника. Не получается тут трансформация ради транформации? Ведь никакой прикладной пользы data vault stage, вроде бы не дает, кроме "унифицированной" модели
Как вариант, отказаться от stage, в пользу raw DV, но тут вам надо самим взвесить, на сколько сложнее будет все остальное из-за "легких" трансформаций на этапе забора данных из источника
VS
Я подобное в одном хранилище реализовывал, в целом, классический stage сводиться просто к temp таблицам, а потом при помощи ELT быстро раскидывал на сырой слой
PG
В dv при реализованном raw область stage просто сводится к landing зоне инкремента, а вся история хранится в формате dv. Оно удобно тем, что можно места меньше занять, чем в исходном формате, а также тем, что в bdv более удобно складывать. Но можно из полновесного stage просто в bdv сразу качать
VS
именно так
A
понял, всем спасибо!
2020 June 14
e
Вот тружусь над домашним ОпенСоурс - делаю универсального клиента к реляционным базам в Excel
если кто то видит что подобное пригодится в работе и готов потратить пару часов на бето - тестирование - то я готов "заточить" инструмент под ваши задачи . (добавить "экзотику" как источник и пр. )
* стучитесь в личку
если кто то видит что подобное пригодится в работе и готов потратить пару часов на бето - тестирование - то я готов "заточить" инструмент под ваши задачи . (добавить "экзотику" как источник и пр. )
* стучитесь в личку
Зарелизил бетку на SF
https://sourceforge.net/projects/in2sql/
https://sourceforge.net/projects/in2sql/
2020 June 15
🅰
Привет! Посоветуйте, какая архитектура данных наиболее оптимальна в сфере ежемесячной абонплаты за предоставление услуг (ЖКХ, начислено-собрано, вх. и исх. сальдо)? Сейчас данные вручную из нескольких подразделений стекаются в итоговую Google таблицу. Есть потребность автоматизировать сбор данных для последующей визуализации.
Н
Артур, вы практически спросили "что лучше Винда или Линукс" :)
DL
Артур, вы практически спросили "что лучше Винда или Линукс" :)
Обе плохи!
Н
Обе плохи!
только OS/2! только хардкор!
🅰
Да, понимаю. Новичок, мне сложно сформулировать. Думаю, есть какая-то оптимальная связка, чтобы сорганизоваться на начальном этапе.