Привет! Меня зовут Вячеслав Пачков, я ведущий инженер по разработке ПО в департаменте СХД YADRO. В этом посте я расскажу о T-RAID — технологии защиты целостности данных, которая используется в нашей гибридной СХД TATLIN.UNIFIED, а также СХД для сверхбольших объемов данных TATLIN.ARCHIVE.
Это мой вольный перевод статьи "Data Engineering is Not Software Engineering", с рядом моих правок, дополнений, а так же сокращений (так как автор склонен повторять одно и то же, но иными словами или излишне "разжевывать" очевидные вещи). Мне кажется, автор действительно поднял очень важную тему, которую я "чувствовал" по своей практике, но не мог сформулировать так точно, как это сделал он.
Мало кто задумывается, что дата-инженерия и разработка ПО имеют значительные различия. Поэтому распространено мнение, что некое отставание дата-инженерии в части внедрения современных методов разработки, таких как Agile, Test Driving Development и т.д. обусловлено лишь отставанием в освоении этих передовых практик.
На самом деле этот взгляд ошибочен. Хотя дата-инженерия и разработка ПО действительно имеют много общего, между ними существуют значительные различия. Игнорирование этих различий и управление командой дата-инженеров по тем же принципам, что и командой разработчиков ПО, является ошибкой. Особенно этим грешат относительно молодые менеджеры, или те, кто никогда не работал с "датой". Собственно, этим зачастую и вызваны ошибки в пименении "в лоб" соврмененых методой разработки. Дата-инженерия — как томат: технически это фрукт, но это не значит, что его стоит добавлять в фруктовый салат.
Не разбрасывайте по офису флешки с персональными данными сотрудников и клиентов, обновляйте политику конфиденциальности и пользуйтесь российскими серверами.
Сегодня копилочку ваших знаний о работе с ПД пополнят еще несколько важных мыслей. Речь пойдет не о бездушных серверах и устройствах, а о людях – тех, кто должен работать с информацией.
Привет, Хабр! Меня зовут Наталья Горлова, я архитектор данных. Несколько лет назад мы в CDEK поняли, что продукты, на которых работало хранилище, перестали нас устраивать: не устраивала гибкость разработки и скорость поставки данных. C тех пор произошло множество изменений, которыми хочется поделиться с сообществом.
Расскажу, как платформа данных развивалась, и к чему мы пришли на конец 2024 года. Эта статья — ретроспектива моей почти шестилетней работы и текущих реалий нашей платформы данных.
Привет, Хабр! Я Артём Чаадаев, бэкенд-разработчик в Туту. Я занимаюсь разработкой на языке Go в команде ассортимента размещения. Мы отвечаем за работу с контентом отелей и интеграции с поставщиками.
Периодически мы собираем данные для аналитики, и в таких задачах нужно реализовывать схему отправки данных в ClickHouse. В этой схеме мы преобразовываем данные с помощью Redpanda Connect. В статье покажу простой практический пример работы с этим инструментом, который должен помочь тем, кто только начинает его использовать. А еще расскажу про преимущества и проблемы, с которыми мы столкнулись при работе с Redpanda Connect.
Мы живем в век данных и data-driven подхода. Есть продуктовые компании, где даже минимальные изменения в продукте обязаны пройти A/B-тест перед релизом (который из-за этого может и не состояться). С бумом данных и AI произошел и бум ETL (Extract, Transform, Load) инструментов. Сейчас, в 2024 году, выбор действительно впечатляет, даже если ограничиться только open source-решениями:
Корпоративные практики BI отличаются тем, что единое хранилище данных позволяет самым разным сотрудникам — от рядовых специалистов до ТОП-менеджеров — получать нужную информацию и анализировать ее для принятия верных решений. Но это становится возможным только в том случае, если можно гарантировать, что каждый пользователь получит доступ только к данным, которые он имеет право видеть. О том, как этот подход работает на уровне объектов, и в чем разница между RLS и OLS, читайте под катом.
Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.
Привет! Меня зовут Игорь Конев, я — старший инженер команды DBaaS в Авито. В этой статье я рассказываю о нашем подходе к работе Stateful-приложений в k8s на примере DBaaS и о том, как удалось автоматизировать жизненный цикл баз данных у нас в Авито. Статья будет полезна новичкам, которые не работали в Kubernetes, не сталкивались с менеджментом Stateful-приложений или хотели бы массово разворачивать базы данных в Kubernetes.
История, связанная с этой задачей, началась для нас в мае 2024 года. Один из крупных пользователей Greenplum/Arenadata DB обратился к нам с запросом реализовать возможность отслеживания изменения размеров файлов данных таблиц. Эта функциональность стала бы составной частью, источником событий для системы мониторинга пользовательских кластеров. Задача показалась нам крайне интересной и перспективной. Однако пользователю, как это часто бывает, решение требовалось уже вчера.
С одной стороны, мы осознавали всю сложность этой задачи в полнофункциональной реализации для всех пользователей нашего продукта (и как следствие, адекватно оценивали предполагаемые трудозатраты). С другой стороны, затачивать решение под конкретного пользователя, но в то же время и поставлять эту реализацию как часть общего решения мы сочли неправильным. По итогу команда разработки продолжила работу в своём темпе и в соответствии со своим представлением о реализации.
Хеш-индексы в PostgreSQL - мощный, но недооценённый инструмент.
Когда они быстрее B-Tree, а когда наоборот?
Простое объяснение, тесты и ключевые нюансы, которые помогут ускорить запросы...
Obsidian на Хабре посвящено немало статей и, главным образом, про то, как создать и вести в нем базу знаний или систему управления личными делами. При этом остается обделенной вниманием тема анализа накопленного графа заметок с точки зрения его структуры и динамики. А это дополнительный слой информации, в том числе не закладываемой явно в содержание самих заметок. В качестве примера проведу в данной статье анализ своего графа заметок, собранного за прошедший год.
Привет! Меня зовут Виталий Флёрин, я руководитель отдела BI-аналитики в M2. За год мы успешно перевели всю отчетность компании с Cognos Analytics на Apache Superset и увеличили MAU до 200 (каждый третий сотрудник компании). В статье хочу поделиться опытом внедрения новой системы отчетности и ее эффективного использования.
Материал будет полезен BI-специалистам, кто работает над развитием внутренних систем и хочет переехать на Superset.
История началась с того, что после ухода Cognos Analytics с российского рынка, нам нужно было выбрать новую BI для компании и мигрировать всю отчетность. Текущая система была развернута on-premises и продолжала работать в штатном режиме. Да, без обновлений и поддержки, но благодаря этому мы смогли тщательно подойти к выбору нового решения и обеспечить плавный переход пользователей на новую платформу.
Установка Arenadata DB 7.2 выполняется с помощью Arenadata Cluster Manager (ADCM). Это средство предназначено для разворачивания кластера на большом числе хостов с большим объемом оперативной памяти на каждом из них. А если кластер Arenadata нужен не для производительной работы, а для проведения экспериментов или для разработки/тестирования, можно ли развернуть его на компьютере с небольшим объемом оперативной памяти, например, 32 Гб? Будет ли кластер работать стабильно? Позволит ли он выполнять тяжелые операции? Каково минимальное количество виртуальных машин, на которых можно запустить Arenadata DB 7.2?
Данные — это новая нефть. От эффективности работы с ними напрямую зависит успех любого проекта, особенно в эпоху микросервисов. В этой статье мы погрузимся в мир данных и рассмотрим его с точки зрения Java-разработчика, который хочет добиться продуктивности и оставаться во всеоружии при работе с любыми объемами информации.
Цель этой статьи - предоставить полное руководство по структурам, концептам и инструментам для работы с данными в экосистеме Java, с уклоном в микросервисную архитектуру.
Мы пройдем путь от простейших структур данных, таких как примитивы и массивы, до сложных концептов, таких как озера данных и потоки событий. Рассмотрим различные способы хранения, обработки и передачи данных, а также архитектурные компоненты, необходимые для построения эффективных систем. Подробно остановимся на стратегиях развития - как правильно выбрать структуру и инструменты в зависимости от стадии развития проекта, от прототипа до высоконагруженной системы. Особое внимание уделим специфике микросервисной архитектуры и тому, как она влияет на выбор подходов к работе с данными.
Статья будет полезна Java-разработчикам разного уровня: от начинающих, желающих систематизировать свои знания, до опытных, ищущих решения для сложных задач в области хранения, передачи и обработки данных.
Привет! Как и обещала в первой части — теперь про ребалансировки и не только.
Выделяют безотлагательную и совместную ребалансировки.
При безотлагательной ребалансировке пользователи прекращают потребление из партиции, которые им назначены, затем отказываются от права владеть этими партициями, после снова присоединяются к consume group, получают совершенно новое назначение партиций и после этого возобновляют потребление. По сути, это короткое окно недоступности для всей consume group. Длина этого окна зависит от количества пользователей и некоторых параметров конфигурации.
Совместная ребалансировка - это инкрементная ребалансировка, при которой переназначается лишь некоторое подмножество партиций, и пользователи продолжают потребление из тех партиций, которые не были переназначены. Координатор уведомляет пользователей, что они должны будут отказаться от права владения некоторым подмножеством партиций, они прекращают потребление и отказываются от права владения. Затем эти партиции назначаются новым владельцам. Подход может включать несколько итераций, пока не будет достигнуто равномерное распределение. В отличие от безотлагательного подхода, мы не получаем полной недоступности. Это важно для больших consume groups, где балансировка может занять значительное количество времени.
Настраиваю домашний NAS на Ubuntu, сталкиваюсь с проблемами доступа через SMB на iOS, ищу решения и делюсь опытом. Рассказываю, как правильно настроить Samba, исправить несовместимости с Apple-устройствами с помощью VFS-модуля Fruit и избежать распространённых ошибок. В статье есть готовые конфиги, команды для настройки и ссылки на полезную документацию. Если вы тоже запускаете NAS и хотите минимизировать головную боль с правами доступа и совместимостью, этот материал для вас!
