Научная статья на тему 'Текстовый поиск. Работа с неструктурированными данными'

Текстовый поиск. Работа с неструктурированными данными Текст научной статьи по специальности «Автоматика. Вычислительная техника»

CC BY
281
121
Поделиться

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Андрей Александрович Коновалов,

Текст научной работы на тему «Текстовый поиск. Работа с неструктурированными данными»

А.А. Коновалов

ТЕКСТОВЫЙ ПОИСК. РАБОТА С НЕСТРУКТУРИРОВАННЫМИ ДАННЫМИ

Андрей Александрович Коновалов

Сертифицированный консультант SAP HANA, Я ' " БДО Юникон Бизнес Солюшнс.

Ш Закончил Северо-Кавказский государственный

« ' Щ технический университет по специальности

■ ” м «Автоматизированные системы обработки

V ш информации и управления».

Принимал участие в проектах по SAP HANA, SAP BW, SAPUI5.

А.А. Коновалов. Текстовый поиск. Работа с неструктурированными данными

117

ВВЕДЕНИЕ

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

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

• нормативная справочная информация, почта;

• договоры, данные о клиентах (CRM);

• схемы, сметы, акты;

• записи колл-центра;

• страницы сайтов, статьи, форумы, блоги.

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

• извлечение, идентификация, структурирование и анализ содержимого;

• возможность оперативной обработки большого объема данных;

• стойкий к ошибкам поиск;

• комбинирование структурированной информации с неструктурированной;

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

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

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

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

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

• Что пользователи действительно думают о продукте

• Как клиенты откликнулись на последнюю рекламную кампанию

• Каковы основные причины неудачи (программный, аппаратный, обслуживание)

• Какие имеются ключевые проблемы с новым продуктом на базе записей колл-центра.

118

SAP HANA

Технологическая платформа для решения современных бизнес-задач

ПРИМЕНЕНИЕ ОПЕРАТОРА LIKE В ТЕКСТОВОМ ПОИСКЕ

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

• Ошибкоустойчивый поиск (поиск имени продукта “saphana" -> “sap hana“)

• В сравнении с оператором LIKE не так критичен порядок слов, а также регистр

• Извлечение данных из бинарных объектов

• Возможность лингвистического поиска по описанию продуктов («компанию» -> «компания»)

• Результаты с соответствующими весовыми коэффициентами релевантности (можно сортировать по релевантности)

• Поиск с синонимами (“Ltd" -> “Limited")

• Использование стоп-слов (слова-паразиты не будут учитываться).

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

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

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

• Поддержка морфологии (слова «день» и «дни» имеют общую морфологическую основу)

• Широкая поддержка форматов файлов, включая бинарные объекты (txt, html, xml, pdf, doc, ppt, xls, rtf, msg)

• Идентификация выражений в лингвистических разметках (распознавание текста из xml)

• Классификация слов и выражений («Алексей Иванов» — «персона»)

• Работает нативно на SAP HANA (нет издержек передачи данных между системами)

• Поддержка большого числа языков

• Возможность создания своих конфигураций, словарей, таблиц синонимов

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

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

А.А. Коновалов. Текстовый поиск. Работа с неструктурированными данными

119

• Гибкие настройки текстового анализа (можно задавать приоритет весовых коэффициентов релевантности для лингвистического поиска более высокими, чем от нечеткого поиска)

• Поисковые наборы правил1

• Инструмент Info Access toolkit1 2.

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

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

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

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

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

При создании индекса создается скрытая колонка, содержащая текстовые данные, извлеченные 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 <путь к таблице> (<название колонки>) [<список параметров>]

1 Хранимый в SAP HANA объект конфигураций, содержащий перечень условий, которые определяют, попадет ли та или иная запись таблицы в результат запроса. Применяется при выполнении запроса.

2 Инструмент предоставляет front-end JavaScript API и инструменты UI (в состав которых входят различные шаблоны и сниппеты) для быстрой разработки небольших браузерных приложений на основе поиска. Протокол передачи HTTP.

3 Все буквы переводятся в единый (например, верхний) регистр.

4 Разбивка текста на отдельные слова и выражения — ключи словаря.

5 Позволяет определить морфологическую основу.

120

SAP HANA

Технологическая платформа для решения современных бизнес-задач

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

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

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

Название конфигурации Описание конфигурации

LINGANALYSIS_BASIC поддерживает токенизацию

LINGANALYSIS_STEMS поддерживает токенизацию поддерживает стемминг

LINGANALYSIS_FULL поддерживает токенизацию поддерживает стемминг поддерживает теги частей речи

А.А. Коновалов. Текстовый поиск. Работа с неструктурированными данными

121

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 FULLTEXT INDEX ‘INDEX1' ON ‘A' (‘pdf') FAST PREPROCESS OFF TEXT ANALYSIS ON LANGUAGE DETECTION (‘EN','RU') MIME TYPE ‘application/pdf' CONFIGURATION ‘EXTRACTION CORE' FUZZY SEARCH INDEX ON

Формирование SQL-запроса

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

SELECT * FROM <путь к таблице> WHERE CONTAINS (<имя колонки>, <искомая фраза>, <тип поиска>)

В полнотекстовом поиске SAP HANA используются три типа поиска: EXACT (по умолчанию), LINGUISTIC, FUZZY.

122

SAP HANA

Технологическая платформа для решения современных бизнес-задач

Тип поиска EXACT вернет строку, только если она полностью содержит искомую.

При использовании типа LINGUISTIC производится поиск с учетом морфологической основы слова. Наиболее гибкий тип, FUZZY, также называется нечетким поиском; он, в отличие от вышеописанных типов, стоек к ошибкам. К примеру, при неправильном входящем слове «нармотинвый» в результате будет найдено слово «нормативный» (если оно есть в соответствующий колонке и коэффициент соответствия удовлетворяет заданному). Данный тип поиска можно использовать как к колонкам с созданным полнотекстовым индексом, так и без него, для следующих типов: VARCHAR, NVARCHAR, DATE. При этом типе поиска определяется степень соответствия сравниваемых выражений. Степень соответствия зависит от многих факторов (таких как способ сравнения). Также механизм работы данного поиска зависит от типа колонки, на которой проводится поиск. Для строковых типов (VARCHAR, NVARCHAR) строка сравнивается с искомой с использованием нечеткой логики. Для текстовых типов механизм немного сложнее — искомая строка сравнивается с терминами, полученными в результате токенизации. Для дат FUZZY-поиск проверяет значения на специфичные для этого типа ошибки (неверный формат даты). Общий синтаксис для FUZZY-поиска:

SELECT * FROM <путь к таблице> WHERE CONTAINS (<имя колонки>, <искомая фраза>, fuzzy (<нижний порог толерантности к ошибкам>, <другие параметры>))

Также в FUZZY-поиске присутствуют зарезервированные слова / специальные символы (таблица 2).

Зарезервированные слова/специальные символы Описание Пример Описание примера

OR Логический оператор ИЛИ CONTAINS (col, ‘sap OR hana’) Ищет “sap" или “hana"

— Оператор вычитание CONTAINS (col,’sap-hana’) Поиск всех записей, где есть “sap", но нет“hana"

мм Поиск фразы CONTAINS (col, ‘“sap hana"’) Поиск фразы “sap hana" (а не отдельных слов)

*,% Использование шаблона для поиска1 CONTAINS (col, ‘*.txt’) Поиск всех записей, где упоминаются текстовые файлы

Таблица 2. Зарезервированные слова и символы в операторе CONTAINS

1 Замещает нечеткий поиск.

А.А. Коновалов. Текстовый поиск. Работа с неструктурированными данными

123

Пример 3. Требуется создать запрос к таблице B, результат которого содержит все поля таблицы и весовые коэффициенты релевантности запроса. В результирующие строки должны попасть записи, у которых в поле “TEXT" содержится фраза “SAP HANA", чувствительность к ошибкам — 0,7. Данный запрос выглядит следующим образом:

SELECT *, SCORE () AS RELEVANCE FROM “B“ WHERE CONTAINS (TEXT, ‘“SAP HANA“', fuzzy (0.7));

Доступные функции для FUZZY-поиска:

• SNIPPETS — предоставляет контекст в виде текста (показывает первое вхождение), искомые слова выделяет тегом bold. Возвращаемый текст ограничен 12 токенами. Общий синтаксис:

SELECT *, SNIPPETS (‘колонка') FROM <путь к таблице> WHERE CONTAINS (<имя колонки^ <искомая фраза>, FUZZY (<набор параметров>)

• HIGHLIGHTED — аналогичен функции SNIPPETS (также выделяет тегом bold искомое слово). Разница заключается в том, что ищет только первое слово из фразы и возвращает все совпадения в тексте1.

• SCORE — возвращает степень соответствия. Рассчитывается исходя из:

1) релевантности или весов атрибутов (которые настраиваются через contains или через view);

2) коэффициент в нечетком поиске (чем больше совпадений, тем он больше);

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

Пример 4. Требуется создать процедуру с входным параметром “varC“ (искомая фраза). Имя таблицы “tabA“, колонка “TEXT". Необходимо получить результат либо через нечеткий поиск с нижним порогом 0,7, либо через лингвистический поиск. При этом результаты через лингвистический поиск более приоритетные. Тогда следует воспользоваться следующей конструкцией:

SELECT “TEXT“, SCORE () AS RELEVANCE FROM “tabA“ WHERE CONTAINS (TEXT,: varC, FUZZY (0.7), WEIGHT (0.4)) OR CONTAINS (TEXT,: varC, LINGUISTIC, WEIGHT (0.5))

Пример 5. Имеется таблица “tabA“ с колонкой “PDF“. Необходимо получить все документы, где упоминается «Петр Иванов», и контекст упоминания. В этом случае вы напишете:

1 При поиске в больших текстах может вернуть большой объем данных.

124

SAP HANA

Технологическая платформа для решения современных бизнес-задач

SELECT *, SNIPPETS (“PDF“) FROM “tabA“ WHERE CONTAINS (PDF, ‘“Петр Иванов1", fuzzy (0.8))

Системные view, связанные с текстовым поиском и индексацией, представлены в таблице 3.

Monitoring view Описание

SYS.FULLTEXT_INDEXES Таблица полнотекстовых индексов в системе

SYS.M_FULLTEXT_QUEUES Таблица очередей для полнотекстовых индексов

SYS.M_TEXT_ANALYSIS_LANGUAGES Таблица кодов языков

SYS.M_TEXT_ANALYSIS_MIME_TYPES Таблица MIME-типов

SYS.M_FUZZY_SEARCH_INDEXES Таблица потребления памяти индексами нечеткого поиска

SYS.M_HEAP_MEMORY Таблица использования памяти в системе

Таблица 3. Список системных view

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

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

Алгоритм работы пользователя с приложением:

1. Заходит через веб-браузер в приложение.

2. Вводит данные для поиска.

3. Получает список документов, отсортированных по релевантности.

4. Выбирает документ и категорию.

5. Получает искомый список.

Механизм взаимодействия клиентских и серверных частей приложения представлен на рисунке 1.

Рассмотрим часть подготовки модели данных этого приложения. Для поиска документов создадим таблицу “TDoc“ с колонкой для хранения бинарных объектов “BLOB". На колонке построим полнотекстовый индекс. Используем таблицу “$TA_<INDEXNAME>“, построенную в процессе создания полнотекстового индекса, для поиска категорий.

А.А. Коновалов. Текстовый поиск. Работа с неструктурированными данными

125

Клиент Сервер

Поиск документов )

Искомая фраза

Список документов

Поиск слов по категории )

Номер документа, категория

Список слов

Клиент Сервер

Рисунок 1. Взаимодействие клиентской и серверной частей приложения

Таблица “TDoc“ будет состоять из колонок “ID” (ключ), “NAME” (имя документа),

“DOC” (содержимое документа), “MIMECOLUMN” (MIME-тип файла). MIME-тип файла указывается, так как предполагается хранение файлов различных типов. Выполним инструкцию:

CREATE COLUMN TABLE “SCHEMANAME“.“TDoc“ (

“ID“ INTEGER CS_INT NOT NULL,

“NAME“ NVARCHAR (240) NOT NULL,

“DOC“ BLOB MEMORY THRESHOLD 1000,

“MIMECOLUMN" NVARCHAR (100),

PRIMARY KEY (“ID“)) UNLOAD PRIORITY 5 AUTO MERGE где “SCHEMANAME” — имя схемы, в которой будет создана таблица ”TDoc”.

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

CREATE FULLTEXT INDEX “FULLTEXT_DOC“ ON “SCHEMANAME“.“TDoc“ (“DOC“)

MIME TYPE COLUMN “MIMECOLUMN“

CONFIGURATION ‘EXTRACTION_CORE'

ASYNC

LANGUAGE DETECTION (‘EN','RU')

126

SAP HANA

Технологическая платформа для решения современных бизнес-задач

FUZZY SEARCH INDEX ON FAST PREPROCESS OFF TEXT ANALYSIS ON

TOKEN SEPARATORS () [] <>!?*@+ {} =«&'

где “FULLTEXT_DOC“ — название индекса.

Проверить созданный индекс мы можем через запрос (должна вернуться запись с нашим индексом):

select * from SYS.FULLTEXT_INDEXES where INDEX_NAME = ‘FULLTEXT_DOC'

Также после построения индекса должна присутствовать таблица “$TA_FULLTEXT_ DOC“ в той же схеме, где расположена таблица. Проверить ее наличие можно прямым обращением к ней:

select * from “SCHEMANAME“.“$TA_FULLTEXT_DOC“

Пример запроса по поиску документа через нечеткую логику с получением контекста употребления, результат отсортирован по релевантности (поиск фразы “sap hana”):

select ID, TO_DECIMAL (SCORE (),3,2) AS score, “NAME“, SNIPPETS (“DOC“)

FROM “SCHEMANAME“.“TDoc“

WHERE CONTAINS (“DOC“,'“sap hana“', FUZZY (0.6, ‘textSearch=fulltext'))

ORDER BY score DESC

Пример запроса для поиска всех продуктов (категория “PRODUCT") по документу с идентификатором 5:

select distinct “TA_TOKEN“ from “SCHEMANAME“.“$TA_FULLTEXT_DOC“ where “ID“ = ‘5' AND “TA TYPE“ = ‘PRODUCT'

ИНФОРМАЦИОННЫЕ РЕСУРСЫ

1. http://help.sap.com/hana/SAP_HANA_Developer_Guide_en.pdf

2. http://help.sap.com/hana/SAP_HANA_Text_Analysis_Language_Reference_Guide_en.pdf

3. http://www.informationweek.com/software/information-management/structure-models-and-meaning/d/d-id/1030187

4. http://habraha br.ru/pos t/114997/