Программировать или не программировать? В этом ли вопрос?

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

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

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

Однако в сфере расширенной аналитики (advanced analytics) ситуация противоположна: эта область находится в состоянии активного развития, в частности, такие направления, как глубокое обучение и распределенные алгоритмы для больших данных. Поэтому, чтобы получить максимум от данных, специалисты должны имеет возможность оперативно экспериментировать с новой функциональностью, написанной ими самими или их коллегами.

Следовательно, настоящий вопрос заключается не в том, какую парадигму выбрать, а в том, как добиться того, чтобы пользователи получили лучшее от обоих подходов: легкость многократного использования и универсальность. Безусловно, все сводится к открытости выбранной аналитической платформы. Разве мы можем ограничивать сегодняшних и завтрашних data scientists’ов визуальной средой, поддерживающей только один аналитический язык? Какой именно? По-настоящему открытая платформа, дает data scientists’ам возможность выбрать инструменты, обеспечивающие удобство работы, эффективное сотрудничество и применение уже имеющихся знаний, без необходимости изучать основы каждой парадигмы программирования, задействованной в вашей организации.

Далее мы расскажем о том, как платформа KNIME обеспечивает интеграцию различных технологий, объединяя языки программирования, такие как R и Python, и визуальную разработку SQL-кода. Кроме того, вы узнаете, как данная парадигма позволяет применять передовые разработки в области больших данных, а также множество JavaScript-библиотек для визуализации.

Аналитика. Модульная структура кода на R и Python

Наиболее важными скриптовыми языками программирования для анализа данных, безусловно, являются R и Python. На рисунке ниже показано, как код, написанный специалистами на двух этих языках, может быть интегрирован в среде KNIME. В этом примере на R реализована визуализация, а на Python – создание модели (не потому, что это обязательно хороший вариант, а просто чтобы продемонстрировать, что мы можем это сделать). Любой пользователь может взять этот шаблон и повторно его использовать, возможно, даже не заглядывая в код.

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

 

Подобная интеграция реализована также и для других языков, например, для Groovy и Matlab. В развитие некоторых из них вносит свой вклад постоянно активное сообщество KNIME.

ETL. Визуальный SQL

ETL (extract, transform, load; извлечение, преобразование, загрузка) обычно не привлекает особого внимания. Но в этой области наблюдается аналогичная ситуация: специалист может намного быстрее написать несколько строк SQL-кода, чем собрать вместе несколько модулей в графической среде. Тем не менее, не все пользователи свободно владеют SQL. Такие пользователи также должны иметь возможность свободно манипулировать данными и использовать всю функциональность SQL (с учетом различных нюансов при работе с разными базами данных).

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

На рисунке ниже показан пример шаблона, в рамках которого выполняется чтение двух таблиц из базы данных, а затем их соединение после нескольких операций агрегации. Следует отметить, что этот набор узлов будет выполнен не в самой среде KNIME, а отправлен на выполнение в СУБД. То есть среда KNIME неявно формирует соответствующий SQL-оператор (его можно увидеть в окне просмотра узла (node view)). И чтобы еще больше облегчить процесс, в зависимости от типа узла-коннектора, KNIME обеспечивает доступность только поддерживаемых операций (например, для узла агрегации) и формирует подходящий SQL-диалект для базы банных.

Большие данные. Обертка для Hadoop

Визуальный подход к SQL, описанный выше, также позволяет моделировать и управлять ETL-операциями непосредственно в Hadoop. При использовании сертифицированных коннекторов для Cloudera, Hortonworks или MapR весь процесс реализуется точно так же, как если бы операции выполнялись в вашей локальной базе данных MySQL, но, на самом деле, они выполняются в Hadoop. Зачем же останавливаться на этом? Если мы имеем доступ к R, Python и SQL, то почему же тогда не добавить узлы, позволяющие выполнять код непосредственно в Hadoop? Начиная с версии 2.12, в KNIME присутствуют узлы, инкапсулирующие вызовы MLlib и операции Spark. Новую функциональность обеспечивает специальный скриптовый узел для работы со Spark.

Визуализация. JavaScript – четвертый мушкетер

И, наконец, вместо того, чтобы создавать новую библиотеку для визуализации, компания KNIME недавно представила JavaScript-узел, который создает визуализации с помощью различных библиотек. На рисунке ниже показан пример визуализации, созданной посредством популярной библиотеки D3. Аналогичным образом можно работать и с другими библиотеками. При этом одной из полезных особенностей данной концепции является то, что результирующие узлы также могут быть использованы для отображения визуализаций в веб-портале KNIME (KNIME WebPortal). Это позволяет применять интерактивные элементы управления рабочим процессом на основе веб-интерфейса, в результате чего мы получаем полноценную управляемую аналитику (guided analytics). Но это уже тема для другой статьи.

 

По материалам: KNIME

Добавить комментарий

Ваш адрес email не будет опубликован.

закрыть

Поделиться

Отправить на почту
закрыть

Вход

закрыть

Регистрация

+ =