Формальный непроцедурный язык программирования
В данной статье мы хотели бы рассказать о том, как мы в команде Wargaming Platform знакомились с BigQuery, о задаче, которую необходимо было решать, и проблемах, с которыми мы столкнулись. Кроме того, расскажем немного о ценообразовании и об инструментах, имеющихся в BigQuery, с которыми нам удалось поработать, а также предоставим наши рекомендации, как можно сэкономить бюджет во время работы с BigQuery.
В прошлой статье мини-цикла о работе с агрегатами я рассказывал, как организовать эффективное многопоточное преобразование потока первичных данных в данные агрегированные. Там мы рассматривали задачу "свертки" продаж в агрегаты вида товар/дата/кол-во.
Сегодня мы рассмотрим более сложный вариант, который зачастую начинается со слов "А заказчик захотел…" и приводит нас к иерархичным агрегатам в нескольких одновременных разрезах, которые позволяют нам в СБИС практически мгновенно строить оперативные отчеты в подсистемах организации торговли, бухгалтерского учета и даже управления активными продажами.
Как сообщает telegram-канал Cross Join, в репозиторий Postgres упал комит, упрощающий работу с jsonb. Теперь можно обращаться к частям jsonb с помощью квадратных скобок, причем это работает как на чтение, так и на запись.
Прощай jsonb_set и прочие костыли типа data = data - 'a' || '{"a":5}'
Обновляем значение объекта по ключу. 25 здесь является числом, но взято в кавычки, потому что присваиваемое значение должно быть jsonb
-- (person_data имеет тип jsonb)
UPDATE users
SET person_data['age'] = '25'; 
В общем задача звучала так: установить Redmine на сервер, где веб-сервер на nginx.
Так как Redmine написан на RoR, то необходимо иметь RoR среду, но проблема в том, что разные RoR приложения могут требовать разные версии окружения. В моем случае необходимо было предусмотреть возможность установки RoR приложений с разным окружением, а значит нужен менеджер версий, который будет разворачивать нужную среду в нужном месте.
Всем привет! На связи Александр Киваев, руководитель направления департамента управления справочной информацией в команде управления данными «Ростелекома». Если у вас в компании внедрена и эффективно работает MDM система, то считайте, что вы сорвали джэк-пот, потому что это значительно облегчит вам процесс внедрения новых информационных систем в IT инфраструктуру компании, упростит и удешевит интеграцию имеющихся систем, и позволит вам создавать качественную аналитическую и управленческую отчетность, сократив при этом время на обработку, актуализацию и верификацию данных.
Именно эти преимущества мотивируют крупные компании внедрять MDM-решения. В этой статье мы хотим рассказать об опыте внедрения системы управления мастер-данными Ростелекома, о том с какими сложностями мы столкнулись и какими способами нам удалось их решить.
Предположим, вам надо обработать на PostgreSQL большое (не, не так... БОЛЬШОЕ) количество записей, чтобы посчитать какие-нибудь агрегаты. В предыдущей статье были разобраны различные варианты, как это можно организовать, а в этой посмотрим, как при этом особо никого не заблокировать, включая "набегающий поток" данных.
Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок, или что-то еще... В любой управленческой системе подобных задач наберется горка, и СБИС тоже не является исключением.
Но у всех этих ситуаций есть общий момент - количество изменений сильно больше количества целевых агрегатов. Например: тысячи товаров, по каждому десятки тысяч отгрузок в день.
Всем привет! Я тимлид и Senior Oracle Developer, 12 лет работаю с OeBS и в основном пишу SQL запросы. Хотел бы рассказать, как за это время менялся мой подход в написании SQL запросов.
С течением жизни приложения в его БД накапливается все больше данных. Десктопное оно, SaaS или даже мобильное - неважно, в современном мире почти каждый что-то хранит "у себя".
Если это какая-то локальная утилита - не страшно, само ее существование у пользователя достаточно ограничено. Но если это что-то вроде нашего СБИС, который накапливает и помогает анализировать операции за все время существования бизнеса, то, по мере его роста, не только операций становится больше, но и понимания, какие именно сводные отчеты помогают в оперативном управлении.
Вот про то, как сделать такие отчеты быстрыми, какие бывают способы их реализации и встречаются "грабли" на этом пути, сегодня и поговорим.
Ваша банковская система будет назначать клиентам более высокий процент, на основании того что они не живут по адресу, на который указывает штамп в паспорте о прописке - а реально это та же самая улица, она раньше называлась по другому. Как подобного избежать?
Особо углубляться в описание малинового продукта нет необходимости. Глобальная сеть пестрит статьями с описанием как самого микрокомпьютера, так и проектов на нем.
Не буду лукавить и приводить кучу доказательств и обоснований того почему сделано так как сделано (а с учетом ценников на пром автоматику, система получилась копеечная, <150$ против самой дешевой дельты с ограниченным функционалом за 300$), так как давным-давно меня заинтересовал симбиоз RasberyPi и программного комплекса промышленной автоматизации Codesys и хотелось проверить на реально необходимом проекте. И только поэтому был выбран данный «Hardware», хоть и сомнение в стабильной работе не покидали до последнего момента.
Сегодня я расскажу о том, как использовать функцию `UNNEST` в Google BigQuery для анализа параметров событий и свойств пользователей, которые вы получаете вместе с данными Google Analytics.
Привет, Хабр! Меня зовут Артемий Козырь.
За последние годы у меня накопился довольно обширный опыт работы с данными и тем, что сейчас называют Big Data.
Не так давно также разгорелся интерес к сфере интернет-маркетинга и Сквозной Аналитики, и не на пустом месте. Мой друг из действующего агентства снабдил меня данными и кейсами реальных клиентов, и тут засквозило понеслось.
Получается довольно интересно: Azure SQL + dbt + Github Actions + Metabase.
GET /api/products?page=10
{"items": [...100 products]}GET /api/products?page=11
{"items": [...another 100 products]}
Для многих систем характерен паттерн постоянного накопления данных с течением времени. Причем основная их масса больше никогда не изменяется - то есть они пишутся в режиме append-only.
Это не только различного рода логи и метрики оборудования, но и такие, казалось бы, несвязанные вещи, как переписка между пользователями или комментарии к новостям.
Около года назад я уже писал про модель организации секционирования таких данных и вызываемые этим каскадные изменения в структуре БД. А сегодня на примере нашего сервиса анализа логов PostgreSQL-серверов разберем особенности обслуживания организованных так баз, и как грамотный подход (и немного ночной работы) может сократить затраты на инфраструктуру в разы.
Транзация — это набор операций по работе с базой данных, объединенных в одну атомарную пачку.
Транзакционные базы данных (базы, работающие через транзакции) выполняют требования ACID, которые обеспечивают безопасность данных. В том числе финансовых данных ? Поэтому разработчики их и выбирают.
Я расскажу о том, что такое транзакция. Как ее открыть, и как закрыть. И почему это важно — закрывать транзакцию. И тогда при написании запросов к базе у вас будет осознанное понимание, что происходит там, под капотом, и зачем же нужен этот обязательный коммит после апдейта.
Каждому специалисту по обработке и анализу данных, прежде чем запускать на своем наборе данных сложные алгоритмы машинного обучения, нужно исследовать и проанализировать его несколькими способами.
Бессерверный SQL — это инструмент распределенных вычислений, который позволяет обрабатывать распределенные данные с помощью языка SQL без необходимости администрировать серверы баз данных. Если у нас есть данные, или даже "большие данные", в одном из наших озер или хранилищ, например AWS S3 или хранилище BLOB-объектов Azure, мы сможем выполнить запрос SQL на этих данных без необходимости создавать конвейер или импортировать данные в распределенные базы данных, например в Cassandra или MongoDB.
Это огромное преимущество, особенно если мы собираемся взаимодействовать с данными в автономных системах, не создавая конвейеры, или просто взглянуть на абсолютно новые данные, которые только что были добавлены в хранилище, прежде чем реплицировать или преобразовывать их, а затем сохранять в выделенную базу данных.
Подробности под катом!
Одним из наиболее частых требований-"хотелок" бизнеса является построение всяких разных рейтингов - "самые оборотистые клиенты", "самые продаваемые позиции", "самые активные сотрудники", … - любимая тема разных дашбордов.
Традиционно, есть два подхода к этой задаче: запрос по требованию по "сырым" данным или предварительная агрегация. И если "просто посчитать" такой отчет по первичке - упражнение для SQL-новичка, но очень "тяжелое" для производительности СУБД, то вариант сделать так, чтобы он строился практически мгновенно при большом количестве активных аккаунтов независимых бизнесов, как у нас в СБИС, без необходимости пересчитывать агрегированную статистику каждый день судорожно по всем клиентам - интересная задача.