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

Компания Seagate объявила о старте поставок жёстких дисков с ёмкостью от 30 ТБ. На данный момент это только начало, основной объём поставок запланирован на конец этого года. Диски разработаны по технологии HAMR, которая и позволяет достичь очень большой ёмкости. Но, скорее всего, это будет нишевый продукт для корпоративного использования, а рынку HDD эта новинка вряд ли поможет.

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

К тому же многим аналитикам привычнее и зачастую нужнее проводить аналитику в электронных таблицах (Excel, Google Sheet) или BI. Да, можно выгружать отчеты из «Метрики» сначала в Excel-файлы. Но на таком полуручном режиме оперативной и эффективной аналитики особо не построишь.

Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data в Лиге Цифровой Экономики. В этой статье я пошагово распишу, как получать данные из «Яндекс.Метрики» в электронные таблицы (Excel, Google Sheet) и BI в автоматическом режиме. 

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

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

По этим причинам мы попробуем вести на Хабре дневник разработки. Может кто-то почерпнёт тут идеи для своих проектов, а мы в свою очередь сумеем раньше прислушаться к мнению аудитории и улучшим свои решения.

После выхода статьи «Топ-5 ошибок потребителей услуг ЦОД» к нам стали поступать просьбы продолжить цикл и рассказать про типовые ошибки проектировщиков и служб эксплуатации ЦОД. Почему бы и нет? Но сразу стоит заметить, что клиентов у ЦОД Linxdatacenter много, поэтому выявить самые распространенные тенденции было несложно, а вот выборка по ошибкам проектировщиков и служб эксплуатации у нас намного меньше хотя бы потому, что взаимодействуем мы с ними намного реже. Однако несколько типичных моментов выделить можно. В этой статье расскажем про ошибки проектировщиков ЦОД, с которыми нам довелось столкнуться.

Друзья мои, программисты и операторы, я бы хотел поговорить о том, как в Linux работает запись файлов.

Раньше я думал, что она устроена определённым образом, и как Джон Леннон, «I’m not the only one». Оказалось, операции записи работают совершенно иначе. То, как они работают, интересно и важно знать.

Позвольте начать с того, как я раньше думал о записи файлов.

Совсем недавно вышло обновление платформы для бизнес-аналитики Дельта BI с решениями, знаковыми для всей отрасли. Учитывая нашу реальность и недоступность глобальных продуктов, обновление ощутимо увеличивает отрыв Дельта BI от ближайших конкурентов на российском рынке. Показываем и рассказываем, почему.

В этой статье я хочу представить мой алгоритм оптимизации суммирования ряда чисел в массиве (на примере контейнера map). 

Итак, дано задание

Есть некая электронная книга, которую одновременно читает неограниченное количество читателей. Нужно сделать так, чтобы любой читатель в любой момент мог проверить, сколько еще читателей читают ту же страницу, что и он. Предложена наивное решение хранить в map<int,int> в качестве ключа номера страниц, в качестве значения- количество прочитавших их пользователей. Конечно, при таком подходе программа медленно работает с большими тестами потому, что количество итераций по контейнеру map равняется числу прочитанных пользователем страниц. То есть, если пользователь прочел 1000 страниц из 1000 возможных, то в цикле нужно будет сделать 1000 итераций, и это сильно замедляет программу.  

Чтобы уменьшить время работы программы, нужно упростить алгоритм подсчета пользователей. В этом алгоритме я отдельно считаю, сколько пользователей прочли столько же полных сотен страниц, как и искомый читатель, и затем уже постранично суммирую всех, кто прочел столько же страниц из той сотни, на которой сейчас находится читатель. Такой алгоритм позволяет вместо 999 итераций (если пользователь читает 999-ю страницу) сделать всего 108 (9 итераций сотням и 99 по единичным страницам). 

 Это вкратце, теперь перейдем к подробному описанию и для начала приведу код.

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

Читайте, что именно мы сделали и какой был результат.

Начинаем цикл статей об архитектуре аналитических платформ. Поговорим об общем устройстве и подробнее остановимся на анатомии ETL на примере Modus. Вы узнаете, из каких компонентов состоит аналитическая система, откуда она получает и как работает с данными, и что мы в Modus делаем такого, чтобы оптимизировать эти процессы.

Один из моих знакомых недавно сходил на собеседование, на котором его попросили спроектировать укорачиватель ссылок. Он растерялся и задачу — как хотел интервьюер — не осилил, а потом нашел в интернете популярное решение и попросил меня прокомментировать. Полная формулировка поставленной проблемы: «Как бы вы разработали службу сокращения URL-адресов, подобную TinyURL?»

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

В последнее время в работе часто сталкиваюсь с вопросом про подключение FineBI V6.0 к ClickHouse - столбцовой системе управления базами данных (СУБД) для онлайн обработки аналитических запросов (OLAP). Ловите пошаговую инструкцию.

Привет, Хабр! С вами Андрей Чернов — Java-архитектор микросервисов в СберТехе.

Это третья часть материала про то, как мы развиваем Platform V SessionsData — высокопроизводительное распределённое in-memory хранилище для общего контекста сессионных запросов key-value. В первой части я рассказал, почему мы решили создать собственный микросервис, а во второй — как нам удаётся достигать высокой доступности сервиса. Сегодня поговорим о том, какие наработки помогут нам и дальше развивать Platform V SessionsData.

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

DragonflyDB - молодая in-memory база данных, написанная на C++ и совместимая с Redis (не форк). Под капотом используется многопоточная архитектура (в отличии от однопоточного Redis) для лучшей утилизации современных процессоров и более простого вертикального масштабирования.

Особое внимание в DragonflyDB привлекает устройство кеша и его очистки, которая должна превосходить известные LRU и LFU политики.

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

Но рост объема хранимых данных — не единственный возможный выигрыш от применения сжатия, поэтому мы задумались о разработке собственного решения.

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

Мониторинг 

Продолжаем разговор о том, что в NiFi делать можно и нужно, а что можно, но лучше не стоит. Если вы пропустили первую часть разговора, то вам сюда. Там про улучшение читаемости схем и повышение производительности (ну почти). Здесь же пойдет речь о том, как проводить мониторинг бизнес-части схемы, чтобы всем было хорошо (ну или чтобы не было плохо), ну и немного о переносимости процессоров. Поехали!

Есть мнение, что хуже всего — не вести мониторинг бизнес-части схемы совсем, используя популярный подход «и так сойдет!». Но если подумать, есть одна вещь хуже отсутствия мониторинга — неправильный мониторинг.

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

В данной статье мы собрали список вопросов, на которые обязательно нужно обращать внимание при размещении оборудования в ЦОД.

Мечтал ли я когда-либо ворочать миллиардами? Честно признаюсь, да. И нельзя сказать, что Вселенная меня не услышала. Вот только я никак не имел в виду миллиарды записей в базе данных...

Ранее я уже писал о нашем опыте использования ScyllaDB в качестве архивного хранилища. Разумеется, исследования и открытия, связанные с новой базой данных, для нас на этом не закончились... Создавая архив для данных, вероятность обращения к которым близка к нулю, мы, конечно, допускали, что время от времени клиенты будут просить вернуть данные обратно в оперативное хранилище. Но запрос на извлечение из архива сразу всех записей стал для нас неожиданностью. Хорошо ещё, что клиента интересовал только ключ записи, а не вся запись целиком. Тем не менее достать 10 млрд. ключей из ScyllaDB за приемлемое время звучало как челлендж. Ну надо так надо.