Size: a a a

2019 July 24

AZ

Anton Zadorozhniy in Data Engineers
Nikita Blagodarnyy
Как-будто стоечный свитч просто рандомно половину пакетов дропает. Ребутнешь другие службы-на них тоже загорится.
ребутни свич
источник

DP

Dumitru Preguza in Data Engineers
В Spark есть способ сохранить alias"ы после createOrReplaceTempView ?
источник

A

Alexander in Data Engineers
Dumitru Preguza
В Spark есть способ сохранить alias"ы после createOrReplaceTempView ?
Что значит сохранить?
источник

DP

Dumitru Preguza in Data Engineers
Alexander
Что значит сохранить?
источник

DP

Dumitru Preguza in Data Engineers
Падает и за 18 строчки (где пытается использовать alias BANCLL34 что сверху)
источник

PA

Polina Azarova in Data Engineers
теперь моя очередь пугать всех hbase master is initializing)
пишет что 0 регионов
и такой ужас
1588230740 hbase:meta,,1.1588230740 state=FAILED_OPEN, ts=Wed Jul 24 20:40:26 MSK 2019 (793s ago), server=hadoop.com,60020,1563989855499
это всё, да?)
источник

АЖ

Андрей Жуков in Data Engineers
Дни hbase в чати!
источник

PA

Polina Azarova in Data Engineers
я вообще умею чинить FAILED_OPEN, но тут ошибка не в мете и выглядит так, что всё потрачено
источник

PA

Polina Azarova in Data Engineers
может диру в зукипере зачистить и его отпустит? ^^
источник
2019 July 25

MK

Max Kovgan in Data Engineers
добрый утр
источник

MK

Max Kovgan in Data Engineers
вот:
источник

MK

Max Kovgan in Data Engineers
ребят,  такой девопс-дев вопрос:

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

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

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

знаю, как через protobuf/thrift и т.п. сделать 1 источник истины и схемы для api+client, но тогда субд - не версионировано.

есть какое-то единое решение для schema management "сразу всего"?
источник

MK

Max Kovgan in Data Engineers
и вот:
источник

MK

Max Kovgan in Data Engineers
я понимаю как решить пол задачи одним методом,
и пол - другим.
но тогда будет перехлестываться "истина".
т.е. первое решение и второе будут вместе описывать de facto ту же схему.
источник

MK

Max Kovgan in Data Engineers
😘
источник

MK

Max Kovgan in Data Engineers
хотелось бы услышать что-то типа schema registry, и что protobuf/thrift/etc поддерживают sql
источник

e_

epik _ in Data Engineers
Max Kovgan
ребят,  такой девопс-дев вопрос:

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

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

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

знаю, как через protobuf/thrift и т.п. сделать 1 источник истины и схемы для api+client, но тогда субд - не версионировано.

есть какое-то единое решение для schema management "сразу всего"?
Можно OpenAPI заюзать - там есть генераторы почти для всего
источник

MK

Max Kovgan in Data Engineers
swagger & co. ?
источник

e_

epik _ in Data Engineers
ага, ну сваггер вроде платный. мы просто openAPI юзаем
источник

DZ

Dmitry Zuev in Data Engineers
Шо?
источник