andyN, спасибо за комментарий. Конечно, мерять данные «в машинах» — иезуитство. Для обработки структурированных (шаблонных) данных используется арго «молотилка», и не имеет значение количество йотобайт и стоек. Для обработки неструктурированных данных, на мой взгляд, BigData начинается с такого набора данных, которых достаточно на генерацию новых устойчивых сущностей, выявление которых невозможно на меньшем наборе данных.
Приведу пример от коллег: есть АСКУЭ — счетчики электричества, автоматически передающие «в центр от Юстаса» данные потребления электричества в квартире. Кажется ежеминутно. Анализируя некий большой объем данных возможно выяснить, какой стиральной машинкой пользуется ваша семья, и даже сколько ей лет, и в счете на электричество присылать рекламу новой стиральной машины :-)
P.S. Данные наших архивов и рейл-тайм потоков «хранятся» не на одной «машине» и даже не в одном ДЦ.
Да, спасибо, CvetKomm, уже на все дан ответ :-) Индекс цитирования — одна из многих «фоновых» задач, — наглядная и практически интересная и полезная (наверное). В «рейтингологии» всегда присутствует параметр регулярности/скважности: минута, час, сутки, неделя, месяц, квартал, год. Для рейтинга СМИ логично использовать месяц-квартал, меньшие или большие интервалы конечно возможны, но на них девиация и ситуационные всплески будут или слишком влиятельны или, наоборот, чересчур размазаны в итоге.
Почитал сам себя — уж очень мудренно получилось ;) Давайте на пальцах «покажу» примерчики, надеюсь будет понятней. У нас есть «демонстрашка» для партнеров, на которой можно поглядеть вживую некоторые верхушки Платформы — сайт ilook.ru (мы его не продвигаем, не рекламируем. рекламы на нем нет, это некий удобный интерфейс для проверки данных и гипотез). На сайте есть блок Сегондня/Вчера/Всего — который показывает накопение данных в Платформу. Это «окошко» в (со)хранилище данных и метаданных, грубо говоря — к кластерам Монги, в которые помещаются данные.
Но одновременно (некоторые) данные помещаются в Эластик для пред.анализа. Если в строке поиска Вы введете поисковое слово/фразу (например, местоимение Я), то получите страницу выдачи, с учетом морфологии (т.е. сообщения, содержащие также «мне», «меня», «мое»...). Приоритет — у только что пришедших сообщений (во многих наших задачах время — приоритет).
А есть еще «пользовательские темы» (долгоживущие объекты, с глубоким анализом данных, но с реал-таймом, например — br-analytics.ru/12366591/), то для таких объектов вполне хватает MySQL, хотя сейчас мы с SAP'ом работаем над вариантом c HANA, поскольку для ряда задач это может дать существенную прибавку к пороговым планкам.
P.S. Для задач обработки архивных данных, о которой и шла речь в статье аналитиков, можно остановиться на любой БД, или даже остановиться на файлах со строками. Хотя Вы это и так знаете :-) Избыточность применяемых технологий — вполне себе распространенная проблематика. Не всегда нужен микроскоп, чтобы забить гвоздь
Пару недель назад, на конференции по BigData обсуждали с коллегами из Cloudera (уверен, что Вам, как эксперту по MR не надо рассказывать про них) проблематику задач OBD&A, куда конечно же падают аналитики соцмедиа. Коллеги с завистью смотрели на нехадуповское решение, поскольку ни Шарк, ни Антилопа не решают такие задачи — сдерживает сама матричная платформа. Да, просчитать прошлое, найти коллеции медицинских препаратов, или нарушения в томографическом слепке — т.е. когда все данные одинаково (не)важны — здесь все хорошо (на это и создавалось). А вот для исследовательских задач или задач оперативной социологии — не всегда.
Потока 3 — потому что больше было не нужно: запустили на ночь — утром аналитики получили данные. Зачем тратить ресурсов больше, чем нужно для получения результата в нужное время?
Для данного исследования — никакую ;) Эта задача интересна логикой результата. Что же касается стандартных задач по анализу данных соцмедиа, то в них зачастую крайне важна оперативность обработки новых данных, когда счет идет на секунды — поток в сотни и тысячи неструктурированных сообщений в секунду нужно анализировать (в том числе и задействуя для части подпотоков медленные лингвомодули) на лету. Поэтому используется связки разных по функциональности блоков, а из баз хранения/пред.анализа используется Монга и Эластик. Для оконечных тем — MySQL.
В BigData важнее машины — ум прокладки за рулем. Если ума немного, то любые данные будут казаться «так себе». Кстати, может поделитесь Вами выстраданным уровнем, сверх которого данные становятся Big? Можно даже в самосвалах ;)
Мы очень любим Хабр. Именно поэтому размещаем многие материалы сначала в нашем блоге на Хабре.
Мы уважительно относимся к ПРОФЕССИОНАЛЬНОМУ сообществу Хабра, и ценим наших новых партнеров, с которыми познакомились здесь:
1. Олимпийские виджеты уже размещены на сотне сайтов из 7 стран. После публикации на Хабре.
2. По аналогичной с виджетами технологии 7 февраля стартовал уникальный проект вместе с РИА Новости — «Олимпийское настроение» (http://ria.ru/sochi2014_news/20140207/993694100.html), аналогов которому в мире нет.
Мы профессионально анализируем мнения людей и делаем это на мировом уровне. Например, SocialBaker в день открытия Олимпиада «насчитал» 1 млн публичных сообщений, по нашим данным — 1.8 млн (потому что мы анализируем данные не только Твиттер и не только англоязычные).
Мы знаем, что в любом, даже профессиональном, сообществе, бывает всякое — как говорится, «в семье не без урода» (с) народная пословица. Думаю, что сообществу Хабра следует развиваться дальше, вводя корректировки (само)оценки экспертизы в оценке работы профессионалов. Неразумно приравнивать экспертное мнение профи с мнениями недорослей-Митрофанушек, даже не понимающих смысловую разницу между фразами «Спасибо не надо» и «Спасибо, не надо» — от таких даже «минус» воспринимается как плюс ;)
Если вовремя не блокировать заразу, то может пострадать весь здоровый организм сообщества Хабр. Наглядный пример: LinkedIn — попустительство организаторов привело к тому, что LIn стал не только сообществом работников, менеджеров и управленцев, но и проституток. И пришлось после IPO вычищать толпы путан, использующих Lin для предложения своих услуг.
Прямо как в притче: предожили трем слепым описать слона, привели к слону: первый схватился за хобот, говорит: «Слон — это змея!», второй обхватил ногу: «Слон — это дерево!», третий долго ощупывал ухо: «Слон — это растение с большими листьями». Так что, kikaha, вы (раз «мы», то значит не Вы) хобот-то отпустите… А лингвистический анализ коммента еще на пару притч потянет.
API есть и используется, но для данного проекта требуется расширение, которое пока формализовано на 90%: и мобильные решения, и вебовское будут пользоваться одним API к Платформе.
Подключение сторонних приложений/сервисов к API — возможно и планируется. Запросы, с кратким описанием приложения и потребностей, можно отправлять на info@palitrumlab.ru. Обсуждается подключение в бете сторонних проектов, но пока без обязательств.
Публичный доступ к API Платформы (бесплатно с ограничением запросов/выборки) будет только после запуска основного продукта и оценки нагрузки на инфраструктуру.
Никто и не спорит. Потому и было сказано "… или представлены в зачаточном виде". Дьявол — в мелочах: по какой базе работает «свой поисковый запрос»? А если я хочу читать не только «свою ленту», но и чужую ленту (например, Ксении Собчак), на которую не подписан, поскольку у меня нет аккаунта в Твиттере?
Подобных заинтересованностей у пользователей может быть много, в том числе и приведенные хотелки выше — типа получения сообщений «тех, кто рядом». Для реализации подобных и многих других хотелок каждая из систем должна реализовывать свою технологическую платформу, или использовать чужую (как было с приложениями поверх базы Google Reader)
Если очень общО: Flipboard — читалка RSS и избранных источников (СМИ). Функций 1) тематических лент в оперативном режиме из всего объема соцмедиа, 2) сборки тредов, 3) расширенных коммуникативных функций «a la HotSuite» в Flipboard (News360, TapTou...) нет или представлены в зачаточном виде, поскольку требуют наличия собственной Платформы сбора и анализа.
Повторюсь, это если кратко. Во всех програамах и приложениях есть свои вкусности и каждый имеет возможность выбрать продукт с нужным набором функциональности.
Судя по первым откликам задача переноса _акцента_ с привычных для ЦА Хабры RSS-лент на тематические ленты будет не очень простой. Поясню на примере.
Привычная парадигма: мы привыкли читать _сайтами_ (источниками) — подписываемся на Хабру, 4pda, 3dnews, technews и пр., и пролистываем заголовки, пока не попадаем на интересный нам материал. Т.е. у каждого из нас есть первоначальная выборка _тематических источников_, читая которые мы сами отфильтровываем нужное.
Подобный подход вполне подходит для узкотематических источников, редакционная команда которых выстроила хороший «фильтр» для качественного контента, чтобы пользователь получал нужное и не в чрезмерном для человека объеме. И Хабр здесь является хорошим примером. Но в случае крупного всеядного агентства, например РИА «Новости», на выходе получается лента с 2 000 новостями, для большинства людей такой поток каждый день осилить нереально.
Парадигма «сборных тематических лент», когда человеку собираются материалы по интересующей его теме (дизайн, коммутаторы, приложения для Android, Сирия, Олимпиада) из разных источников, про которые мы можем даже не знать, позволяет расширить первую парадигму, и является, IMHO, более человеческой для обычных людей.
А если подход «сборных лент» дополнить опцией указания конкретными источниками (Хабра, 3dnews, 4pda), то получим привычное нам чтение RSS-лент, но со значительной экономией времени — система отфильтрует только сообщения по важным темам. При таком варианте даже новости РИА не покажутся страшным потоком, если наложить фильтр, например «Digit, Сирия, Олимпиада».
Приведу пример от коллег: есть АСКУЭ — счетчики электричества, автоматически передающие «в центр от Юстаса» данные потребления электричества в квартире. Кажется ежеминутно. Анализируя некий большой объем данных возможно выяснить, какой стиральной машинкой пользуется ваша семья, и даже сколько ей лет, и в счете на электричество присылать рекламу новой стиральной машины :-)
P.S. Данные наших архивов и рейл-тайм потоков «хранятся» не на одной «машине» и даже не в одном ДЦ.
Но одновременно (некоторые) данные помещаются в Эластик для пред.анализа. Если в строке поиска Вы введете поисковое слово/фразу (например, местоимение Я), то получите страницу выдачи, с учетом морфологии (т.е. сообщения, содержащие также «мне», «меня», «мое»...). Приоритет — у только что пришедших сообщений (во многих наших задачах время — приоритет).
А есть еще «пользовательские темы» (долгоживущие объекты, с глубоким анализом данных, но с реал-таймом, например — br-analytics.ru/12366591/), то для таких объектов вполне хватает MySQL, хотя сейчас мы с SAP'ом работаем над вариантом c HANA, поскольку для ряда задач это может дать существенную прибавку к пороговым планкам.
P.S. Для задач обработки архивных данных, о которой и шла речь в статье аналитиков, можно остановиться на любой БД, или даже остановиться на файлах со строками. Хотя Вы это и так знаете :-) Избыточность применяемых технологий — вполне себе распространенная проблематика. Не всегда нужен микроскоп, чтобы забить гвоздь
Потока 3 — потому что больше было не нужно: запустили на ночь — утром аналитики получили данные. Зачем тратить ресурсов больше, чем нужно для получения результата в нужное время?
Мы уважительно относимся к ПРОФЕССИОНАЛЬНОМУ сообществу Хабра, и ценим наших новых партнеров, с которыми познакомились здесь:
1. Олимпийские виджеты уже размещены на сотне сайтов из 7 стран. После публикации на Хабре.
2. По аналогичной с виджетами технологии 7 февраля стартовал уникальный проект вместе с РИА Новости — «Олимпийское настроение» (http://ria.ru/sochi2014_news/20140207/993694100.html), аналогов которому в мире нет.
Мы профессионально анализируем мнения людей и делаем это на мировом уровне. Например, SocialBaker в день открытия Олимпиада «насчитал» 1 млн публичных сообщений, по нашим данным — 1.8 млн (потому что мы анализируем данные не только Твиттер и не только англоязычные).
Мы знаем, что в любом, даже профессиональном, сообществе, бывает всякое — как говорится, «в семье не без урода» (с) народная пословица. Думаю, что сообществу Хабра следует развиваться дальше, вводя корректировки (само)оценки экспертизы в оценке работы профессионалов. Неразумно приравнивать экспертное мнение профи с мнениями недорослей-Митрофанушек, даже не понимающих смысловую разницу между фразами «Спасибо не надо» и «Спасибо, не надо» — от таких даже «минус» воспринимается как плюс ;)
Если вовремя не блокировать заразу, то может пострадать весь здоровый организм сообщества Хабр. Наглядный пример: LinkedIn — попустительство организаторов привело к тому, что LIn стал не только сообществом работников, менеджеров и управленцев, но и проституток. И пришлось после IPO вычищать толпы путан, использующих Lin для предложения своих услуг.
Подключение сторонних приложений/сервисов к API — возможно и планируется. Запросы, с кратким описанием приложения и потребностей, можно отправлять на info@palitrumlab.ru. Обсуждается подключение в бете сторонних проектов, но пока без обязательств.
Публичный доступ к API Платформы (бесплатно с ограничением запросов/выборки) будет только после запуска основного продукта и оценки нагрузки на инфраструктуру.
Подобных заинтересованностей у пользователей может быть много, в том числе и приведенные хотелки выше — типа получения сообщений «тех, кто рядом». Для реализации подобных и многих других хотелок каждая из систем должна реализовывать свою технологическую платформу, или использовать чужую (как было с приложениями поверх базы Google Reader)
Повторюсь, это если кратко. Во всех програамах и приложениях есть свои вкусности и каждый имеет возможность выбрать продукт с нужным набором функциональности.
Привычная парадигма: мы привыкли читать _сайтами_ (источниками) — подписываемся на Хабру, 4pda, 3dnews, technews и пр., и пролистываем заголовки, пока не попадаем на интересный нам материал. Т.е. у каждого из нас есть первоначальная выборка _тематических источников_, читая которые мы сами отфильтровываем нужное.
Подобный подход вполне подходит для узкотематических источников, редакционная команда которых выстроила хороший «фильтр» для качественного контента, чтобы пользователь получал нужное и не в чрезмерном для человека объеме. И Хабр здесь является хорошим примером. Но в случае крупного всеядного агентства, например РИА «Новости», на выходе получается лента с 2 000 новостями, для большинства людей такой поток каждый день осилить нереально.
Парадигма «сборных тематических лент», когда человеку собираются материалы по интересующей его теме (дизайн, коммутаторы, приложения для Android, Сирия, Олимпиада) из разных источников, про которые мы можем даже не знать, позволяет расширить первую парадигму, и является, IMHO, более человеческой для обычных людей.
А если подход «сборных лент» дополнить опцией указания конкретными источниками (Хабра, 3dnews, 4pda), то получим привычное нам чтение RSS-лент, но со значительной экономией времени — система отфильтрует только сообщения по важным темам. При таком варианте даже новости РИА не покажутся страшным потоком, если наложить фильтр, например «Digit, Сирия, Олимпиада».