(* Но боялся спросить)
Авторы Фиби Вонг и Роберт Беннетт
Чтобы быть настоящим специалистом по анализу данных или тем, что многие блоггеры и работодатели называют единорогом, вы должны освоить каждый этап процесса анализа данных - от хранения ваших данных до запуск готового продукта (как правило, прогнозной модели) в производство. Но основная часть обучения науке о данных сосредоточена на методах машинного / глубокого обучения; к знаниям в области управления данными часто обращаются второстепенно. Студенты, изучающие науку о данных, обычно изучают навыки моделирования с обработанными и очищенными данными в текстовых файлах, хранящихся на их ноутбуке, игнорируя способ создания колбасы данных. Студенты часто не осознают, что в отраслевых условиях получение необработанных данных из различных источников для моделирования обычно составляет 80% работы. А поскольку корпоративные проекты обычно включают в себя огромный объем данных, для обработки которых их локальный компьютер не оборудован, весь процесс моделирования часто происходит в облаке, при этом большинство приложений и баз данных размещаются на серверах в других центрах обработки данных. Даже после того, как студент устроился на работу в качестве специалиста по данным, управление данными часто становится чем-то, чем занимается отдельная группа инженеров данных. В результате слишком много специалистов по обработке данных слишком мало знают о хранении данных и инфраструктуре, часто в ущерб своей способности принимать правильные решения на своей работе. Цель этой статьи - предоставить дорожную карту того, что специалист по данным в 2019 году должен знать об управлении данными - от типов баз данных, где и как данные хранятся и обрабатываются, до текущих коммерческих вариантов - чтобы начинающие единороги могли погрузитесь глубже самостоятельно или, по крайней мере, узнайте достаточно, чтобы звучать так, как на собеседованиях и коктейльных вечеринках.
Рост неструктурированных данных и инструментов для больших данных
История науки о данных - это действительно история хранения данных. В доцифровую эпоху данные хранились в наших головах, на глиняных табличках или на бумаге, что делало агрегирование и анализ данных чрезвычайно трудоемкими. В 1956 году IBM представила первый коммерческий компьютер с магнитным жестким диском 305 RAMAC. Для всего устройства требовалось 30 футов x 50 футов физического пространства, он весил более тонны, и за 3200 долларов в месяц компании могли арендовать устройство для хранения до 5 МБ данных. За 60 лет, прошедшие с тех пор, цена за гигабайт в DRAM упала с колоссальных 2,64 миллиарда долларов в 1965 году до 4,9 долларов в 2017 году. Помимо того, что хранилище данных стало намного дешевле, хранилище данных также стало намного плотнее / меньше по размеру. Дисковая пластина в 305 RAMAC хранит сто бит на квадратный дюйм, по сравнению с более чем триллионом бит на квадратный дюйм в сегодняшней типичной дисковой пластине.
Эта комбинация резкого снижения стоимости и размера хранилища данных - вот что делает возможной сегодняшнюю аналитику больших данных. Благодаря сверхнизкой стоимости хранения создание инфраструктуры обработки и анализа данных для сбора и извлечения информации из огромного количества данных стало прибыльным подходом для бизнеса. А с обилием устройств Интернета вещей, которые постоянно генерируют и передают данные пользователей, предприятия собирают данные о постоянно растущем количестве действий, создавая огромное количество крупномасштабных, высокоскоростных и разнообразных информационных ресурсов ( или три V больших данных). Большинство этих действий (например, электронные письма, видео, аудио, сообщения в чатах, сообщения в социальных сетях) генерируют неструктурированные данные, на которые сегодня приходится почти 80% всех корпоративных данных и которые за последнее десятилетие растут в два раза быстрее, чем структурированные данные.
Этот массовый рост данных резко изменил способы хранения и анализа данных, поскольку традиционные инструменты и подходы не были оснащены для обработки «трех V больших данных». Были разработаны новые технологии, позволяющие обрабатывать постоянно увеличивающийся объем и разнообразие данных с более высокой скоростью и меньшими затратами. Эти новые инструменты также оказывают глубокое влияние на то, как специалисты по обработке данных выполняют свою работу, позволяя им монетизировать огромный объем данных, выполняя аналитику и создавая новые приложения, которые раньше были невозможны. Ниже приведены основные инновации в области управления большими данными, о которых, по нашему мнению, должен знать каждый специалист по данным.
Реляционные базы данных и NoSQL
Системы управления реляционными базами данных (СУБД) появились в 1970-х годах для хранения данных в виде таблиц со строками и столбцами, используя операторы языка структурированных запросов (SQL) для запроса и обслуживания базы данных. Реляционная база данных - это в основном набор таблиц, каждая из которых имеет схему, которая жестко определяет атрибуты и типы данных, которые они хранят, а также ключи, которые идентифицируют определенные столбцы или строки для облегчения доступа. В ландшафте СУБД когда-то правили Oracle и IBM, но сегодня многие варианты с открытым исходным кодом, такие как MySQL, SQLite и PostgreSQL, не менее популярны.
Реляционные базы данных нашли применение в деловом мире благодаря некоторым очень привлекательным свойствам. Целостность данных имеет первостепенное значение в реляционных базах данных. СУБД удовлетворяет требованиям атомарности, согласованности, изоляции и долговечности (или ACID-совместимости), налагая ряд ограничений для обеспечения надежности и точности хранимых данных, что делает их идеальными для отслеживания и хранения таких вещей, как номера счетов, заказы и платежи. Но эти ограничения требуют дорогостоящих компромиссов. Из-за ограничений схемы и типа СУБД плохо хранят неструктурированные или полуструктурированные данные. Жесткая схема также удорожает установку, обслуживание и развитие СУБД. Для настройки СУБД требуется, чтобы пользователи заранее указали конкретные варианты использования; любые изменения схемы обычно трудны и требуют много времени. Кроме того, традиционные СУБД были разработаны для работы на одном компьютерном узле, что означает, что их скорость значительно ниже при обработке больших объемов данных. Разделение РСУБД с целью горизонтального масштабирования при сохранении соответствия ACID также является чрезвычайно сложной задачей. Все эти атрибуты делают традиционные СУБД плохо приспособленными для обработки современных больших данных.
К середине 2000-х существующие СУБД больше не могли справляться с меняющимися потребностями и экспоненциальным ростом нескольких очень успешных онлайн-предприятий, и в результате было разработано множество нереляционных (или NoSQL) баз данных (вот история о том, как Facebook столкнулся с ограничениями MySQL, когда объем их данных начал расти). Не имея в то время каких-либо известных решений, эти онлайн-компании изобрели новые подходы и инструменты для обработки огромного количества неструктурированных данных, которые они собирали: Google создал GFS, MapReduce и BigTable; Amazon создал DynamoDB; Yahoo создала Hadoop; Facebook создал Кассандру и Улей; LinkedIn создал Кафку. Некоторые из этих предприятий открыли исходные коды своей работы; некоторые опубликовали исследовательские работы с подробным описанием их конструкции, что привело к быстрому распространению баз данных с новыми технологиями, а базы данных NoSQL стали крупным игроком в отрасли.
Базы данных NoSQL не зависят от схемы и обеспечивают гибкость, необходимую для хранения и управления большими объемами неструктурированных и полуструктурированных данных. Пользователям не нужно знать, какие типы данных будут храниться во время настройки, и система может учитывать изменения в типах данных и схеме. Базы данных NoSQL, предназначенные для распределения данных по разным узлам, обычно более масштабируемы по горизонтали и отказоустойчивы. Однако эти преимущества производительности также связаны с расходами - базы данных NoSQL не совместимы с ACID, и согласованность данных не гарантируется. Вместо этого они обеспечивают возможную согласованность: когда старые данные перезаписываются, они возвращают результаты, которые временно немного неверны. Например, индекс поисковой системы Google не может перезаписывать свои данные, когда люди одновременно ищут данный термин, поэтому он не дает нам самых последних результатов при поиске, но дает нам самые последние, лучший ответ может. Хотя эта настройка не будет работать в ситуациях, когда согласованность данных абсолютно необходима (например, финансовые транзакции); он отлично подходит для задач, требующих скорости, а не высокой точности.
В настоящее время существует несколько различных категорий NoSQL, каждая из которых служит определенным целям. Хранилища ключ-значение, такие как Redis, DynamoDB и Cosmos DB, хранят только пары ключ-значение и предоставляют базовые функции для получения значения, связанного с известным ключом. Лучше всего они работают с простой схемой базы данных и когда важна скорость. Хранилища с широкими столбцами, такие как Cassandra, Scylla и HBase, хранят данные в семействах столбцов или таблицах и созданы для управления петабайтами данных в масштабной распределенной системе. Хранилища документов, такие как MongoDB и Couchbase, хранят данные в формате XML или JSON с именем документа в качестве ключа и содержимым документа в качестве значения. Документы могут содержать много различных типов значений и могут быть вложенными, что делает их особенно подходящими для управления полуструктурированными данными в распределенных системах. Графические базы данных, такие как Neo4J и Amazon Neptune, представляют данные как сеть связанных узлов или объектов, чтобы облегчить визуализацию данных и аналитику графов. Графические базы данных особенно полезны для анализа взаимосвязей между разнородными точками данных, например, в предотвращении мошенничества или в графах друзей Facebook.
MongoDB в настоящее время является самой популярной базой данных NoSQL и принесла существенную пользу некоторым предприятиям, которые изо всех сил пытались обрабатывать свои неструктурированные данные с помощью традиционного подхода РСУБД. Вот два отраслевых примера: после того, как MetLife потратила лет на попытки создать централизованную базу данных клиентов на основе СУБД, которая могла бы обрабатывать все ее страховые продукты, кто-то на внутреннем хакатоне построил базу данных с MongoDB в течение нескольких часов, что пошли в производство через 90 дней. YouGov, исследовательская фирма, собирающая 5 гигабит данных в час, сэкономила 70 процентов емкости хранилища, которую она раньше использовала, за счет перехода с СУБД на MongoDB.
Хранилище данных, озеро данных и болото данных
Поскольку источники данных продолжают расти, выполнение аналитики данных с несколькими базами данных стало неэффективным и дорогостоящим. Одно решение под названием Data Warehouse появилось в 1980-х годах, которое централизует данные предприятия из всех его баз данных. Хранилище данных поддерживает поток данных из операционных систем в системы аналитики / принятия решений, создавая единое хранилище данных из различных источников (как внутренних, так и внешних). В большинстве случаев хранилище данных - это реляционная база данных, в которой хранятся обработанные данные, оптимизированные для сбора бизнес-информации. Он собирает данные с заранее определенной структурой и схемой, поступающие из транзакционных систем и бизнес-приложений, и эти данные обычно используются для оперативной отчетности и анализа.
Но поскольку данные, которые попадают в хранилища данных, необходимо обработать, прежде чем они будут сохранены - с сегодняшним огромным объемом неструктурированных данных, это может занять значительное время и ресурсы. В ответ компании начали поддерживать озера данных в 2010-х годах, в которых хранятся все структурированные и неструктурированные данные предприятия в любом масштабе. Озера данных хранят необработанные данные и могут быть настроены без предварительного определения структуры данных и схемы. Озера данных позволяют пользователям запускать аналитику без необходимости перемещать данные в отдельную аналитическую систему, позволяя предприятиям получать информацию из новых источников данных, которые ранее не были доступны для анализа, например, путем создания моделей машинного обучения с использованием данных из файлов журналов, потоки кликов, социальные сети и устройства Интернета вещей. Сделав все корпоративные данные доступными для анализа, специалисты по обработке данных могут ответить на новый набор бизнес-вопросов или решить старые вопросы с помощью новых данных.
Общей проблемой архитектуры озера данных является то, что без надлежащего качества данных и инфраструктуры управления, когда терабайты структурированных и неструктурированных данных перетекают в озера данных, часто становится чрезвычайно сложно отсортировать их содержимое. Озера данных могут превратиться в болота данных, поскольку хранимые данные станут слишком беспорядочными, чтобы их можно было использовать. Многие организации теперь призывают к более широкому использованию методов управления данными и метаданными, чтобы предотвратить образование болота данных.
Распределенная и параллельная обработка: Hadoop, Spark и MPP
В то время как потребности в хранении данных и вычислениях за последние несколько десятилетий росли на дрожжах, традиционное оборудование недостаточно продвинулось, чтобы не отставать. Корпоративные данные больше не помещаются в стандартное хранилище, а вычислительная мощность, необходимая для обработки большинства задач анализа больших данных, может занять недели, месяцы или просто невозможна для выполнения на стандартном компьютере. Чтобы преодолеть этот недостаток, было разработано множество новых технологий, в которых несколько компьютеров работают вместе, распределяя базу данных по тысячам обычных серверов. Когда сеть компьютеров соединена и работает вместе для выполнения одной и той же задачи, компьютеры образуют кластер. Кластер можно рассматривать как отдельный компьютер, но он может значительно улучшить производительность, доступность и масштабируемость по сравнению с одной, более мощной машиной и с меньшими затратами за счет использования стандартного оборудования. Apache Hadoop - это пример распределенных инфраструктур данных, которые используют кластеры для хранения и обработки огромных объемов данных, а также то, что обеспечивает архитектуру Data Lake.
Когда вы думаете о Hadoop, думайте о распределении. Hadoop состоит из трех основных компонентов: Распределенная файловая система Hadoop (HDFS), способ хранения и отслеживания ваших данных на нескольких (распределенных) физических жестких дисках; MapReduce, фреймворк для обработки данных на распределенных процессорах; и еще один согласователь ресурсов (YARN), структура управления кластером, которая управляет распределением таких вещей, как использование ЦП, память и распределение полосы пропускания сети между распределенными компьютерами. Уровень обработки Hadoop является особенно заметным нововведением: MapReduce - это двухэтапный вычислительный подход для обработки больших (несколько терабайт и более) наборов данных, распределенных по большим кластерам стандартного оборудования надежным и отказоустойчивым способом. Первый шаг - распределить ваши данные между несколькими компьютерами (карта), при этом каждый из них параллельно выполняет вычисления на своем срезе данных. Следующий шаг - объединить эти результаты попарно (уменьшить). Google опубликовал статью о MapReduce в 2004 году, которую подхватили программисты Yahoo, которые реализовали ее в среде Apache с открытым исходным кодом в 2006 году, предоставив каждому бизнесу возможность хранить беспрецедентный объем данных с использованием стандартного оборудования. Несмотря на то, что существует множество реализаций этой идеи с открытым исходным кодом, торговая марка Google MapReduce прижилась, вроде Jacuzzi или Kleenex.
Hadoop создан для итеративных вычислений, сканирования огромных объемов данных с диска за одну операцию, распределения обработки между несколькими узлами и сохранения результатов обратно на диск. Запросы зеттабайтов проиндексированных данных, выполнение которых в традиционной среде хранилища данных заняло бы 4 часа, можно было выполнить за 10–12 секунд с помощью Hadoop и HBase. Hadoop обычно используется для создания сложных аналитических моделей или приложений для хранения больших объемов данных, таких как ретроспективная и прогнозная аналитика; машинное обучение и сопоставление с образцом; сегментация клиентов и анализ оттока клиентов; и активные архивы.
Но MapReduce обрабатывает данные партиями и поэтому не подходит для обработки данных в реальном времени. Apache Spark был построен в 2012 году, чтобы восполнить этот пробел. Spark - это инструмент параллельной обработки данных, который оптимизирован по скорости и эффективности за счет обработки данных в памяти. Он работает по тому же принципу MapReduce, но работает намного быстрее, выполняя большую часть вычислений в памяти и записывая на диск только при заполнении памяти или завершении вычислений. Это вычисление в памяти позволяет Spark запускать программы до 100 раз быстрее, чем Hadoop MapReduce в памяти, или в 10 раз быстрее на диске. Однако, когда набор данных настолько велик, что нехватка оперативной памяти становится проблемой (обычно сотни гигабайт и более), Hadoop MapReduce может превзойти Spark. Spark также имеет обширный набор библиотек аналитики данных, охватывающий широкий спектр функций: Spark SQL для SQL и структурированных данных; MLib для машинного обучения, Spark Streaming для потоковой обработки и GraphX для графической аналитики. Поскольку Spark сосредоточен на вычислениях, он не имеет собственной системы хранения и вместо этого работает на различных системах хранения, таких как Amazon S3, Azure Storage и Hadoop's HDFS.
Hadoop и Spark - не единственные технологии, использующие кластеры для обработки больших объемов данных. Другой популярный вычислительный подход к распределенной обработке запросов называется Массовая параллельная обработка (MPP). Подобно MapReduce, MPP распределяет обработку данных между несколькими узлами, и узлы обрабатывают данные параллельно для повышения скорости. Но в отличие от Hadoop, MPP используется в СУБД и использует архитектуру без совместного использования - каждый узел обрабатывает свой собственный фрагмент данных с помощью многоядерных процессоров, что делает их во много раз быстрее, чем традиционные СУБД. Некоторые базы данных MPP, такие как Pivotal Greenplum, имеют зрелые библиотеки машинного обучения, которые позволяют выполнять аналитику в базе данных. Однако, как и в случае с традиционной СУБД, большинство баз данных MPP не поддерживают неструктурированные данные, и даже структурированные данные потребуют некоторой обработки для соответствия инфраструктуре MPP; поэтому для настройки конвейера данных для базы данных MPP требуется дополнительное время и ресурсы. Поскольку базы данных MPP совместимы с ACID и обеспечивают гораздо более высокую скорость, чем традиционные СУБД, они обычно используются в высокопроизводительных решениях для корпоративных хранилищ данных, таких как Amazon Redshift, Pivotal Greenplum и Snowflake. Например, Нью-Йоркская фондовая биржа ежедневно получает от четырех до пяти терабайт данных и проводит комплексную аналитику, наблюдение за рынком, планирование и мониторинг емкости. Компания использовала традиционную базу данных, которая не могла справиться с рабочей нагрузкой, которая загружалась часами и имела низкую скорость запросов. Переход к базе данных MPP сократил время их ежедневного анализа на восемь часов.
Облачные службы
Еще одно нововведение, полностью изменившее возможности корпоративной аналитики больших данных, - это появление облачных сервисов. В старые тяжелые времена, до появления облачных сервисов, предприятиям приходилось покупать локальные решения для хранения данных и аналитики у поставщиков программного и аппаратного обеспечения, обычно выплачивая авансовые сборы за бессрочную лицензию на программное обеспечение и ежегодные сборы за обслуживание и обслуживание оборудования. К этому добавляются затраты на электроэнергию, охлаждение, безопасность, защиту от стихийных бедствий, ИТ-персонал и т. Д. Для создания и обслуживания локальной инфраструктуры. Даже когда было технически возможно хранить и обрабатывать большие данные, большинство предприятий сочли, что делать это в больших масштабах непомерно дорого. Масштабирование с помощью локальной инфраструктуры также требует обширного процесса проектирования и закупок, реализация которого занимает много времени и требует значительного первоначального капитала. В результате были проигнорированы многие потенциально ценные возможности сбора данных и аналитики.
Локальная модель начала быстро терять долю рынка, когда облачные сервисы были введены в конце 2000-х годов - мировой рынок облачных услуг ежегодно рос на 15% в последнее десятилетие. Платформы облачных сервисов предоставляют подписку на различные услуги (от виртуальных вычислений до инфраструктуры хранения и баз данных), предоставляемые через Интернет с оплатой по мере использования, предлагая клиентам быстрый доступ к гибким и недорогим хранилищам и виртуальные вычислительные ресурсы. Поставщики облачных услуг несут ответственность за все закупки и обслуживание своего оборудования и программного обеспечения и обычно имеют обширную сеть серверов и обслуживающий персонал для предоставления надежных услуг. Многие компании обнаружили, что с помощью облачных сервисов они могут значительно снизить затраты и повысить операционную эффективность, а также могут быстрее разрабатывать и производить свои продукты с помощью готовых облачных ресурсов и их встроенной масштабируемости. Устраняя первоначальные затраты и временные затраты на создание локальной инфраструктуры, облачные сервисы также снижают барьеры для внедрения инструментов больших данных и эффективно демократизируют аналитику больших данных для малых и средних предприятий.
Существует несколько моделей облачных сервисов, из которых наиболее распространены общедоступные облака. В общедоступном облаке все оборудование, программное обеспечение и другая вспомогательная инфраструктура принадлежат и управляются поставщиком облачных услуг. Клиенты совместно используют облачную инфраструктуру с другими облачными арендаторами и получают доступ к их сервисам через веб-браузер. Частное облако часто используется организациями с особыми потребностями в безопасности, такими как государственные учреждения и финансовые учреждения. В частном облаке службы и инфраструктура предназначены исключительно для одной организации и поддерживаются в частной сети. Частное облако может быть локальным или размещаться у стороннего поставщика услуг в другом месте. Гибридные облака объединяют частные облака с общедоступными, позволяя организациям воспользоваться преимуществами обоих. В гибридном облаке данные и приложения могут перемещаться между частными и общедоступными облаками для большей гибкости: например, публичное облако может использоваться для больших объемов данных с низким уровнем безопасности, а частное облако - для конфиденциальных, критически важных для бизнеса данных, таких как финансовая отчетность. Мультиоблачная модель включает несколько облачных платформ, каждая из которых предоставляет определенный сервис приложений. Мультиоблако может представлять собой комбинацию общедоступных, частных и гибридных облаков для достижения целей организации. Организации часто выбирают мультиоблако в соответствии с их конкретным бизнесом, местоположением и временными потребностями, а также во избежание привязки к поставщику.
Практический пример: создание сквозной инфраструктуры обработки и анализа данных для запуска рекомендательного приложения
Создание жизнеспособного продукта для науки о данных включает в себя гораздо больше, чем просто построение модели машинного обучения с помощью scikit-learn, ее обработку и загрузку на сервер. Это требует понимания того, как все части экосистемы предприятия работают вместе, начиная с того, где / как данные поступают в группу обработки данных, среды, в которой данные обрабатываются / преобразуются, соглашений предприятия для визуализации / представления данных и того, как выходные данные модели будут преобразованы в качестве входных данных для некоторых других корпоративных приложений. Основные цели включают построение процесса, который будет легко поддерживать; где модели могут быть повторены и производительность воспроизводима; а результаты модели могут быть легко поняты и визуализированы для других заинтересованных сторон, чтобы они могли принимать более обоснованные бизнес-решения. Достижение этих целей требует выбора правильных инструментов, а также понимания того, что делают другие в отрасли, и передовых методов.
Давайте проиллюстрируем это на примере: предположим, что вас только что наняли в качестве ведущего специалиста по данным для запуска приложения для рекомендаций по отпуску, которое, как ожидается, соберет сотни гигабайт как структурированных (профили клиентов, температуры, цены и записи транзакций), так и неструктурированных (данные клиентов) сообщения / комментарии и файлы изображений) данные от пользователей ежедневно. Ваши прогностические модели необходимо будет переобучать с использованием новых данных еженедельно и мгновенно давать рекомендации по запросу. Поскольку вы ожидаете, что ваше приложение станет огромным хитом, ваши возможности для сбора, хранения и аналитики данных должны быть чрезвычайно масштабируемыми. Как бы вы спроектировали процесс обработки данных и построили свои модели? Какие инструменты вам понадобятся для выполнения работы? Поскольку это стартап, и вы являетесь ведущим - и, возможно, единственным - специалистом по данным, вы должны принимать эти решения.
Во-первых, вам нужно будет выяснить, как настроить конвейер данных, который принимает необработанные данные из источников данных, обрабатывает данные и передает обработанные данные в базы данных. Идеальный конвейер данных имеет низкую задержку событий (возможность запрашивать данные сразу после их сбора); масштабируемость (возможность обрабатывать большие объемы данных по мере масштабирования вашего продукта); интерактивные запросы (поддерживают как пакетные запросы, так и интерактивные запросы меньшего размера, которые позволяют специалистам по данным исследовать таблицы и схемы); управление версиями (возможность вносить изменения в конвейер без остановки конвейера и потери данных); мониторинг (конвейер должен генерировать предупреждения, когда данные перестают поступать); и тестирование (возможность протестировать конвейер без перебоев). Возможно, самое главное, ему лучше не мешать повседневным бизнес-операциям - например, Если новая модель, которую вы тестируете, вызовет остановку работы вашей оперативной базы данных, закроются головы. Создание и поддержка конвейера данных обычно является обязанностью инженера по данным (более подробно в этой статье есть отличный обзор построения конвейера данных для стартапов), но специалист по анализу данных должен, по крайней мере, быть знаком с процессом, его ограничения и инструменты, необходимые для доступа к обработанным данным для анализа.
Затем вам нужно будет решить, хотите ли вы создать локальную инфраструктуру или использовать облачные сервисы. Для стартапа высшим приоритетом является масштабирование сбора данных без масштабирования операционных ресурсов. Как упоминалось ранее, локальная инфраструктура требует огромных начальных затрат и затрат на обслуживание, поэтому облачные сервисы, как правило, являются лучшим вариантом для стартапов. Облачные сервисы позволяют масштабироваться в соответствии со спросом и требуют минимальных усилий по обслуживанию, так что ваша небольшая команда сотрудников может сосредоточиться на продукте и аналитике, а не на управлении инфраструктурой.
Чтобы выбрать поставщика облачных услуг, вам нужно сначала установить данные, которые вам понадобятся для аналитики, а также базы данных и инфраструктуру аналитики, наиболее подходящие для этих типов данных. Поскольку в вашем конвейере аналитики будут как структурированные, так и неструктурированные данные, вы можете настроить как хранилище данных, так и озеро данных. Специалистам по данным важно учитывать, поддерживает ли уровень хранения инструменты для работы с большими данными, которые необходимы для построения моделей, и обеспечивает ли база данных эффективную аналитику в базе данных. Например, некоторые библиотеки машинного обучения, такие как MLlib от Spark, не могут эффективно использоваться с базами данных в качестве основного интерфейса для данных - данные должны быть выгружены из базы данных, прежде чем с ними можно будет работать, что может занять чрезвычайно много времени, поскольку объем данных растет и может стать узким местом, если вы регулярно переобучаете свои модели (что вызывает еще одну «головокружительную» ситуацию).
Что касается науки о данных в облаке, большинство облачных провайдеров упорно работают над развитием собственных возможностей машинного обучения, которые позволяют ученым легко создавать и развертывать модели машинного обучения с данными, хранящимися на их собственной платформе (у Amazon есть SageMaker, у Google - BigQuery). ML », у Microsoft - Машинное обучение Azure ). Но наборы инструментов все еще развиваются и часто являются неполными: например, BigQuery ML в настоящее время поддерживает только линейную регрессию, бинарную и многоклассовую логистическую регрессию, кластеризацию K-средних и импорт моделей TensorFlow. Если вы решите использовать эти инструменты, вам придется тщательно проверить их возможности, чтобы убедиться, что они делают то, что вам нужно.
Еще одна важная вещь, которую следует учитывать при выборе поставщика облачных услуг, - это привязка к поставщику. Если вы выберете проприетарное решение для облачной базы данных, вы, скорее всего, не сможете получить доступ к программному обеспечению или данным в своей локальной среде, а для смены поставщика потребуется переход на другую базу данных, который может быть дорогостоящим. Один из способов решения этой проблемы - выбрать поставщиков, поддерживающих технологии с открытым исходным кодом (вот Netflix объясняет, почему они используют программное обеспечение с открытым исходным кодом). Еще одно преимущество использования технологий с открытым исходным кодом состоит в том, что они, как правило, привлекают более широкое сообщество пользователей, а это означает, что вам будет проще нанять кого-то, у кого есть опыт и навыки для работы в вашей инфраструктуре. Другой способ решения проблемы - выбор сторонних поставщиков (таких как Pivotal Greenplum и Snowflake), которые предоставляют решения для облачных баз данных с использованием других крупных облачных провайдеров в качестве серверной части хранилища, что также позволяет хранить ваши данные в нескольких облаках. если это соответствует потребностям вашего стартапа.
Наконец, поскольку вы ожидаете роста компании, вам необходимо внедрить надежную практику управления облаком, чтобы защитить свое облако и предотвратить потерю и утечку данных - например, управление доступом к данным и обеспечение безопасности интерфейсов и API. Вы также захотите внедрить лучшие практики управления данными, чтобы поддерживать качество данных и гарантировать, что ваше озеро данных не превратится в болото данных.
Как видите, корпоративный проект по науке о данных - это гораздо больше, чем настройка гиперпараметров в моделях машинного обучения! Мы надеемся, что этот общий обзор вдохновил вас узнать больше об управлении данными и, возможно, вы подберете несколько вещей, чтобы произвести впечатление на инженеров по обработке данных, работающих с водяным охладителем.
Заявление об ограничении ответственности: мнения, выраженные в этой статье, являются нашими собственными и не отражают взгляды наших прошлых или нынешних работодателей.
