Вот более реалистичный запрос. Про нюансы мне пришлось специально уточнять, тк сеть даже не попыталась об этом задуматься и в первом варианте ответа это не учитывала. Клиент ничего не покупавший в 2022 году также подходит под условие "сделал меньше 3х покупок".
Запрос, который выдала сеть, дает АБСОЛЮТНО некорректный результат.
Более того она не осознает, что при наличии условия 2, условие 1 является избыточным, заведомо усложняя запрос и создавая лишнюю нагрузку на БД.
Так же клиент, который что-то купил в феврале или марте 2023, ничего не покупавший в 2022 году, не попадет в выборку, а логически по условию должен - ответ "клиент не покупал ноутбуки в сентябре" тоже часть статистики. Боюсь представить что выдала бы сеть, если бы я и эту часть попытался уточнить)
Проблематика в степени доверия. Почему я должен быть уверен, что этот ИИ даст мне правильный ответ, корректные данные из БД, корректным образом обработанные? Как принимать решения по этим данным?
Вот простейшая задача, на который генерируется с виду правильный ответ, но по факту на реальных данных даст абсолютно неверное решение.
Основные вложения как технических специалистов так и аналитиков / методологов будут на этапе проектирования (какую модель данных для себя выбрать, в какие процессы и как именно встроить работу с инструментом) и внедрения решения.
На этапе поддержки и сопровождения потребуется минимум затрат технических специалистов - я бы оценил до 20% FTE.
Хорошо продуманный, внедренный и контролируемый процесс работы с Atlas гарантирует, что работа аналитиков/ методологов и дата стюардов будет сопоставима с трудоазтартами при работе с другими инструментами документирования (WORD, EXCEL, WIKI, GIT, jupiter notebook и пр).
OpenMatadata - многообещающий и интересный по архитектуре и функционалу продукт. Сам к нему присматриваюсь и планирую в ближайшие недели пилотировать.
Что привлекает:
Архитектура кажется проще (в том числе технологически) в сравнение с DataHub
Встроенные профилирование и DQ (простенький)
Версионирование метаданных (!)
Data Lineage до столбцов (появится летом в релизе 0.11)
Открытые JSON модели метаданных - близко по духу к ATLAS и задел на гибкость
PULL/PUSH наполнение метаданных. Развитый REST API
Плотная интеграция с DBT, вплоть до вывода исполняемого кода в интерфейс. В современных платформах данных DBT встречается все чаще как инструмент трансформации данных.
Разметка текста - базовая, но в Atlas даже такого нет.
Социальные функции - владельцы данных, комментирование, упоминания, доска актваности etc
Зачатки системы нотификации об изменениях - webhook, к которому можно приладить свое приложение для красивой доставки нотификации
Есть конечно подозрение, что часть функционала в варианте из коробки окажется слишком упрощенной, ограниченной, недостаточной для конкретных нужд.
Почему я часто говорю про важность гибкости инструмента к настройке и кастомизации, в том числе подразумевая простоту архитектурного решения, чтобы без капитальных трудозатрат доделать продукт под себя.
Спасибо за мнение. Было бы интересно посмотреть на ваш подход к сравнению и результаты. По функциональности из коробки, да, DataHub кажется выигрывает.
У меня нет полноценно практического опыта использования DataHub.
Изучая документацию и доступное демо, сложилось следующее сугубо личное мнение:
+ Владение данными, профиль пользователя (статистика)
+ Вроде есть базовый функционал по профилированию данных и простенькие отчеты по статистике использования. Не до конца понял где доступно (для каких интеграций) и как работает.
+ Развитое документирование карточки метаданных - есть отдельная вкладка для описания с разметкой текста.
+ Большой спектр доступных интеграций, PULL и PUSH механизмы наполнения каталога данными.
- При этом интерфейс кажется перегружен и вызывает эстетическую неприязнь.
- Нет Data Lineage до столбцов (есть где-то roadmap). Не понравилось как отображается Data Lineage - каждый уровень нужно принудительно раскрывать, а в текстовом списке доступны не все уровни зависимости в части Lineage (Impact доступен)
- Не до конца понятно, возможно ли кастомизировать модели метаданных, на сколько возможно (сложно) кастомизировать процессы вытягивания метаданных (интеграции)
- Архитектура показалась усложненной, стек примененных технологий - обширный. Похоже на наследие внутренней корпоративной кухни LinkedIn где продукт рождался. Задача "доработать под себя" может оказаться крайне затруднительной.
Да, максимально органично Atlas встраивается в Hadoop экосистему и присутствует в составе дистрибутивов от ArenaData, Cloudera и HortonWorks.
Но про прибитось Atlas к Hadoop не соглашусь. Для работы из экосистемы Hadoop Atlas нужны только HBase и Solr, которые при необходимости могут быть запущены встроено совместно с Atlas (режим embedded).
Автоматизировать захват метаданных из любых компонентов своей инфраструктуры (написать свой процесс) и далее наполнять ими Atlas - задача не требующая больших вложений.
Инструменты, которые заменяют SQL рисованием: SAS Data Integration Studio, Informatica, Pentaho — почти всегда плохо:
Частично или полностью недоступен Git: сравнение, слияние, версионность джобов и т.д.
Ограничения на автогенерацию.
Вендор-лок.
не совсем
1) GIT - и да, и нет. Деплой джоба (сам исполняемый код) всегда можно помещать в гит и там смотреть что изменилось, но читабельность конечно уступает стандартному sql. Cмотреть, что изменилось в самой визуальной части джоба (квадратики) действительно невозможно гитом, но это невозможно будет и через рисование sql.
2) Автогенерить джобы сложнее - да, но ограничнений нет. Нужно копать в недокументированный код - сужает легкость порога вхождения
3) Да
При этом есть и плюсы:
1) Если переносить все на sql, то есть специфики, например, для постгреса важно запускать все в виде небольших иструкций, а не хранимых процедур. Чтобы это реализовать, нужно все равно делать обертку, и возможно писать свой ETL таким образом.
2) Возможности авто визуального восприятия и анализа зависимостей - тут действительно грубо говоря sql рисование, но должно быть продвинутым, чтобы отследить атрибутный маппинг нужно прямо заморочиться серьезно с рисованием, если рисовать его по фактической реализации, а не по документации.
Для небольшого проекта действительно не стоит брать SAS DIS и вендорные аналоги.
Для большого - нужно понимать сколько трудозатрат уйдет на создание своего аналога.
Из open source есть AirFlow, есть DBT. AirFlow не позволяет производить анализ, что и где используется - это просто набор скриптов исполняемых (хранимые процедуры, питон и тд)
Похоже я поспешил =). Не заметил последнее условие с OR, которое важно.
Да запрос написан логически корректно =)
Да, запрос она переписала. Это и значит справляется? Вас убедило то, что запрос теперь написан иначе? Вы не станете его проверять? В этом и проблема!
Но вы надеюсь понимаете, что SQL запрос, предложенные ИИ дает, неверный ответ? Или мне нужно подробно расписать, где в нем допущены логические ошибки?
-
Вот более реалистичный запрос. Про нюансы мне пришлось специально уточнять, тк сеть даже не попыталась об этом задуматься и в первом варианте ответа это не учитывала. Клиент ничего не покупавший в 2022 году также подходит под условие "сделал меньше 3х покупок".
Запрос, который выдала сеть, дает АБСОЛЮТНО некорректный результат.
Более того она не осознает, что при наличии условия 2, условие 1 является избыточным, заведомо усложняя запрос и создавая лишнюю нагрузку на БД.
Так же клиент, который что-то купил в феврале или марте 2023, ничего не покупавший в 2022 году, не попадет в выборку, а логически по условию должен - ответ "клиент не покупал ноутбуки в сентябре" тоже часть статистики. Боюсь представить что выдала бы сеть, если бы я и эту часть попытался уточнить)
.
Проблематика в степени доверия. Почему я должен быть уверен, что этот ИИ даст мне правильный ответ, корректные данные из БД, корректным образом обработанные? Как принимать решения по этим данным?
Вот простейшая задача, на который генерируется с виду правильный ответ, но по факту на реальных данных даст абсолютно неверное решение.
Интеграцию с DBT тоже для себя в первую очередь отметил и увидел в этом шанс еще больше отказаться от документации =)
OMD появилась сравнительно недавно - первые полноценные устойчивые релизы во второй половине 2021 году.
Потребность в Data Catalog появилась раньше - мы начали внедрять Atlas в 2020
Про тяжеловесность - скорее ложное впечатление.
Основные вложения как технических специалистов так и аналитиков / методологов будут на этапе проектирования (какую модель данных для себя выбрать, в какие процессы и как именно встроить работу с инструментом) и внедрения решения.
На этапе поддержки и сопровождения потребуется минимум затрат технических специалистов - я бы оценил до 20% FTE.
Хорошо продуманный, внедренный и контролируемый процесс работы с Atlas гарантирует, что работа аналитиков/ методологов и дата стюардов будет сопоставима с трудоазтартами при работе с другими инструментами документирования (WORD, EXCEL, WIKI, GIT, jupiter notebook и пр).
OpenMatadata - многообещающий и интересный по архитектуре и функционалу продукт. Сам к нему присматриваюсь и планирую в ближайшие недели пилотировать.
Что привлекает:
Архитектура кажется проще (в том числе технологически) в сравнение с DataHub
Встроенные профилирование и DQ (простенький)
Версионирование метаданных (!)
Data Lineage до столбцов (появится летом в релизе 0.11)
Открытые JSON модели метаданных - близко по духу к ATLAS и задел на гибкость
PULL/PUSH наполнение метаданных. Развитый REST API
Плотная интеграция с DBT, вплоть до вывода исполняемого кода в интерфейс. В современных платформах данных DBT встречается все чаще как инструмент трансформации данных.
Разметка текста - базовая, но в Atlas даже такого нет.
Социальные функции - владельцы данных, комментирование, упоминания, доска актваности etc
Зачатки системы нотификации об изменениях - webhook, к которому можно приладить свое приложение для красивой доставки нотификации
Есть конечно подозрение, что часть функционала в варианте из коробки окажется слишком упрощенной, ограниченной, недостаточной для конкретных нужд.
Почему я часто говорю про важность гибкости инструмента к настройке и кастомизации, в том числе подразумевая простоту архитектурного решения, чтобы без капитальных трудозатрат доделать продукт под себя.
Спасибо за мнение. Было бы интересно посмотреть на ваш подход к сравнению и результаты. По функциональности из коробки, да, DataHub кажется выигрывает.
У меня нет полноценно практического опыта использования DataHub.
Изучая документацию и доступное демо, сложилось следующее сугубо личное мнение:
+ Владение данными, профиль пользователя (статистика)
+ Вроде есть базовый функционал по профилированию данных и простенькие отчеты по статистике использования. Не до конца понял где доступно (для каких интеграций) и как работает.
+ Развитое документирование карточки метаданных - есть отдельная вкладка для описания с разметкой текста.
+ Большой спектр доступных интеграций, PULL и PUSH механизмы наполнения каталога данными.
- При этом интерфейс кажется перегружен и вызывает эстетическую неприязнь.
- Нет Data Lineage до столбцов (есть где-то roadmap). Не понравилось как отображается Data Lineage - каждый уровень нужно принудительно раскрывать, а в текстовом списке доступны не все уровни зависимости в части Lineage (Impact доступен)
- Не до конца понятно, возможно ли кастомизировать модели метаданных, на сколько возможно (сложно) кастомизировать процессы вытягивания метаданных (интеграции)
- Архитектура показалась усложненной, стек примененных технологий - обширный. Похоже на наследие внутренней корпоративной кухни LinkedIn где продукт рождался. Задача "доработать под себя" может оказаться крайне затруднительной.
Да, максимально органично Atlas встраивается в Hadoop экосистему и присутствует в составе дистрибутивов от ArenaData, Cloudera и HortonWorks.
Но про прибитось Atlas к Hadoop не соглашусь. Для работы из экосистемы Hadoop Atlas нужны только HBase и Solr, которые при необходимости могут быть запущены встроено совместно с Atlas (режим embedded).
Автоматизировать захват метаданных из любых компонентов своей инфраструктуры (написать свой процесс) и далее наполнять ими Atlas - задача не требующая больших вложений.
Инструменты, которые заменяют SQL рисованием: SAS Data Integration Studio,Informatica, Pentaho — почти всегда плохо:
Частично или полностью недоступен Git: сравнение, слияние, версионность джобов и т.д.Ограничения на автогенерацию.Вендор-лок.не совсем
1) GIT - и да, и нет. Деплой джоба (сам исполняемый код) всегда можно помещать в гит и там смотреть что изменилось, но читабельность конечно уступает стандартному sql. Cмотреть, что изменилось в самой визуальной части джоба (квадратики) действительно невозможно гитом, но это невозможно будет и через рисование sql.
2) Автогенерить джобы сложнее - да, но ограничнений нет. Нужно копать в недокументированный код - сужает легкость порога вхождения
3) Да
При этом есть и плюсы:
1) Если переносить все на sql, то есть специфики, например, для постгреса важно запускать все в виде небольших иструкций, а не хранимых процедур. Чтобы это реализовать, нужно все равно делать обертку, и возможно писать свой ETL таким образом.
2) Возможности авто визуального восприятия и анализа зависимостей - тут действительно грубо говоря sql рисование, но должно быть продвинутым, чтобы отследить атрибутный маппинг нужно прямо заморочиться серьезно с рисованием, если рисовать его по фактической реализации, а не по документации.
Для небольшого проекта действительно не стоит брать SAS DIS и вендорные аналоги.
Для большого - нужно понимать сколько трудозатрат уйдет на создание своего аналога.
Из open source есть AirFlow, есть DBT. AirFlow не позволяет производить анализ, что и где используется - это просто набор скриптов исполняемых (хранимые процедуры, питон и тд)