как раз за gridgain Грефу памятник еще поставят, когда они единственные из банков не будут вырублены ораклом и будут иметь живой пример куда двигаться в век клаудов и кластеров
у вас хреновый архитек. в итерации не должны поля появляться, поля могут возникнуть в результате серьезной трудности засунуть сущность в существующие структуры. добавление колонки это форс мажер, а не планомерная работа. то же касается связей между таблицами, они должны настраиваться без DDL.
так я и не требую абсолютно все, я говорю что архитек не доработал, если вам постоянно требуется изменения в структурах. меняющиеся требования не должны требовать постоянных изменений структур.
да, SQL не идеален, требует разбивать шибко сложные запросы, требует процедурных костылей. да, но альтернативы то не решили эти проблемы, а лишь возвели их в квадрат. совсем недавно все бегали с map-reduce парадигмой, поработали пару лет и утомились писать вместо небольшого джоина на один абзац десяток классов, которые требуется рефакторить каждый квартал иначе кластер дохнет. утомившись с чистой джавой и цикл в цикле, запускает цикл срочно приладили элементы функционального языка, но и тут счастья не наступило. теперь поверх функциональщины повсюду прилаживают старый добрый SQL.
что касается ваших проблем, то у вас явно не доработал архитек, раз схема постоянно меняется. в рсубд принято воротить универсальные структуры, на все случаи жизни и на века.
побеждает потому, что практика показала то что все альтернативы в итоге сильно проигрывают. при разработке оптимальным ожидается одно, при запуске оказывается оптимально данные достать по другому, через какое-то время даные распухают не равномерно и оптимум уже третий. переписывая в третий раз, люди начинуют понимать силу деклативного языка и начинают от вендоров требовать прикрутить SQL. к хадупам уже прикрутили, in memory grids аля apache ignite тоже по сути SQL уже прикручен.
видимо вы в весьма глухом месте живете, у нас вот SQL абстракция никуда не потекла, а лишь захватила еще и наши хадупы, гнусно посмеявшись на бесплодными попытками чем либо заменить. spark на хадупах — все тот же sql, все тот же cost based оптимизатор. ничего лучше так никто и не предложил
В случае, когда я делаю закат солнца вручную (пишу джойны, аггрегации, подзапросы прямо в коде приложения, делаю руками выборку, вотэтовсё), я могу это легко контролировать — сделать декомпозицию на несколько простых, часто чистых, функций, каждую из которых обложить тестами и комбинировать уже готовые абстрагированные блоки, контролируя таким образом сложность, как алгоритмическую, так и тестирования.
в 80х годах прошлого века от этого подхода отказались в пользу cost based optimizator. это то же самое, что в сезон отпусков проложить маршрут через центр города, а потом весь год терять 3 часа в пробках, которые более сообразительная молодежь объезжает, потому что маршрут выбирает в зависимости от дорожных условий.
самое главное преимущество SQL — он не указывает как достать данные. это декларативный язык.
да, они работают ровно так же как и 30 лет назад. что рсубд, что нафигационные. поэтому подход читать в параллель все без разбору, не разбираясь нужно или не нужно выглядит чем-то новым. 30 лет назад о таком никто и помыслить не мог.
30 лет назад никому в голову не приходило читать параллельно с тысячи нод принципиально все данные, абсолютно все субд тогда доставали данные по индексу и соревновались методиках сокращения кол-ва чтений. что иерархические, что рсубд.
во первых k-v хранилище не иерархия, во вторых если я натолкаю в dbf таблички ссылку на парент, фокспро не превратиться в иерархическую субд.
там все реально по другому. суть иерархической субд — нафигация по индексу, суть того о чем я говорю противоположна. там зачастую читают абсолютно все данные начала времен.
ничего общего. иерахические это ничем не примечательны. одна нода, нафигация по иерархии, update/delete, блокировки, транзакции и прочее. то о чем я говорю из другого мира. тысячи нод и просто файлики, никаких транзакций, update/delete, блокировок и прочего. в файликах просто ключь-значение. это и не субд даже, это подход.
но все такие есть еще один подход, который правда базой не назвать. из парадигмы бигдата. k-v хранилище с табу на update/delete. в value храниться сложный объект (например avro-parquet). учитывая, что это все заморочено ради параллельной обработки, то все таки это нечто новое и мало похожее на все, что было ранее.
ну BI к хадупам может совсем open source и нет, но это же крошечная часть решения, не самая дорогая и к тому же сегодня уже любой BI поверх хадупа бегает. это не самая дорогая и нагруженная часть решения. IBM, Oracle, «Полиматика», «Прогноз» все работают по верх хадупов.
по нетизе, разве там кроме NZSQL и C++ на чем то можно писать то, что будет на узлах кластера запускаться? там же все языки лишь как SQL клиент выступают.
как не крути хадупы фичастее и перспективней, а в свете санкций и ориентира на импортнозамещение считай неизбежны в гоструктурах. было бы лучше если бы госсектор в эту сторону развивал компетенции, а не подсаживался глубоко на сугубо американский софт. тем более, что хадупы много выгодней по деньгам.
думаю хадупы намного фичастее. в хадупах можно воротить всякие реалтайм стриминги, кафки, тьма сториджей под различные задачки, джобы на разных языках можно писать, в комплекте мульёны ML библитек.
слышал что в госструктурах зарплаты у работяг много меньше, отсюда и уровень спецов меньше.
по системе все здорово, но нафига IBM? в гоструктурах должен быть опенсоурс, дата лейк на хадупе, который все это и дешевле и фичастее сделает
все хорошо, но что за задача то? зачем читаются эти файлы?
как я понимаю Oozie будет запускать каждый джоб через spark-submit скрипт, т.е. стартовать на каждый джоб отдельный jvm, соответственно каждый джоб будет иметь свой sparkSession. многим задачам такое не подойдет…
что касается ваших проблем, то у вас явно не доработал архитек, раз схема постоянно меняется. в рсубд принято воротить универсальные структуры, на все случаи жизни и на века.
в 80х годах прошлого века от этого подхода отказались в пользу cost based optimizator. это то же самое, что в сезон отпусков проложить маршрут через центр города, а потом весь год терять 3 часа в пробках, которые более сообразительная молодежь объезжает, потому что маршрут выбирает в зависимости от дорожных условий.
самое главное преимущество SQL — он не указывает как достать данные. это декларативный язык.
там все реально по другому. суть иерархической субд — нафигация по индексу, суть того о чем я говорю противоположна. там зачастую читают абсолютно все данные начала времен.
по нетизе, разве там кроме NZSQL и C++ на чем то можно писать то, что будет на узлах кластера запускаться? там же все языки лишь как SQL клиент выступают.
как не крути хадупы фичастее и перспективней, а в свете санкций и ориентира на импортнозамещение считай неизбежны в гоструктурах. было бы лучше если бы госсектор в эту сторону развивал компетенции, а не подсаживался глубоко на сугубо американский софт. тем более, что хадупы много выгодней по деньгам.
по системе все здорово, но нафига IBM? в гоструктурах должен быть опенсоурс, дата лейк на хадупе, который все это и дешевле и фичастее сделает
как я понимаю Oozie будет запускать каждый джоб через spark-submit скрипт, т.е. стартовать на каждый джоб отдельный jvm, соответственно каждый джоб будет иметь свой sparkSession. многим задачам такое не подойдет…
а движок у Hive какой, Tez?