Comments 5
Замечательно! Но не могу не заметить, что MSSQL делает такое из коробки. Конечно, сейчас в одной стране после известных событий по понятным причинам все переходят на Постгре, но тем не менее...
Многие СУБД умеют самые различные оптимизации: https://javarush.com/groups/posts/423-kljevihe-optimizacii-sql-ne-zavisjajshie-ot-stoimostnoy-modeli-chastjh-5-
Интересная инженерная задача, но я скорее соглашусь с сообществом: невозможно гарантировать выполнение констрейнтов в Data Lake.
Вы фактически сделали Vendor Lock-in на Data Lake для тех, кто будет внедрять ваше решение. Использование других инструментов может легко нарушать констрейнты. У меня, например, trino используется для перекачки данных в Apache Superset, очистка данных выполняется на Apache Spark.
Думаю, что более логичным шагом было бы внести предложения по констрейнтам в Delta Lake или Apache Iceberg или даже может в Hive Metastore, тогда можно было ожидать соблюдение гарантий констрейнта независимо от того, какой инструмент работает с данными в Data Lake
Хотя может я неправильно понял, может констрейнты влияют только на выбор плана исполнения, а фактические результат не будет отличаться независимо от того есть констрейнты или нет? В этом случае ваше решение действительно впечатляет как в инженерном плане, так и в уровне экспертизы.
Гарантировать выполнение констрейнтов на уровне аналитической системы действительно очень сложно (в первую очередь с точки зрения производительности), но и отказываться от их преимуществ не хочется. Поэтому типичный подход, который выбирают многие аналитические инстурменты - использовать констрейнты для планирования, но не проверять их. Это просто практический компромисс. Примеры: Apache Iceberg, Snowlfake, Tableau.
Как мы ускорили Trino, научив оптимизатор удалять ненужные Join