Лучший метод для обработки и хранения аналитических данных - PullRequest
1 голос
/ 20 января 2011

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

Вот упрощенная версия моей текущей идеи, которая работает хорошо, но имеет недостаток остановки показа:

CREATE TABLE message_log (
    log_id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
    log_campaign_id INT UNSIGNED NOT NULL,
    log_message_id INT UNSIGNED NOT NULL,
    log_action VARCHAR(10) NOT NULL,
    log_timestamp INT UNSIGNED NOT NULL,
    log_counted TINYINT UNSIGNED NOT NULL DEFAULT 0,
    INDEX(log_counted)
);

CREATE TABLE message_stats (
    stats_campaign_id INT UNSIGNED NOT NULL,
    stats_year INT UNSIGNED NOT NULL,
    stats_month TINYINT UNSIGNED NOT NULL,
    stats_day TINYINT UNSIGNED NOT NULL,
    stats_hour TINYINT UNSIGNED NOT NULL,
    stats_sent_count INT UNSIGNED NOT NULL,
    stats_open_count INT UNSIGNED NOT NULL,
    stats_bounce_count INT UNSIGNED NOT NULL,
    PRIMARY KEY (stats_campaign_id, stats_year, stats_month, stats_day, stats_hour)
);

Так что идея заключается в различных log_action (отправлено, open, bounce) регистрируются в режиме реального времени в таблице message_log.Таблица message_stats содержит обработанные данные, которые являются просто подсчетом отправленных, открытых и отклоненных сообщений с интервалом в 1 час.Флаг message_log.log_counts указывает, была ли строка обработана в message_stats.

Когда мне нужна актуальная статистика, я просто выбираю строки из message_log с log_counts = 0, подсчитываю их в message_stats и устанавливаю log_counts =1.Теперь я могу быстро и легко выбирать статистику для конкретной или общей годовой, ежемесячной, ежедневной или почасовой статистики, группируя различные столбцы.

Может быть проще пропустить полностью message_log и просто обновить таблицу message_stats в реальном временивремя, но я решил сохранить необработанные данные журнала, чтобы впоследствии их можно было легко восстановить, просто обрезав message_stats и установив message_log.log_counts = 0.

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

Есть идеи по поводу лучшего подхода?Я знаю, что я не первый, кто сталкивается с этой дилеммой.

Ответы [ 2 ]

1 голос
/ 05 апреля 2013

Один из вариантов - не решить эту проблему самостоятельно. Существует целый ряд аналитических служб или инструментов, которые могут помочь с тяжелой работой здесь (полное раскрытие: я основал одну из них) Я сделал этот ответ в вики сообщества, чтобы другие могли добавлять свои любимые. Но вот список потенциальных решений с моим мнением о них:

  1. Острый IO (моя компания). Пользовательская аналитика через API. Полезно, когда вы думаете о создании специального аналитического решения, но не хотите создавать все с нуля. Может использоваться для встраивания аналитических функций прямо в ваш веб-сайт или приложение. Много девелоперских рычагов здесь! Но нет встроенных приборных панелей. Вы должны построить свой собственный.

  2. MixPanel. Настраиваемая панель аналитики. Хорошо, если вы хотите место для входа и просмотра данных. Отлично подходит для просмотра в пользовательском интерфейсе. Также подходит для отслеживания и участия в пользовательских взаимодействиях. Может стать чрезмерно дорогим при больших объемах.

  3. Vertica. Аналитическая БД, которую вы развертываете на собственном оборудовании. Высокая масштабируемость, высокая схема. Многие аналитические решения старой школы (Zynga и т. Д.) Построены на этом.

  4. Hadoop-а-а-службы. Есть ряд компаний, предлагающих это. Они управляют сложностью построения и поддержки кластера Hadoop. Вы все еще должны делать такие вещи, как писать задания по уменьшению карты. Потенциально вы сэкономите много времени, если вам нужен Hadoop.

Пожалуйста, добавьте больше!

1 голос
/ 20 января 2011

Создайте message_stats_locale_agnostic, а затем измените message_stats, чтобы он содержал столбец языкового стандарта.

Теперь у вас есть три этапа: message_log => message_stats => message_stats_locale_agnostic.

Message_stats по-прежнему содержит агрегированные данные, нотеперь он также разрезает его по локали, так что в итоге в этой таблице будет больше строк, чем раньше.

Теперь вам также потребуется еще один процесс агрегации, который заполняет таблицу message_stats_locale_agnostic, игнорируя столбец локали, который сейчассуществует в message_stats.Эта таблица по сути то, что у вас есть в message_stats.

Если вам нужны данные, основанные на локали, выберите из message_stats (зная, что это будет немного медленнее, чем при выборе из message_stats_locale_agnostic.) Если вам нужны данные не на основев локали выберите из message_stats_locale_agnostic.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...