Оригинал: https://medium.com/zs-associates/my-data-governance-framework-c1879486bc09

За последние 10+ лет у меня была возможность быть автором или внести вклад в более чем 100 стратегий и фреймворков управления данными в различных отраслях. Хотя у каждой организации есть свои уникальные вызовы, я обнаружил, что определенный общий фреймворк неизменно служил эффективной отправной точкой для внедрения управления данными.

Установление четкого фреймворка на раннем этапе имеет решающее значение. Оно проясняет, что такое управление данными и чем оно не является, помогая избежать путаницы, задать ожидания и стимулировать внедрение. Хорошо структурированный фреймворк предоставляет простое, повторяемое визуальное представление, которое вы можете использовать снова и снова, чтобы объяснить управление данными и то, как вы планируете внедрить его во всей организации.

В этой статье я разберу пять основных компонентов моего личного фреймворка, предоставив практический подход, который может работать для любой организации, в любом секторе.

Стратегия

Четко определенная стратегия является основой любой успешной инициативы по управлению данными. Она устанавливает цель, направление и приоритеты усилий по управлению, обеспечивая соответствие бизнес-целям. Без четкой стратегии усилия по управлению данными станут фрагментированными и реактивными.

• Миссия, видение и общая стратегия.** Этот подкомпонент определяет, почему необходимо управление данными, чего оно стремится достичь и как оно будет реализовано. Миссия формулирует основную цель управления, такую ​​как обеспечение целостности данных, соответствие требованиям и создание ценности. Видение обеспечивает долгосрочную перспективу, описывая желаемое состояние управления данными внутри организации. Общая стратегия определяет подход и руководящие принципы для внедрения управления в бизнес-операции.
• Задачи и цели.** Чтобы добиться значимых результатов, управление данными должно быть связано с измеримыми целями. Это включает в себя установление конкретных, количественно определяемых целей, таких как улучшение показателей качества данных на определенный процент, снижение рисков соответствия требованиям или увеличение внедрения метаданных. Четкие цели обеспечивают подотчетность и позволяют организациям отслеживать прогресс, демонстрировать ценность и постоянно совершенствовать свои усилия по управлению.

Области компетенции

Для эффективного внедрения управления данными организации должны разработать набор основных областей компетенции, которые касаются политик, процессов и структур, необходимых для управления данными. Эти области компетенции служат строительными блоками управления, обеспечивая охват всех критических аспектов – от качества данных до безопасности. Четко определенный набор компетенций гарантирует, что усилия по управлению являются взаимоисключающими и коллективно исчерпывающими (MECE), избегая пробелов или избыточности.

• Политики, стандарты и соответствие требованиям.** Управление начинается с четко определенных политик и стандартов, которые устанавливают правила, руководящие принципы и требования соответствия для управления данными во всей организации. Политики определяют, что необходимо сделать, устанавливая ожидания в отношении таких тем, как доступ к данным, качество и защита, а стандарты определяют, как эти ожидания реализуются с помощью конкретных процедур или пороговых значений. Важно отметить, что управление должно также включать возможность подтверждения соответствия этим политикам и стандартам посредством механизмов мониторинга, отчетности и аудита, обеспечивая подотчетность и соответствие нормативным требованиям.
• Управление данными.** Может показаться немного странным иметь «управление данными» в качестве компетенции в рамках управления данными, но оно служит уникальной и основополагающей цели. Эта компетенция определяет и реализует роли, обязанности и подотчетность во всей модели управления. Она обеспечивает организационную основу, которая поддерживает все другие компетенции, разъясняя, кто отвечает за принятие каких решений и деятельность, как назначается право собственности и как координируется деятельность по управлению между бизнесом и ИТ. Это включает в себя определение владельцев данных, распорядителей, руководителей доменов, путей эскалации и форумов по управлению.
• Метаданные и каталогизация.** Метаданные – данные о данных – необходимы для понимания, организации и управления информационными активами. Эта компетенция сочетает в себе управление метаданными с инструментами каталогизации и обнаружения данных для предоставления централизованного инвентаря активов данных, включая бизнес-определения, технические метаданные и происхождение данных. Управление метаданными также включает в себя определение минимальных стандартов метаданных, установление того, какие метаданные необходимо собирать и поддерживать, и где. Каталог данных строится на этой основе, делая метаданные доступными для поиска и доступными, позволяя пользователям находить, понимать и доверять данным, с которыми они работают. Это способствует прозрачности и демократизации данных, позволяя большему количеству пользователей в организации получать доступ к необходимым им данным.
• Архитектура данных.** Эта статья посвящена фреймворку управления данными, а не архитектуре предприятия или фреймворку архитектуры решений. Таким образом, роль архитектуры данных здесь конкретно ограничена теми аспектами, которые пересекаются с управлением данными. Сюда входит обеспечение того, чтобы посредством программ изменений, процессов проектирования решений и механизмов архитектурного управления правильные средства контроля и соображения по управлению данными были встроены на раннем этапе жизненного цикла новых систем, потоков данных и процессов. Это соответствие имеет решающее значение, поскольку отдача от инвестиций в управление данными значительно выше, когда оно внедряется на этапе проектирования, а не когда средства контроля управления ретроспективно устанавливаются после создания и развертывания систем. Таким образом, архитектура данных становится фактором, способствующим устойчивому управлению данными в масштабах предприятия в соответствии с политикой.
• Управление качеством данных.** Высококачественные данные являются основой надежной аналитики, искусственного интеллекта, нормативной отчетности и повседневных бизнес-операций. Эта компетенция охватывает ряд действий, которые обеспечивают соответствие данных цели, и ее обычно можно разбить на несколько различных областей. Во-первых, она начинается с понимания данных и формулирования четких бизнес-требований – какие данные необходимы, на каком уровне точности, своевременности или полноты и для какой цели. После установления этих требований организации могут обеспечить, чтобы правильные средства контроля качества данных были встроены в операционные процессы для предотвращения проблем в источнике (например, правила проверки в формах или автоматические проверки в каналах данных). Отдельная, но тесно связанная компетенция фокусируется на измерении самого качества данных, используя определенные метрики и методы профилирования для оценки данных по отношению к бизнес-требованиям. Кроме того, компетенция качества данных может включать в себя управление проблемами: структурированный процесс для выявления, документирования, отслеживания и устранения проблем с данными. Это позволяет организациям не только реагировать на проблемы с данными, но и анализировать основные причины и внедрять долгосрочные улучшения, обеспечивая надежность данных с течением времени.
• Мастер-данные и справочные данные.** Управление мастер-данными и справочными данными управляет основными бизнес-сущностями данных (например, клиентами, продуктами, поставщиками), чтобы устранить дублирование, повысить согласованность и обеспечить единый источник истины. Во многих организациях эта компетенция поддерживается платформой управления мастер-данными (MDM). Платформа MDM обеспечивает централизованные рабочие процессы, создание золотой записи, сопоставление данных и синхронизацию между системами. Она играет решающую роль в обеспечении согласованности, целостности и точности данных, особенно для общекорпоративной отчетности и обработки транзакций.
• Безопасность данных.** Безопасность данных обеспечивает защиту конфиденциальных, критически важных и регулируемых данных от несанкционированного доступа, неправильного использования или раскрытия в соответствии с политиками управления и схемами классификации данных. Это включает в себя внедрение и мониторинг контроля доступа на основе ролей, шифрование, токенизацию, маскирование, протоколы безопасной передачи данных и разделение обязанностей. Эффективное управление безопасностью данных также гарантирует, что меры безопасности соответствуют утвержденным политикам использования данных и регулярно тестируются и подтверждаются посредством проверок соответствия требованиям и оценок рисков.
• Этика и конфиденциальность.** Технически, эту область можно интерпретировать как подпадающую под действие “Политики, стандарты и соответствие требованиям”, поскольку многие этические требования и требования конфиденциальности в конечном итоге регулируются посредством формальной политики. Однако часто стоит выделять их отдельно из-за их растущей актуальности и заметности – особенно с ростом искусственного интеллекта, алгоритмического принятия решений и усилением нормативного контроля. Эта компетенция фокусируется на обеспечении ответственного, справедливого и прозрачного использования данных путем определения этических принципов, практик конфиденциальности, процессов управления согласием и стратегий защиты персональных данных. Учитывая, насколько централизованными стали доверие и подотчетность в организациях, движимых данными, рассмотрение этики и конфиденциальности как отдельных компетенций помогает обеспечить, чтобы она получала необходимую видимость, право собственности и ресурсы.
• Грамотность в области данных и культура.** Управление – это не только контроль, или не должно быть. Речь также идет о том, чтобы предоставить людям возможность эффективно и ответственно использовать данные. Эта компетенция способствует повышению грамотности в области данных, снабжая бизнес-пользователей и технических пользователей обучением, знаниями и инструментами, необходимыми им для интерпретации, доверия и действий на основе данных. Она включает в себя информационные кампании, образовательные ресурсы, передовые методы и поддержку самообслуживания для развития культуры, основанной на данных, во всей организации.

Адаптация фреймворка

Области компетенции, описанные выше, оказались хорошей отправной точкой в каждом проекте, в котором я участвовал. Но у каждой организации есть свой собственный контекст, операционная модель, приоритеты и история, и в результате я часто трачу значительное время с клиентскими организациями на доработку этого списка, чтобы он наилучшим образом соответствовал их уникальной ситуации. Ниже приведены некоторые из наиболее распространенных аспектов, по которым адаптируется модель компетенции:

• Безопасность данных и архитектура данных** иногда явно не выделяются как часть фреймворка компетенции управления данными. Во многих организациях они рассматриваются как ответственность ИТ-функции или функции технологий, и предполагается, что соображения управления встроены в более широкие процессы архитектурного управления и управления безопасностью.
• Грамотность в области данных** иногда переименовывается или перефразируется, называя ее управлением изменениями, расширением возможностей данных, пропагандой данных или продвижением данных. Во всех случаях основная цель, которая заключается в расширении возможностей пользователей и развитии культуры, основанной на данных, остается очень похожей.
• Этика и конфиденциальность** иногда полностью встроены в более широкую компетенцию “Политики, стандарты и соответствие требованиям”, особенно когда этические принципы и принципы конфиденциальности уже формально кодифицированы посредством политических инструментов. В этих случаях основное внимание уделяется пониманию соответствующих нормативных требований (например, GDPR, HIPAA или законов, связанных с искусственным интеллектом), преобразованию их в действенные политики и стандарты, а затем обеспечению соответствия посредством структур управления, обучения и механизмов надзора.
• Некоторые организации проявляют интерес к выделению возможности искусственного интеллекта или аналитики в качестве отдельной компетенции или управлению ими (“Управление искусственным интеллектом”). Лично я считаю, что большая часть того, что требуется для обеспечения надежной аналитики и искусственного интеллекта, может и должна обрабатываться с помощью существующих компетенций. Тем не менее, небольшое число организаций, с которыми я работал, предпочли рассматривать это как отдельную компетенцию, особенно когда управление моделями искусственного интеллекта/машинного обучения является текущим приоритетом.

Реализация (внедрение и исполнение)

В то время как стратегия и области компетенции управления данными в основном универсальны, реализация управления может значительно варьироваться между организациями, отраслями и нормативной средой. Этот компонент фокусируется на том, как управление структурировано, встроено и введено в действие в организации. Речь идет о том, как вы “делаете” управление – как вы стимулируете исполнение на местах.

Эта часть фреймворка в некоторой степени уникальна для моего личного взгляда на управление данными. В то время как большинство организаций определяют управление через список компетенций или столпов, они не доходят до интеграции того, как управление фактически реализуется. Я намеренно включаю его как часть основного фреймворка, потому что я считаю, что без четкого пути к исполнению и внедрению управление рискует остаться теоретическим. Встраивание реализации непосредственно во фреймворк усиливает то, что управление должно быть действенным, прожитым и встроенным в повседневные операции, а не просто набором добрых намерений.

То, как вы думаете о реализации, может варьироваться, но я обычно выделяю два основных компонента: роли и домены. Определение ролей (таких как владельцы данных или распорядители) помогает прояснить, кто за что несет ответственность, и обеспечивает согласованность во всей организации. Определение доменов (таких как данные о клиентах, продуктах или финансах) помогает структурировать управление вокруг логических бизнес-группировок. Вместе эти компоненты обеспечивают подход к управлению данными, ориентированный на домен, а это означает встраивание обязанностей по управлению в бизнес-области, которые лучше всего знают данные, и выполнение управления в контексте, а не изолированно.

• Основные роли и обязанности**

Право собственности и подотчетность могут быть разъяснены с помощью определенного набора ролей. Хотя в управлении данными участвует много ролей, приведенные ниже представляют собой некоторые из наиболее важных ролей, которые обычно повторяются в разных доменах данных:

• Владельцы доменов.** Несут ответственность за надзор за управлением в пределах определенного бизнес-домена, такого как данные о клиентах, финансы или продукты. Они помогают расставлять приоритеты в усилиях, обеспечивают соответствие бизнес-целям и несут ответственность за успех управления в своем домене.
• Владельцы данных.** Несут ответственность за качество, безопасность и жизненный цикл конкретных данных (или наборов данных). Они принимают решения об использовании данных, доступе к ним и критических требованиях к управлению.
• Распорядители данных.** Обычно работают от имени владельцев данных или доменов, выполняя большую часть повседневной работы, связанной с управлением данными. Это включает в себя обеспечение соблюдения стандартов, ведение метаданных, поддержку инициатив по качеству данных и координацию решения проблем.
• Владельцы систем.** Несут ответственность за технические системы и платформы, где данные хранятся, обрабатываются или передаются. Они обеспечивают, чтобы требования к управлению были встроены в архитектуру, средства контроля и уровни доступа этих систем.
• Владельцы бизнес-процессов.** Обеспечивают интеграцию политик управления и стандартов данных в бизнес-процессы, которые собирают, создают или изменяют данные. Они помогают встроить управление в операционные рабочие процессы и проектирование процессов.
• Домены данных**

Управление может применяться в значимых бизнес-контекстах, известных как домены данных. Эти домены определяют логические группировки данных на основе того, как они используются в организации. Хотя конкретные домены будут различаться в зависимости от отрасли (следовательно, эта часть фреймворка обязательно является пользовательской), следующие примеры иллюстрируют, как розничная компания может структурировать свои домены данных:

• Клиент** – Информация о физических или юридических лицах, которые покупают или используют ваши продукты или услуги.
• Продукт** – Информация о предлагаемых товарах или услугах, в том числе структура, цены и описания.
• Поставщик** – Информация о поставщиках, их контрактах и результатах их деятельности.
• Финансовый** – Записи о доходах, расходах, бюджетах и других финансовых транзакциях.
• Сотрудник** – Информация о персонале, в том числе роли, вознаграждение и история отдела кадров.
• Продажи** – Данные о покупках, транзакциях и деятельности, приносящей доход.
• Запасы и цепочка поставок** – Отслеживает уровни запасов, перемещение товаров и процессы доставки.
• Маркетинг и кампании** – Захватывает кампании, расходы на рекламу и стратегии таргетинга.
• Соответствие требованиям и нормативным требованиям** – Данные, используемые для выполнения юридических, аудиторских и нормативных обязательств.
• Цифровая и веб-аналитика** – Измеряет, как пользователи взаимодействуют с цифровыми платформами и веб-сайтами.

Технологическое обеспечение

Технологии играют решающую роль в том, чтобы сделать управление данными практичным и масштабируемым. Хотя эти технологии соответствуют ключевым областям компетенции управления данными, они не сопоставляются 1:1, поскольку многие компетенции поддерживаются более широкими технологическими стеками или интегрированными решениями. Кроме того, то, как организации структурируют и развертывают эти технологии, может значительно варьироваться в зависимости от их размера, отрасли и зрелости данных.

Тем не менее, в большинстве случаев технологии, связанные с управлением данными, можно сгруппировать по следующим ключевым категориям.

• Платформа управления данными.** Эти платформы позволяют организациям определять и управлять правом собственности на данные, обязанностями по управлению, рабочими процессами и утверждениями, а также облегчают операции управления, такие как ведение журналов проблем, запросы на изменение данных и подтверждение. Все чаще они также поддерживают управление проблемами на основе рабочих процессов, позволяя организациям назначать, отслеживать и решать проблемы управления данными между командами. Эти инструменты служат основой для того, чтобы сделать управление действенным и видимым в разных доменах.

• Примеры: Collibra, Informatica Axon, Alation Stewardship Workbench
• Качество данных.** Обеспечение высокого качества данных требует специализированных инструментов мониторинга, профилирования, очистки и исправления. Эти решения выявляют несоответствия, отсутствующие значения и ошибки, позволяя командам исправлять проблемы с данными в режиме реального времени и обеспечивать соблюдение стандартов качества данных в разных системах.

• Примеры: Informatica Data Quality, Talend, Ataccama ONE
• Каталог данных и наблюдаемость.** Каталоги данных предоставляют центральный инвентарь активов данных, объединяя метаданные, происхождение и бизнес-определения для повышения обнаружения и прозрачности данных. Все чаще каталоги объединяются с инструментами наблюдаемости данных для мониторинга работоспособности, свежести и поведения данных в режиме реального времени. Некоторые инструменты также предлагают автоматическое сканирование и классификацию данных по всему ландшафту данных.

• Примеры: Alation, Collibra, BigID
• Управление мастер-данными.** Платформы MDM необходимы для управления основными бизнес-сущностями, такими как клиенты, продукты и поставщики. Эти инструменты поддерживают сопоставление данных, создание золотой записи, рабочие процессы проверки и синхронизацию мастер-данных в разных системах. Они являются ключом к обеспечению согласованности в масштабах предприятия, удалению дубликатов и единому источнику истины для ключевых доменов данных.

• Примеры: Informatica MDM, Reltio
• Решения для обеспечения безопасности данных.** Эта категория включает в себя инструменты, которые управляют контролем доступа, шифрованием, маскированием, токенизацией и безопасной передачей данных. Она также поддерживает рабочие процессы запросов на доступ к данным, гарантируя, что только авторизованные пользователи могут получить доступ к конфиденциальным или классифицированным данным на основе политик управления и классификации данных.

• Примеры: Immuta, Privacera, Microsoft Purview Data Security
• Мониторинг этики, конфиденциальности и соответствия требованиям.** Эти инструменты поддерживают обеспечение соблюдения и мониторинг этичного использования данных, правил конфиденциальности (например, GDPR, HIPAA) и внутренних политик. Они предоставляют возможности для управления правами субъектов данных, отслеживания согласия, контрольных журналов и мониторинга использования, которые имеют решающее значение для укрепления доверия и выполнения нормативных обязательств.

• Примеры: BigID, OneTrust, Collibra Protect

При создании этой части фреймворка вы можете заменить общие категории фактическими инструментами и платформами, которые вы используете, например, перечислив Collibra вместо “платформы управления данными” или Informatica Data Quality вместо “инструментов качества данных”. Это обеспечивает более ощутимое, специфичное для организации представление о том, как конкретные технологии обеспечивают ключевые возможности.

Управление управлением данными

Чтобы управление данными работало, ему необходима четкая координация, постоянный надзор и устойчивый прогресс. Именно этим и занимается управление управлением данными – обеспечение того, чтобы остальная часть фреймворка действительно была реализована. Это придает структуру тому, как все части работают вместе, и привлекает людей к ответственности.

• Политики и стандарты**

Политики и стандарты являются основой управления данными. Они определяют правила, ожидания и обязанности, как правила дорожного движения на дороге. Все остальное во фреймворке указывает на них. Политики задают направление, а стандарты воплощают его в жизнь:

• Политика** говорит, что необходимо сделать. Это четкое правило, например, “данные о клиентах должны быть защищены”.
• Стандарт** говорит, как это сделать. Он дает подробности, например, “зашифруйте данные о клиентах и храните их в течение 3 лет”.
• Форумы управления**

Форумы управления обеспечивают необходимый надзор, координацию и структуры принятия решений для управления данными. Хотя конкретные форумы зависят от структуры организации и потребностей в управлении, к распространенным типам относятся:

• Совет по управлению корпоративными данными.** Центральный орган, который устанавливает стратегическое направление, решает межфункциональные вопросы и обеспечивает соответствие управления бизнес-целям.
• Форумы управления данными, ориентированные на домен.** Группы, которые осуществляют надзор за управлением в пределах конкретных доменов данных (например, клиенты, финансы, продукты), обеспечивая реализацию политик на уровне домена и эскалируя критические вопросы на корпоративный уровень.
• Региональные форумы управления или форумы управления бизнес-подразделением.** В глобальных или децентрализованных организациях управление данными может быть структурировано по региональному, бизнес-подразделению или дивизионному признаку для учета местных требований, нормативных различий и операционных потребностей.
• Рабочие группы, ориентированные на конкретные компетенции.** Некоторые организации учреждают группы управления, ориентированные на конкретные компетенции, такие как качество данных, управление метаданными, безопасность данных или этика данных, для продвижения передовых методов и технической реализации.
• Метрики и измерение производительности**

Чтобы продемонстрировать эффективность и влияние управления данными, организации должны отслеживать ключевые показатели эффективности (KPI), такие как показатели качества данных, показатели соблюдения политик, время решения проблем управления и внедрение метаданных. Эти метрики помогают обосновать инвестиции, выявить пробелы и стимулировать постоянное совершенствование.

• Управление изменениями**

Чтобы управление было по-настоящему встроено, вы можете повышать осведомленность, внедрять и изменять поведение, например, с помощью программ обучения, коммуникационных стратегий и инициатив по вовлечению.

Заключение

Надежный фреймворк управления данными обеспечивает ясность, структуру и повторяемый, масштабируемый подход к управлению данными. Хотя путь управления каждой компании уникален, фреймворк, представленный в этой статье, служит проверенной отправной точкой – той, которая может быть адаптирована в соответствии с любой отраслью, любой организацией и любым уровнем зрелости данных.

Оригинал тут: https://blog.bacalhau.org/p/distributed-data-warehouse-with-bacalhau

Это часть 5-дневной серии о Bacalhau 1.7

День 1: Анонс Bacalhau 1.7.0: Расширение возможностей предприятий за счет улучшенной масштабируемости, управления заданиями и поддержки
День 2: Масштабирование вычислительных задач с помощью разделенных заданий Bacalhau
День 3: Упрощение безопасности: Облегчение модели аутентификации Bacalhau
День 4: Использование разделения AWS S3 с Bacalhau

Это пятая часть – Распределенное хранилище данных с Bacalhau и DuckDB

Во многих приложениях, полагающихся на хранилища данных, необходимо хранить источники данных в разных местах. Это может быть связано с соображениями конфиденциальности, нормативными требованиями или желанием обрабатывать данные ближе к источнику. Однако бывают случаи, когда необходимо проводить анализ этих источников данных из одного места, не перемещая данные.

В этой статье Bacalhau используется для организации распределенной обработки, а DuckDB предоставляет возможности SQL-хранения и запросов для некоторой фиктивной информации о продажах, расположенной в ЕС и США.

Предварительные требования

Для воспроизведения этого руководства вам понадобятся следующие компоненты:

• Bacalhau CLI
• Docker и Docker Compose
• Пример многорегиональной настройки:

git clone https://github.com/bacalhau-project/examples.git

Архитектура

Пример файла Docker Compose и определения заданий Bacalhau в репозитории примеров имитируют следующую архитектуру:

• Оркестратор Bacalhau:** Центральная панель управления для распределения заданий
• Вычислительные узлы:** Распределены по регионам, работают близко к данным
• Региональное хранилище:** Региональные хранилища данных, использующие MinIO в этой настройке
• DuckDB:** Механизм SQL-запросов, работающий на каждом вычислительном узле. Bacalhau использует пользовательский образ, который добавляет несколько определяемых пользователем функций для помощи в разделении больших наборов данных между узлами на основе следующих методов:
  • `partition_by_hash`: Равномерное распределение файлов по разделам
  • `partition_by_regex`: Разделение на основе шаблонов
  • `partition_by_date`: Разделение на основе времени

Вы можете найти более подробную информацию о том, как работают эти функции, в документации по пользовательскому образу.
Вы можете увидеть настройку каждого компонента в файле Docker Compose. Создайте архитектуру, выполнив следующую команду:

docker compose up -d

Файл Docker Compose использует несколько файлов конфигурации Bacalhau, которые вы можете увидеть в папке configuration, где вычислительные узлы помечены как узлы US и EU соответственно.

Они также настраивают узлы оркестратора для записи данных в региональные бакеты MinIO.

Создание образцов данных

После того, как вы создали имитацию инфраструктуры, вы можете создать образцы данных, используя задание генератора данных, чтобы записать 3000 записей в каждый регион в формате JSON в соответствующий бакет MinIO.

Перейдите в каталог заданий

cd ../jobs

Сгенерируйте данные для США:

bacalhau job run -V Region=us -V Events=3000 \
-V StartDate=2024-01-01 -V EndDate=2024-12-31 \
-V RotateInterval=month data-generator.yaml

Сгенерируйте данные для ЕС:

bacalhau job run -V Region=eu -V Events=3000 \
-V StartDate=2024-01-01 -V EndDate=2024-12-31 \
-V RotateInterval=month data-generator.yaml

Доступ к данным для анализа

Bacalhau поддерживает два способа доступа к региональным данным:

• Источники ввода Bacalhau**

InputSources:
    - Type: s3
      Source:
        Bucket: local-bucket
        Key: "data/*"

Этот метод предоставляет больше контроля, параметров предварительной обработки и поддерживает другие типы источников, помимо S3.

• Прямой доступ DuckDB**

SET VARIABLE files = (
    SELECT LIST(file)
    FROM partition_by_hash('s3://local-bucket/**/*.jsonl')
    );
    SELECT * FROM read_json_auto(getvariable('files'));

Этот метод проще и привычнее для заданий, использующих только SQL. Определения заданий также используют SQL-запросы для обработки данных из источника ввода.

Выполнение анализа

После размещения данных вы можете отправлять задачи анализа в виде заданий Bacalhau. В каждом случае, после запуска задания используйте `

bacalhau job describe <job_id>

`, чтобы увидеть результаты задания, передав идентификатор задания из вывода команды `

bacalhau job run

`. Во всех примерах показано использование данных из США. Вы также можете изменить `Region` на `eu`, чтобы увидеть результаты из региона ЕС.

• Анализ месячных трендов**

bacalhau job run -V Region=us monthly-trends.yaml

Определение задания.

Пример вывода:

month      | total_txns | revenue | unique_customers | avg_txn_value
------------|------------|----------|------------------|---------------
2024-03-01 | 3,421      | 178,932  | 1,245            | 52.30
2024-02-01 | 3,156      | 165,789  | 1,189            | 52.53
2024-01-01 | 2,987      | 152,456  | 1,023            | 51.04

• Оперативный мониторинг**

• Hourly Operations (Почасовые операции)
  • Отслеживает метрики работоспособности
  • Контролирует процент успешных транзакций
  • Показывает почасовые закономерности

bacalhau job run -V Region=us hourly-operations.yaml

• Anomaly Detection (Обнаружение аномалий)
  • Идентифицирует необычные паттерны
  • Использует статистический анализ
  • Отмечает значительные отклонения

bacalhau job run -V Region=us anomaly-detection.yaml

• Бизнес-аналитика**

• Product Performance (Эффективность продукта)
  • Анализирует эффективность категорий
  • Отслеживает долю рынка
  • Показывает паттерны продаж

bacalhau job run -V Region=us product-performance.yaml

• Monthly Trends (Месячные тренды)
  • Долгосрочный анализ трендов
  • Месячные агрегации
  • Ключевые бизнес-показатели

bacalhau job run -V Region=us monthly-trends.yaml

• Анализ клиентов**

• Customer Segmentation (Two-Phase) (Сегментация клиентов (Двухфазная))
  • Фаза 1: Вычисление локальных метрик
  • Фаза 2: Объединение и сегментация
  • Запустите Фазу 1

bacalhau job run -V Region=us customer-segments-phase1.yaml

• Запомните ID задания и запустите Фазу 2

bacalhau job run -V Region=us -V JobID=<phase1-job-id> customer-segments-phase2.yaml

Итог

В этой статье объединены распределенные вычислительные мощности Bacalhau с гибкими возможностями SQL DuckDB для создания распределенного хранилища данных, разнесенного по регионам. Примеры заданий Bacalhau предоставляют ряд аналитических задач, от оперативного мониторинга до сегментации клиентов, при этом данные остаются в исходном месте и используются запросы SQL к данным, хранящимся в S3-совместимых бакетах.

Перевод: Внедрение и оптимизация Apache DolphinScheduler в NetEase Mail

Оригинал: https://apachedolphinscheduler.substack.com/p/netease-mails-migration-journey-to

В связи с бурным развитием Интернета, электронная почта — один из важнейших инструментов обмена информацией — испытывает постоянно растущий спрос на обработку данных и планирование задач. NetEase Mail, ведущий поставщик услуг электронной почты в Китае, внедрил платформу DolphinScheduler, чтобы лучше справляться с задачами обработки огромных объемов данных и планирования задач. Компания провела углубленное внедрение и оптимизацию платформы в реальных условиях эксплуатации.

Докладчик:

Лэй Баосинь, инженер больших данных NetEase Mail

Предпосылки проекта и выбор платформы

NetEase Mail – это ведущий китайский поставщик услуг электронной почты, являющийся частью крупной интернет-компании NetEase. Вот основные характеристики и информация о компании:

* Широкая линейка продуктов: NetEase Mail предлагает разнообразные почтовые услуги, включая:
* Бесплатная почта: Наиболее известные сервисы 126.com и 163.com, хорошо известные в Китае.
* Корпоративная почта: Предназначена для бизнеса, предлагая более надежные и профессиональные решения.
* VIP-почта: Почтовые сервисы премиум-класса с расширенными функциями и поддержкой.
* Долгая история: Существует с 1997 года, что говорит о стабильности и накопленном опыте.
* Огромная база пользователей: Благодаря популярности сервиса в Китае, NetEase Mail обслуживает миллионы пользователей.
* Технологическая зрелость: NetEase Mail активно использует современные технологии (например, Kubernetes, Apache DolphinScheduler и Streampark) для обработки больших объемов данных, планирования задач и улучшения общей эффективности.
* Ориентация на стабильность и безопасность: Компания уделяет большое внимание предоставлению стабильных, безопасных и эффективных почтовых услуг.
* Инновационное развитие: NetEase Mail постоянно совершенствует свои сервисы, внедряя новые функции, интегрируя искусственный интеллект и оптимизируя инфраструктуру.
* Вклад в opensource: NetEase Mail активно контрибьютит в open-source проекты, например, SeaTunnel, что говорит об их технической экспертизе и желании делиться разработками с сообществом.

В целом, NetEase Mail – это авторитетный и инновационный поставщик услуг электронной почты в Китае, отличающийся широким спектром услуг, ориентацией на стабильность и безопасность, а также активным применением передовых технологий.

История развития NetEase Mail

С момента запуска в 1997 году, NetEase Mail прошла несколько важных этапов развития, эволюционировав от 126 Mail, 163 Mail до Mail Master, постоянно расширяя линейку продуктов и спектр услуг. Сегодня NetEase Mail создала диверсифицированную бизнес-систему, включающую бесплатную почту, корпоративную почту, VIP-почту и многое другое, предоставляя стабильные, безопасные и эффективные услуги электронной почты огромному количеству пользователей.

*Из рисунка выше видно, что NetEase Mail внедрила Apache DolphinScheduler в 2023 году.*

Сценарии применения данных

В ежедневной работе NetEase Mail необходимо обрабатывать огромные объемы данных журналов бизнес-операций. Эти данные требуют постоянного холодного и горячего резервного копирования в течение более полугода, а журналы бизнес-операций обрабатываются и хранятся отдельно как в автономном режиме (HDFS), так и в режиме реального времени (ClickHouse). В то же время, для обеспечения доступности бизнеса, критически важные звенья, такие как основные механизмы отправки/получения электронной почты и аутентификации пользователей, требуют эффективной обработки данных и поддержки планирования задач.

Предпосылки выбора и преимущества DolphinScheduler

Столкнувшись с постоянно растущими потребностями в обработке данных, команда NetEase Mail сравнила несколько платформ планирования задач с открытым исходным кодом. DolphinScheduler выделился благодаря поддержке различных механизмов планирования, высокой стабильности, простоте использования и богатой функциональности. Он способен поддерживать различные сценарии работы с данными, отвечая сложным и разнообразным требованиям NetEase Mail к планированию задач.

Развертывание платформы и текущее использование

Путь обновления и преобразования на основе DS

После внедрения платформы DolphinScheduler, команда NetEase Mail встала на путь непрерывной оптимизации и обновления. Начиная с предварительных исследований и сравнений при выборе платформы, затем решая проблемы, возникающие в процессе использования, и, наконец, выполняя вторичную разработку для постоянного улучшения простоты использования и пользовательского опыта, команда неустанно двигалась к совершенствованию платформы. После подтверждения выбора в марте 2023 года, первоначальная трансформация на основе функциональности оповещения была завершена в декабре 2023 года, а к марту 2024 года была достигнута стабильная работа и продолжающиеся исследования.

Архитектура данных и текущее использование

В настоящее время в отделе NetEase Mail платформа DolphinScheduler развернута в архитектуре 3 Master, 5 Worker и работает на Kubernetes (k8s). Платформа поддерживает более 1200 автономных задач планирования для таких сервисов, как защита от спама, контроль рисков, AI и многого другого, с ежедневным количеством запусков, превышающим 50 000.

*На уровне архитектуры данных, благодаря интеграции DolphinScheduler с Streampark, было достигнуто сочетание автономного планирования и обработки задач Flink в режиме реального времени. Между тем, самостоятельно разработанные компоненты, такие как центр метаданных и портал данных, формируют уровень обслуживания данных, обеспечивая поддержку управления данными и сервисов.*

Внедрение платформы значительно повысило эффективность разработки данных, снизило затраты на эксплуатацию и обслуживание и обеспечило стабильный вывод бизнес-данных, тем самым оказывая сильную поддержку быстрой итерации и инновациям в бизнесе.

Типы задач и поддержка приложений

Платформа DolphinScheduler стала основной платформой планирования задач внутри отдела, предлагая широкий спектр типов задач, включая Spark, Shell, SQL, SeaTunnel, Python и многое другое. Эти задачи обеспечивают надежную поддержку данных для нисходящих приложений, таких как управление метаданными, отчеты BI и исследования и разработки данных, удовлетворяя потребности в обработке данных в различных бизнес-сценариях.

Интеграция функциональности распространения данных и методы оптимизации

Интеграция функциональности распространения данных

Что касается планирования и распространения данных, команда NetEase Mail выявила несколько проблем, которые необходимо было решить для повышения эффективности и возможностей обработки данных, в том числе:

• Частые запросы на обработку данных:** Частые запросы на обработку данных от персонала, не занимающегося исследованиями и разработками, требуют поддержки разработчиков данных.
• Низкая готовность к созданию промежуточных таблиц:** Команды разработчиков продуктов и контроля качества демонстрируют небольшую готовность к созданию промежуточных таблиц, поскольку это занимает много времени.
• Существуют пороги в конфигурации синхронизации данных:** Конфигурация задач синхронизации данных между гетерогенными источниками данных представляет определенные пороги, требующие специализированной поддержки разработки данных.
• Процесс разработки задач синхронизации относительно длинный:** Полный процесс разработки задач синхронизации данных является длительным, включая такие шаги, как создание таблиц, создание конфигурации синхронизации и создание задач планирования.

Чтобы решить эти проблемы, команда NetEase Mail интегрировала функциональность распространения данных в платформу DolphinScheduler.

*Общий подход – это создание промежуточных таблиц + генерация конфигурации задач синхронизации + создание задач планирования, что повышает эффективность обработки промежуточных данных и обеспечивает комплексный процесс для построения задач обработки данных.*

Эта функциональность предлагает два режима — быструю конфигурацию и пользовательскую конфигурацию. Она может автоматически генерировать операторы DDL таблицы на основе параметров формы и выполнять логику создания таблицы, одновременно генерируя SQL для промежуточной обработки и конфигурации задач синхронизации данных, и, наконец, вызывать внутренние методы Dolphin для создания рабочих процессов и задач планирования.

В результате внедрения этой функциональности среднее время обработки промежуточных данных сократилось с 1 часа до 20 минут, что увеличило эффективность разработки на 67%, и она уже поддерживает более 40 онлайн-задач обработки данных, при этом количество пользователей постоянно растет.

Оптимизация методов автономного планирования для повышения отказоустойчивости

Исходный механизм планирования, при обработке сбоев зависимых задач, приводил к непосредственному сбою зависимых узлов, делая невозможным повторный запуск незавершенной цепочки данных одним щелчком мыши. Это увеличивало операционную нагрузку на разработчиков данных и увеличивало время восстановления после сбоев.

Чтобы решить эту проблему, команда переработала логику обработки сигналов ожидания и сбоев в методе getModelDependResult класса DependentExecute в модуле dolphinscheduler-master. Когда статус зависимой задачи — FAILED, статус в dependResultList изменяется на WAITING, чтобы нижестоящие задачи получали статус WAITING, а не FAILED.

Эта оптимизация позволяет восстанавливать и повторно запускать цепочку данных одним щелчком мыши, снижая затраты на ручное вмешательство, повышая эффективность и интеллектуальность восстановления цепочки задач, ускоряя скорость восстановления цепочки данных после сбоев и обеспечивая своевременное восстановление и вывод бизнес-данных.

Интеграция и оптимизация компонентов SeaTunnel, повышение эффективности синхронизации данных

Чтобы удовлетворить потребности в крупномасштабной синхронизации данных для нового бизнеса, команда внедрила инструмент интеграции данных SeaTunnel и развернула его в кластере Kubernets (k8s) в режиме разделенного кластера.

За счет оптимизации плагинов SeaTunnel NetEase Mail предлагает как пользовательские, так и быстрые режимы конфигурации, тем самым снижая порог использования.

Принцип реализации

С точки зрения реализации, решение поддерживает как конфигурацию на основе форм, так и пользовательскую конфигурацию. Режим конфигурации на основе форм генерирует логику взаимодействия для конфигурации SeaTunnel (ST) через параметры формы и поддерживает конфигурацию дополнительных пользовательских параметров, а также конфигураций JVM на уровне задач.

Бэкэнд получает параметры формы для генерации необходимой конфигурации для контекста выполнения задачи. Он разрабатывает интерфейс IConfigGenerator для реализации логики генерации Source и Sink для каждого источника данных, и, наконец, класс SeatunnelConfigGenerator используется для генерации окончательной конфигурации ST.

Развертывание и настройка

Что касается развертывания и настройки, то кластер SeaTunnel использует архитектуру 2 Master, 5 Worker для обеспечения высокой доступности и производительности синхронизации.

За счет оптимизации логики сегментирования для HDFS, HIVE и MultiTable Source, считыватель получает более сбалансированные сегменты, что повышает производительность синхронизации данных. Соответствующие оптимизации были отправлены в виде PR в сообщество.

С точки зрения настройки параметров, в ответ на требование крупномасштабной синхронизации данных из HDFS в Doris, после исследования и настройки параметров кода DorisSink была достигнута скорость передачи данных в 2 миллиона записей в секунду, что значительно повысило производительность синхронизации данных.

Практический пример проекта: перенос задач и практика изоляции ресурсов

Эффективная миграция задач с платформы Mammoth на DolphinScheduler

Платформа Mammoth – это программное обеспечение платформы больших данных, разработанное для внутреннего использования в NetEase Group, и некоторые зависимости между задачами Mammoth очень сложны, требуя анализа и организации. Если это делать вручную, эффективность будет низкой, и, вероятно, возникнут пропуски или ошибки.

В конце концов, после изучения представления зависимостей задач на платформе DolphinScheduler, было решено перейти на DolphinScheduler.

Что касается выбора метода миграции, то если бы был принят ручной подход к миграции, он был бы не только трудоемким и отнимающим много времени, но и подвержен ошибкам миграции из-за сложности зависимостей задач, что повлияло бы на общую стабильность задач.

Исходя из различных соображений, после обсуждения и исследований NetEase Mail решила принять решение об автоматизированном решении синхронизации. Это решение автоматически собирает метаданные задач и lineage задач со старой платформы, преобразует их в формат конфигурации задач платформы Dolphin и одновременно добавляет зависимости задач. Наконец, рабочие процессы быстро создаются через интерфейс Dolphin. Для достижения этого процесса NetEase Mail использовала инструмент синхронизации PyDolphinScheduler, официально предоставляемый DolphinScheduler — Python API, который позволяет определять рабочие процессы с использованием кода Python, а именно, “workflow as code”.

Кроме того, NetEase Mail также собирала метаданные и lineage задач Mammoth через систему метаданных, пакетно переписывала задачи Mammoth в задачи DolphinScheduler и автоматически добавляла узлы зависимостей в соответствии с lineage.

Эта практика эффективно завершила перенос более 300 задач Mammoth, обеспечив плавный бизнес-переход, достигнув массовой миграции одним щелчком мыши, значительно сэкономив затраты на рабочую силу и предоставив ценный опыт для аналогичных сценариев миграции задач в будущем.

Практика изоляции групп Worker

Следующая практика проекта — это практика изоляции ресурсов на основе группировки Worker в DolphinScheduler.

В повседневном использовании платформы NetEase Mail DolphinScheduler ключевым бизнес-сценарием является поддержка задач планирования онлайн-мониторинга QA. Эти задачи характеризуются высокой частотой планирования, в основном на уровне минут; существует большое количество задач, при этом количество задач, связанных с мониторингом, в настоящее время достигает 120+.

Выполнение этих задач планирования мониторинга в настоящее время в основном достигается с помощью типа задачи SHELL путем вызова самостоятельно разработанного jar-пакета инструмента обработки задач ETL. Этот jar-пакет предоставляет дополнительные функциональные возможности во время выполнения задачи, такие как проверки идемпотентности, повторные попытки по таймауту и т.д.

Однако этот вид вызова запустит множество процессов JVM на рабочих узлах (worker nodes). В это время, если некоторые критически важные задачи планирования также запланированы на тот же рабочий узел, и OOM killer запускается из-за нехватки памяти, эти критически важные задачи, как правило, имеющие более высокое использование памяти, могут получить более высокий балл OOM и с большей вероятностью будут завершены, что приведет к нестабильному выполнению критически важных задач.

Кроме того, для выполнения некоторые задания синхронизации Т+1 на следующее утро требуют большого количества ресурсов и не подходят для планирования на том же узле, что и другие задания, что может повлиять на производительность и стабильность выполнения других заданий на том же работнике.

Поэтому команда NetEase Mail рассматривала возможность использования решения для изоляции Worker group для решения вышеуказанных проблем.

Благодаря изоляции групп Worker команда отделила высокочастотные задачи планирования, такие как мониторинг в режиме реального времени, от других задач, обеспечив стабильное выполнение основных графиков, связанных с OKR, и повысив общую стабильность и надежность выполнения задач.

На практике NetEase Mail создала на платформе различные группы Worker, содержащие различные узлы Worker, включая такие группы, как Default, AI, Monitoring, Hadoop и группы задач с большими ресурсами, чтобы избежать проблем блокировки задач и состязания за ресурсы, оптимизировать распределение ресурсов и повысить общую утилизацию ресурсов и производительность платформы.

Эта практика эффективно решила такие проблемы, как блокировка задач, вызванная высокой частотой планирования задач мониторинга QA, и проблемы OOM узла worker, вызванные высоким запросом ресурсов задачами Т+1 рано утром, тем самым снизив операционные риски.

Итоги и перспективы

Резюме практики

Внедрив платформу DolphinScheduler и проведя серию мероприятий по развертыванию и оптимизации, команда NetEase Mail достигла значительных результатов в повышении эффективности разработки данных, снижении эксплуатационных затрат и обеспечении стабильного вывода бизнес-данных. Вторичная разработка платформы тесно связана с бизнес-потребностями, подчеркивая повышенное удобство для пользователя и эффективность разработки, в то время как команда постоянно сосредотачивается на оптимизации и улучшении платформы и активно вносит вклад в сообщество, стимулируя постоянное развитие платформы.

Значение и преимущества платформы

Платформа DolphinScheduler играет важную роль в бизнесе NetEase Mail. Она не только повышает эффективность и стабильность разработки данных, но и удовлетворяет разнообразные потребности бизнеса за счет оптимизированных процессов планирования задач, обеспечивая своевременный вывод данных и активно способствуя устойчивому развитию почтового бизнеса.

Обмен опытом и идеями

В процессе развертывания и оптимизации платформы команда NetEase Mail накопила богатый практический опыт. Этот опыт представляет собой важную справочную ценность для других предприятий при выборе и использовании платформ планирования задач. Команда подчеркивает, что вторичная разработка должна быть тесно интегрирована с фактическими бизнес-потребностями, всегда уделяя первоочередное внимание пользовательскому опыту и эффективности разработки. В то же время постоянная ориентация на оптимизацию и улучшение платформы и активное участие в построении сообщества с открытым исходным кодом может стимулировать постоянное совершенствование и развитие платформы.

Перспективы на будущее

Заглядывая в будущее, команда NetEase Mail планирует продолжить изучение и продвижение в следующих направлениях:

• Внедрение ИИ:** Интеграция возможностей ИИ и LLM для достижения более интеллектуальных и удобных для пользователя процессов ETL обработки данных, повышая уровень автоматизации и интеллектуализации обработки данных.
• Управление данными:** Интеграция данных планирования DolphinScheduler с внутренним центром метаданных для достижения интеллектуального сбора и анализа lineage данных/задач и карт данных, обеспечивая сильную поддержку управления данными.
• Оптимизация платформы:** Дальнейшая оптимизация производительности и функциональности платформы DolphinScheduler для повышения ее стабильности и надежности, что позволит лучше удовлетворять растущие потребности в обработке данных.
• Внедрение DATA OPS:** Достижение интеграции и консолидации между платформой DolphinScheduler и другими системами платформ данных, содействие автоматизации интеграции и передачи данных, а также построение более эффективной экосистемы данных.

В заключение

Практика развертывания и оптимизации NetEase Mail на основе платформы DolphinScheduler не только решила существующие проблемы планирования задач и обработки данных, но и заложила прочный фундамент для будущего развития. Благодаря постоянным технологическим инновациям и практическим исследованиям NetEase Mail продолжит предоставлять пользователям более качественные и эффективные услуги электронной почты, а также вносить больший вклад в развитие сообщества с открытым исходным кодом.

DataHub 1.0 уже здесь! Получите максимальную отдачу от нового UX

00:00:00 Введение и анонсы

• Приветствие участников и анонс гостей.
• Мэгги расскажет об обновлении дорожной карты DataHub.
• Паулина и Анна представят новый UX DataHub 10.
• Харшел из команды DataHub поделится новостями от Block.
• Шершанка, технический директор и соучредитель, подведет итоги.

00:01:01 Анонс DataHub 10

• Анонс DataHub 10 и ссылки на блог и видеоролики.
• Видео о начале проекта DataHub.

00:02:33 Важность DataHub

• DataHub как важный компонент инфраструктуры.
• Переход на DataHub и отключение собственного инструмента lineage.
• Расширение модели DataHub для поддержки элементов данных.

00:04:11 Обновления дорожной карты DataHub

• Мэгги рассказывает о последних обновлениях DataHub.
• Четыре столпа: открытие, управление, метаданные и наблюдаемость.
• Фокус на открытии данных и интеграции с новыми инструментами.

00:05:09 Открытие данных

• Фокус на человеко-ориентированном понимании данных.
• Интеграция с новыми инструментами, такими как MLflow и Cockroach DB.
• Разработка новых интеграций, включая Hex и Vertex AI.

00:07:32 Управление данными

• Введение иерархической родословной для упрощения графиков.
• Расширение поддержки терминов в глоссарии.
• Обеспечение всеобщего доступа к данным и централизованного соответствия требованиям.

00:10:52 Наблюдаемость данных

• Обеспечение доступности и демократизация качества данных.
• Централизованное отслеживание и разрешение инцидентов.
• Улучшения в утверждениях и расширенный поток инцидентов.

00:12:53 Основные направления проекта

• Фокус на API и SDK для автоматизации регистрации, обогащения и поиска данных.
• Важность качества обслуживания и аудита ведения журнала.
• Улучшение отслеживаемости событий в центре обработки данных.

00:13:40 Пакет SDK для Python

• Работа над улучшением пакета SDK для Python версии 2.
• API для регистрации, обогащения и извлечения данных.
• Вклад в документацию для улучшения понимания улучшений.

00:14:42 Учетные записи служб

• Внедрение учетных записей служб для команд.
• Управление автоматизацией и рабочими процессами.
• Призыв к обратной связи и сотрудничеству.

00:15:41 Будущие обновления и DataHub Cloud

• Опрос о будущих обновлениях DataHub и DataHub Cloud.
• DataHub Cloud как управляемый сервис с дополнительными возможностями.
• Переход к повестке дня и представлению UX-дизайнеров.

00:16:47 Дизайн продуктов в DataHub

• Инвестиции в дизайн продуктов в DataHub.
• Важность дизайна для инноваций и постоянного совершенствования.
• Использование данных и отзывов пользователей для улучшения продукта.

00:18:44 Принципы дизайна

• Философия дизайна: простота, обратная связь, последовательность.
• Создание системы проектирования в Figma и Storybook.
• Внедрение токенов и принципов для компонентов.

00:19:43 Примеры изменений

• Изменения в цветах и стилях кнопок и диаграмм.
• Введение специальных дизайнерских жетонов.
• Постепенные обновления пользовательского интерфейса.

00:20:54 Панель навигации и структурированные свойства

• Улучшение панели навигации для удобства пользователей.
• Гибкость отображения структурированных свойств.
• Постоянное совершенствование продукта на основе отзывов пользователей.

00:23:37 Введение и принципы последовательности

• Обсуждение предварительных просмотров вкладки “Стоп”.
• Введение в принципы согласованности и последовательности.
• Создание графической библиотеки для визуализации данных.

00:24:02 Итеративность и визуализация данных

• Итеративный процесс создания графических элементов.
• Примеры различных диаграмм и их эволюция.
• Переход от высокой плотности данных к более сжатым диаграммам.

00:25:46 Новые функции и панель вкладок

• Введение новой панели вкладок “Статистика”.
• Улучшение представления данных для пользователей.
• Демонстрация новых функций и взаимодействий.

00:28:27 Взаимодействие с пользователями

• Призыв к участию в исследовании пользователей.
• Важность обратной связи для улучшения продукта.
• Возможности участия в опросах и тестировании юзабилити.

00:31:19 Обнаружение данных с агентами ИИ

• Введение в тему обнаружения данных с агентами ИИ.
• Представление Сэма Осборна и его роли в компании Block.
• Обзор управления данными и блокчейна в компании.

00:32:39 Проблемы и перспективы управления данными

• Переход на облачный сервис Data Hub.
• Проблемы и возможности каталогизации данных.
• Введение агентов ИИ для улучшения управления данными.

00:34:33 Демонстрация работы с Cloud Desktop

• Cloud Desktop настроен для взаимодействия с LLM.
• Возможность задавать вопросы о данных, связанных с домашними животными.
• Программа ищет данные на сервере Data Hub и предоставляет резюме.

00:35:23 Анализ данных и ключевые показатели

• Программа ищет данные и предоставляет информацию о ключевых показателях.
• Возможность задавать дополнительные вопросы о профилях домашних животных.
• Программа показывает количество строк и активные инциденты.

00:37:05 Использование Slack и Data Hub

• Возможность использовать Slack для планирования изменений в Data Hub.
• Программа помогает определить, на какие данные повлияет изменение.
• Возможность узнать, кому нужно сообщить об изменениях.

00:38:38 Демонстрация работы с Goose

• Goose – агент искусственного интеллекта с открытым исходным кодом.
• Интеграция с локальной и удаленной системами через расширения.
• Пример использования для поиска данных и владельцев данных.

00:43:39 Демонстрация работы в среде IDE

• Проект DBT с использованием идентификатора на базе искусственного интеллекта.
• Возможность проверять изменения в Data Hub и их влияние.
• Программа помогает избежать проблем и обеспечивает безопасность.

00:45:59 Введение в агентов искусственного интеллекта

• Агенты организуют контекстное управление разговорами с LLM.
• Интеграция с системами через протокол MCP.
• Агенты взаимодействуют с LLM и внешними службами данных.

00:47:50 Модель контекстного протокола MCP

• MCP – открытый стандарт для использования данных и инструментов в контексте взаимодействия с ИИ.
• Охватывает аспекты запроса данных, вызова служб и чтения/записи информации.
• Может использоваться для конкретных случаев использования и внешних серверов.

00:48:41 Агенты и спецификация MCP

• Представлен агент искусственного интеллекта с открытым исходным кодом codename goose.
• Спецификация MCP выпущена компанией Anthropic и является стандартным протоколом для ИИ.
• Обсуждается сотрудничество с ACRIL и улучшения Python SDK для приложений ИИ.

00:49:45 Демонстрация и использование codename goose

• Codename goose поддерживает стандарт MCP и позволяет подключаться к различным моделям и поставщикам.
• Демонстрационное видео показывает, как codename goose помогает в выполнении различных задач и упрощении рабочих процессов.

00:50:12 Интеграция и улучшения

• Агенты, стандарты MCP и центр обработки данных помогают быстрее подключать пользователей и интегрироваться с внутренними службами.
• Обсуждаются улучшения Python SDK для поиска сущностей и lineage, оптимизированных для интеграции с ИИ.

00:51:16 Будущее MCP

• В спецификацию MCP добавлены элементы авторизации с помощью OAuth и элементы для выборки и потоковой передачи.
• Ожидается появление множества официальных и неофициальных серверов MCP для различных приложений и сервисов.

00:51:50 Философия Data Hub

• Спецификация MCP вписывается в философию Data Hub, подчеркивающую важность стандартов и переносимости.
• Внедряются стандарты Open Lineage, Iceberg REST Catalog и MCP Model для более эффективного взаимодействия с метаданными.

00:53:02 Рекомендации и советы

• Видео на YouTube и ресурсы на GitHub подробно рассказывают о стандарте MCP.
• Профессиональный совет: делайте сеансы короткими, обобщайте данные и записывайте их в текст для предотвращения разрыва контекстного окна.

00:53:57 Заключение

• Агенты искусственного интеллекта и центр обработки данных помогают в обнаружении данных.
• Проект codename goose и его интеграция с Data Hub являются важными шагами в развитии ИИ.

00:54:38 Введение и прогресс проекта

• Проект быстро развивается, появляются интересные функции.
• Все продемонстрированные элементы, кроме Slack, имеют открытый исходный код.
• Пользовательский интерфейс улучшается, версии 1 и 2 уже доступны.

00:55:50 Проблемы и решения центра обработки данных

• Центр обработки данных решает сложные проблемы в цепочке поставок данных.
• Включает производственные системы, системы преобразования данных и системы искусственного интеллекта.
• Цель – связать всю цепочку поставок данных и обеспечить недостающий контекст.

00:56:32 Важность контекста для различных ролей

• Потребители данных ищут доверие и доступность данных.
• Специалисты по обработке данных беспокоятся о своевременности и изменениях.
• Руководители команд следят за доступом и использованием данных.

00:57:25 Управление искусственным интеллектом

• Важно отслеживать данные, используемые моделями искусственного интеллекта.
• Управление искусственным интеллектом должно быть машинно-ориентированным.
• Понимание доступа моделей к персональным данным и автономных агентов.

00:59:16 Переход к машинно-ориентированному управлению

• Агенты будут действовать автономно, преобразовывать и создавать данные.
• Важно отслеживать действия агентов и гарантировать их правильность.
• Центр обработки данных помогает создавать контекст для машин и агентов.

01:00:53 Заключение и благодарности

• Благодарность участникам за участие и вопросы.
• Обещание предоставить запись и более подробную информацию.
• Призыв обращаться через Slack для дальнейших вопросов и обсуждений.

Казалось не очевидная задача, но победа случилась на второй день.

querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/me/ HTTP/1.1" 401 285 0.000000
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/login_method/ HTTP/1.1" 200 273 0.000000
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind TRY with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind SUCCESS with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_worker         | [2025-03-27 20:36:56,786: INFO/MainProcess] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] received
querybook_worker         | [2025-03-27 20:36:56,787: DEBUG/MainProcess] TaskPool: Apply <function fast_trace_task at 0x7fb3791b0d30> (args:('celery.local.sync_elasticsearch__debouncer', 'f407a87d-ae47-450b-95b1-c44df07eb1e7', {'lang': 'py', 'task': 'celery.local.sync_elasticsearch__debouncer', 'id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'shadow': None, 'eta': None, 'expires': None, 'group': None, 'group_index': None, 'retries': 0, 'timelimit': [None, None], 'root_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'parent_id': None, 'argsrepr': "['users', 1]", 'kwargsrepr': '{}', 'origin': 'gen100@6ede59afb0cf', 'ignore_result': False, 'properties': {'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'delivery_mode': 2, 'delivery_info': {'exchange': '', 'routing_key': 'celery'}, 'priority': 0, 'body_encoding': 'base64', 'delivery_tag': '2d6aecef-9aea-4564-9bd0-994731c8eba5'}, 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'hostname': 'celery@05a545667216', 'delivery_info': {'exchange': '', 'routing_key': 'celery', 'priority': 0,... kwargs:{})
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "POST /ds/login/ HTTP/1.1" 200 655 0.282608
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/me/ HTTP/1.1" 200 490 0.011824
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/setting/ HTTP/1.1" 200 215 0.020317
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/announcement/ HTTP/1.1" 200 215 0.011983
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query/transpile/ HTTP/1.1" 200 419 0.017954
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/user/notifiers/ HTTP/1.1" 200 348 0.018368
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query_execution_exporter/ HTTP/1.1" 200 215 0.023621
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:02] "GET /ds/user/environment/ HTTP/1.1" 200 233 5.029392
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /static/favicon/querybook.svg HTTP/1.1" 200 5544 0.017975
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_metastore/ HTTP/1.1" 200 215 0.010979
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/environment/ HTTP/1.1" 200 215 0.029958
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_engine/ HTTP/1.1" 200 215 0.017463
querybook_worker         | [2025-03-27 20:37:06,821: INFO/MainProcess] Task celery.local.sync_elasticsearch[185cb78a-0b66-47de-a3db-71e6bea1e53c] received
querybook_worker         | [2025-03-27 20:37:06,821: DEBUG/MainProcess] basic.qos: prefetch_count->6
querybook_worker         | [2025-03-27 20:37:06,823: INFO/ForkPoolWorker-3] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] succeeded in 5.021026143018389s: None
querybook_elasticsearch  | [2025-03-27T20:37:19,071][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Cancel background move metadata process.
querybook_elasticsearch  | [2025-03-27T20:37:19,073][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Performing move cluster state metadata.
querybook_elasticsearch  | [2025-03-27T20:37:19,074][INFO ][o.o.i.i.MetadataService  ] [d8d3bb7a5243] Move metadata has finished.

Мистер Дюк теперь может заходить в Querybook

Тот кто первый входит будет являться админом

Далее сделал конвектор к Trino и один eviroment, и добавил конектор в него и юзера

Можно писать запросики

Красивый прогресс

Тоже красиво

Работает и даже на русском.

PS: Откуда взялся Ldap?

Вот этот под руку попался https://github.com/intoolswetrust/ldap-server

Он на базе Apache Directory https://directory.apache.org/apacheds/downloads.html
Сделан как раз для тестов, то что нужно.

Вот так делаем:

docker pull kwart/ldap-server
docker run -it --rm kwart/ldap-server

Потом так:

../containers/bundled_querybook_config.yaml

AUTH_BACKEND: 'app.auth.ldap_auth' # Same as import path when running Python
LDAP_CONN: 'ldap://192.168.215.2:389'
LDAP_USER_DN: 'uid={},ou=Users,dc=ldap,dc=example'

И так

LDAP_CONN: "ldap://192.168.215.2:389"   #  без сертификатов, и так сойдет,  но они нужны и корневые особенно для ldaps. 
LDAP_USER_DN: "uid={},ou=Users,dc=ldap,dc=example"
LDAP_UID_FIELD: "uid"
LDAP_EMAIL_FIELD: "uid"  # У меня нет почты в ldap поэтому схитрил, но надо бы добавить атрибут mail в схему LDAP
LDAP_LASTNAME_FIELD: "sn"
LDAP_FIRSTNAME_FIELD: "cn"  # Используйте cn, если givenName отсутствует
LDAP_FULLNAME_FIELD: "cn"
LDAP_BIND_DN: "uid=admin,ou=system"
LDAP_BIND_PASSWORD: "secret"
LDAP_SEARCH_BASE: "dc=ldap,dc=example"

Теперь осталось придумать как всунуть туда hive matastore – это будет чуть сложнее, чем казалось.
Один всунуть можно, но одного мало, а много лень. Может сделать еще один как все и уже его одного добавлять? пока не знаю 🧐

Методы приоритизации задач: как эффективно управлять временем

Картинку стащил из паблика

Приоритизация задач — ключевой навык для повышения продуктивности как в профессиональной, так и в личной жизни. Визуальное руководство объединяет несколько популярных методов, которые помогают структурировать работу и фокусироваться на главном. Рассмотрим их подробнее.

---

1. Матрица Эйзенхауэра

Принцип: Задачи делятся на четыре категории по критериям срочности и важности:

• Срочные и важные (Do): требуют немедленного выполнения (например, кризисные ситуации).
• Важные, но не срочные (Schedule): планируются на будущее (стратегические цели, саморазвитие).
• Срочные, но не важные (Delegate): можно делегировать (рутинные задачи, ответы на письма).
• Несрочные и неважные (Delete): устраняются (бесцельный скроллинг соцсетей).

Пример:

• Do: Срочный отчет для клиента.
• Schedule: Планирование квартальной стратегии.
• Delegate: Ответы на стандартные запросы через ассистента.
• Delete: Просмотр развлекательных видео в рабочее время.

---

2. Time Blocking (Временные блоки)

Принцип: Рабочий день делится на отрезки времени, каждый из которых посвящен конкретной задаче. Это минимизирует многозадачность и повышает концентрацию.

Пример расписания на понедельник:

|Время|Задача|

|-----------|---------------------------|

|9:00–11:00|Глубокая работа (написание статьи).|

|11:00–12:00|Встречи с командой.|

|13:00–14:00|Обработка срочных задач.|

Совет: Используйте буферные периоды между блоками для переключения контекста.

---

3. Метод 3-3-3

Принцип: День делится на три части:

• 3 часа на глубокую работу (сложные проекты).
• 3 часа на выполнение срочных, но менее важных задач.
• 3 часа на рутинные дела (проверка почты, административные задачи).

Преимущество: Баланс между продуктивностью и поддержанием рабочего процесса.

---

4. ABCDE-метод

Принцип: Задачи ранжируются от A (наивысший приоритет) до E (можно исключить):

• A: Последствия невыполнения критичны (например, оплата счетов).
• B: Важно, но не срочно (планирование отпуска).
• C: Желательно, но не обязательно (оптимизация процессов).
• D: Можно делегировать (подготовка документов).
• E: Исключить (устаревшие задачи).

---

5. Moscow-метод

Принцип: Задачи сортируются по категориям:

• Must have: Без этого проект провалится (основной функционал).
• Should have: Важно, но не критично (дополнительные фичи).
• Could have: Желательные улучшения (улучшение UI).
• Won’t have: Откладывается на будущее.

Пример для разработки приложения:

• Must have: Регистрация пользователей.
• Should have: Интеграция с соцсетями.
• Could have: Анимированные переходы.

---

6. Принцип Парето (80/20)

Принцип: 20% усилий дают 80% результата. Фокусируйтесь на задачах с максимальной отдачей.

Пример:

• 20% клиентов приносят 80% прибыли → Уделяйте им больше внимания.
• 20% функций продукта определяют его успех → Сначала реализуйте их.

---

Итоговые рекомендации

1. Комбинируйте методы: Используйте матрицу Эйзенхауэра для ежедневной приоритизации и Time Blocking для планирования.
2. Регулярно пересматривайте задачи: Удаляйте или делегируйте то, что потеряло актуальность.
3. Избегайте перфекционизма: Согласно принципу Парето, иногда «достаточно хорошо» лучше, чем «идеально».

---

Визуальное сопровождение: На изображении, вероятно, представлены схемы матриц, примеры расписаний и диаграммы, иллюстрирующие распределение усилий по методам. Это помогает быстро усвоить концепции и применить их на практике.

Управление временем — это не про то, чтобы сделать больше, а про то, чтобы сделать правильные вещи. Выбирайте подходящие методы, экспериментируйте и оптимизируйте свой workflow!

🔗 Подробнее: [scottcaputo.com](https://scottcaputo.com)

Тестируем AI функции в Trino 474

Дока тут: https://trino.io/docs/current/functions/ai.html

Заводим конектор llm.properties

connector.name=ai
ai.provider=openai
ai.model=gpt-4o-mini
ai.openai.api-key=sk-XXXXXXa
ai.openai.endpoint= https://api.XXXXX/openai

немного конфига config.properties

sql.path=llm.ai

Пробуем:

SELECT ai_analyze_sentiment('Ai да заяц какой умный как утка только отруби не есть'); -- mixed
SELECT ai_analyze_sentiment('Ai да заяц какой умный'); -- positive

SELECT ai_classify('Buy fucking deep! and bitcoin', ARRAY['spam', 'not spam']); -- spam
-- spam

SELECT ai_classify('много денег', ARRAY['Хорошо', 'Плохо']); -- Хорошо

SELECT ai_classify('мало денег', ARRAY['Хорошо', 'Плохо']); -- Плохо

SELECT ai_fix_grammar('Пошёл я, значица, на рынок, там нашол один такой магазинчег, где продают всякие запчасти. Думал, прикуплю видюху крутую, чтобы всё летало. Смотрю - лежыт такая, блестит, вся из себя навороченая. Спрашиваю продавца: "Скока стоит эта красота?" А он мне такой цену заломил, у меня глаза на лоб полезли.');
-- Пошёл я, значит, на рынок, там нашёл один такой магазинчик, где продают всякие запчасти. Думал, прикуплю крутую видеокарту, чтобы всё летало. Смотрю - лежит такая, блестит, вся из себя навороченная. Спрашиваю продавца: "Сколько стоит эта красота?" А он мне такую цену назвал, что у меня глаза на лоб полезли.

SELECT ai_gen('Опиши что такое Москва коротко'); 
-- Москва — столица и крупнейший город России, расположенный в центральной части страны. Это политический, экономический и культурный центр, известный своими историческими памятниками, такими как Кремль и Красная площадь, а также современными skyscrapers. Город обладает развитой инфраструктурой, включая транспортную сеть, образовательные учреждения и театры. Москва также является одним из крупнейших мегаполисов мира с разнообразной культурой и многонациональным населением.

SELECT ai_mask(
    'Позвони мне быстро 987 554 32 11 или приходи ул. ленина 43 кв. 32,  скажи, что от Гаврилова Юры',
    ARRAY['телефон', 'Адрес',  'Имя']);
-- Позвони мне быстро [MASKED] или приходи [MASKED], скажи, что от [MASKED]

SELECT ai_translate('Буря мглою небо кроет,
Вихри снежные крутя;
То, как зверь, она завоет,
То заплачет, как дитя,
То по кровле обветшалой
Вдруг соломой зашумит,
То, как путник запоздалый,
К нам в окошко застучит.', 'en');

/*
The storm covers the sky with gloom,  
Whirling snowstorms twist and turn;  
Now, like a beast, it howls,  
Now it cries like a child,  
Now on the dilapidated roof  
Suddenly rustles with straw,  
Now, like a late traveler,  
It knocks at our window.
*/


SELECT name, address,comment, ai_classify(comment, ARRAY['Хорошо', 'Плохо', 'Можно помочь']), ai_translate(comment, 'ru') FROM tpch.sf1000.customer limit 10;

Customer#037500001	rLbDxR0mC,PwQ5QkxWCfXCC	tes; slyly regular pearls cajole quickl	Плохо	лжем; хитро обычные жемчужины уговаривают быстро
Customer#037500002	0bZ7K57TnmFs9goL41xTB64xBTLuXPtGPN	unusual, ironic pinto beans haggle across the regular req	Плохо	необычные, ироничные пинто фасоль торгуются по обычному запросу
Customer#037500003	5QliQMqzyz	ietly. deposits nag sometimes according to the even deposits. f	Плохо	тихо. депозиты иногда зависят от равномерных депозитов. f
Customer#037500004	FMm4JPC9UUSTOdfsfn	ect; slyly even packages haggle. pending inst	Плохо	ждут; хитро даже пакеты торгуются. в ожидании инст
Customer#037500005	a CUUBM75af0IX66Jm	unts are bold, unusual packages. fluffily unusual foxes nag furiously even deposits	Плохо	Унцы — это смелые, необычные пакеты. Пухово-необычные лисы яростно требуют даже депозиты.
Customer#037500006	VoXTOweLVJuiKe7xcn K69l7RoN61,	ar pinto beans haggle blithely. 	Можно помочь	Фасоль "пинто" торгуются беззаботно.
Customer#037500007	fUoQ2Fkssi94OhGGE1UetR w	ages hang blithely among the slyly ruthless accounts. carefully pen	Плохо	возрасты беззаботно свисают среди хитро безжалостных счетов. осторожно пишите
Customer#037500008	xogtDxejUq	 slyly special dependencies use quickly throughout the blithely stealthy accounts. depend	Можно помочь	Лукавые специальные зависимости используются быстро на протяжении безмятежных скрытных отчетов. зависеть
Customer#037500009	ou,BZuF,BMMeEoSUgyODRQZFQJyIsFQMSWp	en requests maintain. carefully ironic requests sleep carefull	Плохо	запросы поддерживают. осторожно ироничные запросы спят осторожно
Customer#037500010	lcP8JaVg2dz	y final packages. accounts along the quietly ironic ideas nag carefully idly express requests. requests detect 	Плохо	Итоговые пакеты. учетные записи вдоль тихо ироничных идей настойчиво и бездумно выражают запросы. запросы обнаруживают

При тестировании ни один заяц не пострадал, но вот hive и iceberg пришлось зарубить, там новые параметры для конфига. Так,что. придется их изучить при обновлении на новые версии, старые работать не будут.

а каталог iceberg я добавил так в итоге

connector.name=iceberg
fs.native-s3.enabled=true
s3.endpoint=https://gateway.storjshare.io
s3.region=us1
hive.metastore.uri=thrift://metastore:9083
hive.metastore.username=trino
hive.metastore.thrift.client.connect-timeout=1m
s3.path-style-access=true
s3.aws-access-key=XXXXX
s3.aws-secret-key=CCCCCCCCC
s3.socket-read-timeout=1m

iceberg.file-format=PARQUET
iceberg.compression-codec=SNAPPY
iceberg.target-max-file-size=128MB

но еще заметил эту багу https://github.com/trinodb/trino/issues/25427

перевод: https://www.openpioneers.com/p/the-state-of-open-source-llms

С возвращением в Open Pioneers #32.

Прошло несколько месяцев с момента моей последней рассылки. Жизнь и работа в Linux Foundation занимали много времени, но я поставил перед собой цель снова писать еженедельно, начиная с этого момента.

Я также использую этот перезапуск, чтобы кое-что изменить: помимо нового брендинга, я перешел с платформы Beehiiv на Substack для своей рассылки. Я также решил сделать контент более личным и углубляться в темы с открытым исходным кодом, которые мне интересны. Я по-прежнему буду рассказывать об альтернативах с открытым исходным кодом, объявлять о раундах финансирования или интересных вакансиях в секторе открытого исходного кода, но скорее в качестве побочного замечания.

Я почистил список подписчиков и оставил в нем только тех, кто регулярно открывал мои электронные письма, так как не хочу никому рассылать спам.

Тем не менее, я очень рад снова начать это делать. В сфере открытого исходного кода происходит так много интересного, и я с нетерпением жду возможности продолжать узнавать об этом вместе с вами!

Состояние открытых больших языковых моделей (LLM)

Большие языковые модели (LLM) с открытым исходным кодом превратились из нишевых академических проектов в устойчивые, управляемые сообществом платформы, которые бросают вызов проприетарным гигантам, таким как Microsoft или Google. Сегодня LLM с открытым исходным кодом не только способствуют прозрачности и сотрудничеству, но и обеспечивают более экономичный и адаптируемый подход к разработке искусственного интеллекта.

Новая эра товарного ИИ

Движение за открытый исходный код в области ИИ росло экспоненциально в течение последних нескольких лет. Вместо того чтобы полагаться исключительно на дорогие закрытые модели от крупных технологических компаний, разработчики и исследователи по всему миру теперь могут получать доступ к современным LLM, модифицировать и улучшать их. Эта коммодитизация имеет решающее значение для обеспечения доступности ИИ для всех, от независимых хакеров и стартапов до академических учреждений.

Последние разработки показали потенциал LLM с открытым исходным кодом. Например, китайская модель R1 от DeepSeek привлекла всеобщее внимание, поскольку она соответствует характеристикам ведущих моделей, таких как o1 от OpenAI, при этом обучаясь за небольшую часть стоимости и вычислительной мощности. Использование DeepSeek обучения с подкреплением и архитектуры “смесь экспертов” позволяет ей активировать только подмножество из своих 671 миллиарда параметров на запрос, тем самым снижая энергопотребление и требования к оборудованию.

Преимущества и проблемы LLM с открытым исходным кодом

LLM с открытым исходным кодом предлагают несколько убедительных преимуществ:

• Прозрачность и доверие:** Благодаря общедоступным данным обучения, исходному коду и весам моделей, LLM с открытым исходным кодом позволяют проводить тщательную проверку, что делает их менее “черным ящиком” по сравнению с проприетарными аналогами. Эта прозрачность приводит к доверию сообщества и совместному устранению неполадок.
• Низкие затраты:** Модели с открытым исходным кодом снижают барьер для входа. Экономическая эффективность открытого исходного кода особенно выгодна для академических учреждений и стартапов с ограниченными ресурсами – другими словами: это способствует инновациям.
• Настройка и гибкость:** Открытый доступ означает, что разработчики могут точно настраивать модели для нишевых приложений, интегрировать знания, специфичные для конкретной области, или даже адаптировать модели для местных языков – ключевое соображение для таких инициатив, какOpenEuroLLM, которая стремится обслуживать языковое разнообразие Европы.

Однако остаются и проблемы. LLM с открытым исходным кодом могут быть уязвимы для атак с использованием состязательных методов, и качество доступных данных обучения может варьироваться. Более того, хотя открытые модели способствуют инновациям, они также поднимают вопросы об ответственном использовании, поскольку мощные инструменты ИИ в чужих руках могут привести к злоупотреблениям. Баланс между открытостью и безопасностью – это продолжающийся разговор внутри сообщества, к которому мы должны отнестись серьезно.

Ключевые LLM с открытым исходным кодом, о которых вам следует знать

Ниже приведен снимок текущего ландшафта открытого исходного кода, согласно таблице лидеров Hugging Face Open LLM.

Следующие LLM с открытым исходным кодом выделяются для меня, потому что они очень часто смешиваются и сочетаются более широким сообществом ИИ:

• Llama 3.1 (Meta):** Серия Llama 3.1 от Meta — от небольших моделей до массивной версии с 405 млрд параметров — неизменно занимает высокие позиции в области генерации общего текста, многоязыковой обработки и задач кодирования.
• Mistral Large 2 (Mistral AI):** Благодаря мощной архитектуре с 123 миллиардами параметров и впечатляющему контекстному окну (до 128 тысяч токенов), Mistral Large 2 превосходно справляется как с пониманием языка, так и с задачами кодирования. Его разреженная конструкция “смесь экспертов” оптимизирует производительность при одновременном снижении затрат на вывод, что делает его лидером в эффективности и масштабируемости.
• DeepSeek R1 (DeepSeek):** Модель R1 от DeepSeek использует обучение с подкреплением и подход “смесь экспертов” для обеспечения конкурентоспособных возможностей рассуждения, математики и кодирования. Хотя DeepSeek предположительно использует менее сложное оборудование по сравнению со своими западными конкурентами (в США действует запрет на экспорт в Китай графических процессоров Nvidia), он достигает высокой производительности при небольшой доле затрат на обучение. Этот факт привел к множеству обсуждений, в том числе и в основных СМИ.
• DeepSeek v3 (DeepSeek):** Основываясь на серии R1, DeepSeek v3 использует архитектуру Mixture-of-Experts с 671 миллиардом параметров – с 37 миллиардами активированных параметров на токен – для обеспечения впечатляющей эффективности при генерации общего текста, многоязычной обработке и задачах кодирования.
• Qwen 2.5 (Alibaba):** Qwen 2.5 от Alibaba произвел фурор благодаря своим сильным многоязычным возможностям, специализированной производительности в области кодирования и математических рассуждений, а также эффективным стратегиям развертывания. Его компоненты с открытым исходным кодом выпущены под лицензией Apache 2.0.
• Falcon-180B (Technology Innovation Institute):** Модель Falcon-180B является свидетельством возможностей крупномасштабных LLM с открытым исходным кодом. Обученная на более чем 3,5 триллионах токенов, она обеспечивает первоклассную производительность по множеству тестов, что делает ее одной из самых конкурентоспособных доступных альтернатив с открытым исходным кодом. ( Вам потребуется примерно 8 видеокарт A100 с 80 ГБ памяти или эквивалентное оборудование для запуска этой модели )

Перспективы

Поскольку инвестиции в ИИ с открытым исходным кодом продолжают расти, такие игроки отрасли, как Meta, и общественные инициативы по всей Европе и за ее пределами удваивают ставки на потенциал совместной разработки ИИ. Благодаря тому, что компании выпускают свои модели под разрешительными лицензиями и делятся подробными техническими деталями и тестами, экосистема LLM готова к быстрым изменениям.

Большинство экспертов считают, что будущее ИИ будет построено на основе открытого исходного кода, где общие знания ускоряют инновации и приводят к более равноправному технологическому прогрессу.

Я думаю, что это будущее только началось.

Новые и популярные проекты с открытым исходным кодом 🔥

• Second Me:** Прототип с открытым исходным кодом, где вы создаете своего собственного “ИИ-клона”: новый вид ИИ, который сохраняет вас, передает ваш контекст и защищает ваши интересы. GitHub

• Cursor Talk to Figma MCP:** Model Context Protocol (MCP), позволяющий Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них. GitHub

На что способен MCP в области дизайна Cursor Talk to Figma MCP см. видео

• Classless.css:** Легкий CSS-фреймворк для веб-сайтов с безупречным вкусом, но без желания добавлять классы. GitHub

Раунды финансирования проектов с открытым исходным кодом 💸

• Supabase, альтернатива Google Firebase с открытым исходным кодом, привлекла $100 млн при оценке стоимости в $2 млрд. Ссылка
• AheadComputing, игрок из экосистемы RISC-V, объявила о посевном финансировании в размере $21,5 млн. Ссылка
• Rerun, создатели платформы для ведения журналов и визуализации мультимодальных данных, привлекли посевное финансирование в размере $17 млн под руководством PointNine. Ссылка
• Onyx, решение для корпоративного поиска с открытым исходным кодом, привлекло посевное финансирование в размере $10 млн под совместным руководством Khosla Ventures и First Round Capital. Ссылка
• Lingo.dev, создатели инструментария для локализации с открытым исходным кодом, привлекли $4,2 млн. Ссылка

Очень интересные проекты:

• [https://github.com/onyx-dot-app/onyx](https://github.com/onyx-dot-app/onyx)** – Помогите своей инженерной команде, службе поддержки, отделу продаж и команде эксплуатации продукта быстрее находить информацию. Искусственный интеллект с открытым исходным кодом, подключенный к документам, приложениям и сотрудникам вашей компании.

• [https://github.com/rerun-io/rerun](https://github.com/rerun-io/rerun)** – Визуализируйте потоки мультимодальных данных. Бесплатно, быстро, просто в использовании и легко интегрируется. Написано на Rust.

• [https://github.com/lingodotdev/lingo.dev](https://github.com/lingodotdev/lingo.dev)** – Фиксируйте. Переводите. AI-локализация для команд, которые быстро выпускают продукты. Переводите приложения, веб-сайты и целые базы данных, используя лучшие LLM-модели.

• [https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp](https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp)** – Этот проект реализует интеграцию Model Context Protocol (MCP) между Cursor AI и Figma, позволяя Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них.

https://github.com/n8n-io/n8n

n8n – Платформа для безопасной автоматизации рабочих процессов для технических команд
n8n – это платформа автоматизации рабочих процессов, которая предоставляет техническим командам гибкость кода со скоростью no-code. Благодаря 400+ интеграциям, встроенным возможностям AI и лицензии fair-code, n8n позволяет создавать мощные автоматизации, сохраняя при этом полный контроль над вашими данными и развертываниями.
Платформа автоматизации рабочих процессов с моделью Fair-code и встроенными AI-возможностями. Объедините визуальное построение с пользовательским кодом, разместите у себя (self-host) или в облаке, 400+ интеграций.
Ключевые возможности

Код, когда это необходимо: Пишите на JavaScript/Python, добавляйте npm-пакеты или используйте визуальный интерфейс.

AI-Native платформа: Создавайте рабочие процессы AI-агентов на основе LangChain, используя собственные данные и модели.

Полный контроль: Размещайте у себя (self-host) с нашей лицензией fair-code или используйте наше облачное предложение.

Готовность к работе в enterprise-среде: Расширенные разрешения, SSO и развертывания с “воздушным зазором” (air-gapped deployments).

Активное сообщество: 400+ интеграций и 900+ готовых к использованию шаблонов.

Развертывание с помощью Docker:

docker volume create n8n_data
docker run -it rm name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Получите доступ к редактору по адресу http://localhost:5678

скоро добавят MCP https://habr.com/ru/articles/893482/

Перевод: https://medium.com/adevinta-tech-blog/from-lakehouse-architecture-to-data-mesh-c532c91f7b61

От архитектуры data lakehouse к data mesh

В Adevinta мы верим в то, что данные являются продуктом, который позволяет принимать обоснованные решения и внедрять инновации во все наши бизнес-подразделения. Чтобы извлечь максимальную пользу из наших данных, нам необходимо предоставить нашим командам инструменты и инфраструктуру для обнаружения, доступа и анализа данных автономно. Наш путь к этой цели начался с централизованной архитектуры data lakehouse, и теперь мы переходим к более децентрализованной парадигме data mesh. В этой статье мы поделимся нашей мотивацией, этапами и решениями на этом пути.

От централизованного к децентрализованному: почему мы это делаем?

В начале у нас была централизованная команда данных, которая отвечала за сбор, обработку и обслуживание всех данных в организации. Мы построили data lakehouse на основе облачных хранилищ, таких как AWS S3, и движков обработки, таких как Spark и Databricks. Эта централизованная архитектура хорошо работала в начале, когда наши потребности в данных были относительно простыми.

Однако по мере роста Adevinta и увеличения сложности наших бизнес-операций централизованная архитектура стала узким местом. Централизованной команде данных было сложно удовлетворить разнообразные и меняющиеся потребности различных бизнес-подразделений. Существовали следующие проблемы:

• Медленная доставка:** Требования к данным должны были проходить через централизованную команду, что порождало задержки и снижало скорость итераций.
• Ограниченное владение:** Бизнес-подразделения имели небольшой контроль над данными, которые им были необходимы, что препятствовало инновациям и экспериментированию.
• Отсутствие масштабируемости:** Централизованной команде данных было сложно масштабировать свои операции, чтобы соответствовать растущему объему и сложности данных.

Чтобы преодолеть эти проблемы, мы решили перейти к архитектуре data mesh. Data mesh – это децентрализованный подход к управлению данными, который наделяет конкретные бизнес-подразделения (domain) ответственностью за их собственные данные. Каждое business domain владеет своими данными, разрабатывает и обслуживает свои конвейеры данных, а также предоставляет свои данные другим domain в виде продуктов данных.

Путь к Data Mesh: этапы и решения

Наш переход к data mesh является постепенным процессом, который включает в себя несколько этапов.

Шаг 1: Выявление и приведение в соответствие Domains:

Первым шагом было выявление основных domains в Adevinta, например, маркетинг, финансы, поиск и монетизация. Важно соответствие domains организационной структуре и то, что каждая domain имеет четкого владельца и понимание данных, за которые они несут ответственность.

Шаг 2: Объявление Domain Data Owners:

После определения domains нам нужно было назначить владельцев данных для каждой domain. Domain data owners являются владельцами данных, генерируемых их domain, и отвечают за качество, доступность и управляемость данных.

Шаг 3: Определение продукта данных:

Затем каждая domain должна определить свои продукты данных. Продукты данных – это переиспользуемые компоненты данных, предоставляющие ценность различным командам. Примеры продуктов данных включают агрегации данных, машинное обучение и отчетность.

Шаг 4: Создание самостоятельной платформы данных:

Чтобы дать возможность domains управлять своими данными, нам нужно было создать самостоятельную платформу данных. Платформа предоставляет инфраструктуру и инструменты, необходимые domains для создания, развертывания и обслуживания своих конвейеров данных. Платформа должна быть самообслуживаемой, надежной и безопасной.

В Adevinta мы опираемся на существующую инфраструктуру data lakehouse и развиваем ее для поддержки data mesh. Это включает в себя:

• Централизованный каталог данных:** Каталог данных предоставляет всем domains доступ к метаданным и схемам данных, позволяя им обнаруживать и понимать продукты данных, доступные в организации.
• Стандарты качества данных:** Централизованная команда данных поддерживает стандарты качества данных и политики, чтобы обеспечить высокое качество данных. Команды доменов несут ответственность за соблюдение этих стандартов и политик.
• Аутентификация, авторизация и аудит (AAA):** Централизованная AAA защищает доступ к данным и соответствие требованиям безопасности.
• Мониторинг и оповещения:** Платформа предоставляет централизованные панели мониторинга и оповещения, позволяющие domains проактивно отслеживать состояние и производительность своих конвейеров данных.

Шаг 5: Обучение, пропаганда и повторение:

Наконец, очень важно обучать и пропагандировать data mesh во всей организации. Нам нужно было убедиться, что все понимают принципы data mesh и преимущества, которые он приносит. Важно начинать с малого, повторять и учиться на наших ошибках.

Решения, которые нам необходимо было принять:

Переход к парадигме data mesh требует принятия ряда важных решений. Некоторые из наиболее серьезных из них включают в себя:

• Определение границ domain:** Критически важно определить границы каждого domain четким и однозначным образом. Это гарантирует, что каждая domain четко понимает данные, за которые она несет ответственность.
• Выбор технологии:** необходимо тщательно выбирать правильную технологию для data mesh. Платформа должна быть самообслуживаемой, надежной и безопасной.
• Управление изменениями:** Переход к data mesh требует значительных изменений в том, как организация относится к управлению данными. Важно справиться с этими изменениями эффективным образом.

Преимущества Data Mesh

Реализовав архитектуру data mesh, мы ожидаем получить следующие преимущества:

• Улучшенная скорость доставки:** domains могут самостоятельно разрабатывать и развертывать свои конвейеры данных, сокращая время, необходимое для предоставления новых продуктов данных.
• Повышенное владение:** domains имеют полный контроль над своими данными, что позволяет им внедрять инновации и экспериментировать с использованием данных.
• Улучшенная масштабируемость:** архитектура data mesh более масштабируема, чем централизованная архитектура, позволяя нам адаптироваться к растущему объему и сложности данных.
• Повышение качества данных:** domains лучше осведомлены о своих данных, что ведет к более высокому качеству данных.

Вывод

Переход от архитектуры data lakehouse к data mesh – это значительное изменение для Adevinta. Однако мы полагаем, что это необходимо для того, чтобы раскрыть весь потенциал наших данных. Наделив наши бизнес-domains ответственностью за их собственные данные, мы сможем ускорить инновации, принимать более обоснованные решения и, в конечном счете, лучше обслуживать наших клиентов. Этот путь является непрерывным процессом, и мы полны решимости сделать data mesh успешным в Adevinta.

Статья переведена с помощью gtp4o search preview – без доступа через VPN