Поскольку все больше компаний осознают важность науки о данных и передовой аналитики для своей прибыли, началось столкновение культур. Как эти быстрорастущие месторождения могут стать частью экосистемы компании, особенно для устоявшихся компаний, которые существуют уже десять лет или дольше?
Специалисты по обработке данных и ИТ-специалисты имеют совершенно разные потребности в инфраструктуре. Здесь я изложу некоторые из этих требований и расскажу, как выйти за их пределы и развиваться вместе.
Департамент Перспективы
При запуске программ по науке о данных в компаниях самые большие проблемы часто возникают не из-за самой технологии, а из-за простого недопонимания. Межведомственные заблуждения могут привести к серьезному недовольству между начинающими группами по науке о данных и ИТ-отделами.
Чтобы бороться с этим, мы рассмотрим обе перспективы и учтем все их потребности. Мы начнем с определения того, что требуется ИТ-специалисту для поддержания успешного рабочего процесса, а затем посмотрим, что нужно специалисту по данным для максимальной эффективности. Наконец, мы найдем общий язык: как использовать его для реализации здоровой инфраструктуры для процветания обоих.
ИТ-потребности
Давайте начнем с рассмотрения типичной инфраструктуры данных для ИТ и разработки программного обеспечения.
Что касается данных, есть три важных предварительных условия, на которых должен сосредоточиться любой ИТ-отдел:
- данные, которые являются безопасными
- данные, которые являются эффективными
- данные, которые соответствуют
Из-за этого большая часть ИТ использует схемы на основе таблиц и часто использует SQL (язык структурированных запросов) или один из его вариантов.
Эта настройка означает, что для каждой цели существует большое количество таблиц. Каждая из этих таблиц отделена друг от друга внешними ключами, связывающими их. Благодаря этой настройке запросы могут выполняться быстро, эффективно и с учетом требований безопасности. Это важно для разработки программного обеспечения, где данные должны оставаться нетронутыми и надежными.
При такой структуре требуемое оборудование часто минимально по сравнению с потребностями науки о данных. Сохраненные данные четко определены и развиваются в предсказуемом темпе. Мало данных повторяется, и процесс запроса уменьшает количество необходимых ресурсов обработки.
Давайте посмотрим, как наука о данных отличается.
Наука о данных нуждается
С другой стороны, наука о данных имеет другой набор потребностей. Исследователи данных нуждаются в свободе передвижения со своими данными и гибкости для быстрого изменения своих данных. Они должны иметь возможность перемещать данные нестандартными способами и обрабатывать большие объемы одновременно.
Эти потребности трудно реализовать с использованием высокоструктурированных баз данных. Наука о данных требует другой инфраструктуры, полагаясь вместо этого на неструктурированные данные и схемы без таблиц.
Когда речь идет о неструктурированных данных, мы говорим о данных без внутреннего определения. Это туманно до тех пор, пока не получит данные от ученого. Для большинства разработок каждое поле должно быть определенного типа, например, целое число или строка. Однако для науки о данных речь идет о поддержке точек данных, которые плохо определены.
Схемы без таблиц добавляют больше гибкости к этой квази-хаотической установке, позволяя всей информации жить в одном месте. Это особенно полезно для ученых-данных, которым регулярно нужно объединять данные творческим и неструктурированным способом. Популярные варианты включают варианты или структуры NoSQL, которые допускают несколько измерений, например кубы OLAP.
В результате аппаратное обеспечение, требуемое для науки о данных, часто является более существенным. Он должен содержать всю используемую информацию, а также подмножества этих данных (хотя это часто распределяется между несколькими структурами или службами). Аппаратное обеспечение также может потребовать значительных ресурсов обработки, поскольку большие объемы данных перемещаются и агрегируются.
Дистилляция потребностей в действии
Имея в виду эти два набора потребностей, теперь мы можем видеть, как может происходить недопонимание. Давайте рассмотрим эти перспективы и используем их, чтобы определить, какие изменения мы ищем и как. Какие проблемы необходимо решить, если перенести науку о данных в традиционные ИТ-среды?
Простота манипулирования данными
В традиционной ИТ-среде базы данных любой конкретной организации, вероятно, следуют жесткой структуре с таблицами, разделенными в соответствии с конкретными потребностями, соответствующей схемой для определения каждого фрагмента данных и внешними ключами, связывающими их все вместе. Это делает для эффективной системы запроса данных. Исследовательская природа некоторых методов науки о данных может довести это до предела.
Когда для обычной задачи может потребоваться объединение дюжины или более таблиц, преимущества структур на основе таблиц становятся менее очевидными. Популярный способ справиться с этим — реализовать вторичную NoSQL или многомерную базу данных. Эта вторичная база данных использует обычные ETL (Extract, Transform, Load), чтобы сохранить свою информацию свежей. Это добавляет стоимость дополнительного оборудования или использования облачных сервисов, но сводит к минимуму любые другие недостатки.
Имейте в виду, что в некоторых случаях добавление отдельной базы данных для науки о данных может быть более доступным, чем использование той же базы данных (особенно, когда возникают сложные вопросы лицензирования).
Простота масштабирования данных
Эта конкретная проблема охватывает два упомянутых несоответствия:
- регулярное увеличение данных от процедур
- необходимость неструктурированных типов данных
В традиционных информационных технологиях размер вашей базы данных четко определен, либо остается неизменным, либо растет в умеренном темпе. При использовании базы данных для науки о данных этот рост может быть экспоненциальным. Распространено добавлять гигабайты данных каждый день (или больше). При огромном размере данных такого рода бизнес должен будет включать план масштабирования внутренней архитектуры или использовать соответствующее облачное решение.
Что касается неструктурированных данных, они могут занимать много ресурсов с точки зрения хранения и вычислительной мощности, в зависимости от вашего конкретного использования. Из-за этого часто неэффективно хранить все это в базе данных, которая может использоваться для других целей. Решение похоже на масштабирование в целом. Нам либо понадобится план для масштабирования нашей внутренней архитектуры, чтобы удовлетворить эти потребности, либо нам нужно будет найти подходящее облачное решение.
Использование ресурса
Последнее существенное отличие, о котором мы поговорим, — это использование ресурсов. Для ИТ использование ресурсов обычно эффективно, четко определено и согласовано. Если база данных поддерживает сайт электронной коммерции, существуют известные ограничения. ИТ-специалист будет примерно знать, сколько пользователей будет в течение определенного периода времени, поэтому они могут планировать предоставление оборудования на основе того, сколько информации необходимо для каждого пользователя.
С традиционной ИТ-инфраструктурой проблем не возникнет, если в проекте используется всего несколько сотен строк из нескольких таблиц. Но проект, который требует каждую строку из двух десятков таблиц, может быстро стать проблемой. В науке о данных потребности в обработке и хранении меняются от проекта к проекту — и такую непредсказуемость может быть трудно поддерживать.
В традиционных ИТ-ресурсах ресурсы могут совместно использоваться другими сторонами, которые могут быть действующей производственной площадкой или внутренней командой разработчиков. Риск здесь заключается в том, что запуск крупномасштабного проекта по науке о данных может потенциально заблокировать других пользователей на некоторое время. Другой риск заключается в том, что серверы, на которых хранится база данных, могут не справиться с необходимыми объемами обработки. Вызов 200 000 строк из 15 таблиц и запрос агрегации данных сверху становятся проблемой. Такая величина запросов может быть чрезвычайно сложной для сервера, который обычно обрабатывает около тысячи пользователей одновременно.
Идеальное решение сводится к облачной обработке. Это касается двух ключевых факторов. Во-первых, это позволяет выполнять запросы от любых важных баз данных. Второе — это то, что он предоставляет ресурсы масштабирования, которые могут соответствовать каждому проекту.
Итак, каков окончательный список требований к обоим?
Теперь, когда мы подробно поговорили о потребностях, давайте подведем их итоги. Для долгосрочного успеха отделу информационных технологий и информационных технологий потребуется следующее:
- отдельная база данных, чтобы уменьшить влияние на другие заинтересованные стороны
- масштабируемое решение для хранения данных с учетом изменений в данных
- решение для масштабирующей обработки с учетом различных типов проектов
- неструктурированная база данных для эффективного поиска и хранения сильно меняющихся данных
Создание аргумента для науки о данных
Давайте разберем все по спецификациям, чтобы мы могли составить взаимовыгодное решение. Теперь мы рассмотрим, как определить конкретные ресурсы, необходимые для организации:
Исследование спецификаций
Со стороны ИТ есть три основных определения, необходимых для создания необходимой инфраструктуры. Эти:
- количество данных
- в какой степени он нуждается в обработке
- как данные попадут в хранилище
Вот как вы можете определить каждый.
Потребность в хранении данных
Все начинается с необходимого начального размера данных и предполагаемых текущих добавлений данных.
Для ваших первоначальных потребностей в данных, возьмите определенный размер вашей текущей базы данных. Теперь вычтите все столбцы или таблицы, которые вам не понадобятся в ваших проектах по науке о данных. Возьмите это число и добавьте размер данных любых новых источников, которые вы будете вводить. Новые источники могут включать данные Google Analytics или информацию из вашей системы Point of Sale. Это общее количество будет хранилищем данных, которое мы будем стремиться получить заранее.
Хотя первоначальные потребности в хранилище полезны заранее, вам все равно придется учитывать текущие потребности в данных — поскольку вы, вероятно, со временем добавите больше информации в базу данных. Чтобы узнать эту информацию, вы можете рассчитать свои ежедневные добавленные данные из ваших текущих доступных данных. Посмотрите, сколько информации было добавлено в вашу базу данных за последние 30 дней, а затем разделите ее на 30. Затем повторите это для каждого источника информации, который вы будете использовать, и сложите их вместе.
Хотя это не совсем точно, есть старая мантра развития, которую вы должны удвоить, и мы собираемся использовать ее здесь. Почему? Мы хотим учитывать непредсказуемые изменения, которые могут повлиять на ваши потребности в хранении данных — например, рост компании, потребности каждого проекта или просто общие области.
Теперь, когда это число определено, умножьте его на 365. Теперь это ваш прогнозируемый прирост данных за один год, который при добавлении к вашей первоначальной сумме будет определять, сколько хранилища вы должны посмотреть на получение.
Обработка ресурсов
В отличие от потребностей в хранении данных, потребности в обработке намного сложнее точно рассчитать. Основная цель здесь — решить, хотите ли вы увеличить нагрузку на запросы или на локальный компьютер (или облачный экземпляр). Имейте в виду, что когда я говорю о локальном компьютере, я имею в виду не только компьютер, который вы обычно используете, — вам, вероятно, понадобится какая-то оптимизированная рабочая станция для более интенсивных вычислений.
Чтобы сделать этот выбор, нужно подумать о самом крупном проекте по науке о данных, который вы можете запустить в следующем году. Может ли ваше решение для обработки данных обработать запрос такого размера, не становясь недоступным для всех других заинтересованных сторон? Если это возможно, тогда вы готовы идти без дополнительных ресурсов, необходимых. Если нет, то вам нужно будет планировать получение рабочих станций соответствующего размера или масштабирование облачных экземпляров.
ETL (извлечение, преобразование, загрузка) процессов
После того, как вы решите, где хранить и обработать ваши данные, следующим решением будет как. Создание процесса ETL обеспечит упорядочение и обновление вашей базы данных по науке и не позволит использовать ненужные ресурсы из других источников.
Вот что вы должны иметь в своей документации ETL:
- любые процедуры резервного копирования, которые должны иметь место
- откуда будут поступать данные и куда они будут отправляться
- точные размеры, которые должны быть перемещены
- как часто должен происходить перевод
- должен ли перевод быть завершенным (переписать всю базу данных) или может быть аддитивным (только перемещаться по новым вещам)
Подготовка решения
Со всеми точками данных, пришло время выбрать решение. Эта часть займет небольшое исследование и будет в значительной степени зависеть от ваших конкретных потребностей, так как на первый взгляд они имеют много общего.
Три из крупнейших облачных решений — Amazon Web Services (AWS), Google Cloud Platform (GCP) и Microsoft Azure — предлагают одни из лучших цен и функций. Все три имеют относительно схожие затраты, хотя для AWS значительно сложнее рассчитать затраты (из-за структуры ценообразования по выбору).
Помимо цены, каждый предлагает масштабируемое хранилище данных и возможность добавлять экземпляры обработки, хотя каждый вызывает свои «экземпляры» под другим именем. При изучении того, что использовать для своей собственной инфраструктуры, примите во внимание, какие типы проектов вы будете использовать чаще всего, так как это может изменить стоимость каждого из них и набор функций.
Тем не менее, многие компании просто выбирают то, что соответствует их существующему технологическому стеку.
Возможно, вы также захотите создать собственную инфраструктуру внутри компании, хотя это значительно сложнее и не для слабонервных.
Дополнительные советы для гладкой реализации
Со всеми вашими утками подряд вы можете приступить к реализации! Чтобы помочь, вот несколько с трудом заработанных советов по облегчению вашего проекта — от подачи до исполнения.
Проверьте свой процесс ETL
Когда вы впервые соберете свой процесс ETL, не тестируйте все сразу! Это может создать серьезную нагрузку на ваши ресурсы и резко увеличить ваши облачные затраты, если есть ошибка, или если вам придется повторить попытку несколько раз.
Вместо этого рекомендуется сначала запустить процесс, используя только первые 100 строк или около того ваших исходных таблиц. Затем запустите полную передачу, как только вы узнаете, что это сработает.
Проверьте свои запросы слишком
То же самое касается любого большого запроса, который вы запускаете в облачном экземпляре. Ошибиться в миллионах фрагментов данных в системе гораздо сложнее, чем в нескольких, особенно если вы платите за ГБ.
Создать стратегию резервного хранилища
Большинство облачных операторов предлагают это как функцию, поэтому вам, возможно, не придется беспокоиться об этом. Тем не менее, ваша группа должна обсудить, хотели бы они создавать свои собственные регулярные резервные копии данных или же было бы более эффективно восстанавливать данные в случае необходимости.
Проблемы безопасности и конфиденциальности
При перемещении данных клиентов в облако убедитесь, что все участники осведомлены о политиках управления данными вашей компании, чтобы избежать проблем в будущем. Это также может помочь вам сэкономить на объеме данных, хранящихся в облаке.
Наименование измерений во время ETL
При выполнении ETL из табличной базы данных в неструктурированную базу данных будьте осторожны с процедурами именования. Если имена просто передаются оптом, вероятно, у вас будет много полей из разных таблиц, имеющих одно и то же имя. Простой способ преодолеть это сначала — назвать новые измерения в неструктурированной базе данных как {oldtablename}_{columnname} а затем переименовать их оттуда.
Запусти свой мотор!
Теперь вы можете планировать основы своей аналитики и инфраструктуры данных науки. После определения многих ключевых вопросов и ответов процесс внедрения и получения управленческого участия должен пройти гораздо более плавно.
Сложно придумать ответы для своей компании? Я замаскировал что-то важное? Дай мне знать в комментариях!