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

Question

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

Данные организованы в виде схемы звезды с одним большим фактом и ~ 15 измерениями.
20B строк фактов в месяц
10 измерений с сотней строк (несколько иерархии)
5 измерений с тысячами строк
2 измерения с ~ 200К строк
2 больших размера с рядами 50–100 м

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

Лучшие участники в 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 

Вопросы:

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

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

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

Tnx,
Аггей.

Answer 1

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

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

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

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

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

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

В моем плане пропускной способности пакета «назад-в-пустяке» предлагается примерно 3-5 ТБ или около того в месяц, включая индексы для Oracle или SQL Server. Вероятно, меньше в Oracle с растровыми индексами, хотя лист индекса имеет 16-байтовый ROWID для оракула по сравнению с 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, традиционно используемого этими устройствами. Быстрый дисковый ввод-вывод не является сильной стороной облачных архитектур.

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

Читайте сайт Монаша: http://www.dbms2.com/ Он пишет о больших базах данных.

Может быть, вы можете использовать Oracle Exadata (http://www.oracle.com/solutions/business_intelligence/exadata.html и http://kevinclosson.wordpress.com/exadata-posts/) или, возможно, вы можете использовать Hadoop. Hadoop бесплатно.

Answer 6

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

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

Answer 7

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