Unity Catalog στο Databricks: διακυβέρνηση στημένη σωστά

Το Unity Catalog είναι το επίπεδο διακυβέρνησης στο Databricks. Ελέγχει ποιος μπορεί να βλέπει και να αλλάζει κάθε πίνακα, view, file volume, function και μοντέλο AI, καταγράφει το lineage ανάμεσά τους και κρατά αρχείο πρόσβασης ώστε να μπορείτε να το αποδείξετε σε έναν ελεγκτή.

Αν τρέχετε σήμερα Databricks, είστε ήδη σε αυτό ή μεταφέρεστε σε αυτό. Το legacy Hive metastore αποσύρεται και κάθε νεότερη δυνατότητα του Databricks προϋποθέτει το Unity Catalog από κάτω.

Το ερώτημα δεν είναι πλέον αν θα το υιοθετήσετε. Είναι αν ο σχεδιασμός των catalogs σας θα έχει ακόμη νόημα μετά από τρία χρόνια νέων ομάδων, νέων δεδομένων και έναν ή δύο ελέγχους.

Στα προγράμματα μεταποίησης και άμυνας όπου έχω δουλέψει, η τεχνολογία σπάνια ήταν το δύσκολο κομμάτι. Δύσκολο ήταν να συμφωνηθεί ποιος κατέχει ποια δεδομένα, πώς διαχωρίζονται τα περιβάλλοντα και ποια τεκμήρια χρειάζεται η ομάδα ασφάλειας.

Όλα βρίσκονται κάτω από ένα metastore, τον κορυφαίο container. Από κάτω, τα assets δεδομένων και AI χρησιμοποιούν ένα namespace τριών επιπέδων: catalog.schema.object. Ένα query στο prod_finance.gl.journal_lines ονομάζει το catalog, το schema και τον πίνακα.

Τα αντικείμενα στα οποία δίνετε δικαιώματα λέγονται securable objects. Σύμφωνα με την τεκμηρίωση του Unity Catalog, χωρίζονται σε δύο ομάδες:

1. Assets με namespace: πίνακες, views, volumes (file storage υπό διακυβέρνηση), functions, μοντέλα και services.
2. Αντικείμενα σε επίπεδο metastore: storage credentials, external locations, connections (προς εξωτερικές βάσεις δεδομένων) και shares.

Δύο από αυτά τα αντικείμενα επιπέδου metastore αξίζουν μια απλή εξήγηση, γιατί καθορίζουν πού βρίσκονται φυσικά τα δεδομένα σας.

Ένα storage credential περιέχει μια ταυτότητα cloud, όπως ένα IAM role ή ένα managed identity, που έχει πρόσβαση σε storage account ή bucket. Ένα external location συνδυάζει μια διαδρομή storage με ένα credential. Μαζί επιτρέπουν στο Unity Catalog να διαβάζει και να γράφει στο cloud storage χωρίς να δίνει κλειδιά στους χρήστες.

Μετά, managed απέναντι σε external. Με τους managed πίνακες, το Unity Catalog διακυβερνά τον πίνακα και διαχειρίζεται τα αρχεία του. Με τους external πίνακες, διακυβερνά μόνο την πρόσβαση.

Η Databricks προτείνει πλέον managed πίνακες για όλα τα νέα δεδομένα και κρατά τους external κυρίως για αναβαθμίσεις από Hive. Συμφωνώ. Το ότι άλλα εργαλεία γράφουν στις ίδιες διαδρομές είναι συνήθως λόγος να διορθώσετε το pipeline, όχι να μείνει ο πίνακας external για πάντα.

Ένας περιορισμός διαμορφώνει τα πάντα: μπορείτε να έχετε μόνο ένα metastore ανά περιοχή cloud. Δεν λύνετε την απομόνωση με περισσότερα metastores. Τη λύνετε με catalogs.

Τα δικαιώματα του Unity Catalog είναι τυπικά SQL grants που κληρονομούνται προς τα κάτω. Ένα grant σε catalog ισχύει για κάθε schema και πίνακα μέσα του. Ένας χρήστης χρειάζεται USE CATALOG και USE SCHEMA για να φτάσει σε έναν πίνακα και μετά SELECT για να τον διαβάσει.

GRANT USE CATALOG ON CATALOG prod_finance TO `finance-analysts`;
GRANT USE SCHEMA ON SCHEMA prod_finance.gl TO `finance-analysts`;
GRANT SELECT ON SCHEMA prod_finance.gl TO `finance-analysts`;

Τα grants απαντούν στο «μπορεί αυτή η ομάδα να διαβάσει αυτόν τον πίνακα». Τα ρυθμιζόμενα δεδομένα χρειάζονται πιο λεπτομερείς απαντήσεις, και εκεί μπαίνουν οι υπόλοιποι έλεγχοι.

Ο πίνακας συνοψίζει τους κύριους ελέγχους πρόσβασης και την κατάστασή τους τον Οκτώβριο του 2026.

Έλεγχος	Τι κάνει	Κατάσταση (Οκτώβριος 2026)
Grants και ιδιοκτησία	Δικαιώματα σε επίπεδο αντικειμένου, κληρονομούμενα από catalog σε schema και σε αντικείμενο	Γενικά διαθέσιμο
Row filters και column masks σε επίπεδο πίνακα	Μια SQL function συνδεδεμένη με έναν πίνακα κρύβει γραμμές ή καλύπτει τιμές	Γενικά διαθέσιμο
Πολιτικές ABAC για row filters και column masks	Μία πολιτική, ορισμένη σε επίπεδο catalog, schema ή πίνακα, ισχύει για κάθε αντικείμενο που φέρει governed tag	GA από τις 28 Απριλίου 2026
Governed tags	Tags σε επίπεδο λογαριασμού με ελεγχόμενα κλειδιά, τιμές και το ποιος μπορεί να τα αναθέτει	GA από τις 2 Απριλίου 2026
Ταξινόμηση δεδομένων	Σαρώνει πίνακες και επισημαίνει ευαίσθητα δεδομένα όπως PII	GA από τις 20 Απριλίου 2026· custom classifiers σε Beta
Πολιτικές ABAC DENY και πολιτικές σε επίπεδο metastore	Ρητές απαγορεύσεις που υπερισχύουν των grants· πολιτικές σε εμβέλεια metastore	Beta
Cross-engine ABAC	Εξωτερικές μηχανές διαβάζουν managed πίνακες με προστασία ABAC, με τις πολιτικές να επιβάλλονται από το serverless compute του Databricks	GA από την 1η Οκτωβρίου 2026

Οι ημερομηνίες προέρχονται από τα release notes της Databricks για τον Απρίλιο 2026 και τα release notes του Οκτωβρίου 2026.

Το ABAC (attribute-based access control) είναι η αλλαγή που μετράει περισσότερο για μεγάλα περιβάλλοντα. Αντί να γράφετε ένα mask ανά πίνακα, βάζετε tag στις στήλες, για παράδειγμα classification = export_controlled, και γράφετε μία πολιτική που καλύπτει κάθε στήλη με αυτό το tag για όλους εκτός από μια επώνυμη ομάδα.

Οι νέοι πίνακες προστατεύονται μόλις αποκτήσουν tag. Η ταξινόμηση δεδομένων μπορεί να προτείνει τα tags.

Ελέγξτε πρώτα το compute. Οι πίνακες με ασφάλεια ABAC χρειάζονται serverless compute ή Databricks Runtime 16.4 και πάνω. Τα παλαιότερα clusters δεν μπορούν να τους διαβάσουν καθόλου.

Δύο παγίδες που θα επισήμαινα νωρίς. Αντικρουόμενες πολιτικές στην ίδια στήλη για τον ίδιο χρήστη μπλοκάρουν το query με σφάλμα.

Και αν η ταυτότητα run-as ενός pipeline πέφτει κάτω από ένα mask, τα ανανεωμένα δεδομένα μπορεί να αποθηκευτούν καλυμμένα. Εξαιρέστε σκόπιμα τις ταυτότητες υπηρεσιών και τεκμηριώστε το γιατί.

Το lineage καταγράφεται αυτόματα, μέχρι το επίπεδο στήλης, για queries που τρέχουν μέσω Databricks SQL και Spark DataFrames σε οποιοδήποτε workspace συνδεδεμένο με το metastore. Καλύπτει notebooks, jobs, pipelines και dashboards. Το lineage στηλών χάνεται όταν ο κώδικας αναφέρεται σε πίνακες μέσω διαδρομής storage, ακόμη ένας λόγος να καταργήσετε την πρόσβαση μέσω διαδρομών.

Τα τεκμήρια audit προέρχονται από τα system tables. Το system.access.audit κρατά τα συμβάντα audit και φέρει ακόμη την ένδειξη Public Preview στην τεκμηρίωση των system tables.

Οι πίνακες lineage και billing βρίσκονται δίπλα του, με 365 ημέρες δωρεάν διατήρησης. Από προεπιλογή μόνο οι διαχειριστές λογαριασμού και metastore βλέπουν τα system tables, οπότε αποφασίστε νωρίς ποιος παίρνει δικαίωμα ανάγνωσης και αν θα αντιγράφετε τα δεδομένα audit στο SIEM σας για μεγαλύτερη διατήρηση.

Το sharing άλλαξε όνομα φέτος. Η Databricks ανακοίνωσε το OpenSharing στις 10 Ιουνίου 2026 ως την επόμενη έκδοση του πρωτοκόλλου Delta Sharing, που φιλοξενείται πλέον από το Linux Foundation και επεκτείνεται σε assets AI και clients Iceberg.

Θα βλέπετε ακόμη «Delta Sharing» σε παλαιότερα έγγραφα και συμβάσεις. Ένα share είναι αντικείμενο του Unity Catalog, και το sharing Databricks προς Databricks είναι επίσης ο τρόπος να μετακινείτε δεδομένα ανάμεσα σε περιφερειακά metastores.

Για μικτά περιβάλλοντα, οι managed και foreign πίνακες Apache Iceberg έγιναν γενικά διαθέσιμοι στις 21 Μαΐου 2026. Οι foreign πίνακες διαβάζονται μέσω Lakehouse Federation από catalogs όπως το AWS Glue ή το Snowflake Horizon. Μηχανές όπως Spark, Flink και Trino μπορούν να χρησιμοποιούν το Iceberg REST catalog endpoint του Unity Catalog.

Υπάρχει επίσης ένα open-source Unity Catalog υπό το LF AI & Data Foundation, αλλά είναι έργο σε στάδιο sandbox, όχι η managed υπηρεσία. Μην χτίσετε σχέδιο εξόδου πάνω του χωρίς δοκιμή.

Τα catalogs είναι η κύρια μονάδα απομόνωσης. Οι βέλτιστες πρακτικές της Databricks για το Unity Catalog λένε ότι τα catalogs συνήθως αντιστοιχούν σε ένα περιβάλλον, μια ομάδα, μια επιχειρηματική μονάδα ή συνδυασμό τους. Οι περισσότεροι πραγματικοί σχεδιασμοί είναι συνδυασμός.

Δύο τρόποι να χωρίσετε τα catalogs

Catalog ανά περιβάλλον

• Catalogs dev, test και prod, schemas ανά τομέα
• Εύκολη σύνδεση κάθε catalog με το workspace του
• Η ιδιοκτησία θολώνει καθώς οι τομείς μεγαλώνουν μέσα σε ένα catalog
• Ταιριάζει σε μικρότερες ομάδες και πρώιμες υλοποιήσεις

Catalog ανά τομέα και περιβάλλον

• prod_finance, prod_quality, dev_finance και ούτω καθεξής
• Κάθε ομάδα τομέα κατέχει τα δικά της catalogs
• Σαφής λογοδοσία και καθαρότερο εύρος audit
• Περισσότερα catalogs για ονοματοδοσία, σύνδεση και grants

Θα επέλεγα ως προεπιλογή τομέα συν περιβάλλον για κάθε εταιρεία με περισσότερες από μια χούφτα ομάδες δεδομένων. Απαιτεί περισσότερη πειθαρχία στην ονοματοδοσία από την αρχή. Γλιτώνει τον καβγά δύο χρόνια αργότερα για το ποιος κατέχει τον πίνακα που όλοι ρωτούν αλλά κανείς δεν συντηρεί.

Ο υπόλοιπος σχεδιασμός καταλήγει σε τέσσερις κανόνες:

1. Οι ομάδες έρχονται από τον identity provider σας. Εισάγετε χρήστες και ομάδες στον λογαριασμό Databricks μέσω automatic identity management ή μέσω SCIM αν ο provider σας δεν το υποστηρίζει. Ορίστε τις ομάδες στο Microsoft Entra ID, στο Okta ή σε αντίστοιχο, όχι στο Databricks. Όταν κάποιος φεύγει, η πρόσβαση φεύγει μαζί με τον λογαριασμό του στον κατάλογο.
2. Οι ομάδες κατέχουν τα παραγωγικά αντικείμενα. Η οδηγία της ίδιας της Databricks είναι να ανατίθεται η ιδιοκτησία των παραγωγικών catalogs και schemas σε ομάδες, ποτέ σε άτομα. Ένας ιδιοκτήτης μπορεί να δίνει πρόσβαση, οπότε ένα άτομο ως ιδιοκτήτης είναι μόνιμη εξαίρεση.
3. Συνδέστε τα catalogs με workspaces. Ένα παραγωγικό catalog συνδεδεμένο μόνο με παραγωγικά workspaces δεν μπορεί να ερωτηθεί από ένα sandbox, ό,τι κι αν λένε τα grants.
4. Ταξινομήστε πριν δώσετε πρόσβαση. Συμφωνήστε ένα σύντομο λεξιλόγιο tags (ευαισθησία, προσωπικά δεδομένα, έλεγχος εξαγωγών, σύστημα προέλευσης) ως governed tags και γράψτε πολιτικές ABAC πάνω σε αυτό.

Στη μεταποίηση, οργάνωσα τα catalogs ανά σύστημα εργοστασίου, δηλαδή ανά τομέα OT και συστήματος προέλευσης, όχι ανά εργοστάσιο. Τα δεδομένα OT από historians, MES και αισθητήρες βρίσκονται στα δικά τους catalogs, που τα κατέχει η ομάδα δεδομένων παραγωγής ή μηχανικής. Τα δεδομένα IT από το ERP (SAP, Oracle ή Microsoft Dynamics 365), την ποιότητα και την εφοδιαστική αλυσίδα βρίσκονται σε άλλα.

Τα επιμελημένα, συνδεδεμένα δεδομένα για τους αναλυτές ζουν σε ένα τρίτο σύνολο. Το όριο OT/IT γίνεται ορατό μέσα στο ίδιο το catalog. Αν η εξαγωγή από το ERP είναι εντός εύρους, οι σημειώσεις μου για το γιατί αποτυγχάνει η μετάπτωση δεδομένων SAP ισχύουν και για τις ροές δεδομένων ERP.

Στα αμυντικά προγράμματα, περιμένετε από την ομάδα ασφάλειας τέσσερις ερωτήσεις. Ποιος μπορεί να δει δεδομένα υπό έλεγχο εξαγωγών; Πώς διαχωρίζονται από όλα τα υπόλοιπα;

Πού αποθηκεύονται; Μπορείτε να τα αποδείξετε όλα αυτά για οποιαδήποτε μέρα του τελευταίου έτους;

Το Unity Catalog απαντά στις περισσότερες, αν σχεδιάσετε γι' αυτό:

1. Ελάχιστα δικαιώματα. Κανένα grant σε επίπεδο metastore ή catalog σε ευρείες ομάδες. Δώστε grants σε επίπεδο schema σε επώνυμες ομάδες και χρησιμοποιήστε masks ABAC για στήλες με tag ελέγχου. Χρησιμοποιήστε πολιτικές DENY μόνο όταν βγουν από το Beta και τις αποδεχτούν οι φορείς διαπίστευσης.
2. Διαχωρισμός. Χωριστά catalogs για τα ελεγχόμενα δεδομένα, με δική τους managed τοποθεσία storage, συνδεδεμένα με αποκλειστικά workspaces. Η Databricks προτείνει το managed storage σε επίπεδο catalog ως κύρια μονάδα απομόνωσης, κάτι που ταιριάζει καλά εδώ.
3. Διαμονή δεδομένων. Ένα metastore ανά περιοχή σημαίνει ότι τα δεδομένα μένουν στην περιοχή του storage τους, εκτός αν κάποιος τα μοιραστεί. Αντιμετωπίστε κάθε share του OpenSharing και κάθε σύνδεση ανάμεσα σε περιοχές ως απόφαση διαμονής δεδομένων που χρειάζεται έγκριση.
4. Τεκμήρια audit. Το lineage μαζί με το system.access.audit, εξαγόμενα στο SIEM σας, σας δείχνουν ποιος είχε πρόσβαση σε τι και πού κατέληξε. Έχετε υπόψη ότι ο πίνακας audit είναι ακόμη σε Public Preview. Στη δουλειά μου στην άμυνα, οι ομάδες ασφάλειας ήθελαν τα audit logs αντιγραμμένα στο δικό τους SIEM, όχι μόνο στα system tables του Databricks. Βάλτε αυτή τη ροή στο σχέδιο από την αρχή.

Το Unity Catalog δεν αποφασίζει τι θεωρείται διαβαθμισμένο ή δεδομένο υπό έλεγχο ITAR και δεν αντικαθιστά τη διαπίστευση. Ορισμένοι αμυντικοί φόρτοι εργασίας δεν μπορούν να τρέξουν καθόλου σε εμπορική περιοχή cloud.

Ο σχεδιασμός των catalogs βοηθά κι εκεί: τραβά μια καθαρή γραμμή ανάμεσα σε ό,τι μπορεί να πάει στην πλατφόρμα και ό,τι όχι. Αν γράφετε το επίπεδο πολιτικής που βρίσκεται πάνω από την πλατφόρμα, ο οδηγός μου για πλαίσιο διακυβέρνησης AI καλύπτει την πλευρά των ρόλων και των εγκρίσεων.

Αυτή είναι η σειρά που θα ακολουθούσα για μια εταιρεία που μεταφέρεται από το Hive metastore ή ξεκινά από την αρχή.

1. Συμφωνήστε το μοντέλο catalogs και τη σύμβαση ονοματοδοσίας. Τομέας συν περιβάλλον, γραμμένο, εγκεκριμένο από τους ιδιοκτήτες των δεδομένων. Αν το αλλάξετε αργότερα, μετονομάζετε τα πάντα.
2. Συνδέστε τον identity provider. Provisioning σε επίπεδο λογαριασμού, ομάδες ορισμένες στον κατάλογο, SCIM σε επίπεδο workspace απενεργοποιημένο για τα workspaces του Unity Catalog.
3. Στήστε storage credentials και external locations. Τα κατέχει μια ομάδα πλατφόρμας. Κανείς άλλος δεν παίρνει CREATE EXTERNAL LOCATION.
4. Δημιουργήστε catalogs με managed storage και συνδέσεις με workspaces. Τα παραγωγικά catalogs ανήκουν σε ομάδες από την πρώτη μέρα.
5. Ορίστε governed tags και ενεργοποιήστε την ταξινόμηση δεδομένων. Ελέγξτε τα ευρήματά της πριν γράψετε πολιτικές πάνω τους.
6. Γράψτε πολιτικές ABAC για ευαίσθητες στήλες. Δοκιμάστε με πραγματικούς χρήστες σε κάθε τύπο compute που τρέχετε, συμπεριλαμβανομένου κάθε cluster που είναι ακόμη κάτω από το Runtime 16.4.
7. Μεταφερθείτε από το Hive metastore. Η Databricks προτείνει πλέον πρώτα federation του Hive metastore και μετά αναβάθμιση των πινάκων επί τόπου. Το UCX βοηθά σε μεγάλα περιβάλλοντα, αλλά είναι έργο του Databricks Labs, που το συντηρεί η κοινότητα και δεν υποστηρίζεται επίσημα. Σχεδιάστε αναλόγως.
8. Ενεργοποιήστε την εξαγωγή audit και τον έλεγχο του lineage. Δώστε δικαίωμα ανάγνωσης στα system tables, στήστε τη ροή προς το SIEM και συμφωνήστε ποιος ελέγχει τι.
9. Απενεργοποιήστε την πρόσβαση στο Hive metastore μόλις μεταφερθούν όλα, ώστε κανείς να μη χτίζει σιωπηλά πάνω στην παλιά διαδρομή.

1. Grants σε μεμονωμένα άτομα. Λειτουργεί για μια εβδομάδα. Μετά κανείς δεν μπορεί να απαντήσει ποιος έχει πρόσβαση σε τι.
2. Ένα τεράστιο catalog με schemas ανά ομάδα. Η ιδιοκτησία και το εύρος του audit θολώνουν, και το ξαναχτίζετε αργότερα.
3. Πίνακες που μένουν external «προς το παρόν». Χάνετε τις δυνατότητες των managed πινάκων και κρατάτε δύο ιδιοκτήτες για κάθε αρχείο.
4. Δοκιμή πολιτικών σε έναν μόνο τύπο cluster. Το ABAC συμπεριφέρεται διαφορετικά ανάλογα με το compute. Τα παλιά runtimes αποτυγχάνουν εντελώς.
5. Το audit ως μεταγενέστερη φάση. Ο ελεγκτής θα ρωτήσει για την περίοδο πριν το ενεργοποιήσετε.

Αν είστε στην αρχή, γράψτε το μοντέλο catalogs και το λεξιλόγιο tags σε μία σελίδα πριν δημιουργήσει κανείς catalog. Αν είστε στη μέση της μετάπτωσης, τρέξτε την αξιολόγηση, καταγράψτε κάθε πίνακα που είναι ακόμη external ή ακόμη στο Hive metastore και δώστε σε καθέναν ιδιοκτήτη και ημερομηνία.

Για την ευρύτερη εικόνα, ξεκινήστε από το σε τι χρησιμοποιείται το Databricks και δείτε την τιμολόγηση του Databricks πριν διαστασιολογήσετε serverless compute για το ABAC. Αν ζυγίζετε πλατφόρμες, η σύγκρισή μου Snowflake vs Databricks καλύπτει τη διακυβέρνηση και στις δύο πλευρές. Βοηθώ οργανισμούς στη μεταποίηση και την άμυνα να παίρνουν αυτές τις αποφάσεις σχεδιασμού. Αν μια δεύτερη γνώμη θα βοηθούσε, κλείστε μια κλήση.

Τι είναι το Unity Catalog στο Databricks;

Το Unity Catalog είναι το επίπεδο διακυβέρνησης του Databricks. Προσφέρει ένα σημείο για τη διαχείριση της πρόσβασης σε πίνακες, views, file volumes, functions και μοντέλα AI, καταγράφει αυτόματα το lineage και κρατά αρχείο πρόσβασης στα audit system tables. Τα assets ονομάζονται ως catalog.schema.object κάτω από ένα μοναδικό metastore ανά περιοχή.

Είναι το ABAC στο Databricks γενικά διαθέσιμο;

Ναι. Οι πολιτικές attribute-based access control για row filters και column masks έγιναν γενικά διαθέσιμες στις 28 Απριλίου 2026, με τα governed tags και την ταξινόμηση δεδομένων επίσης GA τον Απρίλιο του 2026. Οι πολιτικές DENY, οι πολιτικές σε επίπεδο metastore και οι custom classifiers ήταν ακόμη σε Beta τον Οκτώβριο του 2026.

Είναι το Delta Sharing το ίδιο με το OpenSharing;

Ναι. Η Databricks ανακοίνωσε το OpenSharing τον Ιούνιο του 2026 ως την επόμενη εξέλιξη του πρωτοκόλλου Delta Sharing, που φιλοξενείται πλέον από το Linux Foundation και επεκτείνεται σε assets AI και clients Iceberg. Η τεκμηρίωση της Databricks περιγράφει πλέον το sharing με το όνομα OpenSharing.

Να χρησιμοποιήσω managed ή external πίνακες στο Unity Catalog;

Managed πίνακες για όλα τα νέα δεδομένα. Η Databricks τους προτείνει γιατί τότε το Unity Catalog διαχειρίζεται τα αρχεία, τη συντήρηση και τις δυνατότητες απόδοσης. Κρατήστε external πίνακες μόνο όπου ένα άλλο σύστημα πρέπει να κατέχει τα αρχεία ή κατά την αναβάθμιση από Hive metastore, και σχεδιάστε τη μετατροπή τους.

Πώς μεταφέρομαι από το Hive metastore στο Unity Catalog;

Η Databricks προτείνει πρώτα federation του Hive metastore ως foreign catalog και μετά αναβάθμιση των πινάκων επί τόπου χωρίς μετακίνηση δεδομένων. Για μεγάλα περιβάλλοντα, τα εργαλεία UCX του Databricks Labs αξιολογούν την ετοιμότητα και μεταφέρουν ομάδες, δικαιώματα και πίνακες, αλλά το UCX το συντηρεί η κοινότητα και δεν υποστηρίζεται επίσημα.

Πρέπει τα catalogs να οργανώνονται ανά περιβάλλον ή ανά επιχειρηματικό τομέα;

Για τους περισσότερους οργανισμούς, και τα δύο: ένα catalog ανά τομέα ανά περιβάλλον, όπως prod_finance και dev_finance. Δίνει σε κάθε ομάδα τομέα σαφή ιδιοκτησία και καθαρό εύρος audit. Μικρότερες ομάδες μπορούν να ξεκινήσουν με ένα catalog ανά περιβάλλον και schemas ανά τομέα.