27 июня вышел Git 2.37 с новым механизмом очистки файловой системы, её встроенным монитором и другими доработками. Подробности рассказываем к старту курса по Fullstack разработке на Python.

Новый механизм удаления недоступных объектов

Часто мы говорим о классификации объектов как «достижимых» и «недостижимых»: 

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

• если такой ссылки нет, объект «недоступен».

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

В конфигурации Git внимательные читатели заметят параметр gc.pruneExpire. Он определяет «отсрочку»: насколько долго недостаточно устаревшие для полного удаления недоступные объекты остаются в покое. Это делается, чтобы смягчить состояние гонки, когда недостижимый объект, который должен быть удалён, становится доступным любому другому процессу (например, входящему обновлению ссылки или push) до удаления и оставляет репозиторий повреждённым.

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

До Git 2.37 каждый уцелевший недостижимый объект записывался как несвязанный, а mtime отдельных объектов использовалось для хранения их возраста. Это может привести к серьёзным проблемам, когда слишком много новых недостижимых объектов не могут быть удалены.

В Git 2.37 представили cruft packs, позволяющие хранить недоступные объекты в одном пакетном файле, записывая возраст отдельных объектов во вспомогательную таблицу, которая вместе с пакетом хранится в *.mtimes.

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

$ git gc --cruft --prune=1.day.ago

В каталоге $GIT_DIR/objects/pack появится файл .mtimes с возрастом каждого недостижимого объекта за последние сутки:

$ ls -1 .git/objects/pack pack-243103d0f640e0096edb3ef0c842bc5534a9f9a4.idx pack-243103d0f640e0096edb3ef0c842bc5534a9f9a4.mtimes pack-243103d0f640e0096edb3ef0c842bc5534a9f9a4.pack pack-5a827af6f1a793a45c816b05d40dfd4d5f5edf28.idx pack-5a827af6f1a793a45c816b05d40dfd4d5f5edf28.pack

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

[исходники]

Встроенный монитор файловой системы для Windows и macOS

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

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

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

В Git 2.37 Windows и macOS эта функция встроена, а это устраняет необходимость установки внешнего инструмента и настройки хука. Включить функцию можно параметром конфигурации core.fsmonitor.

$ git config core.fsmonitor true

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

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

 [исходники, исходники, исходники, исходники]

К широкому применению готов разреженный индекс

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

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

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

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

В 2.37.0 окончательные интеграции введены в git show, git sparse-checkout и git stash. Из всех интеграций наибольший прирост производительности получил git stash: команда считывает и записывает индексы несколько раз в одном процессе и иногда ускоряется почти на 80% (все подробности — в этом треде).

[исходники, исходники, исходники]

Чтобы узнать больше, ознакомьтесь с примечаниями к версии 2.37 или любой предыдущей версии в репозитории Git.

Интересные факты

Теперь обратимся к не столь важным темам этого релиза.

Говоря о разреженных проверках, в этом релизе мы не рекомендуем использовать стиль определения разреженной проверки non-cone.

git sparse-checkout поддерживает два типа шаблонов, определяющих, какие части вашего репозитория следует извлекать: cone и non-cone, позволяющий указывать отдельные файлы с помощью синтаксиса в стиле .gitignore, может сбивать с толку при правильном использовании и имеет проблемы с производительностью: в худшем случае все шаблоны должны пытаться сопоставляться со всеми файлами. И самое важное: он несовместим с разреженным индексом, который повышает производительность применения разреженного извлечения для всех команд Git, с которыми вы знакомы.

По этим и многим другим причинам стиль шаблонов non-cone устарел в пользу —cone и в будущем релизе будет удалён.

[исходники]

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

У core.fsyncMethod появилась «пакетная обработка», которая в поддерживаемых файловых системах при записи множества отдельных файлов может дать значительное ускорение. Режим работает путём постановки множества обновлений в кеш с обратной записью диска перед выполнением единственного fsync(), заставляющего диск очищать этот кеш. Затем файлы атомарно перемещаются на место, а к моменту попадания в каталог объекта гарантируют fsync-надёжность.

Сейчас этот режим поддерживает только пакетную запись несвязанных объектов и будет включён, только если core.fsync содержит значение loose-objects. В синтетическом тесте добавления 500 файлов в репозиторий с помощью git add (каждый из которых приводит к созданию нового несвязанного объекта) новый режим batch по сравнению с отсутствием fsync вообще накладывает лишь скромный штраф.

В Linux добавление 500 файлов без fsync() занимает 0,06 секунды и 1,88 секунды с fsync() после каждой записи несвязанного объекта и всего 15 секунд с новой пакетной функцией fsync(). Другие платформы показывают аналогичное ускорение, ярким примером является Windows, где цифры составляют 0,35, 11,18 и всего 0,41 секунды соответственно.

[исходники]

Если вы когда-нибудь задавались вопросом: «Что изменилось в моём репозитории со вчерашнего дня?», один из способов выяснить это — параметр —since, который поддерживается всеми стандартными командами просмотра ревизий — log и rev-list и т. д.

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

Предположим, у вас три коммита: C1, C2 и C3, где C2 — родительский для C3, а C1 является родителем C2. Если и C1, и C3 записаны за последний час, но C2 старше одного дня (возможно, из-за отставания часов коммитера), тогда обход с —since=1.hour.ago покажет только C3, ведь просмотр C2 заставляет Git остановить обход.

Если вы ожидаете, что история репозитория несёт некоторый перекос часов, вместо —since можно воспользоваться —since-as-filter, который печатает только коммиты после указанной даты, но не останавливает свой обход, увидев более раннюю дату.

[исходники]

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

Даже в простом примере попытка вспомнить объектный фильтр для клонирования репозитория требует заклинания:

$ git config remote.origin.partialCloneFilter

В Git 2.37 узнать это намного проще, например через git remote -v:

$ git remote -v origin    git@github.com:git/git.git (fetch) [tree:0] origin    git@github.com:git/git.git (push)

Между квадратными скобками легко увидеть, что удалённый original использует фильтр tree:0

Эта работа подготовлена ​​Абхрадипом Чакраборти, студентом Google Summer of Code, одним из трёх студентов, которые присоединились к работе над Git в этом году.

[исходники]

Говоря об удалённой настройке, отметим, что Git 2.37 поставляется с поддержкой предупреждения или выхода при обнаружении учётных данных в виде простого текста, хранящихся в вашей конфигурации с новой настройкой transfer.credentialsInUrl.

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

Этот новый параметр позволяет Git либо игнорировать, либо останавливать выполнение, когда он видит один из элементов этих учётных данных, устанавливая для transfer.credentialsInUrl значение «warn» или “die” соответственно. Значение по умолчанию «allow» ничего не делает.

[исходники, исходники]

Если вы когда-либо использовали git add -p для постепенного добавления содержимого рабочего дерева, то, возможно, знакомы с «интерактивным режимом» git add или git add -i, из которых git add -p не поддерживается.

В дополнение к «patch»  git add -i поддерживает «status», «update», «revert», «add untracked», «patch» и «diff». До недавнего времени режим git add -i фактически был написан на Perl. Эта команда стала последним предметом длительных усилий по портированию команд Git с Perl на C. Это позволяет использовать библиотеки Git без порождения подпроцессов, которые могут быть непомерно дорогими на некоторых платформах.

Повторная реализация команды git add -i на языке С появилась в выпусках Git уже версии 2.25.0. В более поздних версиях эта повторная реализация находилась в режиме «тестирование» по выбору. Git 2.37 поддерживает повторную реализацию на C по умолчанию, поэтому пользователи Windows должны заметить ускорение git add -p.

[исходники, исходники, исходники, исходники, исходники, исходники, исходники]

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

Если вы заинтересованы в том, чтобы внести свой вклад в Git, сейчас, как никогда, интересное время для начала. Ознакомьтесь с этим руководством, чтобы получить несколько советов по началу работы.

Подводная часть айсберга

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

А пока Git развивается, мы поможем прокачать ваши навыки или с самого начала освоить профессию, актуальную в любое время.

• Профессия Fullstack-разработчик на Python

• Профессия Data Scientist

Выбрать другую востребованную профессию.

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

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

На фото — Джек Корнер, куратор отдела палеонтологии в Музее Скалистых гор, показывает масштаб окаменелостей тираннозавра рекса на месте раскопок в Форт-Пек, штат Монтана, в июне 1990 года.

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

Сцена из фильма Парк Юрского периода.

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

К ним относятся:

1. Компьютерная томография
2. 3D-сканирование
3. 3D-моделирование
4. 3D-печать

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

На что способен современный продвинутый компьютерный томограф ?

Для каждого изображения сканер, как правило, делает от 1500 до 1700 рентгеновских снимков. Фотографии делаются по мере вращения образца в рентгеновском луче с уровнем дозы в 100 раз превышающей уровень дозы, используемой на людях. Эти изображения затем используются для создания 3D-модели всего образца — по сути, стопки виртуальных срезов вскрытия, — которыми можно манипулировать, вращать и изучать под любым углом, раскрывая все детали его внутренней структуры.

«Мы можем видеть пространственные детали, недоступные при вскрытии, а некоторые части настолько деликатны, что в противном случае, их можно было бы не заметить»
— доктор Ландман палеонтолог

Затем на основе сканирования палеонтологи могут в цифровом виде реконструировать мозг и внутреннее ухо с помощью специального программного обеспечения.

Pawpawsaurus — панцирный динозавр, чей череп недавно изучали с помощью КТ

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

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

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

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

То, что невозможно расположить в аппарате КТ, сканируют при помощи 3D-сканера. На сегодняшний день существуют оптические и лазерные 3D-сканеры, в разных вариациях. Портативные, ручные, стационарные.

Лазерный сканер Artec 3D, для точного захвата крупных объектов, таких как здания и самолёты. Стоимость такого сканера 6700000р.

Принцип работы лазерных 3D-сканеров — направленный лазерный луч отражается от поверхности предмета, образуя облако точек. Каждая точка имеет свои координаты в пространстве. Программное обеспечение определяет их и создаёт готовую трёхмерную цифровую модель на основе этих данных.

Бюджетный оптический 3D-сканер

А вот принцип работы оптического 3D-сканера отличается от лазерного. Так, процесс оптического сканирования заключается в подсвечивании объектов создаваемым структурированным светом проектора и съёмки отражённого света с определённых ракурсов. Проще говоря, объект засвечивают световой полоской или паттерном – эталонным монохромным рисунком.

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

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

Что делают, чтобы сканы были максимально точны?

• Во-первых, большие объекты, как правило, сканируют методом обхода. Специалист использует ручной сканер и определяет для себя зоны оцифровки объекта. В случае с большим скелетом, поскольку он состоит из множества костей, делают так: 1 зона = 1 кость.

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

На фото команда Artec3d сканирует скелет взрослой особи Тираннозавра рекса.

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

Пример «артефактов» лазерного сканирования

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

Качественный скан Тираннозавра рекса от команды Artec3d

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

Чудесная история о том, как китов сканировали для нужд палеонтологов

«Утром в ноябре 2011 года американский палеонтолог Николас Пиенсон провожал глазами груженные рудой самосвалы, с рёвом проносящиеся по участку Панамериканского шоссе между шахтами в пустыне Атакама и чилийским портовым городом Кальдера. Перед ним расстилался 250-метровый участок песчаника, расчищенный для прокладки новых шоссейных полос. Однако это был, не совсем простой участок.»

Палеонтолог Николас Пиенсон.

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

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

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

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

Сканирование остатков китов.

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

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

Всё это привело к тому, что Смитсоновский институт анонсировал выставку, на которой должен был быть представлен десятиметровый скелет одного из китов, похороненных в Кальдере. Я не нашёл подтверждений тому, состоялась данная выставка, или нет, но сам факт использования 3D-сканирования, которое позволило сократить долговременную работу до срока в менее один месяц, заслуживает восхищения. К слову, помимо скелета на выставке анонсировался показ того, как современные технологии создают науку будущего:

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

Более подробно о данной истории вы можете прочитать здесь. Материал интересный.

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

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

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

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

Скелет самки Тираннозавра рекса, возрастом около 11-ти лет. Довольно известный экспонат, которому дали женское имя «Джейн». После того как её нашли, возникло множество споров касательно видовой принадлежности. Какое-то время подростка Тираннозавра причисляли к Нанотираннусам, так как череп найденной самки был почти идентичен ранее найденному образцу черепа Нанотираннуса, который был обнаружен в 1942г. в формации Хелл-Крик, от этого образца череп «Джейн» отличался лишь наличием травмы, вероятнее всего, полученной в результате схватки с другим Тираннозавром подростком. В результате исследований этих двух черепов палеонтологи подтвердили, что образцы принадлежат к одному и тому же виду. А также в 2005 году в музее Берпи состоялась конференция, на которой обсуждалось, представляют ли собой Нанотираннусы взрослых особей своего вида или же подростковых особей Тираннозавра. Так большинством было принято решение ликвидировать род Нанотираннусов, а всех животных этого рода назвать подростками Тираннозавра. Таким образом, «Джейн» всё же вернулась в родную семью.

Работа над черепом «Джейн» имела ряд проблем. У меня не было скана этого черепа, однако если учитывать что это довольно молодая особь, то решено было поискать сканы черепов Тираннозавров примерно её возраста. А также использовать морфологическое описание, доступные фотографии и палео эскизы черепа «Джейн». Поиски были довольно долгими, однако вот что мне удалось найти.

Скан черепа Нанотираннуса в программе Meshlab. Лично для меня самая удобная программа для просмотра сканов в формате ply, особенно если нужно наложить текстуру на модель:

Первый найденный череп Нанотираннуса (Nanotyrannus lancensis) индекс каталога (CMNH 5741). Обнаружен в 1942г:

Несколько полезных фотографий сканов реконструкции черепа «Джейн»:

Фото снимков всех оригинальных фрагментов черепа «Джейн»(BMRP 2002.4.1)

Череп BMRP 2002.4.1, вид сверху. Центральная линия иллюстрирует деформацию черепа в результате травмы.

По данным отсканированных образцов фоссилий CMNH 5741, а также фотографиям, морфологическому описанию и эскизам черепа BMRP 2002.4.1, мне удалось сделать реконструкцию черепа «Джейн». Опираясь на эти данные, я стал превращать полный скан черепа Нанотираннуса в реконструированную модель черепа Джейн с устранением посмертной травмы. Для этого я конвертировал скан в программе Netfabb из формата ply — в формат obj, там же провёл удаление полигонов породы, которая забила череп. Отделил верхнюю часть черепа от нижней, соответственно, обе половины были с повреждённой сеткой, так как череп был в положении закрытой пасти.

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

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

После редактирования модели в Netfabb — мне нужно было поработать над геометрией черепа, чтобы приблизить её к образцу Джейн. Затем нужно было сделать примитивный скульпт. Выравнивание и наращивание объёма в некоторых местах, очищенного от породы черепа, я сделал в Meshmixer. Удобная, но, к сожалению, ограниченная в своих возможностях программа, особенно для профессиональных 3D-скульпторов. Касаемо зубов и объёма в месте разделения нижней челюсти от верхней, то всё это я тоже сделал в этой же программе.

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

Законченный проект в Zbrush

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

Верхняя и нижняя челюсти. Полностью готовая 3D-модель, реконструкции черепа «Джейн»

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

Печать нижней челюсти Тираннозавра, команды Artec3d

Основные виды 3D-печати

1. Прототипирование методом наплавления (FDM)
2. Селективное лазерное спекание (SLS)
3. Лазерная стереолитография (SLA)
4. Электронно-лучевая плавка (EBM)
5. Производство моделей с использованием ламинирования (LOM)
6. Многоструйное моделирование (MJM)

P.S. Некоторые из этих видов имеют подтипы, например (SLA) делится на такие типы как (LCD), (DLP), (mSLA) и др. Но в целом технология подразумевает построение объекта с помощью отверждения жидкой светочувствительной смолы.

В этой части я вкратце расскажу только о двух самых популярных в мире видах 3D-печати, которые также используются в рамках палеонтологии.

И я так решил по двум причинам.

1. Подробный обзор всех основных видов 3D-печати — это материал равный примерно 6 большим статьям. Так как поверьте материала реально много.
2. Я буду честным с вами в своём опыте, поэтому расскажу вкратце только о тех видах 3D-печати, с которыми работал лично.

Работаю я с технологией FDM и SLA кратко рассмотрим эти технологии.

FDM — самая распространённая технология 3D-печати в мире. С её помощью выращивают изделия как дешёвые домашние принтеры, так и промышленные системы высокоточной 3D-печати. Принцип построения по технологии FDM заключается в послойном выращивании изделия из предварительно расплавленной пластиковой нити.

Профессиональный FDM 3D-принтер, с областью печати 600×600×600мм. Стоимость 1 млн. руб.

На промышленных предприятиях или в сфере крупного бизнеса, как правило, используются промышленные или профессиональные 3D-принтеры, стоимость их сильно варьируется в довольно крупных суммах. Однако в сферах науки используются в основном профессиональные устройства, которые качественно справятся со своей задачей. Крупные объекты в основном печатают на таких принтерах, так как площадь и скорость печати промышленного устройства, существенно превосходит таковые у аппаратов в бюджетном сегменте. Например, обычно бюджетный принтер имеет площадь печати не превышающий 450×450×450мм., тогда как промышленный имеет площадь от 600×600×600мм и до 2 и более метров. Соответственно, сканы крупных костей и черепов, сотрудники университетов или музеев печатают на таких принтерах.

Трицератопс, напечатанный на 3D-принтере, можно увидеть в Business Design Center в Лондоне. (Фото: Chris Ratcliffe/Bloomberg).

Однако с крупными объектами вполне могут справиться и принтеры в бюджетном сегменте, но объект нужно будет предварительно подготовить для печати, разрезав модель на части. При этом даже в таком случае печать будет очень долгой. Ниже, после нескольких слов про SLA печать, я расскажу — как печатал череп тираннозавра «Джейн» размером 1:1 (длина от носа до затылка 70см), на бюджетном FDM 3D-принтере.

Лазерная стереолитография (SLA) — технология 3D-печати, основанная на послойном отверждении жидкого материала под действием луча лазера. Используется в промышленных 3D-принтерах компаний 3D-Systems и Uniontech. Фотополимер — это вещество, изменяющее свои свойства под воздействием ультрафиолетового света.

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

Бюджетный фотополимерный 3D-принтер.
Область печати 72×150×150мм. Цена около 20тыс. руб.

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

Печать зуба Мегалодона фотополимерным принтером:

Финишный результат:

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

Из трёх FDM 3D-принтеров у меня в наличии только один с областью печати 400×400×400мм. Шесть лет назад я собрал его сам из разных комплектующих, этот принтер собственной сборки можно отнести к бюджетному сегменту. На нём и будет происходить печать черепа.

Фото вышеупомянутого 3D-принтера

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

Скриншот всех деталей черепа в программе Simplify3d

Печать производилась пластиком ABS, соплом 0.4 и слоем 0.2 Каждая крупная деталь печаталась отдельно. Лишь несколько удалось напечатать за 1 проход. По времени печати вышло примерно 3 недели. Самые крупные детали печатались минимум двое суток, это время печати одной крупной детали.

А вот и нос)

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

Частично собранный череп, на фоне взрослого ручного кота для масштаба. Габариты черепа и кота 1:1))

Химическая обработка черепа ацетоном. При помощи кисти весь череп несколько раз обмазывается.

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

Дальнейший этап работ, включает в себя грунтование и роспись черепа акриловыми красками. Я использовал белый грунт с баллона:

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

Финишный результат на фото:

Череп тираннозавра «Джейн» в моих руках

Скажи сы-ы-ыр 🙂

Череп состоит из двух частей. Нижней и верхней челюсти.

Далее «Джейн» с несколькими остальными репликами от моей мастерской (Nessitera Bones Factory), уехала в небольшое путешествие. На фестиваль науки «Улики Эволюции» в г. Санкт-Петербурге. Там она порадовала своим присутствием многих увлечённых людей. Думаю, стоит показать фотографии с фестиваля, ну а я с вами прощаюсь. Свои вопросы или критику оставляйте в комментариях, постараюсь ответить всем.

Фото с мероприятий:

На фото два черепа Тираннозавра «Джейн», на момент смерти ей было 11 лет. «Chomper» двухлетний детёныш тираннозавра:

На фото Самир Ефимов(справа) и Александр Яскин(слева). Организаторы фестиваля, от научпоп сообщества «Фанерозой»:

Дмитрий Соболев «Упоротый палеонтолог» фото его выступления:

«Джейн» на фестивале «Улики эволюции»:

Джейн обросла плотью. Художники Наталья Смирнова и Дмитрий Бухтияров:

Источники

https://www.researchgate.net
https://3dtoday.ru
https://ndt.by
Личный опыт)

Привет, Хабр! Буквально недавно стали известны итоги открытого соревнования по машинному обучению Data Fusion Contest 2022. Это уже второе соревнование, причём более масштабное, чем первое. В конкурсе с общим призовым фондом 2 млн рублей приняли участие более тысячи человек. Участники соревновались не один и не два дня, битва умов продолжалась целых 3,5 месяца. За это время организаторы получили 6,5 тыс. решений.

Что нужно было делать участникам? Если кратко, то главная задача была такой: при помощи машинного обучения решить проблему сопоставления из двух совершенно разных массивов данных. Требовалось сопоставить данные клиентов из датасета с транзакциями клиентов ВТБ по банковским картам и данные кликстрима (информация о посещении web-страниц) клиентов Ростелекома. Нужно было установить соответствие между клиентами двух организаций. Оно устанавливалось, если два клиента из датасетов – один и тот же человек. Конечно же, данные были деперсонализированы, сохранялась лишь весьма ограниченная информация о самом поведении пользователей. Сопоставлять всё это обучали искусственный интеллект. Подробности – под катом. А ещё там будет ссылка на исходники крутой библиотеки для ИИ, которую использовали победители конкурса. Поехали!

Зачем всё это?

Технологии Data Fusion и алгоритмы слияния данных становятся всё более востребованными в арсенале специалистов по анализу данных. Благодаря этим технологиям, с одной стороны, появляется возможность оперативно решать задачи бизнеса, с другой – удаётся сохранять высокий уровень безопасности клиентских данных, не выводя их за пределы компании.

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

Сбер создал и опубликовал в открытом доступе программную библиотеку PyTorch-LifeStream, содержащую несколько алгоритмов построения эмбеддингов событийных данных.

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

Событийные данные – разные последовательности. Это истории посещений сайтов,  банковских транзакций, истории мобильных звонков, истории покупок, событий в онлайн-играх и т. п. Сгенерированный на основе алгоритмов библиотеки эмбеддинг такой последовательности не содержит каких-либо персональных данных.

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

Про задачу

Самой популярной из трёх задач соревнования стала главная – Matching. Всего было представлено более 3 тысяч вариантов её решения от 84 команд. От участников требовалось сделать решение, которое устанавливало бы соответствие между клиентами крупного банка и интернет-провайдера, о чём говорилось выше. В качестве ответа для каждого клиента банка нужно было предоставить 100 наиболее вероятных клиентов провайдера. Оценка велась для ранжирования – то есть чем ближе правильный ответ был к началу списка, тем выше оценка.

Решения, предложенные участниками, оценивались и ранжировались автоматически. Победителей номинаций выбирали члены жюри – организаторы соревнования и приглашённые эксперты. Принять участие в Data Fusion Contest 2022 могли все желающие, если им исполнилось 17 лет.

Команда Сбера Sberbank AI Lab пришла на соревнование, имея обширный опыт работы с событийными данными. Участники – учёные из Лаборатории по искусственному интеллекту Сбера. Стоит отметить, что и для них всё было непросто – конкурсная задача матчинга позволила удачно применить разработанный в Лаборатории ИИ метод генерации эмбеддингов транзакционных данных одновременно для двух разных доменов событийных данных (транзакции и кликстрим – атрибуты посещения веб-страниц).

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

Про данные

Всего в датасете было 15,4 млн транзакций для 17581 уникального клиента банка и 94,8 млн событий кликстрима для 14671 уникального клиента провайдера. Примерно 16,6% клиентов банка были без матчинга. Кроме того, организаторы предоставили неразмеченные данные в виде датасета из 4952 клиентов банка с 4,4 млн транзакций и столько же клиентов интернет-провайдера с 32 млн кликов. Вот как выглядели сами данные. Сопоставленные пары идентификаторов клиентов в банке и у провайдера:

Банковские транзакции:

ID клиента, mcc-код и два поля с его текстовым описанием, код валюты с расшифровкой, сумма транзакции и время транзакции.

Кликстрим – данные о веб-сёрфинге:

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

Базовое решение

Организаторы соревнования предложили baseline, в котором в качестве фичей считались простые статистики (sum, mean, count) по сумме транзакции или количеству кликов в разрезе каждого mcc-кода или категории. Фичи для транзакций и кликов объединялись и подавались в алгоритм бустинга. Алгоритм обучался как задача бинарной классификации. Правильным ответом была 1, если транзакции и кликстрим соответствуют одному человеку (есть мэтч). Ну и 0 получался, если клиенты были разными людьми. Для каждого клиента банка был доступен один правильный клиент интернет-провайдера (соответствие из разметки) и несколько случайно выбранных из всей выборки неправильных примеров. На public leaderboard базовое решение получило оценку качества R1 = 0.2217.

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

Модель Sberbank AI Lab

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

Сеть включает два этапа:

• TrxEncoder, который преобразует каждую отдельную транзакцию или  клик в векторное представление.

• SequenceEncoder, который сжимает последовательность векторов из TrxEncoder в один конечный вектор.

В качестве кодировщика транзакций был взят готовый слой из библиотеки TrxEncoder. Его работа показана на схеме:

Обучающий батч содержит 128 пар пользователей банк-провайдер. Это короткая последовательность событий, выбранная для каждого пользователя дважды – один раз на основе транзакций в банке и второй раз на основе его истории посещений сайтов. Таким образом, есть 256 образцов последовательностей транзакций для 128 пользователей банка и 256 образцов последовательностей кликов для 128 пользователей провайдера. Затем создаётся матрица 256*256 с попарными расстояниями L2 и матрица с совпадением-несовпадением меток. Метки использованы для выборки положительных и отрицательных образцов для функции потерь Softmax Loss.

SequenceEncoder – рекурентно-нейронная сеть (RNN), совместно используемая для транзакций и кликов. Веса инициализируются случайным образом. TrxEncoder представляет собой конкатенацию обучаемых векторов (эмбеддингов) категориальных признаков и нормализованных числовых значений. TrxEncoder обучается транзакциями, а затем отдельный TrxEncoder обучается на данных кликов. Также предварительно обучаются веса для обоих TrxEncoder.

Команду вдохновила архитектура BERT для предварительной подготовки. Поэтому использована схема TrxEncoder + TransformerEncoder и задача MLM (Masked Language Model). TransformerEncoder предсказывает маскированные векторы TrxEncoder.

Аугментации

На всех этапах обучения сети использовались аугментации.

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

При втором способе аугментации вырезалась часть из всей последовательности. Длина и место начала семпла выбирались случайно. Параметры семплирования были заданы так, что в обучение попадали как очень короткие последовательности (порядка 64 событий), так и очень длинные (до 2000 событий, примерно половина всей последовательности). На коротких последовательностях сеть быстрее учится. На длинных – получает больше информации.

Ансамблирование

В финальном варианте решения команда добавила использование ансамбля сетей. Несколько сетей обучались с разными random seeds. Каждая сеть выдавала матрицу попарных расстояний, а эти матрицы усреднялись по всем сетям ансамбля. В итоге это дало самый большой прирост качества: для ансамбля из пяти моделей метрика качества R1 выросла с 0.2819 до 0.2949. Вот график зависимости качества от количества сетей в ансамбле:

В финальном решении удалось уместить 11 сетей, вычисление ответа для которых выполнялось почти за час. Можно было ускорить инференс и взять больше моделей в ансамбль, если бы команда вовремя заметила, что GPU в контейнер не подключилось. Позже были проведены точные замеры на локальной машине, оказалось, что с GPU инференс с пятью моделями в ансамбле работает 2 минуты, из них полторы – это предобработка данных.

Итоговое решение команды Сбера доступно на GitHub. 

Что же, на этом всё. Если вам интересны подробности решения либо есть другие вопросы – пишите в комментариях, а мы обязательно ответим.

Платформе 8.х почти 19 лет, идет ли она в ногу со временем?

На сайте releases.1c.ru  первые релизы 1с 8.х датируются 2003 годом. В промышленной эксплуатации  был  оперативный учет, а бухгалтерский и механизм сложных периодических расчетов (зарплата) были в бэта тестировании.

С тех пор платформа до версии 8.3 нарастила функционал во многих направлениях, казалось бы там есть все что нужно для автоматизации учета , создания веб\мобильных приложений, готовые типовые конфигурации.  Беглый просмотр архитектуры https://v8.1c.ru/platforma/  вызывает желание автоматизировать все, что возможно на предприятии напр. полную цепочку от продаж до учета. Если оценивать запас прочности системы на рост данных, объема операций, подключений – платформа предлагает масштабируемый  на нужное число серверов сервер приложений 1С. Механизм фоновых заданий позволяет обрабатывать наборы операций (пакеты)  параллельно.

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

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

Термин допускает разные трактовки в зависимости от архитектуры и задач (пример).

Кстати фирма 1С под масштабируемостью подразумевает совсем другое. 

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

• Интернет продаж\мобильных приложений

• Электронных платежей

• Применения роботов в обработке заказов\сделок. Напр на фондовом рынке большинство сделок создается роботами или автоматизированными процедурами.

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

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

Конечно можно предложить рассмотреть конструктор на стеке Java, С# в связке с любимой СУБД ,но нужно понимать, что они не для прикладного программирования, без полноценных RAD  (Rapid application development) инструментов и там вообще ничто не ограничивает от плохих архитектурных решений, кроме опыта, знаний и правильного понимания архитектурных паттернов. Плюс цена такого решения будет в разы дороже. Далее рассматриваются решения с максимальным использованием возможностей 1С. Я знаю что ктото пишет\читает напрямую в\из базу SQL и использует недокументированные возможности, но с RAD это не имеет ничего общего лучше каждый инструмент использовать по назначению.

Анонс. (далее нерешенные темы анонсируются как темы отдельных статей, по просьбам трудящихся ;)): У разработчика на 1С достигшего уровня гуру 1С возникает соблазн строить архитектуру вокруг 1С. Если же разработчик знает технологии реализованные на Java или C# возможности интеграции 1С с другими приложениями кажутся скромными.  Приходит осознание, что 1С это всего лишь один из сервисов с ограниченным функционалом  и правильней строить архитектуру как микросервисную, где 1С это сервис хоть и не микро.

Далее примеры будут приводится для финансового учета операций с фондового рынка ценных бумаг, где приходится работать с исходными сделками импортируя их без агрегации в количестве  около 1 миллиона в день, а количество изменений (связанные реквизиты, трансферы, изменения реквизитов или трансферов) по ним около 4-6 миллионов в день.

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

Разберем кейс на примере: Сообщения с изменениями операций поступают в шину RabbitMQ . Оттуда их считывает процесс Message Reader и сохраняет сообщения в индексированный буфер. Данные из буфера читаются кластером 1С и преобразуются в документы, записи регистров сведений 1С и сохраняются в базу.

Влияние языка программирования 1С на масштабирование приложений

Импорт данных

Давайте сначала попробуем максимально быстро импортировать операции. В 1С есть возможность разбить наборы данных (операции\платежи\ сделки ) на массивы фиксированного размера (далее пакет) , и запустить на исполнение фоновыми заданиями в нужном количестве (40 параллельных заданий вполне оптимально для одного современного двухпроцессорного сервера приложений).

Попробуем через документ.

Документ не аргумент

Для операций в 1С предусмотрены метаданные типа Документ и для определенных случаев можно применять БизнесПроцессы, Задачи. При этом Документ естественно имеет преимущества – его можно записывать без проведения, логику создания проводок\движений в регистры вынести в отдельные параллельные обработки.

Возьмем Документ, мы можем передать 1000 xml в фоновое задание,  создать  1000 документов в памяти, разыменовать ссылки на справочники одним запросом и … записывать каждый документ в пакете придется последовательно методом Документ.Записать() без проведения. Если посмотрите, как это отражается каждая запись в Profiler MSSQL станет еще грустнее .

Не забывайте что любая операция Документ.Записать() это на SQL сервере это как минимум поиск существующего документа,  обновление таблиц, а если есть табличные части в документе то еще удаление\вставка.

Анонс Внутренняя трассировка через SQL Profiler операций записи , особенно в регистры , тянет на отдельную статью там сразу видны все узкие места. Чаще всего в профайлере анализируют запросы на чтение напр https://infostart.ru/1c/articles/1492368/ , по анализу операций записи статей не встречал.

Можно закрыть глаза на эффективность обработки данных документов на уровне процессор – память , ведь это можно решить распараллеливанием, но запись на диск (даже SSD) уже будет узким местом.

Конечно когда 40 параллельных фоновых заданий пишут документы (пусть последовательно внутри задания) это дает надежду увеличить возможности кластера и увеличить их например до 80  и решить проблему оборудованием (напр много ядер и база на SSD полностью). Однако при таком количестве мелких DML (data manipulation language) операций SQL (не путать с транзакциям 1С\MS SQL ) вы неизбежно упретесь в возможности записи в MS SQL transaction log даже на уровне его процессов write log  см статью

https://chrisadkin.io/2015/09/09/tuning-the-logcache_access-spinlock-on-a-big-box/

https://chrisadkin.io/2015/06/11/writelog-at-scale-going-beyond-you-need-faster-disks/

Это неочевидный момент – метод .Записать() создает несколько DML операций SQL  . Помножьте это на количество операций и вы поймете какую нагрузку 1С  создает на SQL Server которую можно наблюдать как количество BatchJobs в секунду . Даже если это заключить в НачатьТразнакцию \ ЗафиксироватьТранзакцию лучше не станет, ведь транзакция будет содержать не крупный DML оператор на 1000 записей, а больше 1000  маленьких.

Анонс: С такой ситуацией столкнулся на практике при нагрузочном тесте кластера на VMWare, там очень много интересных эффектов проявилось при высокой нагрузке

Не случайно при разработке на MS SQL или Oracle рекомендуют укрупнять DML операции и транзакции до разумного предела. Кроме того обновление записи в таблице влечет еще и обновление индексов которых 1С создает немало (см. здесь). 

Анонс: При высокой параллельной записи индексы серьезно затрудняют даже вставку (а обновление тем более) и есть особые рекомендации Microsoft на эту тему.  

При таком устройстве языка программирования невозможно записать несколько документов в одном DML операторе

При такой организации языка возникает много запросов\ответов по сети. Обмен по сети между кластером 1С и SQL в этом случае уже требует Teamed lan , + процессорные ресурсы сервера , ведь трафик увеличивается и его кто-то должен обрабатывать на сервере даже если сетевая карта часть работы берет на себя.

А может быть использовать Регистр сведений без регистратора как альтернативу Документу?

Конечно, на экзамене 1С будет оценка 2 за нецелевое использование,  но если очень хочется, то можно. Можно построить , например, такой регистр сведений.

И да метод РегистрСведенийНаборЗаписей.<Имя регистра сведений>.Записать (Истина) позволяет добавить сразу несколько документов с разными ИдИсхСистемы. Это хорошо, но проблемы в языке 1С остаются

1. Обновлять записи придется в рамках одного значения  измерения ИдИсходнойСистемы. Ведь отбор в наборе записей может устанавливаться только на равенство  (см справку).Это нивелирует все выигрыши если есть повторные обновления большинства документов (напр так устроена front office система).

2. Если посмотреть MS SQL профайлер 1С использует  при Update простые delete , insert  по комбинации измерений, а не более эффективный  merge

3. Если у документа нужна табличная часть, ее придется помещать в отдельный регистр сведений и для связи с основной таблицей повторять в ней значения измерений основного документа. Вообще необходимость измерений, не дает рассматривать регистр сведений как простую таблицу (аналог табличной части документа). В этом примере невозможно добавить несколько одинаковых реквизитов с разными значениями. А простых таблиц в 1С не предусмотрено, если не считать трюки с регистром сведений у которого одно измерение УИД. 

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

Формирование движений в Регистры Бухгалтерии  и Накопления с максимальной скоростью

Я намеренно упустил регистры сложных периодических расчетов поскольку диапазон их практического применения ограничен расчетом зарплаты и начислением различной амортизации.

По производительности от медленных до быстрых рассматриваемые регистры располагаются так:

Движения по регистрам платформа позволяет формировать не только из модуля объекта документа (Процедура ОбработкаПроведения), но и из любой обработки через НаборЗаписей.

В нем тоже существует ограничение на работу с набором записей поскольку метод .Записать() можно вызвать только для одного регистратора. Это ограничение легко обойти если под Регистратором понимать не операцию\сделку, а вот такой документ СУУ_АгрегированныеПроводки, который может служить регистратором для проводок сотни реальных документов.

Вариант реализации на практике

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

А где будет исходный документ основание?

Его можно поместить в индексированный реквизит проводки, или движения регистра

Проблема записи проводок\движений пакетом решена?

На самом деле нет и виной тому организация хранения итогов по остаткам. Если посмотреть через SQL Profiler даже в периоде с нерассчитанными итогами и отключенными текущими итогами, sql код обращается к рассчитанным итогам, как понимаю для контроля периода записи. Организация записи не самая эффективная, но это когда-нибудь решат. Корень проблемы в возможности динамического обновления остатков даже за закрытый месяц, а механизма отложенного обновления остатков как в регистрах накопления с агрегатами нет (они бывают только оборотные).  Конечно динамическое обновление остатков это плюс для разных схем с ручным отпуском\приемом товара, но жирный минус когда нужно просчитать миллионы документов. С включенными текущими итогами о производительности вообще можно забыть, поэтому сдвиг итогов на прошлый месяц и выключение текущих итогов разумный компромисс.

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

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

Анонс: Как выйти за рамки инструментов 1С и сохранить скорость разработки?

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

Управление неуправляемыми фоновыми заданиями

Вообще, чтобы  обработать операции параллельно  — механизма фоновых заданий недостаточно. Параллельные вычисления это достаточно старая тема и есть даже сайт https://parallel.ru/tech , где максимально собрано много научной информации. Массово в 1С это стало возможно применять с 2009 года , когда  появился механизм фоновых заданий, сервера на базе чипсетов Intel\AMD стали не только многопроцессорными, но и многоядерными.

В  1С с фоновыми заданиями работать просто:

1. Нужно передать немутабельные параметры с массивом операций.

2. Запустить на выполнение

3. Дождаться завершение всех или части фоновых заданий. Можно проверять по таймауту

Но построение программы с параллельной обработкой в самом простом случае это еще

А) Балансировка нагрузки

Б) Обработка ошибок

С) Работа с общей памятью

Д) Отладка

Кто ответственен за балансировку нагрузки кластер или программист?

Для версии 8.3.21 есть возможность назначения сервиса фоновых заданий на несколько серверов кластера и гибко распределять нагрузку даже для конкретных фоновых заданий или групп , что описано тут <Вывести в приложение>

https://its.1c.ru/db/v8321doc#bookmark:cs:TI000000036

И через дополнительные параметры фоновых заданий. Сделано разумно, но ведь есть еще ситуации, когда фоновых заданий может быть много, напр грузим 4 миллиона операций по 1000 в каждом задании. Получим 4000 фоновых заданий. Что будет если система сформирует их все сразу ? 😉 Ничего хорошего.

Даже если задания встанут в очередь, кластер не может предсказать как будет работать алгоритм разработчика. Напр на старте задания выполняют запрос на чтение к базе, это не грузит кластер\но грузит базу SQL – а после получения выборки задания начинают ее обрабатывать почти одновременно . Тут легко оказаться в ситуации, когда число взятых на выполнение заданий превосходит возможности кластера и никакие трюки с механизмом «Доступная производительность» не помогут.

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

Анонс: Разработка собственного механизма управления заданиями это уже близко к системному программированию с моделью событий, пусть и реализуемые на языке 1С . Основная проблема – отслеживать пакеты заданий с разных сеансов, напр кто-то запустил импорт из тысячи заданий, кто-то расчет за прошлый период из тысячи заданий, а уложится нужно, например, в 80 одновременно выполняющихся. Реализация на уровне кластера могла бы упростить задачу.

Если соблюдать деление на пакеты при обработке больших данных, то все можно сделать предсказуемым и объем требуемой памяти, и соединение 1000 объектов с большой таблицей, и управление нагрузки задавая максимальное количество фоновых заданий. Печально только то, что в кластере 1С, при управлении фоновыми заданиями, задать максимальное  количество заданий для одновременного исполнения нельзя.

Обработка ошибок – задание улетело и обещало вернуться

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

Из официальной документации последних версий

Цитаты

Завершившиеся успешно или аварийно фоновые задания хранятся в течение суток, а потом удаляются… История хранится для каждой информационной базы… Фоновых заданий ‑ не более 1 000 заданий… Регламентных заданий ‑ не более 1 000 заданий… При этом система пытается хранить не менее 3 последних запусков для каждого различного регламентного задания…

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

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

Общая память не так страшна если это InMemory СУБД

В горизонтально масштабируемой среде важна общая память, чтобы отслеживать процесс обработки. Пример из жизни в шину приходят версии операций\котировок и т.д. вам нужно это загрузить параллельно причем версия 1 не должна  перетереть версию 2. Без общей памяти такой подход невозможен, приходится делать выборку последних версий т.е. создавать одну выборку и инфраструктуру хранения.  С общей памятью можно фиксировать загруженную версию и быстро проверять ее, без обращения к диску СУБД. Пока такое можно решить только внешними средствами выбрав подходящую InMemory СУБД либо MySQL с таблицами в памяти, где многие аспекты совместной работы и нагрузок решены.

Анонс.  Следует заметить, что InMemory СУБД это не просто таблица в памяти или MSSQL с tempdb, который поместили виртуальный диск в  память. Это защита от потери данных, сброс на диск данных которые, не помещаются в память и многое другое. InMemory tables в MSSQL не совсем решают задачу общей памяти так как они разработаны для задач быстрого получения отчетов а не записи. Как следствие   к выбору средства общей памяти нужно подходить взвешено.

В 1С мы имеем полушаги по обмену информацией между заданиями

ВременноеХранилище – имеет время жизни ограничение по работе с фоновыми заданиями

https://its.1c.ru/db/v8317doc#bookmark:dev:TI000000819 «Данные, помещенные во временное хранилище в фоновом задании, не будут доступны из родительского сеанса до момента завершения фонового задания.»

https://its.1c.ru/db/v8321doc#bookmark:dev:TI000000809 «ВНИМАНИЕ! При помещении во временное хранилище фактическая сериализация значения не выполняется. Помещается ссылка на значение, которое хранится в кеше в течение 20 минут. По истечении этого периода значение сериализуется, записывается на диск (в хранилище сеансовых данных) и удаляется из кеша.»

Менеджер временных таблиц – мутабелен , его нельзя делить между заданиями. Нельзя дописывать во временные таблицы, а можно только однократно записать (фактически аналог select into)

Остается только использовать структуры хранящиеся в СУБД напр. регистры сведений, но они медленные в текущей реализации 1С 8.х

Отладка  — поймай меня, если сможешь

Формально отлаживать фоновые задания можно, просто когда возникают проблемы плавающего характера приходится применять методы трассировки  — фиксация состояния программы вставками в код. Трассировка должна быть незаметной для производительности и независимой от транзакций. Метаданные 1С для этого не подходят,а  журнал регистрации имеет фиксированную структуру и с ним тяжело работать c  точки зрения поиска– это не https://logging.apache.org/ . Выход – выносить механизм трассировки на внешние механизмы, задача для реализации в хорошем виде непростая и тянет на отдельную статью 😉 

Как обойти ограничения 1С?

Я думаю в статье приведено достаточно примеров задач, которые можно решить горизонтальным масштабированием  в 1С, но структура языка программирования 1С накладывает четкие ограничения. А зачем их собственно обходить, если есть другие языки программирования? Ответ простой   — ради плюсов, которые дает использование 1С как средство быстрой разработки и наличие хороших типовых конфигураций 1С. Замечу хороших с прикладной точки зрения, но не с точки зрения производительности. Чтобы эти плюсы сохранить нужно стратегически сохранять разработку прикладного кода в рамках платформы 1С 8.х, а за рамки выводить только узкий функционал. Решение в этом случае не получится монолитным и похожим на микросервисную архитектуру, но это не должно пугать —  она и так начинает делится на более менее крупном внедрении напр

• Отдельная база для ведения справочной информации (master data management)

• Отдельные базы для разных юрлиц или видов учета . Классический вариант 1С Управление торговлей отдельно, 1С Бухгалтерия отдельно.

• Обмены

• Шины данных (RabbitMQ+ буфер для хранения)

• Управление всем этим и многое другое

Основные направления обхода ограничений:

Анонс: Импорт в регистр сведений, напрямую через СУБД. Достаточно простая структура позволяет это сделать грамотно, а объем хранения в СУБД не имеет значения при правильно организованных индексах.

Анонс: Агрегируйте. Если вы работаете с большим количеством операций, лучше избегать дублирования по цепочке бизнес процесса. Это не всегда возможно если FrontOffice, Backoffice  и Finance\Management accounting находятся в разных системах. Однако расходы на хранение и обслуживание такого количества информации сразу можно умножать на 3 . И тут сразу появляется повод договорится с Business owner систем. Ведь важно не только все это хранить на избыточных RAID но и быстро считать. Агрегация непростой процесс, поскольку даже в Finance\Management accounting ошибки сверки требуют лезть в расшифровку . Вы либо храните ее внутри системы, либо доверяете внешней с учетом возможных изменений конечно 😉

Анонс:  Если чтото лучше вне 1С используйте это. В качестве примера можно привести интеграцию с шинами. Пример RabbitMQ. Есть решения от PinkRabbit, и сейчас от 1С. Проблему со считыванием они как то решают, но ведь важно не просто считать, а быстро сохранить . Делать это через кластер 1С, который отделен от базы данных (а без этого не получится горизонтального масштабирования)  неэффективно по производительности , особенно когда речь идет о 7 миллионах сообщений в день, которые могут еще за пару часов появится J . Выход – отдельное решение с буфером.

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

В качестве заключения

Можно ли все это исправить расширяя язык программирования? Конечно можно, просто цепочка изменений внутри платформы и кластера будет достаточно большой. Еще нужно внедрить соответствующий стиль программирования в массы, ведь не все читают статьи подобные этой.  Пока 1С предпочитает наращивать возможности функционала типа СистемаВзаимодействия без пересмотра базовой архитектуры. Однако рост данных это цунами которое неожиданно появляется из небольших волн, ты либо готов к нему сейчас либо нет. Кто хочет подготовится заранее, предложить альтернативные решения, присоединяйтесь в чат. 

«Трон», «Призрак в Доспехах», «Тринадцатый этаж», «Аватар» Джеймса Кэмерона, добрая треть эпизодов Стар Трека… Наше общественное сознание давным-давно готово к тому, что наш мозг можно (и, наверное, нужно?) будет оцифровывать. Но как далеко нам остается до технологии полноценной загрузки сознания? И какой у нас шанс увидеть это в обозримом будущем, хотя бы для Маска и Гейтса?

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

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

В этом крошечном кубическом миллиметре мозговой ткани (размером меньше песчинки) ученые насчитали 100 000 нейронов и более миллиарда связей между ними. И, что важно, им удалось записать всю эту конфигурацию на компьютер. Включая форму каждого соединения и нейрона. Для этого им потребовалось… два петабайта памяти. Для сравнения, все спутниковые снимки Земли, собранные миссиями Landsat за 30 лет, занимают всего 1,3 петабайта.

Если бы ученые попробовали сейчас записать на компьютер целый мышиный мозг, в котором около 14 млн нейронов, то им нужно было бы 280 петабайт. Это примерно столько, сколько весь Google обрабатывает за день. Чтобы хранить такой мозг на облаке по коммерческим ценам AWS ($0,021 за ГБ) нужно было бы платить по $5,88 млн в месяц. Хотите подождать 30 лет, пока технологии подрастут, и вы сможете воскресить этот мозг? Будьте добры, выложите $2,1 млрд.

Дороговато, прямо скажем. Но чего не сделаешь ради любимого домашнего питомца! Мозг которого, между прочим, по числу нейронов в 6100 раз меньше, чем у человека.

В общем, даже если бы Безос, Маск и Цукерберг собрались вместе и сыграли в рулетку на сохранение полного оцифрованного мозга хотя бы одного из них, при текущем уровне технологий их совместного капитала хватило бы на 11 месяцев хранения такого мозга (при стоимости $36 млрд в месяц). Ну а в действительности, конечно, такой объем данных сейчас просто негде было бы держать.

Вопрос хранения

Итак, для хранения одного человеческого мозга нам сейчас нужно ~170 800 петабайт данных. Это 1,7 зеттабайта. Нереально много, но в принципе, если у нас будет стоять задача сохранить один какой-то мозг для поколений… Смотрим: в 2020 году в мире было создано 64,2 зеттабайт данных. УРА! Это 37 мозгов! Каждый год!

…Но из них удалось перманентно сохранить меньше 2%. Большая часть этих данных была временно создана или реплицирована, а затем удалена, чтобы освободить место. А 2% от 64,2 ЗБ это… 1,284 ЗБ новых данных, которые за год смогло сохранить человечество. Даже для одного мозга таких объемов «нового хранилища» не хватит.

Так что нам придется удалять часть той информации, из которой сейчас состоит интернет, или требовать у людей резервировать пространство на их жестких дисках, создавать поменьше сайтов и прекратить загружать котиков на Ютуб, чтобы мы всем человечеством смогли за год сохранить хотя бы один мозг для поколений (сейчас весь интернет, по оценкам, весит порядка 40 ЗБ).

Может показаться, что это как-то чересчур, и такого не может быть. Где один мозг, который дай бог прочитал сотню книг, — а где весь объем информации, накопленный человечеством. Но количество нейронных связей в мозгу (~2·1014) просто чересчур велико, в тысячи раз больше, чем звезд в галактике. Каждый нейрон связан с сотнями или тысячами других, и сложность у итоговой структуры получается невероятная.

Конечно, отчасти дело здесь в несовершенстве наших текущих технологий сканирования мозга. Если вывести дело из лабораторий на коммерческий рынок, наверное найдутся компании, способные ужать данные в 10 или 100 раз. И еще они наверняка станут предлагать нам услугу удаления мозжечка — в конце концов, зачем нам моторика, если мы живем в облаке. Занимая всего 10% объема мозга, мозжечок содержит в себе 77% наших нейронов. А это 77% потенциальной экономии!

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

Эх, заживём!

Вопрос пропускной способности

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

И тут уже проблема другого порядка: самый большой из когда-либо созданных компьютеров с одним модулем памяти имел ОЗУ на 160 ТБ. Это примерно в миллион раз меньше тех 1,7 ЗБ, которые нам нужны. Даже если для технологий хранения мозга каким-то чудом будет работать закон Мура (который уже несколько лет как истощил себя в плане улучшения средств хранения данных), для выхода на нужные мощности нам потребуется минимум 40 лет. То есть, если прямо сейчас бросить все силы в разработку и заняться этим делом так же, как мы занимались уменьшением размера транзисторов, к 2062 году человечество получит рабочую модель мозга на компьютере, способную реагировать с такой же скоростью, как и наш текущий мозг. Это при лучшем стечении обстоятельств, конечно.

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

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

Вопрос времени

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

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

Но это не слишком большая проблема, потому что в 20 лет у нас 90-100 миллиардов нейронов. И с такой скоростью мы потеряем всего 2-3% наших нейронов к 80 годам. Если мы не заболеем нейродегенеративным заболеванием, наш мозг может хорошо работать в течение всей нашей жизни. Но тогда возникает вопрос: в каком возрасте лучше остановиться и сделать автосохранение?

Какой ум вы бы предпочли сохранить, себя 20-летнего или 70-летнего? В первом случае мозг будет более пластичным, зато во втором — у вас будет уже накопленный багаж знаний. К тому же, вы можете сэкономить 2-3% на оплату сканирования и хранения данных. Но если сохраниться слишком поздно, можно получить цифровой мозг с начавшей развиваться деменцией. Или мозг с зачатками болезни Альцгеймера, которая может начать развиваться даже раньше 40 лет.

Ну и что делать? В каком возрасте вы — лучший вы? Когда нужно себя сохранять? Стоит ли жертвовать всем своим опытом и воспоминаниями? Если вы решили сохранить себя 30-летнего, а умерли в 80, видимо, нужно записывать для вас блокнотик с перечислением всех тех событий, которые случились с вами за эти 50 лет? И пару фото из семейного альбома, чтобы показать, чем для вас всё закончилось? 

Вопрос этики

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

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

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

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

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

Даже просто моделирование «физического» ввода и вывода — уже большая проблема. Нужны будут камеры, которые могут в точности скопировать человеческий глаз, кожа, способная реагировать на прикосновение, ноздри, способные улавливать ароматы. Про внутренние органы нечего и говорить, это еще сложнее. Если бы мы могли всё это сделать, получился бы готовый человек.

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

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

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

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

Здесь остается только пожелать всем хабровчанам долгой и здоровой жизни) Потому что она у нас совершенно точно одна. Даже если элементы кого-то из нас через 40-50 лет и начнут существовать на облаке AWS или в форме андроидов.

Промокод для читателей нашего блога!

— 15% на все тарифы VDS (кроме тарифа Прогрев) — по промокоду HabrFIRSTVDS.

50 тысяч активных серверов и 10 тысяч клиентов, которые с нами больше 5 лет.