Как мы загружаем данные в "Центр управления кассами Магнита"

08.05.20

Интеграция - Внешние источники данных

Статья о том, как мы делали механизм загрузки больших объемов данных в "Центр управления кассами Магнита"

 

 

 

Введение ^

 

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

 

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

 

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

 

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

 

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

  • Стабильными. Минимум «падений», никаких потерь.

  • Удобными. Чем «юзабельнее» инструменты, тем легче с ними работать.

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

  • Оптимальными. Нужен баланс между скоростью доставки данных и комфортной работой пользователей в базе.

  • Логируемые. Что, когда и почему не загрузилось? Ответы нужно найти вчера.

  • Настраиваемыми. Ситуации бывают разные и иногда нужно запустить инструмент с особыми параметрами выполнения.

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

 

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

 

«В начале была архитектура» ^

 

«Центр управления кассами» (или сокращённо ЦУК) — это конфигурация собственной разработки компании с внедрёнными подсистемами БСП (на данный момент 3.0.1.293).

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

 

Функционально в базе каждый пользователь должен работать только с данными своей «Организации». Ему не нужно и не положено видеть чужие.

Однако, есть особые люди, которые должны видеть все данные, собирать сводные отчеты и вообще работать в базе без подобных ограничений.

 

Что мы сделали — разделили загружаемые документы на «области данных».

 

 

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

 

 

А что это даёт нашим загрузкам? Позволяет добиться как можно большего распараллеливания, о чем подробнее будет сказано далее.

 

 

«Из чего всё состоит?» ^

 

Что вообще у нас происходит? Есть источник данных — специальная система, которая в момент обращения наполняет свои таблицы свежей порцией записей. В ней находятся колонки «примитивных» типов: строки, числа, даты.

 

Как происходит обращение из 1С? В самом низу окна конфигуратора есть объект метаданных, который, хоть и нечасто используется 1Сники, но очень подходит для нашей задачи. ВнешнийИсточникДанных. Каждая таблица внешней системы добавляется в ЦУК, прописываются её колонки и методы, а дальше платформа позволяет работать с ними в коде и запросах.

 

 

Задача наших инструментов загрузки — регламентно выбирать эти записи, стыковать с данными ЦУКа и создавать документы. При этом в момент стыковки проводить как можно больше проверок корректности заполнения и выявлять ошибки на всех этапах.

 

 

Что же делать с ошибками? ^

 

Ошибки могут случаться совершенно разные:

 

  • ошибки стыковки: не определено нужное подразделение, найдено несколько контрагентов и т.д.

  • ошибки проверок: документ в закрытом периоде, не заполнен обязательный реквизит, указана неверная аналитика и т.п.

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

 

Чем больше данных, тем больше возможно ошибок. И все они без потерь должны быть в результате доставлены в ЦУК не блокируя работу ни самих загрузок, ни пользователей. Было решено сделать просто — хранить все непрогруженные данные в своих регистрах. Из которых механизм загрузки должен уметь создавать документы по той же логике, что и при загрузке из основного источника.

 

 

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

 

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

 

 

Инструменты работы с ошибками ^

 

Как помним, ошибки бывают разные. Есть те, которые случились из-за неудачного стечения обстоятельств. Они попадут в регистр и будут прогружены позднее автоматически. Есть те, которые также были временными. Например, приехал документ с аналитикой, которая ещё не закодирована в базе. Такое иногда случается. Но ничего страшного, ведь, как только в ЦУК появятся нужные элементы, следующий цикл прогрузки ошибочных записей сделает своё дело.

 

 

Но случаются и более сложные ситуации. Например, почему-то к нам приехали данные, которых вообще не должно было быть. Как же нам потом анализировать и обрабатывать накопленные ошибки? Нужен отчет!

 

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

 

 

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

 

 

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

 

Обработки загрузки данных ^

 

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

 

У каждого вида есть своя обработка. Каждую обработку можно запустить:

  1. Интерактивно (администратором или ответственным пользователем)
  2. Регламентно (по заданному расписанию)
  3. Программно (из других инструментов)
  4. Извне (внешним соединением)

 

Загружать данные можно из:

 

  1. Внешнего источника (основной режим запуска)

  2. Ошибочных записей (выборка из нашего регистра)

  3. Файл или каталог с файлами

 

Каждая обработка содержит в себе:

  1. Настройки выборки и хранения данных

  2. Логика стыковки

  3. Проверка корректности

  4. Заполнение документа

  5. Прочие технические настройки

 

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

 

Общий механизм ^

 

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

 

 

Общий модуль:

 

  • Содержит в себе основную логику выполнения

  • Получает на вход уточняющие параметры и обработку загрузки

  • Выполняет все необходимые действия, согласно параметрам выполнения

  • Вызывает события из обработки загрузки

  • Пишет лог выполнения в регистр на каждом этапе

 

Логирование ^

 

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

 

 

 

Схема взаимодействия инструментов ^

 

Итак, сейчас у нас для каждой загрузки есть:

 

  • Таблица в внешнем источнике данных

  • Обработка загрузки

  • Регистр ошибочных записей

  • Отчет по ошибочным записям

  • Возможно наличие выборочной загрузки ошибок

     

Также имеются общие для всех загрузок объекты:

 

  • Общий модуль механизма

  • Регистр сведений логирования

 

Вот так в результате выглядит их взаимодействие:

 

 

  1. Пользователь работает с отчетом по ошибкам и выборочной загрузкой ошибок.

  2. Пользовательские инструменты обращаются в соответствующую обработку загрузки

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

  4. Администратор также может запускать непосредственно обработку загрузки. Например, иногда внепланово нужно пролить данные из другой таблицы внешнего источника с особыми отборами. Тогда администратор настраивает нужным образом обработку и выполняет её.

  5. Обработка загрузки сама ничего не делает — она передаёт себя в общий модуль.

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

 

Как это работает? ^

Как же происходит загрузка данных?

 

 

Общий модуль выполняет этапы:

 

  1. Выборка данных источника

  2. Стыковка с данными нашей базы

  3. Определение и запись ошибок

  4. Многопоточная прогрузка данных фоновыми заданиями

  5. Сбор всех данных и анализ результата

 

 

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

 

Далее используется специальный запрос, внутри которого происходит стыковка всей информации с базой ЦУК. Также в рамках этого запроса и происходят проверки на ошибки. По содержашим ошибки записям ставится флаг «ЕстьОшибки» и заполняется «ОписаниеОшибок».

 

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

 

Распараллеливание ^

Самый долгий процесс — запись данных в базу. Этот этап нужно было максимально ускорить. И тут нам на помощь пришёл наш общий реквизит «РазделительУчета», о котором говорилось в самом начале.

 

Как происходит распараллеливание:

  1. Все данные разбиваются на порции по разделителям учета.

  2. На каждую порцию запускается своё фоновое задание с включенным разделением данных (ФоновоеЗадание.РазделениеДанных)

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

  4. Родительский сеанс в это время опрашивает свои ФЗ, собирает и обрабатывает по ним результаты выполнения. Если вдруг какое-то задание не выполнилось (упало, отменено), то вся порция данных этого задания помещается в регистр ошибочных записей с соответствующей ошибкой. Это позволяет нам быть уверенными, что все данные из источника попадут в нашу базу.

 

Эта стандартная картина может усложняться. Например, в пики больших объемов, каждое дочернее фоновое задание может порождать ещё потоки. В результате, на один РазделительУчета могут трудиться уже не одно, а несколько фоновых заданий по проведению документов. Например, таким образом, чтобы количество записей в каждом потоке было усреднено. В таком случае берётся общее число записей в каждом основном потоке, определяется среднее число на каждый дополнительный поток и распределяются равномерно загружаемые строки.

 

 

В результате грамотного распараллеливания скорость загрузки данных заметно увеличивается. В зависимости от типа документов, некоторые загрузки добавляют в базу больше 50 тысяч документов за 2 минуты. Некоторые, 1.5 миллиона документов за час. Такие показатели вполне удовлетворяют потоку компании.

А что под капотом? ^

Теперь, когда ясна архитектура и само взаимодействие между объектами, можно рассказать об устройстве внутри них.

 

Центром является общий модуль. Он принимает в себя обработку с параметрами. Структура параметров — это, можно сказать, одна основная переменная, содержащая в себе большое количество свойств и подсвойств.

 

  • Основные (обязательные) настройки. Обработка загрузки, Регистр ошибок, таблица внешнего источника и так далее.

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

  • Настройки логики. Например, таймаут одного ожидания фоновых заданий или стоит ли дополнительно записывать файл данных в каталог.

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

  • Выполняемые шаги и события. Это «ПередПолучениемДанных», «ПередСтыковкойДанных», «ПередЗапускомФоновогоЗадания», «ПередДобавлениемСообщения». Как раз при помощи этого разработчик конкретной обработки загрузки может оперировать данными и в нужный момент времени либо обработать их по своему, либо полностью отказаться от выполнения текущего шага.

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

 

 

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

 

Выводы ^

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

 

Понравилась статья?

Покажите это автору своим "плюсом" и комментариями =) 

 

 

См. также

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9156    9    8    

10

Перенос данных из Парус 8 в ЗГУ 3

Зарплата Внешние источники данных Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    22350    18    1    

21

Автоматическая многопоточная выгрузка данных 1С 8.3 в БД Clickhouse и MS SQL (для работы с данными 1С в BI-системах)

Внешние источники данных Платформа 1С v8.3 Управляемые формы Анализ и прогнозирование Конфигурации 1cv8 Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)

Готовое решение для автоматизированной выгрузки данных из 1С 8.3, а также MS Excel в базу данных ClickHouse, а также в Microsoft SQL для работы с данными 1С в Yandex Datalens, Visiology, Apache Superset (и не только) - "Экстрактор данных 1С в BI". Решение отлично работает со всеми типовыми (и не только) конфигурациями 1С 8.3 для управляемых форм. Gозволяет автоматизировать работу бизнес-аналитика по ежедневной выгрузке данных из 1С в БД ClickHouse для последующей работы с этой БД в Yandex Datalens/ Система полностью автоматизирует работу с хранилищем данных в БД Clickhouse/MS SQL. Не надо быть программистом, чтобы одной кнопкой получать любые данные из 1С в Вашей BI-системе

230000 руб.

15.11.2022    12913    12    47    

28

Перенос данных из Парус 7.хх в ЗГУ ред.3

Внешние источники данных Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 7.хх учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

24000 руб.

24.04.2017    48629    96    159    

86

Перенос начальных остатков из Парус 7.71 в БГУ

Внешние источники данных Взаиморасчеты Учет ОС и НМА Логистика, склад и ТМЦ Бюджетный учет Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 2.0 1С:Бухгалтерия государственного учреждения Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Перенос словарей и начальных остатков из ПП Парус-Бухгалтерия Бюджет 7.71 в 1Сv8 БГУ2. Заполнение словарей и документов по вводу начальных остатков. Не требуется установка ПП Парус7. Возможна дозагрузка. Позволит автоматически и наиболее полно ввести данные в программу для начала работы. 

15600 руб.

08.12.2011    81471    128    123    

146

Перенос данных из Парус 10 (Торнадо) в ЗГУ ред.3 через Excel

Внешние источники данных Загрузка и выгрузка в Excel Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате из Парус 10(Торнадо) учреждений через файлы Excel в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ). В принципе, обработка может быть использована для загрузки из файлов Excel, полученных из любых информационных систем.

24000 руб.

16.11.2018    29980    20    31    

21
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. DitriX 2091 09.05.20 15:57 Сейчас в теме
Не хватает цифр.
Какой объем данных переноситься, как вы переносите такие регистры, как сегменты, у которых нет регистраторов и т.д.
Как вы переносите цены, когда в документе их может быть десятки тысяч.

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

Какие оптимизации вы проводите? Например, мы когда выгружаем цены на кассы, мы смотрим - какие характеристики есть и какие на них цены, если цены одинаковые, то на кассу уходит просто цена за артикул, если на 50% или более есть одинаковыя цена, то выгружаем отдельно артикул-цена и отдельно - характеристика-цена на те, которые отличаются от артикула.
У нас это привело к знатным оптимизациям, так как в нашем кейсе - мы смогли ускориться до 60-70% на обмене и значительно уменьшить объем данных.
Вот такие тонкости интетесны.

А так, имхо - статья ни о чем :)
Нет результата, какие проблемы вы решили, а главное - какие не смогли решить?
И какие результаты получили? На сколько ускорились/снизили нагрузку/повысили стабильность?
sinichenko_alex; evn-zorin; KUAvanesov; keln; Yakud3a; Yashazz; maksa2005; maxopik2; karpik666; johnnyshut23; +10 Ответить
2. SeiOkami 3418 09.05.20 16:24 Сейчас в теме
(1) о каких вообще ценах и характеристиках идёт речь? Боюсь, вы пытаетесь в нашей статье найти оптимизацию каких-то своих процессов.
Ну и на большинство ваших вопросов ответы есть в самой публикации. Цифры, проблемы, решения. Разве что какой-нибудь график не нарисован.
alx1c; AlexBober78; fredly_nightly; cuztam; +4 Ответить
4. DitriX 2091 09.05.20 17:36 Сейчас в теме
(2) ну значит статья для неких высококвалифицированных специалистов. К коим я, судя по всему, не отношусь.
Ибо тут не сказано ровным счетом ничего, из того, что мог бы кто-то взять на вооружение.
Где тут указаны цифры?
В зависимости от типа документов, некоторые загрузки добавляют в базу больше 50 тысяч документов за 2 минуты. Некоторые, 1.5 миллиона документов за час.

Вот это? Они создают 1.5 миллиона документов с десятком сысяц строк в таблице и 10 таблицами на 20 колонок в каждой?
Или это 1.5 миллиона документов вообще без табличных частей и проводок по регистрам?

И все остальное в таком же духе.
Если вам этой информации достаточно, чтобы принять решение, и перенять некие механизмы (хотя я хз как это сделать из статьи), где даже не указан транспорт, ибо внешним осточником может быть эластик, а может быть эксель файл, то тогда я рад за вас :)
Yakud3a; Brawler; johnnyshut23; +3 Ответить
6. AlexBober78 09.05.20 17:48 Сейчас в теме
(4)
ибо внешним осточником может быть эластик, а может быть эксель файл

такое чувство, что вы вообще статью не читали...
не важно, что является источником. Здесь же речь именно о загрузке. Хоть с файла, хоть с другой базы.
alx1c; SeiOkami; fredly_nightly; +3 Ответить
3. fredly_nightly 09.05.20 16:46 Сейчас в теме
(1) "Вот такие тонкости интетесны."
Как раз тут куча тонкостей, которые касаются не конкретной узкой задачи, а самого подхода к загрузки в целом. С примерами, которые можно брать на вооружение для своих нужд.
Такая информация более полезна, чем графики с "А вот у нас в компании удалось на 40% уменьшить потребление туалетной бумаги. А у вас?".
Это всё, конечно, очень интересно, но толк есть только для сотрудников конкретно этой хвастающейся компании.

Статья классная. Хотелось бы поглядеть сам модуль. Сколько на нём вообще инструментов загрузок базируется?
Yakud3a; alx1c; SeiOkami; AlexBober78; +4 Ответить
5. DitriX 2091 09.05.20 17:39 Сейчас в теме
(3) Ахаха, статья класная, только вот самое важное из нее так раз и упущено, про что вы сами и написали. Т.е. из статьи ничего не понятно о том, на какие нагрузки она предназначена и как быстро справляется с ними.
Если бы они написали, что они делают обмен между 500 кассами раз в неделю, и загрузка длится три дня - вам было бы интересно, в этом случае,вообще смотреть на эти модули?
sinichenko_alex; Yakud3a; maxopik2; johnnyshut23; +4 Ответить
7. AlexBober78 09.05.20 18:02 Сейчас в теме
(5) непонятно, чего вы хотите. Описан механизм со всем его подходом. Вполне ясно, что при помощи регистра можно сохранять все ошибки, обрабатывать их. И про лог всё ясно. И про распараллеливание. И что вся разработка базируется на одном модуле с единым функционалом. И что отчет по ошибкам строится тем же инструментом, что и грузится. Вся суть ясна. Не хватает деталей внутренностей именно этого модуля, но это лишь детали.

Но вам нужны какие-то абстрактные цифры, которые не имеют никакого смысла в отрыве от всего остального.
Они зависят от кучи факторов. Архитектура базы, количество данных в документах\справочниках\регистрах, селективность этих данных. Железо, сервер, количество баз на этом сервере, количество пользователей, время запуска. Сложность стыковки, обработки. Без знания всего этого цифры не имеют никакого смысла. Зачем вам вообще это?

Если автор напишет, что "скорость увеличилась на 100500%", вам станет лучше?
BomjBandit; starik-2005; alx1c; SeiOkami; fredly_nightly; +5 1 Ответить
8. kida1 146 11.05.20 13:53 Сейчас в теме
chernenko_vv, Можете ли подсчитать сколько времени у вас ушло на изучение проблемы, постановку задачи, и собственно реализацию? и сколько человек над этим работали? С учетом конечно того, что задача созревала не один день, но все же примерно оцените по времени.
16. SeiOkami 3418 12.05.20 14:12 Сейчас в теме
(8) работа происходила примерно так (специальности называю примерно)
Двое человек занимались тех.анализом, разработкой, тех. тестированием
После два человека на функциональном тестировании (каждый отвечает за свою функ.область)
По времени не скажу - нужно поднимать архивы почты. Разработка велась несколько лет назад. Если найду данные, то напишу.
9. Bronislav 12.05.20 06:30 Сейчас в теме
А какой временной лаг от появления чека на кассе до попадания в "Центр управления кассами"?
10. RustIG 1301 12.05.20 09:05 Сейчас в теме
(0) спасибо за статью. полезно.
11. Yakud3a 12.05.20 09:22 Сейчас в теме
Резюме статьи, для загрузки/выгрузки мы используем 1с, в 1с разделитель учёта и работу в разных потоках! Как выше написал DitriX, ценность статьи нулевая! Никак не хотелось бы обидеть автора статьи, но видя что автор работает в Магните, где тысячи магазинов, то хотелось бы увидеть больше подробностей, используемых технологий/механизмов чем вот читать подобную воду...
12. Unknown31 12.05.20 13:32 Сейчас в теме
Не уловил пользы разделителя данных. Что изменилось в плане производительности от использования измерения Организации и распараллеливания по ней (+ отключение эскалации блокировок на требуемых таблицах)
13. SeiOkami 3418 12.05.20 13:42 Сейчас в теме
(12)

· разделитель учета добавляется в самое начало таблицы и индексов.
· при выполнении запросов (например, при проведении документа) все данные автоматически выбираются с отбором по индексируюемому полю разделителя.
· физически, на SQL все данные по разным разделителям учета максимально разнесены друг от друга (на разных "страницах"). это даёт скорость в выполнении запросов и записей
· так же и все таблицы остатков\оборотов регистров "разбиты" на области данных. запросы по виртуальным таблицам идут быстрее

Это то, что сразу вспомнил
14. Unknown31 12.05.20 13:50 Сейчас в теме
(13) Если Измерение Организация будет первым в соответствующих индексах будет тоже самое.
Решение жизнеспособное, но выгода все равно не очевидна. Но если пользователю потребуется доступ к нескольким организациям - не всем будут проблемы.
Простой RLS по организации не мешал бы производительности в таких условиях.

Изначально Разделитель позиционируется для работы в модели сервиса.
15. SeiOkami 3418 12.05.20 13:56 Сейчас в теме
(14) обычным индексированием поля вы не добьётесь добавления поля первым во все индексы (как и вообще добавления во все индексы).

По этому поводу советую подробнее почитать про разделение данных общими реквизитами (так, как это делают в модели сервиса БСП).
17. 3vs 12.05.20 19:46 Сейчас в теме
Как мы загружаем данные в "Центр управления кассами Магнита"

Похоже, отзагружались.

Новые ИТ-шники в «Магните»
Российская компания-ритейлер «Магнит» сообщила о привлечении новой команды для ускорения цифровой трансформации бизнеса. В ее главе находится один из основателей Lamoda Флориан Янсен, который займет должность исполнительного директора «Магнита», а также станет одним из трех заместителей генерального директора организации — Яна Дюннинга.

Вместе с ним в «Магнит» приходит команда бывших топ-менеджеров компании Lamoda: директор по трансформации Пол Роговски, директор по аналитике и управлению данными Фабиан Шефер, директор по информационным технологиям Валентин Щитов, а также директор по инновационному развитию и партнерству Павел Орлов. Заявления об их уходе от прошлого работодателя прозвучали в первых числах мая 2020 г. — без указания конкретных причин.

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

«Флориан Янсен, Пол Роговски и Фабиан Шефер приступят к работе до конца мая, как только получат разрешения на работу, Павел Орлов и Валентин Щитов уже приступили», — рассказали CNews представители «Магнита».

Цифровая трансформация в организации стартовала в начале 2020 г. Она затронет более 20 тыс. торговых точек «Магнита» и около 300 тыс. его сотрудников по всей стране. Основная часть информационных систем будет развернута в российском ЦОДе SAP на базе SAP HANA Enterprise Cloud.

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

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

Сфера ответственности
В сферу ответственности Флориана Янсена как исполнительного директора войдут офис цифровой трансформации, проектный офис, ИТ и новые технологии, продвинутая аналитика и большие данные, маркетинг, в том числе цифровые продукты, лояльность и CRM, а также омниканальные сервисы, отмечается в сообщении «Магнита».

«Консолидация управления функциями, которые лежат в основе любого современного ритейлера, в руках Флориана Янсена позволит “Магниту” пройти цифровую трансформацию максимально эффективно и контролируемо», — полагают его новые работодатели.
Показать


Источник:
www.cnews.ru/news/top/2020-05-12_magnit_peremanil_iz_lamoda
zqzq; Синицын; KUAvanesov; +3 Ответить
18. Yashazz 4707 12.05.20 22:33 Сейчас в теме
Совершенно пустопорожний набор красивых слов и картинок. Просто ни о чём. Всё о разделителях учёта (общих реквизитах и не только), о правильной архитектуре, взаимодействии с внешними ИБ, о фоновых заданиях итд - уже расписано и рассказано в множестве полезных толковых статей. А тут - "вот, мы сделали и это было круто" - ничего конкретного, и никаких оригинальных красивых ходов. Вдумайтесь - под предложенные автором схемы легко подходит более половины функционала типовых конфигураций и БСП. Это просто ни о чём.

Я неоднократно писал высоконагруженные системы, обладавшие всеми вышеперечисленными атрибутами, как само собой разумеющееся, и мне странно, что для кого-то (именующего себя архитектором и ведущим разрабом) это открытие и находка. Имхо, эта публикация - набор общих слов и банальностей. Эдакое "2х2=4" с эффектным оформлением.

В надежде найти хоть какую-то изюминку внимательно прочитал всю статью. Увы, пустой трёп.
19. fredly_nightly 13.05.20 12:52 Сейчас в теме
(18) заметил, что вы любите заходить в публикации и писать "баян", "ни о чём".
И самому выкладывать очередной жевано-пережеваный аккордеон [:]/\/\/\/\[:]
20. Yashazz 4707 13.05.20 15:36 Сейчас в теме
(19) Люблю, да, особенно когда оно и есть баян.
А вот где (не считая позорища про таблицы значений и СКД), где я-то баяны выкладывал? А если выкладывал, то сам не писал это прямым текстом? А? Примеры в студию, можно в личку)
21. alx1c 13.05.20 20:59 Сейчас в теме
(18)
Я неоднократно писал высоконагруженные системы

Ну так поделитесь вашим опытом написания таких систем, а то в ваших статьях ничего подобного я не нашел
22. Yashazz 4707 14.05.20 10:55 Сейчас в теме
(21) Верно. Я публикую мелкую ерунду, которую имею возможность опубликовать. Ошмётки, так сказать. На большее у меня нет или сил, или времени, или разрешения. Вы же не думаете, что я стану здесь в открытую писать механику сжатия данных, применённую для оптимизации обмена сообщениями в одной госсистеме, которую курировал лично министр? Или что расскажу способы быстрого поиска в некоей системе "одного окна" с лагом не более 3-5 минут, которую делал для другой госконторы по закрытому и не очень честному тендеру?

Некоторые фрагменты я, кстати, публикую. Точнее, обобщённые решения по некоторым инструментам.

или вот есть у меня гордость, отличная "скользящая" база-прокладка между сайтом и бэк-офисной здоровенной УХ, основанная на каскаде асинхронных действий. Хотел бы рассказать, но... больше хочется спокойно спать ночью)
23. Yashazz 4707 14.05.20 11:09 Сейчас в теме
А насчёт высоконагруженных систем, исходя из своего опыта, могу сказать в первую очередь (и это будет в поддержку автору статьи) вот что: никакие стендовые испытания, с хитроумными замерами и всякими изысками, никогда себя не оправдывали. И никакие сценарные тестирования тоже. С завидной регулярностью повторялась ситуация трогательного несовпадения кейсов, предложенных методистами и тестировщиками, с реальностью живой эксплуатации. На стендах всё летало, а потом, при вроде бы тех же процессах, той же параллельности и производительности, всплывали совершенно экзотические узкие места. Иногда такие, что хвалёный ЦУП их найти не помогал. Поэтому скажу: практика - критерий истины. Только рабочая база. Только живая эксплуатация. Только хардкор.
26. alex_sayan 04.07.21 14:24 Сейчас в теме
(23) это не вопрос тестовых стендов, это вопрос квалификации специалистов. Сами по себе инструменты и методики чудес не делают, они максимально полезны только в руках сильных специалистов. Некоторые микроскопом пытаются забивать гвозьди, потом пеняют на микроскоп
24. Cyberhawk 135 18.06.20 08:59 Сейчас в теме
Родительский сеанс в это время опрашивает свои ФЗ, собирает и обрабатывает по ним результаты выполнения. Если вдруг какое-то задание не выполнилось (упало, отменено), то вся порция данных этого задания помещается в регистр ошибочных записей с соответствующей ошибкой
Заложена ли в систему отработка ситуации, когда родительский сеанс упал, а порожденные (и контролируемые им) ФЗ успешно доделали свое дело, но не отчитались об этом?
25. chernenko_vv_2 43 26.06.20 11:44 Сейчас в теме
(24) если родительский сеанс упадёт (например, его срубит администратор), то система, запускающая родительский сеанс, узнает о падении и запишет себе это.

В это время порождённые ФЗ продолжат загружать данные. Информацию мы сможем увидеть в ЖР.

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

Такой подход был выбран с расчётом на то, что для нас важнее быстрее доставить данные и ничего не потерять.
Оставьте свое сообщение