Лучший способ обработки и хранения данных аналитики

Question

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

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

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 (пересылаются, открытая, подпрыгивать) регистрируется в режиме реального времени в таблице message_log. В таблице message_stats хранятся обработанные данные, которые представляют собой просто количество отправленных, открытых и возвращенных сообщений через 1 час. Флаг message_log.log_counted указывает, была ли строка обработана в message_stats.

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

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

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

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

Answer 1

Создайте 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.

Answer 2

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

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

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

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

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

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