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

Эта статья продолжение статьи HDB++ TANGO Archiving System, в которой рассказывалось об архитектуре и о том как настроить архивацию. Здесь речь пойдет о том как поднять и настроить docker в котором будет работать база архивирования.

«Не СХД, а болид “Формулы-1”», — подумал я, когда увидел анонс нового топового массива от Huawei. А еще со скепсисом: «Посмотрим, как этот суперкар покажет себя на трассе». И вот мне посчастливилось «обкатать» Huawei OceanStor Dorado 18000 V6, нагрузив ее синтетическими и прикладными тестами. Делюсь полученными результатами. Заодно получилось пройти незапланированный квест в поисках параметра, который вначале заметно портил картину производительности на AIX. Итак, под кат.

Всем привет! В недавней статье мы рассказали, как мы шли к построению нашей Data Platform.

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

То есть, если возвращаться к финальной схеме из упомянутой выше статьи (специально дублирую ее ниже, чтобы уважаемым читателям было удобнее), то сегодня мы будем более углубленно говорить о реализации «правой части» схемы — той, что лежит после Apache NiFi.

Уже 7 лет я занимаюсь в DataLine искусством capacity-менеджмента — управляю основными ресурсами дата-центра. Проще говоря, обеспечиваю каждому клиенту необходимое и достаточное место, электричество и холод для решения его задач. Мы уже рассказывали, как ведем статистику по потреблению оборудования и определяем стандартную мощность. Но что насчет самих стоек, которые отвечают за место?

Сегодня проведу небольшой ликбез по серверным стойкам, покажу, что и как мы выбираем для надежной работы оборудования. Список рекомендаций по выбору шкафов будет в последнем разделе, опытные ЦОДоводы могут сразу переключаться на него и предлагать свои дополнения.

Эта статья — итог нашего эфира в Телеграме. Можно заодно послушать запись эфира в Салатовой телеге.     

Привет! Меня зовут Андрей Серебрянский, я дата инженер в Vivid Money. Сегодня я расскажу про то, для каких задач можно применять Kafka Streams и покажу код для наших простых примеров. Это будет полезно тем, кто использует Kafka, но еще не пробовал Kafka Streams. Если вы бы хотели сохранять состояние при обработке Kafka топиков или искали простой синтаксис для обогащения одних топиков информацией из других, то сегодня я покажу, как это можно делать легко и практически из коробки.

Всем привет!

На сегодняшний день данные и всё связанное с ними (ML, AI, DataMining, etc) это самый хайповый тренд в IT-индустрии. Все - от ритейлеров до компаний Илона Маска - работают (или пытаются работать) с данными. Нас в Леруа Мерлен эта волна не обошла стороной - data-driven подход к принятию решений является одним из основных в компании. Следуя ему, мы создали свою платформу данных, которой на данный момент пользуется около 2 тыс.человек, а в минуту обрабатывается примерно 1800 запросов. В этой статье мы (Data-команда Леруа Мерлен Россия) расскажем, как за 2 года построили платформу данных в компании с большим количеством оффлайн-процессов, про ее архитектуру и опыт, который мы получили в процессе создания.

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

Проявления избыточной сложности в хранилищах данных можно перечислять долго. Это таблицы с сотнями полей, SQL-скрипты на тысячи строк, отдельные SQL-скрипты одинакового назначения для разных типов данных, отсутствие необходимой нормализации данных, отсутствие первичных ключей и ограничений целостности, отсутствие необходимых полей начала или окончания срока действия записи, наличие многочисленных и сложных «костылей», перекодировка или реклассификация данных, изменение типа или формата данных, замена идентификаторов, разнобой в наименованиях, излишнее количество слоев информационной системы, «протягивание» полей окольными путями, упаковка и распаковка составных полей, расчет лишних полей и использование лишних связей и условий, дублирование информации в записях и лишняя фильтрация записей, наследование таблиц, отсутствие единых правил заполнения данных.

Основной причиной избыточной сложности является денормализация в витринах данных. Популярное утверждение «денормализируйте, если необходимо повысить производительность» игнорирует проблему избыточной сложности, и поэтому во многих случаях неверно. Впрочем, источник цитаты это признает: «денормализованная база данных под большой нагрузкой может работать медленнее, чем её нормализованный аналог». Нетребовательность к структуре и качеству данных со временем неизбежно приводит к усложнению структуры данных и алгоритмов, ошибкам, замедлению работы информационных систем и раздуванию IT-подразделений.

Но можно значительно упростить доработки и поддержку хранилища данных, если придерживаться описанных далее правил.

Мы продолжаем цикл публикаций о системе хранения Dell EMC PowerStore. Сегодня расскажем о том, как эффективно организовать работу с различными версиями продуктивных данных и их копиями при совместном использовании PowerStore и программного продукта Dell EMC AppSync.

Уверены, каждый хоть раз задумывался о количестве информации, которой мы с вами окружены, о том, с какой колоссальной скоростью она создается. Данные стали самостоятельным ресурсом, ценность которого зачастую гораздо выше физических носителей или устройств обработки. Потеря или неэффективное их использование может оказать негативное, а порой и губительное влияние на работоспособность организаций. Но, безусловно, главной ценностью обладает именно актуальная информация, поэтому важны не только сами данные, но и их копии, и возможность оперативно работать с ними. Это позволяет значительно повысить ценность самой информации.

Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали — писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.

Эта статья является конспектом книги «Designing Data-Intensive Applications».

В предыдущем конспекте мы рассмотрели «грязную» операцию чтения – это разновидность состояния гонки, возникающая при попытке конкурентной записи в одни объекты различными транзакциями. К этой категории проблем также относится ситуация потери обновления.

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

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

В большинстве серверов HPE имеется встроенный контроллер управления Integrated Lights Out (iLO). Его первоначальное назначение – удаленное управление сервером:
включение/выключение, перехват графической консоли, подключение медиа-устройств – что и иллюстрирует название «Lights-Out» – «Свет выключен» – в ЦОД, где трудятся серверы HPE, администратору нет необходимости быть рядом.

Эта статья является конспектом книги «Designing Data-Intensive Applications».

В суровой реальности информационных систем очень многое может пойти не так - программное или аппаратное обеспечение базы данных может отказать в любой момент; в любой момент может произойти фатальный сбой приложения; разрывы сети могут неожиданно отрезать приложение от базы данных или один узел базы от другого; состояния гонки между клиентами могут привести к неожиданным ошибкам.

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

В этом конспекте рассмотрим примеры возможных проблем и изучим алгоритмы, которые используют БД для их предотвращения. Рассмотрим вопрос управления конкурентным доступом, обсудим различные виды возникающих состояний гонки, а также реализацию в базах различных уровней изоляции.

"Размышления без практики приводят к заблуждению, практика без размышления приводит к затруднению."

Мы ведём войну с индивидуальностью у шардов в кластере MongoDB. Это продолжение статьи Шардинг от которого невозможно отказаться, а это значит, что наступила пора конкретики.

Как я и обещал, здесь мы рассмотрим подробнее:

• настройку процесса выравнивания размера шардов
• расчет поправок для коррекции границ
• мониторинг распределения данных в коллекциях

Эта статья является конспектом книги «Designing Data-Intensive Applications».

В этом конспекте рассмотрим, как сохранить полученные от пользователя данные и как найти их снова в случае запроса с точки зрения БД.

Почему разработчика приложений должны волновать внутренние нюансы того, как БД хранит данные и как она их находит? Вряд ли вы собираетесь реализовать собственную подсистему хранения данных с нуля, но вам определенно нужно выбрать из множества существующих подсистему хранения, подходящую именно для вашего приложения. Чтобы настроить его на оптимальную работу при вашей нагрузке, не помешает иметь хотя бы приблизительное представление о том, каковы внутренние механизмы функционирования подсистемы хранения.

Всем привет, меня зовут Максим Крупенин, я работаю Data & Analytics Solution Architect в EPAM Systems. За 4 года работы в EPAM мне пришлось поработать в разных проектах, связанных с BI, Big Data, Data warehouse и другими технологиями. В этой статье поделюсь одним из клиентских проектов, где мы реализовали кастомное решение для near real time-аналитики на базе Snowflake. Надеюсь, статья будет полезной, оставляйте фидбек в комментариях.