Comments 15
Не сказали самого интересного - в чем смысл такого подхода, какое время выполнения запросов, хорошо ли распараллеливаются запросы, можно ли «на ходу» добавлять и удалять данные, партиции, создавать и перестраивать индексы (в том числе, пространственные) и, притом, выполнять запросы? Все перечисленное и более того отлично и очень быстро выполняется с помощью PostgreSQL/PostGIS или SQLite3/Spatialite. Если нужно лишь разово обработать все данные это еще проще и быстрее сделать прямо на текстовых логах (используя SQL запросы в OGR2OGR с csv данными или любыми другими), без загрузки их в базы данных.
Выбор инструмента для обработки пространственных данных во многом зависит от способа хранения данных и от их объема. В нашем случае это несколько гигабайт только для одного дня для одного региона, которые хранятся в распределенном хранилище данных (Hive). Метод, описанный в статье, позволяет произвести нужные расчеты на кластере, не прибегая к дополнительным действиям по выборке, копированию данных на другие сервисы (PostrgeSQL/PostGIS и т.п.), созданию пространственного индекса на них.
Точных замеров по времени и скорости запросов в данной работе мы не проводили, и они напрямую зависят от текущей загруженности кластера. Вы можете ознакомиться с уже проведенными исследованиями, где рассчитаны метрики эффективности запросов, разобраны планы их обработки, приведены сравнения при использовании разных пространственных индексов здесь https://jiayuasu.github.io/files/paper/GeoSpark_Geoinformatica_2018.pdf
Ваши объемы несколько гигабайт в день и нужны лишь разовые запросы? ogr2ogr с csv или json драйвером более чем достаточно. Даже на лаптопе типа эппл эйр легко обрабатывается полный дамп OpenStreetMap в пару терабайт размером средствами ogr2ogr (у меня на гитхабе код опубликован для проекта преобразования OSM в тематические слои, проект спонсирован компанией Google Inc., потому указана совместимость только с Google BigQuery, хотя я сам использую PostgreSQL). А на одном средненьком сервере пятилетней давности можно в реальном времени обрабатывать сотни гигабайт суточных пространственных данных с помощью PostgreSQL/PostGIS и SQLite3/Spatialite (система мониторинга трафика для Германии, к примеру). Если вам для такой задачи кластер нужен - что-то очень не так с вашим решением или реализацией.
можно и вашими методами считать, альтернатив много. Здесь нужно понимать, что кластер мы развернули не для одной конкретной задачи, а показали как можно сделать расчет без дополнительного копирования данных из существующего хранилища данных Hive в PostGIS (и прочее) в привычной среде Apache Spark, с которой взаимодействуем на ежедневной основе.
В итоге, вы все равно используете SQL и пространственные функции (ST_…, даже их имена в PostGIS совпадают), только еще и кучу оберток пишете. В том же PostgreSQL есть внешние источники данных, чтобы данные не копировать. Вот я и спрашиваю, в чем же какие-то плюсы вашего решения? На порядок больше кода (да еще на разных языках), медленнее, возможности меньше,… а где преимущества?
преимущество хотя бы в том, что мне не нужен PostGIS. Функции действительно совпадают, и это хорошо как и возможность использовать привычный аналитику SQL API. Почему вы решили, что медленнее и возможности меньше, я не понял.
Потому что именно SQL движки работают наиболее оптимально с дисковыми данными, а раз вы еще и "на лету" индексы создаете, это уже означает считывание всех данных для индексации - по сути, вы делаете ровно то, отсутствием чего хвалитесь в статье (передачу всех данных в ваш движок). Это дорого (вычислительно, по трафику, по финансам, в конце концов) и неэффективно для работы с большими данными. Вот из моего примера выше - попробуйте таким способом на небольшом сервере для миллиона водителей (как раз получается несколько сот гигабайт данных в сутки) анализировать дорожный трафик и рекомендации создавать - тут-то и становится понятно, что умеет PostGIS и насколько быстро он это все делает. Это вам не разово вычислить простейший агрегат на небольшом наборе данных, который хоть в экселе можно получить.
Денис, а пространственные данные как добавляются и куда, где они хранятся?
Есть ли возможность работать без Scala (если это этот язык в примерах)?
Просто я очень хорошо понимаю про пространственные данные, JTS, GeoTools, PostGIS, а вот всякие Spark не очень.
И присоединюсь к предыдущему комментарию, как много данных, какой выигрыш по времени и в сравнении с чем?
Что ещё вы используете для работы с пространственными данными?
В отличие от PostGIS, Sedona производит пространственные расчеты «на лету», создавая пространственный индекс каждый раз заново, когда идет преобразование из spark dataframe в spatial rdd. Другими словами, пространственные данные нигде не хранятся в случае Sedona.
Выбор инструмента для обработки пространственных данных зависит от способа хранения и от их объема. Условно для работы с мегабайтами данных осваивать и настраивать новую среду Apache Spark+Sedona не имеет смысла, того же PostGIS будет вполне достаточно. Преимущество описанного метода расчета именно в возможности работы с большим объемом данных (гигабайты).
Помимо Scala есть варианты установки с Python (PySpark) и R (SparkR).
Для малых объемов данных (гигабайты) PostgreSQL обычно не нужен, как я выше уже написал. Какие же это «большие данные», если они в оперативную память современного смартфона помещаются? А нужен для сотен гигабайт и более (по определению, большие данные превышают объем оперативной памяти, а это сейчас порядка сотни гигабайт для типового сервера). Если ваше решение работает с гигабайтами - так и сравнивайте его с эксель, а не PostgreSQL.
Спасибо большое за примеры, выглядит интересно.
Отвечая немного на комментарии про то что использовать специализированные решения для геоданных - мне кажется это сильно усложнит систему. Грубо говоря, если у тебя уже есть большой data lake с настроенным к нему доступом из Spark, то поднимать рядом еще одну систему или использовать какой-то отдельный движок - кажется перебором.
Ну и этот вариант должен достаточно хорошо масштабироваться. Там упомянули что это гигабайты для одного дня для одного региона. Ну то есть если хочется проанализировать данные за год в нескольких регионах - это уже влегкую десятки террабайт. А если их еще хочется какими-то другими данными обогатить? Условно поджойнить на еще какие-то атрибуты и тд.
Да, можно сделать предобработку в Spark, нарезать данные, и проанализировать с помощью чего-то еще… Но зачем, когда тут это практически из коробки?
Поскольку вообще никаких метрик не показано, то возникает много вопросов. А терабайты и десятки терабайт обработать совершенно не проблема, и никакие кластеры тут не нужны для разовых запросов. С перечисленными мной выше решениями обработка легко выполняется даже на лаптопе типа эппл эйр с подключенным внешним диском нужного размера для хранения данных. Или в облаке гугл - 18 терабайт диски доступны, у меня на гитхабе опять же есть примеры, как многотеребайтные данные с помощью GDAL обрабатывать (и этот проект для Гугл написан, хотя то же самое отлично работает на лаптопе). На предложенном в статье решении требуется целый кластер [современных серверов], притом, обработка может оказаться даже медленнее и возможностей доступно меньше (тот же PostGIS предлагает очень много геопространственных функций и да, они реально нужны). И в чем смысл? К примеру, в Google BigQuery или Microsoft SQL и прочих можно пространственные данные хранить и обрабатывать, но набор пространственных функций урезан [и приходится руками на яваскрипт писать то, что в PostGIS с помощью внешних сишных библиотек реализовано]. Вот как минимальное остовное дерево и так далее на своем кластере захотите посчитать, поймете, что или хороший геопространственный движок нужен или ближайшие месяцы будете все это на яваскрипт кодить.
Во-первых, поздравляю вас с покупкой эппл эйр и с работой с Гугл - здесь есть чем гордиться!
Скажите, а вы когда-нибудь использовали Sedona и, может, сравнивали с PostGIS по скорости работы?
Если да - поделитесь пожалуйста результатами тестов
Эппл эйр это очень удобный «попугай» для сравнения, всем понятно, что если задача решается на эйре, то использование для нее кластера полностью избыточно. Sedona я не тестировал, а вот Apache Spark несколько лет назад на мак про 8 гигабайт был абсолютно неповоротливой и не юзабельной штукой. Притом, что на том же «железе» PostGIS позволяет комфортно терабайтные датасеты обрабатывать (тот же дамп OSM). Да и питон с распределенными ленивыми вычислениями отлично работает - берем dask, distributed и терабайтные датасеты обрабатываются без проблем, вот пример докер образа для спутниковой интерферометрии: https://hub.docker.com/r/mobigroup/pygmtsar-large Контейнер требует 16 Гб оперативки, а без контейнера достаточно 8 ГБ, в образе около 100 ГБ данных упаковано, а можно и на терабайтах растров использовать. Потому я и спрашиваю тесты и метрики, иначе сравнение Sedona на кластере против PostGIS на «калькуляторе» не имеет смысла (притом, что второй даже так будет намного быстрее за счет индексов).
Apache Sedona — как быстро работать с геоданными