Школа Больших Данных
552 subscribers
101 photos
694 links
Канал Школы Больших Данных https://www.bigdataschool.ru/ - обучение технологиям Big Data: разработка приложений и администрирование кластеров Hadoop, Kafka, Spark, NoSQL, Python, ML и DS.
Тел: +7 (495) 41-41-121
Контакты: @Bigdataschool_msk @olga_burykh
Download Telegram
#Python #ООП #статьи
✳️Для чего нужны классы в Python
Класс является базовым понятием в концепции ООП.
ООП (объектно-ориентированное программирование) — это методология программирования, которая основана на построении реализации программы в виде классов и объектов.
✔️Класс — это своего рода описание реализации поведения одной общей задачи в виде реализации поведения набора подзадач-действий (методов). В классе также имеются поля, которые характеризуют его особенности (например, у класса Машина может быть поле «объем двигателя» и т.д.). Поля обычно представлены как набор переменных, которые объявляются вне методов данного класса, но очень часто могут быть задействованы в них.
Для инициализации (присвоения значений) данных полей служит такой элемент, как конструктор.
Однако класс является общей и универсальной реализацией для всех предусмотренных случаев, связанных с данной задачей. Зачастую разработчику не требуется использовать всю данную реализацию с кучей полей (особенности класса, в программе обычно представлены как переменные) и методов одновременно. Для этого в ООП предусмотрены объекты.
✔️Объект (экземпляр) — это копия имеющейся реализации (класса) для выполнения текущей задачи. Именно при создании экземпляра класса (объекта) мы можем вызывать необходимые (но только те, которые реализованы в пределах копируемого класса) нам методы или инициализировать поля.
Исходя из всего выше написанного можно сделать вывод, что для того, чтобы пользоваться созданной реализацией (классом), нам необходимо ее скопировать, то есть создать экземпляр (объект).

Далее особенности создания классов в Python + несколько практических примеров
@BigDataSchool_ru
https://python-school.ru/blog/python-classes/
#bigdata #hadoop #статьи
Как защитить данные в кластере Apache HBase от несанкционированного доступа?
Как и любое хранилище, колоночно-ориентированная мультиверсионная NoSQL-СУБД типа key-value Apache HBase, которая работает поверх HDFS и обеспечивает возможности Google BigTable для Hadoop, имеет механизмы защиты данных.
Их можно разделить на следующие категории:
аутентификация и авторизация пользователей и сервисов, которые обращаются к этой СУБД
управление доступом на основе ролей (RBAC) определяет, какие пользователи или группы могут читать и записывать ресурс или выполнять конечную точку сопроцессора
метки видимости, которые позволяют вам помечать ячейки и контролировать доступ к помеченным ячейкам, чтобы дополнительно ограничить, кто может читать или записывать определенные подмножества ваших данных. Метки видимости хранятся в виде тегов.
шифрование данных в состоянии покоя в базовой файловой системе, как в HFiles, так и в WAL. Это защищает данные в состоянии покоя от злоумышленника, который имеет доступ к базовой файловой системе, без необходимости изменять реализацию клиента. Этот способ также может защитить от утечки данных из-за неправильно расположенных дисков, что может быть важно для соблюдения законодательных и нормативных требований.

Далее рассмотрим на примерах.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/hbase-security-methods.html
#ML #Python #статьи
🤖L1 и L2 регуляризация
В машинном обучении и Data science, регуляризация является важной техникой для управления переобучением модели. Она помогает избежать слишком сложной модели, которая может хорошо подстроиться под обучающие данные, но будет работать плохо на новых данных.
Рассмотрим два основных типа регуляризации: L1 и L2.
Как они работают, и как их можно использовать в Python для создания более надежных моделей в data science.
🔹L1 регуляризация также известна как Lasso (Least Absolute Shrinkage and Selection Operator) регуляризация. Она основана на добавлении штрафа, равного абсолютному значению коэффициентов модели.
L1 регуляризация склонна к отбору признаков, так как она может уменьшить веса признаков до нуля. Это позволяет убрать неинформативные признаки из модели, что может уменьшить сложность модели и улучшить ее обобщающую способность.
🔹Помимо L1 регуляризации, существует также L2 регуляризация (иногда называемая Ridge регуляризацией), которая также применяется в линейной регрессии и многих других моделях.
L2 регуляризация так же добавляет к оптимизационной функции модели штрафную функцию.
Кроме того, L2 регуляризация может помочь в предотвращении переобучения и улучшении обобщающей способности модели, а также в уменьшении влияния шума в данных на модель.

Далее: Реализация L1 и L2 в цикле обучения модели.
@BigDataSchool_ru
https://python-school.ru/blog/regularization-l1-l2/
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по 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
#python #machinelearning #статьи
📐Логистическая регрессия — это алгоритм машинного обучения, который используется для решения задачи бинарной классификации, то есть разделения данных на два класса. Она получила свое название благодаря тому, что использует логистическую функцию для прогнозирования вероятности принадлежности объекта к одному из классов.
По своей сути логистическая регрессия просто берет уравнение линейной регрессии и использует его как параметр сигмовидной функции.
В целом, логистическая регрессия — это мощный инструмент для решения задач бинарной и многоклассовой классификации в Python. Она проста в использовании и предоставляет множество метрик для оценки качества работы модели.
Плюсы логистической регрессии:
1. Это относительно простой алгоритм, который требует небольшого количества вычислительных ресурсов и может быть эффективно использован для решения большого количества задач классификации.
2. Интерпретируемость: логистическая регрессия позволяет понимать, какие переменные влияют на классификацию и каким образом.
3. Работает хорошо на небольших наборах данных: логистическая регрессия показывает хорошие результаты на небольших наборах данных.
4. Небольшая вероятность переобучения: логистическая регрессия склонна к менее переобучению, поскольку она не имеет множества параметров, которые нужно оптимизировать.

Минусы логистической регрессии:
1. Требуется нормализация признаков: логистическая регрессия требует нормализации признаков, чтобы гарантировать, что признаки вносят одинаковый вклад в модель.
2. Работает плохо на сложных задачах:  может работать плохо на задачах с большим количеством признаков или сложной структурой данных.
3. Линейность: логистическая регрессия работает только с линейными границами решений, что ограничивает ее способность решать сложные задачи классификации.
4. Низкая точность: логистическая регрессия может показывать низкую точность, если классы не являются линейно разделимыми.
@BigDataSchool_ru
https://python-school.ru/blog/logisticregression/
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по 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/
#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
#ApacheSpark #bestpractice @BigDataSchool_ru
Тест по 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
👀Виды хранения данных в СУБД: сравнение.
Способы хранения данных в СУБД можно разделить на 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
#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
#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
#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
#apachespark #bestpractice @BigDataSchool_ru
Тест по 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
#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