Size: a a a

Архитектура данных

2020 February 27

FL

Fedor Lavrentyev in Архитектура данных
Дальше возможны разные логики - можно игнорить, можно оповещать, можно падать
источник
2020 March 01

e

er@essbase.ru in Архитектура данных
Paul Golubev
Есть всякие data bigdata конфы, но они в основном бизнесовые. Можно там, где про data governance есть тематика
источник

FL

Fedor Lavrentyev in Архитектура данных
Какая лють
источник

FL

Fedor Lavrentyev in Архитектура данных
Я не очень понял, какую задачу они решали этой системой, для кого и почему именно в таком виде. Но выглядит страшно. :)
источник

FL

Fedor Lavrentyev in Архитектура данных
Vladislav 👻 Shishkov
Как только слышу eav, сразу большая тема для разговора, а нужен ли он. Пока был не нужен 😬
Я вспомнил кейс, когда EAV пригодился.

Хотели считать статистики распределений по колонкам на Spark. Если брать каждую колонку отдельно и строить по ней границы, бины и порядоквые статистики - то получается по N запросов на каждую колонку. Если же все колонки предварительно свернуть в EAV - то достаточно N запросов на всю таблицу, только добавляется группировка по атрибуту.

В EAV-ном виде расчет статистик проще разрабатывать, проще менеджерить, меньше оверхед на запуски, а по чистому времени примерно то же самое.

Но хранить данные в DWH в EAV’е, конечно, не стоит.
источник
2020 March 02

PG

Paul Golubev in Архитектура данных
Fedor Lavrentyev
Я не очень понял, какую задачу они решали этой системой, для кого и почему именно в таком виде. Но выглядит страшно. :)
Тоже не очень понял, кто потребители и какой вопрос решается. Метаданные чего именно, только хранилищ, или всея ПО? Но судя по характеру рассказа, они гордятся этим, и каждый из прогеров в идеале должен быть настолько ленив, чтобы автоматизировать максимально :)
источник
2020 March 06

AS

Aleksey S. in Архитектура данных
А что сейчас самое модное и удобное из опенсурса, чтобы хранить описание мастер-данных - метаданные, для Data governance?
Где бизнес-сущности описываются, их атрибуты - и желательно маппинг на конкретные поля в таблицах баз данных, чтобы отслеживать зависимости при изменениях
источник

RK

Roman Kolchin in Архитектура данных
Aleksey S.
А что сейчас самое модное и удобное из опенсурса, чтобы хранить описание мастер-данных - метаданные, для Data governance?
Где бизнес-сущности описываются, их атрибуты - и желательно маппинг на конкретные поля в таблицах баз данных, чтобы отслеживать зависимости при изменениях
опенсорс — это не про удобство 😊
источник

e

er@essbase.ru in Архитектура данных
Aleksey S.
А что сейчас самое модное и удобное из опенсурса, чтобы хранить описание мастер-данных - метаданные, для Data governance?
Где бизнес-сущности описываются, их атрибуты - и желательно маппинг на конкретные поля в таблицах баз данных, чтобы отслеживать зависимости при изменениях
есть условно бесплатный Oracle 🤪 OEMM
- в смысле его можно попробовать достаточно долго 😉

https://www.oracle.com/middleware/technologies/enterprise-metadata-management.html
источник

FL

Fedor Lavrentyev in Архитектура данных
Aleksey S.
А что сейчас самое модное и удобное из опенсурса, чтобы хранить описание мастер-данных - метаданные, для Data governance?
Где бизнес-сущности описываются, их атрибуты - и желательно маппинг на конкретные поля в таблицах баз данных, чтобы отслеживать зависимости при изменениях
Маппинг и зависимости правильно выковыривать из ETL-ного кода. Иначе они очень быстро разъезжаются и становятся неактуальными.
источник

AS

Aleksey S. in Архитектура данных
Не, в ETL совсем другое. Я про управление мета-данными - т.е. сущностями бизнеса типа "Заказ" и его атрибутами "Кассир", "Сумма" и т.п., а не ORDER nvarchar(36)
Наложение бизнес-сущности на поле в БД - приятный бонус, чтобы зависимости отслеживать при изменениях бизнес-процессов
источник

AS

Aleksey S. in Архитектура данных
А вот Оракл может быть больно... у нас всё же MS SQL как СУБД, может любовь не возникнуть
источник

AS

Aleksey S. in Архитектура данных
А платное, но дешевое? ))
И не облачное
Есть?
источник

PG

Paul Golubev in Архитектура данных
Aleksey S.
А вот Оракл может быть больно... у нас всё же MS SQL как СУБД, может любовь не возникнуть
Oemm для кучи источников, я даже кликвью файлы им разматывал
источник

PG

Paul Golubev in Архитектура данных
Там только интерфейс не очень то удобный, особенно для ведения бизнес глоссария
источник

FL

Fedor Lavrentyev in Архитектура данных
Сущность типа «Заказ» и его атрибут типа «Кассир», так или иначе, затронуты в ETL
источник

FL

Fedor Lavrentyev in Архитектура данных
Тебе нужны метаданные на всех слоях, от бизнес-глоссария до физики
источник

FL

Fedor Lavrentyev in Архитектура данных
И они все связаны
источник

FL

Fedor Lavrentyev in Архитектура данных
И эту связь можно жестко отслеживать и фиксировать
источник

FL

Fedor Lavrentyev in Архитектура данных
(но мы для этого пилим очень большой велосипед)
источник