20 миллиардов строк/месяц - Hbase/Hive/Greenplum/Что?

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

Данные организованы в структуре звездной схемы с одним большим фактом и размером ~ 15.  

20 байт строк в месяц  

10 измерений со сто строк (несколько иерархии)  

5 размеров с тысячами рядов  

2 размера с ~ 200K строк  

2 больших размера с рядами 50M-100M

Два типичных запроса работают против этой БД

Верхние члены в dimq:

select    top X dimq, count(id) 
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 
group by  dimq 
order by  count(id) desc

Меры против кортежа:

select    count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),...
from      fact 
where     dim1 = x and dim2 = y and dim3 = z

Вопросы:

  • Какая лучшая платформа для выполнения таких запросов
  • Какое оборудование требуется

  • Где можно разместить (EC2?)


    (пожалуйста, игнорируйте вопросы импорта и загрузки на данный момент)

Tnx,  

Аггей.

Ответы

Ответ 1

Я не могу этого достаточно подчеркнуть: получить то, что хорошо играет с готовыми инструментами отчетности.

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

  • Забудьте о облачных системах (Hive, Hbase), пока у них не будет зрелой поддержки SQL. Для хранилища данных вам нужно что-то, что работает с обычными инструменты отчетности. В противном случае вы будет постоянно находиться увязший писать и поддерживать специальные программы отчетов.

  • Объемы данных управляемы с помощью более традиционная СУБД, такая как Oracle - я знаю крупную европейскую телекоммуникационную компанию Oracle. Все остальные при прочих равных условиях два порядка больше, чем ваши объемы данных, поэтому общие архитектуры дисков все еще имеют запас для вас. общедоступная архитектура Netezza или Teradata, вероятно, будет быстрее, но эти объемы не на уровне, который находится за пределами обычной системы с общим диском. Имейте в виду, что все эти системы довольно дорого.

  • Также помните, что MapReduce является not эффективный выбор запроса Алгоритм. это    в основном механизм распределения грубой силы вычисления. Greenplum    имеет встроенный интерфейс MapReduce, но не предназначенное для общего использования ничего двигатель будет намного более эффективным и получить больше работы за меньшее аппаратное обеспечение.

Я считаю, что Teradata или Netezza, вероятно, будут идеальным инструментом для этой работы, но, безусловно, самым дорогим. Oracle, Sybase IQ или даже SQL Server также будет обрабатывать тома данных, но будет медленнее - они являются общими дисковыми архитектурами, но могут управлять этим типом объема данных. См. Это сообщение для описания функций, связанных с VLDB в Oracle и SQL Server, и имейте в виду, что Oracle только что внедрила платформа хранения Exadata.

Мой план загрузки пакетов с пассивным пакетом предполагает, возможно, 3-5 ТБ или около того в месяц, включая индексы для Oracle или SQL Server. Вероятно, меньше на Oracle с растровыми индексами, хотя индексный лист имеет 16-байтовый ROWID в oracle против ссылки на 6 байтов на SQL Server.

Sybase IQ широко использует индексы растровых изображений и оптимизирован для запросов хранилища данных. Несмотря на архитектуру с общим диском, она очень эффективна для этого типа запросов (IIRC - это исходная архитектура, ориентированная на столбцы). Это, вероятно, будет лучше, чем Oracle или SQL Server, поскольку он специализируется на этом типе работы.

Greenplum может быть более дешевым вариантом, но я никогда не использовал его, поэтому я не могу прокомментировать, насколько хорошо он работает на практике.

Если у вас есть 10 измерений всего несколько сотен строк, подумайте о слиянии их с одним размером мусора, который уменьшит вашу таблицу фактов объединив десять ключей в один. Вы по-прежнему можете реализовать иерархии в отношении размера мусора, и это снизит размер вашей таблицы фактов на 1/2 или больше и исключит использование дискового пространства по индексам.

Я настоятельно рекомендую вам пойти с чем-то, что прекрасно сочетается с разумным поперечным сечением инструментов отчетности. Это означает, что передняя часть SQL. Коммерческие системы, такие как Crystal Reports позволяют создавать отчеты и аналитические материалы для людей с более доступным набором навыков SQL. Мир с открытым исходным кодом также генерировал BIRT, Jasper Reports и Pentaho.. Hive или HBase поставили вас в основу создания пользовательского интерфейса, которого вы действительно не хотите, если только вы не будете счастливы потратить следующие 5 лет на создание настраиваемых форматов отчетов на Python.

Наконец, разместите его где-нибудь, вы можете легко получить быстрый фид данных из своих производственных систем. Это, вероятно, означает ваше собственное оборудование в вашем собственном центре обработки данных. Эта система будет связана с вводом-выводом; он делает простую обработку на больших объемах данных. Это означает, что вам понадобятся машины с быстрыми дисковыми подсистемами. Облачные провайдеры, как правило, не поддерживают этот тип оборудования, поскольку он на порядок дороже, чем тип одноразового блока 1U, традиционно используемого этими нарядами. Fast Disk I/O не является областью архитектуры облаков.

Ответ 2

У меня был большой успех с vertica. В настоящее время я загружаю от 200 миллионов до 1 миллиарда строк в день - в среднем около 9 миллиардов долларов в месяц - хотя я достиг 17 миллиардов долларов в месяц. У меня близко к 21 размерности, и запросы выполняются очень быстро. Мы перешли от старой системы, когда у нас просто не было окон времени для работы с dataload.

мы сделали очень исчерпывающее исследование и исследование различных решений - и практически посмотрели на все, что было на рынке. В то время как Терадата и Нетеца бы нам подошли, они были просто слишком дороги для нас. Vertica избили их обоих по соотношению цена/производительность. Это, кстати, столбчатая база данных.

Сейчас у нас около 80 пользователей, и ожидается, что к концу следующего года он вырастет примерно до 900, когда мы начнем полностью развертываться.

Мы широко используем службы ASP.NET/dundas/reporting для отчетов. Он также отлично справляется с решениями сторонних разработчиков - хотя мы этого не пробовали.

Кстати, что вы собираетесь использовать для dataload? Мы используем informatica и были очень довольны им. SSIS подтолкнула нас к стене.

Ответ 3

Используя HBase и jasperserver hbase, сообщающие о подключении, можно создать достойные отчеты. В HBase может быть создана OLAP с низкой задержкой. Это будет работать так же, как SQL. Плагин Jasperserver HBase предоставляет язык запросов Hbase, который является командой расширения Hbase.

Ответ 5

Мне любопытно, что вы наконец выбрали. Ваш вопрос был в конце 2008 года. Сегодня ситуация отличается от HBase, Greenplum, pig и т.д., Предоставляя SQL как доступ.

Ответ 6

Альтернативой для небольшого числа пользователей будет кластер (beowulf). 20K покупает вам 50 неттопов по 500G каждый. Это около 3 кВт пиковой мощности. Или 4 месяца хранения облаков.

Ответ 7

NXC, вы уверены, что эти 600 миллиардов строк в день? Даже если одна строка будет всего одним байтом, это 600 ГБ данных в день. Предполагая более разумные 100 байт в строке, мы говорим о 60 ТБ данных в день, 1,8 PB в месяц. Я действительно сомневаюсь, что кто-то накачивает много данных через Oracle.

Другие источники, похоже, подтверждают, что Oracle становится довольно сложно обрабатывать, когда объем данных достигает 2-значного TB цифры.