SQL Server'da programlı ETL için standart bir dil / arayüz var mı?

Şu anda veri ambarımız için ETL oluşturma sürecindeyim. SSIS 2008 kullanıyoruz, ancak en önemlisi bileşenlerin yeniden kullanılmasındaki zorluk olan sorunlarla karşılaşıyoruz. Her tablo için ayrı paketlerimiz vardır ve her paket bir üst paketten bir dizi değişken girdi olarak alır. Bu giriş değişkenlerinde değişiklik yaptığımız için, her pakete girmemiz gerekiyor (şimdi 15 tane var, ancak bu sayı önemli ölçüde büyüyecek) ve bu değişikliklerle başa çıkmak için paketi değiştirmeliyiz. Ayrıca, ayıklama için rasgele SQL çalıştırılamaması, zayıf günlük yetenekleri vb.

Kodda ETL'leri geliştirmenin, kodun yeniden kullanılmasını, ortak kütüphanelerin, daha iyi birim testlerinin vb. Etkinleştirilmesini sağlayan bir yol olsaydı, tüm bu süreç çok daha sağlam olurdu . SQL Server için fiili standart ETL dili / API var mı? GUI araçlarından mümkün olduğunca kaçınmak istiyorum.

Düzenleme: Arka planımı belirtmeliyim. Ben bir DBA değilim ve resmi (veya gayri resmi) bir DBA eğitimim yok, temelde bu şeyleri devam ederken anladım, bu yüzden SSIS ile uygunsuz şeyler yapmaya veya bu ETL'ye yaklaşmaya çalıştığım her olasılık var projeyi yanlış açıdan. Ayrıca, şu anda eyalet hükümetinde çalışıyorum, bu nedenle yeni bir yazılım paketi satın almayı gerektiren çözümler olasılık alanı içinde değil.

İşte görevlerimizden biri. Depomuza her bir tablo yüklemek için tek bir SSIS Paketi kullanıyoruz. Her bir Fact paketi ve Dimension paketi genellikle aynıdır, sadece

• Kaynak veritabanından alıntılar
• Veri Akışındaki Manipülasyonlar
• Hedef tabloyla birleşir

Ne yapabilmek istiyorum (SSIS'de zor olduğunu düşünüyorum)

• Bir metin dosyasından çıkarma sorgusunu yükleyin. Geliştiriciler ayıklama sorgularını yazarken ve test ederken, SSIS çalıştırmadan önce sorgularını herhangi bir şekilde işlememeliyim ve sorguyu bir DB Source nesnesine yapıştırmam ve yapıştırmamalıyım.
• Her bileşeni ayrı ayrı test edin. Diğer tablo yüklerinden bağımsız olarak ayrı bir tablo için ETL sürecinin tamamını test edebilmeliyim.
• Paylaşılan mantıkta tek bir yerde değişiklik yapın, her bir paketi düzenlemek zorunda değilsiniz. Her paket verileri denetim tablolarına aynı şekilde yükler, denetlenen yüklenen verileri değiştirmek istersem, 15 paketin tümünü de düzenlemek istemiyorum (bu sayı zamanla çok daha büyük olacak).

Tüm süreç, paylaşılan kodun doğru kullanımı ile programlı olarak yapılırsa, uygulamanın çok daha kolay ve daha sağlam olacağını hisseder.

Bunu sağlayan bir araç var - http://www.varigence.com/products/biml.html

Ticari bir sürümü var, ancak BIDS Yardımcısı'nın bir kısmını da ücretsiz bir araç olan BIDS Yardımcısı'na ekliyoruz. http://bidshelper.codeplex.com/

Bu konuda aklınıza gelebilecek tüm soruları cevaplamaktan mutluluk duyarım.

Bu şirketimin sağladığı bir araçtır.

Bunu okuduktan hemen sonra Varigence'nin araçlarını tavsiye etmeyi düşündüm. Ancak, Varigence'deki baş mimarlardan biri olan John Welch'in benden önce buraya geldiğini görüyorum.

Varigence'in araçları SSIS'nin üzerinde bir soyutlama katmanıdır. Sağladığı avantaj, yeniden kullanılabilir "şeyleri" tanımlamak ve böylece birden fazla paket arasında tutarlılık sağlamaktır. Paketlerin nasıl yapılandırılması ve bireysel olarak nasıl farklılık göstereceğini tanımlarsınız - Varigence'ın araçlarından "derlenmiş" çıktılar SSIS paketleridir.

SSIS paketleri için Dinamik SQL olarak düşünün. Bir GUI ile. Gerçekten çok havalı.

SSIS'i birkaç kez denedim ve vazgeçtim. IMO sadece ihtiyacım olan tüm C # yapmak çok daha kolay. SSIS çok karmaşık, çok fazla gotchas var ve buna değmez. C # becerilerini geliştirmek için SSIS öğrenmeye aynı zamanı harcamaktan daha fazla zaman harcamak çok daha iyidir - eğitiminizden çok daha fazla getiri elde edersiniz. Burada fazla ayrıntıya girmeme gerek yok - Ayende, eklenecek hiçbir şeyim olmayan harika bir özet yazdı .

Ayrıca bir VS çözümünde işlevselliği bulmak ve sürdürmek çok daha kolaydır. VS ile birim testi yapmak kolaydır. Tek yapmam gereken Subversion'daki kaynağı kontrol etmek ve nasıl yüklendiğini doğrulamak. Birim testi SSIS paketlerini hafifçe koymak çok önemlidir.

Ayrıca, SSIS'in bazı satırlarda bazı sütunları sessizce dolduramadığı, sadece istisnaları yükseltmeden atladığı durumlar vardı. Sorun giderme ve neler olduğunu anlamaya çok zaman harcadık. C # 'da alternatif bir çözüm geliştirmek bir saatten az sürdü ve iki yıl boyunca sorunsuz çalışıyor.

Ayrıca Rhino ETL gerçekten harika görünüyor.

Stackoverflow ile ilgili birkaç benzer tartışma vardı .

Şahsen, SQL'de mümkün olduğunca ETL sürecini idare ediyorum. FTP siteleri veya Excel gibi garip veri kaynaklarından içe aktarmak için SSIS kullanıyorum, ancak bu SQL'in geri kalanını yaptığı veritabanına ham veri almak için.

Mevcut durumum, verilerin çoğunun bağlı sunucuları ayarlayabileceğim diğer MS SQL veritabanlarında olması nedeniyle nispeten basittir. Başka platformlara bağlanmak zorundaysanız, OPENQUERYve kullanmanızı öneririz BULK INSERT. Gerekirse programlı olarak yapılabilirler ve ikisi arasında çoğu veri türüne bağlanabilirler.

SQL kullanıyorum çünkü en iyi bildiğim şey bu ama bazı objektif avantajları var. En önemlisi, zaten kullanılıyor: yeni bir araç öğrenmeye veya ödemeye gerek yok. Bu, sizin için değilse patronunuz için önemli olan, yaygın olarak bulunan bir beceridir. Veritabanında çalıştığından günlüğe kaydetme kolaydır. Düz metin koduna dayanır, bu nedenle kolayca aranır ve kaynak kontrolü ile iyi çalışır. Satıcının işleri değiştirme ve geriye dönük uyumluluğu kırma şansı çok düşüktür. Muhtemelen en azından herhangi bir RBAR dili kadar hızlıdır.

Daha fazlasına ihtiyacınız varsa, yalnızca SSIS ve SQLCLR'de kullanıldığı için .NET'i öneririm. Genel ETL sürecini yönetmek için C # uygulamalarını kullanıyorum - alt adımları başlatmak, çıktılarını izlemek, e-posta göndermek. Ancak bunların neredeyse tamamı SQL Agent, dbmail vb. İle yapılabilir.

Eğer herhangi bir sebep var mı edemez senin ETL için SQL kullanın? Sizin için ne yapamadı?