Привет, коллеги!

В феврале необязательно доставать чернила и плакать можно и радоваться.

Во-первых, Grafana заапрувила новую версию нашего плагина для мониторинга Kubernetes: KubeGraf v.1.5.0 доступен для инсталляции.

Во-вторых, оказалось, что за полтора года с момента выхода первой версии плагин скачали четверть миллиона раз!

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

Маленький дисклеймер:

наш продукт является переработанной версией официального плагина от Grafana (который не поддерживается уже около двух лет). Об истории его создания мы уже писали здесь, на Хабре. Напомню ключевые особенности KubeGraf:

• интеграция с k8s-api для построения карты ваших приложений, сгруппированных по неймспейсам / нодам-кластера + привязка к конкретным podам/сервисам;

• сводная страница со всеми ошибками / предупреждениями о работе нод и приложений кластера;

• возможность инсталляции плагина с облачными k8s-провайдерами через авторизацию с помощью bearer-tokena.

А что нового в пятом релизе? Много разного и полезного:

• совместимость с последними версиями Grafana;

• добавлена информация и визуализация лимитов по cpu/memory, добавлена индикация при превышении requested и приближению к limit, а также индикация того, что для какого-либо приложения не настроены requests/limits;

• в дашбордах по мониторингу deployments/daemonsets/statefulsets в разделе Templating теперь выводятся только те namespaceы, в которых содержатся ресурсы данного типа;

• в дашборде мониторинга конкретных podов исправлено отображение потребления cpu/memory;

• таблица с алертами и предупреждениями отсортирована в соответствии с severity (info/warning/critical);

• доработана инструкция по установке плагина и исправлены k8s-манифесты, необходимые для его установки (добавлены namespaceы);

+ мелкие доработки интерфейсов и навигации.

Пользуйтесь!

Кстати

Кстати, в качестве вспомогательной утилиты в процессе разработки нашего плагина мы создали helm-чарт, с помощью которого вы можете установить любую версию плагина из репозитория с его исходным кодом (например, используя определенный тег), не дожидаясь её появления в grafana-plugins-repository.

Все так же ждём ваших звездочек, issue и pull requests в нашем репозитории.

Обсудить плагин можно в нашем телеграм-чате или в Slack.

Привет! Я Илья Тананаев. Руковожу отделом первой линии техподдержки в ITSumma. И хочу поделиться опытом, как из поиска решения проблемы пропущенных чатиков с клиентами мы построили кузницу кадров. Успешно успевая при этом обрабатывать 3k+ клиентских обращений в сутки.

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

Придумали простое и утилитарное решение поставить между высококвалифицированными админами и клиентами первую линию поддержки, которая взяла бы на себя относительно простую работу по уточнению запросов. Но дальше случилось так, что бонусом к изначальной задаче мы открыли отличный способ развития компании и путь обучения недавно пришедших в IT специалистов.

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

С чего всё началось

ITSumma начиналась с того, что мы помогали сайтам выдерживать нагрузки и не падать при любых обстоятельствах. Сейчас, спустя 13 лет после основания компании, техподдержка уже далеко не единственное направление нашей работы, но по-прежнему существенное. У нас большой отдел эксплуатации, который следит за инфраструктурой клиентов и реагирует на инциденты 24/7 с SLA в 15 минут.

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

С ростом числа клиентов дежурным админам стало слишком тяжело одновременно решать свои обычные рабочие задачи и отвечать на запросы клиентов; начали появляться потерянные или неотвеченные клиентскиечатики. Мы поняли, что пора разделить контроль за отслеживанием входящих запросов и задач и, собственно, их исполнение.

Зачастую любой контроль ложится на плечи руководителя, но такая рутина, как принять задачу у клиента и передать её дальше не лучшее использование времени и сил менеджера. Эффективнее потратить их на более важные и подходящие по скиллам дела, а рутину делегировать отдельным специальным людям.

Так появилась первая линия поддержки.Вначале она состояла всего из... двух человек. Они должны были звонить и принимать звонки от клиентов, следить за всеми входящими обращениями и облекать их в задачи для админов. Плюс, что-то совсем простое делать сами и потихоньку обучаться новому.

Итерации решения

Сначала первая линия не работала 24/7, да и в принципе, не сразу взяла на себя работу с вообще всеми клиентами. Тем не менее, когда мы вышли на две стабильные смены с 7 утра по Москве (с 12 по Иркутску наш стандартный режим для большинства сотрудников) и с 11 по Москве в будние дни, это уже сильно сняло нагрузку с админов и помогло упорядочить работу. Мы поняли, что первая линия действительно полезна, а от админов круглосуточной техподдержки поступил запрос на работу первой линии не только в дневное время.

В 2019-м мы ввели еще смены для подстраховки на время пиковой нагрузки по будням с 10 утра по Москве. А позже, проанализировав ситуацию, решили, что нужно переводить первую линию на 24/7 чтобы помогать техподдержке всё время.

Итоги первого года работы первой линии:

• Избавили квалифицированных админов от рутины по звонкам и приёму обращений клиентов, сделав их работу более упорядоченной.

• Ответственным за SLA стал не только отдел эксплуатации, но и первая линия поддержки.

• Получили более надежный процесс обслуживания клиентов, в котором задачи не теряются, а выполняются вовремя.

• Сотрудники первой линии начали не просто передавать задачи и создавать таски, но и самостоятельно выполнять некоторые из них, например, обновлять сертификаты. Чем помогли админам эффективнее использовать свои ресурсы.

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

Постепенно на первую линии перешло реагирование на некоторые алерты мониторинга, обновление сертификатов, редактирование конфигурации nginx и ssl certbot. Например, если у клиента в ночное время приходил алерт по продовой площадке и не резолвился, то нужно было оповестить клиента в течении 15 мин согласно SLA.

На картинке число обращений по одному их проектов, которое ежемесячно обрабатывают самостоятельно бойцы первой линии. Понятно, что сложность у них разная, но объёмы всё равно можно представить. Дополнительно мы строим еще кучу графиков в Redash по дням недели, по часам и т.д., чтобы распределять дежурства, соответствующие нагрузке.

Расписание для людей

Проблема приема обращений решилась, но с учётом перехода на круглосуточный режим надо было утрясти расписание работы сотрудников. Если смены просто зафиксировать, условно два через два, то в разные месяцы получится разное количество смен и люди будут то перерабатывать, то не дорабатывать (по ТК должно быть определенное количество часов за период).

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

Мы попробовали разные варианты: 8- и 12-часовые смены, только дневные и только ночные, вперемешку и т.д. Вот что получилось:

• Думали было над 12-часовыми сменами вперемежку день/ночь но даже не стали пробовать на практике: поразмыслив, поняли, что это был бы жестокий удар по биоритму и здоровью.

• Пробовали чередовать 8-часовые вечерние и ночные смены, чтобы разброс был не такой большой, ритм нарушается все равно. В итоге люди не могут отоспаться и отдохнуть и просто неожиданно заболевают.

• Отдельно ночные и дневные дежурные вариант, которые устроил больше всего.

Дополнительно по мере развития отдела появились еще 8-ми часовые смены на дневное пиковое время в это время нагрузка самая большая, и 12 часов подряд её выдерживать тяжело. Сейчас у специалиста первой линии есть не только возможность выбрать подходящий ему график, но и расставить приоритеты для возможной ротации, как по времени, так и по отделам. Сотрудник оценивает по 5-балльной шкале удобство возможного времени работы, а также оставляет комментарии о том, какие у него предпочтения, либо внерабочая активность.

Развитие специалистов первой линии поддержки

Как я уже сказал, изначально первая линия поддержки появилась, чтобы переложить часть нагрузки с плеч высококвалифицированных специалистов на менее опытных коллег. Поэтому в целом мы не выставляем высоких требований к навыкам сотрудника первой линии: важно понимание работы веба и основ сервисов, ну и желание развиваться в администрировании. Но на разных этапах и в зависимости от потока кандидатов мы берём более подготовленных людей или акцентируем внимание на софт-скиллах.

Однако быстро выяснилось, что чем опытнее специалист первой линии, тем больше времени экономится на следующих этапах и быстрее решаются проблемы клиентов. Так в наших глазах (и в глазах наших сотрудников) работа в поддержке превратилась из обычной рутинной в трамплин для развития в IT. Поработав на передовой, ребята набираются опыта, растут как специалисты и переходят в другие отделы на более высокие должности.

Но это нам теперь понятно, что развитие выгодно и сотрудникам, и нам, как компании. А началось все очень прозаично и прагматично.

Таско-дни или командировки в другие отделы

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

Договорились с соседними отделами мониторинга и документации, что будем отправлять к ним людей на таско-дни в эти один-три дня сотрудники первой линии будут полностью заниматься задачами по документации или мониторингу, как будто они работают в этих отделах.

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

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

Эксперимент с таско-днями был удачным. Он наглядно показал пользу от выбранной тактики помогать развиваться нашим сотрудникам. Поэтому теперь мы всегда закладываем резерв под подобную практику, но сейчас это не несколько дней для нескольких человек, а полноценные две недели или, в последнее время, месяц для одного сотрудника первой линии, которые он работает в другом отделе. Мы называем это командировками.

Наши командировки похожи на стажировку, только лучше. За время месячной командировки человек успевает не только повысить свою квалификацию, но и принести пользу отделу, к которому он прикомандирован. В отличие от стажировки, на которую приходят совсем с нуля, сотрудник первой линии уже знаком с процессами в компании и быстрее входит в курс дела. У него есть мотивация на рост. И возможность понять, что ему ближе и как он хочет дальше развиваться.

К тому же, есть пространство для манёвра. По результатам командировки, если навыков еще недостаточно, можно спокойно вернуться в первую линию и там подрасти в выбранном направлении во время относительно малой загруженности браться за задачи для саморазвития под контролем более опытных коллег. В случае же испытательного срока или стажировки приходится расставаться, если отведенного времени не хватило.

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

Направления для командирования сотрудников первой линии поддержки такие:

• документация;

• мониторинг;

• эксплуатация;

• дежурства второй линии;

• аккаунтинг;

• и даже разработка.

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

Это нас возвращает к тому, зачем понадобилось автоматизировать обучение. Компания быстро развивается, есть много возможностей для роста, и в итоге достаточно часто на первую линию нужны новички (не путать с текучкой, её у нас как раз нет). Так настройка системы обучения и knowledge sharing превратились в приоритетные задачи.

Онбординг-курсы

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

Документирование нашей работы прошло довольно стандартный путь:

• Понятно, что сначала документации как таковой не было были разрозненные наброски.

• На первой итерации по улучшению я выделил время и постарался её систематизировать стало чуть лучше, но еще не достаточно.

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

• Третья итерация не конечная точка, а непрерывная работа по улучшению. Мы собираем отзывы новичков, исправляем и расширяем то, где обнаруживаются недостаточно понятные места. Вообще фидбэк новичков очень полезен, а когда они еще и дописывают недостающую информацию, это вообще супер.

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

Еще несколько месяцев назад, чтобы ввести в курс нового коллегу, кому-то из менеджеров или более опытных сотрудников приходилось ртом рассказывать всё самое важное, знакомить с основными инструментами, сидеть рядом и показывать, что нужно сделать в каждом случае. Это два-три полных дня и еще пару недель регулярных индивидуальных консультаций долго и трудозатратно.

Для автоматизации процесса онбординга поднялиMoodle и сделали свои курсы. Они состоят из некоторой справочной информации, видеоуроков и тестов. У роликов есть временне метки с описаниями, поэтому к такому материалу удобно возвращаться, если позже понадобится что-то уточнить.

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

При проверке скрипта на корректность перед запуском на какие критерии обращаем внимание?

1. block for commit.

2. block for delay.

3. PS/SQL file successfully completed.

4. exit.

5. set auto commit off.

6. current schema.

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

Пройти и курс, и тест можно пройти сколько угодно раз, это ни на что не влияет.

Можем ли мы изменять категорию задач вручную в созданной задаче? Если да, то где?

a. Можем, но аккуратно в Состояние.

b. Нет

c. Можем. В созданной задаче в правой колонке. Там, где Категория

d. Неее. Такого быть не может

e. Надо зайти в группы слева и там найти логово дракона. Вскрыть яйцо и после откроется тайна, где можно изменить категорию у задачи.

Как видите, это не похоже на строгую сертификацию. Это просто еще один способ помочь новому сотруднику усвоить много информации в короткие сроки.

После доработки документации онбординг курсы это лучшие инвестиции в развитие отдела.

Потратив один раз время и вложившись в автоматизацию стартового обучения, мы:

• Сэкономили время опытных специалистов на онбординг новичков.

• Уберегли главного наставника новичков от выгорания.

• Сделали онбординг качественнее (и это, пожалуй, главное). Когда один и тот же человек пятый-десятый раз рассказывает одно и то же, он легко может что-то пропустить, потому что путается, что кому уже рассказывал. С автоматическими курсами такое не произойдет.

И проверять, что человек точно всё понял и готов к боевой работе, с курсами гораздо проще и объективнее. Вообще, результат так всем понравился, что мы уже сделали обучение для отделов документации и мониторинга именно туда чаще всего вырастают из первой линии поддержки.

Результаты

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

Для сотрудников это хорошая возможность для старта карьеры: начальные требования очень лояльные и есть, куда расти. ITSumma занимается разными направлениями, так что новичок у нас может попробовать себя в разных областях и выбрать, что ему по душе. При этом мы расширяемся, поэтому способные люди точно не останутся без новых вызовов и повышения.

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

Сейчас в первой линии работает 13 человек, из них 4-5 постоянно находятся в командировках в бэк-отделах, получают новые знания и повышают имеющиеся. За время этого не очень-то длинного эксперимента уже 9 человек пошли на повышение. Например, первая линии поддержки была отправной точкой для тимлида отдела дежурств и тимлида отдела документации, специалистов в отделах документации, мониторинга, бэкапов и аккаунтинга.

И да, у нас больше нет проблем с пропущенными обращениями или невыполненными вовремя задачами от клиентов. Админы и дежурные не отвлекаются на звонки, а расходуют свои скиллы для решения сложных инфраструктурных задач.

Takeaways

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

Первая линия поддержки это просто пример. У любой IT-компании есть что-то, что могут делать новички: ручное тестирование, простая верстка, документация, скриптованное бэкапирование или обновление. Всегда можно найти подходящую песочницу.

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

Напоследок признаюсь, что были некоторые внутренние опасения, когда (уже больше года назад) мы перешли на удалённый режим работы и начали активно нанимать людей не из Иркутска, Москвы и Питера то есть городов нашего оффлайнового присутствия на момент коронавирусного перелома. Но опасались зря: у нас уже работает достаточно людей из ранее непривычных часовых поясов, и вообще,вакансии в отделе практически постоянно есть. В общем, разница во времени не помеха, если люди хотят работать, а мы хотим, чтобы они у нас работали.

Задача обогащения данных напрямую связана с темой их обработки и анализа. Обогащение нужно для того, чтобы конечные потребители данных получали качественную и полную информацию.

Сам термин "обогащение данных" это перевод англоязычного Data enrichment, который проводит аналогию между данными и... ураном. Точно так же, как промышленники насыщают урановую руду, увеличивая долю изотопа 235U, чтобы её можно было использовать (хочется надеяться, в мирных целях), в процессе обогащения данных мы насыщаем их информацией.

Обогащение данных это процесс дополнения сырых данных той информацией, которая в исходном виде в них отсутствует, но необходима для качественного анализа.

Конечными потребителями такой информации чаще всего являются аналитики, но могут быть и нейронные сети, пользователи приложения или предоставляемого API.

Заметим, что обогащение данных термин широкий, и получать данные из внешних источников можно весьма разнообразными способами. Например, представим бизнес-процесс регистрации нового клиента. Если в данных этого клиента отсутствует e-mail, то взаимодействие с внешним источником в этом случае может быть буквально следующим: взяли телефон, позвонили клиенту, узнали его e-mail. Получается, этот процесс может включать в себя такие совершенно не автоматизированные операции, как обычный телефонный разговор со всеми этими эс как доллар, "а" как русская. Это тоже можно считать обогащением данных, но данный пласт проблем в этой статье мы затрагивать не будем. Нас интересуют вполне конкретные случаи, когда данные хранятся в базе данных и именно БД служит внешним источником данных для обогащения.

Источниками сырых исходных данных могут быть:

• Система кассовых платежей, которая отслеживает транзакции и отправляет в хранилище данных: время, id торговой точки, количество и стоимость купленного товара и т.д.

• Логистическая система, которая отслеживает движение товара: id транспорта и его водителя, gps-координаты в заданные моменты времени, статус, маршрут и т.д.

• Телеметрия с датчиков интернета вещей.

• Система мониторинга инфраструктуры.

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

Таким образом, типовую задачу можно сформулировать следующим образом: на вход поступают данные вида <таймстамп, идентификатор источника, содержимое пакета>, а конечному потребителю требуется соединить (в смысле join) справочную информацию об источнике из хранилища данных с идентификатором источника из сырых данных.

Как обогащаем данные

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

Другой вариант использовать инструменты потоковой обработки данных. В этом случае нужно определиться, где же всё-таки хранить справочную информацию и что будет являться Single Source of Truth (SSOT), или единым источником истины для справочных данных. Если хранить справочные данные в хранилище, то к нему придется каждый раз обращаться, и это может быть накладным, так как к сетевым издержкам добавится ещё и обращение к диску. Вероятно, оптимальнее хранить справочную информацию в оперативной памяти или другом горячем хранилище, например, в Tarantool.

Мы, очевидно, отдаём предпочтению именно последнему варианту, и наша схема приобретает завершенный вид.

Она отличается от первой иллюстрации процесса обогащения данных тем, что появилась конкретика: процесс обогащения происходит на лету с помощью потокового обработчика, справочные данные хранятся в горячем хранилище (оперативной памяти).

Давайте посмотрим, какие плюсы и минусы мы получим, если возьмем за основу данную схему.

Преимущества потокового обогащения данных:

• В хранилище всегда актуальные данные, которые готовы к использованию. В нашем динамичном мире зачастую необходимо иметь доступ к реалтайм-данным и сразу их использовать, не тратя время на дополнительную подготовку, распаковку и т.д. Потоковый обработчик, можно сказать, приносит их нам на блюдечке.

• Схема хорошо масштабируется, если подобрать соответствующие технологии. С правильными инструментами можно масштабироваться под требуемую пропускную способность платформы и под объемы справочной информации.

Недостатки:

• Источник истины для справочной информации вынесен из надёжного дискового хранилища данных в менее надёжную оперативную память. При сбое это грозит потерей всех несинхронизированных данных.

• Требуется гораздо больше памяти как оперативной, так и постоянной. В целом, для любой системы аналитики желательно иметь побольше дискового пространства и оперативной памяти, но здесь это становится обязательным условием.

Какие технологии используем

Что касается технологий, то мы выбираем более-менее устоявшиеся на рынке решения с открытым исходным кодом и хорошей документацией, учитывая совместимость.

Выбранный стек технологий:

• Apache Kafka источник данных и брокер очередей;

• Apache Spark потоковый обработчик данных;

• Apache Ignite горячее хранение справочной информации;

• Greenplum и Apache Hadoop хранилище данных.

В выборе Greenplum мы немного поступились совместимостью. Связать его со Spark не совсем тривиальная задача, для этого не существует стандартного open source коннектора (подробнее рассказывали в этой статье). Поэтому мы разрабатываем такой коннектор сами.

В остальном набор достаточно стандартный. Hadoop держим на всякий случай, например, чтобы использовать тот же Hive поверх HDFS вместо Greenplum.

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

Итак, вот окончательные очертания нашей схемы обогащения данных.

Версии, которые используем:

• Apache Spark 2.4.6.

• Apache Ignite 2.8.1.

• Apache Kafka 2.4.1.

• Greenplum 6.9.0.

• Apache Hadoop 2.10.1.

Обращаю на это внимание, потому что от версий выбранных компонент зависит совместимость и возможность этих компонент взаимодействовать. Например, если нужно, чтобы Apache Spark писал данные в базу данных Greenplum, это может стать отдельной проблемой, и версии также будут важны. Наш коннектор на текущий момент работает именно со Spark v2, для Spark v3 его нужно отдельно дорабатывать.

Что в результате

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

Но есть и ограничения, связанные с тем, что source of truth, по сути, находится в оперативной памяти. Поэтому при редактировании справочной информации надо напрямую работать с Ignite через интерфейсы самого Ignite. Кроме этого, нужен аккуратный механизм синхронизации, чтобы кэш Ignite был персистентным. У Ignite есть собственный механизм для записи на диск, но все же Ignite больше ориентирован на работу в ОЗУ, поэтому для резервирования справочной информации в хранилище данных лучше использовать что-нибудь специально для этого предназначенное, например, Airflow.

Полезные ссылки, чтобы понять, как строить взаимодействие между Spark и Ignite и насколько это уже проработанный механизм:

• О том, как можно использовать содержимое базы Apache Ignite в качестве объекта dataframe, можно почитать здесь https://ignite.apache.org/docs/latest/extensions-and-integrations/ignite-for-spark/ignite-dataframe.

• Видео (на английском) про развитие Apache Ignite и его специфику, где-то с 12 минуты будет про использование Hadoop+Spark+Ignite https://databricks.com/session/fast-data-with-apache-ignite-and-apache-spark.

• Каким образом использовать Apache Spark + Apache Ignite (с хорошим и детальным техническим разбором), можно прочитать в блоге Сбербанка здесь же на Хабре http://personeltest.ru/aways/habr.com/ru/company/sberbank/blog/427297.

• Информацию о том, каким образом можно взаимодействовать с содержимым базы Apache Ignite через обычный интерфейс SQL, можно найти здесь https://ignite.apache.org/docs/latest/SQL/sql-api.

Пользуясь случаем: мы расширяем отдел систем обработки данных. Если вам интересно заниматься с подобного рода задачами, пишите мне в личку, в телеграм @its_ihoziainov или на job@itsumma.ru с пометкой data engineering.

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

Пятничный привет тебе, Хабр!

Если есть возможность в выходные отдыхать, а не работать это очень круто. А если получается отдыхать с пользой это круто вдвойне. Как? например, читая классные книги.
Мы, издательство ITSumma Press,постоянно ищем интересные и полезные иностранные книги, которые еще не переведены на русский язык. Я, например, частенько слушаю аудиоверсии не-технических книг, которые помогают разобраться в сложных темах без специального образования. И обзоры самых интересных находок время от времени я буду представлять здесь. Если какая-то книга многим покажется занимательной, мы поставим её в очередь на перевод!

Ну, а пока первый выпуск "ITS книгобзор". Сегодня расскажу вам, почему прямохождение стало причиной появления выдающейся женской груди и от том, как понять, роботы это поставщики прав и свобод или их потребители. Поехали!

Название: Unbound: How Eight Technologies Made Us Human and Brought Our World to the Brink

Автор: Richard L. Currier

Год издания: 2017

Доктор наук в области социокультурной антропологии, профессор в Беркли, Карриер последовательно и в деталях рассказывает о наиболее значимых, с его точки зрения, технологиях, которые кардинально повлияли на развитие человечества. Автор доступно показывает траекторию изобретений и анализирует последствия их появления для экономики, политики и этики. Сегодня расскажу вам самое запоминающееся о первых двух технологиях, а остальное и в деталях вы узнаете, если прочтёте оригинал.

Итак, палка. Она, родимая, была первой технологией человека. Для выкапывания корешков и сражения с врагами. Она же послужила тому, что мы стали прямоходящими. Хотя после выхода книги выдвигалась и другая теория. Кстати, по гипотезе Карриера, именно женщины начали использовать палку как инструмент.

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

Огонь удостоился отдельной главы. Из-за него мы потеряли волосяной покров по всему телу, развили новую функцию у самого большого нашего органа (хотя мы все знаем, что размер не главное) и оптимизировали пищеварительный тракт.

Автор, конечно же, останавливается и на печатном станке, и на часах, и на автомобилях. И приводит удивительные истории о том, как изобретение отдельного индивидуума может развернуть историю планеты на 180 градусов.

Отличная книга: научные теории и доказательства излагаются так легко и понятно, что даже дедушка на пенсии поймет, о чем речь. После прочтения\прослушивания у вас будет чёткое понимание, как мы спустились с деревьев и полетели в космос, по пути превратившись в любвеобильных невротиков и трудоголиков.

Актуальной книга будет всегда. Особенно, как мне кажется, для родителей. Прочитайте и узнаете, что отвечать на многочисленные детские Почему?

Название: Robot Rights

Автор: David Gunkelm

Год издания: 2018

Автор детально разбирает современные популярные подходы к вопросу прав роботов. Основной корпус книги посвящен четырем комбинациям пары могут иметь права должны иметь права:
1) могут, но не должны,
2) могут и должны,
3) не могут, но должны,
4) не могут и не должны.

Важно понимать, что до сих пор нет единого мнения о том, что\кто такие роботы. На это в огромной степени повлияли следующие факторы:

• sci-fi кинематограф и литература с многочисленными терминаторами, единым разумом и тп.

• сверхбыстрое развитие науки и технологий, которые с каждым годом подкидывают нам новые версии электронных созданий.

• многообразие функций и задач новых девайсов: от тостера для поджаривания хлеба до электронной собаки для эмоционального восстановления. Автор напоминает, что главное отличает tools от machines. Если первые заменяют предыдущие версии инструментов и выполняют грязную, тяжелую, унизительную работу (вспомнилось, что в английском это называется 3D works dangerous, dirty, demeaning), то machines заменяют самого человека. И не только на рабочем месте, но и в социуме норовят его полностью заместить, а то и поработить.

Во-вторых, остаются разногласия по поводу самой природы прав и их значения относительно роботов. Ганкел приводит отсылки ко множеству научных работ, где роботы рассматриваются не только в качестве потребителей (consumer) прав и свобод, но и в качестве поставщиков (producer).

Однако, хотя автор и не выделял это в отдельную проблему, все же главным затруднением в вопросе прав роботов видится то, что человек предрасположен наделять вещи человеческими качествами. В список significant others уже входят не только роботы-компаньоны, но даже современные пылесосы. Татьяна Черниговская как-то рассказала, как ее подруга постоянно норовила включить в комнате свет, чтобы пылесосу было светло убираться. Появился даже принцип when in doubt, treat as a human.

Казалось бы, проблема не стоит нашего внимания, ведь нужно лишь:

• четко разъяснять потребителям, что перед ними кусок дорогого пластика и проводов;

• подчеркивать целевую детерминацию роботов они созданы для того чтобы копать\вычислять\грузить денно и нощно;

• корректно выбирать названия для новых изобретений.

И вуаля, мы сумеем предотвратить эмоциональную привязку к роботам. Глядишь, мы перестанем извиняться перед своим автомобилем за колдобину на дороге или ласковым голосом упрашивать телефон удержать заряд в сорокоградусный мороз.

Но не все так просто. Автор приводит занятные примеры, когда даже эмоционально подкованные и просвещенные военные отказывались от машин-саперов, не желая видеть, как последние страдают. Люди продолжают относиться к машинам как к живым существам. Хотя, вспоминая знаменитый Chinese Room Argument, нам пора бы уже усвоить: даже если кажется, что тостеру больно, когда мы, например, резко дергаем его за шнур, это еще не означает, что тостеру действительно больно. Вообще, дихотомия being vs. appearing проходит красной нитью через всю книгу.

Книга заканчивается тем, что, возможно, нам стоит защищать права роботов даже не столько ради самих роботов (как в случае с животными, например), а ради самих людей:

• люди относятся к роботам так же, как они относятся к людям. И даже аристотелевский катарсис не работает: если человек выпустит гнев на робота, не факт что этот человек станет ангелом в общении с живыми людьми.

• несмотря на то, что взрослые люди понимают, что робот это механизм в обличье homo sapiens, они все равно должны к ним относиться как к людям. А все потому, что дети берут со взрослых пример и, не видя разницу между роботом и человеком, будут относится к людям так, как их родители\взрослые относились к роботам.

Еще больше новостей про интересные книги, книжную индустрию и разной полезной информации в нашем новом телеграм-канале ITSumma Press Книжная Среда. Наши редакторы делятся прочитанным. Обсуждать тоже можно в сопутствующем чате. Присоединяйтесь!