Введение

В настоящее время всё большую популярность приобретает термин “Big Data“, объединяющий в большинстве случаев как структурированную, так и неструктурированную информацию.

Структурированные данные поддаются автоматической обработке (естественное представление в БД позволяет оперировать данными с использованием стандарта SQL), в то время как данные в неструктурированном виде лишены такой возможности.

Считается, что структурированные данные говорят нам «что», неструктурированные отвечают «почему». В неструктурированном виде хранится большая часть управляющей и регулирующей информации, в том числе около 80% внутрикорпоративной:

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

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

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

Описанные проблемы решаются текстовым анализатором (text data processing). Его основная задача — преобразование неструктурированных данных в структурированные для последующего анализа. Другими словами, можно быстро обрабатывать большие объемы данных без необходимости погружения в текст. К примеру, необходимо предотвратить создание дублирующих записей о клиентах в CRM системе. В таком случае оператор в процессе создания записи будет иметь перед глазами список аналогичных существующих записей.

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

Или: посредством анализа социальных сетей (развитие текстового анализа послужило созданию Social Networking Data Mining) можно следить за настроением рынка — оперативно получать feedback от клиентов:

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

Применение оператора LIKE в текстовом поиске

Оператор LIKE можно считать упрощенным вариантом полнотекстового поиска (покрывает метод EXACT. (см. Примечание)). С определенным спектром задач он справляется (поиск фразы в открытом документе), но его возможности ограничены. Полнотекстовый поиск (FULL TEXT SEARCH) обычно используется в случае, когда функциональности … WHERE “COMPANY_NAME” like ‘%нефть%’… недостаточно и требуются более мощные и гибкие возможности. Оператор LIKE ищет последовательность символов, в то время как полнотекстовый поиск обладает рядом преимуществ и особенностей:

• Ошибкоустойчивый поиск (поиск имени продукта “saphana“ –> “sap hana“)
• В сравнении с оператором LIKE не так критичен порядок слов, а также регистр
• Извлечение данных из бинарных объектов
• Возможность лингвистического поиска по описанию продуктов («компанию» –> «компания»)
• Результаты с соответствующими весовыми коэффициентами релевантности (можно сортировать по релевантности)
• Поиск с синонимами (“Ltd“ –> “Limited“)
• Использование стоп-слов (слова-паразиты не будут учитываться).

Примечание. Тип полнотекстового поиска возвращает строку, если она полностью содержит искомую.

ТЕКСТОВЫЙ АНАЛИЗ В SAP HANA

В SAP HANA текстовый анализ предоставляет большое число возможных типов и правил анализа для разных секторов на 20 языках (включая русский).

Примечание. На момент SPS7 (декабрь 2013 г.) все конфигурации кроме EXTRACTION_CORE_VOICEOFCUSTOMER поддерживают русский язык.

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

Положительные стороны текстового анализатора SAP HANA:

• Поддержка морфологии (слова «день» и «дни» имеют общую морфологическую основу)
• Широкая поддержка форматов файлов, включая бинарные объекты (txt, html, xml, pdf, doc, ppt, xls, rtf, msg)
• Идентификация выражений в лингвистических разметках (распознавание текста из xml)
• Классификация слов и выражений («Алексей Иванов» — «персона»)
• Работает нативно на SAP HANA (нет издержек передачи данных между системами)
• Поддержка большого числа языков
• Возможность создания своих конфигураций, словарей, таблиц синонимов
• Гибкие настройки текстового анализа (можно задавать приоритет весовых коэффициентов релевантности для лингвистического поиска более высокими, чем от нечеткого поиска)
• Поисковые наборы правил (Примечание. Хранимый в SAP HANA объект конфигураций, содержащий перечень условий, которые определяют, попадет ли та или иная запись таблицы в результат запроса. Применяется при выполнении запроса)
• Инструмент Info Access toolkit (Примечание. Инструмент предоставляет front-end JavaScript API и инструменты UI (в состав которых входят различные шаблоны и сниппеты) для быстрой разработки небольших браузерных приложений на основе поиска. Протокол передачи HTTP)

Недостатки текстового анализатора SAP HANA:

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

Как устроен анализ текста в SAP HANA

 

В SAP HANA используются офлайн- алгоритмы полнотекстового поиска, что означает, что вначале строится дополнительная структура — словарь токенов. В подготовку словаря входят следующие операции: нормализация, токенизация, стемминг, идентификация типа слова или выражения, определение части речи.

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

При создании индекса создается скрытая колонка, содержащая текстовые данные, извлеченные SAP HANA Preprocessor из выбранной колонки. Поисковые запросы выполняются на скрытой колонке, но текст возвращается из оригинальной. Также при включенном параметре текстового анализа (TEXT ANALYSIS ON) создается таблица с именем “$TA_<имя индекса>“ в той же схеме — в ней хранятся результаты текстового анализа. По размеру данная таблица может превышать размер оригинального документа. Ее можно использовать, к примеру, для автодополнения в поисковых полях приложения или для анализа документа. Поддерживает партицирование.

Полнотекстовый индекс создается автоматически для колонок с типом TEXT, SHORTTEXT. При этом нельзя удалить индекс (только вместе с колонкой); также после создания будет возможность переопределить только часть параметров (PHRASE INDEX RATIO, FUZZY SEARCH INDEX, LANGUAGE DETECTION). Для колонок с типами VARCHAR, NVARCHAR, ALPHANUM, CLOB, NCLOB, BLOB индекс создается вручную. В этом случае имеется возможность удалить только индекс.

Создание полнотекстового индекса

Полнотекстовый индекс создается для отдельной колонки в таблице только с поколоночным хранением. Синтаксис:

CREATE FULLTEXT INDEX <Имя индекса> ON <путь к таблице> (<название колонки>) [<список параметров>]

Через список параметров можно настроить тип синхронизации при обновлении. В полнотекстовом индексе существуют два типа синхронизации: синхронный (по умолчанию) и асинхронный. При синхронном обновлении текстовый препроцессор автоматически запускается сразу после обновления поля, и, соответственно, автоматически создается текстовый индекс. В это время нет возможности обновлять данные обрабатываемой таблицы (до завершения работы препроцессора). При асинхронном обновлении текстовый препроцессор не запускается сразу после обновления полей таблицы, и, следовательно, не блокирует таблицу. В данном случае вставка результата, полученного текстовым препроцессором, и вставка оригинальных данных не происходят в одно время. Соответственно, данные для полнотекстового поиска не будут доступны сразу после обновления таблицы. Для управления текстовым препроцессором асинхронно в SAP HANA используются менеджер очередей.

Следует отметить параметры FAST PREPROCESS и TEXT ANALYSIS. Первый из них определяет, должен ли текстовый препроцессор отработать в экспресс-режиме (по умолчанию включен). В этом режиме язык задается английским, лингвистический анализ пропускается, используется только токенизация. Не работает с бинарными объектами. Поддерживает не все типы поиска. Второй параметр отвечает за выполнение текстового анализа (некоторые опции, такие как конфигурация, требуют, чтобы он был включен). Если он включен — создается таблица “$TA_<имя индекса>“. Не сочетается с параметром FAST PREPROCESS ON.

Один из ключевых параметров — конфигурации: благодаря ему определяется логика построения словаря токенов. Конфигурации в текстовом анализе содержат группу настроек анализа текста: правила анализа, параметры процесса извлечения выражений, ссылки на стандартные словари, позволяющие производить классификацию слов и выражений по типам. В параметре CONFIGURATION определяется используемая конфигурация. Она может быть поставляемой SAP или пользовательской (во втором случае необходимо указать путь к.hdbtextconfig — конфигурационному файлу). Для работы параметра требуется установка TEXT ANALYSIS ON. Список преднастроенных конфигураций, поставляемых SAP, представлен в Таблице 1.

Название конфигурации	Описание конфигурации
LINGANALYSIS_BASIC	поддерживает токенизацию
LINGANALYSIS_STEMS	поддерживает токенизацию поддерживает стемминг
LINGANALYSIS_FULL	поддерживает токенизацию поддерживает стемминг поддерживает теги частей речи
EXTRACTION_CORE	извлекает типизированные выражения из неструктурированного текста (люди / организации / адреса). Наиболее подходящий в большинстве случаев
EXTRACTION_CORE_VOICEOFCUSTOMER	данная конфигурация расширена преднастроенными типами выражения и правилами для выявления настроения рынка (поддерживает различные речевые обороты, использует синтаксические шаблоны)

Таблица 1. Поставляемые SAP конфигурации текстового поиска

Примеры использования конфигурации TEXT ANALYSIS ON CONFIGURATION ‘EXTRACTION_CORE’

Пример 1. Требуется создать полнотекстовый индекс для таблицы A, в которой pdf-документы хранятся в колонке “pdf“, обновление индексов должно выполняться синхронно. Информация в документах хранится на английском и русском языках. Тогда следует выполнить следующую команду:

CREATE FULLTEXT INDEX ‘INDEX1’ ON ‘A’ (‘pdf’) FAST PREPROCESS OFF TEXT ANALYSIS ON SYNC LANGUAGE DETECTION (‘EN’,’RU’) MIME TYPE ‘application/pdf’

Пример 2. Требуется создать полнотекстовый индекс для таблицы A, в которой документы хранятся в колонке “pdf“. Известно, что к данным документам часто будут обращаться, используя нечеткий поиск, для того чтобы найти встречающиеся названия компаний. В данном случае создадим индекс следующей командой:

CREATE