Выбор хранилища больших данных

В настоящее время передо мной стоит задача создать хранилище данных для хранения и обработки огромного количества данных. Предполагаемое количество составляет более 7 миллиардов событий в день. Данные должны храниться в течение 7 дней. Средний размер события ~0,5 - 1 Кб. Нам нужно обработать данные, чтобы:

  • генерировать отчеты;
  • модели поездов.

В настоящее время я оцениваю:

  • Google Большой запрос
  • Красное смещение
  • Stratio + Cassandra + AWS + EMR + EBS
  • Клаудера + AWS

Итак, меня интересует:

  • решение, которое вы используете внутри своей компании (фреймворки, настройка, база данных, количество узлов и т. д.)
  • любые примеры реальной стоимости/сравнения, если это возможно
  • сложность управления (devops)

google-bigquery amazon-redshift bigdata cloudera cassandra-2.0
person Yuli Reiri    schedule 24.05.2016    source источник
comment
Вопросы по администрированию профессиональной серверной или сетевой инфраструктуры не относятся к теме Stack Overflow, если только они непосредственно не касаются программирования или инструментов программирования. Вы можете получить помощь по сбою сервера.   -  person Gustavo Morales    schedule 24.05.2016
comment
@MoralesBatovski это не так, тема шире и включает в себя программные решения и фреймворки, например, от компании Stratio и Cloudera. А bigquery эластичен и работает только через API...   -  person Yuli Reiri    schedule 24.05.2016
comment
слишком широко и оффтопично.   -  person Zig Mandel    schedule 24.05.2016
comment
Вопросы @ZigMandel конкретны и относятся к опыту работы с хранилищем больших данных. Если у вас есть ценный вклад и опыт в этой области - добро пожаловать   -  person Yuli Reiri    schedule 24.05.2016
comment
tske посмотрите на причину, по которой он помечен как оффтоп. вы именно просите рекомендации по инструментам, которые явно не по теме. потратьте время на изучение специфики и задайте конкретный вопрос по программированию.   -  person Zig Mandel    schedule 24.05.2016
comment
Я выбираю стек технологий, а не инструмент. Это большая разница.   -  person Yuli Reiri    schedule 24.05.2016

Ответы (2)


arrow_upward
4
arrow_downward

Недавно я написал это резюме на основе серии статей Марка Лита, сравнивающих BigQuery, Spark, Hive, Presto, ElasticSearch, AWS Redshift, AWS EMR и Google Dataproc:

https://cloud.google.com/blog/big-data/2016/05/bigquery-and-dataproc-shine-in-independent-big-data-platform-comparison

Резюме резюме:

  • Тот же набор данных (1 миллиард строк), те же запросы, множество технологий и конфигураций.
  • BigQuery был самым быстрым для выполнения запросов: 2 секунды.
  • BigQuery был единственным быстрым по умолчанию: не требовалась ни оптимизация, ни предварительная обработка данных. 1 миллиард строк был загружен за 25 минут, и данные были готовы к запросу.
  • Другим решениям требовалось несколько часов для загрузки данных (со значительными затратами), и они были во много раз медленнее, чем BigQuery.

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

person Felipe Hoffa    schedule 25.05.2016

arrow_upward
1
arrow_downward

Мы используем BigQuery, плюсы:

  • SQL, на основе столбцов
  • поддерживает данные JSON в столбцах --> преимущество, неструктурированное
  • чрезвычайно дешевый 1 петабайт около 21 тысячи долларов в месяц.
  • управляемый сервис от Google, без devops
  • Возможность приема 100 000 строк в секунду
  • см. слайд #24 из связанная презентация

Другие варианты использования и архитектуры вы найдете: http://www.slideshare.net/martonkodok/complex-realtime-event-analytics-using-bigquery-crunch-warmup

person Pentium10    schedule 24.05.2016
comment
какие минусы вы нашли из своего опыта? - person Mikhail Berlyant; 24.05.2016
comment
Отсутствие профессиональной поддержки, странные ошибки API, нужны очень продвинутые разработчики SQL, но это весело. - person Pentium10; 24.05.2016