Comments 33
Это что islandandroid.17bullets.com?
Интересно было бы посмотреть на такую статистику по группам вконтакте.
Так себе big data, все на одну машину даже помещается.
А где можно потрогать суточную выгрузку? :)
Какую БД вы используете для хранения такого объема данных?
Для данного исследования — никакую ;) Эта задача интересна логикой результата. Что же касается стандартных задач по анализу данных соцмедиа, то в них зачастую крайне важна оперативность обработки новых данных, когда счет идет на секунды — поток в сотни и тысячи неструктурированных сообщений в секунду нужно анализировать (в том числе и задействуя для части подпотоков медленные лингвомодули) на лету. Поэтому используется связки разных по функциональности блоков, а из баз хранения/пред.анализа используется Монга и Эластик. Для оконечных тем — MySQL.
Почитал сам себя — уж очень мудренно получилось ;) Давайте на пальцах «покажу» примерчики, надеюсь будет понятней. У нас есть «демонстрашка» для партнеров, на которой можно поглядеть вживую некоторые верхушки Платформы — сайт ilook.ru (мы его не продвигаем, не рекламируем. рекламы на нем нет, это некий удобный интерфейс для проверки данных и гипотез). На сайте есть блок Сегондня/Вчера/Всего — который показывает накопение данных в Платформу. Это «окошко» в (со)хранилище данных и метаданных, грубо говоря — к кластерам Монги, в которые помещаются данные.
Но одновременно (некоторые) данные помещаются в Эластик для пред.анализа. Если в строке поиска Вы введете поисковое слово/фразу (например, местоимение Я), то получите страницу выдачи, с учетом морфологии (т.е. сообщения, содержащие также «мне», «меня», «мое»...). Приоритет — у только что пришедших сообщений (во многих наших задачах время — приоритет).
А есть еще «пользовательские темы» (долгоживущие объекты, с глубоким анализом данных, но с реал-таймом, например — br-analytics.ru/12366591/), то для таких объектов вполне хватает MySQL, хотя сейчас мы с SAP'ом работаем над вариантом c HANA, поскольку для ряда задач это может дать существенную прибавку к пороговым планкам.
P.S. Для задач обработки архивных данных, о которой и шла речь в статье аналитиков, можно остановиться на любой БД, или даже остановиться на файлах со строками. Хотя Вы это и так знаете :-) Избыточность применяемых технологий — вполне себе распространенная проблематика. Не всегда нужен микроскоп, чтобы забить гвоздь
Но одновременно (некоторые) данные помещаются в Эластик для пред.анализа. Если в строке поиска Вы введете поисковое слово/фразу (например, местоимение Я), то получите страницу выдачи, с учетом морфологии (т.е. сообщения, содержащие также «мне», «меня», «мое»...). Приоритет — у только что пришедших сообщений (во многих наших задачах время — приоритет).
А есть еще «пользовательские темы» (долгоживущие объекты, с глубоким анализом данных, но с реал-таймом, например — br-analytics.ru/12366591/), то для таких объектов вполне хватает MySQL, хотя сейчас мы с SAP'ом работаем над вариантом c HANA, поскольку для ряда задач это может дать существенную прибавку к пороговым планкам.
P.S. Для задач обработки архивных данных, о которой и шла речь в статье аналитиков, можно остановиться на любой БД, или даже остановиться на файлах со строками. Хотя Вы это и так знаете :-) Избыточность применяемых технологий — вполне себе распространенная проблематика. Не всегда нужен микроскоп, чтобы забить гвоздь
Итоговый многопоточный (3 потока) алгоритм, который применялся к обработке данных за месяц, позволил обработать месячный массив в 655 млн за 6 часов.
Сначала вы открыли для себя многопоточность, а там гляди откроете человечеству mapreduce
Кстати, откройте секрет, почему потока 3?
Пару недель назад, на конференции по BigData обсуждали с коллегами из Cloudera (уверен, что Вам, как эксперту по MR не надо рассказывать про них) проблематику задач OBD&A, куда конечно же падают аналитики соцмедиа. Коллеги с завистью смотрели на нехадуповское решение, поскольку ни Шарк, ни Антилопа не решают такие задачи — сдерживает сама матричная платформа. Да, просчитать прошлое, найти коллеции медицинских препаратов, или нарушения в томографическом слепке — т.е. когда все данные одинаково (не)важны — здесь все хорошо (на это и создавалось). А вот для исследовательских задач или задач оперативной социологии — не всегда.
Потока 3 — потому что больше было не нужно: запустили на ночь — утром аналитики получили данные. Зачем тратить ресурсов больше, чем нужно для получения результата в нужное время?
Потока 3 — потому что больше было не нужно: запустили на ночь — утром аналитики получили данные. Зачем тратить ресурсов больше, чем нужно для получения результата в нужное время?
А зачем вам онлайн-агрегация, если вы пересчитываете данные за месяц?
И зачем пересчитывать все данные за месяц, чтобы составить рейтинг цитируемости?
И зачем пересчитывать все данные за месяц, чтобы составить рейтинг цитируемости?
Рейтинг цитируемости — далеко не основная наша задача. Для подавляющего большинства решаемых нами задач необходим режим реального времени, например, для анализа мнений во время теле-эфиров, событий, управления репутацией и тд — счет идет на секунды.
Пересчитывать данные за месяц для рейтинга необходимо потому, что данные за меньший временной промежуток менее объективны. Например, за день — может быть «новость дня» и кто первый её опубликовал,того и тапки, на тот источник и ссылаются больше всего.
Пересчитывать данные за месяц для рейтинга необходимо потому, что данные за меньший временной промежуток менее объективны. Например, за день — может быть «новость дня» и кто первый её опубликовал,
Да, спасибо, CvetKomm, уже на все дан ответ :-) Индекс цитирования — одна из многих «фоновых» задач, — наглядная и практически интересная и полезная (наверное). В «рейтингологии» всегда присутствует параметр регулярности/скважности: минута, час, сутки, неделя, месяц, квартал, год. Для рейтинга СМИ логично использовать месяц-квартал, меньшие или большие интервалы конечно возможны, но на них девиация и ситуационные всплески будут или слишком влиятельны или, наоборот, чересчур размазаны в итоге.
Я все-таки соглашусь с комментарием выше, что это не «big data». Когда «это» явно больше одной машины — тогда это «big data». А сейчас это «data mining», как бы вам ни хотелось думать иначе. И ничего в этом плохого нет. «Big data» это просто модный штамп, но зачастую задача извлечения каких-то зависимостей из текста объемом в 100 МБ оказывается сложнее, чем несложная обработка терабайта логов какого-нибудь веб-сервера. Так что, как разработчикам, Вам нечего стыдиться — скорее наоборот.
Вот этот момент заинтересовал: «да, подобные сообщения фильтруются и не доходят до модуля анализа». Насколько я знаю (из практического опыта), некоторых ботов даже люди не могут распознать. Сидит себе профайл в соцсети, пишет какие-то цитатки изредка, шарит ссылочки, имеет 150 друзей. Поясните пожалуйста поподробнее про Ваши алгоритмы распознавания, уж очень сомнительным выглядит утверждение про фильтрацию ботов.
Вот этот момент заинтересовал: «да, подобные сообщения фильтруются и не доходят до модуля анализа». Насколько я знаю (из практического опыта), некоторых ботов даже люди не могут распознать. Сидит себе профайл в соцсети, пишет какие-то цитатки изредка, шарит ссылочки, имеет 150 друзей. Поясните пожалуйста поподробнее про Ваши алгоритмы распознавания, уж очень сомнительным выглядит утверждение про фильтрацию ботов.
andyN, спасибо за комментарий. Конечно, мерять данные «в машинах» — иезуитство. Для обработки структурированных (шаблонных) данных используется арго «молотилка», и не имеет значение количество йотобайт и стоек. Для обработки неструктурированных данных, на мой взгляд, BigData начинается с такого набора данных, которых достаточно на генерацию новых устойчивых сущностей, выявление которых невозможно на меньшем наборе данных.
Приведу пример от коллег: есть АСКУЭ — счетчики электричества, автоматически передающие «в центр от Юстаса» данные потребления электричества в квартире. Кажется ежеминутно. Анализируя некий большой объем данных возможно выяснить, какой стиральной машинкой пользуется ваша семья, и даже сколько ей лет, и в счете на электричество присылать рекламу новой стиральной машины :-)
P.S. Данные наших архивов и рейл-тайм потоков «хранятся» не на одной «машине» и даже не в одном ДЦ.
Приведу пример от коллег: есть АСКУЭ — счетчики электричества, автоматически передающие «в центр от Юстаса» данные потребления электричества в квартире. Кажется ежеминутно. Анализируя некий большой объем данных возможно выяснить, какой стиральной машинкой пользуется ваша семья, и даже сколько ей лет, и в счете на электричество присылать рекламу новой стиральной машины :-)
P.S. Данные наших архивов и рейл-тайм потоков «хранятся» не на одной «машине» и даже не в одном ДЦ.
Что касается ботов — их «видно» по ссылающимся сообщениям — текстам и структуре сообщения сопровождающего ссылку. У нас достаточно сложный алгоритм выявления ботов, включающий и полу-ручную обработку, и автоматические механизмы.
Небольшое техническое дополнение: у нас есть в разработке технологии раннего выявления новых трендов (задача «Челябинского метерорита»). Существующие технологии, например, наших коллег из ИППИ РАН, предназначены для более длительных (месяцы, годы) изменений. Применение нашей технологии к информационному полю еще требует аналитического сопровождения (много «мусора», нужно добавлять объединение сюжетов, серьезно модифицировать NER для соцмедиа и т.п.), но зато у технологии обнаружилась классная «фича» — великолепное обнаружение бот-сетей :-) Так что данную проблематику мы считаем практически закрытой. И массовое задействование бот-сетей и множества «человекообразных» бот-аккаунтов легко обнаруживаемым.
Спасибо за комментарий. Получается, что вы не анализируете профайл как таковой, а смотрите только на текст и ссылку самого сообщения? А что если тексты и ссылка уникализированы? Я понимаю, что в реальности как правило никто так не делает (ибо зачем?), но все же. К примеру — есть бот, он «написал» какой-то уникальный пост и скинул ссылку на сайт, его сообщение «ретвитнули» еще 50 других ботов. Такие штуки не обнаружатся?
Конечно обнаружатся. Это самая простейшая эвристика. Например, не слишком заморачивающиеся на интеллект бото-владельцы используют данную «технологию» для симуляции жизни своих голем-аккаунтов, не понимая, что их «труд» и выдает с головой всю рассаду :-) такие случаи не интересны, но массовы, особенно в Твиттере.
В интернет-тусовке есть несколько известных личностей, которые пытаются продвигать подобные «наработки», не понимая, что просто подставляют заказчиков под скандал.
В интернет-тусовке есть несколько известных личностей, которые пытаются продвигать подобные «наработки», не понимая, что просто подставляют заказчиков под скандал.
Очень странное мнение… Вообще-то речь идет о базе в 7 млрд. сообщений (более 50 терабайт), новых записей 400-500 в секунду, с реалтайм анализом (определение языка, разворачивание ссылок, обновление и анализ авторов, анализ спам-ботов и пр.). Анализ произведен по 650 млн сообщений (4,5 терабайт). Серверов несколько десятков (специализированных HP). Мало?
Т.е. речь идет о базе, где средний размер сообщений почти в 8kb(?
Оук, выкинем пробелы, символы лишнее…
По нижней оценке получим около 1т слов на сообщение. Длинных таких слов.
P.S. Радость от цифр бд была бы неполной… если не дополнить деталями по:
— кол-во дубликатов
— накладные расходы от служебных данных бд
— размеры базы с учетом/без индексов?
— … /*хардкор какой-нить*/
А так по цифрам — весомо, увесисто, много… Но вопросы есть, как то (по тви) — 1.3млн твитов за день?
Деталей, нам! Деталей))))
p.p.s. про детали хорошо и статью написать, техническую.
Оук, выкинем пробелы, символы лишнее…
По нижней оценке получим около 1т слов на сообщение. Длинных таких слов.
P.S. Радость от цифр бд была бы неполной… если не дополнить деталями по:
— кол-во дубликатов
— накладные расходы от служебных данных бд
— размеры базы с учетом/без индексов?
— … /*хардкор какой-нить*/
А так по цифрам — весомо, увесисто, много… Но вопросы есть, как то (по тви) — 1.3млн твитов за день?
Деталей, нам! Деталей))))
p.p.s. про детали хорошо и статью написать, техническую.
здравствуйте!
А как считаете индекс smi?
Какие данные из сообщений используются в процессе анализа? Вы ведь не просто количество ссылок считаете?)
А как считаете индекс smi?
Какие данные из сообщений используются в процессе анализа? Вы ведь не просто количество ссылок считаете?)
Добрый день! Для расчета используется как раз количество ссылок и их доля в общем объеме. Индекс цитируемости СМИ (SMI) – округленное до тысяч общее количество опубликованных ссылок на Топ-30 СМИ. За март 2014 года количество ссылок на ресурсы Топ-30 составило 4 407 176, соответственно, SMI = 4407 пунктов. Количественный показатель для Рейтинга цитируемости СМИ в социальных медиа (SMR) представляет собой долю ссылок на материалы каждого СМИ в общем количестве ссылок на ресурсы Топ-30, умноженную на 10.
Например: на ресурсы РИА «Новости» (ria.ru) было сделано 516 641 ссылок, что составляет 11.7% от общего количества ссылок на Топ-30 СМИ, и SMR = 117 пунктов.
Например: на ресурсы РИА «Новости» (ria.ru) было сделано 516 641 ссылок, что составляет 11.7% от общего количества ссылок на Топ-30 СМИ, и SMR = 117 пунктов.
Спасибо за ответ)
Можно еще по технической части вопросов:
Какие источники сообщений для сбора? Твиттер/вк?
Как ведётся сбор? ключевые слова? списки акков? api/парсинг?
Какой объём данных получается за месяц, день(в любом виде — json/csv/db/...)?
Можно еще по технической части вопросов:
Какие источники сообщений для сбора? Твиттер/вк?
Как ведётся сбор? ключевые слова? списки акков? api/парсинг?
Какой объём данных получается за месяц, день(в любом виде — json/csv/db/...)?
Источники и статистика по сбору: www.ilook.ru/statistics
Для каждого источника своя технология сбора — api, парсинг, rss, прямое партнерство с некоторыми источниками и др.
Для каждого источника своя технология сбора — api, парсинг, rss, прямое партнерство с некоторыми источниками и др.
Упс(
Sign up to leave a comment.
Data Mining в Big Data: рейтинг цитируемости СМИ в социальных медиа