Comments 5
Стандартно большие данные характеризуются тремя признаками VVV, хотя в вольных интерпретациях количество «V» доходило и до семи.
Сергей, 23 упоминания уже похабного термина Big Data на такую маленькую маркетинговую статью… Не много?
Будет круто если наконец-то расскажете о своей реализации биллинга с техническими подробностями (во всех Ваших статьях — ни слова). Все-таки это Хабр, а не LinkedIn/Facebook :-)
Будет круто если наконец-то расскажете о своей реализации биллинга с техническими подробностями (во всех Ваших статьях — ни слова). Все-таки это Хабр, а не LinkedIn/Facebook :-)
Было бы интересно рассмотреть реальные кейсы. Например, рассмотреть одну из реальных моделей, которая применялась для снижения оттока абонентов.
Постановка задач — чаще всего, всё начинается с «я тут видел у соседей любопытную штуку, давайте сделаем так же! Начинаем пилот» — именно в это месте нужно понять, что хочется и какие конкретно результаты и показатели будем оценивать: что можно поднять кластер с hadoop даже на бесплатных виртуалках — не вопрос.
Что этот кластер будет как-то работать — ну, в общем, будет. И данные хранить будет.
И что дальше?
Зовите хороших аналитиков ( хотя б в аренду), смотрите похожие случаи внедрения — люди любят пиариться не только по теме «а вот мы с помощью больших данных зарабатываем 100500 денег в неделю!», но и с техническими деталями, прикидывайте, сколько будет требовать команда + железо — возможно, вы не окупите всё это или хватит 2 аналитиков, pandas и Excel на хорошем ноутбуке, анализировать срезы данных.
Подмена понятий — туда же: никто не мешает сделать 1 срез данных с ключом по телефонному номеру, второй — по сложному ключу, например, по всем номерам, связанным с паспортом абонента на определённой территории, ещё пяток — на разные временные рамки и заниматься анализом.
Недостаток информации: честное слово, не нужно объяснять всем сотрудникам команды, как считать APRU 8 способами — объясните это аналитикам ещё в 1 пункте, те напишут внятное ТЗ и будет у вас 8 типов APRU по клиентам /областям / периодам / сексуальной ориентации и предпочитаемой марке машины ( если железо позволит — в реальном времени и при желании — в 3d)
Ну а если вы не можете даже поставить цели — лучше не начинайте это долгое, дорогое и неблагодарное дело.
Что этот кластер будет как-то работать — ну, в общем, будет. И данные хранить будет.
И что дальше?
Зовите хороших аналитиков ( хотя б в аренду), смотрите похожие случаи внедрения — люди любят пиариться не только по теме «а вот мы с помощью больших данных зарабатываем 100500 денег в неделю!», но и с техническими деталями, прикидывайте, сколько будет требовать команда + железо — возможно, вы не окупите всё это или хватит 2 аналитиков, pandas и Excel на хорошем ноутбуке, анализировать срезы данных.
Подмена понятий — туда же: никто не мешает сделать 1 срез данных с ключом по телефонному номеру, второй — по сложному ключу, например, по всем номерам, связанным с паспортом абонента на определённой территории, ещё пяток — на разные временные рамки и заниматься анализом.
Недостаток информации: честное слово, не нужно объяснять всем сотрудникам команды, как считать APRU 8 способами — объясните это аналитикам ещё в 1 пункте, те напишут внятное ТЗ и будет у вас 8 типов APRU по клиентам /областям / периодам / сексуальной ориентации и предпочитаемой марке машины ( если железо позволит — в реальном времени и при желании — в 3d)
Ну а если вы не можете даже поставить цели — лучше не начинайте это долгое, дорогое и неблагодарное дело.
Sign up to leave a comment.
Большим данным большой биллинг: о BigData в телекоме