Хранилища данных *

• совместно используемые файлы в облачных хранилищах (например, Dropbox, iCLoud, Sync, Egnyte, Ionos Hidrive, AWS S3);
  
• инструменты NAS с облачным подключением (например, Western Digital Mycloud);
  
• корпоративные коммуникации (Slido, Zoom, Onedrive, Airtable и др.);
  
• ссылки для сброса пароля, ссылки для входа Oauth.

Долгожданный стандарт 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. И здесь нас ждет не меньше подводных камней, чем на этапе согласования.

Как избежать недопонимания между бизнесом и ИТ в ходе проектирования? Как убедиться, что разработанное решение действительно решает задачи заказчика? И как помочь пользователям безболезненно перейти на новую систему?

Привет, Хабр! На связи группа экспертов по управлению данными из МТС.
А именно: Патрисия Кошман — руководитель группы (управление метаданными) и Аксинья Ласкова — эксперт по практикам качества данных.

Сервисы МТС собирают огромное количество данных разных типов и качества, начиная с информации об оборудовании сети и заканчивая данными о кинопроизводстве. Естественно, эти данные нужно хранить, обрабатывать и находить им применение.

Как это происходит у нас — рассказали под катом!

Хранилище данных — это информационная система, в которой хранятся исторические и коммутативные данные из одного или нескольких источников. Он предназначен для анализа, составления отчетов и интеграции данных транзакций из разных источников.

Рассмотрим сильные и слабые стороны самых популярных методологий.

Здравствуйте, Хабровчане!

Сегодня мы хотим рассказать о новых продуктах АЭРОДИСК в области систем хранения данных – моделях СХД ENGINE AQ Лайт, AQ 440 и AQ 450. Это очень значимое обновление линейки СХД в этом году, и, что немаловажно, оно связано не только с обновлением на программном уровне, но и с изменениями в аппаратном обеспечении.

Чтобы первым узнать про новую линейку СХД Engine АQ и функциональные возможности каждой модели – записывайтесь на наш вебинар «Синергия технологий: Обзор новой линейки СХД от Аквариус и АЭРОДИСК» 9 апреля в 15:00 (МСК).

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

Рассказываем, чем грамотно построенные процессы управления мастер-данными могут помочь продажам. 

Привет! Меня зовут Андрей Чучалов, я работаю в билайне, и в этом посте я расскажу про оптимизацию параметров запуска приложений в Spark, поиск проблем и повышение производительности. Разберем запуск приложений Spark в базовой и расширенной версиях, покажу методы расчёта основных параметров работы приложения для производительности и эффективности использования доступных ресурсов кластера. Бонусом — о том, как всё это привязано к деньгам, и где сэкономить можно, а где — не стоит.

Для чего это вообще нужно

Спараметризировать приложение — это не такая уж грандиозная задача, а вот попытаться понять взаимосвязь эффективности работы приложения со стоимостными параметрами такой работы — это уже сложнее. Тут вам пригодится своеобразное «боковое зрение».

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

Есть желание добавить в Synology Download Station возможность искать по 613 торрент трекерам? Хочется видеть, какие именно торренты будут загружены? Хочется чтобы оно работало и в мобильном приложении?