Спонсируемый Более полутора десятилетий люди говорили о большое количество данных и атрибуты, которыми он обладает на современном предприятии.
Повторяйте вместе с нами, потому что вы знаете три V больших данных: Объем, Скорость, а также Разнообразие, к которому некоторые впоследствии добавили Достоверность и один или два Ценить. Возможно, это немного расширяет суть. Но одна вещь, которой не хватает во всем этом V-разговоре о встроенных битах, каскадно поступающих в центр обработки данных, – это тот простой факт, что если вы не можете найти данные, это не принесет вам никакой пользы.
Нам нужно V-слово для «находимости», и мы не смогли придумать его, почесав голову некоторое время, и не смогли найти подходящего в мировых онлайн-тезаурусах, что забавно, если задуматься. Видимость кажется слабее того, что мы ищем, поэтому обнаружение данных, тема последней статьи в этой серии из четырех частей, посвященной Kubernetes в корпоративном центре обработки данных, будет иметь значение.
И что касается Red Hat, обнаружение данных – это не только выяснение того, какие данные у вас есть, и поиск нужных данных для решения конкретной проблемы или создания определенного алгоритма, но и установление того, что наборы данных не полны мусора, который может радикально искажение результатов.
Глубокая чистка
«Наука о данных – это разрушительная сила, значение которой приобретает все большее значение», – объясняет Пит Брей, директор по маркетингу служб данных в Red Hat, чья платформа OpenShift становится пробным камнем для Kubernetes коммерческого уровня.
«Крупные компании осознают это, и ни один бизнес не останется без внимания, и на самом деле их конкурентоспособность в определенной степени будет зависеть от науки о данных. И давайте посмотрим правде в глаза, на предприятии много науки о данных используется в маркетинговых целях. Так компании взаимодействуют со своими клиентами. Но в зависимости от того, кого вы спросите, от 40 до 50 процентов – некоторые говорят, что 80 процентов – времени, которое специалисты по данным тратят в своей работе, просто на поиск нужных данных, а затем, как только они их найдут, чистота данных станет большой проблемой. . Специалистам по данным нужно больше времени уделять алгоритмам и машинному обучению и меньше беспокоиться о том, чтобы найти нужные данные и убедиться, что они чистые ».
Это была постоянная проблема при обработке данных, и в действительности она не сильно отличалась три десятилетия назад с появлением Teradata и ее конкурентов в развивающемся бизнесе хранилищ данных, когда кошмар извлечения / преобразования / загрузки выполнялся массовыми партиями из исторических данных. записи реляционной базы данных. Это действительно принесло пользу многим компаниям, но при огромных усилиях. Ситуация с обнаружением и очисткой данных не улучшилась для предприятий с появлением более десяти лет назад инфраструктуры распределенной обработки MapReduce и ее базовой распределенной файловой системы Hadoop, которая позволяла обрабатывать большие объемы данных, но приводила к гораздо более медленным запросам, которые выполнялись пользователями. привыкший. Мы вернулись в пакетный режим (и пришлось это сделать, учитывая размер данных).
Специалистам по данным нужно больше времени уделять алгоритмам и машинному обучению и меньше беспокоиться о том, чтобы найти нужные данные и убедиться, что они чистые.
«Скорость изменения данных ускоряется, – говорит Брей. «Хотя ETL и пакетная загрузка все еще происходят, мы наблюдаем все больше и больше анализа данных в реальном времени, и это также меняет характер обнаружения данных. Мы больше не думаем только о записях, файлах и объектах. Нам нужно беспокоиться об извлечении данных из больших пожарных шлангов и множества маленьких соломинок ».
С этой целью были разработаны методы маркировки данных и каталогизации, часто с использованием методов машинного обучения, которые могут автоматически создавать метаданные о данных, чтобы их было легче найти в будущем.
«Большинство умных организаций стараются делать это автоматически», – объясняет Брей. «Здесь Kafka и другие потоковые приложения анализируют входящие потоки и запускают определенные процессы ниже по потоку на основе тегов, связанных с потоками.
«Это очень важный первый шаг. Предварительная маркировка данных – очень ценный подход, поскольку он помогает решить последующую проблему поиска данных для дальнейшего использования. Таким образом, данные помечаются, и они могут перемещаться прямо в базу данных, data хранилище или озеро данных. В машинном обучении эта концепция переходит в особый вид базы данных, называемый хранилищем функций. Это подготавливает данные, выполняет некоторую предварительную обработку и сохраняет их в базе данных для будущего использования машиной. обучаются обучающим моделям по мере того, как они проходят через множество итераций и изменений алгоритмов ».
Пометка и каталогизация данных – это первый шаг в обнаружении данных, но как только это будет сделано и появится головокружительный массив наборов данных, вам придется их найти. Это не так просто, как вылить все данные в хранилище объектов S3, а затем наложить на него слои Elasticsearch или IBM Spectrum Discover, хотя компании так и поступают.
Это необходимо, но недостаточно, потому что не все данные, полезные для специалистов по данным, находятся в хранилище объектов. Цель «пирога в небе» – иметь федеративную службу данных – подумайте о PrestoDB от Facebook и его коммерческих вариантах Ahana и Starburst, или о программном обеспечении для кэширования данных Tachyon от AMPLab в Калифорнийском университете в Беркли и его коммерческом варианте Alluxio, – которые могут оставьте данные там, где они есть, в том формате, в котором они уже есть, и выполните запрос к ним, будь то в реляционной базе данных, хранилище объектов, HDFS или чем-то еще.
Если ваши данные в беспорядке, и вам действительно нужно начать думать о том, как вы выполняете обнаружение данных, развертывание платформы Kubernetes – идеальное время для выполнения этой работы. И если у вас уже есть совместная работа по обнаружению данных, Kubernetes сможет использовать большую часть работы, которую вы уже сделали.
«Если вы в этом разбираетесь, вы подумаете о том, как использовать Kubernetes не только для обеспечения гибкости, необходимой вам для ваших приложений, но и для ваших данных», – советует Брей.
«Вам предстоит иметь дело с разнообразной, неоднородной, распределенной вычислительной средой, и вам необходимо создать платформу для доступа к данным и их хранения, обладающую такой же гибкостью и разнообразием. Если вы неправильно получаете данные и не можете найти то, что вам нужно, чтобы принять правильное решение, тогда вся остальная работа, которую вы делаете, по сути, ни к чему не приведет ».
При поддержке Red Hat.
