перформанс будет один

подчеркиваю, на батче

нет

ну вот смотри, у тебя 130-140 млн, сделай replication facktor 3, на 1,5 петабайта чистых данных, по которым надо периодически делать выборки

у вас есть сан, где все лежит, который помереть физически может, до него много гигабит проложено,и вот там hbase стоит

hbase какой-нибудь нельзя так конечно

и мы по ключу чего ищем

я про san не говорю

при этом у тебя разрабы не хотят ничего где больше 3 компонентов

или тот же батч, тебе сначала нужно петабайт на ноды прогнать

NAS и SAN разные вещи

потом обратно

например word count по петабайту

еще раз, смотри, у тебя 12 дисков создают максимальный поток ну может быть 20-30 гигабит в секунду, правильно?

локально если считать

а сеть у тебя 80 гигабит в секунду

сеть не боттлнек

ну ладно, это 5 лет назад все развеяли

hbase какой-нибудь нельзя так конечно

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

щас будут пруфы :)

что в большинстве случаев плохо

потому что вы на существующем кластере не можете быстро решать новые задачи

вам нужно городить новое решение узкоспецилищированное

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

что в большинстве случаев плохо

тоже нет, это плохо для тех кто держится за он-премис бареметал инфру, и в таких случаях у вас в сто раз сложнее задача - обеспечить уровень сервиса для всех ваших сервисов на одном кластере

у меня был бареметал комплекс, мы для операционного hbase вынуждены были делать отдельный кластер просто потому что никак нельзя все вместе, и аналитику и hbase обеспечить - упираемся в просаживание по latency дисков

у меня был бареметал комплекс, мы для операционного hbase вынуждены были делать отдельный кластер просто потому что никак нельзя все вместе, и аналитику и hbase обеспечить - упираемся в просаживание по latency дисков

ну так может hbase правильно использовать?

ну так может hbase правильно использовать?

эт как? :)

входящий поток до полумиллиона сообщений в секунду на дневной полке, нужно хранить последние дцать события по каждому клиенту, персистентно

оно прекрасно работало к слову

и до сих пор вроде работает

но на облаке у нас данные лежали бы в объектном сторе который отделен от компьюта (да, он медленее чем эфемерал, но зато сразу реплицируется по АЗ, и позволяет запускать отдельные кластера для аналитики по этим данным по требованию), а онлайновая база была бы в какой-то динаме, отдельно

вот выше приложил whitepapers на тему эффекта data locality, из начала 2010-ых - не устарели :)

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

я вообще не предлагаю делать зоопарк :)

есть известный набор capabilities, мы их реализуем известными компонентами, для батча это объектный сторадж + компьют, иногда это HDFS + YARN, иногда это S3 + YARN, а иногда это Ceph + Kubernetes

Почему же, сейчас файлохранилище и какая-то аналитика для батча, потом кластер HBase или еще что-то и т.п. Да, в облаке это решается просто - выбрал сервис и запустил, но тут же облако не подходит, видимо.

кому что удобнее по его потребностям и легаси

HBase особенно таких размеров как был у нас мало кому нужен, это не часть "обязательной программы"

Безопасность, аудит и т.п. не нужно?

обязательно нужно

это вообще главный хлеб

уже пятая реализация GDPR на даталейке за плечами, так что знаю о чем говорю :)

Ну так ты знаешь, что для GDPR тебе нужно или набрать еще кубики, или делать свой велосипед.

да, например HDP/HDF дают неплохую заготовку, но там пилить и пилить

да, например HDP/HDF дают неплохую заготовку, но там пилить и пилить

Это правда

но некоторым клиентам нужен confluent, и тогда нужно думать куда писать lineage например

Но HDP/HDF - вот она система достаточно общего назначения и зоопарк. Или нет?

кстати confluent кафку можно заставить жить с ranger plugin, но сама контора тогда не обещает обслуживания в рамках SLA

Но HDP/HDF - вот она система достаточно общего назначения и зоопарк. Или нет?

я не понимаю критерия "зоопарковости"

у меня у текущего клиента 7 кластеров HDP и 4 кластера confluent, хостятся под десяток приложений в которых сочетается стриминг с батчом

Я тогда тоже не понимаю, о чем вы спорите)

это зоопарк? :)

про зоопарк ты вроде начал

Началось с коробки per use case против сумки с инструментами, нет?)

я не говорил с коробки per use case

коробка per capability

это зоопарк? :)

Что там с сервисом? SLA выдерживается? Такой подход же не расходится с @krivdathetriewe, получается, а сервис зависит от рук, по собственному опыту.

Что там с сервисом? SLA выдерживается? Такой подход же не расходится с @krivdathetriewe, получается, а сервис зависит от рук, по собственному опыту.

о да, это главная причина множества кластеров; там клиент до сих пор упирается в он-премис, поэтому все растащено по нескольким датацентрам и обложено кастомными репликациями, фейловерами и реконсиляциями

Привет! В ближайших планах переезд с 2.x на 3.x (дистрибутив HDP) , какие могут быть подводные камни?

Интересно кому если, то мы практически переехали.

Интересно кому если, то мы практически переехали.

а вы DPS пробовали?

Интересно кому если, то мы практически переехали.

Переезжали в каком составе, всю грядку сервисов?

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

Переезжали в каком составе, всю грядку сервисов?

Всю HDP разом.

Основные проблемы были с специализированными компонентами около платформы (например, из-за изменения для учетных данных регистра), в остальном ок, хотя документация содержит ошибки. В целом, неплохо.

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

а как реплицируете сейчас?

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

и еще вопрос: это rolling upgrade или требуется даунтайм на каждом кластере, и какой?

на R&D выпустил HDP3 как вариант для новых инсталляций, но пока нет апгрейда, ждем чего намутят вместе с HWX

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

Остались разработки и миграция данных

Когда с 2 на 3, то только Express и простой.

мне заявили похрен на практики и тд, у нас бюджет

Ростелеком что ль? Го и бюджет

Морячки наверняка

Ростелеком что ль? Го и бюджет

Нет, не Ростелеком

на R&D выпустил HDP3 как вариант для новых инсталляций, но пока нет апгрейда, ждем чего намутят вместе с HWX

а чего у вас за фирма?

а чего у вас за фирма?

https://teradata.com

щас будут пруфы :)

Прочитал одну статью. Ну неоднозначно совсем

Медленнее, дороже, споф - резонный вопрос зачем

https://teradata.com

Расскажи как там?

Медленнее, дороже, споф - резонный вопрос зачем

не сильно медленнее, споф это смотря как сделать, зачем - отдельное масштабирование компьюта!

Медленнее, дороже, споф - резонный вопрос зачем

зависит от реализации, s3 у amazon не spof

Расскажи как там?

смотря в какой практике, в нашей неплохо

зависит от реализации, s3 у amazon не spof

+1, s3 это противоположность spof

не сильно медленнее, споф это смотря как сделать, зачем - отдельное масштабирование компьюта!

ну вообще все это имеет смысл для cloud, в on-premise только для изолирования batch и near real-time

Реплицировать данные rsyncом между несколькими хостами и следить за этим, это не то же самое что и s3 использовать

ну вообще все это имеет смысл для cloud, в on-premise только для изолирования batch и near real-time

c точки зрения чистого перфоманса для он-према система с HDFS+YARN будет быстрее, это факт, но с точки зрения управляемости, гомогенности среди - будут люди делать дата лейки на ceph + k8s, истино говорю, если еще не делают

И NFS аналогично, ждём Apache Ozone

c точки зрения чистого перфоманса для он-према система с HDFS+YARN будет быстрее, это факт, но с точки зрения управляемости, гомогенности среди - будут люди делать дата лейки на ceph + k8s, истино говорю, если еще не делают

Да, согласен, второе, особенно если в облаке, будет быстрее, дешевле, и проще в обслуживании

зависит от реализации, s3 у amazon не spof

Мы про облака или онпрем?

Можно и свой с3-комп. Но нафейхуа при хдфс

Ceph можно не только для хдфс использовать, например

Мы про облака или онпрем?

В он-преме можно swift от openstack поднять

Или свифт

и создавайте в openstack хосты с spark только когда нужны для обсчёта

А может он уже есть

и всё

И в Alluxio кэшировать

Пошустрее будет