Big data: новое золото инков
ТЕХНОЛОГИИ / НОЯБРЬ #8_2023
Записала Надежда ФЕТИСОВА / Иллюстрация: Кирилл ФИЛОНОВ
Что такое big data, как они родились и где хранятся? Можно ли похитить оттуда персональные данные? Какие вызовы нужно преодолеть новой отрасли и при чем тут закон Мура? Эти и другие вопросы в выпуске «Инженерного подкаста» НИЯУ МИФИ Александр Никоноров обсудил с менеджером по развитию бизнес-технологий, старшим вице-президентом «Раффайзенбанка», доцентом НИЯУ МИФИ Михаилом Ровнягиным. НАЭ публикует текстовую версию подкаста.
Послушать выпуск «Инженерного подкаста» о больших данных можно здесь
Михаил, давайте начнем с основ. Объясните, пожалуйста, что такое большие данные.
Есть классические характеристики больших данных (big data), три V: variety, velocity, volume. Подразумевается, что большие данные имеют значимый объем (volume), накапливаются с приличной скоростью (velocity), разнообразны и не всегда структурированы (variety). Можно сказать и так: большие данные — это такой набор информации, который невозможно обработать на мощном персональном компьютере, нужен набор серверов.
Большие данные сложнее искать, обрабатывать и структурировать, нежели реляционные базы данных. Этим занимаются так называемые data-инженеры.
Big data сегодня используются практически везде. Например, необходим мониторинг надежности серверов в дата-центре. Допустим, там 5 тыс. серверов, и если с каждого собирать хотя бы по три метрики, то вскоре нас захлестнет гигантский объем информации, которую необходимо обработать. А ценность этой информации, возможно, окажется невелика. Скорее всего, необходимы какие-то предварительные агрегации, с тем чтобы работать потом уже с ними.
Вторая ситуация: данные банковских транзакций. Их, по сравнению с метриками, не так много, однако важно, чтобы такие данные обрабатывались моментально: транзакция совершилась — и это сразу отразилось на показателях банка. То есть данных меньше, при этом их ценность больше.
Обе эти задачи будет решать инженер, владеющий стеком обработки технологий больших данных.
Еще один пример. Когда газета New York Times уходила в онлайн в 2007 году, редакции нужно было отсканировать гигантский объем публикаций за все предыдущие годы. И в решении этой задачи, осуществляемом в несколько этапов (сканирование публикаций, их обработка, распознавание текста, индексация и выкладка на сайт), тоже помогли big data. Кстати, это было одно из первых применений технологии Hadoop, лежащей в основе всего современного big data стека.
А что такое Hadoop?
Для начала объясню, что собой представляет технологический стек, которым пользуются специалисты по большим данным. Это программы или программные каркасы, позволяющие программисту упростить работу с данными.
В частности, для того чтобы реализовать метод k-средних (наиболее популярный метод кластеризации. — Прим. ред.), надо взять весь набор точек и заняться их обработкой на большом масштабе. То есть некое пространство не помещается в оперативную (и даже в постоянную) память одного сервера. Мы должны эту информацию нарезать, распределить по серверам, далее параллельно обработать, получить результаты, собрать их на одном сервере и выдать пользователю. Это параллельная обработка на множестве — или кластере — серверов. Задача сложная, велика вероятность ошибки. Для ее избежания придуманы фреймворки (готовые наборы инструментов, от англ. framework — каркас, структура), связанные с распределением и синхронизацией данных. Например, обеспечивающие барьерную синхронизацию: вычисления запускаются, все процессы дожидаются точки барьерной синхронизации, после чего вычисления продолжаются.
Таких каркасов уже немало. Первым, самым популярным фреймворком, написанным на языке Java для обработки больших данных, как раз и был проект Apache Hadoop. Можно упомянуть и такие фреймворки, как Apache Spark, Apache Kafka.
Еще один метод работы с big data — популярные нынче нейросети.
Сегодня на слуху фреймворк для обучения нейросетей TensorFlow. Его можно запускать в распределенном режиме на большом кластере машин.
В этом случае мы говорим, что метод анализа данных — это нейросети, а технологическая реализация — стек — это библиотека TensorFlow поверх серверов, оснащенных графическим ускорителем. Получается дуализм: есть метод, решающий определенную задачу, и есть технология — то, как это сделано «в железе». Наша лаборатория искусственного интеллекта и больших данных в НИЯУ МИФИ занимается и тем, и другим.
А ChatGPT вы используете?
Конечно. При достаточном уровне контроля со стороны человека — неплохая вещь для решения классических задач. Например, для того чтобы проанализировать научную статью и отделить контент, имеющий смысл, от «воды».
Можно сравнить ChatGPT с Google Translate (он, кстати, создан с применением нейросетевых технологий). Онлайн-переводчики, к которым все уже привыкли, раньше были глуповатыми, затем стали неплохо переводить технические тексты, а потом — и тексты общего назначения. ChatGPT тоже пока несовершенна: дает ссылки на несуществующие страницы, может выдать подряд практически одинаковые абзацы, но для определенных задач она применима.
Для решения задач, которыми занимается наша лаборатория, использовать генеративные текстовые нейросети пока рано. Например, одна из наших интересных задач — планирование и размещение вычислений по серверам. Когда я поставил соответствующую задачу ChatGPT, сеть ответила, что она не программист, и предложила ряд ссылок на тексты по планированию вычислений. Часть ссылок были нормальными, другие вели в пустоту. На этом помощь ChatGPT закончилась.
На запрос: «Напиши банковский процессинг» нейросеть скромно ответила, что она робот и банковский процессинг написать не может, но знает, из каких частей он состоит. При дополнительных вводных, конкретизируя, как должны выглядеть эти части, ChatGPT позволяет сгенерировать более или менее рабочий код. Каких-то моментов он не учитывает, скорость разработки близка к скорости разработки знающим человеком в известной ему предметной области. Так что пока запросы ChatGPT для нас — пустая трата времени с прикладной точки зрения.
Предлагаю перейти к инженерному блоку. Расскажите, пожалуйста, как устроена инфраструктура хранения массива данных.
Начну с печальной истории. В США была компания, дата-центр которой располагался в одной башне-близнеце Международного торгового центра в Нью-Йорке, а резервный ЦОД — в другой его башне. Что случилось с ними, думаю, объяснять не надо. Отсюда вывод: резервные мощности должны находиться в географически разнесенных точках, и между ними должен быть хороший канал связи. Я сталкивался с ситуациями, когда канал перерубали экскаваторщики. Вывод: технологии, отвечающие за хранение данных, должны учитывать все подобные факторы.
Кроме того, все данные на один сервер не упаковать. Берем какую-нибудь хорошую систему управления базами данных (СУБД) — скажем, PostgreSQL, внутри на одном сервере хранятся таблицы, связанные друг с другом. Если нужно получить связанную информацию из таблиц, мы их объединяем в оперативной памяти и выдаем эту информацию, никаких проблем.
Как только всё перестает помещаться на один сервер, сразу начинаются вопросы: где должен стоять второй сервер? Какова будет задержка доступа к нему? Где будем объединять информацию — на этом сервере или на том, куда мы ее вынесем? Сплошные проблемы. Поэтому все системы хранения больших объемов данных устроены по другому принципу: они имеют репликацию, то есть тиражирование данных, осуществляемое в одноранговой сети: там нет ведущих и ведомых серверов — все сервера ведущие и могут вносить изменения в данные.
При этом в хороших системах хранения (например, Apache Cassandra) есть механизмы, позволяющие отселять копии данных на удаленные сервера. Это сделано для геораспределенности, для обеспечения отказоустойчивости хранения. Инженер, разворачивающий подобную систему, говорит: «У меня есть дата-центр, он состоит из стоек, в стойках стоят сервера». Из этого можно сделать вывод, что серверов достаточно много — может быть, десяток, без учета коммуникационного оборудования. 10 серверов в стойке, 10 стоек — уже 100 серверов. И это только одно помещение. А еще нужно поместить копии в remote дата-центр, там тоже развернуть что-то похожее.
Есть вопросы, которые сейчас аукаются в связи с вопросами импортозамещения. Условный RuTube тормозит, потому что не развита сеть доставки контента: нет локальных копий данных, куда пользователь может подключиться, поближе с географической точки зрения. Такие проблемы тоже решаются системами хранения больших данных.
Если в дата-центре хранятся данные личного характера (например, банковские), можно ли, войдя в этот дата-центр, их украсть?
Известно, что подельник Эдварда Сноудена выносил диски с информацией в карманах брюк. В принципе, безопасность зависит от инженеров, которые разворачивали систему, — во многих системах хранения есть механизм transparent data encryption (прозрачное шифрование данных). Пользователь сохраняет свои персональные данные, они шифруются и хранятся на диске в зашифрованном виде.
Также есть оконечные (сквозные) системы шифрования, поддерживаемые на уровне операционной системы: сама система все, что к ней прилетает, хранит на дисках в шифрованном виде, а мастер-пароль берет из облака.
Перед тем как любая промышленная система вводится в эксплуатацию, выполняется так называемая проверка безопасности приложения (application security review) — проверяются моменты, связанные с безопасностью: есть ли шифрование, защищено ли оно паролями, корректно ли выполнена сертификация систем без шифрования и т. д.
Конечно, инженеры мыслят линейно, а хакеры — нелинейно, но «защита от дурака» точно не повредит.
Как используются большие данные в науке?
Первые системы распределенной обработки данных и появились благодаря науке — ученые генерировали такой гигантский объем информации, которой невозможно было обработать на одном сервере.
Например, в середине 2000‑х годов были популярны так называемые грид-системы. Работали они следующим образом: где-то генерировались данные, информация об этом поступала на узлы участников грид-системы. Узлы эти данные обрабатывали и возвращали в центр обработки, где хранились финальные результаты. К такой системе легко добавить новые вычислительные узлы — это плюс. Но есть и существенный минус — пропускная способность сети. Грид-системы — очень сильно распределенные системы, Интернет тогда был небыстрый. Так что гораздо эффективнее было обращаться к данным, лежащим на локальном диске, а лучше — в локальной оперативной памяти, а еще лучше — прямо в процессорах. Тем не менее распределенными грид-системами пользовались многие, например ЦЕРН: она предоставляла платформу, к которой подключались различные научные организации, в том числе МИФИ.
Было большое количество открытых (open-source) добровольческих проектов — таких, например, как SETI@home (от англ. Search for Extra-Terrestrial Intelligence at Home) — некоммерческий проект, направленный на поиск внеземных форм жизни. Он использовал свободные вычислительные мощности волонтеров для анализа радиосигналов, полученных проектом SETI. За 20 лет проект обработал все имеющиеся данные и в 2020 году был заморожен.
По сути, такие геораспределенные вычисления — это первые системы обработки больших данных по всему миру, произошедшие из науки.
Коммерсанты и промышленники подумали, что подход неплохой, только зачем создавать географически распределенные системы, если можно построить дата-центр, где сервера будут стоять рядом? Их свяжет сеть интерконнект, и задачи будут решаться быстрее.
Подход поменялся: если проекты типа SETI@home — это перемещение данных к коду, то сейчас коды перемещаются к данным. Есть система хранения, данные лежат на серверах дата-центра, и к ним подселяется программка, которая их обрабатывает.
Технологии big data используют все современные крупные научные проекты, по-другому никак. Адронный коллайдер генерирует гигантский объем информации. У ученых есть свои дата-центры, там применяются те же методы, которые использует коммерция для анализа больших данных бизнеса.
Какие проблемы сейчас у big data?
Главная проблема — инженеров не хватает. Еще есть сложности общевычислительного характера: объем данных на планете растет по экспоненте. Не все данные одинаково полезны, но все их нужно, во‑первых, где-то хранить, во‑вторых, успевать обрабатывать; то есть процессоры и оперативная память должны быть достаточно быстрыми, чтобы справляться с их обработкой. И вот тут мы концептуально, фундаментальным образом упираемся в закон Мура. Напомню, что руководитель Intel Гордон Мур эмпирически вывел правило, согласно которому количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые два года. Вся отрасль на это ориентировалась: считалось, что через два года, выпуская тот же объем процессоров, можно будет обрабатывать в полтора раза больше данных. Либо можно увеличить объемы выпуска и обрабатывать кратно больше данных.
Однако сейчас это правило работает не всегда: выпускать кристаллы площадью 3−4 нанометра технологически сложно, на выходе — большое количество брака. Процесс миниатюаризации компьютеров продолжается, возникают новые проблемы. В результате объем данных растет, а промышленность не может выпустить столько машин, сколько необходимо для их обработки — часто это даже коммерчески невыгодно.
Поэтому перед разработчиками систем big data стоит серьезная задача: упаковать все необходимое, не упираясь в нехватку электронной компонентной базы. Это значит, что алгоритмы должны стать более совершенными, а код — более качественным.
Теперь давайте поговорим о перспективах отрасли. Какие шаги нужно предпринять для улучшения технологий?
Главное — отбирать светлые умы и внедрять их наработки. Одна небезызвестная китайская компания использует интересную методику: все опубликованные в научных журналах статьи на тему обработки и хранения больших данных мониторятся, анализируются внутри компании. Дальше происходит попытка внедрения описанных идей своими силами. Если попытка не удалась, то к работе в компании привлекается ученый, написавший статью.
У отрасли в целом большой научный потенциал. Если раньше много статей писались «в стол», то теперь технологические гиганты радуются новым идеям, готовы вкладывать в них миллионы долларов и внедрять их в свои бизнес-процессы. Иногда через какое-то время корпорации сливают наработки в открытый доступ, и они расходятся по всему миру.
Другое дело, что авторы — ученые — далеко не всегда получают от этого прибыль. Возможно, дело дойдет до того, что научные статьи будут продаваться бизнесу — почему нет?
Есть классические характеристики больших данных (big data), три V: variety, velocity, volume. Подразумевается, что большие данные имеют значимый объем (volume), накапливаются с приличной скоростью (velocity), разнообразны и не всегда структурированы (variety). Можно сказать и так: большие данные — это такой набор информации, который невозможно обработать на мощном персональном компьютере, нужен набор серверов.
Большие данные сложнее искать, обрабатывать и структурировать, нежели реляционные базы данных. Этим занимаются так называемые data-инженеры.
Big data сегодня используются практически везде. Например, необходим мониторинг надежности серверов в дата-центре. Допустим, там 5 тыс. серверов, и если с каждого собирать хотя бы по три метрики, то вскоре нас захлестнет гигантский объем информации, которую необходимо обработать. А ценность этой информации, возможно, окажется невелика. Скорее всего, необходимы какие-то предварительные агрегации, с тем чтобы работать потом уже с ними.
Вторая ситуация: данные банковских транзакций. Их, по сравнению с метриками, не так много, однако важно, чтобы такие данные обрабатывались моментально: транзакция совершилась — и это сразу отразилось на показателях банка. То есть данных меньше, при этом их ценность больше.
Обе эти задачи будет решать инженер, владеющий стеком обработки технологий больших данных.
Еще один пример. Когда газета New York Times уходила в онлайн в 2007 году, редакции нужно было отсканировать гигантский объем публикаций за все предыдущие годы. И в решении этой задачи, осуществляемом в несколько этапов (сканирование публикаций, их обработка, распознавание текста, индексация и выкладка на сайт), тоже помогли big data. Кстати, это было одно из первых применений технологии Hadoop, лежащей в основе всего современного big data стека.
А что такое Hadoop?
Для начала объясню, что собой представляет технологический стек, которым пользуются специалисты по большим данным. Это программы или программные каркасы, позволяющие программисту упростить работу с данными.
В частности, для того чтобы реализовать метод k-средних (наиболее популярный метод кластеризации. — Прим. ред.), надо взять весь набор точек и заняться их обработкой на большом масштабе. То есть некое пространство не помещается в оперативную (и даже в постоянную) память одного сервера. Мы должны эту информацию нарезать, распределить по серверам, далее параллельно обработать, получить результаты, собрать их на одном сервере и выдать пользователю. Это параллельная обработка на множестве — или кластере — серверов. Задача сложная, велика вероятность ошибки. Для ее избежания придуманы фреймворки (готовые наборы инструментов, от англ. framework — каркас, структура), связанные с распределением и синхронизацией данных. Например, обеспечивающие барьерную синхронизацию: вычисления запускаются, все процессы дожидаются точки барьерной синхронизации, после чего вычисления продолжаются.
Таких каркасов уже немало. Первым, самым популярным фреймворком, написанным на языке Java для обработки больших данных, как раз и был проект Apache Hadoop. Можно упомянуть и такие фреймворки, как Apache Spark, Apache Kafka.
Еще один метод работы с big data — популярные нынче нейросети.
Сегодня на слуху фреймворк для обучения нейросетей TensorFlow. Его можно запускать в распределенном режиме на большом кластере машин.
В этом случае мы говорим, что метод анализа данных — это нейросети, а технологическая реализация — стек — это библиотека TensorFlow поверх серверов, оснащенных графическим ускорителем. Получается дуализм: есть метод, решающий определенную задачу, и есть технология — то, как это сделано «в железе». Наша лаборатория искусственного интеллекта и больших данных в НИЯУ МИФИ занимается и тем, и другим.
А ChatGPT вы используете?
Конечно. При достаточном уровне контроля со стороны человека — неплохая вещь для решения классических задач. Например, для того чтобы проанализировать научную статью и отделить контент, имеющий смысл, от «воды».
Можно сравнить ChatGPT с Google Translate (он, кстати, создан с применением нейросетевых технологий). Онлайн-переводчики, к которым все уже привыкли, раньше были глуповатыми, затем стали неплохо переводить технические тексты, а потом — и тексты общего назначения. ChatGPT тоже пока несовершенна: дает ссылки на несуществующие страницы, может выдать подряд практически одинаковые абзацы, но для определенных задач она применима.
Для решения задач, которыми занимается наша лаборатория, использовать генеративные текстовые нейросети пока рано. Например, одна из наших интересных задач — планирование и размещение вычислений по серверам. Когда я поставил соответствующую задачу ChatGPT, сеть ответила, что она не программист, и предложила ряд ссылок на тексты по планированию вычислений. Часть ссылок были нормальными, другие вели в пустоту. На этом помощь ChatGPT закончилась.
На запрос: «Напиши банковский процессинг» нейросеть скромно ответила, что она робот и банковский процессинг написать не может, но знает, из каких частей он состоит. При дополнительных вводных, конкретизируя, как должны выглядеть эти части, ChatGPT позволяет сгенерировать более или менее рабочий код. Каких-то моментов он не учитывает, скорость разработки близка к скорости разработки знающим человеком в известной ему предметной области. Так что пока запросы ChatGPT для нас — пустая трата времени с прикладной точки зрения.
Предлагаю перейти к инженерному блоку. Расскажите, пожалуйста, как устроена инфраструктура хранения массива данных.
Начну с печальной истории. В США была компания, дата-центр которой располагался в одной башне-близнеце Международного торгового центра в Нью-Йорке, а резервный ЦОД — в другой его башне. Что случилось с ними, думаю, объяснять не надо. Отсюда вывод: резервные мощности должны находиться в географически разнесенных точках, и между ними должен быть хороший канал связи. Я сталкивался с ситуациями, когда канал перерубали экскаваторщики. Вывод: технологии, отвечающие за хранение данных, должны учитывать все подобные факторы.
Кроме того, все данные на один сервер не упаковать. Берем какую-нибудь хорошую систему управления базами данных (СУБД) — скажем, PostgreSQL, внутри на одном сервере хранятся таблицы, связанные друг с другом. Если нужно получить связанную информацию из таблиц, мы их объединяем в оперативной памяти и выдаем эту информацию, никаких проблем.
Как только всё перестает помещаться на один сервер, сразу начинаются вопросы: где должен стоять второй сервер? Какова будет задержка доступа к нему? Где будем объединять информацию — на этом сервере или на том, куда мы ее вынесем? Сплошные проблемы. Поэтому все системы хранения больших объемов данных устроены по другому принципу: они имеют репликацию, то есть тиражирование данных, осуществляемое в одноранговой сети: там нет ведущих и ведомых серверов — все сервера ведущие и могут вносить изменения в данные.
При этом в хороших системах хранения (например, Apache Cassandra) есть механизмы, позволяющие отселять копии данных на удаленные сервера. Это сделано для геораспределенности, для обеспечения отказоустойчивости хранения. Инженер, разворачивающий подобную систему, говорит: «У меня есть дата-центр, он состоит из стоек, в стойках стоят сервера». Из этого можно сделать вывод, что серверов достаточно много — может быть, десяток, без учета коммуникационного оборудования. 10 серверов в стойке, 10 стоек — уже 100 серверов. И это только одно помещение. А еще нужно поместить копии в remote дата-центр, там тоже развернуть что-то похожее.
Есть вопросы, которые сейчас аукаются в связи с вопросами импортозамещения. Условный RuTube тормозит, потому что не развита сеть доставки контента: нет локальных копий данных, куда пользователь может подключиться, поближе с географической точки зрения. Такие проблемы тоже решаются системами хранения больших данных.
Если в дата-центре хранятся данные личного характера (например, банковские), можно ли, войдя в этот дата-центр, их украсть?
Известно, что подельник Эдварда Сноудена выносил диски с информацией в карманах брюк. В принципе, безопасность зависит от инженеров, которые разворачивали систему, — во многих системах хранения есть механизм transparent data encryption (прозрачное шифрование данных). Пользователь сохраняет свои персональные данные, они шифруются и хранятся на диске в зашифрованном виде.
Также есть оконечные (сквозные) системы шифрования, поддерживаемые на уровне операционной системы: сама система все, что к ней прилетает, хранит на дисках в шифрованном виде, а мастер-пароль берет из облака.
Перед тем как любая промышленная система вводится в эксплуатацию, выполняется так называемая проверка безопасности приложения (application security review) — проверяются моменты, связанные с безопасностью: есть ли шифрование, защищено ли оно паролями, корректно ли выполнена сертификация систем без шифрования и т. д.
Конечно, инженеры мыслят линейно, а хакеры — нелинейно, но «защита от дурака» точно не повредит.
Как используются большие данные в науке?
Первые системы распределенной обработки данных и появились благодаря науке — ученые генерировали такой гигантский объем информации, которой невозможно было обработать на одном сервере.
Например, в середине 2000‑х годов были популярны так называемые грид-системы. Работали они следующим образом: где-то генерировались данные, информация об этом поступала на узлы участников грид-системы. Узлы эти данные обрабатывали и возвращали в центр обработки, где хранились финальные результаты. К такой системе легко добавить новые вычислительные узлы — это плюс. Но есть и существенный минус — пропускная способность сети. Грид-системы — очень сильно распределенные системы, Интернет тогда был небыстрый. Так что гораздо эффективнее было обращаться к данным, лежащим на локальном диске, а лучше — в локальной оперативной памяти, а еще лучше — прямо в процессорах. Тем не менее распределенными грид-системами пользовались многие, например ЦЕРН: она предоставляла платформу, к которой подключались различные научные организации, в том числе МИФИ.
Было большое количество открытых (open-source) добровольческих проектов — таких, например, как SETI@home (от англ. Search for Extra-Terrestrial Intelligence at Home) — некоммерческий проект, направленный на поиск внеземных форм жизни. Он использовал свободные вычислительные мощности волонтеров для анализа радиосигналов, полученных проектом SETI. За 20 лет проект обработал все имеющиеся данные и в 2020 году был заморожен.
По сути, такие геораспределенные вычисления — это первые системы обработки больших данных по всему миру, произошедшие из науки.
Коммерсанты и промышленники подумали, что подход неплохой, только зачем создавать географически распределенные системы, если можно построить дата-центр, где сервера будут стоять рядом? Их свяжет сеть интерконнект, и задачи будут решаться быстрее.
Подход поменялся: если проекты типа SETI@home — это перемещение данных к коду, то сейчас коды перемещаются к данным. Есть система хранения, данные лежат на серверах дата-центра, и к ним подселяется программка, которая их обрабатывает.
Технологии big data используют все современные крупные научные проекты, по-другому никак. Адронный коллайдер генерирует гигантский объем информации. У ученых есть свои дата-центры, там применяются те же методы, которые использует коммерция для анализа больших данных бизнеса.
Какие проблемы сейчас у big data?
Главная проблема — инженеров не хватает. Еще есть сложности общевычислительного характера: объем данных на планете растет по экспоненте. Не все данные одинаково полезны, но все их нужно, во‑первых, где-то хранить, во‑вторых, успевать обрабатывать; то есть процессоры и оперативная память должны быть достаточно быстрыми, чтобы справляться с их обработкой. И вот тут мы концептуально, фундаментальным образом упираемся в закон Мура. Напомню, что руководитель Intel Гордон Мур эмпирически вывел правило, согласно которому количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые два года. Вся отрасль на это ориентировалась: считалось, что через два года, выпуская тот же объем процессоров, можно будет обрабатывать в полтора раза больше данных. Либо можно увеличить объемы выпуска и обрабатывать кратно больше данных.
Однако сейчас это правило работает не всегда: выпускать кристаллы площадью 3−4 нанометра технологически сложно, на выходе — большое количество брака. Процесс миниатюаризации компьютеров продолжается, возникают новые проблемы. В результате объем данных растет, а промышленность не может выпустить столько машин, сколько необходимо для их обработки — часто это даже коммерчески невыгодно.
Поэтому перед разработчиками систем big data стоит серьезная задача: упаковать все необходимое, не упираясь в нехватку электронной компонентной базы. Это значит, что алгоритмы должны стать более совершенными, а код — более качественным.
Теперь давайте поговорим о перспективах отрасли. Какие шаги нужно предпринять для улучшения технологий?
Главное — отбирать светлые умы и внедрять их наработки. Одна небезызвестная китайская компания использует интересную методику: все опубликованные в научных журналах статьи на тему обработки и хранения больших данных мониторятся, анализируются внутри компании. Дальше происходит попытка внедрения описанных идей своими силами. Если попытка не удалась, то к работе в компании привлекается ученый, написавший статью.
У отрасли в целом большой научный потенциал. Если раньше много статей писались «в стол», то теперь технологические гиганты радуются новым идеям, готовы вкладывать в них миллионы долларов и внедрять их в свои бизнес-процессы. Иногда через какое-то время корпорации сливают наработки в открытый доступ, и они расходятся по всему миру.
Другое дело, что авторы — ученые — далеко не всегда получают от этого прибыль. Возможно, дело дойдет до того, что научные статьи будут продаваться бизнесу — почему нет?
ДРУГИЕ МАТЕРИАЛЫ