#ApacheKafka #DataScience @BigDataSchool_ru
Тест по основам Kafka-топиков.
📨Кто отвечает за публикацию сообщений в топиках?
Тест по основам Kafka-топиков.
📨Кто отвечает за публикацию сообщений в топиках?
Anonymous Quiz
50%
message-брокер
47%
продюсеры
0%
консьюмеры
3%
Zookeeper
#Kafka #DataScience #статьи
🌊Для чего нужны потоки в Kafka и как они работают.
Потоки в Kafka — это неизменяемые коллекции данных, которые предназначены для добавления данных в топики Kafka.
Kafka-потоки также являются потоками фактов, где каждый факт представляет собой уникальное и неизменяемое событие (event). Данные потоков хранятся в виде структуры ключ-значение (key-value).
Создавать Kafka-потоки можно двумя способами:
1. с помощью библиотеки Kafka Streams
2. с помощью платформы KSQL
Каждый из этих способов мы подробно рассмотрим далее на практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-streams-building/
🌊Для чего нужны потоки в Kafka и как они работают.
Потоки в Kafka — это неизменяемые коллекции данных, которые предназначены для добавления данных в топики Kafka.
Kafka-потоки также являются потоками фактов, где каждый факт представляет собой уникальное и неизменяемое событие (event). Данные потоков хранятся в виде структуры ключ-значение (key-value).
Создавать Kafka-потоки можно двумя способами:
1. с помощью библиотеки Kafka Streams
2. с помощью платформы KSQL
Каждый из этих способов мы подробно рассмотрим далее на практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-streams-building/
Практические курсы по Apache Kafka для аналитиков, разработчиков, администраторов Big Data
Что такое потоки и как их создавать в Kafka
Что такое потоки и как их создать в Kafka: особенности потоковой обработки Big Data в распределенной среде - обучение Big Data для начинающих
#AirFlow #DataScience #VertexAI #статьи
💡Что такое Vertex AI Pipelines от Google.
Google Vertex AI — это новый набор инструментов для поддержки сквозного жизненного цикла ML-решений и MLOps-задач.
Он состоит из множества инструментов, включая Workbench, Feature Store, бессерверный конвейер Kubeflow, задания, эксперименты и отслеживание метаданных, реестр ML-моделей, конечные точки для развертывания их в онлайн, пакетные прогнозы и много других полезных функций.
Vertex AI интегрируется со многими открытыми ML-фреймворками, такими как TensorFlow, PyTorch и scikit-learn, а также поддерживает все среды машинного обучения через настраиваемые контейнеры для обучения и прогнозирования.
Ключевыми достоинствами Vertex AI с точки зрения MLOps являются следующие:
✔️бессерверные решения сокращают затраты на инфраструктуру и развертывание. Стоимость использования стартует от 0,03$ за запуск конвейера и цена ресурсов Google Cloud.
✔️оптимизация функций и вариантов использования специально для машинного обучения
✔️поддержка кэширования.
Перечень недостатков Vertex AI Pipelines более широкий:
✔️отсутствие планировщика требует использовать сторонние инструменты, такие как Cloud Scheduler и Cloud Function, Jenkins, AirFlow или что-то еще
✔️нет поддержки микроконвейеров, а разрабатывать большие сквозные конвейеры может быть очень сложно, долго и дорого
✔️нет поддержки взаимозависимых и динамических DAG
✔️отсутствие CLI, что затрудняет протестировать конкретную задачу или конвейер
✔️невозможность запустить конвейеры локально
✔️недостаточные контроль и наблюдаемость по сравнению с AirFlow на Kubernetes
✔️привязка к инфраструктуре Google может вызвать дополнительные сложности и проблемы с настройкой сети, VPN и брандмауэра. В большинстве случаев компоненты конвейера должны взаимодействовать с пользовательской инфраструктурой, например, считывать данные из базы данных или взаимодействовать с конечными точками. Однако, бессерверная модель Vertex AI не позволит работать со статическими IP-адресами в шорт-листе и т. д.
✔️Наконец, фреймворк пока еще имеет мало реальных внедрений, а потому его небольшое сообщество еще не накопило список лучших практик, операторов и кейсов. Вместе с «сырой» документацией это сильно повышает порог входа в технологию, что противоречит идее MLOps, которая стремится устранить разрывы между ML-разработкой и программной инженерией.
Таким образом, новый продукт от Google AI пока нельзя назвать успешным инструментом современной дата-инженерии для решения MLOps-задач, в отличие от Apache AirFlow, который мы рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/airflow-vs-vertex-ai-pipelines-in-mlops.html
💡Что такое Vertex AI Pipelines от Google.
Google Vertex AI — это новый набор инструментов для поддержки сквозного жизненного цикла ML-решений и MLOps-задач.
Он состоит из множества инструментов, включая Workbench, Feature Store, бессерверный конвейер Kubeflow, задания, эксперименты и отслеживание метаданных, реестр ML-моделей, конечные точки для развертывания их в онлайн, пакетные прогнозы и много других полезных функций.
Vertex AI интегрируется со многими открытыми ML-фреймворками, такими как TensorFlow, PyTorch и scikit-learn, а также поддерживает все среды машинного обучения через настраиваемые контейнеры для обучения и прогнозирования.
Ключевыми достоинствами Vertex AI с точки зрения MLOps являются следующие:
✔️бессерверные решения сокращают затраты на инфраструктуру и развертывание. Стоимость использования стартует от 0,03$ за запуск конвейера и цена ресурсов Google Cloud.
✔️оптимизация функций и вариантов использования специально для машинного обучения
✔️поддержка кэширования.
Перечень недостатков Vertex AI Pipelines более широкий:
✔️отсутствие планировщика требует использовать сторонние инструменты, такие как Cloud Scheduler и Cloud Function, Jenkins, AirFlow или что-то еще
✔️нет поддержки микроконвейеров, а разрабатывать большие сквозные конвейеры может быть очень сложно, долго и дорого
✔️нет поддержки взаимозависимых и динамических DAG
✔️отсутствие CLI, что затрудняет протестировать конкретную задачу или конвейер
✔️невозможность запустить конвейеры локально
✔️недостаточные контроль и наблюдаемость по сравнению с AirFlow на Kubernetes
✔️привязка к инфраструктуре Google может вызвать дополнительные сложности и проблемы с настройкой сети, VPN и брандмауэра. В большинстве случаев компоненты конвейера должны взаимодействовать с пользовательской инфраструктурой, например, считывать данные из базы данных или взаимодействовать с конечными точками. Однако, бессерверная модель Vertex AI не позволит работать со статическими IP-адресами в шорт-листе и т. д.
✔️Наконец, фреймворк пока еще имеет мало реальных внедрений, а потому его небольшое сообщество еще не накопило список лучших практик, операторов и кейсов. Вместе с «сырой» документацией это сильно повышает порог входа в технологию, что противоречит идее MLOps, которая стремится устранить разрывы между ML-разработкой и программной инженерией.
Таким образом, новый продукт от Google AI пока нельзя назвать успешным инструментом современной дата-инженерии для решения MLOps-задач, в отличие от Apache AirFlow, который мы рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/airflow-vs-vertex-ai-pipelines-in-mlops.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Трудности выбора в MLOps: оркестрация ML-конвейеров с Vertex AI Pipelines и Apache AirFlow
Мы уже сравнивали MLflow и Kubeflow, которые позволяют управлять конвейерами машинного обучен
#DataScience #NoSQL #SQL #статьи
5 популярных языков запросов к графам.
❇️GraphQL очень гибкий и экономичный с точки зрения сетевой передачи. Он поддерживается многими языками программирования (JavaScript, Java, Python, Ruby и PHP), позволяет настраивать структуру передаваемых и принимаемых данных, а также включать поля из нескольких ресурсов в один запрос. Однако, он не очень прост в реализации, имеет статичную схему данных, не поддерживает кэширование на клиенте и загрузку файлов. GraphQL работает только с JSON-форматом. Этот язык запросов подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно унифицировать выполнение запросов, снизить число конечных точек и нагрузку на сеть.
❇️Gremlin — это язык обхода графов Apache TinkerPop, принятый во многих графовых базах данных. В свою очередь, Apache TinkerPop — это среда вычислений на основе графов для транзакционных и аналитических графовых СУБД. Gremlin — это функциональный язык потока данных, который позволяет пользователям лаконично выражать сложные обходы (или запросы) графа свойств своего приложения. Разработчики могут писать запросы Gremlin на любом языке программирования, который поддерживает композицию функций и вложенность функций, например, Python, Java, Javascript, Scala и Groovy, чтобы выполнить императивные (процедурные) и декларативные (описательные) обходы в графе. Однако, это достаточно низкоуровневый язык обхода графа, который не очень легко читать.
❇️Cypher — это язык запросов популярной графовой базы данных Neo4j, который немного похож на SQL. Однако, он основан на шаблонах и предоставляет визуальный способ сопоставления отношений и шаблонов. Cypher позволяет использовать средства отображения графов объектов (OGM) для сопоставления отношений и узлов в графах со ссылками и объектами в модели предметной области. OGM, встроенный в Neo4j, использует операторы запроса Cypher вместе с драйвером Java и сопоставляет существующие объекты домена с объектами этой графовой СУБД (узлами и ребрами графа). Neo4j-OGM поддерживает быстрое сканирование метаданных класса и оптимизированное управление загрузкой данных.
❇️SPARQL (SPARQL Protocol and RDF Query Language) — это язык запросов, который позволяет пользователям запрашивать информацию из баз данных, которые могут быть сопоставлены с RDF (Resource Description Framework). SPARQL немного похож на стандартный SQL, но данные в запросе SPARQL внутренне выражаются в виде троек из субъекта, предиката и объекта. SPARQL может объединять запросы из разных репозиториев, обращаясь как RDF, так и к реляционным СУБД, а также интегрировать данные в пересекающихся доменах. Однако, SPARQL нелегко читать и понимать.
❇️AQL (ArangoDB Query Language) — это язык запросов для извлечения и изменения данных, хранящихся в ArangoDB — мультимодельной БД, поддерживающей графовую и документную модели, а также ключ-значение. AQL поддерживает различные функции, такие как ANALYZER(), BOOST(), EXISTS() и пр., позволяющие выполнять сложные вычисления. Он помогает разработчикам разрабатывать надежные приложения и напрямую отображать данные в базу данных. Это достаточно гибкий язык, который упрощает масштабирование и адаптацию архитектуры ИС к изменениям.
Более подробно: что общего у GraphQL, Gremlin, Cypher, SPARQL и AOL, а также чем они отличаются.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/graph-languages-overview.html
5 популярных языков запросов к графам.
❇️GraphQL очень гибкий и экономичный с точки зрения сетевой передачи. Он поддерживается многими языками программирования (JavaScript, Java, Python, Ruby и PHP), позволяет настраивать структуру передаваемых и принимаемых данных, а также включать поля из нескольких ресурсов в один запрос. Однако, он не очень прост в реализации, имеет статичную схему данных, не поддерживает кэширование на клиенте и загрузку файлов. GraphQL работает только с JSON-форматом. Этот язык запросов подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно унифицировать выполнение запросов, снизить число конечных точек и нагрузку на сеть.
❇️Gremlin — это язык обхода графов Apache TinkerPop, принятый во многих графовых базах данных. В свою очередь, Apache TinkerPop — это среда вычислений на основе графов для транзакционных и аналитических графовых СУБД. Gremlin — это функциональный язык потока данных, который позволяет пользователям лаконично выражать сложные обходы (или запросы) графа свойств своего приложения. Разработчики могут писать запросы Gremlin на любом языке программирования, который поддерживает композицию функций и вложенность функций, например, Python, Java, Javascript, Scala и Groovy, чтобы выполнить императивные (процедурные) и декларативные (описательные) обходы в графе. Однако, это достаточно низкоуровневый язык обхода графа, который не очень легко читать.
❇️Cypher — это язык запросов популярной графовой базы данных Neo4j, который немного похож на SQL. Однако, он основан на шаблонах и предоставляет визуальный способ сопоставления отношений и шаблонов. Cypher позволяет использовать средства отображения графов объектов (OGM) для сопоставления отношений и узлов в графах со ссылками и объектами в модели предметной области. OGM, встроенный в Neo4j, использует операторы запроса Cypher вместе с драйвером Java и сопоставляет существующие объекты домена с объектами этой графовой СУБД (узлами и ребрами графа). Neo4j-OGM поддерживает быстрое сканирование метаданных класса и оптимизированное управление загрузкой данных.
❇️SPARQL (SPARQL Protocol and RDF Query Language) — это язык запросов, который позволяет пользователям запрашивать информацию из баз данных, которые могут быть сопоставлены с RDF (Resource Description Framework). SPARQL немного похож на стандартный SQL, но данные в запросе SPARQL внутренне выражаются в виде троек из субъекта, предиката и объекта. SPARQL может объединять запросы из разных репозиториев, обращаясь как RDF, так и к реляционным СУБД, а также интегрировать данные в пересекающихся доменах. Однако, SPARQL нелегко читать и понимать.
❇️AQL (ArangoDB Query Language) — это язык запросов для извлечения и изменения данных, хранящихся в ArangoDB — мультимодельной БД, поддерживающей графовую и документную модели, а также ключ-значение. AQL поддерживает различные функции, такие как ANALYZER(), BOOST(), EXISTS() и пр., позволяющие выполнять сложные вычисления. Он помогает разработчикам разрабатывать надежные приложения и напрямую отображать данные в базу данных. Это достаточно гибкий язык, который упрощает масштабирование и адаптацию архитектуры ИС к изменениям.
Более подробно: что общего у GraphQL, Gremlin, Cypher, SPARQL и AOL, а также чем они отличаются.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/graph-languages-overview.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
5 популярных языков запросов к графам
Для продвижения нашего нового курса по графовым алгоритмам в бизнес-приложениях, сегод
#DataScience #DevOps #ML #статьи
🪤Скрытый технический долг в ML-системах.
Технический долг - дополнительные затраты, возникающие в долгосрочной перспективе, с которыми сталкивается команда, в результате выбора простых и быстрых вариантов вместо принятия решений, более правильных в долгосрочной перспективе.
Для систем Machine Learning технический долг существует на системном уровне, а не на уровне кода. Поэтому традиционного подхода к техническому долгу, как и в разработке ПО, недостаточно для его устранения: нужны подходы, специфичные для ML.
Технический долг растет при использовании данных не по назначению, что в классической разработке ПО решается ограничением видимости. В Machine Learning также помогает предоставление доступа к данным и моделям только определенным пользователям и командам, а также тщательное управление этими разрешениями.
Далее читайте подробно про техдолг в проектах Machine Learning.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/mlops-to-eliminate-technical-debt-in-ml-projects.html
🪤Скрытый технический долг в ML-системах.
Технический долг - дополнительные затраты, возникающие в долгосрочной перспективе, с которыми сталкивается команда, в результате выбора простых и быстрых вариантов вместо принятия решений, более правильных в долгосрочной перспективе.
Для систем Machine Learning технический долг существует на системном уровне, а не на уровне кода. Поэтому традиционного подхода к техническому долгу, как и в разработке ПО, недостаточно для его устранения: нужны подходы, специфичные для ML.
Технический долг растет при использовании данных не по назначению, что в классической разработке ПО решается ограничением видимости. В Machine Learning также помогает предоставление доступа к данным и моделям только определенным пользователям и командам, а также тщательное управление этими разрешениями.
Далее читайте подробно про техдолг в проектах Machine Learning.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/mlops-to-eliminate-technical-debt-in-ml-projects.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
MLOps для устранения техдолга в проектах Machine Learning
Почему в ML-проектах накапливается технический долг и как MLOps устраняет проблемы разработки и развертывания систем Machine Learning
#kafka #DataScience #статьи
🌊Как работают события и их потоки в брокере Kafka
Событие в Kafka — это факт, описывающий изменение состояния объекта (например, заполнение топика сообщениями или разбиение топика на разделы).
Kafka узнает о новом событии благодаря механизму регистрации событий. Регистрация событий — это считывание текущего состояния объекта и сравнение этого состояния с более ранним. В случае, если текущее состояние объекта отличается от предыдущего, брокер Kafka автоматически регистрирует новое событие, а также создает поток событий, в который помещаются все события зарегистрированные в данный момент времени.
Поток событий (event stream) представляет собой коллекцию (множество) событий, которые происходят одновременно в данный момент времени.
Далее разберем на практических примерах особенности работы потоков событий.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-events/
🌊Как работают события и их потоки в брокере Kafka
Событие в Kafka — это факт, описывающий изменение состояния объекта (например, заполнение топика сообщениями или разбиение топика на разделы).
Kafka узнает о новом событии благодаря механизму регистрации событий. Регистрация событий — это считывание текущего состояния объекта и сравнение этого состояния с более ранним. В случае, если текущее состояние объекта отличается от предыдущего, брокер Kafka автоматически регистрирует новое событие, а также создает поток событий, в который помещаются все события зарегистрированные в данный момент времени.
Поток событий (event stream) представляет собой коллекцию (множество) событий, которые происходят одновременно в данный момент времени.
Далее разберем на практических примерах особенности работы потоков событий.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-events/
Практические курсы по Apache Kafka для аналитиков, разработчиков, администраторов Big Data
Что такое события в распределенном брокере Kafka
Как устроены события в брокере Kafka: особенности потоковой обработки Big Data в распределенной среде - обучение Big Data для начинающих
#DataScience #DevOps #MachineLearning
📜GraphQL для ML: возможности и примеры
GraphQL - язык запросов для API, который позволяет клиенту запрашивать только нужные данные, в отличие от традиционных REST API, которые возвращают весь набор данных ресурса, связанный с конечной точкой.
Эта технология снижает нагрузку на сеть, позволяя реализовать сложные аналитические вычисления в рамках одного запроса. Применяя GraphQL к системам машинного обучения, можно управлять ML-моделями и отслеживать их производительность с помощью единого API.
Наконец, с точки зрения производственного использования проектов Machine Learning, GraphQL позволяет экономно в плане трафика обновлять ML-модели в режиме реального времени, что крайне важно для приложений машинного обучения, которые необходимо постоянно переобучать и обновлять.
Если ML-модель должна обрабатывать много данных и различные параметры фильтрации, с потенциалом будущего развития системы машинного обучения, GraphQL будет отличным выбором.
Для примитивных CRUD-операций подойдет классический REST API, который реализует манипулирование ресурсами через основные HTTP-запросы (GET, POST, PUT, DELETE).
К примеру, используя GraphQL, разработчики могут создавать API, который позволяет пользователям гибко и эффективно взаимодействовать с ML-моделями обработки естественного языка (NLP). Предположим, NLP-приложение для понимания запросов клиентов и ответа на них. С GraphQL это приложение может запросить ML-модель, чтобы понять намерение клиента и предоставить соответствующий ответ в режиме реального времени и без дополнительных сетевых запросов.
Также GraphQL можно использовать для распознавания изображений, создав API, который позволяет пользователям запрашивать ML-модель и получать информацию об объектах или сценах на картинке.
К примеру, для идентификации растений или грибов в лесу. Еще GraphQL подойдет для создания унифицированного аналитического API, который позволит всем заинтересованным сторонам использовать единый источник доступа к согласованным данным, но несвязанным между собой семантически. Это соответствует ключевым идеям концепции непрерывного управления и сопровождения ML-систем под названием MLOps.
Таким образом, GraphQL может быть мощным инструментом для создания и управления моделями машинного обучения с широким спектром сценариев практического использования.
Как применить его для разработки API проекта машинного обучения, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/graphql-api-in-ml-projects.html
📜GraphQL для ML: возможности и примеры
GraphQL - язык запросов для API, который позволяет клиенту запрашивать только нужные данные, в отличие от традиционных REST API, которые возвращают весь набор данных ресурса, связанный с конечной точкой.
Эта технология снижает нагрузку на сеть, позволяя реализовать сложные аналитические вычисления в рамках одного запроса. Применяя GraphQL к системам машинного обучения, можно управлять ML-моделями и отслеживать их производительность с помощью единого API.
Наконец, с точки зрения производственного использования проектов Machine Learning, GraphQL позволяет экономно в плане трафика обновлять ML-модели в режиме реального времени, что крайне важно для приложений машинного обучения, которые необходимо постоянно переобучать и обновлять.
Если ML-модель должна обрабатывать много данных и различные параметры фильтрации, с потенциалом будущего развития системы машинного обучения, GraphQL будет отличным выбором.
Для примитивных CRUD-операций подойдет классический REST API, который реализует манипулирование ресурсами через основные HTTP-запросы (GET, POST, PUT, DELETE).
К примеру, используя GraphQL, разработчики могут создавать API, который позволяет пользователям гибко и эффективно взаимодействовать с ML-моделями обработки естественного языка (NLP). Предположим, NLP-приложение для понимания запросов клиентов и ответа на них. С GraphQL это приложение может запросить ML-модель, чтобы понять намерение клиента и предоставить соответствующий ответ в режиме реального времени и без дополнительных сетевых запросов.
Также GraphQL можно использовать для распознавания изображений, создав API, который позволяет пользователям запрашивать ML-модель и получать информацию об объектах или сценах на картинке.
К примеру, для идентификации растений или грибов в лесу. Еще GraphQL подойдет для создания унифицированного аналитического API, который позволит всем заинтересованным сторонам использовать единый источник доступа к согласованным данным, но несвязанным между собой семантически. Это соответствует ключевым идеям концепции непрерывного управления и сопровождения ML-систем под названием MLOps.
Таким образом, GraphQL может быть мощным инструментом для создания и управления моделями машинного обучения с широким спектром сценариев практического использования.
Как применить его для разработки API проекта машинного обучения, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/graphql-api-in-ml-projects.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
MLOps с Graphene: зачем и как использовать GraphQL для проектов Machine Learning
Недавно мы упоминали GraphQL как мощный и гибкий язык запросов к данным, хранящимся в графо
#ApacheKafka #DataScience #статьи
〽️Для чего нужны потоки в Kafka и как они работают
Потоки в Kafka — это неизменяемые коллекции данных, которые предназначены для добавления данных в топики Kafka. Kafka-потоки также являются потоками фактов, где каждый факт представляет собой уникальное и неизменяемое событие (event). Данные потоков хранятся в виде структуры ключ-значение (key-value).
Создавать Kafka-потоки можно двумя способами:
1️⃣с помощью библиотеки Kafka Streams
2️⃣с помощью платформы KSQL.
Каждый из этих способов мы подробно рассмотрим далее на практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-streams-building/
〽️Для чего нужны потоки в Kafka и как они работают
Потоки в Kafka — это неизменяемые коллекции данных, которые предназначены для добавления данных в топики Kafka. Kafka-потоки также являются потоками фактов, где каждый факт представляет собой уникальное и неизменяемое событие (event). Данные потоков хранятся в виде структуры ключ-значение (key-value).
Создавать Kafka-потоки можно двумя способами:
1️⃣с помощью библиотеки Kafka Streams
2️⃣с помощью платформы KSQL.
Каждый из этих способов мы подробно рассмотрим далее на практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-streams-building/
Практические курсы по Apache Kafka для аналитиков, разработчиков, администраторов Big Data
Что такое потоки и как их создавать в Kafka
Что такое потоки и как их создать в Kafka: особенности потоковой обработки Big Data в распределенной среде - обучение Big Data для начинающих
#ApacheKafka #DataScience #статьи
❓Какие элементы отвечают за извлечение сообщений в Kafka
Извлечение сообщений в Kafka — это процесс получения содержимого опубликованных продюсером сообщений в заданном топике.
За получение сообщений отвечает продюсер, однако за сам процесс извлечения отвечают такие элементы, как:
⭕️смещение (offset) — это порядковый номер записи (индекс), который указывается для получения конкретной записи в данный момент времени независимо от того, когда она была создана. Заданные пользователем смещения позволяют переходить к конкретной записи минуя все остальные. Брокер Kafka устроен таким образом, что каждой записи при создании присваивается порядковый номер, на который указывает курсор (метка, которая перемещается при обращении или создании записи). Как только пользователь обращается к конкретной записи, указывая соответствующий индекс, курсор перемещается в данном направлении и фиксируется на заданном элементе (записи);
⭕️цикл опроса — это механизм, представляющий собой бесконечный цикл (цикл, выполнение которого не завершится до тех пор, пока не произойдет полная остановка программы), который осуществляет координацию (распределение подписчиков по топикам) и перебалансировку разделов (передачу раздела от неактивного подписчика активному), а также отвечает за извлечение данных из топиков.
Далее разберем извлечение сообщений в Kafka в нескольких практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-message-polling/
❓Какие элементы отвечают за извлечение сообщений в Kafka
Извлечение сообщений в Kafka — это процесс получения содержимого опубликованных продюсером сообщений в заданном топике.
За получение сообщений отвечает продюсер, однако за сам процесс извлечения отвечают такие элементы, как:
⭕️смещение (offset) — это порядковый номер записи (индекс), который указывается для получения конкретной записи в данный момент времени независимо от того, когда она была создана. Заданные пользователем смещения позволяют переходить к конкретной записи минуя все остальные. Брокер Kafka устроен таким образом, что каждой записи при создании присваивается порядковый номер, на который указывает курсор (метка, которая перемещается при обращении или создании записи). Как только пользователь обращается к конкретной записи, указывая соответствующий индекс, курсор перемещается в данном направлении и фиксируется на заданном элементе (записи);
⭕️цикл опроса — это механизм, представляющий собой бесконечный цикл (цикл, выполнение которого не завершится до тех пор, пока не произойдет полная остановка программы), который осуществляет координацию (распределение подписчиков по топикам) и перебалансировку разделов (передачу раздела от неактивного подписчика активному), а также отвечает за извлечение данных из топиков.
Далее разберем извлечение сообщений в Kafka в нескольких практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-message-polling/
Практические курсы по Apache Kafka для аналитиков, разработчиков, администраторов Big Data
Как брокер Kafka осуществляет извлечение сообщений в распределенной среде
Сегодня поговорим про механизм, отвечающий за извлечение сообщений в брокере Kafka. Читай
#DataScience #NoSQ #статьи
⛰️Архитектура и принципы работы графовой MPP-СУБД
TigerGraph — это распределенное графоориентированное хранилище данных с массивно-параллельной обработкой запросов.
Оно отличается от других NoSQL-баз горизонтально масштабируемой архитектурой, которая позволяет поддерживать выполнение рабочих нагрузок на больших графах до сотен миллиардов сущностей и 1 триллиона отношений. TigerGraph поддерживает встроенное параллельное выполнение запросов, повзволяя быстрее исследовать данные, хранящиеся в этой графовой СУБД. Внутренний язык запросов этой MPP-СУБД, GSQL, является декларативным SQL-подобным языком запросов с невысоким порогом входа. Он является полным по Тьюрингу, что означает, что любой запрос может быть выражен с помощью GSQL, в отличие от других подобных языков.
Архитектура TigerGraph включает механизм хранения графов (GSE, Graph Storage Engine), отвечающий за физическое хранение и сжатие данных графа, и механизм обработки графов (GPE, Graph Processing Engine), который предлагает возможности параллельной обработки и разделения графа, что важно для масштабируемости системы.
Для координации действий компонентов используется REST-подход передачи сообщений. В частности, центральное место в управлении задачами занимает RESTPP, усовершенствованный сервер RESTful.
Впрочем, пользователи могут взаимодействовать с TigerGraph и другими способами:
✅с помощью клиента GSQL — один экземпляр TigerGraph может поддерживать несколько клиентов GSQL на удаленных узлах
✅через GraphStudio — графический пользовательский интерфейс, обеспечивающий большинство основных функций GSQL
✅по RESTPP в рамках интеграционного взаимодействия приложений по REST API
✅утилита gAdmin для системного администрирования.
Далее разберем на практике.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-tigergraph-and-how-to-use-it.html
⛰️Архитектура и принципы работы графовой MPP-СУБД
TigerGraph — это распределенное графоориентированное хранилище данных с массивно-параллельной обработкой запросов.
Оно отличается от других NoSQL-баз горизонтально масштабируемой архитектурой, которая позволяет поддерживать выполнение рабочих нагрузок на больших графах до сотен миллиардов сущностей и 1 триллиона отношений. TigerGraph поддерживает встроенное параллельное выполнение запросов, повзволяя быстрее исследовать данные, хранящиеся в этой графовой СУБД. Внутренний язык запросов этой MPP-СУБД, GSQL, является декларативным SQL-подобным языком запросов с невысоким порогом входа. Он является полным по Тьюрингу, что означает, что любой запрос может быть выражен с помощью GSQL, в отличие от других подобных языков.
Архитектура TigerGraph включает механизм хранения графов (GSE, Graph Storage Engine), отвечающий за физическое хранение и сжатие данных графа, и механизм обработки графов (GPE, Graph Processing Engine), который предлагает возможности параллельной обработки и разделения графа, что важно для масштабируемости системы.
Для координации действий компонентов используется REST-подход передачи сообщений. В частности, центральное место в управлении задачами занимает RESTPP, усовершенствованный сервер RESTful.
Впрочем, пользователи могут взаимодействовать с TigerGraph и другими способами:
✅с помощью клиента GSQL — один экземпляр TigerGraph может поддерживать несколько клиентов GSQL на удаленных узлах
✅через GraphStudio — графический пользовательский интерфейс, обеспечивающий большинство основных функций GSQL
✅по RESTPP в рамках интеграционного взаимодействия приложений по REST API
✅утилита gAdmin для системного администрирования.
Далее разберем на практике.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-tigergraph-and-how-to-use-it.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Зачем вам TigerGraph: обзор графовой MPP-СУБД
Продолжая разговор про языки запросов к графовым базам данных, сегодня познакомимся с G
#Cypher #DataScience #статьи
🎢Постановка задачи: критерии оценки для поиска кратчайшего пути
Поиск кратчайшего пути – это классическая задача на графах, которая успешно решается людьми уже несколько столетий. В настоящее время с ней успешно справляются алгоритмы, поддерживаемые в графовых базых данных.
Например, в популярной NoSQL-СУБД Neo4j есть целая библиотека Graph Data Science, которая содержит множество графовых алгоритмов, включая алгоритм Дейкстры, предложенный еще в 1959 году и до сих пор активно применяемый для поиска кратчайшего пути между вершинами графа.
Однако, сегодня попробуем решить задачу поиска наиболее выгодного пути, используя только средства встроенного языка запросов Neo4j – SQL-подобного Cypher.
В качестве рабочей среды возьмем открытую GUI-консоль Neo4j, а бизнес-постановку задачу сформулируем на примере, понятном каждому жителю мегаполиса. При планировании маршрутов передвижения в городе часто возникает такая ситуация, что в какую-то точку можно добраться только пешком из-за загруженности дорог или вовсе их отсутствия.
Также нередки случаи, когда при меньшей протяженности пути в километрах по времени прохождения он становится более длительным из-за автомобильных пробок, аварий или дорожных работ.
Таким образом, для оценки пути с точки зрения бизнеса, например, в службе доставке или логистической компании, важно учитывать несколько критериев:
✅допустимый способ перемещения (пешком или на автомобиле);
✅расстояние в километрах;
✅длительность прохождения этого расстояния в зависимости от способа перемещения.
Чтобы решить эту задачу, сперва создадим направленный взвешенный граф, обозначив вершины буквами, а соединяющие их ребра промаркируем несколькими отношениями, задав расстояние в километрах и время прохождения этого расстояния пешком или на автомобиле. Причем не все отношения, заданных в километрах, могут быть пройдены обоими способами передвижения.
Как решить эту задачу, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/cypher-queries-to-find-shortest-path-in-neo4j.html
🎢Постановка задачи: критерии оценки для поиска кратчайшего пути
Поиск кратчайшего пути – это классическая задача на графах, которая успешно решается людьми уже несколько столетий. В настоящее время с ней успешно справляются алгоритмы, поддерживаемые в графовых базых данных.
Например, в популярной NoSQL-СУБД Neo4j есть целая библиотека Graph Data Science, которая содержит множество графовых алгоритмов, включая алгоритм Дейкстры, предложенный еще в 1959 году и до сих пор активно применяемый для поиска кратчайшего пути между вершинами графа.
Однако, сегодня попробуем решить задачу поиска наиболее выгодного пути, используя только средства встроенного языка запросов Neo4j – SQL-подобного Cypher.
В качестве рабочей среды возьмем открытую GUI-консоль Neo4j, а бизнес-постановку задачу сформулируем на примере, понятном каждому жителю мегаполиса. При планировании маршрутов передвижения в городе часто возникает такая ситуация, что в какую-то точку можно добраться только пешком из-за загруженности дорог или вовсе их отсутствия.
Также нередки случаи, когда при меньшей протяженности пути в километрах по времени прохождения он становится более длительным из-за автомобильных пробок, аварий или дорожных работ.
Таким образом, для оценки пути с точки зрения бизнеса, например, в службе доставке или логистической компании, важно учитывать несколько критериев:
✅допустимый способ перемещения (пешком или на автомобиле);
✅расстояние в километрах;
✅длительность прохождения этого расстояния в зависимости от способа перемещения.
Чтобы решить эту задачу, сперва создадим направленный взвешенный граф, обозначив вершины буквами, а соединяющие их ребра промаркируем несколькими отношениями, задав расстояние в километрах и время прохождения этого расстояния пешком или на автомобиле. Причем не все отношения, заданных в километрах, могут быть пройдены обоими способами передвижения.
Как решить эту задачу, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/cypher-queries-to-find-shortest-path-in-neo4j.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Ищем кратчайший путь с Cypher-запросами в Neo4j
Сегодня в рамках продвижения нашего нового курса по графовым алгоритмам в бизнес-прило
#DataScience #MachineLearning #статьи
💬Что такое дрейф данных, чем это опасно и как его обнаружить
В отличие от многих других информационных систем, проекты машинного обучения очень сильно зависят от данных.
Если производственные данные, которые поступают в ML-модель, радикально отличаются от тех, на которых она обучалась, встроенные в нее алгоритмы становятся неэффективны. Этот эффект называется дрейф данных и обычно случается из-за изменения поведения исследуемых объектов в реальном мире с течением времени или изменения меры оценки качества модели. Как правило, при этом статистические свойства входных данных меняются, что приводит к сдвигу в их распределении. Если вовремя не обнаружить дрейф данных, т.е. до того, как он негативно повлияет на результаты моделирования, прогнозы Machine Learning будут ошибочными. Например, риэлторская компания Zillion, базирующаяся в Сиэтле, в результате дрейфа данных своих ML-моделей понесла убытки в размере около $300 миллионов из-за ошибочных прогнозов цен после резких изменений на рынке недвижимости из-за пандемии COVID-19.
Поскольку дрейф данных обычно вызван изменением их статистических свойств, для обнаружения этого явления используются статистические тесты, такие как тест Колмогорова-Смирнова, индекс стабильности распределения, тест Кульбака-Лейблера, тест Дженсена-Шеннона, метрика Вассерштейна, критерий хи-квадрат и Z-тест. Автоматизировать выполнение этих тестов позволяют современные MLOps-инструменты, одним из которых является Python-библиотека мониторинга ML-моделей с открытым исходным кодом, разработанная компанией Evidently. ai.
Далее рассмотрим, как она работает.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-evidently-library-for-mlops.html
💬Что такое дрейф данных, чем это опасно и как его обнаружить
В отличие от многих других информационных систем, проекты машинного обучения очень сильно зависят от данных.
Если производственные данные, которые поступают в ML-модель, радикально отличаются от тех, на которых она обучалась, встроенные в нее алгоритмы становятся неэффективны. Этот эффект называется дрейф данных и обычно случается из-за изменения поведения исследуемых объектов в реальном мире с течением времени или изменения меры оценки качества модели. Как правило, при этом статистические свойства входных данных меняются, что приводит к сдвигу в их распределении. Если вовремя не обнаружить дрейф данных, т.е. до того, как он негативно повлияет на результаты моделирования, прогнозы Machine Learning будут ошибочными. Например, риэлторская компания Zillion, базирующаяся в Сиэтле, в результате дрейфа данных своих ML-моделей понесла убытки в размере около $300 миллионов из-за ошибочных прогнозов цен после резких изменений на рынке недвижимости из-за пандемии COVID-19.
Поскольку дрейф данных обычно вызван изменением их статистических свойств, для обнаружения этого явления используются статистические тесты, такие как тест Колмогорова-Смирнова, индекс стабильности распределения, тест Кульбака-Лейблера, тест Дженсена-Шеннона, метрика Вассерштейна, критерий хи-квадрат и Z-тест. Автоматизировать выполнение этих тестов позволяют современные MLOps-инструменты, одним из которых является Python-библиотека мониторинга ML-моделей с открытым исходным кодом, разработанная компанией Evidently. ai.
Далее рассмотрим, как она работает.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-evidently-library-for-mlops.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
MLOps c Python-библиотекой Evidently: обнаружение дрейфа данных в ML-моделях
Полезный MLOps без лишних усилий: что такое дрейф данных, чем это опасно и как его обнаружить с легковесной Python-библиотекой Evidently
#DataScience #статьи
📌Краткий ликбез по gRPC
Напомним, gRPC – это технология интеграции систем, включая клиентский и серверный компоненты, основанная на удаленном вызове процедур в редакции 2015 года от Google. Как и многие RPC-технологии, gRPC предполагает определение сервиса и его методов, которые можно вызывать удаленно, с их параметрами и типами возвращаемых значений. По умолчанию gRPC использует бинарный формат Protobuf в качестве языка определения интерфейса (IDL) для описания интерфейса сервиса и структуры сообщений полезной нагрузки.
В качестве транспортного протокола gRPC использует HTTP/2 и предоставляет несколько API:
▶️унарные RPC, когда клиент отправляет один запрос на сервер и получает один ответ, как в типовых синхронных веб-сервисах
▶️серверные потоковые RPC, когда клиент отправляет запрос на сервер и получает поток для чтения последовательности сообщений. Клиент читает данные из возвращенного потока до тех пор, пока не останется сообщений. Технология gRPC гарантирует упорядочение сообщений в рамках отдельного RPC-вызова.
▶️клиентские потоковые RPC, когда клиент записывает последовательность сообщений и отправляет их на сервер, используя предоставленный поток. Как только клиент закончил писать сообщения, он ждет, пока сервер прочитает их и вернет свой ответ. За порядок сообщений в рамках отдельного RPC-вызова отвечает сама технология gRPC.
▶️двунаправленные потоковые RPC, когда обе стороны (клиент и сервер) отправляют последовательность сообщений, используя поток чтения-записи. Два потока работают независимо, поэтому клиенты и серверы могут читать и записывать в любом порядке. Например, сервер может дождаться получения всех клиентских сообщений, прежде чем отправлять ответы, или попеременно читать сообщение, а затем отвечать, или комбинировать операции чтения и записи каким-то другим образом. Порядок сообщений в каждом потоке сохраняется.
Канал gRPC обеспечивает подключение к gRPC-серверу на указанном узле и порту. Он используется при создании клиентского stub-объекта. Клиенты могут указать аргументы канала, чтобы изменить поведение gRPC по умолчанию, например, включить или выключить сжатие сообщений. Канал имеет состояние, например, подключен и свободен.
Таким образом, gRPC является очень мощной технологией и подходит для потоковой обработки данных благодаря наличию настраиваемых стриминговых API. Поэтому потенциально ее можно использовать в проектах машинного обучения, которые должны переобучаться в режиме реального времени.
Как это сделать, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/mlops-with-kafka-streams-and-grpc.html
📌Краткий ликбез по gRPC
Напомним, gRPC – это технология интеграции систем, включая клиентский и серверный компоненты, основанная на удаленном вызове процедур в редакции 2015 года от Google. Как и многие RPC-технологии, gRPC предполагает определение сервиса и его методов, которые можно вызывать удаленно, с их параметрами и типами возвращаемых значений. По умолчанию gRPC использует бинарный формат Protobuf в качестве языка определения интерфейса (IDL) для описания интерфейса сервиса и структуры сообщений полезной нагрузки.
В качестве транспортного протокола gRPC использует HTTP/2 и предоставляет несколько API:
▶️унарные RPC, когда клиент отправляет один запрос на сервер и получает один ответ, как в типовых синхронных веб-сервисах
▶️серверные потоковые RPC, когда клиент отправляет запрос на сервер и получает поток для чтения последовательности сообщений. Клиент читает данные из возвращенного потока до тех пор, пока не останется сообщений. Технология gRPC гарантирует упорядочение сообщений в рамках отдельного RPC-вызова.
▶️клиентские потоковые RPC, когда клиент записывает последовательность сообщений и отправляет их на сервер, используя предоставленный поток. Как только клиент закончил писать сообщения, он ждет, пока сервер прочитает их и вернет свой ответ. За порядок сообщений в рамках отдельного RPC-вызова отвечает сама технология gRPC.
▶️двунаправленные потоковые RPC, когда обе стороны (клиент и сервер) отправляют последовательность сообщений, используя поток чтения-записи. Два потока работают независимо, поэтому клиенты и серверы могут читать и записывать в любом порядке. Например, сервер может дождаться получения всех клиентских сообщений, прежде чем отправлять ответы, или попеременно читать сообщение, а затем отвечать, или комбинировать операции чтения и записи каким-то другим образом. Порядок сообщений в каждом потоке сохраняется.
Канал gRPC обеспечивает подключение к gRPC-серверу на указанном узле и порту. Он используется при создании клиентского stub-объекта. Клиенты могут указать аргументы канала, чтобы изменить поведение gRPC по умолчанию, например, включить или выключить сжатие сообщений. Канал имеет состояние, например, подключен и свободен.
Таким образом, gRPC является очень мощной технологией и подходит для потоковой обработки данных благодаря наличию настраиваемых стриминговых API. Поэтому потенциально ее можно использовать в проектах машинного обучения, которые должны переобучаться в режиме реального времени.
Как это сделать, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/mlops-with-kafka-streams-and-grpc.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
MLOps c Kafka Streams и gRPC: 3 способа развернуть ML-модель в production
Сегодня рассмотрим, как развернуть модель машинного обучения в конвейере Apache Kafka, испол
#DataScience #HBase #статьи
Как сохранить данные из памяти Memgraph на диск с GQLAlchemy
Напомним, Memgraph — это высокопроизводительная графовая СУБД с открытым исходным кодом, которая хранит и обрабатывает данные в памяти. Потребление памяти для хранения графа в Memgraph зависит от множества переменных, но это можно оценить. Пустой экземпляр Memgraph в Ubuntu x86 потребляет около 75 МБ памяти из-за базовых накладных расходов во время выполнения. После загрузки набора данных потребление памяти возрастает до 260 МБ. Во время активной работы графовой СУБД память используется для хранения графа и выполнения запросов к нему. Потребление памяти для выполнения запроса монотонно увеличивается во время выполнения и освобождается после его завершения. Рекомендуется иметь в два раза больше оперативной памяти, чем объем, который занимает фактический набор данных графа.
Впрочем, хранить данные в памяти не всегда удобно, поскольку размер ОЗУ всегда ограничен. Поэтому имеет смысл хранить на диске свойства графа, которые напрямую не задействованы в графовых алгоритмах. Для этого в Memgraph есть Python-библиотека с открытым исходным кодом GQLAlchemy.
GQLAlchemy представляет собой средство сопоставления графов и объектов (Object Graph Mapper, OGM), обеспечивая связь между объектами графовой СУБД и Python. Помимо Memgraph, GQLAlchemy также поддерживает и Neo4j. OGM позволяет разработчику вместо запросов Cypher писать объектно-ориентированный код, который OGM автоматически преобразует. На практике это очень удобно, поскольку в больших графах есть узлы с множеством метаданных, которые не используются в графовых вычислениях. Графовые СУБд вообще не очень эффективно работают с большими строками или Parquet-файлами. Обойти это ограничение можно, используя отдельную реляционную СУБд или NoSQL-хранилище типа key-value для связи больших свойств с идентификатором узла. Это простое решение легко реализовать, но сложно поддерживать. Вместо этого проще использовать библиотеку GQLAlchemy, которая с версии 1.1 позволяет определить, какие свойства хранить в графовой базе данных, а какие — в постоянном хранилище на диске. Это можно задать однократно в определении модели и больше не беспокоиться о том, правильно ли сохранены или загружены свойства из нужного источника.
Библиотека GQLAlchemy построена на основе Pydantic и обеспечивает моделирование объектов, проверку, сериализацию и десериализацию данных. Она позволяет определить классы Python, которые сопоставляются с объектами графа, такими как узлы и отношения в графовой базе. Каждый такой класс имеет свойства или поля, содержащие данные об объектах графа.
Таким образом, граф будет занимать меньше места в памяти, а графовые алгоритмы будут работать быстрее.
Далее поговорим про персистентность Redis.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-save-data-from-memory-to-disk-in-memgraph-and-redis.html
Как сохранить данные из памяти Memgraph на диск с GQLAlchemy
Напомним, Memgraph — это высокопроизводительная графовая СУБД с открытым исходным кодом, которая хранит и обрабатывает данные в памяти. Потребление памяти для хранения графа в Memgraph зависит от множества переменных, но это можно оценить. Пустой экземпляр Memgraph в Ubuntu x86 потребляет около 75 МБ памяти из-за базовых накладных расходов во время выполнения. После загрузки набора данных потребление памяти возрастает до 260 МБ. Во время активной работы графовой СУБД память используется для хранения графа и выполнения запросов к нему. Потребление памяти для выполнения запроса монотонно увеличивается во время выполнения и освобождается после его завершения. Рекомендуется иметь в два раза больше оперативной памяти, чем объем, который занимает фактический набор данных графа.
Впрочем, хранить данные в памяти не всегда удобно, поскольку размер ОЗУ всегда ограничен. Поэтому имеет смысл хранить на диске свойства графа, которые напрямую не задействованы в графовых алгоритмах. Для этого в Memgraph есть Python-библиотека с открытым исходным кодом GQLAlchemy.
GQLAlchemy представляет собой средство сопоставления графов и объектов (Object Graph Mapper, OGM), обеспечивая связь между объектами графовой СУБД и Python. Помимо Memgraph, GQLAlchemy также поддерживает и Neo4j. OGM позволяет разработчику вместо запросов Cypher писать объектно-ориентированный код, который OGM автоматически преобразует. На практике это очень удобно, поскольку в больших графах есть узлы с множеством метаданных, которые не используются в графовых вычислениях. Графовые СУБд вообще не очень эффективно работают с большими строками или Parquet-файлами. Обойти это ограничение можно, используя отдельную реляционную СУБд или NoSQL-хранилище типа key-value для связи больших свойств с идентификатором узла. Это простое решение легко реализовать, но сложно поддерживать. Вместо этого проще использовать библиотеку GQLAlchemy, которая с версии 1.1 позволяет определить, какие свойства хранить в графовой базе данных, а какие — в постоянном хранилище на диске. Это можно задать однократно в определении модели и больше не беспокоиться о том, правильно ли сохранены или загружены свойства из нужного источника.
Библиотека GQLAlchemy построена на основе Pydantic и обеспечивает моделирование объектов, проверку, сериализацию и десериализацию данных. Она позволяет определить классы Python, которые сопоставляются с объектами графа, такими как узлы и отношения в графовой базе. Каждый такой класс имеет свойства или поля, содержащие данные об объектах графа.
Таким образом, граф будет занимать меньше места в памяти, а графовые алгоритмы будут работать быстрее.
Далее поговорим про персистентность Redis.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-save-data-from-memory-to-disk-in-memgraph-and-redis.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Работа с диском в резидентных СУБД на примере Memgraph и Redis
Как выгрузить граф знаний из памяти в Memgraph на диск с GQLAlchemy и сохранить ключи и значения из резидентного NoSQL-хранилища Redis
#DataScience #MachineLearning #статьи
Управленческий MLOps: 2 подхода к разработке системы Machine Learning
В концепции MLOps, которая стремится сократить разрыв между различными специалистами, участвующими в процессах разработки, развертывания и эксплуатации систем машинного обучения, можно выделить 2 подхода:
1️⃣фокус на продукте (Product first)
2️⃣фокус на модели Machine Learning (Model first).
Мышление, ориентированное на продукт, фокусируется на конечной цели, которая заключается в предоставлении пользователям ценной прогностической информации. Конечной целью является предоставление полезных и высококачественных прогнозных данных для принятия управленческих решений. Поэтому понимание ключевых бизнес-требований, потребностей пользователей и желаемых результатов является главным на старте создания ML-системы. Согласно MLOps-концепции при этом также следует учитывать масштаб команды, включая бизнес-пользователей, аналитиков данных, специалистам по Data Science, разработчиков и DevOps-инженеров.
Мышление, ориентированное на продукт, требует активного сотрудничества, доверия к данным и понимания вариантов использования, а также:
✅согласование моделей машинного обучения с общим продуктом или услугой, реализация которых обеспечивает денежный поток
✅приоритизация функций ML-продукта, которые оказывают наибольшее влияние на пользователей и бизнес
✅обеспечение бесшовной интеграции компонентов ML-системы с другой ИТ-инфраструктурой
✅постоянная доработка и улучшение на основе отзывов пользователей и бизнес-данных.
Обратной стороной продуктового мышления является техническое — мышление, ориентированное на модель, которое отдает приоритет разработке и оптимизации ML-алгоритмов. Этот подход направлен на достижение высокой производительности и точности моделей, а также их эффективное обслуживание. Особое внимание в подходе Model first уделяется оптимизации алгоритмов и архитектуре с концентрацией на возможностях модели, а не на пользовательском опыте и бизнес-потребностях.
Это смещение фокуса в технологии приводит к концептуальному дрейфу модели, когда ML-система построена вокруг инструментов, а не решаемой проблемы. Тем не менее, мышление, ориентированное на модель, отлично подходит для улучшения существующей, а не для построения новой ML-системы.
Можно сказать, что подход Model first работает хорошо в следующих ситуациях:
✅R&D, когда в ходе фундаментальных исследований ищутся возможности новых алгоритмов
✅поиск сложных взаимосвязей и закономерности в больших данных, что тоже носит исследовательский характер
✅пользовательские модели, когда бизнес-задача настолько новая, что нужно много экспериментировать, построив несколько моделей, чтобы определить потенциал и ограничения будущего продукта
✅Proof-of-Concept, когда нужно продемонстрировать заинтересованным сторонам потенциал ML-модели c с помощью простого доказательства концепции.
Все эти MLOps-процессы отличаются друг от друга, и используют различные метрики оценки эффективности, что мы и рассмотрим дальше.
@BigDataSchool_ru
https://bigdataschool.ru/blog/mlops-and-product-management-for-ml.html
Управленческий MLOps: 2 подхода к разработке системы Machine Learning
В концепции MLOps, которая стремится сократить разрыв между различными специалистами, участвующими в процессах разработки, развертывания и эксплуатации систем машинного обучения, можно выделить 2 подхода:
1️⃣фокус на продукте (Product first)
2️⃣фокус на модели Machine Learning (Model first).
Мышление, ориентированное на продукт, фокусируется на конечной цели, которая заключается в предоставлении пользователям ценной прогностической информации. Конечной целью является предоставление полезных и высококачественных прогнозных данных для принятия управленческих решений. Поэтому понимание ключевых бизнес-требований, потребностей пользователей и желаемых результатов является главным на старте создания ML-системы. Согласно MLOps-концепции при этом также следует учитывать масштаб команды, включая бизнес-пользователей, аналитиков данных, специалистам по Data Science, разработчиков и DevOps-инженеров.
Мышление, ориентированное на продукт, требует активного сотрудничества, доверия к данным и понимания вариантов использования, а также:
✅согласование моделей машинного обучения с общим продуктом или услугой, реализация которых обеспечивает денежный поток
✅приоритизация функций ML-продукта, которые оказывают наибольшее влияние на пользователей и бизнес
✅обеспечение бесшовной интеграции компонентов ML-системы с другой ИТ-инфраструктурой
✅постоянная доработка и улучшение на основе отзывов пользователей и бизнес-данных.
Обратной стороной продуктового мышления является техническое — мышление, ориентированное на модель, которое отдает приоритет разработке и оптимизации ML-алгоритмов. Этот подход направлен на достижение высокой производительности и точности моделей, а также их эффективное обслуживание. Особое внимание в подходе Model first уделяется оптимизации алгоритмов и архитектуре с концентрацией на возможностях модели, а не на пользовательском опыте и бизнес-потребностях.
Это смещение фокуса в технологии приводит к концептуальному дрейфу модели, когда ML-система построена вокруг инструментов, а не решаемой проблемы. Тем не менее, мышление, ориентированное на модель, отлично подходит для улучшения существующей, а не для построения новой ML-системы.
Можно сказать, что подход Model first работает хорошо в следующих ситуациях:
✅R&D, когда в ходе фундаментальных исследований ищутся возможности новых алгоритмов
✅поиск сложных взаимосвязей и закономерности в больших данных, что тоже носит исследовательский характер
✅пользовательские модели, когда бизнес-задача настолько новая, что нужно много экспериментировать, построив несколько моделей, чтобы определить потенциал и ограничения будущего продукта
✅Proof-of-Concept, когда нужно продемонстрировать заинтересованным сторонам потенциал ML-модели c с помощью простого доказательства концепции.
Все эти MLOps-процессы отличаются друг от друга, и используют различные метрики оценки эффективности, что мы и рассмотрим дальше.
@BigDataSchool_ru
https://bigdataschool.ru/blog/mlops-and-product-management-for-ml.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Продуктовое мышление в MLOps и метрики оценки ML-модели
Продакт-менеджмент в машинном обучении: MLOps-подходы и метрики оценки производительности ML-модели перед развертыванием в production
#DataScience #Python #статьи
Python-приложение для работы с Neo4j в AuraDB
Для развертывания Neo4j будем использовать облачный сервис AuraDB, тарифная политика предлагает вариант бесплатного использования.
Поскольку бесплатный тариф не включает библиотек со специальными графовыми алгоритмами, таких как Graph Data Science и APOC, придется самостоятельно писать функции для работы с графами на внутреннем языке запросов Cypher.
В качестве примера возьмем ситуацию поиска финансовых транзакций между компаниями и физическими лицами. На практике это может быть востребовано в случаях финансового мониторинга и налоговых проверок.
Как обычно, пишем и запускаем Python-программу в интерактивной среде Google Colab, которая будет выполнять следующие действия:
1. Подключаться к облачному инстансу графовой базы данных Neo4j , развернутом в сервисе AuraDB;
2. Создавать граф знаний, состоящий из вершин разных типов, например, компания (Company) и физической лицо (Person), которые могут переводить друг другу деньги на расчетные счета. Такие транзакции и будут отношениями между узлами, которые имеют вес в виде суммы денежного перевода.
3. Искать все пути между заданными вершинами с указанием общей суммы финансовых переводов.
Далее на примере
@BigDataSchool_ru
https://bigdataschool.ru/blog/bank-transactions-with-python-and-neo4j.html
Python-приложение для работы с Neo4j в AuraDB
Для развертывания Neo4j будем использовать облачный сервис AuraDB, тарифная политика предлагает вариант бесплатного использования.
Поскольку бесплатный тариф не включает библиотек со специальными графовыми алгоритмами, таких как Graph Data Science и APOC, придется самостоятельно писать функции для работы с графами на внутреннем языке запросов Cypher.
В качестве примера возьмем ситуацию поиска финансовых транзакций между компаниями и физическими лицами. На практике это может быть востребовано в случаях финансового мониторинга и налоговых проверок.
Как обычно, пишем и запускаем Python-программу в интерактивной среде Google Colab, которая будет выполнять следующие действия:
1. Подключаться к облачному инстансу графовой базы данных Neo4j , развернутом в сервисе AuraDB;
2. Создавать граф знаний, состоящий из вершин разных типов, например, компания (Company) и физической лицо (Person), которые могут переводить друг другу деньги на расчетные счета. Такие транзакции и будут отношениями между узлами, которые имеют вес в виде суммы денежного перевода.
3. Искать все пути между заданными вершинами с указанием общей суммы финансовых переводов.
Далее на примере
@BigDataSchool_ru
https://bigdataschool.ru/blog/bank-transactions-with-python-and-neo4j.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Кто кому заплатил: пример поиска банковских транзакций в Neo4j
Кейс поиска графа финансовых транзакций в Neo4j, вычисление общей суммы и визуализация с Python-библиотекой Networkx в Google Colab
#SQL #DataScience #статьи
Что такое GQL и кто его разрабатывает
В начале 2017 года началась работа по созданию GQL (Graph Query Language) — международного стандартного языка для запросов графов.
Работа ведется под эгидой ISO SC32/WG3 и отражена в манифесте GQL от мая 2018 года.
GQL позиционируется как надежный язык декларативных графовых запросов, основанный на SQL и объединяющий проверенные идеи существующих языков openCypher, PGQL, GSQL и G-CORE, включая запросы на поиск путей, компоновку графа (включение представлений) и поддержку схемы.
Публикацию стандарта планируется завершить в апреле 2024 года и выпустить под названием ISO/IEC 39075 Информационные технологии. Языки баз данных. GQL.
Ожидается, что стандарт GQL будет состоять из нескольких частей, которые включают:
✅спецификации из SQL/Framework и SQL/Foundation (ISO/IEC JTC1 9075:2016, части 1 и 2), в т.ч. некоторые скалярные типы данных, а также операции, функции и предикаты для них, модель транзакции (уровень изоляции, COMMIT, ROLLBACK и пр.), модель безопасности, модель клиента и модель сеанса;
✅шаблоны сопоставления графов (Graph Pattern Matching, GPM) c Property Graph Queries в SQL (SQL/PGQ:2023);
✅специальные возможности GQL, включая типы данных только для графов (вершина, ребро, путь);
✅графовые операции, не включенные в SQL:/PGQ:2023 (создание графа, вставка вершины/ребра, обновление и удаление), запросы;
✅графовый аналог SQL/Schemata.
SQL/PGQ содержит две основные возможности:
✔️Синтаксис для создания графового представления свойств поверх существующих таблиц SQL;
✔️Синтаксис для включения запроса графа свойств (GPM) в предложении SQL FROM.
Проект стандарта GQL основан на языке графовых шаблонов сопоставления и представляет собой полноценный язык БД, включая поддержку вариантов с фиксированной и гибкой схемой, а также
✅ DML-запросы на создание, чтение, обновление и удаление вершин/ребер графа;
✅ DDL-запросы на создание типа графа и самого графа.
Помимо SQL/PGQ в основе GQL лежит openCypher – реализация языка Cypher, который разработан в популярной графовой СУБД Neo4j.
В 2015 году был открыт исходный код Cypher, который затем трансформировался язык openCypher для включения возможностей обработки графов в различноые приложения и базы данных.
Хотя Cypher был изначально разработан в Neo4j, сегодня этот язык и его реализация в виде openCypher используется более чем в 10 продуктах (ArcadeDB, AnzoGraph DB, Katana Graph, Memgraph) и востребован десятками тысяч разработчиков, а также специалистами по Data Science и аналитиками данных.
Подобно SQL, Cypher и openCypher являются декларативными языками, позволяя пользователям просто указать, какие данные нужно получить, без объявления деталей реализации.
@BigDataSchool_ru
https://bigdataschool.ru/blog/opencypher-and-gql-overview.html
Что такое GQL и кто его разрабатывает
В начале 2017 года началась работа по созданию GQL (Graph Query Language) — международного стандартного языка для запросов графов.
Работа ведется под эгидой ISO SC32/WG3 и отражена в манифесте GQL от мая 2018 года.
GQL позиционируется как надежный язык декларативных графовых запросов, основанный на SQL и объединяющий проверенные идеи существующих языков openCypher, PGQL, GSQL и G-CORE, включая запросы на поиск путей, компоновку графа (включение представлений) и поддержку схемы.
Публикацию стандарта планируется завершить в апреле 2024 года и выпустить под названием ISO/IEC 39075 Информационные технологии. Языки баз данных. GQL.
Ожидается, что стандарт GQL будет состоять из нескольких частей, которые включают:
✅спецификации из SQL/Framework и SQL/Foundation (ISO/IEC JTC1 9075:2016, части 1 и 2), в т.ч. некоторые скалярные типы данных, а также операции, функции и предикаты для них, модель транзакции (уровень изоляции, COMMIT, ROLLBACK и пр.), модель безопасности, модель клиента и модель сеанса;
✅шаблоны сопоставления графов (Graph Pattern Matching, GPM) c Property Graph Queries в SQL (SQL/PGQ:2023);
✅специальные возможности GQL, включая типы данных только для графов (вершина, ребро, путь);
✅графовые операции, не включенные в SQL:/PGQ:2023 (создание графа, вставка вершины/ребра, обновление и удаление), запросы;
✅графовый аналог SQL/Schemata.
SQL/PGQ содержит две основные возможности:
✔️Синтаксис для создания графового представления свойств поверх существующих таблиц SQL;
✔️Синтаксис для включения запроса графа свойств (GPM) в предложении SQL FROM.
Проект стандарта GQL основан на языке графовых шаблонов сопоставления и представляет собой полноценный язык БД, включая поддержку вариантов с фиксированной и гибкой схемой, а также
✅ DML-запросы на создание, чтение, обновление и удаление вершин/ребер графа;
✅ DDL-запросы на создание типа графа и самого графа.
Помимо SQL/PGQ в основе GQL лежит openCypher – реализация языка Cypher, который разработан в популярной графовой СУБД Neo4j.
В 2015 году был открыт исходный код Cypher, который затем трансформировался язык openCypher для включения возможностей обработки графов в различноые приложения и базы данных.
Хотя Cypher был изначально разработан в Neo4j, сегодня этот язык и его реализация в виде openCypher используется более чем в 10 продуктах (ArcadeDB, AnzoGraph DB, Katana Graph, Memgraph) и востребован десятками тысяч разработчиков, а также специалистами по Data Science и аналитиками данных.
Подобно SQL, Cypher и openCypher являются декларативными языками, позволяя пользователям просто указать, какие данные нужно получить, без объявления деталей реализации.
@BigDataSchool_ru
https://bigdataschool.ru/blog/opencypher-and-gql-overview.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Что такое GQL и при чем здесь Cypher: новый стандарт языка запросов к графам
Кто и зачем создает аналог SQL для запросов к графовым базам данных, когда выйдет официал
#Datascience #статьи
Что такое векторная СУБД и при чем здесь ИИ
Как и следует из названия, векторная база хранит данные в виде векторов.
Это понятие из математики означает специализированное представление объектов в пространстве и представляет собой одномерную структуру данных, кортеж из одного или нескольких значений.
Векторы являются основой линейной алгебры и используются в Data Science при описании целевой переменной для реализации модели машинного обучения.
Благодаря своему одномерному характеру, векторное представление обучающих характеристик для ML-модели, т.н. фичей, занимает меньше места в памяти, что особенно важно для современных ИИ-приложений, от которых пользователей ожидает оперативного ответа.
Именно распространение ИИ, особенно связанное с появлением генеративных нейросетей (ChatGPT и пр.) в конце 2022 г. и их внедрением в различные сферы деятельности, стимулировало интерес к векторным СУБД.
Большие языковые модели, генеративный ИИ и семантический поиск основаны на векторном встраивании, типе представления данных, которое несет семантическую информацию для понимания контекста и поддержке долговременной памяти. Встраиваивания (embedding) генерируются ИИ-моделями ИИ и имеют очень много атрибутов (фичей), которые представляют различные измерения данных, нужные для понимания закономерностей, взаимосвязей и лежащих в их основе структур.
Чтобы эффективно управлять такими данными, нужен специализированный инструмент, которым и стали векторные СУБД.
Векторные базы данных оптимизированы для хранения векторных встраиваиваний и запросов к ним.
Традиционные скалярные базы данных не могут справиться со сложностью и масштабом векторных данных в реальном времени.
А векторные базы данных специально разработаны для обработки данных такого типа и обеспечивают производительность, масштабируемость и гибкость, необходимые для максимально эффективного использования данных, в т.ч. в ИИ-приложениях.
Они могут быстро и точно искать похожие элементы и анализировать огромные объемы данных, отлично масштабируются и подходят для использования в любом домене.
Завтра разберем: Как работает векторная база данных
@BigDataSchool_ru
https://bigdataschool.ru/blog/ai-and-vector-databases.html
Что такое векторная СУБД и при чем здесь ИИ
Как и следует из названия, векторная база хранит данные в виде векторов.
Это понятие из математики означает специализированное представление объектов в пространстве и представляет собой одномерную структуру данных, кортеж из одного или нескольких значений.
Векторы являются основой линейной алгебры и используются в Data Science при описании целевой переменной для реализации модели машинного обучения.
Благодаря своему одномерному характеру, векторное представление обучающих характеристик для ML-модели, т.н. фичей, занимает меньше места в памяти, что особенно важно для современных ИИ-приложений, от которых пользователей ожидает оперативного ответа.
Именно распространение ИИ, особенно связанное с появлением генеративных нейросетей (ChatGPT и пр.) в конце 2022 г. и их внедрением в различные сферы деятельности, стимулировало интерес к векторным СУБД.
Большие языковые модели, генеративный ИИ и семантический поиск основаны на векторном встраивании, типе представления данных, которое несет семантическую информацию для понимания контекста и поддержке долговременной памяти. Встраиваивания (embedding) генерируются ИИ-моделями ИИ и имеют очень много атрибутов (фичей), которые представляют различные измерения данных, нужные для понимания закономерностей, взаимосвязей и лежащих в их основе структур.
Чтобы эффективно управлять такими данными, нужен специализированный инструмент, которым и стали векторные СУБД.
Векторные базы данных оптимизированы для хранения векторных встраиваиваний и запросов к ним.
Традиционные скалярные базы данных не могут справиться со сложностью и масштабом векторных данных в реальном времени.
А векторные базы данных специально разработаны для обработки данных такого типа и обеспечивают производительность, масштабируемость и гибкость, необходимые для максимально эффективного использования данных, в т.ч. в ИИ-приложениях.
Они могут быстро и точно искать похожие элементы и анализировать огромные объемы данных, отлично масштабируются и подходят для использования в любом домене.
Завтра разберем: Как работает векторная база данных
@BigDataSchool_ru
https://bigdataschool.ru/blog/ai-and-vector-databases.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
ИИ и векторные базы данных: как это работает?
Как устроены векторные базы данных и почему они стали так популярны с распространением
#Datascience #статьи
Как работает векторная база данных
Последовательность применения векторной СУБД в ИИ-приложении можно представить таким образом:
▶️для создания векторных вложений контента, который надо проиндексировать, используется модель встраивания (embedding model);
▶️встраивание вектора вставляется в векторную базу данных со ссылкой на исходный контент, из которого было создано встраивание;
▶️когда приложение выдает запрос, используется ранее определенная модель встраивания для создания встраиваний для запроса к векторной базе данных похожих вложений, которые, в свою очередь, связаны с другим исходным контентом
@BigDataSchool_ru
https://bigdataschool.ru/blog/ai-and-vector-databases.html
Как работает векторная база данных
Последовательность применения векторной СУБД в ИИ-приложении можно представить таким образом:
▶️для создания векторных вложений контента, который надо проиндексировать, используется модель встраивания (embedding model);
▶️встраивание вектора вставляется в векторную базу данных со ссылкой на исходный контент, из которого было создано встраивание;
▶️когда приложение выдает запрос, используется ранее определенная модель встраивания для создания встраиваний для запроса к векторной базе данных похожих вложений, которые, в свою очередь, связаны с другим исходным контентом
@BigDataSchool_ru
https://bigdataschool.ru/blog/ai-and-vector-databases.html
#DataScience #статьи
Что такое гиперграф
Гиперграф — это графовая модель данных, в которой отношения (гиперребра) могут соединять любое количество заданных узлов. Можно сказать, что это обобщение графа, в котором каждым ребром могут соединяться не только две вершины, но и любые подмножества множества вершин. Гиперграфы часто используются при моделировании электрических цепей.
В обычном графе знаний (или графе свойств) отношения имеют только один начальный узел и один конечный узел. А в гиперграфе может быть любое количество узлов на обоих концах отношения.
Такие гиперграфы полезны, когда данные включают большое количество отношений много-ко-многим. Например, этот направленный граф показывает, что Алиса и Боб являются владельцами трех транспортных средств. Выразить эту связь можно с помощью всего одного гиперребра вместо 6 ребер в обычном графе знаний.
Пример разберем на сайте
@BigDataSchool_ru
https://bigdataschool.ru/blog/hypergraphs-and-hypergraphdb-overview.html
Что такое гиперграф
Гиперграф — это графовая модель данных, в которой отношения (гиперребра) могут соединять любое количество заданных узлов. Можно сказать, что это обобщение графа, в котором каждым ребром могут соединяться не только две вершины, но и любые подмножества множества вершин. Гиперграфы часто используются при моделировании электрических цепей.
В обычном графе знаний (или графе свойств) отношения имеют только один начальный узел и один конечный узел. А в гиперграфе может быть любое количество узлов на обоих концах отношения.
Такие гиперграфы полезны, когда данные включают большое количество отношений много-ко-многим. Например, этот направленный граф показывает, что Алиса и Боб являются владельцами трех транспортных средств. Выразить эту связь можно с помощью всего одного гиперребра вместо 6 ребер в обычном графе знаний.
Пример разберем на сайте
@BigDataSchool_ru
https://bigdataschool.ru/blog/hypergraphs-and-hypergraphdb-overview.html