#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,Arenadata,Greenplum, Kafka и Spark
5 популярных языков запросов к графам
Для продвижения нашего нового курса по графовым алгоритмам в бизнес-приложениях, сегод
#SQL #Greenplum #статьи
🗄️Как увеличить емкость базы данных: 4 подхода к масштабированию
Чтобы увеличить емкость СУБД, т.е. объем хранимых в ней данных, используются различные варианты масштабирования:
✅ Вертикальное, которое предполагает наращивание аппаратных ресурсов текущего сервера для обработки большей рабочей нагрузки, включая добавление дополнительной памяти, хранилища или мощности ЦП к существующему серверу. Этот вариант часто является самым простым и быстрым способом масштабирования СУБД, но может оказаться самым дорогим, поскольку требует покупки нового оборудования. Кроме того, бесконечно наращивать ресурсы компьютера не имеет смысла из-за физических ограничений, связанных со скоростью света: по достижении определенного предела увеличение объема памяти теряет смысл.
✅ Горизонтальное масштабирование предполагает добавление дополнительных серверов для распределения рабочей нагрузки. Это обеспечивает лучшую масштабируемость и отказоустойчивость, поскольку если один узел кластера выйдет из строя, другие узлы смогут справиться с ростом нагрузки. Однако, на практике горизонтальное масштабирование может оказаться сложнее в настройке и управлении, чем вертикальное.
✅ Использование массивно-параллельной обработки данных (MPP, Massively Parallel Processing), когда несколько серверов выполняют вычисления для параллельной обработки запросов. Это позволяет повысить производительность при работе с большими наборами данных, что полезно для рабочих нагрузок DWH и бизнес-аналитики. Также MPP-базы также можно масштабировать по горизонтали, чтобы справляться с еще большими рабочими нагрузками.
✅ Шардирование, что предполагает разделение большой базы данных на более мелкие управляемые фрагменты (шарды, shard), каждый из которых хранится на отдельном сервере, обеспечивая масштабируемость и отказоустойчивость. Шардирование БД также может повысить производительность SQL-запросов, которые могут выполняться на определенном сегменте, а не на всей базе данных. Однако, шардирование может быть сложным в настройке и управлении, а также может потребовать специальных навыков.
Как увеличить производительность и емкость хранилища Greenplum, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/how-to-expand-greenplum-cluster.html
🗄️Как увеличить емкость базы данных: 4 подхода к масштабированию
Чтобы увеличить емкость СУБД, т.е. объем хранимых в ней данных, используются различные варианты масштабирования:
✅ Вертикальное, которое предполагает наращивание аппаратных ресурсов текущего сервера для обработки большей рабочей нагрузки, включая добавление дополнительной памяти, хранилища или мощности ЦП к существующему серверу. Этот вариант часто является самым простым и быстрым способом масштабирования СУБД, но может оказаться самым дорогим, поскольку требует покупки нового оборудования. Кроме того, бесконечно наращивать ресурсы компьютера не имеет смысла из-за физических ограничений, связанных со скоростью света: по достижении определенного предела увеличение объема памяти теряет смысл.
✅ Горизонтальное масштабирование предполагает добавление дополнительных серверов для распределения рабочей нагрузки. Это обеспечивает лучшую масштабируемость и отказоустойчивость, поскольку если один узел кластера выйдет из строя, другие узлы смогут справиться с ростом нагрузки. Однако, на практике горизонтальное масштабирование может оказаться сложнее в настройке и управлении, чем вертикальное.
✅ Использование массивно-параллельной обработки данных (MPP, Massively Parallel Processing), когда несколько серверов выполняют вычисления для параллельной обработки запросов. Это позволяет повысить производительность при работе с большими наборами данных, что полезно для рабочих нагрузок DWH и бизнес-аналитики. Также MPP-базы также можно масштабировать по горизонтали, чтобы справляться с еще большими рабочими нагрузками.
✅ Шардирование, что предполагает разделение большой базы данных на более мелкие управляемые фрагменты (шарды, shard), каждый из которых хранится на отдельном сервере, обеспечивая масштабируемость и отказоустойчивость. Шардирование БД также может повысить производительность SQL-запросов, которые могут выполняться на определенном сегменте, а не на всей базе данных. Однако, шардирование может быть сложным в настройке и управлении, а также может потребовать специальных навыков.
Как увеличить производительность и емкость хранилища Greenplum, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/how-to-expand-greenplum-cluster.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Еще больше больших данных: масштабирование кластера Greenplum
Как увеличить емкость MPP-СУБД Greenplum, чтобы повысить объем данных и скорость их обработки: горизонтальное масштабирование кластера
#AirFlow #SQL #статьи
✴️Отладка конвейеров обработки данных в Apache AirFlow: проблемы и возможности
Практикующий дата-инженер знает, как бывает сложно найти ошибку во множестве конвейеров обработки данных, реализованных в виде DAG Apache AirFlow. Ошибка может скрываться как на уровне направленного ациклического графа, так и на уровне отдельно взятой задачи или оператора.
Тем не менее, в большинстве случаев отладка сводится к следующим шагам:
☑️собрать все объекты оператора
☑️собрать метаданных выполнения
☑️настроить панель оповещения и мониторинга на основе вышеупомянутых метаданных.
Для реализации этих шагов можно сделать собственное решение, используя инструменты с открытым исходным кодом, или воспользоваться внешним сервисом, который централизует метаданные, а также обеспечивает мониторинг и оповещения.
Кроме того, AirFlow поддерживает несколько механизмов логирования и генерации метрик для сбора, обработки и визуализации в нижестоящих системах.
В частности, AirFlow поддерживает уведомление об ошибках в режиме реального времени благодаря интеграции с Sentry – сервисом мониторинга производительности приложений и отслеживания ошибок, который можно развернуть в своей инфраструктуре или использовать в облачном варианте.
По умолчанию AirFlow поддерживает логирование в локальную файловую систему, записывая туда логи с веб-сервера, планировщика и worker’ов, исполняющих задачи. Это подходит для сред разработки и для быстрой отладки. Для облачных развертываний AirFlow есть обработчики ведения журнала в облачное хранилище AWS, Google Cloud и Azure. Параметры логирования задаются в файле конфигурации AirFlow, который должен быть доступен для всех процессов: веб-сервера, планировщика и worker’ов. Для производственных развертываний можно использовать FluentD для сбора логов и отправки их в места назначения, такие как Elasticsearch или Splunk, а также StatsD для сбора метрик и их отправки в Prometheus.
Однако, как уже было отмечено выше, чтобы собрать и визуализировать эти системные метрики, сперва необходимо поработать с операторами и задачами. В рамках AirFlow это реализуется средствами кластерной политики и обратных вызовов, чтобы отслеживать продолжительность и статусы задач, а также качество обрабатываемых данных.
Как это сделать, мы рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/dag-debagging-and-monitoring-in-airflow.html
✴️Отладка конвейеров обработки данных в Apache AirFlow: проблемы и возможности
Практикующий дата-инженер знает, как бывает сложно найти ошибку во множестве конвейеров обработки данных, реализованных в виде DAG Apache AirFlow. Ошибка может скрываться как на уровне направленного ациклического графа, так и на уровне отдельно взятой задачи или оператора.
Тем не менее, в большинстве случаев отладка сводится к следующим шагам:
☑️собрать все объекты оператора
☑️собрать метаданных выполнения
☑️настроить панель оповещения и мониторинга на основе вышеупомянутых метаданных.
Для реализации этих шагов можно сделать собственное решение, используя инструменты с открытым исходным кодом, или воспользоваться внешним сервисом, который централизует метаданные, а также обеспечивает мониторинг и оповещения.
Кроме того, AirFlow поддерживает несколько механизмов логирования и генерации метрик для сбора, обработки и визуализации в нижестоящих системах.
В частности, AirFlow поддерживает уведомление об ошибках в режиме реального времени благодаря интеграции с Sentry – сервисом мониторинга производительности приложений и отслеживания ошибок, который можно развернуть в своей инфраструктуре или использовать в облачном варианте.
По умолчанию AirFlow поддерживает логирование в локальную файловую систему, записывая туда логи с веб-сервера, планировщика и worker’ов, исполняющих задачи. Это подходит для сред разработки и для быстрой отладки. Для облачных развертываний AirFlow есть обработчики ведения журнала в облачное хранилище AWS, Google Cloud и Azure. Параметры логирования задаются в файле конфигурации AirFlow, который должен быть доступен для всех процессов: веб-сервера, планировщика и worker’ов. Для производственных развертываний можно использовать FluentD для сбора логов и отправки их в места назначения, такие как Elasticsearch или Splunk, а также StatsD для сбора метрик и их отправки в Prometheus.
Однако, как уже было отмечено выше, чтобы собрать и визуализировать эти системные метрики, сперва необходимо поработать с операторами и задачами. В рамках AirFlow это реализуется средствами кластерной политики и обратных вызовов, чтобы отслеживать продолжительность и статусы задач, а также качество обрабатываемых данных.
Как это сделать, мы рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/dag-debagging-and-monitoring-in-airflow.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Отладка конвейеров Apache AirFlow: операторы, кластерные политики и обратные вызовы задач
Как настроить мониторинг событий в AirFlow для отладки DAG или отдельной задачи: операторы, кластерные политики и обратные вызовы
#BigData #SQL #статьи
Динамическое объединение разделов
Согласно вычислительной модели MapReduce, shuffle-операции состоят из двух последовательных этапов:
1️⃣этап сопоставления (Map), который записывает блоки перемешивания, соответствующие настроенному количеству shuffle-разделов;
2️⃣этап свертки (Reduce), который считывает соответствующие shuffle-блоки, комбинирует их по количеству их разделов перемешивания, а затем последовательно запускает логику свертки для каждого объединенного блока данных.
Именно между этапами Map и Reduce работает динамическое объединение разделов: после этапа сопоставления до завершения перемешивания после записи всех блоков shuffle-данных вычисляется множество статистических данных, таких как количество записей и размер каждого из разделов, чтобы передать эти сведения в исполнительный механизм фреймворка.
Эта статистика используется для поиска оптимизации плана выполнения запросов, чтобы вычислить оптимальный целевой размер для объединенного раздела.
На основе вычисленного целевого размера выполняется оценка количества объединенных разделов в случайном порядке. Если это оценочное число меньше значения, определенного в конфигурации spark.sql.shuffle.partitions, динамическое объединение разделов динамически вставляет во время выполнения преобразование объединения, имеющее входной параметр в качестве предполагаемого количества объединенных перетасованных разделов.
Далее посмотрим на примере.
@BigDataSchool_ru
https://bigdataschool.ru/blog/dynamic-coalescing-in-spark-sql.html
Динамическое объединение разделов
Согласно вычислительной модели MapReduce, shuffle-операции состоят из двух последовательных этапов:
1️⃣этап сопоставления (Map), который записывает блоки перемешивания, соответствующие настроенному количеству shuffle-разделов;
2️⃣этап свертки (Reduce), который считывает соответствующие shuffle-блоки, комбинирует их по количеству их разделов перемешивания, а затем последовательно запускает логику свертки для каждого объединенного блока данных.
Именно между этапами Map и Reduce работает динамическое объединение разделов: после этапа сопоставления до завершения перемешивания после записи всех блоков shuffle-данных вычисляется множество статистических данных, таких как количество записей и размер каждого из разделов, чтобы передать эти сведения в исполнительный механизм фреймворка.
Эта статистика используется для поиска оптимизации плана выполнения запросов, чтобы вычислить оптимальный целевой размер для объединенного раздела.
На основе вычисленного целевого размера выполняется оценка количества объединенных разделов в случайном порядке. Если это оценочное число меньше значения, определенного в конфигурации spark.sql.shuffle.partitions, динамическое объединение разделов динамически вставляет во время выполнения преобразование объединения, имеющее входной параметр в качестве предполагаемого количества объединенных перетасованных разделов.
Далее посмотрим на примере.
@BigDataSchool_ru
https://bigdataschool.ru/blog/dynamic-coalescing-in-spark-sql.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Как механизм AQE выполняет динамическое объединение разделов в Apache Spark
На что влияет количество разделов в Spark SQL и как AQE динамически объединяет их после shuffle-операций: конфигурации spark.sql.adaptive
#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 для запросов к графовым базам данных, когда выйдет официал
#SQL #статьи
TimescaleDB для работы с данными временных рядов в PostgreSQL и Greenplum
Хотя временные ряды можно хранить в самом PostgreSQL и основанной на ней MPP-СУБД Greenplum безо всяких дополнений, TimescaleDB обеспечивает более высокую производительность на той же самой инфраструктуре благодаря гипертаблицам, партиционированным по отметке времени.
Например, бенчмаркинговое сравнение Clickhouse с TimescaleDB показали преимущество последнего на операциях вставки при пакетной обработке небольшого количества строк (100-300). Впрочем, при пакетной обработке строк от 5 000 до 15 000 строк вставку в ClickHouse выполняется быстрее.
TimescaleDB является open-source решением, которое расширяет возможности PostgreSQL для данных временных рядов. Оно обеспечивает автоматическое партиционирование во времени и пространстве (ключ разделения), а также полностью поддерживает SQL, сохраняя стандартный интерфейс PostgreSQL.
По сути, TimescaleDB является абстракцией (виртуальным представлением) многих отдельных таблиц, содержащих фактические данные. Это представление одной таблицы — гипертаблица, состоит из множества фрагментов, которые создаются путем разделения ее данных в одном или двух измерениях: по временному интервалу и (необязательно) ключу разделения.
Практически все взаимодействия пользователя с TimescaleDB осуществляются с помощью гипертаблиц: создание таблиц и индексов, их изменение, вставка и выбор данных.
Таким образом, расширение позволяет оперировать стандартными командами популярной объектно-реляционной СУБД, работая с данными временных рядов.
Это удобно, в том числе для мониторинга системных метрик, особенно когда речь идет о высоконагруженных системах. Поскольку Greenplum основана на PostgreSQL, эта MPP-СУБД также может использовать TimescaleDB. А визуализировать системные метрики можно с помощью типовых инструментов мониторинга, таких как Grafana и Prometheus.
Например, в Grafana уже встроена нативная поддержка TimescaleDB в качестве источника данных, поэтому можно прямо из Greenplum строить графики временных рядов без сложных SQL-запросов. А если ранее для мониторинга использовалась СУБД Prometheus, от него можно отказаться, с помощью адаптера перенести данные в TimescaleDB. Также можно считывать системные метрики ИТ-инфраструктуры с помощью плагина Telegraf и передавать их сразу в TimescaleDB, чтобы надежно хранить в Greenplum.
В заключение отметим, что выбор СУБД для анализа временных рядов зависит от нескольких факторов. Когда проект предполагает аналитику огромных массивов данных в реальном времени, причем скорость выполнения запроса более приоритетна, чем точность, ClickHouse отлично справится с этим.
Если помимо аналитических сценариев, СУБД ориентирована на быструю обработку транзакций с большими массивами данных, в т.ч. time-series, Greenplum/PostgreSQL и TimescaleDB, подойдут лучше. Кроме того, надо учитывать компетенции команды, которая будет разрабатывать и поддерживать решение.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/greenplum/time-series-data-processing-in-clickhouse-and-greenplum-postgresql.html
TimescaleDB для работы с данными временных рядов в PostgreSQL и Greenplum
Хотя временные ряды можно хранить в самом PostgreSQL и основанной на ней MPP-СУБД Greenplum безо всяких дополнений, TimescaleDB обеспечивает более высокую производительность на той же самой инфраструктуре благодаря гипертаблицам, партиционированным по отметке времени.
Например, бенчмаркинговое сравнение Clickhouse с TimescaleDB показали преимущество последнего на операциях вставки при пакетной обработке небольшого количества строк (100-300). Впрочем, при пакетной обработке строк от 5 000 до 15 000 строк вставку в ClickHouse выполняется быстрее.
TimescaleDB является open-source решением, которое расширяет возможности PostgreSQL для данных временных рядов. Оно обеспечивает автоматическое партиционирование во времени и пространстве (ключ разделения), а также полностью поддерживает SQL, сохраняя стандартный интерфейс PostgreSQL.
По сути, TimescaleDB является абстракцией (виртуальным представлением) многих отдельных таблиц, содержащих фактические данные. Это представление одной таблицы — гипертаблица, состоит из множества фрагментов, которые создаются путем разделения ее данных в одном или двух измерениях: по временному интервалу и (необязательно) ключу разделения.
Практически все взаимодействия пользователя с TimescaleDB осуществляются с помощью гипертаблиц: создание таблиц и индексов, их изменение, вставка и выбор данных.
Таким образом, расширение позволяет оперировать стандартными командами популярной объектно-реляционной СУБД, работая с данными временных рядов.
Это удобно, в том числе для мониторинга системных метрик, особенно когда речь идет о высоконагруженных системах. Поскольку Greenplum основана на PostgreSQL, эта MPP-СУБД также может использовать TimescaleDB. А визуализировать системные метрики можно с помощью типовых инструментов мониторинга, таких как Grafana и Prometheus.
Например, в Grafana уже встроена нативная поддержка TimescaleDB в качестве источника данных, поэтому можно прямо из Greenplum строить графики временных рядов без сложных SQL-запросов. А если ранее для мониторинга использовалась СУБД Prometheus, от него можно отказаться, с помощью адаптера перенести данные в TimescaleDB. Также можно считывать системные метрики ИТ-инфраструктуры с помощью плагина Telegraf и передавать их сразу в TimescaleDB, чтобы надежно хранить в Greenplum.
В заключение отметим, что выбор СУБД для анализа временных рядов зависит от нескольких факторов. Когда проект предполагает аналитику огромных массивов данных в реальном времени, причем скорость выполнения запроса более приоритетна, чем точность, ClickHouse отлично справится с этим.
Если помимо аналитических сценариев, СУБД ориентирована на быструю обработку транзакций с большими массивами данных, в т.ч. time-series, Greenplum/PostgreSQL и TimescaleDB, подойдут лучше. Кроме того, надо учитывать компетенции команды, которая будет разрабатывать и поддерживать решение.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/greenplum/time-series-data-processing-in-clickhouse-and-greenplum-postgresql.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Анализ временных рядов в ClickHouse и Greenplum
Анализ временных рядов нужен не только в Data Science, но и в мониторинге системных событий. Ч
#SQL #статьи
Варианты использования и ограничения JDBC-драйвера
Новый JDBC-драйвер 6 версии рекомендуется применять для всех приложений и инструментов, которые используют его предыдущие версии (4 или 5), а также имеют интеграции с SQL-платформами миграции данных и ETL-инструментами, которые не предлагают интеграцию на основе общего Java-драйвера Neo4j.
Также он хорошо подходит для случаев, когда есть существующие интеграции, которые доступны только для чтения, но нужна и запись.
Наконец, благодаря поддержке Jakarta EE, Spring JDBCTemplate и других универсальных возможностей JDBC API 4.3, он отлично пригодится при реализации распределенных транзакций.
Наконец, JDBC-драйвер Neo4j снижает порог входа в эту NoSQL-технологию для разработчиков, которые знакомы с JDBC и хотят продолжать использовать этот API, но с Cypher и графовой СУБД. При этом нет необходимости перепроектировать приложение, созданное на основе общего Java-драйвера Neo4j. Если экосистема уже обеспечивает интеграцию более высокого уровня на основе общего Java-драйвера Neo4j, например Spring Data Neo4j (SDN) для Spring, переход пройдет безболезненно. Однако, JDBC-драйвер не стоит использовать, когда приложение и так работает с общим Java-драйвером и изменения не требуются.
Также стоит отметить ограничения JDBC-драйвер Neo4j:
✔️метаданные базы данных извлекаются максимально эффективно с использованием существующих методов схемы Neo4j, таких как labels(), db.schema.nodeTypeProperties();
✔️узлы с несколькими метками не сопоставляются с названиями таблиц, в отличие от узлов с одной меткой;
✔️нет надежного способа всегда определять тип данных для свойств на узлах, не читая их все, чего драйвер не делает;
✔️некоторые функции JDBC еще не поддерживаются, например, CallableStatement(), а некоторые функции не будут поддерживаться никогда;
✔️транслятор SQL-запросов в Cypher поддерживает только ограниченное подмножество предложений и конструкций, которые могут быть семантически эквивалентны при переводе в Cypher;
✔️нет единого правильного способа сопоставить JOIN-утверждения с отношениями;
✔️не обеспечивается автоматическое изменение или выравнивание наборов результатов, как это было в предыдущей версии. При запросе узлов, связей, путей или сопоставлений, которые должны использовать метод getObject() в наборах результатов, их надо привести к соответствующему типу, который есть в пакете neo4j.jdbc.values. Однако, транслятор SQL в Cypher при подключении к базе данных выяснит, какие свойства имеют метки, и превратит в отдельные столбцы узлов и связей, как это ожидается при выполнении оператора SELECT.
Впрочем, несмотря на эти ограничения, новый JDBC-драйвер Neo4j предоставляет разработчику довольно много возможностей по работе с этой графовой СУБД. Например, другие драйверы с возможность перевода SQL в Cypher доступны только для чтения и не поддерживают операторы записи.
Поэтому они не могут использоваться для сценариев использования ETL, направленных на передачу данных в Neo4j.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/neo4j/jdbc-driver-neo4j-6-release-overview.html
Варианты использования и ограничения JDBC-драйвера
Новый JDBC-драйвер 6 версии рекомендуется применять для всех приложений и инструментов, которые используют его предыдущие версии (4 или 5), а также имеют интеграции с SQL-платформами миграции данных и ETL-инструментами, которые не предлагают интеграцию на основе общего Java-драйвера Neo4j.
Также он хорошо подходит для случаев, когда есть существующие интеграции, которые доступны только для чтения, но нужна и запись.
Наконец, благодаря поддержке Jakarta EE, Spring JDBCTemplate и других универсальных возможностей JDBC API 4.3, он отлично пригодится при реализации распределенных транзакций.
Наконец, JDBC-драйвер Neo4j снижает порог входа в эту NoSQL-технологию для разработчиков, которые знакомы с JDBC и хотят продолжать использовать этот API, но с Cypher и графовой СУБД. При этом нет необходимости перепроектировать приложение, созданное на основе общего Java-драйвера Neo4j. Если экосистема уже обеспечивает интеграцию более высокого уровня на основе общего Java-драйвера Neo4j, например Spring Data Neo4j (SDN) для Spring, переход пройдет безболезненно. Однако, JDBC-драйвер не стоит использовать, когда приложение и так работает с общим Java-драйвером и изменения не требуются.
Также стоит отметить ограничения JDBC-драйвер Neo4j:
✔️метаданные базы данных извлекаются максимально эффективно с использованием существующих методов схемы Neo4j, таких как labels(), db.schema.nodeTypeProperties();
✔️узлы с несколькими метками не сопоставляются с названиями таблиц, в отличие от узлов с одной меткой;
✔️нет надежного способа всегда определять тип данных для свойств на узлах, не читая их все, чего драйвер не делает;
✔️некоторые функции JDBC еще не поддерживаются, например, CallableStatement(), а некоторые функции не будут поддерживаться никогда;
✔️транслятор SQL-запросов в Cypher поддерживает только ограниченное подмножество предложений и конструкций, которые могут быть семантически эквивалентны при переводе в Cypher;
✔️нет единого правильного способа сопоставить JOIN-утверждения с отношениями;
✔️не обеспечивается автоматическое изменение или выравнивание наборов результатов, как это было в предыдущей версии. При запросе узлов, связей, путей или сопоставлений, которые должны использовать метод getObject() в наборах результатов, их надо привести к соответствующему типу, который есть в пакете neo4j.jdbc.values. Однако, транслятор SQL в Cypher при подключении к базе данных выяснит, какие свойства имеют метки, и превратит в отдельные столбцы узлов и связей, как это ожидается при выполнении оператора SELECT.
Впрочем, несмотря на эти ограничения, новый JDBC-драйвер Neo4j предоставляет разработчику довольно много возможностей по работе с этой графовой СУБД. Например, другие драйверы с возможность перевода SQL в Cypher доступны только для чтения и не поддерживают операторы записи.
Поэтому они не могут использоваться для сценариев использования ETL, направленных на передачу данных в Neo4j.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/neo4j/jdbc-driver-neo4j-6-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Обновленный JDBC-драйвер Neo4j: возможности и ограничения
Что не так с общим Java-драйвером Neo4j, зачем нужен JDBC-драйвер, какие функции он поддерживае
#SQL #Greenplum #СУБД
🟰Параллельная обработка SQL-запросов в Greenplum
Как координатор Greenplum на мастер-хосте рассылает сегментам планы выполнения запросов, что такое курсор параллельного получения результатов оператора SELECT и каким образом его использовать для аналитики больших данных в этой MPP-СУБД.
❗Особенности рассылки планов SQL-запросов в Greenplum на выполнение
Хотя Greenplum основана на PostgreSQL, некоторые механизмы работы этих СУБД отличаются. Например, поддержка массово-параллельной загрузки данных и централизованная архитектура кластера Greenplum обусловливает некоторые особенности обработки SQL-запросов в этой СУБД.
Полная статья: https://bigdataschool.ru/blog/news/greenplum/parallel-execution-of-sql-queries-in-greenplum.html
Курсы: https://bigdataschool.ru/courses/greenplum-for-data-engineers
https://bigdataschool.ru/courses/greenplum-arenadata-administration
Наш сайт: https://bigdataschool.ru/
🟰Параллельная обработка SQL-запросов в Greenplum
Как координатор Greenplum на мастер-хосте рассылает сегментам планы выполнения запросов, что такое курсор параллельного получения результатов оператора SELECT и каким образом его использовать для аналитики больших данных в этой MPP-СУБД.
❗Особенности рассылки планов SQL-запросов в Greenplum на выполнение
Хотя Greenplum основана на PostgreSQL, некоторые механизмы работы этих СУБД отличаются. Например, поддержка массово-параллельной загрузки данных и централизованная архитектура кластера Greenplum обусловливает некоторые особенности обработки SQL-запросов в этой СУБД.
Полная статья: https://bigdataschool.ru/blog/news/greenplum/parallel-execution-of-sql-queries-in-greenplum.html
Курсы: https://bigdataschool.ru/courses/greenplum-for-data-engineers
https://bigdataschool.ru/courses/greenplum-arenadata-administration
Наш сайт: https://bigdataschool.ru/
#Spark #SQL #DataFrame
8️⃣Источники данных Apache Spark
❓Какие источники исходных данных поддерживает Apache Spark для пакетной и потоковой обработки, обеспечивая отказоустойчивые вычисления в большом масштабе средствами SQL и Structured Streaming.
Источники данных Apache Spark SQL и структурированной потоковой передачи
Будучи фреймворком для создания распределенных приложений обработки больших объемов данных, Apache Spark может подключаться к разным источникам этих данных, в зависимости от используемого API.
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-data-sources.html
Курсы: https://bigdataschool.ru/courses/apache-spark-core
https://bigdataschool.ru/courses/apache-spark-for-data-engineer
https://bigdataschool.ru/courses/apache-spark-graphframe
https://bigdataschool.ru/courses/apache-spark-machine-learning
https://bigdataschool.ru/courses/apache-spark-sql
https://bigdataschool.ru/courses/apache-spark-structured-streaming
Наш сайт: https://bigdataschool.ru/
8️⃣Источники данных Apache Spark
❓Какие источники исходных данных поддерживает Apache Spark для пакетной и потоковой обработки, обеспечивая отказоустойчивые вычисления в большом масштабе средствами SQL и Structured Streaming.
Источники данных Apache Spark SQL и структурированной потоковой передачи
Будучи фреймворком для создания распределенных приложений обработки больших объемов данных, Apache Spark может подключаться к разным источникам этих данных, в зависимости от используемого API.
Полная статья: https://bigdataschool.ru/blog/news/spark/spark-data-sources.html
Курсы: https://bigdataschool.ru/courses/apache-spark-core
https://bigdataschool.ru/courses/apache-spark-for-data-engineer
https://bigdataschool.ru/courses/apache-spark-graphframe
https://bigdataschool.ru/courses/apache-spark-machine-learning
https://bigdataschool.ru/courses/apache-spark-sql
https://bigdataschool.ru/courses/apache-spark-structured-streaming
Наш сайт: https://bigdataschool.ru/
#Kafka #Decodable #SQL
Пример потокового конвейера из Kafka в Elasticsearch на платформе Decodable
Практическая демонстрация потокового SQL-конвейера, который преобразует данные, потребленные из Apache Kafka, и записывает результаты в Elasticsearch, используя Debezium-коннекторы и задания Apache Flink в облачной платформе Decodable.
Полная статья: https://bigdataschool.ru/blog/news/kafka/from-kafka-to-elasticsearch-with-sql-pipeline-on-decodable.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-basics https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Пример потокового конвейера из Kafka в Elasticsearch на платформе Decodable
Практическая демонстрация потокового SQL-конвейера, который преобразует данные, потребленные из Apache Kafka, и записывает результаты в Elasticsearch, используя Debezium-коннекторы и задания Apache Flink в облачной платформе Decodable.
Полная статья: https://bigdataschool.ru/blog/news/kafka/from-kafka-to-elasticsearch-with-sql-pipeline-on-decodable.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-basics https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#FINAL #ClickHouse #SQL
Модификатор FINAL в ClickHouse: как не выстрелить себе в ногу?
Что такое модификатор FINAL в SELECT-запросе ClickHouse, с какими табличными движками он работает, почему снижает производительность и как этого избежать. Тонкости потокового выполнения SQL-запросов в колоночной СУБД.
Зачем в SELECT-запросе ClickHouse нужен модификатор FINAL?
Хотя SQL-запросы в ClickHouse имеют типовую структуру, их реализация зависит от используемого движка таблиц. Например, запрос на выборку SELECT, который выполняет получение данных, выглядит так (в квадратных скобках показаны опциональные ключевые слова):
Полная статья: https://bigdataschool.ru/blog/news/clickhouse/clickhouse-final-in-select-query.html
Курс: https://bigdataschool.ru/courses/clickhouse
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Модификатор FINAL в ClickHouse: как не выстрелить себе в ногу?
Что такое модификатор FINAL в SELECT-запросе ClickHouse, с какими табличными движками он работает, почему снижает производительность и как этого избежать. Тонкости потокового выполнения SQL-запросов в колоночной СУБД.
Зачем в SELECT-запросе ClickHouse нужен модификатор FINAL?
Хотя SQL-запросы в ClickHouse имеют типовую структуру, их реализация зависит от используемого движка таблиц. Например, запрос на выборку SELECT, который выполняет получение данных, выглядит так (в квадратных скобках показаны опциональные ключевые слова):
Полная статья: https://bigdataschool.ru/blog/news/clickhouse/clickhouse-final-in-select-query.html
Курс: https://bigdataschool.ru/courses/clickhouse
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#ApacheKafka #RisingWave #SQL
Потоковая агрегация событий из Apache Kafka в RisingWave
Практическая демонстрация потоковой агрегации событий пользовательского поведений из Apache Kafka с записью результатов в Redis на платформе RisingWave: примеры Python-кода и конвейера из SQL-инструкций.
Постановка задачи
Одной из ярких тенденций в современном стеке Big Data сегодня стали платформы данных, которые позволяют интегрировать разные системы между собой, поддерживая как пакетную, так и потоковую передачу.
Статья: https://bigdataschool.ru/blog/news/kafka/streaming-aggregation-from-kafka-on-risingwave.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/data-architecture https://bigdataschool.ru/courses/practice-data-architecture
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковая агрегация событий из Apache Kafka в RisingWave
Практическая демонстрация потоковой агрегации событий пользовательского поведений из Apache Kafka с записью результатов в Redis на платформе RisingWave: примеры Python-кода и конвейера из SQL-инструкций.
Постановка задачи
Одной из ярких тенденций в современном стеке Big Data сегодня стали платформы данных, которые позволяют интегрировать разные системы между собой, поддерживая как пакетную, так и потоковую передачу.
Статья: https://bigdataschool.ru/blog/news/kafka/streaming-aggregation-from-kafka-on-risingwave.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/data-architecture https://bigdataschool.ru/courses/practice-data-architecture
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Greenplum #SQL #MVCC
Транзакции и блокировки в Greenplum
Какие SQL-команды есть в Greenplum для транзакционной обработки данных, как MVCC исключает явные блокировки, можно ли установить их вручную и как это сделать: режимы блокировки и глобальный детектор взаимоблокировок в MPP-СУБД.
Транзакции, MVCC и режимы блокировки Greenplum
Про изоляцию транзакций в Greenplum и Arenadata DB мы уже писали здесь. Транзакции позволяют объединить несколько SQL-операторов в одну операцию, чтобы выполнить их атомарно, т.е. все или ни одной.
Статья
Курсы: GPDE GRAD
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Транзакции и блокировки в Greenplum
Какие SQL-команды есть в Greenplum для транзакционной обработки данных, как MVCC исключает явные блокировки, можно ли установить их вручную и как это сделать: режимы блокировки и глобальный детектор взаимоблокировок в MPP-СУБД.
Транзакции, MVCC и режимы блокировки Greenplum
Про изоляцию транзакций в Greenplum и Arenadata DB мы уже писали здесь. Транзакции позволяют объединить несколько SQL-операторов в одну операцию, чтобы выполнить их атомарно, т.е. все или ни одной.
Статья
Курсы: GPDE GRAD
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Kafka #SQL #RisingWave
Потоковая агрегация данных из Kafka на SQL в RisingWave: пример
Как соединить данные из разных топиков Apache Kafka с помощью пары SQL-запросов: коннекторы, материализованные представления и потоковая база данных вместо полноценного потребителя. Подробная демонстрация запросов в RisingWave.
Проектирование и реализация потоковой агрегации данных из Kafka в RisingWave
Вчера я показывала пример потоковой агрегации данных из разных топиков Kafka с помощью Python-приложения, которое потребляет данные о пользователях и событиях их поведения на сайтах из разных топиков Kafka и соединяет их по ключевому идентификатору. Сегодня рассмотрим, как решить эту задачу быстрее с помощью потоковой базы данных RisingWave и коннекторов к Kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковая агрегация данных из Kafka на SQL в RisingWave: пример
Как соединить данные из разных топиков Apache Kafka с помощью пары SQL-запросов: коннекторы, материализованные представления и потоковая база данных вместо полноценного потребителя. Подробная демонстрация запросов в RisingWave.
Проектирование и реализация потоковой агрегации данных из Kafka в RisingWave
Вчера я показывала пример потоковой агрегации данных из разных топиков Kafka с помощью Python-приложения, которое потребляет данные о пользователях и событиях их поведения на сайтах из разных топиков Kafka и соединяет их по ключевому идентификатору. Сегодня рассмотрим, как решить эту задачу быстрее с помощью потоковой базы данных RisingWave и коннекторов к Kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#SQL #Kafka #Redis #RisingWave
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis: демонстрация ETL-конвейера на материализованных представлениях в RisingWave.
Постановка задачи и проектирование потоковой системы
Продолжая недавний пример потоковой агрегации данных из разных топиков Kafka с помощью SQL-запросов, сегодня расширим потоковый конвейер в RisingWave, добавив приемник данных – key-value хранилище Redis. RisingWave – это распределенная реляционная СУБД, которая позволяет работать с потоками данных как с обычными таблицами через типовые SQL-запросы.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis: демонстрация ETL-конвейера на материализованных представлениях в RisingWave.
Постановка задачи и проектирование потоковой системы
Продолжая недавний пример потоковой агрегации данных из разных топиков Kafka с помощью SQL-запросов, сегодня расширим потоковый конвейер в RisingWave, добавив приемник данных – key-value хранилище Redis. RisingWave – это распределенная реляционная СУБД, которая позволяет работать с потоками данных как с обычными таблицами через типовые SQL-запросы.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis:
#ApacheFlink #DataStream #SQL #1.20
Apache Flink 1.20: обзор свежего выпуска
2 августа 2024 года вышел свежий релиз Apache Flink. Знакомимся с главными новинками выпуска 1.20 для упрощения потоковой обработки данных в мощных управляемых конвейерах: новые материализованные таблицы, единый механизм слияния файлов для контрольных точек, улучшения DataStream API и пакетных операций.
Улучшения Flink SQL
Начнем с новинок Flink SQL, одной из которых стало введение новой материализованной таблицы для упрощения конвейеров данных и синтаксиса, связанного с каталогами. Новая материализованная таблица предназначена для упрощения разработки конвейеров обработки данных, а также упрощения пакетных и потоковых операций.
Статья
Курс: FLINK
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Apache Flink 1.20: обзор свежего выпуска
2 августа 2024 года вышел свежий релиз Apache Flink. Знакомимся с главными новинками выпуска 1.20 для упрощения потоковой обработки данных в мощных управляемых конвейерах: новые материализованные таблицы, единый механизм слияния файлов для контрольных точек, улучшения DataStream API и пакетных операций.
Улучшения Flink SQL
Начнем с новинок Flink SQL, одной из которых стало введение новой материализованной таблицы для упрощения конвейеров данных и синтаксиса, связанного с каталогами. Новая материализованная таблица предназначена для упрощения разработки конвейеров обработки данных, а также упрощения пакетных и потоковых операций.
Статья
Курс: FLINK
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Spark #SQL #Dynamic #Partition #Pruning
Динамическое сокращение разделов в Spark SQL
Что такое Dynamic Partition Pruning в Spark SQL, как работает этот метод оптимизации пакетных запросов, зачем его использовать в задачах аналитики больших данных, и каким образом повысить эффективность его практического применения.
Что такое Dynamic Partition Pruning и зачем это нужно в Spark SQL
Параллельная обработка данных в Apache Spark обеспечивается благодаря их разделению. Каждый раздел обрабатывается отдельным процессом (исполнителем). Поэтому можно сказать, что раздел в Spark является единицей параллелизма. Однако, слишком большое количество разделов приводит к потере параллелизма, поскольку 1 исполнитель Spark может обрабатывать только 1 раздел в единицу времени.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Динамическое сокращение разделов в Spark SQL
Что такое Dynamic Partition Pruning в Spark SQL, как работает этот метод оптимизации пакетных запросов, зачем его использовать в задачах аналитики больших данных, и каким образом повысить эффективность его практического применения.
Что такое Dynamic Partition Pruning и зачем это нужно в Spark SQL
Параллельная обработка данных в Apache Spark обеспечивается благодаря их разделению. Каждый раздел обрабатывается отдельным процессом (исполнителем). Поэтому можно сказать, что раздел в Spark является единицей параллелизма. Однако, слишком большое количество разделов приводит к потере параллелизма, поскольку 1 исполнитель Spark может обрабатывать только 1 раздел в единицу времени.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Photon #SQL #Spark #Databricks
Photon: новый векторизованный движок запросов Spark SQL от Databricks
Зачем Databricks выпустила новый движок выполнения запросов Spark SQL для ML-приложений, как он работает и где его настроить: возможности и ограничения Photon Engine.
Преимущества Photon Engine для ML-нагрузок Spark-приложений
Чтобы сделать Apache Apark еще быстрее, разработчики Databricks выпустили новый движок выполнения запросов — Photon Engine. Это высокопроизводительный механизм запросов, который может быстрее запускать Spark SQL и выполнят вычисления над датафреймами, снижая общую стоимость рабочей нагрузки.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Photon: новый векторизованный движок запросов Spark SQL от Databricks
Зачем Databricks выпустила новый движок выполнения запросов Spark SQL для ML-приложений, как он работает и где его настроить: возможности и ограничения Photon Engine.
Преимущества Photon Engine для ML-нагрузок Spark-приложений
Чтобы сделать Apache Apark еще быстрее, разработчики Databricks выпустили новый движок выполнения запросов — Photon Engine. Это высокопроизводительный механизм запросов, который может быстрее запускать Spark SQL и выполнят вычисления над датафреймами, снижая общую стоимость рабочей нагрузки.
Статья
Курсы: CORS SPOT SPARK MLSP GRAS
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"