Публикации, рассказывающие о хранилищах данных
Привет Хабр!
Сегодня познакомимся с ключевыми новинками в версии 5.5 нашего продукта "Кибер Инфраструктура". Кибер Инфраструктура — это универсальное решение, которое представляет собой мультипротокольное программно-определяемое хранилище и платформу виртуализации в одном продукте.
Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем.
За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.
Привет, Хабр! Меня зовут Антон Аплемах, и я владелец продукта cloudfort в облачном провайдере beeline cloud. В блоге на Хабре и в нашем медиа мы рассказываем про open source, тренды в разработке программного обеспечения и облачные технологии. И сегодня я хочу поговорить про хранилища S3, запуск и настройка которых — нетривиальная задача. Какие услуги на основе объектных хранилищ использует бизнес (включая наш новый продукт cloudfort), и что учитывать при выборе решения.
CDC вам не «Centers for Disease Control and Prevention» а «Change data capture». В статье рассказано какие есть виды CDC и как реализовать один из CDC при помощи Debezium.
Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.
Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.
Сгенерированные UUIDv7 имеют все преимущества UUID и при этом упорядочены по дате и времени создания. Это ускоряет поиск индексов и записей в БД по ключу в формате UUID, значительно упрощает и ускоряет базы данных и распределенные системы. Неупорядоченность значений UUID прежде сдерживала использование UUID в качестве ключей и вынуждала разработчиков выдумывать собственные форматы идентификаторов или довольствоваться последовательными целыми числами в качестве ключей.
Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".
Разные участники разработки нового стандарта придерживались различных взглядов, и практически все обсуждавшиеся альтернативные варианты структуры UUIDv7 вошли в стандарт. Поэтому теперь перед разработчиками возникает вопрос, какую из множества возможных спецификаций UUIDv7 реализовывать и применять. Также для массового перехода на UUIDv7 нужна дополнительная функциональность, повышающая привлекательность UUIDv7 для разработчиков и бизнеса.
Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации
Сегодня, когда объёмы данных постоянно растут, а терять их становится всё критичнее, использование внешнего накопителя часто становится необходимостью. У каждого из нас есть файлы, которыми мы дорожим — от рабочих документов до фотографий с домашними питомцами. При этом у жёстких дисков есть срок службы и вероятность отказа в самый неподходящий момент. У меня был подобный опыт с накопителем Seagate и ошибкой «муха СС». С тех пор я в обязательном порядке дублирую все важные файлы в облако и ещё на один диск.
Всем привет!
Как вы знаете, многие поставщики ПО ушли с российского рынка ввиду введённых санкций и многие компании столкнулись с необходимость заняться импортозамещением в кратчайшие сроки. Не стал исключением и наш заказчик. Целевой системой, на которое было принято решение мигрировать старое хранилище, стал Greenplum (далее GP) от компании Arenadata.
Этой статьей мы запускаем цикл материалов посвященных Greenplum. В рамках цикла мы разберем, как вообще устроен GP и как выглядит его архитектура. Постараемся выделить must have практики при работе с данным продуктом, а также обсудим, как можно спроектировать хранилище на GP, осуществлять мониторинг эффективности работы и многое другое. Данный цикл статей будет полезен как разработчикам БД, так и аналитикам.
Доступ к единой истории операций — функция, которую сегодня ожидают видеть пользователи любого современного интернет-банкинга. В приложениях Газпромбанка функция существует уже много лет, но некоторое время назад мы решили существенно её переработать. В этой статье я расскажу, что мы поменяли, как и почему мы решили это сделать, а также почему мы гордимся результатом.
Сразу оговорюсь, что не буду углубляться в технические детали и остановлюсь на подходе, который мы решили использовать. Иначе есть риск что статья превратится в километровое полотнище. А если возникнут вопросы, то либо отвечу на них в комментах, либо аккумулирую и попробую разобрать в следующей статье.
Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.
Что делает наша команда
Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.
Описание задачи
У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.
Ответы приходят в формате JSON. Документации достаточно для начала загрузки, но для полного понимания структуры и содержимого ответа — маловато.
Мы решили просто загружать все подряд — на месте разберемся, что нам нужно и как мы это будем грузить, потом пойдем к источникам с конкретными вопросами. Так как каждый метод API отдает свой класс данных в виде JSON, в котором содержится массив объектов этого класса, нужно построить много таких пайплайнов с обработкой разного типа JSON’ов. Еще одна сложность — объекты внутри одного и того же класса могут отличаться по набору полей и их содержимому. Это зависит от того, как, например, сотрудники подбора заполнят информацию о вакансии на этом сервисе. Этот API работает без версий, поэтому в случае добавления новых полей информацию о них мы получим только либо из данных, либо в процессе коммуникации.
В статье описывается практическое применение популярных Open-Source технологий в области интеграции, хранения и обработки больших данных: Apache NiFi, Apache Airflow и Greenplum для проекта по аналитике учета вывоза отходов строительства.
Статья полезна специалистам и руководителям, которые работают с данными решениями и делают ставку на них в части импортозамещения аналогичных технологий. Статья дает обзор основных сложностей внедрения на примере реального кейса, описывает архитектуру и особенности при совместном использовании решений.
Всем привет! Меня зовут Амир, я Data Engineer в компании «ДЮК Технологии». Расскажу, как мы спроектировали и реализовали на Apache Druid хранилище разрозненных табличных данных.
В статье опишу, почему для реализации проекта мы выбрали именно Apache Druid, с какими особенностями реализации столкнулись, как сравнивали методы реализации датасорсов.
В статье рассказываем о том, кому стоит задуматься о внедрении DWH, как сократить вероятность ошибок на этапе разработки проекта, выбрать стек, методологию и сэкономить ИТ-бюджеты.
В конце прошлого года мы писали о сложном переезде нашего собственного сервиса в новый дата-центр в Детройте. Среди прочих задач мы переносили Clickhouse. Напомню, что речь идет о нагруженном сервисе, который обслуживает десятки серверов, принимающих сотни тысяч запросов с низкой latency в секунду.
В этой статье рассказываем, как мы переносили данные, не имея возможности отключить сервис или воспользоваться автоматической репликацией.
Объем данных для Clickhouse у нас не такой уж и большой - процесс получился не столько объемный, сколько ресурсоемкий. Но в открытых источниках информации по использованным механизмам минимум, поэтому считайте это руководством к clickhouse-copier утилите (https://github.com/ClickHouse/copier) на конкретном примере со скриптами и командами для запуска.
Мой первый опыт на Хабре получился не очень положительным, и, признаюсь, до сих пор смотря на комментарии и оценки, мне стыдно и больно где-то внутри.
Потому в имя исправления ошибок молодости решил написать серию статей о том, как дома собрать свою "идеальную" хранилку, или сервак, или мини облако. Поделюсь опытом, своими знаниями и пониманием, а также мыслями, которые могут помочь выполняя похожую задачу для себя.
Обнаружил серию статей по принципам организации информации и базам данных от математика из Стокгольмского университета и с энтузиазмом перевожу. Моя уверенность в том, что реляционки с 3-й формой нормализации - лучшее, что придумало человечество, резко убавилась... Я бы назвал это "субъективной теорией информации", автор называет "Transitional modeling", но обычно это применяется под названием "якорная модель данных"...
Привет, аналитики!
В прошлый раз мы разобрались, как бизнес-аналитику наладить взаимодействие со стейкхолдерами и превратить их противоречивые требования в единую систему.
Сегодня я хочу поговорить о дальнейшей работе аналитика в проектах по созданию хранилищ данных (DWH). Как пройти весь путь от сбора требований до внедрения готового решения, сохраняя баланс интересов бизнеса и ИТ.
Мы уже выяснили потребности пользователей и достигли консенсуса по целям системы. Теперь предстоит воплотить эти требования в реальное DWH. И здесь нас ждет не меньше подводных камней, чем на этапе согласования.
Как избежать недопонимания между бизнесом и ИТ в ходе проектирования? Как убедиться, что разработанное решение действительно решает задачи заказчика? И как помочь пользователям безболезненно перейти на новую систему?
Привет, Хабр! На связи группа экспертов по управлению данными из МТС.
А именно: Патрисия Кошман — руководитель группы (управление метаданными) и Аксинья Ласкова — эксперт по практикам качества данных.
Сервисы МТС собирают огромное количество данных разных типов и качества, начиная с информации об оборудовании сети и заканчивая данными о кинопроизводстве. Естественно, эти данные нужно хранить, обрабатывать и находить им применение.
Как это происходит у нас — рассказали под катом!
Хранилище данных — это информационная система, в которой хранятся исторические и коммутативные данные из одного или нескольких источников. Он предназначен для анализа, составления отчетов и интеграции данных транзакций из разных источников.
Рассмотрим сильные и слабые стороны самых популярных методологий.