A Data Lake yapılandırılmış ve yapılandırılmamış tüm verilerinizi istediğiniz ölçekte depolamak için kullanabileceğiniz merkezi bir depodur. Daha iyi iş öngörüleri için önce verileri yapılandırmanıza ve ardından farklı analiz türlerini çalıştırmanıza gerek kalmadan verilerinizi olduğu gibi depolayabilirsiniz. Yıllar geçtikçe veri gölleri oluştu Amazon Basit Depolama Hizmeti (Amazon S3) kurumsal veriler için varsayılan depo haline geldi ve çeşitli analitik ve makine öğrenimi kullanım senaryoları için verileri sorgulayan geniş bir kullanıcı grubu için ortak bir seçimdir. Amazon S3, çeşitli veri kümelerine erişmenize, iş zekası kontrol panelleri oluşturmanıza ve veri tüketimini hızlandırmanıza olanak tanır. modern veri mimarisi or veri ağı desen üzerinde Amazon Web Services (AWS).

Veri göllerindeki analitik kullanım örnekleri her zaman gelişmektedir. Çoğu zaman, çeşitli kaynaklardan veriyi sürekli olarak bir veri gölüne almak ve verileri, işlem yeteneklerine sahip birden çok analiz aracı aracılığıyla eşzamanlı olarak sorgulamak istersiniz. Ancak geleneksel olarak Amazon S3 üzerinde oluşturulan veri gölleri değişmezdir ve değişen kullanım durumlarını desteklemek için gereken işlem yeteneklerini sağlamaz. Değişen kullanım senaryolarıyla birlikte müşteriler, yalnızca yeni veya artımlı verileri işlem olarak veri göllerine taşımanın değil, aynı zamanda mevcut verileri temel alınarak dönüştürmenin yollarını arıyor. Apache Parke işlemsel bir formata dönüştürülür. Aşağıdaki gibi tablo formatlarını açın: Apaçi Buzdağı, bu soruna bir çözüm sağlayın. Apache Iceberg, veri göllerinde işlemlere olanak tanır ve veri depolamayı, yönetimi, alımı ve işlemeyi basitleştirebilir.

Bu yazıda, Amazon S3 data lake'teki Apache Parquet formatındaki mevcut verileri Apache Iceberg formatına nasıl dönüştürebileceğinizi gösteriyoruz. Jupyter Notebook tabanlı etkileşimli oturumlar tekrar AWS Yapıştırıcı 4.0.

Mevcut Parkenin Buzdağına Taşınması

Veri gölünü bir işlem tablosu biçimine dönüştürmek için Apache Parquet biçimindeki bir veri gölündeki mevcut verileri Apache Iceberg biçimine geçirmenin iki genel yöntemi vardır.

Yerinde veri yükseltme

Yerinde veri taşıma stratejisinde, mevcut veri kümeleri, önce mevcut verileri yeniden işlemeden veya yeniden düzenlemeden Apache Iceberg formatına yükseltilir. Bu, veri gölündeki veri dosyalarının geçiş sırasında değiştirilmediği ve tüm Apache Iceberg meta veri dosyalarının (bildirimler, bildirim dosyaları ve tablo meta veri dosyaları) verilerin kapsamı dışında oluşturulduğu anlamına gelir. Bu yöntemde meta veriler yalıtılmış bir ortamda yeniden oluşturulur ve mevcut veri dosyalarıyla aynı konuma yerleştirilir. Bu, tüm veri dosyalarının yeniden yazılmasına kıyasla çok daha ucuz bir işlem olabilir. Mevcut veri dosyası formatı Apache Parquet, Apache ORC veya Apache Avro olmalıdır. Yerinde geçiş iki yoldan biriyle gerçekleştirilebilir:

1. kullanma dosya Ekle: Bu prosedür, mevcut veri dosyalarını, dosyaları içeren yeni bir anlık görüntüyle birlikte mevcut bir Iceberg tablosuna ekler. Taşıma veya anlık görüntünün aksine, add_files belirli bir bölümden veya bölümlerden dosyaları içe aktarabilir ve yeni bir Buzdağı tablosu oluşturmaz. Bu prosedür, dosyaların buzdağı tablosunun şemasıyla eşleşip eşleşmediğini belirlemek için şemasını analiz etmez. Tamamlandıktan sonra Iceberg tablosu bu dosyaları Apache Iceberg'in sahip olduğu dosya kümesinin parçasıymış gibi ele alır.
2. kullanma göç: Bu prosedür, bir tabloyu kaynağın veri dosyalarıyla yüklenen bir Apache Buzdağı tablosuyla değiştirir. Tablonun şeması, bölümlemesi, özellikleri ve konumu kaynak tablodan kopyalanır. Desteklenen formatlar Avro, Parquet ve ORC'dir. Varsayılan olarak orijinal tablo şu adla korunur: table_BACKUP_. Ancak işlem sırasında orijinal tabloyu olduğu gibi bırakmak için, aynı kaynak veri dosyalarına ve şemaya sahip yeni bir geçici tablo oluşturmak üzere anlık görüntüyü kullanmanız gerekir.

Bu yazıda size Buzdağını nasıl kullanabileceğinizi göstereceğiz. add_files yerinde veri yükseltme prosedürü. Şunu unutmayın: migrate prosedür AWS Glue Data Catalog'da desteklenmez.

Aşağıdaki diyagramda üst düzey bir gösterim gösterilmektedir.

Verilerin CTAS geçişi

Seçimli tablo oluşturma (CTAS) geçiş yaklaşımı, tüm veri dosyalarının yeniden düzenlenmesiyle birlikte Iceberg'e ilişkin tüm meta veri bilgilerinin oluşturulduğu bir tekniktir. Bu yöntem, kaynak veri kümesini gruplar halinde gölgeler. Gölge yakalandığında gölgeli veri kümesini kaynakla değiştirebilirsiniz.

Aşağıdaki diyagramda yüksek seviyeli akış gösterilmektedir.

Önkoşullar

İzlenecek yolu takip etmek için aşağıdakilere sahip olmanız gerekir:

AWS CLI'de aşağıdaki kodu kullanarak veri boyutunu kontrol edebilirsiniz veya AWS BulutKabuğu:

//Run this command to check the data size aws s3 ls --summarize --human-readable --recursive s3://noaa-ghcn-pds/parquet/by_year/YEAR=2023

Bu yazının yazıldığı an itibarıyla Amazon S107 yolunda 70 yılı için toplam boyutu 2023 MB olan 3 nesne bulunmaktadır.

Çözümü uygulamak için birkaç hazırlık adımını tamamlamanız gerektiğini unutmayın.

AWS CloudFormation kullanarak kaynakları dağıtın

Çözüme yönelik S3 paketini ve AWS IAM rolünü ve politikasını oluşturmak için aşağıdaki adımları tamamlayın:

1. AWS hesabınızda oturum açın ve ardından CloudFormation şablonunu başlatmak için Yığını Başlat'ı seçin.

2. İçin Yığın adı, isim girin.
3. Parametreleri varsayılan değerlerde bırakın. Varsayılan değerler değiştirilirse aşağıdaki adımlarda ilgili değişiklikleri yapmanız gerektiğini unutmayın.
4. Klinik Sonraki yığınınızı oluşturmak için.

Bu AWS CloudFormation şablon aşağıdaki kaynakları dağıtır:

• adlı bir S3 kovası demo-blog-post-XXXXXXXX (XXXXXXXX kullanılan AWS hesap kimliğini temsil eder).
• Adlandırılmış iki klasör parquet ve iceberg kovanın altında.
• Bir IAM rolü ve adlı bir politika demoblogpostrole ve demoblogpostscoped respectivamente.
• An AWS Tutkal veritabanı adlı ghcn_db.
• An AWS Tutkal Paletli adlı demopostcrawlerparquet.

AWS CloudFormation şablonu başarıyla dağıtıldıktan sonra:

1. AWS CLI'de aşağıdaki komutu kullanarak oluşturulan S3 klasöründeki verileri kopyalayın veya AWS BulutKabuğu. değiştirmek XXXXXXXX hedef S3 kova adına uygun şekilde.
   Not: Örnekte yalnızca 2023 yılına ait verileri kopyalıyoruz. Ancak aynı talimatları izleyerek tüm veri kümesiyle çalışabilirsiniz.

   aws s3 sync s3://noaa-ghcn-pds/parquet/by_year/YEAR=2023/ s3://demo-blog-post-XXXXXXXX/parquet/year=2023

2. AWS Management Console'u açın ve AWS Glue konsoluna gidin.
3. Gezinti bölmesinde şunu seçin: Tarayıcıları.
4. Adı verilen tarayıcıyı çalıştırın demopostcrawlerparquet.
5. AWS Glue tarayıcısından sonra demopostcrawlerparquet başarıyla çalıştırıldığında, Apache Parquet verilerinin meta veri bilgileri şu kategori altında kataloglanacaktır: ghcn_db Tablo adıyla AWS Glue veritabanı source_parquet. Tablonun bölümlenmiş olduğuna dikkat edin year ve element sütunlar (S3 kovasındaki gibi).

6. Verileri doğrulamak için aşağıdaki sorguyu kullanın. Amazon Atina konsol. Amazon Athena'yı AWS Hesabınızda ilk kez kullanıyorsanız bir Amazon S3'te sorgu sonucu konumu.

   SELECT * FROM ghcn_db.source_parquet limit 10;

İşleme için bir AWS Glue Studio not defteri başlatın

Bu yazı için bir AWS Glue Studio dizüstü bilgisayar kullanıyoruz. içindeki adımları izleyin AWS Glue Studio'da not defterlerini kullanmaya başlama dizüstü bilgisayar ortamını ayarlamak için. Bunun altında barındırılan not defterlerini başlatın Link ve bunları yerel bir iş istasyonunda açın.

1. AWS Glue Studio'yu açın.
2. Klinik ETL İşleri.
3. Klinik Jupyter dizüstü bilgisayar ve sonra seç Mevcut bir not defterini yükleyin ve düzenleyin. Itibaren Dosya seçin, gerekliyi seçin ipynb dosya ve seçim Açılış, Daha sonra seçmek oluşturmak.
4. Üzerinde Dizüstü bilgisayar kurulumu sayfası, için İş adı, mantıksal bir ad girin.
5. İçin IAM rolüseçin demoblogpostrole. Seçin İş oluştur. Bir dakika sonra Jupyter not defteri düzenleyicisi belirir. Tüm varsayılan hücreleri temizleyin.

Önceki adımlarda AWS Glue Studio dizüstü bilgisayar ortamı başlatılır. Emin olun İndirim dizüstü bilgisayar her kullanıldığında.

Yerinde veri yükseltme

Bu bölümde size nasıl kullanabileceğinizi göstereceğiz. add_files Yerinde veri yükseltmesi elde etmek için prosedür. Bu bölüm şunları kullanır: ipynb dosya adlı demo-in-place-upgrade-addfiles.ipynb. ile kullanmak için add_files prosedür, aşağıdakileri tamamlayın:

1. Üzerinde Dizüstü bilgisayar kurulumu sayfası, için İş adı, girmek demo-in-place-upgrade açıklandığı gibi not defteri oturumu için İşleme için Glue not defterini başlatın.
2. Bölümün altındaki hücreleri çalıştırın Yapıştırma oturumu yapılandırmaları. Önkoşullardan S3 paketi adını sağlayın. bucket_name değiştirilerek değişken XXXXXXXX.
3. Not defterindeki sonraki hücreleri çalıştırın.

Aşağıdaki hücreye dikkat edin Add_files prosedürünü yürütün bölümü belirtilen yolda meta veri oluşturma işlemini gerçekleştirir.

Yeni Iceberg tablosunun veri dosyası yollarını inceleyin. göstermek için Buzdağı tablosunun mevcut veri dosyaları, .files gibi ayrıntıları almak için kullanılabilir. file_path, partition, ve diğerleri. Yeniden oluşturulan dosyalar Amazon S3 altındaki kaynak yolunu işaret ediyor.

Dönüşümden sonra meta veri dosyasının konumunu not edin. adlı yeni klasöre işaret ediyor iceberg Amazon S3 altında. Bu kullanılarak kontrol edilebilir .snapshots kontrol etmek Buzdağı tablolarının anlık görüntü dosyası konumu. Ayrıca Amazon S3 URI'sinde de aynısını kontrol edin s3://demo-blog-post-XXXXXXXX/iceberg/ghcn_db.db/target_iceberg_add_files/metadata/. Ayrıca bildirim listesinin iki versiyonunun daha sonra oluşturulduğuna dikkat edin. add_files prosedür çalıştırıldı. Birincisi veri şemasını içeren boş bir tablo, ikincisi ise dosyaların eklenmesidir.

Tablo, veritabanı altında AWS Glue'da kataloglanmıştır ghcn_db tablo türü olarak ICEBERG.

Kaynak ve hedef tablo arasında Amazon Athena'yı kullanarak kayıt sayısını karşılaştırın. Onlar aynı.

Özetle şunları kullanabilirsiniz: add_files Bir veri gölündeki Apache Parquet formatındaki mevcut veri dosyalarını, meta veri dosyalarını ekleyerek ve tabloyu sıfırdan yeniden oluşturmadan Apache Iceberg formatına dönüştürme prosedürü. Aşağıda bu yöntemin bazı artıları ve eksileri verilmiştir.

Artılar

• Yeniden ifade olmadığından verileri okumak için tam tablo taramalarını önler. Bu zaman kazandırabilir.
• Meta verinin yazılması sırasında herhangi bir hata meydana gelirse, verinin tamamının değil, yalnızca meta verinin yeniden yazılması gerekir.
• Mevcut katalog hala mevcut olduğundan mevcut işlerin kökeni korunur.

Eksiler

• Meta veri yazma işlemi sırasında veri kümesinde veriler işleniyorsa (ekleme, güncelleme ve silme), yeni verileri dahil etmek için işlemin yeniden çalıştırılması gerekir.
• İşlemi ikinci kez çalıştırmak zorunda kalmamak için yazma kesintisi olmalıdır.
• Verilerin yeniden beyan edilmesi gerekiyorsa kaynak veri dosyaları değiştirilmediği için bu iş akışı çalışmayacaktır.

Verilerin CTAS geçişi

Bu bölüm şunları kullanır: ipynb dosya adlı demo-ctas-upgrade.ipynb. Aşağıdakileri tamamlayın:

1. Üzerinde Dizüstü bilgisayar kurulumu sayfası, için İş adı, girmek demo-ctas-upgrade aşağıda açıklandığı gibi not defteri oturumu için İşleme için Glue not defterini başlatın.
2. Bölümün altındaki hücreleri çalıştırın Yapıştırma oturumu yapılandırmaları. Önkoşullardan S3 paketi adını sağlayın. bucket_name değiştirilerek değişken XXXXXXXX.
3. Not defterindeki sonraki hücreleri çalıştırın.

Aşağıdaki hücreye dikkat edin Parkeden Buzdağı tablosu oluşturun bölümü, gölgenin Iceberg formatına yükseltilmesini gerçekleştirir. Iceberg'in, Iceberg tablosuna yazmadan önce verileri tablo bölümlerine göre sıralamasını gerektirdiğini unutmayın. Daha fazla ayrıntıyı şu adreste bulabilirsiniz: Dağıtım Modlarını Yazma.

Yeni Iceberg tablosunun veri ve meta veri dosyası yollarına dikkat edin. Amazon S3 kapsamındaki yeni yola işaret ediyor. Ayrıca Amazon S3 URI'sini kontrol edin s3://demo-blog-post-XXXXXXXX/iceberg/ghcn_db.db/target_iceberg_ctas/ bu yazı için kullanıldı.

Tablo, veritabanı altında AWS Glue altında kataloglanmıştır ghcn_db tablo türü olarak ICEBERG.

Kaynak ve hedef tablo arasında Amazon Athena'yı kullanarak kayıt sayısını karşılaştırın. Onlar aynı.

Özet olarak, CTAS yöntemi, gerçek verileri yeniden düzenlemenin yanı sıra tüm meta veri dosyalarını oluşturarak yeni bir tablo oluşturur. Aşağıda bu yöntemin bazı artıları ve eksileri verilmiştir:

Artılar

• Veriler yeniden düzenlendiğinden işlem sırasında verileri denetlemenize ve doğrulamanıza olanak tanır.
• Geçiş işlemi sırasında herhangi bir çalışma zamanı sorunu varsa, Apache Iceberg tablosu silinerek geri alma ve kurtarma kolayca gerçekleştirilebilir.
• Bir kaynağı taşırken farklı yapılandırmaları test edebilirsiniz. Her konfigürasyon için yeni bir tablo oluşturabilir ve etkisini değerlendirebilirsiniz.
• Gölge verileri, kaynaktaki farklı bir dizine yeniden adlandırılır (böylece eski Apache Parquet verileriyle çakışmaz).

Eksiler

• Geçiş ve test aşamasında hem orijinal Apache Parquet hem de yeni Apache Iceberg tabloları mevcut olduğundan, veri kümesinin depolanması işlem sırasında iki katına çıkar. Maliyet tahmini sırasında bunun dikkate alınması gerekir.
• Hem veriler hem de meta veriler yazıldığı için taşıma işlemi çok daha uzun sürebilir (verilerin hacmine bağlı olarak).
• İşlem sırasında kaynak tabloda değişiklik olması durumunda tabloları senkronize tutmak zordur.

Temizlemek

Gelecekte ücret alınmasını önlemek ve kullanılmayan rolleri ve ilkeleri temizlemek için oluşturduğunuz kaynakları silin: veri kümeleri, CloudFormation yığını, S3 kovası, AWS Glue işi, AWS Glue veritabanı ve AWS Glue tablosu.

Sonuç

Bu gönderide, süreçleri tamamlamak için AWS Glue 3'daki etkileşimli oturumları kullanarak mevcut Apache Parquet biçimli verileri Amazon S4.0'teki Apache Iceberg'e taşıyarak işlemsel veri gölüne dönüştürme stratejilerini öğrendiniz. Mevcut bir veri gölünün Apache Iceberg tablo formatına dayalı bir işlemsel veri gölüne dönüştürülmesinin gerektiği gelişen bir kullanım senaryonuz varsa bu gönderideki yönergeleri izleyin.

Bu yükseltme için seçeceğiniz yol, yerinde yükseltme veya CTAS geçişi veya her ikisinin birleşimi, veri mimarisinin ve veri entegrasyonu hattının dikkatli analizine bağlı olacaktır. Tartışıldığı gibi her iki yolun da artıları ve eksileri var. Yüksek düzeyde, bu yükseltme süreci, veri entegrasyonu kalıplarını ve kullanım durumlarını belirlemek için iyi tanımlanmış birden fazla aşamadan geçmelidir. Doğru stratejiyi seçmek performans, maliyet, veri güncelliği, geçiş sırasında kabul edilebilir kesinti süresi gibi gereksinimlerinize bağlı olacaktır.

Yazar hakkında

Rajdip Çaudhuri Amazon Web Services'ta veri ve analitik konusunda uzmanlaşmış bir Kıdemli Çözüm Mimarıdır. AWS müşterileri ve iş ortaklarıyla veri ve analitik gereksinimleri konusunda çalışmaktan keyif alıyor. Boş zamanlarında futbol ve sinemadan hoşlanır.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/big-data/migrate-an-existing-data-lake-to-a-transactional-data-lake-using-apache-iceberg/