Павел Бернштам
Вернемся к нашему программисту Полю, с которым вместе мы постигали премудрости Облачных вычислений (https://nizinew.com/nauka/tochnye-nauki/chto-takoe-oblachnye-vychisleniya-i-zachem-oni-nuzhny.html ).
Поль начал работать в стартапе, который предлагал онлайн магазинам сервис аналитики. Все переходы пользователей по страницам вебсайта магазина и все транзакции магазина идут в наш стартап, а умные алгоритмы советуют — какие товары люди ищут и не находят, какие товары в какие дни недели должны быть на сайте, как улучшить структуру сайта, чтобы люди больше покупали, за какие товары люди готовы платить больше, какому посетителю сайта какую рекламу показывать и т.д. Поль простой программист, он не алгоритмист. Он не знает, как все эти алгоритмы работают, ему надо только сделать инфраструктуру, на которой побежит код, написанный этими яйцеголовыми алгоритмистами с третьей степенью и службой в 8200 за спиной.
Итак, Поль начинает по-простому — делает базу данных, в которой есть таблица для каждого магазина, и для каждого вида записей — это переходы посетителей между страницами, это транзакции (покупки) и т.д.
Алгоритмистам он говорит — скажите, какие выборки данных вам нужны, я скажу вам как их делать. И для каждой выборки пишет запрос к базе данных на языке SQL — стандартном языке обращений к реляционной (т.е. основанной на таблицах и связях между ними) базе данных.
Пишется код, пишутся тесты — всё бежит как надо. А вот руководство стартапа и нашло первого клиента — цветочный магазин Ивтаха в Иерухаме. В фирме празднование — получен первый чек от клиента!
Подключается к системе магазин Ивтаха, тут и там есть небольшие ошибки, но всё работает!
Тяжелая работа идет дальше — алгоритмисты пишут алгоритмы, маркетологи ищут какие бы еще виды аналитики поставлять магазинам, Поль делает красивый сайт с отчетами для пользователей, продавцы ищу следующих клиентов.
Как известно, главное в стартапе — это не программисты, а продавцы (это не шутка, если что) — дело пошло и вскоре клиентов было уже десять — супермаркет в Реховоте, магазин канцтоваров в Ришоне и т.д.
И начали люди жаловаться, что 1) некоторые сообщения до базы данных не доходят, а теряются 2) программы вычисления аналитики бегут слишком долго — часами, поэтому тяжело их отлаживать, улучшать, искать в них ошибки. Посмотрел Поль, и видит — действительно много ошибок при записи в базу данных, потому что база данных с нагрузкой не справляется. И по этой же причине долго бежит аналитика.
Пропадаем! — подумал Поль, но на свою удачу его пригласил поплавать на яхте бывший коллега Василий, и там, на яхте, на фоне заката, дал Василий Полю советы:
1. Разнести базы данных разных клиентов на разные компьютеры — всё равно между ними связи нет
2. Сделать копию базы данных на другом компьютере, копию которая будет автоматически синхронизироваться с основной базой данных. Запись будет в основную, а алгоритмы аналитики будут читать из read only копии! Более того, можно сделать несколько таких копий, чтобы алгоритмы друг другу не мешали!
И действительно! Помогло! Для каждого магазина в облаке Амазона Поль сделал отдельную ячейку сети, в которой был компьютер с основной базой данных и одной или более копиями для алгоритмов аналитики.
А тем временем руководство стартапа заключило договор с большой сетью супермаркетов Гипербэг по всему Израилю. До подключения их к системе оставалось два месяца и Поль, узнав, сколько записей в день будет генерировать эта сеть, решил протестировать — потянет ли его архитектура такие объёмы данных. Протестировал. Катастрофа. Не тянет. Число записей в базе данных росло на десятки тысяч каждую минуту и база данных на самом мощном и дорогом компьютере облачного сервиса была не способна справляться с записью такого объема данных. А алгоритмы аналитики, когда пытаются сделать запросы к базе данных с поисками корреляции между возрастом пользователя, его городом проживания и списком предыдущих покупок с тем, что он купит следующее, бегут целую неделю и всё никак не заканчиваются.
Короткое объяснение про аналитику: обычно для поиска каких-то статистических зависимостей, корреляций, машинного обучения стараются загрузить все данные в память компьютера — потому что доступ к памяти в тысячи раз быстрее, чем к жесткому диску. Если же у нас количество данных такое, что в память компьютера не влезет — тут начинаются проблемы.
На удачу Поля, его как раз позвали на месяц на резервистские сборы — август, жара, граница с Газой, всё как обычно. И в джипе, на патрулировании Поль поделился своей бедой с Авихаем, старым армейским товарищем. И вот, что ему рассказал Авихай:
— для обработки очень больших наборов данных, нужны совсем другие подходы. таких подходов может быть несколько, разных, в зависимости от типов данных (данные могут быть структурированные (как записи о покупках) и не структурированные (свободный текст — например сообщения людей в мессенджере)), от того в каком темпе они приходят и что с ними нужно делать — если темп, в котором данные приходят очень большой, можно применить асинхронную архитектуру — когда сообщения пишутся сразу не в базу данных или на диск (запись на диск занимает время) а в очередь в памяти, а уже из этой очереди много процессов параллельно читают и куда то записывают данные — каждый процесс на отдельном компьютере читает свой тип данных и сразу пишет на диск, чтобы успеть прочесть из очереди как можно больше и как можно быстрее.
Дисклеймер: вообще то это отдельная тема — приложения под высокой нагрузкой, и эту тему не всегда относят к большим данным. я просто хочу показать, что есть такая проблема — как обработать десятки тысяч сообщений в секунду и у неё есть решения.
— обычные базы данных (реляционные с таблицами и связями между ними) для ОЧЕНЬ больших объемов данных, для высокого темпа записи и поиска сложных корреляций не годятся, для этого есть другие типы хранилищ информации
— для того, чтобы что-то найти в огромных объемах данных существуют специальные алгоритмы, например, Map Reduce, придуманный в (сюрпрайз!) Гугле.
Как он работает? Ваши данные хранятся на очень многих компьютерах, сотни террабайт текстов на тысяче компьютеров. Вам надо, например, подсчитать сколько раз в ваших текстах встречается каждое слово. Свой алгоритм Вы составляете из двух частей:
1) Map — составить для каждого компьютера таблицу: слово -> число повторений этого слова в тексте 2) Reduce — взять несколько таких таблиц с разных компьютеров и слить в одну.
Эти два шага умная система запускает параллельно на разных компьютерах, чтобы получить конечный результат.
Перевести любой алгоритм (например, поиск корреляций в транзакциях из магазина) в такие два шага не всегда тривиально, поэтому позднее придумали всякие навороты — типа пишем запрос к такому набору (профессионалы говорят «кластеру») компьютеров в такой же форме, как к обычной базе данных, а умная система сама переведет это в шаги Map и Reduce и передаст другой умной системе, которая параллельно это всё запустит на всех компьютерах в кластере
Пришлось Полю, по возвращении из армии переписывать всю систему: хранение данных, запросы к данным, перевести алгоритмы в Map Reduce (кстати — совсем не тривиально!) и т.д.
За два месяца они, конечно не успели, но на их счастье сеть Гипербэг тоже была не готова через два месяца к интеграции с умным стартапом Поля.
Зато, когда всё было готово, система криво-косо, но работала, а вскоре её доработали напильником и прибыли сети Гипербэг благодаря аналитике умного стартапа выросли на 10%.
А система оказалась настолько удачной, что когда клиентом нашего стартапа стала всемирная сеть онлайн магазинов “Нозама”, оставалось только добавить компьютеров в кластер и всё! Нагрузки в 100 раз больше система построенная Полем выдержала.
Фирма “Нозама” купила стартап Поля и он уехал в трехнедельный трек по Альпам, где и сломал ногу в предпоследний день трека.
Вообще то настройка подобных систем самому может оказаться не простым делом, поэтому облачные сервисы кроме упомянутых в предыдущей статье (https://nizinew.com/nauka/tochnye-nauki/chto-takoe-oblachnye-vychisleniya-i-zachem-oni-nuzhny.html) сервисов предлагают и сервисы для больших данных — полностью готовая система, для которой пишешь алгоритмы и указываешь на скольких компьютерах их запустить (и платишь за них, платишь, платишь) или даже сервис с интерфейсом пользователя как у Экселя, с формулами и поисками, который на самом деле хранит террабайты данных на сотнях компьютеров — с таким реально можно работать как с экселем не зная программирования, но под капотом всё тоже самое — много компьютеров, каждый из которых содержит часть данных, запросы разбиваются на этапы Map и Reduce (или нечто подобное) и т.д.
Итак, как итог:
Большие Данные (Big Data) это такой баззворд, который все используют по делу и не по делу, но в устах технарей это означает обработку такого большого объема данных, что традиционные, старые, алгоритмы, инструменты, подходы к построению приложений с ними не справляются.
Соответственно для больших данных есть совсем другие инструменты, алгоритмы, подходы.
Существуют разнообразные инструменты, которые позволяют не изобретать велосипед, а использовать некую стандартную архитектуру, в которую просто встроить логику своего приложения
Большие данные возникают, как правило, когда за Вами кто-то следит — записи Ваших разговоров, покупок, перемещений по веб сайту, лайков в фейсбуке и т.д.
Писать приложения для больших данных очень сложно, поэтому всё время возникают инструменты, которые позволяют программистам работать по-старому или почти по старому, а всю работу делают под капотом. И с переменным успехом.
Надо еще учесть, что «большие данные» звучат привлекательно для инвесторов, начальников, журналистов. Поэтому иногда методы работы с большими данными используются там, где можно было бы без них обойтись, грамотно настроив старые добрые решения. Но если это привлечет инвесторов, или просто программисту захочется сделать запись в резюме «Big Data», то большие данные появляются и в презентациях, и в программах.
Сложно дать точную оценку начиная с какого количества данные становятся большими, это зависит от их использования, но если речь идет о террабайтах, если не получается с данными справится на одном компьютере и они делятся на несколько (или много) компьютеров, обработка на которых идет параллельно — это Большие Данные. Твиттер сохраняет 90 млн твитов каждый день. Даже если надо просто сохранить и по запросу быстро выдать любой твит за последние 10 лет — это уже не тривиально, это большие данные. А вот если у Вас 1 Тб данных, то выдать конкретную запись или набор записей по простому условию — это, скорее всего может быть решено простыми средствами. А если по 1 Тб данных надо провести машинное обучение — это может превратиться в сложную задачу, решаемую инструментами больших данных.
Иллюстрация: ppt-online.org
