Хранилище данных: Как я могу запрашивать ежедневные снимки?

У меня есть несколько снимков базы данных, которые не являются временными сериями. Например:

• Снимок дня 1:

  +----+---------------+------------+------------+        
  | ID |     Title     |  Category  |    Date    |
  +----+---------------+------------+------------+
  | 1  | My First Post | helloworld | 2015-01-01 |
  +----+---------------+------------+------------+

• Снимок дня 2 (новое сообщение добавлено сегодня):

  +----+----------------+------------+------------+        
  | ID |      Title     |  Category  |    Date    |
  +----+----------------+------------+------------+
  | 1  | My first post  | helloworld | 2015-01-01 |
  | 2  | My second post | other      | 2015-01-02 |
  +----+----------------+------------+------------+

• Снимок дня 3 (Пост 2 удален сегодня):

  +----+---------------+------------+------------+        
  | ID |     Title     |  Category  |    Date    |
  +----+---------------+------------+------------+
  | 1  | My First Post | helloworld | 2015-01-01 |
  +----+---------------+------------+------------+

Таким образом, между днями строка таблицы может быть постоянной или нет. Теперь мне нужно иметь возможность использовать такой запрос:

SELECT category, COUNT(*) from day1.My_table group by category

Это для одного стола одного дня. Если мы хотим посчитать среднесуточное количество постов по категориям за месяц, мы должны сделать что-то вроде:

SELECT category, SUM(cnt) / 30 
from ( 
    SELECT category, COUNT(*) as cnt 
    from day1.My_table 
    group by category 
        UNION ALL SELECT category, COUNT(*) as cnt 
                  from day2.My_table 
                  group by category 
        UNION ALL ... 
        UNION ALL SELECT category, COUNT(*) as cnt 
                  from day30.My_table 
                  group by category
) group by category

Другой пример, номер публикации, опубликованной за месяц :

SELECT COUNT(distinct id) 
from ( 
    SELECT id 
    from day1.My_table 
    UNION ALL ... 
    UNION ALL SELECT id 
              from day30.My_table
) 

В основном нам нужно учитывать вес. Если у нас есть day1.My_table и day5.My_table, то каждое сообщение, которое находится в день1, а не в день5, будет засчитано, как и в день 2,3,4. Каждый пост, имеющий день1 и день5, будет считаться так, как если бы он находился в каждом дне месяца (= до следующего снимка).

Таким образом, в случае, если я хотел бы считать среднее количество постов в день> = 6 месяцев за год, где у меня есть только один снимок, я бы назначил этому снимку вес 30.

Итак, средний пост, опубликованный за месяц для диапазона> = 6 месяцев назад:

SELECT category, SUM(cnt) / 30 
from ( 
    SELECT category, COUNT(*)*30 as cnt 
    from day1.My_table 
    group by category --- Note: I'm not considering the range defined from the user in this example.
) group by category;

Как отмечается в комментарии, мне нужно будет сделать запрос вроде:

Select category, AVG(*) 
from [fromRange-toRange].MyTable; 

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

Как вы думаете, есть ли способ сделать это в Drill без метаязыка? Я бы сделал это с помощью рекурсивной UDF, но они не могут возвращать запросы.

Каждый снимок имеет размер 250 ГБ, и я хочу иметь возможность сравнивать этот набор данных с другими внешними данными (я заранее не знаю схему этого набора данных).

Есть ли подходящее решение для Apache Drill? Или есть другое решение этой проблемы?

Также ценится любой мета-язык или статья по этой проблеме.

Изменить: у нас нет транзакционных данных. У нас есть данные, которые меняются во времени и могут быть добавлены или удалены; по этой причине нам нужны ежедневные снимки. Также мы не знаем заранее, какие запросы будут выполняться, поэтому мы не можем знать, какой тип агрегации нужно выполнить. Кроме того, каждая строка имеет около 100 столбцов и, скажем, 250 ГБ на снимок (таблицы Mysql). Нам также нужен полнотекстовый поиск по этим данным в каждой строке, в любой возможный день.

Примером поиска может быть «Сколько постов было о какой-то теме?» Поэтому он должен искать во всех сообщениях ключевое слово sometopic. Каждый снимок может иметь или не иметь одинаковые строки. Также два снимка могут иметь один и тот же пост, но слегка измененный.

Давайте думать из коробки. Вместо того, чтобы иметь «снимок», давайте иметь «журнал». В настоящее время у вас есть «текущее» состояние вещей; добавление «log» даст «историю», из которой можно получить «потерянную» информацию.

Один из способов реализации Бревно иметь TRIGGERна INSERTили UPDATEиз таблицы, и есть триггер записи в лог - файл. Этот журнал не будет приятен для специальных запросов, поэтому имейте ночную работу (или, возможно, почасовую), которая суммирует изменения за день - чистый выигрыш (или потерю) количества постов и т. Д. Информация "day2" и информация «за последний месяц» может быть получена из этой сводной таблицы довольно быстро. Или, возможно, второй уровень суммирования, который объявляет состояние каждого дня. Я сомневаюсь, UNIONчто будет необходимо. «Снимок» не будет задействован.

Итак, то, что я искал, - это новый тип системы, связанный с Datawarehousing: Data Lake System.

Вы можете узнать больше в Википедии :

Озеро данных - это метод хранения данных в системе, который облегчает размещение данных в различных схемах и структурных формах, обычно объектных объектах или файлах. Hadoop и платформа AWS S3 могут использоваться для создания хранилищ озера данных.