Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Data Science
Code

Data Science и аналитика для бизнеса: проблемы и решения

by
Length:LongLanguages:

Russian (Pусский) translation by Marat Amerov (you can also view the original English article)

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

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

Перспективы отдела

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

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

Потребности IT

Давайте начнем с рассмотрения типичной инфраструктуры данных для ИТ и разработки программного обеспечения.

Что касается данных, есть три важных предварительных условия, на которых должен сосредоточиться любой ИТ-отдел:

  • данные, которые являются безопасными
  • данные, которые являются эффективными
  • данные, которые являются консистентными

Из-за этого большая часть ИТ использует схемы на основе таблиц и часто использует SQL (язык структурированных запросов) или один из его вариантов.

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

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

Давайте посмотрим, чем отличается Data Science.

Потребности Data Science

С другой стороны, Data Science имеет другой набор потребностей. Data Scientist'ы нуждаются в свободе передвижения со своими данными и гибкости для быстрого изменения своих данных. Они должны иметь возможность перемещать данные нестандартными способами и обрабатывать большие объемы одновременно.

Эти потребности трудно реализовать с использованием высокоструктурированных баз данных. Data Science требует другой инфраструктуры, полагаясь вместо этого на неструктурированные данные и схемы без таблиц.

Когда речь идет о неструктурированных данных, мы говорим о данных без внутреннего определения. Это туманно, пока форма не задана Data Scientist'ом. Для большинства разработок каждое поле должно быть определенного типа, например, целое число или строка. Однако для Data Science речь идет о поддержке точек данных, которые плохо определены.

Схемы без таблиц добавляют больше универсальности к этой квази-хаотической установке, позволяя всей информации жить в одном месте. Это особенно полезно для Data Scientist'ам, которым регулярно нужно объединять данные творческим и неструктурированным способом. Популярные варианты включают варианты или структуры NoSQL, которые допускают несколько измерений, например кубы OLAP.

В результате аппаратное обеспечение, требуемое для Data Science, часто является более существенным. Оно должно содержать всю используемую информацию, а также подмножества этих данных (хотя это часто распределяется между несколькими структурами или службами). Аппаратное обеспечение также может потребовать значительных ресурсов обработки, поскольку большие объемы данных перемещаются и агрегируются.

Дистилляция нуждается в действии

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

Простота манипулирования данными

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

Когда для обычной задачи может потребоваться объединение множества таблиц, преимущества структур на основе таблиц становятся менее очевидными. Популярный способ справиться с этим - реализовать вторичную NoSQL или многомерную базу данных. Эта вторичная база данных использует обычное ETL (Extract, Transform, Load), чтобы сохранить свою информацию актуальной. Это увеличивает стоимость дополнительного оборудования или использования облачных сервисов, но сводит к минимуму любые другие недостатки.

Имейте в виду, что в некоторых случаях добавление отдельной базы данных для Data Science может быть более доступным, чем использование одной и той же базы данных (особенно, когда возникают сложные вопросы лицензирования).

Простота масштабирования данных

Эта конкретная проблема охватывает два упомянутых несоответствия:

  1. регулярное увеличение данных процедурами
  2. необходимость неструктурированных типов данных

В традиционных информационных технологиях размер вашей базы данных четко определен, либо остается неизменным, либо растет скромными темпами. При использовании базы данных для Data Science этот рост может быть экспоненциальным. Распространено добавления гигабайтов данных каждый день (или больше). При огромном размере данных такого рода бизнес должен будет включить план масштабирования внутренней архитектуры или использовать соответствующее облачное решение.

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

Использование ресурсов

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

С традиционной ИТ-инфраструктурой проблем не возникнет, если в проекте используется всего несколько сотен строк из нескольких таблиц. Но проект, который требует каждую строку из двух десятков таблиц, может быстро стать проблемой. В Data Science потребности в обработке и хранении меняются от проекта к проекту, и такую ​​непредсказуемость может быть трудно поддерживать.

В традиционным ИТ, ресурсы могут совместно использоваться другими сторонами, которые могут быть действующей продакшин-площадкой или внутренней командой разработчиков. Риск здесь заключается в том, что запуск крупномасштабного проекта по Data Science может потенциально заблокировать других пользователей на некоторое время. Другой риск заключается в том, что серверы, на которых хранится база данных, могут не справиться с необходимыми объемами обработки. Вызов 200 000 строк из 15 таблиц и запрос на агрегацию данных сверху становятся проблемой. Такая величина запросов может быть чрезвычайно сложной для сервера, который обычно обрабатывает около тысячи пользователей одновременно.

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

Итак, каков окончательный список требований к обоим сторонам?

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

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

Создание кейса для Data Science

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

Исследование спецификаций

Со стороны ИТ, есть три основных определения, необходимых для создания необходимой инфраструктуры. Это:

  1. объём данных
  2. в какой степени он нуждается в обработке
  3. как данные попадут в хранилище

Вот как вы можете определить каждое из них.

Потребность в хранении данных

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

Для ваших первоначальных потребностей в данных, возьмите определенный размер вашей текущей базы данных. Теперь вычтите все столбцы или таблицы, которые вам не понадобятся в ваших проектах на Data Science. Возьмите это число и добавьте размер данных любых новых источников, которые вы будете вводить. Новые источники могут включать данные Google Analytics или информацию из вашей системы Point of Sale. Эта сумма будет хранилищем данных, которое мы будем стремиться получить заранее.

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

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

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

Потребность в ресурсах для обработки

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

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

ETL (извлечение, преобразование, загрузка) процессов

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

Вот что вы должны иметь в своей документации ETL:

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

Подготовка решения

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

Трое из крупнейших облачных решений - Amazon Web Services (AWS), Google Cloud Platform (GCP) и Microsoft Azure - предлагают одни из лучших цен и возможностей. Все три имеют относительно схожие затраты, хотя для AWS значительно сложнее рассчитать затраты (из-за структуры ценообразования по).

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

Тем не менее, многие компании просто выбирают то, что соответствует их существующему технологическому стеку.

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

Дополнительные советы для плавной реализации

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

Проверьте свой ETL-процесс

Когда вы впервые соберете свой ETL-процесс, не тестируйте все сразу! Это может создать серьезную нагрузку на ваши ресурсы и резко увеличить ваши облачные затраты, если произошла ошибка, или если вам придется повторить попытку несколько раз.

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

Проверяйте свои запросы тщательно

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

Создайте стратегию резервного хранилища

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

Проблемы безопасности и конфиденциальности

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

Наименование измерений во время ETL

При выполнении ETL из табличной базы данных в неструктурированную базу данных будьте осторожны с процедурами именования. Если имена переносятся только оптом, у вас, вероятно, будет много полей из разных таблиц, имеющих одно и то же имя. Простой способ преодолеть это сначала - назвать новые измерения в неструктурированной базе данных как {oldtablename}_{columnname}, а затем переименовать их оттуда.

Запустите свой движок!

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

Сложно придумать ответы для своей компании? Я замаскировал что-то важное? Дай мне знать в комментариях!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.