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

Из-за того, что программы обучения (а, следовательно, и компетенции) физиков и программистов сильно отличаются, при их совместной работе над экспериментами нередко возникают трудности. Мы в лаборатории методов ядерно-физических экспериментов ставим своей целью подготовку специалистов, которые могут и разобраться в физике процессов, и написать необходимое программное обеспечение. Для этого в прошлом году мы запустили магистерскую программу, а в этом еще один проект, направленный на знакомство физиков с программированием. О нем я и расскажу в этой статье.

Мы все чаще используем ClickHouse, и эта СУБД хорошо себя зарекомендовала для построения хранилищ данных и выполнения аналитических проектов. Благодаря column-oriented архитектуре ClickHouse сочетает в себе высокую производительность при вставке больших данных (миллионы строк в секунду) и невероятно быстрый full-scan по большим таблицам. Однако, за такую скорость работы этой СУБД приходится платить определёнными ограничениями, а пользователю – иметь ввиду нюансы (некоторые из них мы описали в предыдущей статье), которые непосредственно влияют на проектирование и разработку решений на базе Clickhouse.

В данной статье покажем – с какими трудностями мы столкнулись из-за архитектурных ограничений ClickHouse и как их преодолели, сократив потребляемые ClickHouse-сервером ресурсы почти в 50 раз.

В сборнике VLDB'17 вышла такая статья. В ней представлена NAM-DB, масштабируемая распределённая система баз данных, использующая удалённый прямой доступ к памяти (RDMA) — в основном, однонаправленный вариант RDMA — и инновационную технологию диспетчера временных меток (timestamp oracle) для поддержки транзакций с изоляцией мгновенного снимка (SI). NAM в данном случае означает архитектуру с прикреплением памяти к сети (network-attached-memory), где благодаря активному использованию RDMA вычислительные узлы получают возможность напрямую общаться с пулом узлов памяти.

Greenplum 7 — первая версия СУБД, совместимая с секционированными таблицами из PostgreSQL: World DB. 

Небольшая предыстория: до PostgreSQL 10 партицирование в PostgreSQL выполнялось в очень ограниченной форме и по сути, было просто вариантом наследования таблиц. Начиная с PostgreSQL 10, мы можем использовать декларативный синтаксис для определения парадигмы разделов. 

В рамках слияния с PostgreSQL 12 Greenplum 7 вобрал в себя весь синтаксис PostgreSQL для разбиения таблиц, сохранив при этом синтаксис Greenplum. В результате у Greenplum 7 есть шанс взять лучшее из обоих миров — что именно, обсудим в этой статье. 

Данная статья посвящена в первую очередь начинающим ИТ аналитикам, которые хотят верхнеуровнево разобраться, как необходимо описывать интеграции между системами и как процесс выглядит в целом. Просьба учесть, что часть терминов написана своими словами и намерено упрощена для лучшего понимания. Я думаю, что статья также может быть также полезна менеджерам проектов, ИТ-лидам, менеджерам процессов и разным другим менеджерам, работающим в ИТ.

Перед тем, как рассказать, как могут выглядеть требования к интеграции, я бы хотел обратить внимание, что эта самая интеграция должна быть представлена на общей корпоративной архитектуре. Процесс управления изменениями и обновление архитектурных артефактов может отличаться в разных компаниях, поэтому бывает, что архитектурная служба (и\или служба интеграции) даже не знает о планируемом новом потоке между двух приложений, поэтому я рекомендую аналитику в первую очередь убедится, что поток присутствует на общей корпоративной архитектуре и о нём знают соответствующие подразделения.

И снова здравствуй, Хабр! Сегодня поговорим об актуальной для многих из нас проблеме при работе с базами данных. В ходе работы над разными проектами часто приходится создавать базу данных  (командное пространство, песочница и т.п.), которую использует как сам автор, так и/или коллеги для временного хранения данных. Как у любого «помещения», в нашей «песочнице» есть своё ограничение по объёму выделенного места для хранения данных.  Периодически бывает так, что вы или ваши коллеги забываете об этом маленьком ограничении, из-за чего, к сожалению, заканчивается объём выделенной памяти.

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

Привет, Хабр. Меня зовут Юрий Зорин, в Quadcode я руковожу Ops-департаментом. В марте 2022 года мы внедрили в команде внутреннее менторство: теперь у наших junior-инженеров есть наставник, который помогает развивать нужные навыки. В этой статье хочу рассказать, какой путь мы прошли на текущий момент и подвести первые итоги.

Меня зовут Дмитрий Немчин, я руковожу отделом, который отвечает за движки хранения и обработки данных в платформе данных Тинькофф. Несколько лет назад мы поняли, что продукты, на которых работало хранилище, перестали нас устраивать. Объемы росли, понадобилось масштабируемое решение. В этом тексте я расскажу, как мы пришли к Greenplum в качестве ядра хранилища данных и как используем его. 

Привет! Продолжаю рассказ про интеграционную платформу на базе Apache Kafka и про то, как мы постарались гармонично вписать ее в непростую ИТ инфраструктуру группы НЛМК.

Напомню, что в первой части статьи были описаны соглашения об именовании топиков, подход к реализации ролевой модели и соглашение по базовой схеме данных. Здесь расскажу, как сделали универсальное охлаждение для всех данных из Kafka в корпоративное хранилище на базе Hadoop, про сервис доставки сообщений в ИС и про разработанные сервисы, доступные на нашем Self-Service портале.

Создание пайплайнов для трансфера данных — рутинная задача Data-инженеров. Чтобы ее решить, многие копируют код коннекторов из одного проекта в другой. Из-за копипаста общая структура ломается, и в перспективе может возникнуть трудность с поддержкой проекта.

Источников данных много — Яндекс.Директ, Google Analytics и другие. По отдельности они не дают нужной картины, — данные всё равно приходится собирать в один Data Warehouse. Тут на помощь приходит Meltano: он позволяет стандартизировать написание коннекторов к различным источникам данных и быстро перенести все нужные данные.

С чего началась наша компания? В первую очередь, конечно, с людей и с идеи. Как это обычно бывает, правильные люди абсолютно случайно познакомились друг с другом, и вот я здесь, сижу и пишу этот пост =) Была, однако, и ещё одна очень важная составляющая - данные...

Любой ML-проект начинается с анализа ландшафта доступных данных - что мы можем скачать, выгрузить, разметить, купить. За четыре года наша культура работы с данными, инструментарий, подходы, процесс разметки претерпели очень большие изменения. Сейчас у нас накоплено почти 100 терабайт медицинских исследований, но количество данных абсолютно не важно, если они плохого качества, и их неудобно изучать, понимать и использовать. Недавно я делал обзорный доклад про разные аспекты качества медицинских данных, а вот наше выступление про технические аспекты пути к качеству. Сегодня же я хочу поговорить об очень интересной концепции (или даже философии), которая в последнее время на слуху, но, судя по разным постам в интернете, её суть понятна далеко не всем. Это Data Mesh.

Впервые я столкнулся с этим понятием в докладе Леруа Мерлен на митапе LeanDS. Доклад любопытный, но суть дата меш мне из него была понятна не до конца, так что недавно я взялся за чтение книги от авторки этой концепции и термина - Data Mesh: Devlivering Data-Driven Value at Scale.

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

Границы есть в любых отношениях — и в семейных, и в дружеских, и в деловых. Но в каждом случае они разные. Если в семье принято целовать друг друга в щёчку при встрече, то такие жесты на работе воспримут странно. Очень важно понимать и знать свои границы. Это поможет предотвратить выгорание, избежать конфликтов и недопониманий между коллегами. Так как же огородить себя от недобросовестного работодателя и некомпетентного рекрутера? Как выстроить личные границы с коллегами? Это мы с вами сейчас и узнаем.