Язык программирования Java является одним из самых распространенных языков программирования. На нем написано множество сложных приложений как под Linux, так и под Windows. Однако, как и у любого другого языка программирования, у Java есть свои уязвимости.
Цель этой статьи познакомиться с уязвимостями, типичными для языка программирования Java, а также разобрать практики безопасного кодирования.
Эта статья о том, как аналитик изучает основы SQL, какие допускает ошибки и как старается их исправить. В статье будет то, что помогает погрузиться в SQL впервые: схемы и примеры кода, понятия и определения, проблемы и решения. Статья рассчитана на аналитиков-новичков.
Предыстория: аналитик создает отчёты в BI для директора компании «ABC». Аналитик не умеет программировать и подключается к данным по инструкции. Директор требует срочно добавить в отчёт данные из 3 источников: SAP – объем выручки от продаж; HRLink – затраты на персонал; Битрикс – время обработки заявок.
Аналитик ставит задачу data инженеру на добавление новых данных в BI. Data инженер – единственный специалист по работе с данными в офисе из 400 человек. Он критически оценивает сроки выполнения задачи и объявляет: «Минимум – 2 недели». Такой срок директора не устраивает. Инженер предлагает аналитику альтернативное решение...
Привет! Меня зовут Михаил Благов, я руководитель департамента «Чаптер инженеров данных и разработчиков» в beeline tech. В этом посте я хочу поделиться способом, с помощью которого можно выбрать подходящую архитектуру для конвейера данных в зависимости от требований к нему. В частности, обсудим паттерн CDC (change data capture, aka «захват изменений»), основная идея которого — быстрая репликация какого-то источника в аналитическое хранилище.
Под катом мы:
- познакомимся с вариантами архитектуры конвейеров данных: из каких компонентов и как его можно собирать,
- рассмотрим и сравним четыре разные архитектуры конвейеров.
Disclaimer: серебряной пули не будет, в этой статье я поделюсь опытом выбора архитектуры для решения конкретной задачи. Аналогичный выбор для других случаев потребует дополнительных исследований и замеров производительности.
Начнем с матчасти
В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".
Универсального способа сделать «хорошо» тут нет, но я расскажу про модель запроса, которая позволит вам дать пользователю быстрый отклик, но при этом весьма эффективно с точки зрения PostgreSQL.
Меня зовут Василий, и уже больше пяти лет я причиняю DevOps в хранилищах. Последние полтора года руковожу группой автоматизации хранилищ данных в Почтатехе.
В нашем data warehouse 6,5 петабайт активных данных. Вы и сами можете представить масштабы, когда речь идет о Почте России: работа сайта и приложения, логистика, трейсинг посылок и даже строительство сортировочных центров основываются на данных нашего хранилища.
Я расскажу, как мы применяем DevOps-практики на таких объемах DWH и как внедрить подобное у себя.
Без справочников не обходится ни одна информационная система. Как правило, такие справочники представлены в виде одной либо нескольких таблиц, иногда связанных между собой. Одной из проблем является "неполнота" данных, когда справочник не заполнен по определенным позициям.
Необходимо разработать структуру справочника, который выдает значение "всегда", если нет значения в запрашиваемом узле справочника - должно быть выдано значение из вышестоящего уровня иерархии.
После всем известных событий некоторые каналы привлечения платного трафика стали недоступны или существенно снизилась их отдача.
Мы в Completo более активно стали привлекать клиентов с помощью других инструментов. Это позволило не просесть по лидам. В результате мы получаем от 900 до 1200 MQL ежемесячно, в том числе благодаря автоматизации процессов. В этом материале делимся опытом и рассказываем, как работает автоматизация у нас.
Всем привет! В данной статье попробуем разобраться с проблемой N+1 (или может правильнее 1+N?) и как ее решить с помощью использования EntityGraph.
Проблема N+1 возникает, когда мы генерируем запрос на получение одной сущности из базы данных, но у данной сущности есть свои связанные сущности, которые мы тоже хотим получить и hibernate генерирует вначале один (1) запрос к базе данных, чтобы получить интересующую нас сущность, а потом N запросов, чтобы достать из базы данных связанные сущности. Данная проблема отражается отрицательно на производительности работы базы данных из-за большого числа обращений к ней.
Создадим проект и подключим следующие зависимости:
Привет, Хабр! Меня зовут Салават Сафиуллин, и сегодня я хочу поделиться с вами своим первым опытом создания дашборда на Visiology 3. Это новая версия платформы, которой мы пользуемся уже несколько лет, но она кардинально отличается как архитектурой, так и принципами работы. Дашборды на версии нужно создавать заново и по-другому. Поэтому мне было особенно интересно сделать пробу и подготовить дашборд на базе демонстрационной Visiology 3.0. Под катом — подробный рассказ о моем "пилоте" и некоторые мысли о работе с новой версией Visiology.
В последнее время всё большую популярность набирает Tarantool — платформа in-memory вычислений с гибкой схемой данных, включающая в себя NoSQL-базу данных и сервер приложений. В этой статье я хочу рассказать об одной из его реализаций — Tarantool Data Grid (TDG).
MySQL на сегодняшний день является одной из наиболее распространенных в мире. Достаточно сказать, что по рейтингам 2021 года данная СУБД лишь немного уступала Oracle.
Привет, Хабр! Меня зовут Федор Тюрин, я руководитель команды продуктовой аналитики в Учи.ру. Мы проводим очень много А/Б-тестов (десятки запусков в неделю и сотни в течение года). В таких условиях очень важна автоматизация процесса анализа и подведения итогов теста.
Сегодняшняя задача вполне традиционна для любых учетных систем - поиск записей, содержащих максимальное значение по каждому из ключей. Что-то вроде "покажи мне последний заказ по каждому из клиентов", если переводить в прикладную область.
Кажется, что тут и споткнуться-то негде в реализации - но все оказывается совсем не тривиально.
Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.
Выковыривание информации из html — это скучно. Очень. Между тем, эта потребность выстреливает редко, но метко (© Суворов). Из-за этого есть спрос на готовые и короткие инструкции о том, как это сделать, чтобы не тратить время на изучение. Перед вами как раз такая.
Чтобы добавить хоть какой-то интерес скучнейшему занятию мы для примера будем парсить пользователей Хабра. А чтобы не мелочиться — ещё и реанимируем для этого экспериментальную библиотеку 11-летней давности.
Есть такой проект — htmlSQL. Старая библиотека времён Очаковских и покоренья Крыма (© Грибоедов). Она позволяет делать выборку из HTML в стиле SQL-запросов как на КДПВ, чем она мне когда-то и полюбилась.
