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

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

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

Для меня истинная ЭКГ определяется ответом на вопрос: Поддерживает ли ваша система строгие требования к устойчивым, масштабируемым, высокосвязным и запрашиваемым наборам данных в больших различные организации?

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

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

2. Масштабирование вычислений - добавление дополнительных процессоров должно быть возможным без прерывания обслуживания. Это означает даже добавление нового оборудования, такого как ПЛИС, для выполнения вычислений подобия в реальном времени параллельно с ЭКГ без прерывания обслуживания.

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

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

5. Масштабирование качества данных. Программное обеспечение ЭКГ должно упростить выполнение проверки данных при их вводе в ЭКГ и по мере их развития в ЭКГ по мере появления новых взаимосвязей. Создание обширных и поддерживаемых правил качества данных на декларативных языках, таких как XML Schema с редакторами графического интерфейса пользователя, и создание правил для качества ссылок, таких как SHACL, должно стать неотъемлемым компонентом будущих EKG.

6. Алгоритмы горизонтального масштабирования - ЭКГ должны запускать обширную библиотеку стандартных алгоритмов графов и новое поколение алгоритмов машинного обучения, которые создают встраивание графов. Сложные запросы, интенсивно использующие ЦП, должны иметь возможность запускаться на EKG, не влияя на уровни обслуживания приложений.

7. Масштабируемый запрос. ЭКГ требуется программное обеспечение для запросов, которое позволяет разработчикам выражать распределенные запросы на языках запросов высокого уровня. На днях Map-Reduce мы узнали, что принуждение разработчиков к написанию 10-страничных программ Java, запуск которых занимает несколько дней с неиндексированными необработанными файлами, не поможет в будущем. Такие функции, как Accumulators в GSQL, позволяют разработчикам графических запросов легко выражать распределенные запросы всего несколькими строками кода.

Оставаться маленьким по-прежнему в порядке

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

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

Оперативное мышление или мышление в банке

Одна из ключевых проблем, с которой борются многие архитекторы решений, - это требования к представлению связанных данных в сети по сравнению с представлением связанных данных в базе данных (in-the-can). Как сформулировал Тим-Бернес Ли в своем знаменательном выпуске Scientific American в мае 2001 года, первоначальное видение Семантической паутины было видением публикации данных, а не технологии масштабируемых корпоративных запросов к базам данных.

Хотя использование одного и того же стека для обеих целей было достойной похвалы, похоже, это не сработало. Проблемы с эволюцией схемы и реификацией RDF (Проблема башни Jenga) не позволяли крупномасштабным системам баз данных RDF быть рентабельными для любой команды из более чем десятка разработчиков. RDF * (RDF звезда) - похвальная попытка, но, возможно, это будет слишком мало, слишком поздно. Продукты баз данных LPG теперь доминируют на рынке корпоративных графов и показали, что они могут удовлетворить взыскательные требования предприятия.

Заключение

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

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

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