Pull to refresh

Comments 17

Вы придумали бинарные логи? Или мы не так поняли?
Спасибо за предположение, но не совсем.

Наверное, надо сказать о природе тех данных, которые попадают в хранилище посредством ETL. Это данные из нескольких типов источников:
— логи с веб серверов
— онтология и описание рекламных компаний
— данные с внешних источников

Все эти типы источников мультиплексируются по-разному, чтобы получить одинаковый слепок данных в нескольких независимых экзмеплярах системы. Фактически, мы вынесли проблему масштабируемости и резервирования вне базы данных. Это универсальный подход.
Я подумал, что и правда, можно назвать наш поход multipath io, только более точно будет сказать multipath DWH. Спасибо за идею.
Есть целый класс железа и протоколов для multipath io, поэтому если вы хотите эксплуатировать это название и хотите, чтобы вас понимали, то советую ознакомиться (если уже не сделали) с этой нишей.

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

Другой слабый момент это контроль целостности. Например, главное отличие зеркального raid от multipath именно в наличие алгоритмов контроля целостности. Для контроля целостности и идентичности мало того, чтобы одинаковые данные поступали на вход, в процессе хранения с ними могут происходить неприятные вещи. Работа с бд обычно характеризуется слабой загруженностью процессора и высокой нагрузкой на каналы передачи данных (сеть, оптоволокно, дисковые системы и т.д.), в этом случае свободные ресурсы процессора можно было бы направить на фоновый подсчет всяких md5 и битов четности, которые периодически сравнивать на разных серверах, не нагружая каналы передачи данных. Какие у вас есть средства для мониторинга целостности данных?

Ну и собственно про решение основных проблем вы ничего и не сказали:

1. как получить зеркало/копию/бекап уже работающей базы, или это возможно только если копия включена в самом начале?

2. как синхронизировать данные в двух базах, если у одной из них был длительный/короткий тайммаут?

И раз уж я потратил время на написание этого комментария, то хотелось бы все-таки понять, что конкретно вы получили в итоге?

У вас есть данные: логи вебсерверов, логи информации о РК, доп. данные, эти данные поступают непрерывным потоком.

а. какова пиковая мощность этого потока в гбит/cек?

б. в итоге вы получаете одинаковые записи в бд на всех серверах (группах серверов)?

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

г. где узкое место у железа, которое это все обслуживает?
О, спасибо за пространный комментарий с хорошими вопросами. Попробую ответить.

Название Вы предложили, не я. Мы это называем мультиплексированием.

Потеря производительности есть в том случае, когда звенья связаны и работают синхронно. У нас звенья развязаны и работают асинхронно.

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

Полную копию работающей базы можно получить не возможно, но можно получить ее «клон», достаточный для выполнения задач. Стандартный процесс для этого следующий:
1. Включить новую базу, заполнить ее целиком данными онтологии и описания компаний.
2. скопировать исторические данные (небольшие агрегаты), которые существенны для ее работы.
3. Дать новой базе остояться неделю-две, пока она накопит достаточное количество детализированных данных.

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

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

И отвечая на последнюю серию вопросов:

a) Не могу сказать, не измеряли, в интерфейс влезает. В строках БД сейчас — около миллиарда фактов в день, большинство фактов — больше сотни значимых колонок.
б) да
в) Другой сервер БД означает другие ETL сервера. В записях появится другой server_id, чтобы мы понимали, откуда она пришла
г) узкое место у железа — это всегда диск. У системы в целом — конечная точка, так как там данные сливаются в общую картину и агрегируются. Масштабирование в этой точке похоже на перестройку 5го рейда, то есть недешево. В остальных частях масштабирование линейное добавлением серверов.
Я правильно понял, что:

1. Целостности данных нет (не проверяется, не гарантируется).

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

3. Узким местом является не пропускная способность сети, а дисковая система одного сервера (что-то порядка 8гбит/сек — обычный рейд на 8 не очень шустрых дисков; инкрементная запись в бд близка к пиковому показателю записи на диск).

п.3. выглядит немного странно, неужели у вас каналы в 10 гбит?
1. Проверяется, но не гарантируется.

2. Да, плюс любые исторические данные, которые мы посчитаем нужными. Стандартный минимальный набор — всего несколько гигабайт, перенос которых занимает меньше получаса.

3. Предварительную обработку можно разбросать по разным серверам, тем самым разгрузив сеть и локальные диски. В конечном итоге данные попадают на один DWH-кластер, и перемешиваются там в соответствии с логикой базы данных, а не тем, откуда и как приходят данные.
Не понял вопроса. Мы не используем бинарные логи.
Это все классно и красиво звучит, но о чем статья? О том, что вы «придумали и реализовали механизм клонирования или мультиплексирования»? Так будьте добры, поделитесь секретом, или это просто пиар?
Статья о подходе и собственном опыте. Проблема резервирования больших данных может возникать у многих, и возможно, наш опыт окажется кому-то полезным. Обычные рекомендации — это делать бэкапы или hot-standby через репликацию того или иного рода. Мы же делаем не репликацию базы данных, а репликацию исходных данных, которые попадают в ETL. Это оказывается гораздо проще и эффективнее и дает дополнительные преимущества.
Я рад за вас, что вам получилось реализовать свой механизм, только статья звучит наподобие «все говорят использовать продукт фирмы А, а мы используем продукт фирмы < (свой собственный продукт)». При этом никаких практических данных нет.

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

Я не пишу о продуктах. Я пишу о различных архитектурных или инфраструктурных подходах. Наша компания не делает программные продукты и не предоставляет IT услуги. Мы решаем свое собственные проблемы. И мы для себя решили проблему резервирования хранилища данных таким образом, как я описал, проанализировав стандартные альтернативы и признав их неприемлимыми. Другим это может быть полезна как идея, которая реально работает. Не более того.
Да, возможно я ожидал в статье чего-то большего, нежели просто идея. Но, если суть статьи была в идее, то претензий, конечно, нету. Идея интересная (хоть и очень дорогая как по мне), но было бы еще классно хоть немного узнать о самой реализации…
А в чем, по-Вашему, заключается дороговизна реализации? Я не стал рассказывать о технических аспектах, посчитав их несущественными. В наши дни идеи ценятся дороже. Но если интересно, то вкратце, технически это выглядит следующим образом.

У нас 7 датацентров и порядка 150 серверов, регистрирующих события, связанные с показом рекламы. В день — несколько терабайт сырых логов. В каждом датацентре логи с серверов попадают на специальный мультиплексирующий сервер. Этот сервер «знает» обо всех экземплярах/инстансах хранилища из базы данных конфигурации, а также о ETL серверах, которые обслуживают эти инстансы. Мультиплексирующий сервер «размножает» логи и раскладывает их по ETL серверам так, что на каждый инстанс попадает своя копия, и логи с разных рантайм серверов определенным образом «размазываются» по ETL серверам. Это основная точка «клонирования». Обработка логов детерминирована, то есть одни и те же логи обрабатываются на разных серверах одинаково, даже если они туда попадают в разное время.

Остальные источники данных клонировать проще. Для онтологии и описания кампаний у нас в каждом датацентре стоит одна или несколько read-only реплик с мастер-базы. База не очень большая, и это вполне приемлимо. ETL-сервера читают с этих реплик. Нагрузка небольшая, так как читаются только изменения, и масштабировать легко, если что. Внешние источники попадают на один из серверов, а потом отдельной процедурой разбрасываются по остальным. Объем тут тоже небольшой и несравним с логами.
Вот этого собственно я и ожидал. Спасибо большое.
А дороговизна как по мне — как раз в тех самых нескольких терабайтах дублированных на всех серверах, хотя, при правильной дальнейшей обработке это уже не так существенно. Ну и плюсы этого, которые Вы описали в статье все же имеют значение.
Я рад, что разъяснил возникшее недоразумение. Добавил в конце статьи некоторый контекст проблемы.

Железо и диски сейчас дешевы. Отказ системы стоит гораздо дороже. Нашей целью было сделать максимально простую в администрировании систему, с максимально свободными связями и возможностями восстановления.
Sign up to leave a comment.