Большие данные мертвы. В той их части, которая характеризуется как “большие”. Так считает Джордан Тигани, инженер-основатель Google BigQuery, человек, который больше 10 лет рассказывал всем о пользе big data. Что он имеет в виду и что это значит для бизнеса? Давайте разбираться.

Вспомним, что говорили про большие данные

Пятнадцать лет назад эксперты предполагали, что количество данных будет расти очень быстро. И для работы с ними придется изобрести новые инструменты и технологии.

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

Что же произошло?

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

По словам Джордана сейчас даже самые крупные компании имеют от 1 до 10 терабайт аналитических данных. А у большинства объем данных находится в диапазоне от 1 до 100 Gb. 

Технологии вполне поспевали за реальным, а не прогнозируемым приростом генерируемой информации. Сейчас средняя компания имеет около 10 Gb данных. И ей вполне хватает аппаратных мощностей, чтобы обработать их за секунды.

В 2006 году стандартный инстанс в AWS использовал 1 ядро и 2 Gb ОЗУ. Рабочая нагрузка на такую машину зачастую не помещалась полностью. 

Сейчас же стандартный инстанс AWS работает на физическом сервере мощностью 64 ядра ЦП и 256 Gb RAM, который по желанию клиента можно масштабировать до 24 ТБ оперативной памяти и 445 ядер ЦП. Много ли вы знаете нагрузок, которым требуется столько вычислительных ресурсов?

При этом данные распределяются неравномерно, и большинству компаний не нужно обрабатывать их гигантские объемы. Это привело к тому, что СУБД с традиционной SQL-архитектурой: SQLite, Postgres, MySQL по-прежнему популярны.

И что же мы сейчас имеем? Компаниям предлагают создать и внедрить целый имперский крейсер, тогда как им нужен всего лишь 1 X-wing, чтобы уничтожить Звезду Смерти.

При этом 10 Gb — это все-таки данные, из которых можно извлечь пользу.

Почему 10Gb — это big data?

Давайте представим средний интернет-магазин с клиентской базой в тысячу человек. Пусть каждый из клиентов размещает новый заказ каждый день. И в каждом таком ордере находится сотня позиций. Даже в этом случае сайт генерирует меньше мегабайта новых данных в день. И только почти через 3 года их будет 1Gb. 

Поэтому на первый план выходит не столько количество, сколько качество и подход к данным. То, как вы оцифровываете, храните и обрабатываете их. И делать это не так уж и сложно.

2 примера, которые это доказывают

Наглядный пример — сбор и обработка данных об общественном транспорте современного мегаполиса.

Организовать сбор и обработку данных о сотнях, а то и тысячах единиц техники и миллионах поездок, совершенных пассажирами, — это сложно. Но с этой задачей справится грамотно настроенная платформа, построенная на стеке Apache Kafka-Apache Spark-Greenplum.

Аналогичную по изящности платформу по сбору и обработке данных мы реализовали для сервиса Find My Kids. Это приложение, которое помогает родителям не беспокоиться о том, где находятся и что делают их дети, продвинутый GPS-трекер со встроенными функциями.

У приложения миллионы скачиваний в профильных магазинах, но для сбора и обработки данных они используют решение Kafka-Spark-Greenplum. Объем обрабатываемых данных при этом исчисляется даже не терабайтами, а сотней гигабайт.

Да что говорить, у мировых b2c-компаний их накапливается чуть больше 10 Tb. И даже такое количество данных благодаря современным технологиям можно хранить и обрабатывать быстро и без особых проблем.

В чем польза от этого для бизнеса?

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

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

В качестве примера облегченной платформы мы можем привести собственную разработку — лайт-версию нашего продукта ITS DPP. Почитать о её возможностях можно на сайте.

Комментарии (8)


  1. sshmakov
    05.09.2023 10:05
    +1

    1. volzhanin63
      05.09.2023 10:05
      +1

      все еще умирает


    1. ItsPavel Автор
      05.09.2023 10:05

      Ничего нельзя придумать. Всё, что ты придумываешь, либо было придумано до тебя, либо происходит на самом деле." -- Аркадий и Борис Стругацкие, "Хромая судьба".

      Вообще я пытался не столько перевести, сколько развить мысли Тигани)


      1. sshmakov
        05.09.2023 10:05
        +2

        Намерение благое. Только оригинальная статья гораздо более объемная и подробная, даже с графиками, так что у вас скорее синопсис. Плюс реклама, куда же без нее в корпоративном блоге.


  1. akakoychenko
    05.09.2023 10:05
    +8

    Рассуждения неверны

    Давайте представим средний интернет-магазин с клиентской базой в тысячу человек. Пусть каждый из клиентов размещает новый заказ каждый день. И в каждом таком ордере находится сотня позиций. Даже в этом случае сайт генерирует меньше мегабайта новых данных в день. И только почти через 3 года их будет 1Gb. 

    Да, магазин может хранить только историю заказов. Но, ведь

    1) есть куда больше посетителей, которые пришли на сайт, но не заказали ничего, и даже не зарегистрировались. Надо понимать, почему они отвалились. На каком действии они закончили свой путь? Что отличает их от тех, которые заказали. Что не так с сайтом, что они уходят? Почему они принимают решение уйти?

    2) зарегистрированный юзер как пришёл к заказу, и как не пришёл к заказу. Когда положил, и когда выложил с корзины (что повлияло на это). Когда скопировал название товара и потом вернулся, а когда не вернулся (скорее всего, нашёл у конкурента).

    3) нюансы регистрации, оплаты. Где отвал идёт. Где пользователь тупит, проводя неадекватно много времени.

    4) парсинг конкурентов. Как коррелирует разница цены с конкурентами с поведением пользователей, влияет ли это на конверсии на всех этапах? А если разбить при этом по группам товаров?

    Чтобы на все эти вопросы получить ответ, надо где-то х100-х1000 данных от изначально предложенных трекать. Вот уже и бигдата подкралась

    Все же, данные ж надо не только для бухгалтерии собирать, но, и, чтобы управленческие решения принимать


    1. ItsPavel Автор
      05.09.2023 10:05

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

      Соглашусь, что в зависимости от бизнес метрик увеличивается объем данных, которые нужно хранить и обрабатывать. Но несколько сомневаюсь, что в сравнении с примером они увеличатся на х100, если это не какой-то тяжелый тип данных, которые занимает много места.


  1. Ivan22
    05.09.2023 10:05

    из самой статьи нифига не понятно, но по сути я соглашусь. Принципы работы с данными таки не меняются, не зависимо от того биг там или не очень биг. Все теже ELT все те же дата модели, все те же KPI считаются, все так же работает принцип garbage in - garbage out. Только технологии новые, а суть та же


    1. ItsPavel Автор
      05.09.2023 10:05

      Буду стараться, чтобы было понятнее)