Хабрахабр

Массовая загрузка данных, или Как накормить китайскую деревню

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

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

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

Однако специфика решений имеет некоторые особенности, которые, как оказалось, не очевидны для многих организаций-поставщиков. В своих проектах (немного про работу ЛАНИТ можно почитать тут и тут) мы периодически сталкиваемся с такими задачами и выработали все необходимые решения. К нашему удивлению, мы получали такие запросы и даже претензии:

  • «Мы отправили на загрузку один документ, и он загружался целых 10 секунд. Поэтому если нашей организации нужно будет загрузить 100 тыс. документов, то у нас это займет 100 000*10/3600=277 часов!»
  • «Мы грузим-грузим документы, но в систему ничего не загружается».

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

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

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

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

Источник. Самый крупный торговый центр в мире New Century Global Center в г. Чэнду в Китае. Он имеет 18 этажей и площадь 1 700 000 кв.м.

Компартия Китая поставила задачу обслуживать всех китайцев и всё тут. Что делать гипермаркету? Если недовольных китайцев станет слишком много, не сносить ему своей головушки! Каждый необслуженный китаец – это минус в карму начальника гипермаркета. Если вдруг через год хитрый контроллер принесёт отчет о том, что кассы используются на 1%, то несчастного директора ждет незавидная судьба. При этом, конечно, поставить 150 млн касс руководитель не может. Если рядовой покупатель будет ждать слишком долго (больше минуты), то он с криками «пятисот четире гатеванау тамеаут хана вам всем нафиг» выбежит из гипермаркета и напишет заявление самому товарищу Мао.

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

Источник

Система выдачи билетиков очень простая и работает всегда быстро. Все довольны. Количество касс подбирается таким образом, чтобы:

  • коэффициент использования касс позволил товарищу директору жить долго и счастливо;
  • длина очереди была небольшой и китайцы проводили в ней мало времени (95 процентиль времени ожидания < разумного значения, например, 5 минут);
  • даже если в результате стечения обстоятельств в магазин одновременно пришли бы много покупателей, то время ожидания растянется, но они будут обслужены часов до 23:00 вечера, чтобы они смогли вернуться домой и посмотреть выпуск новостей перед сном.

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

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

Считаем, что разработчики уже оптимизировали все алгоритмы и дальнейшая оптимизация слишком трудоемка или усложняет дальнейшее сопровождение и развитие системы. Качеством проверок мы обычно жертвовать не можем. пример на рисунке 1). На наших проектах время обработки одного запроса, содержащего от одного до пятисот документов (платеж, счет, договор, проект закупки и т.п.), в среднем составляет несколько секунд на бекенде (см. Это время не является константным, а колеблется в некоторых пределах, так как в сложной системе всегда очень много различных факторов, которые могут повлиять на обработку пакета.

Рисунок 1. Типичный график времени обработки пакетов документов. Среднее время в районе трех секунд.

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

Может так случиться, что все 150 млн документов добрые поставщики решат загрузить в систему одновременно. Поэтому на практике в каждый конкретный момент интенсивность загрузки документов бывает очень разной — точно предусмотреть это практически невозможно. А это совсем не одно и то же, как если бы они их загружали строго по расписанию по 5 млн в сутки.

Рисунок 2. Пример распределения количества загруженных документов по суткам за последние полгода.

Понятно, что в среднем загружается примерно 4-5 млн документов в день. На рисунке 2 видно, что число загруженных за сутки документов  колеблется в широких пределах. Максимальное количество загруженных документов за сутки — более 17 млн. При этом в какие-то дни в систему было отправлено более 10 млн документов.

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

Поэтому при проектировании механизмов массовой загрузки мы используем буферизацию запросов с помощью очередей. Очевидно, что в систему одновременно может поступить и два, и три, и десять млн документов. Таким образом мы можем принимать в систему запросы на прием документов с очень большой интенсивностью, ведь операция приема запроса очень простая. Любой запрос от пользователя сначала сохраняется в очереди. Чем больше железа, тем больше «обработчиков», тем больше  запросов одновременно система может обработать. А вот валидация и загрузка документа делается уже специальными «обработчиками», количество которых настраивается в зависимости от имеющихся мощностей.

Нужно найти баланс, чтобы нас (заказчика) устраивал коэффициент использования железа в периоды низкой загрузки, и при этом в пиковые периоды очередь данных на загрузку не росла слишком сильно. Мощность программно-аппаратного комплекса ИС определяется требуемой пропускной способностью и затратами на железо. Если всё чаще случается, что данные не успевают загрузиться за ночь, то это сигнал увеличить пропускную способность за счет добавления железа. С учетом того, что ночью чаще всего мы получаем естественное снижение нагрузки, то можно пользоваться ориентиром — все данные должны загружаться либо в тот же день, либо за ночь.

Рисунок 3. Пример графика изменения длины очереди на загрузку пакетов данных.

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

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

Рисунок 4. Время загрузки пакетов данных. Среднее за период составило 11,92 минуты. Время загрузки включает время ожидания в очереди и время обработки на бекенде.

С другой стороны, если мощности ИС подобраны таким образом, чтобы обрабатывать предполагаемый объем данных в тот же день или максимум за ночь, то поставщику нет смысла  придерживать загрузку данных — нужно просто отправить весь объем документов, и он обработается максимально быстро. Можно сделать вывод: если поставщик отправит пакет данных ночью, время загрузки будет минимальное.

Вернёмся к нашим претензиям. «Мы отправили на загрузку один документ, и он загружался целых 10 секунд. Поэтому, если нашей организации нужно будет загрузить 100 тыс. документов, у нас это займет 100 000 * 10 / 3600 = 277 часов!»

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

Источник

жителей? Что делать, если нужно закупить рис на деревню из 100 тыс. Очевидно, что в этом случае покупка риса на всю деревню растянется на многие часы или сутки, так как придется отстоять очередь последовательно 100 тысяч раз. Не имеет смысла отправлять каждого жителя деревни в гипермаркет друг за другом (следующий выходит только после того, как вернется предыдущий). По сути они отстоят очередь только один раз. С другой стороны, если все жители деревни разом придут в гипермаркет, встанут в очередь все вместе, то они отстоят очередь одновременно. Время их ожидания в очереди будет также существенно зависеть от количества работающих касс.

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

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

Как следствие, синхронные методы не годятся для массовой загрузки — это антипаттерн.

Что больше всего в этой истории волнует  товарища директора? За что его могут наказать.

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

Если система выдачи талончиков в очередь не работает, это совсем плохо. 1. Это прямо настолько плохо, что такие ситуации на следующий день разбираются прямо в кабинете товарища Мао.

Если очередь в гипермаркете увеличивается и покупатели начинают там надолго зависать, то это подозрительно, но не обязательно сразу плохо. 2. За этим надо следить, но бывают две ситуации:

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

3. Если конкретный китаец не может приобрести рис, то это также может быть по разным причинам:

  • если китаец забыл взять деньги, то это не вина товарища директора;
  • если на кассе что-то сломалось или китайца обругала кассирша, то это уже проблема гипермаркета. Если доля таких инцидентов возрастет до определенного уровня, то это станет большой проблемой.

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

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

Количество запросов на загрузку, шт

Доля, %

Полностью успешно загруженные пакеты

125 977 459

79,94%

Пакеты, которые не были полностью или частично загружены в связи с проблемами на стороне поставщика (ФЛК, бизнес-контроль)

29 936 543

19%

Пакеты, которые не были загружены из-за проблемы на стороне ИС

38 805

0,02%

Пакеты-дубликаты

1 638 886

1,04%

Всего

156 812 782

100%

Таблица 1. Статистика по загрузке за июль  2018 года

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

Важно, чтобы был запущен процесс мониторинга ошибок в промышленной среде и анализ причин их возникновения. К сожалению, ошибки ИС могут возникать, особенно, если идет её бурное развитие. Мы на своих проектах в ЛАНИТ используем развитую систему мониторинга интеграционных механизмов, и если видим, что количество ошибок начинает расти, то определяем их источник и стараемся оперативно предпринять корректирующие действия.

В заключение хотелось бы еще раз повторить основные тезисы.

  1. При разработке и развитии государственных или корпоративных ИС возникают задачи массовой загрузки данных. Поток запросов на загрузку в ИС, как правило, имеет случайный характер. Это означает, что мы примерно знаем распределение, но в каждый конкретный момент может прийти и очень мало, и очень много запросов.
  2. Механизмы приема данных для массовой загрузки должны быть построены с использованием очередей. По-другому нельзя и точка. В противном случае мы должны допускать потерю данных, если вдруг придет огромное число данных на загрузку, либо нам нужно использовать очень-очень много железа, которое простаивало бы 99% времени.
  3. Время загрузки данных складывается из времени ожидания в очереди и времени обработки данных. Время обработки пакетов данных на бекенде при адекватных процессах проектирования и разработки – это секунды или миллисекунды. Время ожидания в очереди (минуты) зависит от количества обработчиков, используемых системой. Количество обработчиков определяется мощностью программно-аппаратного комплекса. Больше железа – больше обработчиков, быстрее разбирается очередь. И наоборот.
  4. Синхронные сервисы не применимы для массовой загрузки, поэтому их не рекомендуется использовать.
  5. Если вы поставщик и вам нужно загрузить много данных, отправляйте их все в ИС сразу. Ни в коем случае не стоит отправлять данные последовательно друг за другом (следующий пакет не отправляется, пока не загрузится предыдущий).

Традиционно: у нас есть для вас вакансии!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть