Комментарии 16
Хочу спросить совета. У меня как раз случай маленького проекта. На текущий момент я имею примерно 10 000 000 событий. Храню в TSV-файлах, типа 2017-01-09.txt, обрабатываю через PHP с эпизодическим экспортом в MySQL и последующим исполнением SQL-запросов на получившихся таблицах. Хочется убрать (или минимизировать) вот этот слой про PHP-обработку tsv-файлов и работать сразу в формате SQL. Идея загнать всё в одну таблицу MySQL мне не очень нравится, учитывая, что это должно расширяться хотя бы до 100 млн. событий. Какую систему хранения и обработки вы можете посоветовать для таких масштабов, учитывая, что я явно попадаю в «маленькие проекты», и Hadoop мне, видимо, не нужен?
10/100 млн событий это всего или в день? Даже если в день, то тоже не проблема, пусть будет одна таблица и партиции в ней (надеюсь MySQL умеет партиции, если не умеет, то просто один день — одна новая таблица с аналогичной структурой), грузим тоже специализированной тулзой (Oracle sql*loader / PostgreSQL COPY, в MySQL наверное тоже что то такое есть) и дальше смело работаете, как вы выразились «в формате SQL». Ну и соответственно никакие хадупы тут не нужны.
10/100 млн — всего, проект маленький. У меня было ощущение, что 100 млн записей (это 20 ГБ в тексте) — это многовато для MySQL-таблицы. Хотя, сейчас погуглил, народ использует, и всё нормально. Возможно, мне надо побольше поэкспериментировать с настройками памяти. Сейчас как раз буду работать над аналитикой — попробую перевести хранилище на MySQL из текста. У меня был какой-то психологический барьер на единицы миллионов записей в MySQL :-)
(Извините, это я нажал на минус у комментария — промахнулся. Кто может, компенсируйте, пожалуйста.)
(Извините, это я нажал на минус у комментария — промахнулся. Кто может, компенсируйте, пожалуйста.)
Если там счётчики и часты именно агрегации/аналитика посмотрите на Clickhouse, а так обычной RDBMS хватит более чем, периодически делайте агрегации и партиционирование.
А не смотрели в сторону Elasticsearch? Он как раз заточен под хранение данных с привязкой по времени, типа логов. А в связке с logstash и kibana получите парсер данных -> наполнение базы -> представление в удобном виде.
У меня вопрос, все таки на какое железо ориентирован hadoop?
Исходя из личного опыта с задачками, где было много (ну или относительно много) данных, то весь затык всегда случался не на стороне сервера, а на стороне СХД. Условно даже на СХД начального уровня (например, IBM Storwise v3700) можно свободно хранить сотни терабайт данных, но скорость с которой современные магнитные диски выдают данные в разы уступает скорости с которой современные процессора способны переваривать эти данные. И собственно здесь у меня возникает непонимание — как мне поможет кластер серверов с хадупом, если СХД не может угнаться даже за одним более-менее мощным сервером?
Или подразумевается, что это кластер средненьких серверов и на каждом из них пара сотен ГБ встроенного стораджа на SSD и уже они собираются в кластер? Но если так, то при объемах в сотни ТБ можно разориться на железе…
Исходя из личного опыта с задачками, где было много (ну или относительно много) данных, то весь затык всегда случался не на стороне сервера, а на стороне СХД. Условно даже на СХД начального уровня (например, IBM Storwise v3700) можно свободно хранить сотни терабайт данных, но скорость с которой современные магнитные диски выдают данные в разы уступает скорости с которой современные процессора способны переваривать эти данные. И собственно здесь у меня возникает непонимание — как мне поможет кластер серверов с хадупом, если СХД не может угнаться даже за одним более-менее мощным сервером?
Или подразумевается, что это кластер средненьких серверов и на каждом из них пара сотен ГБ встроенного стораджа на SSD и уже они собираются в кластер? Но если так, то при объемах в сотни ТБ можно разориться на железе…
Кластеры Hadoop как правило используют локальные диски, расположенные на самих нодах. Внешнее хранилище не используется.
В Hadoop-е (или даже в MapReduce-е) активно используется понятие как "locality is a king", то есть данные должны лежать именно там где обрабатываются (в иделале) или точнее "обработка" должна совершаться там где данные расположились. Конкретно касательно СХД и Hadoop можно почитать тут — https://0x0fff.com/hadoop-on-remote-storage/ .
Супер доклад для новичков. Хочу продолжения, к примеру про Spark.
Не усмог увидеть ответ на главный вопрос, обозначенный в названии доклада: где заканчивается просто большая бд и начинается хадуп? Я понимаю, что вопрос довольно абстрактный, но слишком часто слышу истории про использование hadoop только ради hadoop, без какой либо выгодны.
Хотелось бы прочитать статью про то как у вас устроено тестирование hadoop.
Насчет бэкапа неймноды — а вы NameNode HA не используете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С чего начать внедрение Hadoop в компании