Что мешает развиваться автоматизации бизнес-процессов в онлайн-рекрутинге:
Задачи рекрутинга
Человеческий фактор
Социальные сети как инструмент рекрутера
«Уберизация» – наше всё
Да действительно, понять что конкретно мешает, даже по названиям разделов и беглому прочтению, — довольно сложно.
Могу лишь догадаться что это отсутствие вменяемого позиционирования, закрытость и непрозрачность большинства проектов, направленность на выдаивание денег с клиентов на определённом этапе жизненного цикла.
Для меня эта статья — наглядный пример что с гигабитным трафиком надо априори лезть в DPDK, и не молится форточным богам что бы ничего не отваливалось.
У вас, может быть, и нельзя, но не нужно генерализировать и применять свои обстоятельства ко всем вокруг — подобные подходы уже 6-7 лет как используются. То что у всех якобы должна возникать "головная боль" — это ваше личное субъективное суждение.
Либо ищут человека способного рубить леса пилочкой для ногтей, везде лепят популярные решения, без понимания их ограничений и целевых задач
Либо задача давалась для того что бы соискатель сказал пару ласковых интервьюеру, написал саму простую реализацию на питоне, и не пытался гнуть ель резинкой от трусов
Disclosure: тот же Twitch вот прямо сейчас дохнет при ~1600 зрителей, а при 2500 смотреть в СНГ вообще не реально, смотрится более-менее только в Штатах и в Великобритании потому что там как раз таки с CDNом у них проблем нет.
Сравнивать какой-то RTMP сервер «аля Wowza» на Хетзнере / OVH / Online.net со стриммингом рассчитанным на тысячи пользователей без лагов — весьма некорректно.
Если у ретрансляторов с тарелок пять-шесть сотен человек стабильного онлайна в сутки наберётся — это уже считается очень и очень большим успехом. Естественно под такие объёмы CDN не нужен, и если что-то будет глючить — пользователь просто перегрузит страницу… Со спортивными мероприятиями всё чуть серьёзнее: 5-7сек задержки во время матча — уже потенциальные сотни недовольных.
Ну олимпиада в Сочи последний раз транслировалась по Европе и в Штаты через Akamai, а по России у них основное направление — МСК/Питер да дальний/ближний восток.
Никто не будет держать пачку серверов/каналов в РФ если никто ими не пользуется, а о тех что пользуются, естественно, никто не расскажет, ибо это уже коммерческая тайна.
OK, а в чём преимущество перед конкурентами, тем же Akamai и Level3?
У них хотя бы есть выделенные каналы для вещания, вплоть до трансатлантической оптики…
PacketShader не рассматриваю так как он стены корейского Kaist'a с 2010'го не покинул.
Из-за низкой энергоэффективности и сомнительного вертикального масштабирования использование GPGPU для подобных задач довольно нецелесообразно. Естественно можно использовать всякие Xeon Phi или Tile GX, и они будут гораздо эффективнее. Иногда дешевле просто взять два старичка E5-2697 v2, просто потому что их уже давно купили и списали. На практике получается что решения на основе того же Kintex 7 и Kintex Ultrascale дешевле и эффективнее, сужу по тому же Mellanox Innova Flex 4, к примеру.
1. Да, INTEL_IOMMU_DEFAULT_ON и intel_iommu=on нужны. Если netmap справляется, значит нет требований к доступности и можно не заморачиваться — брать и использовать. DPDK нужен там где нужна максимальная доступность (минимальная задержка перед возможностью обработки следующего запроса).
2. Ага, пишу.
Если это Intel XL710, то там надо собрать ядро с INTEL_IOMMU_DEFAULT_ON и добавить intel_iommu=on параметр загрузки.
Там обычно используется PCI-to-PCI мост, который криво мапится через uio_pci_generic вышеупомянутым образом, в принципе если выгрузить драйвер моста, потом подгрузить VFIO и UIO вместо pci_generic родным скриптом dpdk_nic_bind.py, то по идее должно нормально стать (об этом тоже написано в статье).
На 40GbE интерфейсах pci_generic как-то никак плоховато работает.
Я сейчас переписываю bsd socket'ы на DPDK, что бы был полный dropin replacement, и можно было использовать как OpenOnload — поставил, подгрузил, и старый-бодрый nginx 38Gbit кушает на ура.
Под пропускной способностью имеется ввиду не пропускная способность сетевого интерфейса, а то сколько запросов Flume может обработать в секунду. Тут пишется о сценарии ~300-500Гб логов в час, с которого потом выжимается 120-250Гб.
Обычно потом пишут в БД и отрисовуют всякими graylog'aми и kibana. После устаревания утрамбовывают этот компост в "холодное" хранилище на магнитных лентах "аля бобинах", в сервисах типа Amazon Glacier, и подёргивают 6-7 раз в год.
В чистом виде логи писать в БД получается очень расточительно — БД растут как на дрожжах, да и не каждый может позволить себе завести кластер elasticsearch'ей для kibana. Ну, чуваков c elastic.co тоже можно понять, они то разрабатывали всё это не для того что бы в больших масштабах с пол-пинка заводилось — нужно ещё кучу граблей и костылей, а им с того копеечка за поддержку и наставление падаванов.
Вот у вас есть винт с пропускной способностью в 3Гбит'a и большими задержками¹ и есть оперативка с пропускной способностью в 12Гбит и низкими задержками¹, вот вы ж в оперативку пишите избыток того что пишется на винт, и потребление памяти будет расти в логарифмической прогрессии, в идеальных условиях.
Вот те же яйца и с kafka и flume: у вас есть flume со средней пропускной способностью и большими задержками¹, и есть kafka, с высокой пропускной способностью и низкими задержками¹, почти как запись в /dev/null.
kafka по своей природе любит кушать гигабайты и десятки гигабайт оператвы и слаживать всё в чистом виде на винт, прямо как на грампластинку. Потом это всё можно обработать 4-8 flume'ами, положить в другую kafk'у или сразу записать в БД.
¹ — под задержкой нужно понимать готовность устройства к обработке следующего запроса.
Что где использовать — зависит от объёма и скорости прироста логов, количества машин.
kafka спроектирована таким образом что бы работать в кластере, но вы не сможете получать наиболее актуальные данные в текущий момент времени. kafka это просто очередь событий/сообщений, никаких преобразований внутри не происходит. С flume ситуация совсем другая: он обрабатывает и преобразовывает логи в удобоваримый вид для последующей записи в БД hdfs / hbase / scylladb etc. flume может быть как потребителем (sink) данных с kafka, и преобразовывать логи, которые хранятся в очередях, так и поставщиком данных (source) для kafka.
По этому, это проекты с совершенно различными задачами.
Если вам не хватает пропускной способности flume — вы перед ним ставите kafka в качестве буфера.
Также очереди на kafka довольно просто реплицировать для обеспечения отказоустойчивости.
Flume является средством потоковой обработки логов, т.е. вместо низких задержек у него в приоритете высокая пропускная способность и возможность простого партицирования (consistency + partition tolerance + weak availability)
У Storm с точностью до наоборот — быстро обработали и отдали, в очередь больше положенного не кладём (availability + consistency + weak partitionioning)
У Kafka задача — обеспечить высокую доступность с возможностью партицирования, но со слабой консистентностью (availability + partition tolerance + weak consistency)
Сamel вообще не заморачивается с производительностью и доступностью — ему главное один интерфейс преобразовать в другой (consistency + whatever)
Грубо говоря, хаброобыватели из-за недопонимания специфических архитектурных решений высокодоступных или высокопроизводительных проектов сравнивают разные виды кошачих: тигра, гепарда, и льва; спрашивают: кто из них лучше добычу ловит? Вот надо сравнивать по обстоятельствам и ареалу обитания.
Уже писал похожий пост, но, видимо, его никто не заметил.
Что мешает развиваться автоматизации бизнес-процессов в онлайн-рекрутинге:
Да действительно, понять что конкретно мешает, даже по названиям разделов и беглому прочтению, — довольно сложно.
Могу лишь догадаться что это отсутствие вменяемого позиционирования, закрытость и непрозрачность большинства проектов, направленность на выдаивание денег с клиентов на определённом этапе жизненного цикла.
Для меня эта статья — наглядный пример что с гигабитным трафиком надо априори лезть в DPDK, и не молится форточным богам что бы ничего не отваливалось.
У вас, может быть, и нельзя, но не нужно генерализировать и применять свои обстоятельства ко всем вокруг — подобные подходы уже 6-7 лет как используются. То что у всех якобы должна возникать "головная боль" — это ваше личное субъективное суждение.
Почему нельзя? Статью не читай — комментарий пиши ?
Есть bemjson bemhtml bemtree от Яндекса, и оно у них в проектах раньше использовалось — HTML разметка в виде JSON'a в шаблонизатор уходит.
Это не NP полная задача, соответственно нейросети — неуместны.
Выводы:
Сравнивать какой-то RTMP сервер «аля Wowza» на Хетзнере / OVH / Online.net со стриммингом рассчитанным на тысячи пользователей без лагов — весьма некорректно.
Если у ретрансляторов с тарелок пять-шесть сотен человек стабильного онлайна в сутки наберётся — это уже считается очень и очень большим успехом. Естественно под такие объёмы CDN не нужен, и если что-то будет глючить — пользователь просто перегрузит страницу… Со спортивными мероприятиями всё чуть серьёзнее: 5-7сек задержки во время матча — уже потенциальные сотни недовольных.
Никто не будет держать пачку серверов/каналов в РФ если никто ими не пользуется, а о тех что пользуются, естественно, никто не расскажет, ибо это уже коммерческая тайна.
У них хотя бы есть выделенные каналы для вещания, вплоть до трансатлантической оптики…
Скорости в 2.2Мбита считаю смешными.
Из-за низкой энергоэффективности и сомнительного вертикального масштабирования использование GPGPU для подобных задач довольно нецелесообразно. Естественно можно использовать всякие Xeon Phi или Tile GX, и они будут гораздо эффективнее. Иногда дешевле просто взять два старичка E5-2697 v2, просто потому что их уже давно купили и списали. На практике получается что решения на основе того же Kintex 7 и Kintex Ultrascale дешевле и эффективнее, сужу по тому же Mellanox Innova Flex 4, к примеру.
2. Ага, пишу.
Если это Intel XL710, то там надо собрать ядро с INTEL_IOMMU_DEFAULT_ON и добавить intel_iommu=on параметр загрузки.
Там обычно используется PCI-to-PCI мост, который криво мапится через uio_pci_generic вышеупомянутым образом, в принципе если выгрузить драйвер моста, потом подгрузить VFIO и UIO вместо pci_generic родным скриптом dpdk_nic_bind.py, то по идее должно нормально стать (об этом тоже написано в статье).
На 40GbE интерфейсах pci_generic как-то
никакплоховато работает.Я сейчас переписываю bsd socket'ы на DPDK, что бы был полный dropin replacement, и можно было использовать как OpenOnload — поставил, подгрузил, и старый-бодрый nginx 38Gbit кушает на ура.
Надеюсь что статья была полезной.
p.s. обновите прошивку карты.
Недавно вышла хорошая книжка по похожей теме
Site Reliability Engineering
Edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy
Под пропускной способностью имеется ввиду не пропускная способность сетевого интерфейса, а то сколько запросов Flume может обработать в секунду. Тут пишется о сценарии ~300-500Гб логов в час, с которого потом выжимается 120-250Гб.
Обычно потом пишут в БД и отрисовуют всякими graylog'aми и kibana. После устаревания утрамбовывают этот компост в "холодное" хранилище на магнитных лентах "аля бобинах", в сервисах типа Amazon Glacier, и подёргивают 6-7 раз в год.
В чистом виде логи писать в БД получается очень расточительно — БД растут как на дрожжах, да и не каждый может позволить себе завести кластер elasticsearch'ей для kibana. Ну, чуваков c elastic.co тоже можно понять, они то разрабатывали всё это не для того что бы в больших масштабах с пол-пинка заводилось — нужно ещё кучу граблей и костылей, а им с того копеечка за поддержку и наставление падаванов.
Если объяснять на пальцах правой ноги, то:
Вот у вас есть винт с пропускной способностью в 3Гбит'a и большими задержками¹ и есть оперативка с пропускной способностью в 12Гбит и низкими задержками¹, вот вы ж в оперативку пишите избыток того что пишется на винт, и потребление памяти будет расти в логарифмической прогрессии, в идеальных условиях.
Вот те же яйца и с kafka и flume: у вас есть flume со средней пропускной способностью и большими задержками¹, и есть kafka, с высокой пропускной способностью и низкими задержками¹, почти как запись в /dev/null.
kafka по своей природе любит кушать гигабайты и десятки гигабайт оператвы и слаживать всё в чистом виде на винт, прямо как на грампластинку. Потом это всё можно обработать 4-8 flume'ами, положить в другую kafk'у или сразу записать в БД.
¹ — под задержкой нужно понимать готовность устройства к обработке следующего запроса.
CAP теорема
Что где использовать — зависит от объёма и скорости прироста логов, количества машин.
kafka спроектирована таким образом что бы работать в кластере, но вы не сможете получать наиболее актуальные данные в текущий момент времени. kafka это просто очередь событий/сообщений, никаких преобразований внутри не происходит. С flume ситуация совсем другая: он обрабатывает и преобразовывает логи в удобоваримый вид для последующей записи в БД hdfs / hbase / scylladb etc. flume может быть как потребителем (sink) данных с kafka, и преобразовывать логи, которые хранятся в очередях, так и поставщиком данных (source) для kafka.
По этому, это проекты с совершенно различными задачами.
Если вам не хватает пропускной способности flume — вы перед ним ставите kafka в качестве буфера.
Также очереди на kafka довольно просто реплицировать для обеспечения отказоустойчивости.
Было бы неплохо объяснить что:
Грубо говоря, хаброобыватели из-за недопонимания специфических архитектурных решений высокодоступных или высокопроизводительных проектов сравнивают разные виды кошачих: тигра, гепарда, и льва; спрашивают: кто из них лучше добычу ловит? Вот надо сравнивать по обстоятельствам и ареалу обитания.