|
|
|
Source->ETL->DWH->Stage->DWH(ODS)->DWH(Analyst)->OLAP/Reporting->PBI->Excel.. кто длиннее?
|
|||
|---|---|---|---|
|
#18+
Коллеги, день добрый. Александр расписал в соседней ветке указанную цепочку, и она нередко встречается. Пожалуйста, объясните мне сакральную сущность данных преобразований. Что мешает ее сократить? Например: Call-center CRM \ (розница) CRM \\ (корпораты) ABS -> ETL -> DWH -> ADWH -> визуализатор? CRM // (брокеры) Back / ... Просто чем больше систем, тем: * Сложнее понять откуда берутся данные - отсюда интерес к Data Governance * Усложняется получение отчетности * Удлиняется цикл получения отчетности * Растут требования к аппаратному обеспечению * Повышается сложность сопровождения * Увеличивается кол-во сотрудников в отделах разработки и сопровождения систем отчетности * Сильно возрастает % возникновения ошибки: Если допустить, что % внесения ошибки - порядка 2% на каждом этапе, то в итоге получим ->ETL->DWH->Stage->DWH(ODS)->DWH(Analyst)->OLAP/Reporting 0,98 х 0,98 х 0,98 х 0,98 х 0,98 х 0,98 = 0,868.. то есть 13% - кстати, это один из аргументов 6 сигм. Ладно, согласен с DWH - хранить исторические данные из разных систем, обеспечивать взаимодействие нескольких информационных систем, ок. А дальше-то зачем? Что мешает использовать связку DWH - Vertica - Tableau (как Авито сделали) или еще проще Source -> Teradata -> Tableau? Ну или сразу в тот же Qlik запихать - а так и приходится делать, когда перед руководством встает вопрос о быстром получении достоверной отчетности? И не говорите про "большие объемы данных" - в Магните / Х5 / ГПН / Сбербанке / Росгострахе / Ростелекоме и т.д. их не меньше. Нет, конечно, если хочется быть начальником 40 человек, и чтоб сервачков было побольше утилизировано, или чтоб считать себя важным незаменимы человеком, чтоб на поклон ходили и по 2 месяца отчет ждали - то ок, это понятно, дай Бог каждому Пока бизнес платит, чего бы и нет - я бы и больше систем насовал, тот же Data Governance, или DL стал рисовать какой-нибудь, было бы финансирование. Но в целом, объясните кто-нибудь, зачем такая цепочка и что получается результате каждого преобразования? Source->ETL->DWH : ? DWH->Stage : ? Stage->DWH(ODS) : ? DWH(ODS)->DWH(Analyst) : ? DWH(Analyst)->OLAP/Reporting : чистые подготовленные данные для получения отчетности. Не троллинг - задачи и подходы разные бывают, так что буду признателен. С Уважением, Георгий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 12:06 |
|
||
|
Source->ETL->DWH->Stage->DWH(ODS)->DWH(Analyst)->OLAP/Reporting->PBI->Excel.. кто длиннее?
|
|||
|---|---|---|---|
|
#18+
авторSource->ETL->DWH : ? DWH->Stage : ? это один степ, не тупи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 12:21 |
|
||
|
Source->ETL->DWH->Stage->DWH(ODS)->DWH(Analyst)->OLAP/Reporting->PBI->Excel.. кто длиннее?
|
|||
|---|---|---|---|
|
#18+
Ivan Durak - ну, а я думал что-то новое изобрели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 12:40 |
|
||
|
Source->ETL->DWH->Stage->DWH(ODS)->DWH(Analyst)->OLAP/Reporting->PBI->Excel.. кто длиннее?
|
|||
|---|---|---|---|
|
#18+
На каждом этапе - свой набор обработки данных. 1. Source -> Stage чтобы максимально быстро и без каких-либо преобразований (ну за редким исключением) забрать дельту данных из источника в буферную зону для дальнейшей расфасовки. Также иногда храним данные в буферной зоне за некоторый период для разбора полетов, для доказательств что именно такие данные мы забарли из источника, если там они вдруг хитрым образом были скорректированы 2. Stage -> DWH (ODS/3NF/др.) слой хранения сведенных, сопоставленных, обработанных, обогащенных данных; длительное постоянное хранение в едином формате (нужна модель данных) данных в состоянии покоя. Сюда пользователям и системам доступ не даем. Кстати, модель данных - инструмент коммуникации бизнесов между собой и с ИТ 3. DWH -> DWH(Analyst) аналитический слой - денормализованные, агрегированные (не обязательно Group BY), скомпонованные данные - для: * удобства работы Power Users, adHoc-ов * как единый согласованный источник для OLAP и всевозможных BI Tools * для Reporting-отчетов * предоставления внешним/ другим прикладным системам Тем более нужна модель данных. Единый словарь, семантика Если пользователи или системы будут ходить к 2., то до 80% своего времени будут тратить не на решении аналитических задач, а на работу с данными. И куча других проблем образуется п.п. 1, 2, 3 также могут выполняться быстро Теперь про достоверность данных. Если из Source поступает Garbage (имеется ввиду серьезные проблемы, а не данные, которые можно полечить), то п.п. 1,2,3 и MDM, ML, Qlik, Data Governance и прочие аббревиатуры - уже бессмысленны. Схожих источников (одних только розничных CRM в компании - 4-5 штук) может быть много, просто загрузить в Qlik или куда еще и представить отчетик Руководству - ну так себе занятие, все всё поняли Теперь про Data Governance. По DAMA-DMBOK2 - это больше про 10 технологических аспектов, ну еще про C-Levels для избранных под расстрел или ... Мы с коллегами рассматриваем, прежде всего финансовый аспект, как данные - НМА актив, интелл. продукт и работа с ними как с другими активами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 12:49 |
|
||
|
|

start [/forum/topic.php?fid=49&fpage=14&tid=1857551]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
38ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 131ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...