#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по Spark.
🍱Какой язык используется при Maven-сборке?
Тест по Spark.
🍱Какой язык используется при Maven-сборке?
Anonymous Quiz
4%
HTML
9%
UML
13%
XMLS
74%
XML
#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
#python #machinelearning #статьи
📐Логистическая регрессия — это алгоритм машинного обучения, который используется для решения задачи бинарной классификации, то есть разделения данных на два класса. Она получила свое название благодаря тому, что использует логистическую функцию для прогнозирования вероятности принадлежности объекта к одному из классов.
По своей сути логистическая регрессия просто берет уравнение линейной регрессии и использует его как параметр сигмовидной функции.
В целом, логистическая регрессия — это мощный инструмент для решения задач бинарной и многоклассовой классификации в Python. Она проста в использовании и предоставляет множество метрик для оценки качества работы модели.
➕Плюсы логистической регрессии:
1. Это относительно простой алгоритм, который требует небольшого количества вычислительных ресурсов и может быть эффективно использован для решения большого количества задач классификации.
2. Интерпретируемость: логистическая регрессия позволяет понимать, какие переменные влияют на классификацию и каким образом.
3. Работает хорошо на небольших наборах данных: логистическая регрессия показывает хорошие результаты на небольших наборах данных.
4. Небольшая вероятность переобучения: логистическая регрессия склонна к менее переобучению, поскольку она не имеет множества параметров, которые нужно оптимизировать.
➖Минусы логистической регрессии:
1. Требуется нормализация признаков: логистическая регрессия требует нормализации признаков, чтобы гарантировать, что признаки вносят одинаковый вклад в модель.
2. Работает плохо на сложных задачах: может работать плохо на задачах с большим количеством признаков или сложной структурой данных.
3. Линейность: логистическая регрессия работает только с линейными границами решений, что ограничивает ее способность решать сложные задачи классификации.
4. Низкая точность: логистическая регрессия может показывать низкую точность, если классы не являются линейно разделимыми.
@BigDataSchool_ru
https://python-school.ru/blog/logisticregression/
📐Логистическая регрессия — это алгоритм машинного обучения, который используется для решения задачи бинарной классификации, то есть разделения данных на два класса. Она получила свое название благодаря тому, что использует логистическую функцию для прогнозирования вероятности принадлежности объекта к одному из классов.
По своей сути логистическая регрессия просто берет уравнение линейной регрессии и использует его как параметр сигмовидной функции.
В целом, логистическая регрессия — это мощный инструмент для решения задач бинарной и многоклассовой классификации в Python. Она проста в использовании и предоставляет множество метрик для оценки качества работы модели.
➕Плюсы логистической регрессии:
1. Это относительно простой алгоритм, который требует небольшого количества вычислительных ресурсов и может быть эффективно использован для решения большого количества задач классификации.
2. Интерпретируемость: логистическая регрессия позволяет понимать, какие переменные влияют на классификацию и каким образом.
3. Работает хорошо на небольших наборах данных: логистическая регрессия показывает хорошие результаты на небольших наборах данных.
4. Небольшая вероятность переобучения: логистическая регрессия склонна к менее переобучению, поскольку она не имеет множества параметров, которые нужно оптимизировать.
➖Минусы логистической регрессии:
1. Требуется нормализация признаков: логистическая регрессия требует нормализации признаков, чтобы гарантировать, что признаки вносят одинаковый вклад в модель.
2. Работает плохо на сложных задачах: может работать плохо на задачах с большим количеством признаков или сложной структурой данных.
3. Линейность: логистическая регрессия работает только с линейными границами решений, что ограничивает ее способность решать сложные задачи классификации.
4. Низкая точность: логистическая регрессия может показывать низкую точность, если классы не являются линейно разделимыми.
@BigDataSchool_ru
https://python-school.ru/blog/logisticregression/
Корпоративные курсы Python в Big Data и Machine Learning
Линейные модели для классификации: логистическая регрессия - Корпоративные курсы Python в Big Data и Machine Learning
В прошлой статье мы говорили о регуляризации, в этой рассмотрим такую линейную модель для решения задачи классификации как логистическая регрессия. Линейные модели для классификации: логистическая регрессия В мире Data science задача классификации является…
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по Spark.
🍰Что является базовой структурой данных в реляционных СУБД?
Тест по Spark.
🍰Что является базовой структурой данных в реляционных СУБД?
Anonymous Quiz
92%
связанные таблицы
0%
сетевые таблицы
8%
граф
0%
стек
#python #machinelearning #статьи
🖍️Модели для классификации: k ближайших соседей
В области Data science и машинного обучения существует множество алгоритмов для решения задач классификации. Один из наиболее распространенных алгоритмов — это k ближайших соседей, который используется для классификации объектов на основе их близости к другим объектам в обучающей выборке.
Алгоритм k ближайших соседей основан на принципе близости объектов в пространстве признаков. Он состоит в следующем: для каждого объекта из тестовой выборки находим k ближайших соседей из обучающей выборки, и классифицируем объект на основе классов его соседей. Класс, который наиболее часто встречается среди соседей, и будет классом, к которому относится исходный объект.
В Python существует множество библиотек, которые позволяют использовать алгоритм k ближайших соседей для решения задач классификации. Одной из самых популярных является библиотека Scikit-learn.
Преимущества алгоритма k ближайших соседей в задачах классификации заключаются в его простоте и интуитивности. Однако, он может быть неэффективен в случаях, когда обучающая выборка имеет большое количество атрибутов или объектов, поскольку поиск ближайших соседей может быть очень ресурсоемким.
Кроме того, выбор оптимального значения k может оказаться нетривиальной задачей. Слишком маленькое значение k может привести к переобучению модели, тогда как слишком большое значение k может привести к недообучению модели.
Для решения этих проблем существуют различные техники, как перекрестная проверка и оптимизация параметров.
В Python можно легко реализовать алгоритм k ближайших соседей с помощью библиотеки Scikit-learn.
Далее мы попробуем реализовать его.
@BigDataSchool_ru
https://python-school.ru/blog/knnclassifier/
🖍️Модели для классификации: k ближайших соседей
В области Data science и машинного обучения существует множество алгоритмов для решения задач классификации. Один из наиболее распространенных алгоритмов — это k ближайших соседей, который используется для классификации объектов на основе их близости к другим объектам в обучающей выборке.
Алгоритм k ближайших соседей основан на принципе близости объектов в пространстве признаков. Он состоит в следующем: для каждого объекта из тестовой выборки находим k ближайших соседей из обучающей выборки, и классифицируем объект на основе классов его соседей. Класс, который наиболее часто встречается среди соседей, и будет классом, к которому относится исходный объект.
В Python существует множество библиотек, которые позволяют использовать алгоритм k ближайших соседей для решения задач классификации. Одной из самых популярных является библиотека Scikit-learn.
Преимущества алгоритма k ближайших соседей в задачах классификации заключаются в его простоте и интуитивности. Однако, он может быть неэффективен в случаях, когда обучающая выборка имеет большое количество атрибутов или объектов, поскольку поиск ближайших соседей может быть очень ресурсоемким.
Кроме того, выбор оптимального значения k может оказаться нетривиальной задачей. Слишком маленькое значение k может привести к переобучению модели, тогда как слишком большое значение k может привести к недообучению модели.
Для решения этих проблем существуют различные техники, как перекрестная проверка и оптимизация параметров.
В Python можно легко реализовать алгоритм k ближайших соседей с помощью библиотеки Scikit-learn.
Далее мы попробуем реализовать его.
@BigDataSchool_ru
https://python-school.ru/blog/knnclassifier/
Корпоративные курсы Python в Big Data и Machine Learning
Модели для классификации: k ближайших соседей
k ближайших соседей – это базовый инструмент любого Data Scientist. В данной статье разберемся с этим алгоритмом.
#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, чтобы повысить объем данных и скорость их обработки: горизонтальное масштабирование кластера
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по Spark.
📂Какой файл формируется при сборке приложения?
Тест по Spark.
📂Какой файл формируется при сборке приложения?
Anonymous Quiz
39%
исполняемый файл
22%
конфигурационный файл
26%
файл компиляции
13%
файл сборки
#MLOps #ML #статьи
👁️🗨️Что общего у FastAPI с BentoML и при чем здесь MLOps
С точки зрения промышленной эксплуатации, в проектах машинного обучения следует фокусироваться не только и не столько на точности самих алгоритмов Machine Learning. Огромного внимания требует автоматизация рутинных процессов развертывания и сопровождения ML-моделей, что превратилось в целую концепцию под названием MLOps. Поскольку это направление инженерной науки о данных еще довольно молодое, в нем постоянно появляются новые идеи и инструменты.
В частности, одним из самых популярных MLOps-средств считается FastAPI – высокопроизводительный веб-фреймворк для создания API с помощью стандартной аннотации типов Python 3.6+. ML-инженеры часто используют его для развертывания своих моделей в качестве сервисов API.
Впрочем, FastAPI используется не только в ML-проектах. Этот фреймворк отлично подходит для быстрого создания любых REST-приложений на Python. Его дополнительным преимуществом является автогенерация документации API в формате Swagger (открытый стандарт OpenAPI 3) и JSON Schema. Пример создания такого REST API с тестированием методов в Swagger UI мы описывали в этой статье на блоге нашей Школы прикладного бизнес-анализа.
Возвращаясь к тему MLOps, отметим, что способность FastAPI генерировать документацию поддерживает идеи MLOps, а потому этот фреймворк можно отнести к набору инструментальных средств MLOps-Инженера. Однако, это далеко не единственный инструмент этой категории.
Сюда же относится BentoML – открытая библиотека для быстрого создания MVP систем машинного обучения. Она упрощает создание API методов для доступа к обученной ML-модели и совместима со всеми крупными фреймворками: Tensorflow, Keras, PyTorch, XGBoost, scikit-learn и fastai.
BentoML поддерживает адаптивную микропакетную обработку данных, а также предоставляет функции управления моделью и ее развертывания. BentoML отлично реализует идеи MLOps, позволяя разработчикам ML-моделей использовать лучшие практики DevOps. Специалисты по Data Science и инженеры Machine Learning используют BentoML для ускорения и стандартизации процесса запуска моделей в производство, создавая масштабируемые и высокопроизводительные сервисы машинного обучения. Библиотека поддерживает непрерывное развертывание, мониторинг и сопровождение сервисов в производственной среде. Пример практического использования BentoML мы рассматривали в этом материале.
Отметим общие функции FastAPI и BentoML с точки зрения MLOps:
✅они оба основаны на Starlette – легковесной ASGI-платформе для создания асинхронных веб-сервисов на Python;
✅автоматическая документация в Swagger UI согласно открытому стандарту OpenAPI 3;
✅асинхронные запросы, что позволяет обрабатывать несколько запросов одновременно, а не выполнять их линейно.
Несмотря на схожесть в этих фундаментальных вопросах, ключевые различия между BentoML и FastAPI для MLOps заключаются в сценариях использования, характерных для разработки и развертывания систем машинного обучения, что мы и рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/fastapi-versus-bentoml-for-mlops.html
👁️🗨️Что общего у FastAPI с BentoML и при чем здесь MLOps
С точки зрения промышленной эксплуатации, в проектах машинного обучения следует фокусироваться не только и не столько на точности самих алгоритмов Machine Learning. Огромного внимания требует автоматизация рутинных процессов развертывания и сопровождения ML-моделей, что превратилось в целую концепцию под названием MLOps. Поскольку это направление инженерной науки о данных еще довольно молодое, в нем постоянно появляются новые идеи и инструменты.
В частности, одним из самых популярных MLOps-средств считается FastAPI – высокопроизводительный веб-фреймворк для создания API с помощью стандартной аннотации типов Python 3.6+. ML-инженеры часто используют его для развертывания своих моделей в качестве сервисов API.
Впрочем, FastAPI используется не только в ML-проектах. Этот фреймворк отлично подходит для быстрого создания любых REST-приложений на Python. Его дополнительным преимуществом является автогенерация документации API в формате Swagger (открытый стандарт OpenAPI 3) и JSON Schema. Пример создания такого REST API с тестированием методов в Swagger UI мы описывали в этой статье на блоге нашей Школы прикладного бизнес-анализа.
Возвращаясь к тему MLOps, отметим, что способность FastAPI генерировать документацию поддерживает идеи MLOps, а потому этот фреймворк можно отнести к набору инструментальных средств MLOps-Инженера. Однако, это далеко не единственный инструмент этой категории.
Сюда же относится BentoML – открытая библиотека для быстрого создания MVP систем машинного обучения. Она упрощает создание API методов для доступа к обученной ML-модели и совместима со всеми крупными фреймворками: Tensorflow, Keras, PyTorch, XGBoost, scikit-learn и fastai.
BentoML поддерживает адаптивную микропакетную обработку данных, а также предоставляет функции управления моделью и ее развертывания. BentoML отлично реализует идеи MLOps, позволяя разработчикам ML-моделей использовать лучшие практики DevOps. Специалисты по Data Science и инженеры Machine Learning используют BentoML для ускорения и стандартизации процесса запуска моделей в производство, создавая масштабируемые и высокопроизводительные сервисы машинного обучения. Библиотека поддерживает непрерывное развертывание, мониторинг и сопровождение сервисов в производственной среде. Пример практического использования BentoML мы рассматривали в этом материале.
Отметим общие функции FastAPI и BentoML с точки зрения MLOps:
✅они оба основаны на Starlette – легковесной ASGI-платформе для создания асинхронных веб-сервисов на Python;
✅автоматическая документация в Swagger UI согласно открытому стандарту OpenAPI 3;
✅асинхронные запросы, что позволяет обрабатывать несколько запросов одновременно, а не выполнять их линейно.
Несмотря на схожесть в этих фундаментальных вопросах, ключевые различия между BentoML и FastAPI для MLOps заключаются в сценариях использования, характерных для разработки и развертывания систем машинного обучения, что мы и рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/fastapi-versus-bentoml-for-mlops.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
FastAPI versus BentoML: что лучше для MLOps и почему
Что общего у FastAPI с BentoML, чем они отличаются и почему только один из них является MLOps-инструментом для API сервисов Machine Learning
👀Виды хранения данных в СУБД: сравнение.
Способы хранения данных в СУБД можно разделить на 2 категории: ориентация на строки и ориентация на столбцы.
Изменяя способ хранения данных на жестком диске компьютера, можно повлиять на производительность базы данных и ее оптимизацию для транзакционных или аналитических рабочих нагрузок.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/columnar-and-row-based-databases.html
Способы хранения данных в СУБД можно разделить на 2 категории: ориентация на строки и ориентация на столбцы.
Изменяя способ хранения данных на жестком диске компьютера, можно повлиять на производительность базы данных и ее оптимизацию для транзакционных или аналитических рабочих нагрузок.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/columnar-and-row-based-databases.html
#greenplum #статьи
4 уровня изоляции транзакций и их поддержка в Greenplum
На уровне стандарта SQL принято выделять 4 уровня изоляции транзакций:
〽️Read uncommited — чтение незафиксированных данных;
〽️Read committed – чтение зафиксированных данных;
〽️Repeatable read – повторяемое чтение;
〽️Serializable – сериализуемость, т.е. параллельное выполнение набора транзакций, которое гарантированно дает тот же эффект, что и их последовательное выполнение по одной.
Serializable является самым строгим уровнем изоляции транзакций без каких-либо взаимодействий между ними. В остальных уровнях могут происходить такие недопустимые явления, как грязное чтение, когда транзакция считывает данные, записанные параллельно незафиксированной транзакцией, неповторяемое чтение, когда транзакция повторно считывает данные, которые она ранее читала, и обнаруживает, что они были изменены другой транзакцией, зафиксированной с момента первоначального чтения. Также к нарушениям строгой изоляции, которые случаются на Read uncommited и Read committed относят фантомное чтение, когда транзакция повторно выполняет запрос, возвращающий набор строк, удовлетворяющих условию поиска, и обнаруживает, что он изменился из-за другой недавно зафиксированной транзакции. Наконец, изоляцию нарушает аномалия сериализации, когда результат успешной фиксации группы транзакций несовместим со всеми возможными порядками их выполнения по одной за раз.
Далее рассмотрим более подробно.
@BigDataSchool_ru https://www.bigdataschool.ru/blog/distributed-transactions-and-isolation-levels-in-greenplum.html
4 уровня изоляции транзакций и их поддержка в Greenplum
На уровне стандарта SQL принято выделять 4 уровня изоляции транзакций:
〽️Read uncommited — чтение незафиксированных данных;
〽️Read committed – чтение зафиксированных данных;
〽️Repeatable read – повторяемое чтение;
〽️Serializable – сериализуемость, т.е. параллельное выполнение набора транзакций, которое гарантированно дает тот же эффект, что и их последовательное выполнение по одной.
Serializable является самым строгим уровнем изоляции транзакций без каких-либо взаимодействий между ними. В остальных уровнях могут происходить такие недопустимые явления, как грязное чтение, когда транзакция считывает данные, записанные параллельно незафиксированной транзакцией, неповторяемое чтение, когда транзакция повторно считывает данные, которые она ранее читала, и обнаруживает, что они были изменены другой транзакцией, зафиксированной с момента первоначального чтения. Также к нарушениям строгой изоляции, которые случаются на Read uncommited и Read committed относят фантомное чтение, когда транзакция повторно выполняет запрос, возвращающий набор строк, удовлетворяющих условию поиска, и обнаруживает, что он изменился из-за другой недавно зафиксированной транзакции. Наконец, изоляцию нарушает аномалия сериализации, когда результат успешной фиксации группы транзакций несовместим со всеми возможными порядками их выполнения по одной за раз.
Далее рассмотрим более подробно.
@BigDataSchool_ru https://www.bigdataschool.ru/blog/distributed-transactions-and-isolation-levels-in-greenplum.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Распределенные транзакции в Greenplum
Распределенные транзакции в Greenplum с Arenadata DB: уровни изоляции, идентификаторы, снапсшоты и MVCC-модель управления параллелизмом
#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,Arenadata,Greenplum, Kafka и Spark
Ищем кратчайший путь с Cypher-запросами в Neo4j
Сегодня в рамках продвижения нашего нового курса по графовым алгоритмам в бизнес-прило
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по Spark.
🚀Что такое сборка приложений?
Тест по Spark.
🚀Что такое сборка приложений?
Anonymous Quiz
88%
компиляция и компоновка приложения
0%
построение интерфейса приложения
4%
разбиение исходного кода приложения на модули
8%
преобразование исходного кода приложения в языки низкого уровня
#bigdata #ML #статьи
🏘️Что такое метод ближайших соседей: ликбез по Machine Learning
В проектах ML и приложениях интеллектуального анализа данных, а также в пространственных и мультимедийных системах часто используется метод ближайших соседей (kNN, k-Nearest Neighbor).
Он представляет собой простейший метрический классификатор, основанный на оценивании сходства объектов. Классифицируемый объект относится к тому классу, которому принадлежат ближайшие к нему объекты обучающей выборки. Этот метод очень чувствителен к диапазону изменений входных переменных. Поэтому перед его применением входные данные следует нормализовать, приведя числовые значения признаков к одинаковой области изменения.
Можно сказать, что метод ближайших соседей является одним из простейших алгоритмов контролируемого машинного обучения, который сохраняет все доступные данные и классифицирует новую точку данных на основе сходства. Будучи непараметрическим алгоритмом, он не делает никаких предположений относительно базовых данных и не обучается сразу на обучающем наборе, а сохраняет его и во время классификации выполняет действие над набором данных.
С математической точки зрения kNN представляет собой классификацию новой точки данных на основании имеющихся k точек, расположенных ближе всего к ней. Благодаря тому, что kNN-модель не выводит дискриминационную функцию из обучающих данных, а только хранит их и учится на этом датасете только во время прогнозирования в реальном времени, метод ближайших соседей работает очень быстро. Он намного быстрее, чем другие алгоритмы Machine Learning, такие как метод опорных векторов (SVM) или линейная регрессия.
Еще одним преимуществом kNN является простота добавления новых данных, поскольку алгоритм не требует обучения перед тем, как делать прогнозы. Наконец, он очень прост в реализации, для которой нужны только 2 параметра: значение k и мера расстояния, например, евклидова или манхэттенская.
Однако, метод ближайших соседей не очень хорошо работает с большими наборами данных из-за высокой стоимости вычислений расстояния между новой точкой и каждой существующей и снижения производительности алгоритма. Также kNN плохо работает с данными большого размера, потому что при большом количестве измерений становится сложно вычислить расстояние в каждом из них. Как уже было отмечено ранее, kNN чувствителен к шуму в наборе данных, пропускам и выбросам. Необходимо провести предварительную подготовку, в частности, заполнить пропуски, удалить выбросы и нормализовать обучающий датасет.
Из наиболее понятных примеров реального применения метода ближайших соседей в практических приложениях можно отметить обнаружение мошеннических транзакций по кредитным картам и разработку рекомендательных систем, чтобы советовать пользователям товары на основе их предпочтений. Поскольку в этих случаях идет обработка огромного количества данных, целесообразно применять kNN-метод с технологиями Big Data, например, Apache HBase, что мы и рассмотрим далее
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/knn-algorithm-on-data-in-hbase-for-machine-learning.html
🏘️Что такое метод ближайших соседей: ликбез по Machine Learning
В проектах ML и приложениях интеллектуального анализа данных, а также в пространственных и мультимедийных системах часто используется метод ближайших соседей (kNN, k-Nearest Neighbor).
Он представляет собой простейший метрический классификатор, основанный на оценивании сходства объектов. Классифицируемый объект относится к тому классу, которому принадлежат ближайшие к нему объекты обучающей выборки. Этот метод очень чувствителен к диапазону изменений входных переменных. Поэтому перед его применением входные данные следует нормализовать, приведя числовые значения признаков к одинаковой области изменения.
Можно сказать, что метод ближайших соседей является одним из простейших алгоритмов контролируемого машинного обучения, который сохраняет все доступные данные и классифицирует новую точку данных на основе сходства. Будучи непараметрическим алгоритмом, он не делает никаких предположений относительно базовых данных и не обучается сразу на обучающем наборе, а сохраняет его и во время классификации выполняет действие над набором данных.
С математической точки зрения kNN представляет собой классификацию новой точки данных на основании имеющихся k точек, расположенных ближе всего к ней. Благодаря тому, что kNN-модель не выводит дискриминационную функцию из обучающих данных, а только хранит их и учится на этом датасете только во время прогнозирования в реальном времени, метод ближайших соседей работает очень быстро. Он намного быстрее, чем другие алгоритмы Machine Learning, такие как метод опорных векторов (SVM) или линейная регрессия.
Еще одним преимуществом kNN является простота добавления новых данных, поскольку алгоритм не требует обучения перед тем, как делать прогнозы. Наконец, он очень прост в реализации, для которой нужны только 2 параметра: значение k и мера расстояния, например, евклидова или манхэттенская.
Однако, метод ближайших соседей не очень хорошо работает с большими наборами данных из-за высокой стоимости вычислений расстояния между новой точкой и каждой существующей и снижения производительности алгоритма. Также kNN плохо работает с данными большого размера, потому что при большом количестве измерений становится сложно вычислить расстояние в каждом из них. Как уже было отмечено ранее, kNN чувствителен к шуму в наборе данных, пропускам и выбросам. Необходимо провести предварительную подготовку, в частности, заполнить пропуски, удалить выбросы и нормализовать обучающий датасет.
Из наиболее понятных примеров реального применения метода ближайших соседей в практических приложениях можно отметить обнаружение мошеннических транзакций по кредитным картам и разработку рекомендательных систем, чтобы советовать пользователям товары на основе их предпочтений. Поскольку в этих случаях идет обработка огромного количества данных, целесообразно применять kNN-метод с технологиями Big Data, например, Apache HBase, что мы и рассмотрим далее
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/knn-algorithm-on-data-in-hbase-for-machine-learning.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Преимущества Apache HBase для метода ближайших соседей
Что такое метод ближайших соседей, где и как используется этот алгоритм машинного обучения, и как Apache HBase повышает его эффективность
#bigdata #HBase #статьи
✅Плюсы Apache HBase для kNN-алгоритмов
Напомним, Apache HBase является колоночно-ориентированной мультиверсионной NoSQL-СУБД типа key-value. Она работает поверх HDFS и обеспечивает возможности Google BigTable для Hadoop. Благодаря колоночно-ориентированной структуре хранения данных, Apache HBase работает очень быстро. А возможности этой СУБД эффективно обрабатывать огромные объемы данных смягчают недостатки kNN-метода, который изначально не предназначен для работы с большими выборками.
Запуск kNN-алгоритмов на данных в HBase поможет найти наиболее похожие элементы, что пригодится в рекомендательных и AML-системах (Anti-Money Laundering), а также в задачах обработки естественного языка, распознавания изображений, классификации текстов и анализе временных рядов.
Благодаря распределенному характеру HBase, запускаемые на ней kNN-алгоритмы становятся высокопроизводительными и выгодными с экономической точки зрения. Также эти аналитические приложения отлично масштабируются, могут работать с огромными объемами данных и сложными запросами, которые в Apache HBase выражаются не через SQL-инструкции, а в виде кода MapReduce.
Повысить эффективность работы kNN-алгоритмов в Apache HBase помогут следующие рекомендации:
❗️использовать оптимизированные структуры данных, такие как деревья, чтобы улучшить точность вычислений
❗️добавить предварительное вычисление расстояний, чтобы сократить время выполнения программы
❗️распараллелить вычисления между несколькими ядрами ЦП или узлами кластера
❗️выбор наилучшую метрику расстояния, релевантную вычисляемому типу данных
❗️настроить гиперпараметры алгоритма, задав оптимальное значение k. Если количество соседей для алгоритма kNN слишком велико, может случиться переобучение модели и рост вычислительных затрат. Если количество соседей слишком мало, точность алгоритма будет слишком мала из-за зашумления данных.
❗️включить кэширование промежуточных результатов, чтобы повторно использовать их в сложных вычислениях, сокращая время пересчета расстояний между точками данных.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/knn-algorithm-on-data-in-hbase-for-machine-learning.html
✅Плюсы Apache HBase для kNN-алгоритмов
Напомним, Apache HBase является колоночно-ориентированной мультиверсионной NoSQL-СУБД типа key-value. Она работает поверх HDFS и обеспечивает возможности Google BigTable для Hadoop. Благодаря колоночно-ориентированной структуре хранения данных, Apache HBase работает очень быстро. А возможности этой СУБД эффективно обрабатывать огромные объемы данных смягчают недостатки kNN-метода, который изначально не предназначен для работы с большими выборками.
Запуск kNN-алгоритмов на данных в HBase поможет найти наиболее похожие элементы, что пригодится в рекомендательных и AML-системах (Anti-Money Laundering), а также в задачах обработки естественного языка, распознавания изображений, классификации текстов и анализе временных рядов.
Благодаря распределенному характеру HBase, запускаемые на ней kNN-алгоритмы становятся высокопроизводительными и выгодными с экономической точки зрения. Также эти аналитические приложения отлично масштабируются, могут работать с огромными объемами данных и сложными запросами, которые в Apache HBase выражаются не через SQL-инструкции, а в виде кода MapReduce.
Повысить эффективность работы kNN-алгоритмов в Apache HBase помогут следующие рекомендации:
❗️использовать оптимизированные структуры данных, такие как деревья, чтобы улучшить точность вычислений
❗️добавить предварительное вычисление расстояний, чтобы сократить время выполнения программы
❗️распараллелить вычисления между несколькими ядрами ЦП или узлами кластера
❗️выбор наилучшую метрику расстояния, релевантную вычисляемому типу данных
❗️настроить гиперпараметры алгоритма, задав оптимальное значение k. Если количество соседей для алгоритма kNN слишком велико, может случиться переобучение модели и рост вычислительных затрат. Если количество соседей слишком мало, точность алгоритма будет слишком мала из-за зашумления данных.
❗️включить кэширование промежуточных результатов, чтобы повторно использовать их в сложных вычислениях, сокращая время пересчета расстояний между точками данных.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/knn-algorithm-on-data-in-hbase-for-machine-learning.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Преимущества Apache HBase для метода ближайших соседей
Что такое метод ближайших соседей, где и как используется этот алгоритм машинного обучения, и как Apache HBase повышает его эффективность
#apachespark #bestpractice @BigDataSchool_ru
Тест по Spark.
🌳Какой метод используется для предсказания на основе обученной модели случайных лесов?
Тест по Spark.
🌳Какой метод используется для предсказания на основе обученной модели случайных лесов?
Anonymous Quiz
71%
predict()
5%
transform()
5%
get()
19%
getPredict()
#bigdata #Elasticsearch #статьи
⁉️Что не так с SQL-запросами в облачном Elasticsearch на AWS
Исторически платформа данных Polly использовала документо-ориентированную NoSQL-СУБД Elasticsearch для хранения данных. Это хранилище имеет функцию полнотекстового поиска и работает очень быстро благодаря встроенному механизму индексации документов. Но по мере роста объема обрабатываемых данных платформа Polly на Elasticsearch столкнулась с рядом ограничений этой NoSQL-СУБД.
Типичный набор данных Polly включает в себя следующее:
✳️Единые метаданные на уровне набора данных
✳️Набор из n образцов, каждый из которых имеет свои метаданные
✳️Набор из m характеристик, измеренных на выборку, каждая характеристика имеет свои метаданные
✳️Матрица данных (n⨯m), в которой хранятся фактические измерения – это самая большая часть набора информации
✳️Метаданные каждой сущности представляют собой словарь пар ключ-значение.
Сгруппированные наборы данных в репозитории имеют некоторые общие атрибуты, например, источник происхождения и т.д. Пользователи работают с данными в этих наборах, выполняя поиск по метаданным, полнотекстовый поиск по фичам и запрашивая матрицы данных с помощью SQL-запросов. Поэтому нужен API, который принимает запросы полнотекстового поиска и SQL к огромным наборам данных. Из-за роста объема данных общий размер индексов Elasticsearch очень быстро увеличился в 4 раза, с 1 до 4 ТБ. И, хотя облачное хранилище стоит не очень дорого, в AWS OpenSearch есть ограничение на размер тома EBS, который можно подключить к каждому узлу кластера Elasticsearch. При достижении предела размера следует увеличить количество узлов или обновить их до более мощного и более дорогого класса экземпляров.
Обычно кластер Elasticsearch хорошо масштабируется по мере увеличения объема данных, чтобы беспрепятственно справляться с возрастающей нагрузкой во время поиска. Но в случае платформы Polly объемы данных росли очень быстро, хотя большинство матриц данных никогда не запрашивалось. Поэтому запросы к матрицам данных стали неоптимальными, а весь кластер Elasticsearch не эффективно утилизировал вычислительные ресурсы, будучи не лучшим вариантом реализации SQL-запросов из-за следующих ограничений:
❎получение более 10 000 строк для любого нетривиального запроса
❎ограничения при соединениях и агрегациях
❎сложности с запросами вложений в матрице данных с одним документом на строку, где имя каждого образца и измерение в массиве вложенных документов.
Поэтому для поиска с использованием SQL-запросов платформе Polly нужен отдельный инструмент, который имеет встроенную поддержку SQL, хорошо масштабируется с очень большими объемами данных в таблице, отлично работает с огромным количеством таблиц и применяет схему для каждой из них.
Далее рассмотрим, что для этого выбрали инженеры Elucidata и почему.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/delta-lake-for-sql-with-elasticsearch-on-aws-polly-case.html
⁉️Что не так с SQL-запросами в облачном Elasticsearch на AWS
Исторически платформа данных Polly использовала документо-ориентированную NoSQL-СУБД Elasticsearch для хранения данных. Это хранилище имеет функцию полнотекстового поиска и работает очень быстро благодаря встроенному механизму индексации документов. Но по мере роста объема обрабатываемых данных платформа Polly на Elasticsearch столкнулась с рядом ограничений этой NoSQL-СУБД.
Типичный набор данных Polly включает в себя следующее:
✳️Единые метаданные на уровне набора данных
✳️Набор из n образцов, каждый из которых имеет свои метаданные
✳️Набор из m характеристик, измеренных на выборку, каждая характеристика имеет свои метаданные
✳️Матрица данных (n⨯m), в которой хранятся фактические измерения – это самая большая часть набора информации
✳️Метаданные каждой сущности представляют собой словарь пар ключ-значение.
Сгруппированные наборы данных в репозитории имеют некоторые общие атрибуты, например, источник происхождения и т.д. Пользователи работают с данными в этих наборах, выполняя поиск по метаданным, полнотекстовый поиск по фичам и запрашивая матрицы данных с помощью SQL-запросов. Поэтому нужен API, который принимает запросы полнотекстового поиска и SQL к огромным наборам данных. Из-за роста объема данных общий размер индексов Elasticsearch очень быстро увеличился в 4 раза, с 1 до 4 ТБ. И, хотя облачное хранилище стоит не очень дорого, в AWS OpenSearch есть ограничение на размер тома EBS, который можно подключить к каждому узлу кластера Elasticsearch. При достижении предела размера следует увеличить количество узлов или обновить их до более мощного и более дорогого класса экземпляров.
Обычно кластер Elasticsearch хорошо масштабируется по мере увеличения объема данных, чтобы беспрепятственно справляться с возрастающей нагрузкой во время поиска. Но в случае платформы Polly объемы данных росли очень быстро, хотя большинство матриц данных никогда не запрашивалось. Поэтому запросы к матрицам данных стали неоптимальными, а весь кластер Elasticsearch не эффективно утилизировал вычислительные ресурсы, будучи не лучшим вариантом реализации SQL-запросов из-за следующих ограничений:
❎получение более 10 000 строк для любого нетривиального запроса
❎ограничения при соединениях и агрегациях
❎сложности с запросами вложений в матрице данных с одним документом на строку, где имя каждого образца и измерение в массиве вложенных документов.
Поэтому для поиска с использованием SQL-запросов платформе Polly нужен отдельный инструмент, который имеет встроенную поддержку SQL, хорошо масштабируется с очень большими объемами данных в таблице, отлично работает с огромным количеством таблиц и применяет схему для каждой из них.
Далее рассмотрим, что для этого выбрали инженеры Elucidata и почему.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/delta-lake-for-sql-with-elasticsearch-on-aws-polly-case.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Elasticsearch + Delta Lake: архитектура данных биотех-платформы Polly
Зачем биотехнологической платформе Polly от Elucidata понадобился API SQL-запросов в облачном се
#bigdata #greenplum #статьи
✅Что такое PostGIS и как это работает
Как и PostgreSQL, Greenplum поддерживает геометрические типы данных, с помощью которых можно строить статичные визуальные карты. Но этого недостаточно для разработки сложных геоинформационных систем (ГИС). Чтобы обойти эти ограничения, необходимо подключить расширение PostGIS, которое позволяет работать с пространственными пространственные предикатами, индексами и операторами, а также растровыми данными, геометриями, двумерными и трехмерными функциями.
Эти возможности нужны для решения современных геопространственных задач, таких как определение расстояния между точками на местности, подсчет количества объектов в заданной области, вычисления площади, поиска ближайшей заправки или других объектов по заданным критериям.
PostgreSQL обеспечивает поддержку пространственного индексирования GiST, схема которого подходит даже для крупных объектов благодаря индексации, где меньшие объекты действуют как прокси для более крупных. Это расширение добавляет поддержку географических объектов, позволяя выполнять SQL-запросы к пространственным данным, упрощая манипулирование ими при разработке ГИС-решений и картографических приложений. В Greenplum расширение PostGIS включает поддержку пространственных индексов R-Tree на основе GiST и функции для анализа и обработки геопространственных объектов, включая растровые данные. PostGIS Raster использует библиотеку транслятора GDAL (Geospatial Data Abstraction Library) для форматов растровых геопространственных данных, которая представляет вызывающему приложению единую растровую абстрактную модель данных.
Далее про настройки георасширения в Greenplum, особенности и ограничения практического использования.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/postgis-extension-for-greenplum.html
✅Что такое PostGIS и как это работает
Как и PostgreSQL, Greenplum поддерживает геометрические типы данных, с помощью которых можно строить статичные визуальные карты. Но этого недостаточно для разработки сложных геоинформационных систем (ГИС). Чтобы обойти эти ограничения, необходимо подключить расширение PostGIS, которое позволяет работать с пространственными пространственные предикатами, индексами и операторами, а также растровыми данными, геометриями, двумерными и трехмерными функциями.
Эти возможности нужны для решения современных геопространственных задач, таких как определение расстояния между точками на местности, подсчет количества объектов в заданной области, вычисления площади, поиска ближайшей заправки или других объектов по заданным критериям.
PostgreSQL обеспечивает поддержку пространственного индексирования GiST, схема которого подходит даже для крупных объектов благодаря индексации, где меньшие объекты действуют как прокси для более крупных. Это расширение добавляет поддержку географических объектов, позволяя выполнять SQL-запросы к пространственным данным, упрощая манипулирование ими при разработке ГИС-решений и картографических приложений. В Greenplum расширение PostGIS включает поддержку пространственных индексов R-Tree на основе GiST и функции для анализа и обработки геопространственных объектов, включая растровые данные. PostGIS Raster использует библиотеку транслятора GDAL (Geospatial Data Abstraction Library) для форматов растровых геопространственных данных, которая представляет вызывающему приложению единую растровую абстрактную модель данных.
Далее про настройки георасширения в Greenplum, особенности и ограничения практического использования.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/postgis-extension-for-greenplum.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Обработка геоданных в Greenplum с PostGIS
Сегодня познакомимся с расширением PostGIS, которое позволяет PostgreSQL и Greenplum обрабатывать п
#apachespark #bestpractice @BigDataSchool_ru
Тест по Spark.
🌳За что отвечает параметр featuresCol в модели случайного леса Spark?
Тест по Spark.
🌳За что отвечает параметр featuresCol в модели случайного леса Spark?
Anonymous Quiz
44%
за формирование вектора ключевых признаков, по которым будет вестись обучение модели
38%
за указание колонки, содержащей вектор признаков
6%
за формирование вектора целевой переменной
13%
за указание вектора целевой переменной
🆚Сравнение Neo4j с TigerGraph
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/neo4j-vs-tigergraph-what-to-choose.html
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/neo4j-vs-tigergraph-what-to-choose.html
#apachespark #bestpractice @BigDataSchool_ru
Тест по Spark.
🧬Какой метод отвечает за случайное разбиение датасета на тренировочную и тестовую выборки?
Тест по Spark.
🧬Какой метод отвечает за случайное разбиение датасета на тренировочную и тестовую выборки?
Anonymous Quiz
80%
randomSplit()
0%
split()
5%
randomDiv()
15%
splitByRandom()
#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,Arenadata,Greenplum, Kafka и Spark
MLOps c Python-библиотекой Evidently: обнаружение дрейфа данных в ML-моделях
Полезный MLOps без лишних усилий: что такое дрейф данных, чем это опасно и как его обнаружить с легковесной Python-библиотекой Evidently