Netezza geçişleri için veri geçişi, ETL ve yükleme
Bu makale, Netezza'dan Azure Synapse Analytics'e geçiş konusunda rehberlik sağlayan yedi bölümden oluşan serinin 2. bölümüdür. Bu makalenin odak noktası ETL ve yük geçişi için en iyi yöntemlerdir.
Veri geçişiyle ilgili dikkat edilmesi gerekenler
Netezza'dan veri geçişi için ilk kararlar
Netezza veri ambarlarını geçirirken veriyle ilgili bazı temel sorular sormanız gerekir. Örnek:
Kullanılmayan tablo yapıları geçirilmeli mi?
Riski ve kullanıcı etkisini en aza indirmek için en iyi geçiş yaklaşımı hangisidir?
Veri reyonlarını geçirirken: fiziksel olarak mı kalalım yoksa sanal mı kalalım?
Sonraki bölümlerde Netezza'dan geçiş bağlamında bu noktalar ele alınıyor.
Kullanılmayan tablolar geçirilir mi?
İpucu
Eski sistemlerde tabloların zaman içinde yedekli hale gelmesi olağan dışı değildir; çoğu durumda bunların geçirilmesi gerekmez.
Yalnızca mevcut sistemde kullanılmakta olan tabloları geçirmek mantıklıdır. Etkin olmayan tablolar geçirilmeyecek şekilde arşivlenebilir, böylece veriler gelecekte gerekirse kullanılabilir. Belgeler güncel olmadığından, hangi tabloların kullanımda olduğunu belirlemek için belgeler yerine sistem meta verilerini ve günlük dosyalarını kullanmak en iyisidir.
Etkinleştirilirse, Netezza sorgu geçmişi tabloları belirli bir tabloya en son ne zaman erişildiğini belirleyebilecek bilgiler içerir. Bu bilgiler de tablonun geçiş adayı olup olmadığına karar vermek için kullanılabilir.
Belirli bir zaman penceresinde belirli bir tablonun kullanımını arayan örnek bir sorgu aşağıda verilmiştir:
SELECT FORMAT_TABLE_ACCESS (usage),
hq.submittime
FROM "$v_hist_queries" hq
INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;
| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins | 2015-06-16 18:32:25.728042
ins | 2015-06-16 17:46:14.337105
ins | 2015-06-16 17:47:14.430995
(3 rows)
Bu sorgu, yüklü sorgu geçmişi sürümüyle eşleşmesi için yardımcı işlevini FORMAT_TABLE_ACCESS ve görünümün $v_hist_table_access_3 sonundaki rakamı kullanır.
Riski ve kullanıcılar üzerindeki etkiyi en aza indirmek için en iyi geçiş yaklaşımı hangisidir?
Şirketler çevikliği geliştirmek için değişikliklerin veri ambarı veri modeli üzerindeki etkisini düşürmek isteyebileceğinden bu soru sık sık ortaya çıkar. Şirketler genellikle ETL geçişi sırasında verilerini daha modernleştirme veya dönüştürme fırsatı görür. Bu yaklaşım aynı anda birden çok faktörü değiştirdiğinden daha yüksek bir risk taşır ve eski sistemin sonuçlarını yeniyle karşılaştırmayı zorlaştırır. Burada veri modeli değişiklikleri yapmak, diğer sistemlere yapılan yukarı veya aşağı akış ETL işlerini de etkileyebilir. Bu risk nedeniyle, veri ambarı geçişi sonrasında bu ölçekte yeniden tasarlama daha iyidir.
Bir veri modeli genel geçiş kapsamında kasıtlı olarak değiştiriliyor olsa bile, yeni platformda yeniden mühendislik yapmak yerine mevcut modeli olduğu gibi Azure Synapse geçirmek iyi bir uygulamadır. Bu yaklaşım mevcut üretim sistemleri üzerindeki etkisini en aza indirirken, azure platformunun tek seferlik yeniden mühendislik görevleri için performansından ve elastik ölçeklenebilirliğinden yararlanır.
Netezza'dan geçiş yaparken, genellikle mevcut veri modeli Azure Synapse geçiş için zaten uygundur.
İpucu
Gelecekte veri modelinde bir değişiklik planlansa bile mevcut modeli başlangıçta olduğu gibi geçirin.
Veri reyonlarını geçirme: fiziksel mi kalalım yoksa sanal mı kalalım?
İpucu
Veri reyonlarının sanallaştırılması, depolama ve işleme kaynaklarından tasarruf sağlayabilir.
Eski Netezza veri ambarı ortamlarında, kuruluş içindeki belirli bir departman veya iş işlevi için geçici self servis sorguları ve raporları için iyi performans sağlamak üzere yapılandırılmış çeşitli veri reyonları oluşturmak yaygın bir uygulamadır. Bu nedenle, bir veri reyonu genellikle veri ambarının bir alt kümesinden oluşur ve verilerin toplanmış sürümlerini kullanıcıların Microsoft Power BI, Tableau veya MicroStrategy gibi kullanıcı dostu sorgu araçları aracılığıyla hızlı yanıt süreleriyle kolayca sorgulamasını sağlayan bir biçimde içerir. Bu form genellikle boyutsal bir veri modelidir. Veri reyonlarının bir kullanımı, temel alınan ambar veri modeli veri kasası gibi farklı bir şey olsa bile verileri kullanılabilir bir biçimde kullanıma sunmadır.
Kullanıcıların yalnızca bunlarla ilgili belirli veri reyonlarına erişmesine izin vererek ve hassas verileri ortadan kaldırarak, karartarak veya anonimleştirerek, sağlam veri güvenliği rejimleri uygulamak için kuruluş içindeki tek tek iş birimleri için ayrı veri reyonları kullanabilirsiniz.
Bu veri reyonları fiziksel tablolar olarak uygulanırsa, bunları depolamak için ek depolama kaynaklarına ve bunları düzenli olarak oluşturup yenilemek için ek işlemeye ihtiyaç duyarlar. Ayrıca, marttaki veriler yalnızca son yenileme işlemi kadar güncel olacaktır ve bu nedenle son derece geçici veri panoları için uygun olmayabilir.
İpucu
Azure Synapse performansı ve ölçeklenebilirliği, performansdan ödün vermeden sanallaştırmayı etkinleştirir.
Azure Synapse gibi görece düşük maliyetli ölçeklenebilir MPP mimarilerinin ve bu mimarilerin doğal performans özelliklerinin ortaya çıkmasıyla, reyonu bir fiziksel tablo kümesi olarak örneklemek zorunda kalmadan veri reyonu işlevselliği sağlayabilirsiniz. Bu, veri reyonlarını SQL görünümleri aracılığıyla ana veri ambarında etkili bir şekilde sanallaştırarak veya Azure'daki görünümler veya Microsoft iş ortaklarının görselleştirme ürünleri gibi özellikleri kullanarak bir sanallaştırma katmanı aracılığıyla elde edilir. Bu yaklaşım ek depolama ve toplama işleme gereksinimini basitleştirir veya ortadan kaldırır ve geçirilecek veritabanı nesnelerinin toplam sayısını azaltır.
Bu yaklaşımın başka bir olası avantajı da vardır. Toplama ve birleştirme mantığını bir sanallaştırma katmanı içinde uygulayarak ve dış raporlama araçlarını sanallaştırılmış bir görünüm aracılığıyla sunarak, bu görünümleri oluşturmak için gereken işlem genellikle büyük veri hacimlerinde birleştirmelerin, toplamaların ve diğer ilgili işlemlerin çalıştırıldığı en iyi yer olan veri ambarı'na "gönderilir".
Fiziksel veri reyonu üzerinden sanal veri reyonu uygulaması seçmeye yönelik birincil sürücüler şunlardır:
Daha fazla çeviklik: Sanal veri reyonunun değiştirilmesi, fiziksel tablolara ve ilişkili ETL işlemlerine göre daha kolaydır.
Daha düşük toplam sahip olma maliyeti: Sanallaştırılmış bir uygulama daha az veri deposu ve veri kopyası gerektirir.
Sanallaştırılmış bir ortamda veri ambarı mimarisini geçirmek ve basitleştirmek için ETL işlerinin ortadan kaldırılması.
Performans: Fiziksel veri reyonları geçmişte daha iyi performans gösterse de sanallaştırma ürünleri artık azaltmaya yönelik akıllı önbelleğe alma teknikleri uyguluyor.
Netezza'dan veri geçişi
Verilerinizi anlama
Geçiş planlamasının bir bölümü, geçiş yaklaşımı hakkındaki kararları etkileyebileceğinden geçirilmesi gereken veri hacmini ayrıntılı olarak anlamaktır. Geçirilecek tablolardaki "ham veriler" tarafından kaplanan fiziksel alanı belirlemek için sistem meta verilerini kullanın. Bu bağlamda "ham veriler", dizinler ve sıkıştırma gibi ek yükleri hariç olmak üzere tablo içindeki veri satırları tarafından kullanılan alan miktarı anlamına gelir. Bu durum özellikle en büyük olgu tabloları için geçerlidir çünkü bunlar genellikle verilerin %95'inden fazlasını oluşturur.
Belirli bir tablo için geçirilecek veri hacmi için doğru bir sayı elde etmek için verilerin temsili bir örneğini (örneğin, bir milyon satır) sıkıştırılmamış sınırlandırılmış düz ASCII veri dosyasına ayıklayabilirsiniz. Ardından, bu tablonun satırı başına ortalama ham veri boyutunu almak için bu dosyanın boyutunu kullanın. Son olarak, tablonun ham veri boyutunu vermek için bu ortalama boyutu tam tablodaki toplam satır sayısıyla çarpın. Planlamanızda bu ham veri boyutunu kullanın.
Netezza veri türü eşleme
İpucu
Hazırlık aşamasının bir parçası olarak desteklenmeyen veri türlerinin etkisini değerlendirin.
Çoğu Netezza veri türünün Azure Synapse'de doğrudan eşdeğeri vardır. Aşağıdaki tabloda, bu veri türlerini eşlemek için önerilen yaklaşımla birlikte gösterilmektedir.
| Netezza veri türü | veri türünü Azure Synapse |
|---|---|
| BİGİNT | BİGİNT |
| BINARY VARYING(n) | VARBINARY(n) |
| BOOLEAN | BİT |
| BYTEINT | TİNYİNT |
| KARAKTER DEĞİşTİ(n) | VARCHAR(n) |
| KARAKTER(n) | CHAR(n) |
| DATE | TARİh(tarih) |
| ONDALıK(p,s) | ONDALıK(p,s) |
| ÇIFT DUYARLıK | FLOAT |
| FLOAT(n) | FLOAT(n) |
| TAMSAYI | INT |
| ARALIĞI | INTERVAL veri türleri şu anda Azure Synapse Analytics'te doğrudan desteklenmemektedir ancak DATEDIFF gibi geçici işlevler kullanılarak hesaplanabilir. |
| PARA | PARA |
| NİTELİ KARAKTER DEĞİşTİ(n) | NVARCHAR(n) |
| ULUSAL KARAKTER(n) | NCHAR(n) |
| SAYıSAL(p,s) | SAYıSAL(p,s) |
| GERÇEK SAYI | GERÇEK SAYI |
| SMALLİNT | SMALLİNT |
| ST_GEOMETRY(n) | ST_GEOMETRY gibi uzamsal veri türleri şu anda Azure Synapse Analytics'te desteklenmemektedir ancak veriler VARCHAR veya VARBINARY olarak depolanabilir. |
| TIME | TIME |
| SAAT DILIMI ILE SAAT | DATETİMEOFFSET |
| TIMESTAMP | DATETİME |
Bu veri türlerinden birinin geçirilmesi gerekip gerekmediğini belirlemek için Netezza katalog tablolarındaki meta verileri kullanın ve geçiş planınızda buna izin verin. Bu sorgu türü için Netezza'daki önemli meta veri görünümleri şunlardır:
_V_USER: kullanıcı görünümü Netezza sistemindeki kullanıcılar hakkında bilgi verir._V_TABLE: tablo görünümü, Netezza performans sisteminde oluşturulan tabloların listesini içerir._V_RELATION_COLUMN: ilişki sütunu sistem kataloğu görünümü, bir tabloda kullanılabilen sütunları içerir._V_OBJECTS: nesneler görünümü, Netezza'da bulunan tablolar, görünüm, işlevler vb. gibi farklı nesneleri listeler.
Örneğin, bu Netezza SQL sorgusu sütunları ve sütun türlerini gösterir:
SELECT
tablename,
attname AS COL_NAME,
b.FORMAT_TYPE AS COL_TYPE,
attnum AS COL_NUM
FROM _v_table a
JOIN _v_relation_column b
ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;
TABLENAME | COL_NAME | COL_TYPE | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST | COL_INT | INTEGER | 1
ATT_TEST | COL_NUMERIC | NUMERIC(10,2) | 2
ATT_TEST | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST | COL_DATE | DATE | 4
(4 rows)
Sorgu, desteklenmeyen veri türlerinin herhangi bir örneğini tüm tablolarda aramak için değiştirilebilir.
Azure Data Factory, verileri eski bir Netezza ortamından taşımak için kullanılabilir. Daha fazla bilgi için bkz . IBM Netezza bağlayıcısı.
Üçüncü taraf satıcılar , daha önce açıklandığı gibi veri türlerinin eşlemesi de dahil olmak üzere geçişi otomatikleştirmek için araçlar ve hizmetler sunar. Ayrıca, Informatica veya Talend gibi netezza ortamında zaten kullanılmakta olan üçüncü taraf ETL araçları tüm gerekli veri dönüşümlerini uygulayabilir. Sonraki bölümde, mevcut üçüncü taraf ETL işlemlerinin geçişi incelanmıştır.
ETL geçişiyle ilgili dikkat edilmesi gerekenler
Netezza ETL geçişiyle ilgili ilk kararlar
İpucu
ETL geçişi yaklaşımını önceden planlayın ve uygun durumlarda Azure olanaklarından yararlanın.
ETL/ELT işleme için, eski Netezza veri ambarları nzsql ve nzload gibi Netezza yardımcı programlarını veya Informatica veya Ab Initio gibi üçüncü taraf ETL araçlarını kullanan özel olarak oluşturulmuş betikler kullanabilir. Bazen Netezza veri ambarları zaman içinde gelişen ETL ve ELT yaklaşımlarının bir birleşimini kullanır. Azure Synapse geçişini planlarken, gerekli ETL/ELT işlemesini yeni ortamda uygulamanın en iyi yolunu belirlemeniz ve bu arada da ilgili maliyeti ve riski en aza indirmeniz gerekir. ETL ve ELT işleme hakkında daha fazla bilgi edinmek için bkz. ELT ve ETL tasarım yaklaşımı.
Aşağıdaki bölümlerde geçiş seçenekleri açıklanır ve çeşitli kullanım örnekleri için öneriler sağlanır. Bu akış çizelgesi bir yaklaşımı özetler:
İlk adım her zaman geçirilmesi gereken ETL/ELT işlemlerinin envanterini oluşturmaktır. Diğer adımlarda olduğu gibi, standart "yerleşik" Azure özelliklerinin bazı mevcut işlemleri geçirmeyi gereksiz hale getirmesi mümkündür. Planlama amacıyla gerçekleştirilecek geçişin ölçeğini anlamak önemlidir.
Yukarıdaki akış çizelgesinde, karar 1 tamamen Azure'a özel bir ortama geçirilip geçirilmeyeceğine ilişkin üst düzey bir kararla ilgilidir. Tamamen Azure'a özel bir ortama geçiyorsanız, Azure Data Factory veyaAzure Synapse İşlem Hatlarındaki İşlem Hatlarını ve etkinlikleri kullanarak ETL işlemeyi yeniden oluşturmanızı öneririz. Tamamen Azure'a özel bir ortama geçmiyorsanız 2. karar, mevcut bir üçüncü taraf ETL aracının zaten kullanımda olup olmadığıdır.
İpucu
Maliyeti ve riski azaltmak için mevcut üçüncü taraf araçlarına yatırımdan yararlanın.
Bir üçüncü taraf ETL aracı zaten kullanılıyorsa ve özellikle de becerilere büyük bir yatırım varsa veya mevcut iş akışları ve zamanlamalar bu aracı kullanıyorsa, 3. karar aracın hedef ortam olarak Azure Synapse verimli bir şekilde destekleyip desteklemeyebileceğidir. İdeal olan araç, en verimli veri yükleme için PolyBase veya COPY INTO gibi Azure olanaklarından yararlanabilen "yerel" bağlayıcılar içerecektir. PolyBase veya COPY INTOgibi bir dış işlemi çağırmanın ve uygun parametreleri geçirmenin bir yolu vardır. Bu durumda, yeni hedef ortam olarak Azure Synapse mevcut becerilerden ve iş akışlarından yararlanın.
Mevcut bir üçüncü taraf ETL aracını korumaya karar verirseniz, bu aracı Azure ortamında çalıştırmanın (mevcut bir şirket içi ETL sunucusunda değil) ve mevcut iş akışlarının genel düzenlemesini Azure Data Factory sağlamanın avantajları olabilir. Azure'dan daha az veri indirilmesi, işlenmesi ve ardından Azure'a geri yüklenmesi gerekir. Bu nedenle 4. karar, mevcut aracı olduğu gibi çalışır durumda bırakmak mı yoksa maliyet, performans ve ölçeklenebilirlik avantajları elde etmek için Azure ortamına mı taşıyacağınızdır.
Mevcut Netezza'ya özgü betikleri yeniden mühendislikle kullanma
Mevcut Netezza ambarı ETL/ELT işlemesinin bir kısmı veya tamamı nzsql veya nzload gibi Netezza'ya özgü yardımcı programları kullanan özel betikler tarafından işleniyorsa, bu betiklerin yeni Azure Synapse ortamı için yeniden kodlanması gerekir. Benzer şekilde, ETL işlemleri Netezza'da saklı yordamlar kullanılarak uygulandıysa, bunların da yeniden kodlanması gerekir.
İpucu
Geçirilecek ETL görevlerinin envanteri betikleri ve saklı yordamları içermelidir.
ETL işleminin bazı öğelerinin geçirilmesi kolaydır; örneğin, dış dosyadan hazırlama tablosuna basit toplu veri yükü. Örneğin, nzload yerine PolyBase kullanarak işlemin bu bölümlerini otomatikleştirmek bile mümkün olabilir. İşlemin rastgele karmaşık SQL ve/veya saklı yordamlar içeren diğer bölümlerinin yeniden mühendislik işlemi daha uzun sürer.
Netezza SQL'i Azure Synapse uyumluluk açısından test etmenin bir yolu, Netezza sorgu geçmişinden bazı temsili SQL deyimlerini yakalamak, ardından bu sorguların ön ekini ile EXPLAINönek olarak eklemek ve ardından Azure Synapse'da benzer bir geçirilen veri modeli varsayılarak bu EXPLAIN deyimleri Azure Synapse çalıştırmaktır. Uyumsuz SQL'ler bir hata oluşturur ve hata bilgileri kodlama görevinin ölçeğini belirleyebilir.
Microsoft iş ortakları, Netezza SQL ve saklı yordamları Azure Synapse geçirmek için araçlar ve hizmetler sunar.
Üçüncü taraf ETL araçlarını kullanma
Önceki bölümde açıklandığı gibi, çoğu durumda mevcut eski veri ambarı sistemi zaten üçüncü taraf ETL ürünleri tarafından doldurulacak ve korunacaktır. Azure Synapse için Microsoft veri tümleştirme iş ortaklarının listesi için bkz. Veri tümleştirme iş ortakları.
Netezza'dan veri yükleme
Netezza'dan veri yüklerken kullanılabilen seçenekler
İpucu
Üçüncü taraf araçlar geçiş sürecini basitleştirip otomatikleştirebilir ve dolayısıyla riski azaltabilir.
Netezza veri ambarından veri geçişi söz konusu olduğunda, veri yüklemeyle ilgili çözülmesi gereken bazı temel sorular vardır. Verilerin mevcut şirket içi Netezza ortamından buluttaki Azure Synapse fiziksel olarak nasıl taşınacağını ve aktarımı ve yüklemeyi gerçekleştirmek için hangi araçların kullanılacağına karar vermeniz gerekir. Sonraki bölümlerde ele alınan aşağıdaki soruları göz önünde bulundurun.
Verileri dosyalara mı ayıklayacağız yoksa doğrudan bir ağ bağlantısı üzerinden mi taşıyacaksınız?
İşlemi kaynak sistemden mi yoksa Azure hedef ortamından mı düzenlersiniz?
Süreci otomatikleştirmek ve yönetmek için hangi araçları kullanacaksınız?
Dosyalar veya ağ bağlantısı aracılığıyla veri aktarılasın mı?
İpucu
Bu faktörler geçiş yaklaşımı kararını etkilediğinden geçirilecek veri hacimlerini ve kullanılabilir ağ bant genişliğini anlayın.
Geçirilecek veritabanı tabloları Azure Synapse oluşturulduktan sonra, bu tabloları eski Netezza sisteminden ve yeni ortama doldurmak için verileri taşıyabilirsiniz. İki temel yaklaşım vardır:
Dosya ayıklama: Netezza tablolarındaki verileri düz dosyalara, normalde CSV biçiminde, nzsql aracılığıyla -o seçeneğiyle veya deyimiyle
CREATE EXTERNAL TABLEayıklayın. Veri aktarım hızı açısından en verimli olduğu için mümkün olduğunca dış tablo kullanın. Aşağıdaki SQL örneği, dış tablo aracılığıyla bir CSV dosyası oluşturur:CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',') AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;Verileri yerel bir Netezza konağındaki bağlı bir dosya sistemine aktarıyorsanız dış tablo kullanın. JDBC, ODBC veya OLEDB yüklü bir uzak makineye veri aktarıyorsanız, "remotesource odbc" seçeneğiniz yan tümcedir
USING.Bu yaklaşım, ayıklanan veri dosyalarını almak için alan gerektirir. Alan, Netezza kaynak veritabanında yerel (yeterli depolama alanı varsa) veya Azure Blob Depolama uzak olabilir. En iyi performans, bir dosya yerel olarak yazıldığında elde edilir, çünkü bu ağ yükünü önler.
Depolama ve ağ aktarım gereksinimlerini en aza indirmek için gzip gibi bir yardımcı program kullanarak ayıklanan veri dosyalarını sıkıştırmak iyi bir uygulamadır.
Ayıklandıktan sonra düz dosyalar Azure Blob Depolama taşınabilir (hedef Azure Synapse örneğiyle birlikte bulunabilir) veya PolyBase veya COPY INTO kullanılarak doğrudan Azure Synapse yüklenebilir. Verileri yerel şirket içi depolama alanından Azure bulut ortamına fiziksel olarak taşıma yöntemi, veri miktarına ve kullanılabilir ağ bant genişliğine bağlıdır.
Microsoft, büyük hacimli verileri ağ üzerinden Azure Depolama'ya taşımak için AzCopy, özel ağ bağlantısı üzerinden toplu verileri taşımak için Azure ExpressRoute ve daha sonra yüklenmek üzere bir Azure veri merkezine gönderilen fiziksel bir depolama cihazına taşınan dosyalar için Azure Data Box gibi çeşitli seçenekler sunar. Daha fazla bilgi için bkz. veri aktarımı.
Ağ üzerinden doğrudan ayıklama ve yükleme: Hedef Azure ortamı, verileri ayıklamak için eski Netezza sistemine normalde SQL komutu aracılığıyla bir veri ayıklama isteği gönderir. Sonuçlar ağ üzerinden gönderilir ve verileri ara dosyalara göndermeye gerek olmadan doğrudan Azure Synapse yüklenir. Bu senaryoda sınırlayıcı faktör normalde Netezza veritabanı ile Azure ortamı arasındaki ağ bağlantısının bant genişliğidir. Çok büyük veri hacimleri için bu yaklaşım pratik olmayabilir.
Ayrıca her iki yöntemi de kullanan karma bir yaklaşım vardır. Örneğin, Azure Synapse'de hızlı bir şekilde bir test ortamı sağlamak için daha küçük boyut tabloları ve daha büyük olgu tablolarının örnekleri için doğrudan ağ ayıklama yaklaşımını kullanabilirsiniz. Büyük hacimli geçmiş olgu tabloları için Azure Data Box kullanarak dosya ayıklama ve aktarma yaklaşımını kullanabilirsiniz.
Netezza veya Azure'dan mı düzenleme?
Azure Synapse taşınırken önerilen yaklaşım, Azure Synapse Pipelines veya Azure Data Factory kullanarak Azure ortamından veri ayıklama ve yüklemenin yanı sıra polybase veya COPY INTO gibi ilişkili yardımcı programları en verimli şekilde yüklemektir. Bu yaklaşım Azure özelliklerinden yararlanarak yeniden kullanılabilir veri yükleme işlem hatları oluşturmak için kolay bir yöntem sağlar.
Bu yaklaşımın diğer avantajları arasında yönetim ve yükleme işlemi Azure'da çalıştırıldığı için veri yükleme işlemi sırasında Netezza sistemi üzerindeki etkinin azaltılması ve meta veri tabanlı veri yükleme işlem hatlarını kullanarak işlemi otomatikleştirme özelliği yer alır.
Hangi araçlar kullanılabilir?
Veri dönüştürme ve taşıma görevi, tüm ETL ürünlerinin temel işlevidir. Bu ürünlerden biri mevcut Netezza ortamında zaten kullanılıyorsa, mevcut ETL aracının kullanılması Netezza'dan Azure Synapse veri geçişini basitleştirebilir. Bu yaklaşım, ETL aracının hedef ortam olarak Azure Synapse desteklediğini varsayar. Azure Synapse destekleyen araçlar hakkında daha fazla bilgi için bkz. Veri tümleştirme iş ortakları.
ETL aracı kullanıyorsanız Azure bulut performansı, ölçeklenebilirlik ve maliyetten yararlanmak ve Netezza veri merkezindeki kaynakları boşaltmak için bu aracı Azure ortamında çalıştırmayı göz önünde bulundurun. Bir diğer avantaj da bulut ve şirket içi ortamlar arasındaki veri hareketini azaltmaktır.
Özet
Özetlemek gerekirse, verileri ve ilişkili ETL işlemlerini Netezza'dan Azure Synapse geçirme önerilerimiz şunlardır:
Başarılı bir geçiş alıştırması yapmak için önceden plan yapın.
En kısa sürede geçirilecek verilerin ve işlemlerin ayrıntılı bir envanterini oluşturun.
Verileri ve işlem kullanımını doğru bir şekilde anlamak için sistem meta verilerini ve günlük dosyalarını kullanın. Güncel olmayabileceği için belgelere güvenmeyin.
Geçirilecek veri birimlerini ve şirket içi veri merkezi ile Azure bulut ortamları arasındaki ağ bant genişliğini anlayın.
Geçiş iş yükünü en aza indirmek için standart "yerleşik" Azure özelliklerinden yararlanın.
Hem Netezza hem de Azure ortamlarında veri ayıklama ve yükleme için en verimli araçları belirleyin ve anlayın. İşlemin her aşamasında uygun araçları kullanın.
Netezza sistemi üzerindeki etkiyi en aza indirirken geçiş sürecini düzenleyip otomatikleştirmek için Azure Synapse Pipelines veya Azure Data Factory gibi Azure olanaklarını kullanın.
Sonraki adımlar
Güvenlik erişim işlemleri hakkında daha fazla bilgi edinmek için bu serinin sonraki makalesine bakın: Netezza geçişleri için güvenlik, erişim ve işlemler.