Analiz panosu Salı günü doğruydu. Perşembe günü ise müşteri ediniminde %23'lük bir düşüş gösterdi; iş ekibi bunu gerçek bir iş sinyali olarak değerlendirdi, pazarlama bütçelerini yeniden düzenledi, kampanyaları durdurdu ve durumu yönetim kuruluna iletti. Veri mühendisliği ekibi Cuma günü, yukarı akış hizmetinin boş bırakılabilir bir sütun eklediğini keşfetti. registrations Tablo altı gün önce güncellenmemişti. Edinim ölçütünü hesaplayan işlem, yeni boş değerleri hariç tutmak yerine sıfır olarak ele alıyordu. Şema değişikliği bildirimi gönderilmemişti. Hata oluşturacak şekilde hiçbir sözleşme ihlal edilmemişti. İşlem hattı başarıyla çalıştı; doğru görünen ancak yanlış olan rakamlar üretti.
Şema kayması, değerlerin yanlış olduğu veri kalitesi sorunlarından farklı olarak, kaynak ve hedef arasındaki sözleşmeyi bozan yapısal bir mutasyonu temsil eder. Tüm DDL'leri kontrol eden merkezi bir DBA'nın bulunduğu monolitik bir veritabanı ortamında, bu sözleşme tek bir otorite tarafından uygulanır. Düzinelerce bağımsız hizmetin her birinin kendi veri deposuna sahip olduğu, olay akışlarının bağımsız olarak gelişen Avro şemalarını taşıdığı, ana bilgisayar toplu işleri ile bulut analitik platformları arasındaki düz dosya arayüzlerinin, her iki sistemin dokümantasyonunda da bulunmayan örtük sözleşmeler tanımladığı dağıtılmış bir sistemde, sözleşme sistemdeki her sınır boyunca dağıtılır. Dağıtılmış bir ortamda şema kayması, bir DBA'nın hata yapmasını beklemez. Verilerinin her bir alt akış tüketicisine tam olarak görünürlük olmadan, bireysel olarak mantıklı kararlar veren özerk ekiplerin normal çalışmasından ortaya çıkar.
Eski Şema Sınırını Haritala
SMART TS XL Ana bilgisayar programlarını modern analitik platformlara bağlayan her düz dosya formatındaki sözleşmeyi tanımlar.
DAHA FAZLASINI ÖĞRENİN…Şema Kayması Nedir ve Ne Değildir?
Şema kayması, bir veri yapısının yapısında, bu yapıyı kullanan sunucularda yansımayan bir değişikliktir. Tüketicilere yapılan vurgu, kaymayı planlı geçişten ayıran şeydir: Kaynak tabloda ve her tüketici sorguda eş zamanlı olarak yürütülen bir sütun yeniden adlandırma işlemi şema geçişidir. Aynı yeniden adlandırma işleminin yalnızca kaynak tabloda yürütülmesi ve tüketicilerin eski sütun adlarını okumasına neden olması ise şema kaymasıdır.
Veri işlem hatları, kaynak sistem ile hedef veri ambarı arasında bir güven sözleşmesine dayanır. Bu sözleşme şemadır: veri kümesini tanımlayan, üzerinde anlaşılmış yapı, veri tipleri ve sütun adları. Yukarı akış ekipleri, veri ekibini bilgilendirmeden uygulama veritabanlarını değiştirdiklerinde bu sözleşmeyi bozarlar.
Şema kayması, veri kaymasıyla aynı şey değildir. Veri kayması, kararlı bir şema içindeki değerlerin istatistiksel dağılımındaki bir değişikliktir; ortalama sıralama değerlerinin düşmesi, boş değer oranlarının artması, kategorik dağılımların kayması gibi durumlar söz konusudur. Her ikisi de önemli veri kalitesi sinyalleridir, ancak farklı tespit yaklaşımları gerektirir ve farklı temel nedenleri gösterirler. Sütun adlarını ve türlerini izleyen bir şema değişikliği tespit sistemi veri kaymasını yakalayamaz; bir dağıtım izleme sistemi sütun eklemelerini ve kaldırmalarını yakalayamaz.
Şema kayması her zaman zararlı değildir. Zaman içinde kayma şiddetini izlemek, aktif geliştirme döngüleri (zararsız kayma) ile istikrarsızlık (kritik kayma) arasında ayrım yapmaya yardımcı olur. Bir tabloya geriye dönük uyumlu, boş değer alabilen bir sütun eklenmesi şema kaymasıdır; şema değişmiştir, ancak yeni sütunu yok sayan herhangi bir tüketiciyi bozmayabilir. Kaymanın zararsız veya kritik olarak sınıflandırılması, aşağı akış tüketicilerini ve değişikliği nasıl ele aldıklarını anlamayı gerektirir.
Şema Kaymasının Dört Türü
Dağıtılmış veri sistemleri, her biri farklı tespit mekanizmaları gerektiren dört farklı boyutta şema kayması üretir:
Tip 1: Yapısal kayma
Fiziksel şema tanımındaki değişiklikler: sütun eklemeleri, sütun kaldırmaları, sütun yeniden adlandırmaları, veri türü değişiklikleri, kısıtlama eklemeleri veya kaldırmaları, tablo eklemeleri ve kaldırmaları. Bu, şema kaymasının en görünür biçimidir ve gözlemlenebilirlik araçları tarafından en sık ele alınanıdır. Veritabanı INFORMATION_SCHEMA sorguları, şema kayıt defteri karşılaştırmaları ve geçiş aracı denetim günlükleri, bağlı sistemler için yapısal kaymayı etkili bir şekilde yakalar.
Tespit: Şema anlık görüntüsünün temel çizgiyle karşılaştırılması; INFORMATION_SCHEMA sorgulaması; şema kayıt defteri sürüm karşılaştırması.
Tip 2: Anlamsal kayma
Mevcut bir alanın tanımında değişiklik yapılmadan anlamında yapılan değişiklikler. Örneğin, bir sütun adı verilmiş olabilir.
statusdaha önce değerler içerenACTIVE,INACTIVE,PENDINGartık değerler içeriyor1,2,3Çünkü üreten servis numaralandırmasını değiştirdi. Şema, sütun adı, veri türü, boş değer kısıtlaması değişmedi. Anlamsal sözleşme bozuldu. Dize durum değerlerini ayrıştıran tüketiciler artık mantıklarının işleyemediği tamsayılar alıyor.Anlamsal kayma ve bağlamsal kayma, tartışmaya daha yeni katılan ve yapay zeka programı başarısızlıklarının giderek artan bir kısmından sorumlu olmalarına rağmen, çok daha az izlenen kavramlardır. Anlamsal kaymayı otomatik olarak yakalamak en zordur çünkü yapısal bir sinyal üretmez; ya değer dağılımı izleme (bilinen değerlerin bilinmeyen değerlere oranı değişir) ya da açık sözleşme testi gerektirir.
Tespit: Değer dağılımı izleme; izin verilen değerlerin doğrulama kuralları; belirli geçerli değerleri doğrulayan sözleşme testleri.
Tip 3: Biçim kayması
Yapısal olarak değişmemiş alanlardaki değerlerin kodlamasında veya biçiminde değişiklikler. Daha önce UTC ISO 8601 dizeleri içeren bir zaman damgası alanı artık Unix epoch tamsayıları içeriyor. Daha önce ondalık miktarlar içeren bir para birimi alanı artık sent cinsinden tamsayı miktarlar içeriyor. Sütun mevcut, tür yeni değerler için hala geçerli, ancak ayrıştırma kuralı değişti.
Biçim kayması, özellikle dağıtık sistemlerin sınırlarında, bir servisin verileri başka bir servisin çözdüğü bir biçimde serileştirdiği durumlarda ve eski sistemlerden modern sistemlere geçişte, COBOL programlarının aşağı akış ETL süreçlerinin bağlı olduğu belirli bayt konum kurallarına sahip düz dosyalar yazdığı durumlarda yaygındır.
Tespit: Değer aralıklarının ve kalıplarının istatistiksel profillemesi; belirli alanlardaki biçim doğrulama kuralları; sınır sözleşme testleri.
Tip 4: Sözleşme sapması
Bir veri kaynağının kullanılabilirlik, güncellik veya hacim garantilerinde değişiklikler. Kaynak sistem daha önce günlük olarak UTC saatiyle sabah 3'te veri seti teslim ediyordu; şimdi ise sabah 6'da teslim ediyor ve bu durum, sabah 3'te güncellik varsayımına dayanan sonraki süreçleri sessizce bozuyor. Kaynak sistem daha önce günde en az 1,000 kayıt garantisi veriyordu; düşük trafik dönemlerinde artık daha az kayıt üretiliyor. Bu değişikliklerin hiçbiri yapısal anlamda bir şema değişikliği değil, ancak her ikisi de üretici ve tüketici arasındaki sözleşmeyi bozuyor.
Tespit: Tazelik takibi; hacim anormalliği tespiti; SLA tabanlı uyarı sistemi.
Dağıtılmış Sistemler Sorunu Neden Büyütüyor?
Tek bir veritabanı ve tek bir uygulama ekibine sahip monolitik bir sistemde, şema değişiklikleri kontrollü olaylardır. Veritabanı yöneticisi geçiş dosyasını yazar, geliştirici sorguları günceller ve değişiklik birlikte dağıtılır. Şema kayması riski mevcuttur ancak tek yetkilinin yetki alanı ile sınırlıdır.
Dağıtılmış sistemler bu tek otoriteyi ortadan kaldırır. Her hizmet kendi verilerine sahiptir. Her ekip şema kararlarını bağımsız olarak alır. Her hizmetin verilerinin tüketicileri, özellikle tüketici bir veri platformu, bir analiz hattı veya hiçbir ürün ekibinin aktif olarak bakımını yapmadığı eski bir entegrasyon noktası olduğunda, genellikle o ekibin doğrudan farkındalığının dışındadır.
Distributed Schema Drift Propagation Path:
Order Service Kafka Topic Analytics Pipeline
┌─────────────────┐ ┌───────────────┐ ┌──────────────────────┐
│ orders table │──>│ order.created │───>│ orders_fact table │
│ + coupon_id │ │ Avro schema │ │ (missing coupon_id) │
│ (new column) │ │ v1 still used │ │ pipeline runs fine │
│ │ │ │ │ coupon data silently │
│ │ │ │ │ dropped │
└─────────────────┘ └───────────────┘ └──────────────────────┘
▼
BI Dashboard
┌──────────────────┐
│ coupon_revenue │
│ always = $0 │
│ (no error shown) │
└──────────────────┘Şema, yayılma modelini göstermektedir: Sipariş Hizmetleri ekibi ekler coupon_id Veritabanlarına. Ayrıca Kafka olay şemasını da güncelleyerek bunu da dahil ederlerse. coupon_idAnaliz hattının bunu tüketebilmesi için güncellenmesi gerekir. Kafka şeması hala 1. sürümdeyse, alan hiçbir zaman işleme hattına ulaşmaz. İşleme hattı güncellenir ancak BI gösterge paneli modeli yenilenmezse, alan veri ambarında bulunur ancak raporda yer almaz. Bu sapma, dört sınır noktasından herhangi birinde sessiz bir veri kaybına neden olabilir ve her sınır noktası farklı bir algılama mekanizması gerektirir.
Sessiz veri işleme hattı hataları, güncelliğini yitirmiş gösterge panelleri, şema kaymaları ve eksik veri kümeleri, modern kurumsal veri ortamlarında önemli operasyonel riskler haline gelmiştir. Modern veri yığınları, geleneksel ortamlara göre daha hızlı arıza verir; bozuk dönüşümler, güncellik hataları ve sessiz veri bozulmaları, ekipler sorunları manuel olarak tespit etmeden çok önce veri işleme hatları boyunca yayılır.
Dağıtılmış şema kaymasını maliyetli kılan şey "sessiz" özelliğidir. İstisna üreten bir hata fark edilir ve düzeltilir. Sessizce yanlış sayılar üreten bir değişiklik, bu sayılara dayalı bir iş kararı görünür bir sonuç doğurana kadar fark edilmeden devam eder.
Katmana Göre Algılama Yaklaşımları
Şema kayması tespiti, dağıtık bir sistemin her katmanı için farklı araçlar ve teknikler gerektirir:
Veritabanı ve Veri Ambarı Katmanı
En gelişmiş tespit katmanı. Her büyük veritabanı ve veri ambarındaki INFORMATION_SCHEMA tabloları, sorgulanabilir bir meta veri anlık görüntüsü sağlar:
sql
-- Detect structural schema changes since a baseline snapshot
-- Run daily; alert when new differences appear
WITH current_schema AS (
SELECT
table_name,
column_name,
data_type,
is_nullable,
column_default,
ordinal_position
FROM information_schema.columns
WHERE table_schema = 'production'
),
baseline AS (
-- Previous snapshot stored in schema_baseline table
SELECT * FROM schema_monitoring.schema_baseline
WHERE snapshot_date = CURRENT_DATE - 1
)
SELECT
'ADDED' AS change_type,
c.table_name,
c.column_name,
c.data_type,
CURRENT_DATE AS detected_date
FROM current_schema c
LEFT JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE b.column_name IS NULL
UNION ALL
SELECT
'REMOVED' AS change_type,
b.table_name,
b.column_name,
b.data_type,
CURRENT_DATE
FROM baseline b
LEFT JOIN current_schema c
ON b.table_name = c.table_name
AND b.column_name = c.column_name
WHERE c.column_name IS NULL
UNION ALL
SELECT
'TYPE_CHANGED' AS change_type,
c.table_name,
c.column_name,
c.data_type || ' (was: ' || b.data_type || ')' AS data_type,
CURRENT_DATE
FROM current_schema c
JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE c.data_type <> b.data_type;Bu modeli otomatikleştiren araçlar: dbt şema testleri, Great Expectations sütun beklentileri, Monte Carlo tablo sağlığı izleme, Acceldata şema kayması izleme.
Olay Akışı Katmanı
Kafka konuları, Avro, Protobuf ve JSON şemalarının evrimini yönetmek için şema kayıt defterlerini (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) kullanır. Kayıt defteri, yayınlama zamanında uyumluluk kurallarını uygular:
tatlım
# Confluent Schema Registry: compatibility rule configuration
# Applied per topic; enforces at producer registration time
compatibility:
BACKWARD:
# New schema can read data written with old schema
# Safe: consumers can be updated after producers
allows: add_optional_fields, remove_fields_with_defaults
blocks: rename_fields, change_types, add_required_fields
FORWARD:
# Old schema can read data written with new schema
# Safe: consumers can be deployed before producers
allows: add_required_fields, rename_with_aliases
blocks: remove_fields_used_by_consumers
FULL:
# Both backward and forward compatible
# Strictest: ensures zero-downtime evolution
allows: add_optional_fields_with_defaults
blocks: everything_elseŞema kaydı, anlamsal kaymayı önlemez; adı ve türü değişmemiş ancak anlamı değişmiş bir alan, uyumluluk kontrollerinden geçer. Anlamsal doğrulama için sözleşme testi (Pact, AsyncAPI testi) gereklidir.
API Katmanı
API şema kaymasını yakalamanın temelde dört farklı yaklaşımı vardır: Spesifikasyondan spesifikasyona fark alma, spesifikasyondan gerçekliğe izleme, gerçeklikten gerçekliğe izleme ve trafiğe dayalı tespit. Bu alandaki karışıklığın çoğu, insanların farklı yaklaşımlardaki araçları karşılaştırmasından kaynaklanmaktadır.
Mikroservis mimarisindeki dahili servis API'leri için, tüketici odaklı sözleşme testi (Pact) en güvenilir yaklaşımdır: her tüketici, üreticiden ihtiyaç duyduğu sözleşmeyi belirtir, sözleşmeler CI'da üreticinin uygulamasına karşı doğrulanır ve bir tüketicinin sözleşmesini bozan herhangi bir değişiklik, dağıtımdan önce üreticinin test paketinde başarısız sayılır.
Eski Sistem Sınırı: Sapmanın Görünmez Hale Geldiği Nokta
Yukarıda açıklanan her tespit yaklaşımı, sorgulanabilir arayüzler aracılığıyla şema meta verilerini sunan sistemler için geçerlidir: INFORMATION_SCHEMA, şema kayıtları, OpenAPI spesifikasyonları. Eski ana bilgisayar sistemleri ile modern veri platformları arasındaki sınırda ise bu arayüzler mevcut değildir.
Bulut ETL işlem hattı tarafından kullanılmak üzere gecelik düz bir dosya üreten bir COBOL programı, FD girişinde ve çıktı mantığında örtük bir şema tanımlar. Düz dosyanın "şeması", bayt konumları, veri tipleri, COMP-3 paketlenmiş ondalık alanlar ve REDEFINES yapıları, modern gözlem araçlarının sorgulayabileceği herhangi bir kayıt defterinde veya meta veri deposunda değil, COBOL kaynak kodunda bulunur.
COBOL
*> This FD entry IS the schema contract for the nightly extract
*> Any change here constitutes schema drift for the downstream ETL
FD CUSTOMER-EXTRACT-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 350 CHARACTERS.
01 CUSTOMER-EXTRACT-REC.
05 CUST-ID PIC 9(10). *> Bytes 1-10
05 CUST-NAME PIC X(40). *> Bytes 11-50
05 CUST-BALANCE PIC S9(11)V99 COMP-3. *> Bytes 51-57 (packed)
05 CUST-STATUS-CD PIC X(2). *> Bytes 58-59
05 CUST-OPEN-DATE PIC 9(8). *> Bytes 60-67: YYYYMMDD
05 FILLER PIC X(283). *> Bytes 68-350
COBOL ekibi değişirse CUST-BALANCE itibaren PIC S9(11)V99 COMP-3 için PIC S9(13)V99 COMP-3Daha büyük bakiye değerlerini işlemek için iki basamak hassasiyet eklenerek, alan paketlenmiş ondalık biçimde 7 bayttan 8 bayta genişler. 50. bayttan sonraki her alan bir pozisyon kayar. ETL işlem hattının okuduğu düz dosyada artık CUST-BALANCE'tan sonraki tüm alanlar yanlış bayt pozisyonlarındadır. ETL işlem hattı bir hata üretmez; 51-57. baytları CUST-BALANCE olarak okur ve bir sonraki baytı (ki bu artık CUST-BALANCE'ın genişletilmiş gösteriminin ilk baytıdır) CUST-STATUS-CD'nin bir parçası olarak yorumlar. İşlem hattı çalışır. Sayılar yanlıştır. Şema kayması uyarısı tetiklenmez.
Bu, kurumsal ortamlarda şema kaymasının en tehlikeli türüdür: eski sistemlerdeki yapısal değişiklikler, her iki uçta da herhangi bir tespit mekanizması olmadan, düz dosya arayüzleri aracılığıyla sessizce yayılır.
Üç özellik, eski sınır kaymasını benzersiz derecede tehlikeli hale getiriyor:
Şema, gözlemlenebilirlik araçları için görünmezdir. Monte Carlo, VSAM dosyasına bağlanamaz. Acceldata, FD girdisini sorgulayamaz. Değişikliği tespit etmenin tek yolu, COBOL kaynak kodunu önceki bir sürümle karşılaştırmaktır; bu bir kod analizi işlemidir, veri izleme işlemi değildir.
Yayılım sessizdir. Düz dosya arayüzleri kayıt yapısını doğrulamaz; baytları okurlar. Bayt düzenindeki bir değişiklik, hatalara değil, yanlış değerlere yol açar.
Etki alanı geniştir. 300 program tarafından dahil edilen bir COBOL copybook'u, 300 program tarafından paylaşılan bir şemadır. Copybook'ta yapılan bir değişiklik, DDL ALTER TABLE komutuna eşdeğerdir ve 300 programın tamamını aynı anda etkiler; bu 300 programın herhangi biri tarafından üretilen herhangi bir veri setinin her bir alt bileşeni de bu sapmayı miras alır.
Şema Sözleşmeleri: Genellikle Örtük Olanı Biçimlendirmek
Şema kaymasına yönelik yapısal çözüm, örtük sözleşmeleri açık hale getirmek, şemanın ne olduğunu, kimin ona bağlı olduğunu ve hangi değişikliklere izin verildiğini, bir değişiklik yapıldıktan sonra değil, yapılmadan önce tanımlamaktır.
| Sözleşme Katmanı | Neyi Yönetiyor? | Montaj Ekipmanı | Eski Eşdeğer |
|---|---|---|---|
| Veritabanı DDL | Tablo yapısı, sütun tipleri, kısıtlamalar | Liquibase, Flyway, Atlas | DB2 DDL geçiş komut dosyaları |
| Olay şeması | Kafka/olay akışı yapısı | Confluent Şema Kayıt Sistemi, Apicurio | Yok (düz dosyanın kayıt defteri yok) |
| API sözleşmesi | REST/gRPC arayüzü beklentileri | OpenAPI, Pact, AsyncAPI | Yok (dosya arayüzünün özellikleri belirtilmemiş) |
| Veri kalitesi | Değer dağılımları, tazelik, hacim | Büyük Beklentiler, dbt testleri | Yok (yerel test çerçevesi bulunmuyor) |
| Dosya formatı sözleşmesi | Düz dosya bayt düzeni, alan konumları | COBOL FD girişi (gerçeğin kaynağı) | Copybook sürüm kontrolü |
Eski sistem karşılığı sütunundaki "Copybook sürüm kontrolü" girişi, COBOL şema evrimini yönetmek için pratik bir mekanizmadır: copybook'u değişiklik onay süreci olan sürümlü bir yapıt olarak ele almak, hangi programların hangi copybook'u içerdiğinin kaydını tutmak ve herhangi bir copybook değişikliği onaylanmadan önce etki analizi yapılmasını gerektirmek.
Bir defter değişikliği onaylama iş akışı:
- Geliştirici bir değişiklik öneriyor.
CUSTMSTR.CPY - Etki analizi, aşağıdakileri içeren her programı belirler:
CUSTMSTR.CPY(statik analiz) - Bu programlar tarafından üretilen her düz metin dosyası, şema değişikliği olayı olarak tanımlanır.
- Bu düz metin dosyalarının her bir alt kullanıcısı bilgilendirilir.
- Yeni tasarıma karşı tüketici doğrulama testleri yürütülüyor.
- Değişiklik ancak tüm tüketicilerin uyumluluğu onaylaması durumunda onaylanır.
Bu iş akışı, yerel şema kaydı bulunmayan COBOL katmanına uygulanan şema kaydı uyumluluk uygulama modelini yansıtır.
Dağıtılmış Şema Kayması için İzleme Mimarisi
Eksiksiz bir şema kayması izleme mimarisi, tüm sistem katmanlarında dört kayma türünün tamamını kapsar:
Şema anlık görüntü veritabanı. Her tablonun INFORMATION_SCHEMA meta verilerinin, kayıtlı her olay şema sürümünün, her API spesifikasyon sürümünün ve (eski sistemler için) her copybook sürümünün günlük anlık görüntüsünü saklar. Anlık görüntü veritabanı, mevcut durumun karşılaştırıldığı temel referans noktasıdır.
Değişiklik algılama işlem hattı. Günlük karşılaştırma işleri, anlık görüntü veritabanına karşı çalıştırılarak, izlenen her katmanda eklemeleri, kaldırmaları, tür değişikliklerini ve kısıtlama değişikliklerini algılar. Yüksek önem dereceli değişiklikler, geriye dönük uyumluluğu olmayan tür değişiklikleri, sütun kaldırmaları, gerekli alan eklemeleri anında uyarı tetikler. Düşük önem dereceli değişiklikler, boş bırakılabilir sütun eklemeleri, indeks değişiklikleri ise tavsiye niteliğinde bildirimler oluşturur.
Tüketici Etki Kaydı. Her şema yapısını bilinen tüketicilerine eşleyen bir katalog: hangi işlem hatları hangi tablolardan okuyor, hangi servisler hangi Kafka konularını tüketiyor, hangi ETL işleri hangi düz dosyaları işliyor. Bir şema değişikliği tespit edildiğinde, tüketici etki kaydı etki alanını, kaç tüketicinin etkilendiğini ve hangilerinin en kritik olduğunu belirler.
Sözleşme test paketi. Üretici şemaları hakkındaki tüketici varsayımlarını doğrulayan otomatik testler. Veri üreten bir hizmete dokunan her dağıtımda çalıştırılır. Kayıtlı bir tüketicinin bağlı olduğu bir sözleşme ihlal edilirse dağıtım başarısız olur.
Eski sistem sınır izleme. Ana bilgisayar sistemleri için: sürüm kontrollü copybook karşılaştırması, JCL veri kümesi tanımı izleme ve üreten programın FD girişinde tanımlanan şemaya göre düz dosya biçimi doğrulama. Bu katman, veri izleme yerine kod analizi gerektirir ve aşağı akış tüketicileri için şema değişiklikleri oluşturan COBOL kaynak kodundaki değişiklikleri tespit eder.
Planlı izleme, birçok ekibin sandığından daha önemlidir. Acceldata'nın planlı sapma analizine ilişkin kılavuzu, haftalık veya iki haftalık periyotlarla istikrarlı bir temel çizgiye karşı otomatik karşılaştırmalar yapılmasını önermekte ve arızadan sonra rastgele kontroller beklemenin yetersiz olduğunu açıkça belirtmektedir. Özellikle eski sistem sınır izlemesi için, periyot COBOL dağıtım programıyla eşleşmelidir: üretim ortamına herhangi bir copybook sürümü yayınlandığında, bir sonraki planlı karşılaştırmayı beklemek yerine, şema etki analizi hemen başlatılmalıdır.
Ne kadar SMART TS XL Eski Sistemlerdeki Şema Kayması Sorununu Ele Alır
SMART TS XL Bu çözüm, eski sistem sınırındaki tespit açığını, yani modern gözlem araçlarının durduğu ve en tehlikeli şema kaymasının tespit edilemediği katmanı ele almaktadır.
Statik kod analizi özelliği, eski ortamdaki her şema yapısının yapılandırılmış bir temsilini oluşturmak için her COBOL FD girdisini, COPY üyesini ve SELECT yan tümcesini ayrıştırır. Bu analiz, dağıtımdan önce ve sonra olmak üzere kod tabanının iki sürümüne karşı çalıştırıldığında, farklılıklar eski şema değişiklik günlüğünü oluşturur: hangi copybook'lar değişti, hangi alan tanımları değişti, önceki ve sonraki düzenler nelerdi. Bu, COBOL katmanına uygulanan şema anlık görüntü karşılaştırmasıdır.
Uygulama bağımlılık eşlemesi, eski şemalar için tüketici etki kaydını sağlar: hangi programlar hangi copybook'u içerir, hangi programlar hangi düz dosya veri kümelerini üretir, hangi JCL işleri hangi programları çağırır. Şema değişiklik günlüğü değiştirilmiş bir copybook'u tanımladığında, bağımlılık haritası hemen tüketici listesini, copybook'u içeren her programı ve bu programların ürettiği her alt düzey düz dosyayı oluşturur. Bu, bir copybook değişikliğinin düşük riskli dahili bir değişiklik mi yoksa yüzlerce programı ve düzinelerce alt düzey tüketiciyi etkileyen yüksek riskli bir olay mı olduğunu belirleyen etki yarıçapı hesaplamasıdır.
Etki analizi özelliği, etki alanını yapılandırılmış bir iyileştirme kapsamına dönüştürür: bağımlılık haritası tarafından tanımlanan her tüketici için, yeni şemaya uyum sağlamak için hangi değişiklikler gereklidir ve bu değişiklikler hangi sırayla uygulanmalıdır? Eski sistemden modern sisteme geçiş yapan tüketiciler için, COBOL programları tarafından üretilen düz dosyaları okuyan ETL işlem hatları için, etki analizi, ETL işlem hattının sütun eşleme yapılandırmasının yansıtılması gereken belirli alan konum değişikliklerini ve veri türü değişikliklerini belirler.
Kurumsal arama özelliği, şema yapıtlarının keşfini sorgulanabilir hale getirir: belirli bir bayt konumundaki bir alanı okuyan her programı (düzen değişikliğinden etkilenecek tüketicileri belirleyerek), belirli bir alanı tanımlayan her copybook'u (sürümlendirilmesi ve değişiklik kontrolü yapılması gereken şema yapıtını belirleyerek), belirli bir veri kümesine çıktı üreten her programı (şema değişiklikleri tüketici bildirimlerini tetiklemesi gereken üreticileri belirleyerek) bulun. Bu arama özelliği, hem proaktif şema yönetimi iş akışını hem de sapma sonrası olay incelemesini destekler.
Yöneten kuruluşlar için miras modernizasyonu Ana bilgisayar verilerinin modern platformlara taşınmasını içeren programlar, SMART TS XLŞema analizi, geçiş araçlarının ihtiyaç duyduğu kaynak şema dokümantasyonunu, verilerin gerçekte ne olduğunu tanımlayan eksiksiz ve güncel FD giriş tanımlarını ve copybook yapılarını sağlar; bu yapı yalnızca orijinal geçiş spesifikasyonu yazıldığında ne olduğuyla sınırlı değildir.
Kimsenin yazmadığı sözleşme yine de bir sözleşmedir.
Dağıtılmış sistemlerde şema kayması yeni bir sorun değil. Bu, dağıtılmış mimarinin çözmeyi zorlaştırdığı eski bir sorundur; çünkü monolitik sistemlerde şema sözleşmelerini uygulayan otorite, yani merkezi veritabanı yöneticisi, tek uygulama ekibi, birleşik kod tabanı, düzinelerce bağımsız hizmete dağıtılmıştır ve her biri, alt kademedeki her bir tüketiciye ilişkin eksik görünürlükle bireysel olarak mantıklı kararlar almaktadır.
Çözüm, şema üzerindeki yetkiyi yeniden merkezileştirmek değil. Çözüm, örtük sözleşmeleri açık hale getirmek, mevcut durumu temel çizgiyle karşılaştırabilen sistemlere kaydetmek, değişikliklerin getirildiği sınırlarda uyumluluk kurallarını uygulamak ve değişikliklerin yayıldığı sınırlarda ihlalleri izlemektir. Modern sistemler için bunun araçları mevcut ve hızla gelişiyor. Modern platformlarla sınırda olan eski sistemler için ise araç açığı gerçek ve önemli sonuçlar doğuruyor; bulut ETL işlem hattı için şema sözleşmesi olan düz dosya formatı, onu tanımlayan COBOL kaynak kodu analiz edilip şema yapıtı olarak sürümlendirilmediği sürece, her modern gözlem aracı için görünmezdir.
Müşteri kazanımında %23'lük bir düşüş gösteren gösterge paneli, aldığı veriler konusunda yanılmamıştı. Yanılmanın sebebi, verilerin anlamını tanımlayan şemanın, hiçbir sözleşmenin kaydedilmediği ve hiçbir izleme mekanizmasının bulunmadığı bir sınırda değişmiş olmasıydı. Dağıtılmış bir sistemde, ister eski ister modern olsun, bu sınır, şema kayması tespit programlarının ulaşması gereken yerdir.
