Бруно Эдох

В связи с огромным объемом данных, которые генерируются каждый день, растет потребность в организации и извлечении данных еще более эффективными способами. Qlik предоставляет несколько отличных инструментов для работы с данными, таких как QlikView, Qlik Core, Picasso.js и Qlik Big Data Index, и это лишь некоторые из них.

В этой статье мы рассмотрим некоторые подводные камни запросов данных и то, как Qlik становится необходимым решением в этом процессе.

Что такое запрос данных?

Проще говоря, запрос данных — это вопрос о фрагменте данных. Обычно мы запрашиваем данные, хранящиеся в базе данных (например, MySQL, SQLite). С запросами данных мы можем задавать такие вопросы, как: У какого пользователя есть идентификатор 1234? Хранится ли следующий хэш пароля в нашей базе данных? Какой адрес электронной почты связан с пользователем X?

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

Подводные камни запроса данных

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

Выделение всех столбцов звездочками

Очень часто можно встретить SQL-запросы, в которых используются звездочки для выбора всех столбцов:

чрезвычайно удобен в использовании; тем не менее, существует немало опасностей, связанных с таким использованием звездочки. Во-первых, если таблица содержит какие-либо конфиденциальные пользовательские данные, такие как информация о кредитной карте, запрос раскрывает данные. Рискованно, правда? Во-вторых, использование звездочек снижает производительность — чем меньше столбцов нужно вернуть, тем быстрее обрабатывается запрос. Способ справиться с этим - указать желаемый столбец (столбцы), который должен быть возвращен:

Запрос данных без ограничений

Базы данных могут хранить огромные объемы данных — в некоторых случаях тысячи, если не миллионы байтов. Запрос к такой базе данных даст такой же большой объем данных, что приведет к медленному ответу. Понятно, что неэффективно. И, конечно же, никому не нравится ждать хотя бы пару секунд, пока запрос вернет результаты. По возможности, возвращаемые данные должны быть ограничены. Команда LIMIT очень удобна: она ограничивает количество результатов запроса.

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

Спагетти-запрос

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

Нулевая ловушка

NULL является одним из основных источников путаницы в SQL. NULL означает отсутствие значения. Это связано с тем, что NULL в SQL — это не то же самое, что ноль, пустая строка или ложь, как в некоторых языках программирования. Обратите внимание, что есть некоторые исключения из этого различия. Важно знать, как интерпретируется NULL, поскольку некоторые запросы могут привести к неожиданным результатам.

Осторожнее с подзапросами

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

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

Подход Qlik к отказу от написания запросов данных

У самых опытных разработчиков иногда возникают проблемы с запросами данных. Вот где Qlik пригодится. QlikView — мощная платформа для бизнес-обнаружения, упрощающая работу с данными (анализ, визуализация и т. д.). Самое интересное, что QlikView помогает разработчикам избежать написания запросов к данным и, как следствие, избежать ловушек, связанных с записью данных. запросы.

Ранее мы рассмотрели некоторые подводные камни запросов данных. Теперь мы увидим, как использовать QlikView, чтобы предотвратить эти и другие ловушки запросов данных.

Запрос без написания запроса

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

В QlikView нажмите ФайлРедактировать сценарийВыберите «Подключиться» на нижней панели. Выбрать источник данных. Сразу за вас пишется команда загрузки данных. Кнопка «Выбор» на нижней панели позволяет создавать операторы SELECT, выбирая поля данных для работы.

Пример запроса SELECT, сгенерированный редактором скриптов

Ограничьте результат

Иногда может потребоваться ограничить количество записей, получаемых в результате запроса. Это предполагает, что перед оператором LOAD непосредственно ставится FIRST, за которым следует предел результата. Если вас интересуют первые 10 элементов, напишите ПЕРВЫЕ 10 перед ЗАГРУЗИТЬ. Повторная загрузка запроса загружает только первые 10 записей.

Ограничение количества возвращаемых записей также можно выполнить в режиме отладки Debug.

Разбивайте сложные запросы на более мелкие запросы

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

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

Заключительные мысли

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

*****

Об авторе

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