K
куда то их в итоге все равно пускать?
Size: a a a
2019 July 30
ПФ
схема смотрится show create table db.table
это кажется очень кривым путём.
K
я сейчас вообще не про отображение таблиц пользователям говорю,эта задача легко решается 100 разными способами, я лишь говорю, что в схеме hive+spark+ hdfs и еще куча разного компьюта ddl не дает никаких гарантий, а вводит в заблуждение
K
это кажется очень кривым путём.
смотреть текущую схему таблиц можно большим количеством разных способов
K
вопрос был не про это
ПФ
С моей точки зрения не должно возникать желания смотреть где-то кроме места, где определён DDL. И когда ты пишешь свой спаркджоб — тебе не надо никуда лезить, посмотри в репе с миграциями
K
С моей точки зрения не должно возникать желания смотреть где-то кроме места, где определён DDL. И когда ты пишешь свой спаркджоб — тебе не надо никуда лезить, посмотри в репе с миграциями
Пользователь таблицы полезет в гит?
ПФ
Пользователь таблицы полезет в гит?
Разработчик джоба полезет в гит
K
Разработчик джоба полезет в гит
Он увидит одну схему
K
В коде уже другая
ПФ
Хочешь добавить в коде что-то - поменяй DDL
AZ
в том то и дело, что подобный артефакт дает большие гарантии нежели руками написанный ddl, потому что программный подход добавляет как раз таки понимания и покрываемостью тестами,просто потому что это код и, как я уже говорил,метаданные соотвествуют данным , как минимум в рантайме( а значит в тестах).
И нет никакого отказа от гарантий, просто потому что нет разрыва того между тем, что именно считает джоба и что она отображает( а явно написанный ddl здесь лишь ручной труд и человеческий фактор)
И нет никакого отказа от гарантий, просто потому что нет разрыва того между тем, что именно считает джоба и что она отображает( а явно написанный ddl здесь лишь ручной труд и человеческий фактор)
такой артефакт вообще не содержит гарантий на тему DDL, он просто содержит arbitrary code и дело каких-то конвенций и код ревью чтобы он в результате породил конкретную схему.. дальше, если мы пишем тесты - мы должны вместо простого чтения DDL заинферить схему из кода и проверять ее в тестах? как насчет TDD? ну и как я сказал, DDL который генерит Spark находу - это технический DDL, его надо дополнительно парсить чтобы сделать из него что-то отторгаемое чтобы задеплоить отдельно (например на реплику в другом регионе/сайте)
c
Всем привет. Кто может поведать о том, как начинал в этой специальности? Что читал, учил
K
такой артефакт вообще не содержит гарантий на тему DDL, он просто содержит arbitrary code и дело каких-то конвенций и код ревью чтобы он в результате породил конкретную схему.. дальше, если мы пишем тесты - мы должны вместо простого чтения DDL заинферить схему из кода и проверять ее в тестах? как насчет TDD? ну и как я сказал, DDL который генерит Spark находу - это технический DDL, его надо дополнительно парсить чтобы сделать из него что-то отторгаемое чтобы задеплоить отдельно (например на реплику в другом регионе/сайте)
ну вот у вас есть технический DLL, а есть DLL который вы описали руками и он отличается, но по факут на хдфс у вас попадает данные с техническим ddl, ну возможно нужно отпарсить , если в условный mysql cохранять еще или как-то, но это всё делается один раз.
AZ
ну вот у вас есть технический DLL, а есть DLL который вы описали руками и он отличается, но по факут на хдфс у вас попадает данные с техническим ddl, ну возможно нужно отпарсить , если в условный mysql cохранять еще или как-то, но это всё делается один раз.
ну то есть мы возвращаемся к тому чтобы сделать DDL (только не сначала как постановку задачи, а как результат какого-то тестового прогона), и положить его рядом с джобом.. опять без ТДД.. и по сути вы деплоите просто спарковые джобы, а метастор - это просто что эти джобы решили туда сохранить.. это нормальная схема, я видел чисто МЛ даталейки которые так делают, но для промышленного даталейка который под гавернанс процессом кмк сложнее накрутить весь metadata harvesting чтобы выяснить что в итоге хранится, чем порождено, какие версии, чем сделать метаданные частью предмета поставки, и реализовать весь гавернанс как часть деплоймент процесса
K
ну то есть мы возвращаемся к тому чтобы сделать DDL (только не сначала как постановку задачи, а как результат какого-то тестового прогона), и положить его рядом с джобом.. опять без ТДД.. и по сути вы деплоите просто спарковые джобы, а метастор - это просто что эти джобы решили туда сохранить.. это нормальная схема, я видел чисто МЛ даталейки которые так делают, но для промышленного даталейка который под гавернанс процессом кмк сложнее накрутить весь metadata harvesting чтобы выяснить что в итоге хранится, чем порождено, какие версии, чем сделать метаданные частью предмета поставки, и реализовать весь гавернанс как часть деплоймент процесса
ну опять же , для тестов нужен слепок данных, итоговую схему можно получить в процессе билда и паблиша артефакта
AZ
ну опять же , для тестов нужен слепок данных, итоговую схему можно получить в процессе билда и паблиша артефакта
наверное не билда, а прогона против каких-то данных?
K
наверное не билда, а прогона против каких-то данных?
прогон против каких-то данных, да, или скорее прогон относительно каких-то источников, которые могут лежать в тех же ресурсниках или даже относительно реальных данных
AZ
интересно, так эти данные получается у вас в артефакте лежат? или какая-то схема кодогенерации между билдом и упаковкой?
AZ
а еще такой вопрос, если у вас DDL не входит в код, как код ревью проходит? как вы документируете что требуется от джоба в принципе?