Где лучше жить можно выбирать как по привлекательности места, так и избегать заведомо некомфортного для вас окружения. И если привлекательность района обычно преукрашивается риэлторами, то недостатки скорее всего окажутся сюрпризом, когда начнете жить в новом месте. На сайте аренды жилья мне часто попадались квартиры "почти у метро в хорошем районе" симпатичные на фотографиях, при просмотре которых в голове крутился мотив песни "Мусорный ветер, дым из трубы" и с транспортной доступностью в реальности проблемы были не меньше.

Если из окна видна труба завода из которой валит дым "кислотного" цвета, под другим окном оживленная автотрасса/железная дорога и летом не открыть окно из-за гари и громких сигналов транспорта, рядом с этим прелестным пейзажем видны дымок от крематория и кладбище. Когда решите выйти на балкон летом, то комары напомнят что совсем рядом есть заболоченный участок. Поздравляю, вы оказались в том самом месте!!!

Что общего во всех этих факторах, кроме того что я сгустил краски StableDiffusion? В описаном примере для многих людей есть не только экологическая, но психологически дискомфортная составляющая. В студенчестве, в части диплома, связанной с экологией, были расчеты уровня шума в жилых помещениях от трассы/индустриальных объектов. Главный параметр был - расстояние по прямой от жилья.

Если у вас возникала идея получить доступ к метрикам операционной системы и оборудования компьютера из PostgreSQL, то теперь у вас есть инструмент для этого. Я не претендую на его зрелость и готовность к эксплуатации. Это просто прототип, позволяющий получить результаты запросов из osquery в PostgreSQL в виде табличных данных/JSON. Дальше с которыми можете использовать все привычные средства этой базы данных.

В публикациях на хабре, чаще всего самое интересное в комментариях. Вот и в моем прошлом посте "Сгенерировать web интерфейс из БД или объектной модели не стало проще даже 10 лет спустя" я собрал джекпот из SharePoint, Vaadin и нескольких библиотек либо устаревших, либо поддерживаемых "одним автором".

Что я пытался объяснить читателям, что на этапе проверки идей не нужна дополнительная сложность в виде серверной инфраструктуры только ради этой самой инфраструктуры и нового языка программирования/платформы. Именно поэтому мне не нужны сейчас Yii, Symfony и Laravel, не подойдет ADF. На любое обучение тратится драгоценное время и поэтому надо понимать зачем тратить время на что-то, что потом возможно навсегда придется забыть через неделю-другую игры с прототипом.

В своих эксперементах с помощью лапшекода на JavaScript я быстро разработал вполне функциональный интерфейс. А начиналось все с Java 21, хотя в итоге обошелся без нее!

Помню, как более 10 лет назад, я бился с тем, как быстро создать интерфейс для ввода данных в базу данных и отбражения их через браузер. На то время, еще был популярен Google Web Toolkit и было несколько открытых библиотек виджетов к нему, по функционалу догоняющие и иногда превосходящие десктопные.

Однако, реальность оказалась несколько иной. На бэкэнде, базах данных и в big data ситуация гораздо лучше с возможностями бесплатных и открытых проектов, когда не надо покупать лицензии или платить за дополнительные компоненты, можно без СМС и платных подписок запустить хоть Ingenuity на Марс.

После выступления на PgConf2023 у меня на выходных появилось время на реализацию идеи, как реализовать логику конечного автомата на SQL в PostgreSQL. Идея применима к любой СУБД, поддерживающей агрегатные функции, определяемые пользователем. И самое грустное, что в одной из самых популярных аналитических баз данных ClickHouse, эту задачу не нашел как вообще можно решить без Python на чистом SQL, хоть автосгенерированном.

Скоро сказка сказывается, да не скоро дело делается... Жил был Вася. Описали летописцы его житие с учебой в виде таблицы. А устои в обществе где он жил, были описаны с помощью конечного автомата. И конечный автомат мудрости - finite-state machine (FSM) был задан в виде таблицы переходов между состояниями, описанными в виде логических выражений на SQL...

Большую часть прошлого года я работал с Hexvarium. Базирующаяся в Атертоне, штат Калифорния, компания строит и управляет оптоволоконными сетями. В настоящее время у них есть несколько сетей в районе залива, но у них есть планы по расширению в США.

Моя роль заключается в управлении платформой данных, которая содержит 30 миллиардов записей примерно из 70 источников информации. Эти данные используются инженерами, разрабатывающими оптимальные планы развертывания оптоволоконной сети с помощью LocalSolver. Далее приведен пример одного из таких планов.

I will continue the story "How to put the whole world into a regular laptop: PostgreSQL and OpenStreetMap" with secrets about OpenStreetMap geodata, on which many companies have built their business, but not everyone shares the details... Well, today we will open crucial details.

The OSM database in PosgreSQL after loading from the dump takes up more than 587 GB. This is already a large database by the standards of a DBMS, and one huge table for each type of object will not work. For manageability, such data must be partitioned, it's good that PostgreSQL supports declarative data partitioning. It remains only to figure out how to split geographical data. After searching and comparing, the H3 hierarchical hexagonal geospatial indexing system came to rescue. All this was implemented in my openstreetmap_h3 project for fast processing and loading of the world dump into the PostGIS database.

I considered following options from geopartitioning systems...

When a person used to say that he controls the whole world, he was usually placed in the next room with Napoleon Bonaparte. I hope that these times are in the past and everyone can analyze the geodata of the entire Earth and get answers to their global questions in minutes and seconds. I published Openstreetmap_h3 - my project, which allows you to perform geoanalytics on data from OpenStreetMap in PostGIS or in any query engine that can work with Apache Arrow / Parquet.

First of all, I say hello to the haters and skeptics. What I developed is really unique and solves the problem of transforming and analyzing geodata using the usual and familiar tools available to every analyst and data science specialist without bigdata, GPGPU, FPGA. What looks easy to use and code now is my personal project where I have invested my vacations, weekends, sleepless nights and a lot of personal time over the past 3 years. Maybe I will share the background of the project and the rake that I went through, but first I will still describe the end result.

Today I will discover America to you based on OpenStreetMap data in PostgreSQL15/PostGIS and my project openstreetmap_h3. Let's run the query and compare its execution time on the Citus column store in PostgreSQL and on the standard 100GB database partitioned by H3 geoindex.

We will find the top15 buildable locations in North America and the total length of roads, as well as their type and surface. I will not overload the publication with program logs, let's focus on the data! You can easily repeat all requests yourself on your laptop/computer.

Сегодня открою вам Америку на основе данных OpenStreetMap в PostgreSQL15/PostGIS и моего проекта openstreetmap_h3. Запустим запрос и сравним время его выполнения на колоночном хранилище Citus в PostgreSQL и на стандартном в секционированной по H3 геоиндексу базе данных объемом 100GB.

Найдем top15 мест по застройке а Северной Америке и общую протяженность дорог, а также их тип и покрытие. Не буду перегружать публикацию логами программ, сфокусируемся на данных! Вы можете легко повторить все запросы самостоятельно на своем компьютере или ноутбуке.

Продолжим тему из публикации «Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap».

Сегодня визуализируем 15 мест где в России больше всего зданий. В этом нам поможет мой проект openstreetmap_h3 и PostgreSQL 15. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing. Сохраним данные в колоночное хранилище и посмотрим на план запроса для него.

В этой публикации мы будем агрегировать данные в большой таблице где нас интересуют для этих операций лишь два столбца и сможем извлечь пользу от этой модели данных на NVMe накопителе. Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus. Вперед, к заветной цели на самых свежих версиях программ нашего аналитического стека!

Зачем же обычному человеку информация из прошлой публикации "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap"? Если надоело в пятницу читать мемасики и лайкать фотографии котиков в соцсетях, то можно задаться глобальными проблемами аналитики и посчитать протяженность дорог России. Ведь не за горами времена автомобилей с автопилотами... Это конечно не 42, как ответ на главный вопрос жизни, вселенной и всего такого, но результаты будут тоже достаточно лаконичными.

Для этого нам понадобится ноутбук или обычный десктоп, несколько десятков гигабайт свободного места, установленный docker, JVM 11+, maven и мой проект openstreetmap_h3. Анализировать геоданные мы будем с помощью PostgreSQL 15.1, PostGIS 3.3.2, H3 4.1.1. Исходные данные из проекта OpenStreetMap, запросы к БД не претендуют на правильность и качество исходных данных в масштабе страны нам не известно! Данная публикация является грубой интерпретацией данных OSM в первом приближении и не претендует на истинность и неопровержимость. Так же как не стоит верить оценке Хабра на чтение статьи в 127 минут, что сильно превышает реальные 5 минут, которые вы потратите на ознакомление с публикацией.

Продолжу рассказ "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap" секретами о геоданных OpenStreetMap, на которых множество компаний построили бизнес но не все делятся подробностями... Что ж, сегодня приоткроем завесу!

База данных в PosgreSQL после загрузки из дампа занимает больше 587 GB. Это уже по меркам СУБД большая база и одна огромная таблица на каждый тип объектов не сработает. Для управляемости такие данные надо секционировать, хорошо что PostgreSQL поддерживает декларативное секционирование данных. Осталось лишь придумать как разделить географические данные. После поисков и сравнений мне на помощь пришла иерархическая гексагональная геопространственная система индексирования H Все это было реализовано в моем проекте openstreetmap_h3 для быстрой обработки и загрузки мира в базу.

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...

Поделюсь своим свежим опытом непрохождения интервью в канадскую компанию, может кому поможет пройти отбор и получить работу. Либо же узнать что творится с рынком труда с точки зрения разработчика в реальном мире.

Попытаюсь дать несколько советов начинающим изучать программирование и освоить профессию разработчика программного обеспечения. Возможно, некоторые из них вам покажутся спорными, у вас другой план на обучение или опыт когда удалось "войти в айти". Все рассказаное дальше субъективно, основано на моем опыте как интервьювера на Java вакансии, инженеров по данным.

* Определить свою мотивацию, нишу и специализацию

* Нужно ли профильное высшее образование.

И еще больше десятка пунктов личного рецепта, не только для Java разработчиков... Надеюсь, что эти советы помогут вам стать востребованным и хорошо оплачиваемым специалистом!

JVM основная платформа для Big Data решений, таких как Hadoop, Spark, Presto, NiFi но на производительность значительно влияют копирование/сериализация данных "на каждый чих" с последующей сборкой мусора и отсутствие SIMD оптимизаций при работе с данными.

А можно ли в программе на JVM прочитать сотни гигабайт Parquet файлов без Spark/Hadoop? В этом нам поможет библиотека Apache Arrow - проект, которым объединяются десятки решений для работы с Большими Данными. Но для этого даже не обязателен кластер с тысячами ядер и петабайты хранилища! Обработку данных начнем с "золотого стандарта" для open source: PostgreSQL 14 + PostGIS 3.2.0, а продолжим на OpenJDK 11 + Apache Arrow 9.0.0.

В качестве примера измерим с неизвестной точностью "среднюю температуру по больнице" - мы посчитаем число школьных зданий по всему миру в проекте OpenStreetMap. И когда говорят что образование избыточно и в школе дают много лишних знаний, то сразу же хочется задать компьютеру этот вопрос, сверив его с географией.