Всем привет!
Если посмотреть на тему null safety с другой стороны - то это лишь один из аспектов более широкого принципа. Я бы сформулировал его как: "Знай свои данные".
Что же нужно знать:
1) кодировку текстовых данных - всегда явно ее указывать, не ждать, что всегда будет UTF-8
2) часовой пояс\locale - опять же не надеяться на то, что CI pipeline, тестовые и ПРОМ стенды работают в одном часовом поясе. А даже если это так - что на всех правильно настроен часовой пояс) И что никто не запусти код в другом часовом поясе. И никто не пришлет время из другого часового пояса
3) файловую систему, в частности разделители в пути к файлу. Для них есть специальные константы в Java Core, ОС в которой происходит запуск также можно определить
4) все проверки на injection - sql injection и аналоги
5) указание конкретных проверяемых исключений вместо Exception. Это не совсем данные, но часто исключения вызываются некорректными данными
6) unit тесты на граничные значения
7) ну и наконец null safety - может ли по бизнес-процессу значение принимать null или нет
Принцип можно расширить до инфраструктуры и добавить к примеру версии используемых библиотек и плагинов. Если версии не фиксировать - могут подтянутся новые в неожиданный момент с неожиданным поведением)
P.S. Если что-то забыл - дополняйте в комментах
#data #principles
Если посмотреть на тему null safety с другой стороны - то это лишь один из аспектов более широкого принципа. Я бы сформулировал его как: "Знай свои данные".
Что же нужно знать:
1) кодировку текстовых данных - всегда явно ее указывать, не ждать, что всегда будет UTF-8
2) часовой пояс\locale - опять же не надеяться на то, что CI pipeline, тестовые и ПРОМ стенды работают в одном часовом поясе. А даже если это так - что на всех правильно настроен часовой пояс) И что никто не запусти код в другом часовом поясе. И никто не пришлет время из другого часового пояса
3) файловую систему, в частности разделители в пути к файлу. Для них есть специальные константы в Java Core, ОС в которой происходит запуск также можно определить
4) все проверки на injection - sql injection и аналоги
5) указание конкретных проверяемых исключений вместо Exception. Это не совсем данные, но часто исключения вызываются некорректными данными
6) unit тесты на граничные значения
7) ну и наконец null safety - может ли по бизнес-процессу значение принимать null или нет
Принцип можно расширить до инфраструктуры и добавить к примеру версии используемых библиотек и плагинов. Если версии не фиксировать - могут подтянутся новые в неожиданный момент с неожиданным поведением)
P.S. Если что-то забыл - дополняйте в комментах
#data #principles
👍4
Всем привет!
Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему https://habr.com/ru/companies/vk/articles/720652/
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.
#ddd #data_mesh
Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему https://habr.com/ru/companies/vk/articles/720652/
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.
#ddd #data_mesh
❤1🔥1
Java vs Python, часть не помню какая)
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
👍2❤1🔥1
PostgreSQL наносит ответный удар)
Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных.
И отъедающие долю рынка у реляционных СУБД.
Но есть и обратный процесс.
Уже писал про расширения для PostgreSQL. Так вот, возможность хранить NoSQL данные добавляются, как правило, с их помощью.
Что у нас есть на данный момент?
Рассмотрим работу с разными типами данных:
1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки
2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним
3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших...
4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html
5) пространственные данные (spatial) - PostGIS
6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема.
К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли.
А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных.
И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции.
Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита.
P.S. Кроме того, из PostgreSQL можно сделать key-value storage (но не нужно, кэш и БД вместе все равно держать нет смысла). И объекто-ориентированную БД (но зачем, даже не слышал про использование объектных БД, хотя они есть).
Если смотреть на основные типа БД https://db-engines.com/en/ranking - разве что Wide column не покрыты. Но там не просто произвольный набор столбцов у каждой записи, там еще и append only запись как в Kafka для собственно скорости записи.
#postgresql #data #rdbms #nosql
Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных.
И отъедающие долю рынка у реляционных СУБД.
Но есть и обратный процесс.
Уже писал про расширения для PostgreSQL. Так вот, возможность хранить NoSQL данные добавляются, как правило, с их помощью.
Что у нас есть на данный момент?
Рассмотрим работу с разными типами данных:
1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки
2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним
3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших...
4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html
5) пространственные данные (spatial) - PostGIS
6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема.
К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли.
А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных.
И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции.
Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита.
P.S. Кроме того, из PostgreSQL можно сделать key-value storage (но не нужно, кэш и БД вместе все равно держать нет смысла). И объекто-ориентированную БД (но зачем, даже не слышал про использование объектных БД, хотя они есть).
Если смотреть на основные типа БД https://db-engines.com/en/ranking - разве что Wide column не покрыты. Но там не просто произвольный набор столбцов у каждой записи, там еще и append only запись как в Kafka для собственно скорости записи.
#postgresql #data #rdbms #nosql