Big Data *

Источник

Привет, Хабр! Меня зовут Максим Пчелин, и я руковожу разработкой BI-DWH в MyGames (игровое подразделение Mail.ru Group). В этой статье по мотивам нашего с Диной Сафиной выступления на HighLoad++ Moscow 2019 я расскажу о том, как и зачем мы строили клиентоориентированное DataLake-хранилище.

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

Привет, Хабр! Отфильтровав для вас большое количество источников и подписок, сегодня собрал все наиболее значимые новости из мира будущего, машинного обучения, роботов и искусственного интеллекта за ноябрь. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие новости.

Для тех, кто не читал дайджест за октябрь, можете прочесть его здесь.

Итак, а теперь дайджест за ноябрь:

1. MIT разработал новый тип робота, который может расти как растение когда ему требуется дополнительная досягаемость.

Привет, Хабр! Отфильтровав для вас большое количество источников и подписок, собрал все наиболее значимые новости из мира машинного обучения и искусственного интеллекта за октябрь. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие новости.

Для тех, кто не читал дайджест за сентябрь, можете прочесть его здесь.

Итак, а теперь дайджест за октябрь:

1. Фотореалистичная 3D-модель человека выступила на TED. Нейросеть динамически восстанавливает 3D-модель человека на основе распознавания движения лицевых мышц. С помощью данных с камеры нейросеть распознает и восстанавливает эмоции и действия человека.

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

Если Вы — департамент Москвы, то выпустить ролик на федеральном канале и попросить людей прислать изображения счетчиков — не очень большая проблема. Но что делать, если Вы — маленький стартап, и сделать рекламу на телеканале не можете? Как получить 50000 изображений счетчиков в таком случае?

«Когда я слышу про распознавание образов, я никогда не спрашиваю, хорошие там алгоритмы или плохие. Я спрашиваю только, отличают ли они мотоцикл от трактора.» ©

В ClickHouse постоянно возникают задачи, связанные с обработкой строк. Например, поиск, вычисление свойств UTF-8 строк или что-то более экзотическое, будь то поиск типа учёта регистра или поиск по сжатым данным.

Всё началось с того, что руководитель разработки ClickHouse Лёша Миловидов o6CuFl2Q пришёл к нам на факультет компьютерных наук в НИУ ВШЭ и предложил огромное количество тем для курсовых и дипломов. Когда я увидел «Умные алгоритмы обработки строк в ClickHouse» (я, человек, который увлекается разными алгоритмами, в том числе экспериментальными), сразу же настроил планов, как сделаю самый крутой диплом. Мою радость и выражение лица можно описать следующей картинкой:

Приходит как-то на завод специалист по цифровизации. Здесь походил, там походил, лоб наморщил и говорит: «Я знаю, как у вас тут можно кое-что оптимизировать. Экономить конкретно будете! Дайте только мне доступ во-о-от к этим данным по производству». В ответ на заводе разводят руки. «Вот у нас по продажам аналитика. Вот по турбинам что-то есть — шибко умные турбины у Siemens. А по остальному оборудованию отродясь ничего не было».

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


Не каждое производство дошло до высокого технологического уровня. Но помогать нужно всем. На фото кадр из х/ф «Завод».

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

Хабр, привет. Перевел пост, который идёт строго (!) в закладки и передаётся коллегам. Он со списком блокнотов и библиотек ML и Data Science для разных отраслей промышленности. Все коды на Python, и размещены на GitHub. Они будут полезны как для расширения кругозора, так и для запуска своего интересного стартапа.



Отмечу, что если среди читателей есть желающие помочь, и добавить в любую из подотраслей подходящий проект, пожалуйста, свяжитесь со мной. Я их добавлю в список. Итак, давайте начнём изучение списка.

Во втором туре выборов губернатора Приморского края 16 сентября 2018 года встречались действующий и.о. губернатора Андрей Тарасенко и занявший второе место в первом туре коммунист Андрей Ищенко. В ходе подсчета голосов на сайте ЦИК РФ отображалась информационная панель с растущим числом обработанных протоколов и голосов за кандидатов.

Публикация подробных данных по участкам на официальном сайте ЦИК www.izbirkom.ru замерла после ввода 1484 (95.74%) протоколов и не возобновлялась до самого конца. Поэтому когда в трансляции лидер голосования вдруг поменялся с Ищенко на Тарасенко, было неясно, как именно это могло произойти. В СМИ просто писали «после обработки 99,03% протоколов лидер сменился».

Однако, располагая промежуточными суммарными данными из информационной панели, с помощью простой математики и программирования можно подробно установить, что именно происходило с протоколами в ночь после выборов. Используем Python, Colab от Google и Z3 theorem prover от Microsoft Research. Ну и добьём всё обычной дедукцией.

Что делать, если ваш запрос к базе выполняется недостаточно быстро? Как узнать, оптимально ли запрос использует вычислительные ресурсы или его можно ускорить? На последней конференции HighLoad++ в Москве я рассказал об интроспекции производительности запросов — и о том, что даёт СУБД ClickHouse, и о возможностях ОС, которые должны быть известны каждому.



Каждый раз, когда я делаю запрос, меня волнует не только результат, но и то, что этот запрос делает. Например, он работает одну секунду. Много это или мало? Я всегда думаю: а почему не полсекунды? Потом что-нибудь оптимизирую, ускоряю, и он работает 10 мс. Обычно я доволен. Но все-таки я стараюсь в этом случае сделать недовольное выражение лица и спросить: «Почему не 5 мс?» Как можно выяснить, на что тратится время при обработке запроса? Можно ли его в принципе ускорить?

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

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

Недавно мне поручили настроить процесс обработки большого объёма исходных последовательностей ДНК (технически это SNP-чип). Нужно было быстро получать данные о заданном генетическом местоположении (которое называется SNP) для последующего моделирования и прочих задач. С помощью R и AWK мне удалось очистить и организовать данные естественным образом, сильно ускорив обработку запросов. Далось мне это нелегко и потребовало многочисленных итераций. Эта статья поможет вам избежать некоторых моих ошибок и продемонстрирует, что же у меня в конце концов получилось.

14 мая, когда Трамп готовился спустить всех собак на Huawei, я мирно сидел в Шеньжене на Huawei STW 2019 — большой конференции на 1000 участников — в программе которой были доклады Филипа Вонга, вице-президента по исследованиям TSMC по перспективам не-фон-неймановских вычислительных архитектур, и Хенга Ляо, Huawei Fellow, Chief Scientist Huawei 2012 Lab, на тему разработки новой архитектуры тензорных процессоров и нейропроцессоров. TSMC, если знаете, делает нейроускорители для Apple и Huawei по технологии 7 nm (которой мало кто владеет), а Huawei по нейропроцессорам готова составить серьезную конкуренцию Google и NVIDIA.

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

Только в прошлом году в тему было вложено больше 3 миллиардов долларов. Google уже давно объявил нейросети стратегическим направлением, активно строит их аппаратную и программную поддержку. NVIDIA, почувствовав, что трон зашатался, вкладывает фантастические усилия в библиотеки ускорения нейросетей и новое железо. Intel в 2016 году потратил 0,8 миллиарда на покупку двух компаний, занимающихся аппаратным ускорением нейросетей. И это при том, что основные покупки еще не начались, а количество игроков перевалило за полсотни и быстро растет.


TPU, VPU, IPU, DPU, NPU, RPU, NNP — что все это означает и кто победит? Попробуем разобраться. Кому интересно — велкам под кат!

При выполнении запросов в ClickHouse можно обратить внимание, что в профайлере на одном из первых мест часто видна функция LZ_decompress_fast. Почему так происходит? Этот вопрос стал поводом для целого исследования по выбору лучшего алгоритма разжатия. Здесь я публикую исследование целиком, а короткую версию можно узнать из моего доклада на HighLoad++ Siberia.

Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.



Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.

Кто мы такие и какие были предпосылки проекта?

Добрый день, меня зовут Лазарев Владимир, я руководитель BI-интегратора Аналитикс Групп. Мы делаем для бизнеса наглядные отчёты по маркетингу, продажам, финансам, логистике на базе ведущих аналитических платформ Qlik Sense, Power BI, Tableau.

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

И желательно, чтобы данные были интересными… :-)

Откуда появилась идея сделать этот отчёт?

Несколько лет назад Высшая школа экономики опубликовала статью о формировании цен на услуги девушек низкой социальной ответственности в Москве. Это были агрегированные данные анализа 1.800 анкет. Нам показались интересными данные, которые стоят за этими выводами социологов ВШЭ. И мы решили проработать эту тематику.

Когда участники HighLoad++ пришли на доклад Александра Крашенинникова, они надеялись услышать про обработку 1 600 000 событий в секунду. Ожидания не оправдались… Потому что во время подготовки к выступлению эта цифра улетела до 1 800 000 — так, на HighLoad++ реальность превосходит ожидания.

3 года назад Александр рассказывал, как в Badoo построили масштабируемую систему near-realtime обработки событий. С тех пор она эволюционировала, в процессе росли объёмы, приходилось решать задачи масштабирования и отказоустойчивости, а в определённый момент потребовались радикальные меры — смена технологического стека.



Из расшифровки вы узнаете, как в Badoo заменили связку Spark + Hadoop на ClickHouse, в 3 раза сэкономили железо и увеличили нагрузку в 6 раз, зачем и какими средствами собирать статистику в проекте, и что с этими данными потом делать.



О спикере: Александр Крашенинников (alexkrash) — Head of Data Engineering в Badoo. Занимается BI-инфраструктурой, масштабированием под нагрузки, руководит командами, которые строят инфраструктуру обработки данных. Обожает всё распределённое: Hadoop, Spark, ClickHouse. Уверен, что классные распределенные системы можно готовить из OpenSource.

Привет, Хабр!

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

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

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

Фото offerov.net

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

Red Hat Software, американская компания, выпускающая решения на основе свободной операционной системы Linux и другие программные продукты и услуги на основе открытого исходного кода, потеряет самостоятельность. Тут сразу по масштабности, эпичности и значимости сделки вспоминается похожая история из 2009 года о том, как "Oracle проглотила Sun". Та сделка имела весьма удручающие последствия. Интересно, чем все обернется на этот раз?

hdfan2: Сказка про Красную Шапочку на новый лад.

Компания IBM объявила о достижении соглашения о покупке компании Red Hat. Из пресс-релиза можно сделать вывод, что IBM приобрела Red Hat как поставщика «облачных решений» на базе открытых технологий и включает его в состав своего подразделения по «гибридному облаку» как самостоятельное подразделение. Это будет крупнейшее приобретение в истории IBM, отмечает Reuters.

Согласно сообщению, стороны достигли окончательного соглашения, предусматривающего покупку IBM всех эмитированных акций Red Hat по цене $190 за штуку, представляющих общую стоимость предприятия приблизительно в $34 миллиарда. На торгах в пятницу, 26 октября, на NYSE последняя сделка с акциями Red Hat была заключена по цене $117, а рыночная капитализация компании составила $20,53 миллиарда. Таким образом IBM приобретает Red Hat по цене на 60-процентов выше рыночной оценки. Для справки, капитализация IBM на данный момент составляет около 113.9 миллиарда долларов.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).