Кто работает с большими данными: о проектах и инструментах
Мы позвали в подкаст bigdata-разработчика. Но во время разговора оказалось, что наш герой — дата-инженер. А мы хотели обратиться к нему как к дата-аналитику — это вообще другие ребята. Но за то, как разместить эту «дату» в хранилище, всё равно часто отвечает инженер, и называется это data governance. А ещё там есть свои собственные администраторы.
На факультете bigdata-аналитики GeekBrains Артём Гогин ведёт курсы по Hadoop, Spark и Kafka, а ещё он bigdata-разработчик в Сбербанке. Благодаря Артёму мы разберёмся в специальностях и обязанностях, а также в том, что это он вообще преподаёт.
Послушать 20-й выпуск вы можете на разных платформах:
В этом посте мы собрали интересные цитаты из выпуска.
Про память в big data
— Big Data могут создать любые компании, всё зависит лишь от того, как часто они будут собирать информацию. Если мы хотим собирать информацию раз в секунду, то мы получаем один объём информации. Но если мы хотим собирать какие-то логи десять раз в секунду, мы мгновенно получаем в десять раз больше информации. Поэтому вопрос только в том, как часто и как детально мы собираем нашу информацию, от этого и зависит объём наших данных.
— Количество информации измеряется не только количеством строк, но и ресурсами, которые требуются для её обработки. Такое измерение мне больше нравится. Я люблю мерить информацию по гигабайтам оперативки, которые нужны для обработки этой информации. У каждого на компьютере есть оперативная память, каждый представляет, сколько у него на компьютере оперативной памяти и может соотнести мощность своего компьютера с мощностью промышленных кластеров, серверов. Я видел в Сбербанке промышленные сервера, которые содержат несколько сотен терабайт оперативки. По-моему, это достаточно красноречивое сравнение, если вы вспомните, сколько у вас на компьютере оперативки и посчитаете, во сколько раз больше может обработать сервер Сбербанка.
— Если мы хотим сделать какие-то выводы в рамках одной таблицы, например, посчитать сумму или среднее, то есть сделать довольно простые арифметические операции, то нам не нужно засовывать все данные в оперативку. Но если мы хотим выявить зависимость в данных, если мы хотим сравнить данные друг с другом, то тогда, скорее всего, нам потребуется постоянно сравнивать и загружать в оперативку весь объём данных и сравнивать друг с другом.
— Все эти железки становятся дешевле с каждым годом. Я даже слышал выступление на одной конференции в прошлом году, где рассказывали, что сейчас мы, разработчики, можем позволить себе делать просчёты в алгоритмах и использовать не самые лучшие алгоритмы для расчёта данных, потому что всё это окупается железом. Дешевле купить железку в два раза мощнее, чем купить разработчика, который сделает алгоритм в два раза лучше. Но на этой же конференции обещали, что скоро эта эра закончится и железки прекратят дешеветь постоянно.
Про профессии в big data
— Во многих организациях прослеживается три или четыре направления: дата-аналитики, дата-инженеры, дата-сайентисты и администраторы серверов. Эти четыре профессии очень тесно взаимодействуют в хранилище данных и делят круг задач между собой.
— Если кто-то приходит на роль дата-аналитика или дата-сайентиста, то он может представить сразу, чем он будет заниматься. Дата-инженер разрабатывает регулярную обработку данных так, чтобы можно было один раз разработать, поставить на расписание и забыть, чтобы оно работало годами без участия человека. Если кто-то больше хочет заниматься самими данными, смотреть, как данные приходят, какая информация содержится в таблицах, как данные между собой связаны, какая есть зависимость в данных, то тут нужно выбирать между дата-аналитиком и дата-сайентистом.
— Если кто-то хочет искать математический смысл в данных и с точки зрения математики рассматривать данные, то это дорога в дата-сайентисты. А если кто-то хочет больше общаться с людьми, больше решать бизнесовые задачи, помогать пользователям решить, какие данные принесут ту или иную пользу, можно ли будет понять удовлетворённость клиентов по этим данным, понять насколько хорошо совершаются платежи у клиентов, насколько востребованы кредиты у клиентов — то для взаимодействия с бизнесом лучше выбирать направление дата-аналитика.
— Администраторы больших данных не сильно отличаются от всех остальных администраторов, это те же самые люди, которые работают с Linux. Но теперь кроме Linux у них появляются всякие другие хранилища, базы и устройства, за которыми нужно следить, которые заточены для big data.
Про масштабирование в big data
— Вертикальная масштабируемость говорит нам о том, что необходимо в один сервер засунуть очень много железок. Если мы хотим улучшить сервер в два раза, нужно воткнуть в него в два раза больше железок. А горизонтальная масштабируемость говорит нам о том, что нам нужно поставить второй такой же сервер с такими же ресурсами и объединить их в одну систему. Для big data это очень важно, так как в один сервер засовывать железки будет дорого, потому что у одного сервера есть предел по подключению железок. Также один сервер может выключиться и мы тогда ничего не сможем сделать с нашей системой, не сможем ей помочь, восстановить, продолжить работу, если у одного компьютера просто перегорит проводок.
— Существуют некоторые решения, которые позволяют развёртывать целые базы в оперативке. То есть у нас в оперативке может лежать целая база данных, которая живёт только в оперативке, вообще не обращаясь к жёсткому диску. В таком случае часть оперативки может отходить под эти базы, часть могут резервировать некоторые ресурсы для себя, не пуская другие ресурсы в эту оперативку.
— Какой-то процесс может просто забрать себе несколько терабайт оперативки и даже его не использовать, но и не отдавать другим. То есть оперативка может просто простаивать. Но принято, что оперативка всегда может выключиться и тогда все данные пропадут. Потому что никто не застрахован от того, что у нас выключится сервер, выключится электричество в центре обработки данных, сломается маршрутизатор, туда перестанут приходить сетевые взаимодействия. Поэтому оперативка в принципе остаётся свободной по большей части, особенно в big data. В big data очень важны исторические данные и большой объём этих данных. Для того чтобы сделать какую-то операцию очень часто приходится обращаться к данным, которые были загружены год назад или даже несколько лет назад и их точно нет смысла хранить в оперативке или как-то использовать оперативку для хранения части данных - в любом случае все данные будут лежать на жёстком диске. Именно оттуда возьмутся эти данные и только для расчёта они загрузятся в оперативку, а потом опять удаляться.
— Почти из любого приложения можно выжать кучу данных. Если это магазин, то мы можем записывать и генерить огромное количество данных из кликов пользователей. Как они прокрутили мышкой, на какую картиночку ткнули, на какую кнопочку навели мышку и так далее. Каждый пользователь, когда заходит на сайт, водит мышкой по экрану очень много. И каждое движение мы можем отражать в наших данных. Получается, даже если у нас всего лишь тысяча посещений сайта в день, каждое посещение может насчитывать несколько сотен кликов мышкой. Итого мы получаем, что даже с тысячами клиентов в день мы имеем достаточно много записей по каждому конкретному действию клиента на сайте. Вопрос лишь в том как мы потом сможем использовать эти данные и какие выводы из них сделать. Причём такие выводы, чтобы мы потом могли ещё улучшить наш бизнес и улучшить наши продажи, если это магазин.
Про ошибки специалистов в big data
— Первое, на что я обращаю внимание и что когда-то было моей оплошностью в начале: я думал что если оно работает, особенно у меня на компьютере, особенно в моей базе данных, то оно будет также работать и в продакшене на настоящих данных, регулярных и особенно исторических. Моя ошибка была в том, что на моём компьютере данных не настолько много, насколько на промышленных серверах. И система локальная у меня тоже работает намного плавнее, потому что она одна, на одном компьютере, а не на тысяче компьютеров одновременно, ей ничто не мешает и её никто не пытается постоянно выключить, никто не борется с ней за ресурсы. И данные лежат в том виде, который мне хорошо известен.
— Основная задача дата-инженеров сделать так, чтобы про задачу можно было забыть и никогда не вспоминать. То есть чтобы она работала регулярно и безошибочно, без участия человека. Именно поэтому для дата-инженеров всегда есть соблазн сделать так, чтобы это работало только сейчас или на недельку вперёд, но потом, если это сломается, то уже не так важно. Дата-инженеры любят сделать задачу быстрее, чтобы от неё отделаться, чтобы её закрыть, но не подумать о том, что будет через полгода, через год, когда данные могут измениться, когда данные могут потеряться, когда может выключиться сервер и данные потребуется восстанавливать. Поэтому для дата-инженеров я бы посоветовал обратить внимание на то, что мы должны разрабатывать решения, которые работают не только пока мы на них смотрим и готовы что-то руками подоткнуть: руками данные перенести, удалить что-то лишнее. Нужно разрабатывать таким образом, чтобы всё восстановление, вся работа с ошибками шла также в автоматическом режиме, чтобы, если какой-то сервер отключится, если данные изменятся или потеряются, при следующем запуске нашего приложения нужные данные автоматически оставались, а ненужные автоматически удалялись.
Интересно? По ссылкам в начале статьи вы сможете послушать полную версию и подписаться на обновления подкаста ;) Оставайтесь с нами, впереди много классных выпусков!
Освоить востребованную профессию в Аналитике больших данных можно всего за полтора года на курсах GeekBrains.