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

Веб-сайты

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

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

И обычно мы также хотим:

  • Создавайте представления этого состояния и используйте их как сами состояния. Например, если у нас есть объект с first_name и last_name, мы можем захотеть вычислить его full_name, чтобы обеспечить согласованную абстракцию во всем приложении.
  • Создайте правила для того, что допустимо, а что недопустимо в штате. Это может быть базовая типизация или что-то с более сложной логикой.

Что-то вроде Cerebral реализует большинство из этих возможностей.

Популяционный метаэвристический поиск

в частности, генетическое программирование

В прошлом году я построил библиотеку, чтобы помочь Лаборатории вычислительной разведки Хэмпширского колледжа проводить свои исследования. Я сдался в конце года, потому что я думаю, что откусил что-то слишком большое. Но в процессе я понял, какие потребности существуют в такого рода библиотеке. У нас есть в памяти представление состояния программы, по сути, в виде списка индивидуумов для текущего поколения. Вы можете представить весь эксперимент следующим образом:

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

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

Хранение и анализ результатов генетического программирования

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

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

Прямо сейчас я выгружаю все вложенные представления каждого поколения в файл Parquet (например, лучше сжатый JSON). Затем я могу запустить на нем какой-то SQL (либо через Spark SQL, либо через Apache Drill), чтобы извлечь ответы на различные вопросы о данных. Одна из проблем заключается в том, что в SQL трудно рассуждать о очень вложенных данных. Это не то, для чего создавалась система, и вы можете делать это с этими системами, но это кажется очень неинтуитивным.

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

Во всяком случае, сейчас я менее уверен в этом, но мне кажется, что есть способ, которым можно было бы помочь всем трем вариантам использования, используя графы вместо деревьев для их структур данных. Мы уже видим, что Интернет идет по этому пути, по крайней мере, с состоянием на стороне сервера, с GraphQL. Каждый компонент получает свои значения не из дерева состояний, а из запроса графа. Однако на стороне клиента я не знаю, как добавить в это дерево динамические вычисления. Можем ли мы добавить что-то вроде full_name на сайт с помощью GraphQL?

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

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

Что, если бы мы сделали это во время выполнения? Что, если бы мы использовали графовую базу данных для нашей эволюции?

Кроме того, я только что прослушал интервью, в котором говорилось о рассмотрении приложений данных как семантических данных, что похоже на триплеты данных графа ([saul, mother, sarah]). Если бы мы сохранили эти данные в текстовых файлах в виде триплета, мы легко могли бы позже добавить saul, error, 23 . Это означает, что мы могли бы добавить динамически созданные значения позже, чтобы вычислить их… В любом случае, может быть, было бы лучше хранить в базе данных, а не в текстовом файле? Но до сих пор мне очень везло с Parquet, и большая часть наших данных, по крайней мере, только добавляется, мы никогда не хотим что-то удалять…