AWS Glue Veri Kataloğu Sütun İstatistikleri ile Amazon Redshift Data Lake sorgularını hızlandırın | Amazon Web Hizmetleri

Amazon Kırmızıya Kaydırma açık formatlı dosyalardan yapılandırılmış ve yarı yapılandırılmış verileri verimli bir şekilde sorgulamanıza ve almanıza olanak tanır Amazon S3 Amazon Redshift tablolarına veri yüklemenize gerek kalmadan veri gölü. Amazon Redshift, SQL yeteneklerini veri gölünüze genişleterek analitik sorgular çalıştırmanızı sağlar. Amazon Redshift, CSV, JSON, Parquet, ORC gibi çok çeşitli tablo veri biçimlerini ve Apache Hudi, Linux temel Delta Lake ve Apache Iceberg gibi açık tablo biçimlerini destekler.

Dosyalarınızın yapısını, dosyaların S3 konumunu tanımlayarak ve bunları harici bir veri kataloğunda tablolar olarak kaydederek Redshift harici tabloları oluşturursunuz. Harici veri kataloğu AWS Glue Data Catalog, Amazon Athena ile gelen veri kataloğu veya kendi Apache Hive metastore'unuz olabilir.

Geçtiğimiz yıl boyunca Amazon Redshift, yeniden yazma, planlama, tarama yürütme ve AWS Glue Data Catalog sütun istatistiklerini tüketme gibi sorgu motorunun birden fazla alanında veri gölü sorguları için çeşitli performans iyileştirmeleri ekledi. Redshift ile veri gölü sorgularında en iyi performansı elde etmek için şunları kullanabilirsiniz: AWS Glue Data Catalog'un sütun istatistikleri özelliği Data Lake tablolarında istatistik toplamak için. Amazon Redshift Serverless örnekleri için, S3 dosyalarının paralel işlenmesinin artırılmasıyla gelişmiş tarama performansı göreceksiniz ve bu, kullanılan RPU'lara göre otomatik olarak gerçekleşir.

Bu yazıda, endüstri standardını kullanarak gözlemlediğimiz performans iyileştirmelerini vurguluyoruz TPC-DS kıyaslamalar. TPC-DS 3 TB kıyaslamasının genel yürütme süresi 3 kat arttı. Kıyaslamamızdaki sorguların bazıları 12 kata kadar hızlandı.

Performans geliştirmeleri

Son bir yılda veri gölü sorgularının performansını iyileştirmek için aşağıdakiler de dahil olmak üzere çeşitli performans iyileştirmeleri yapıldı.

• Sorgu planlarının kalitesini artırmak için AWS Glue Veri Kataloğu sütun istatistiklerini kullanın ve Redshift optimize edicisini ayarlayın
• Bölüm sütunları için bloom filtrelerini kullanın
• Dosyaların paralel işlenmesinin artırılmasıyla Amazon Redshift Serverless örnekleri için iyileştirilmiş tarama verimliliği
• Benzer taramaları birleştirmek için yeni sorgu yeniden yazma kuralları
• AWS Glue Veri Kataloğundan meta verilerin daha hızlı alınması

Performans kazanımlarını anlamak için, farklı müşteri kullanım durumlarını temsil eden 3 TB veri kümeleri ve sorguları kullanarak endüstri standardı TPC-DS kıyaslamasında performansı test ettik. Performans, 128 RPU'lu bir Redshift sunucusuz veri ambarında test edildi. Testlerimizde, veri kümesi Amazon S3'te Parquet biçiminde depolandı ve harici veritabanlarını ve tabloları yönetmek için AWS Glue Data Catalog kullanıldı. Gerçek tablolar tarih sütununa göre bölümlendirildi ve her gerçek tablo yaklaşık 2,000 bölümden oluşuyordu. Tüm tabloların satır sayısı tablo özelliği, numRows, spektrum sorgu performansı kılavuzlar.

Redshift yama sürümünde bir temel çalışma yaptık (yama 172) geçen yıldan itibaren. Daha sonra, tüm TPC-DS sorgularını en son yama sürümünde (yama 180) geçen yıl eklenen tüm performans iyileştirmelerini içerir. Sonra kullandık AWS Glue Data Catalog'un sütun istatistikleri özelliği AWS Glue Veri Kataloğu sütun istatistiklerinin varlığıyla tüm tablolar ve ölçülen iyileştirmeler için istatistikleri hesaplamak.

Analizimiz, TPC-DS 3TB Parquet kıyaslamasının bu optimizasyonlarla önemli performans kazanımları elde ettiğini ortaya koydu. Özellikle, en son optimizasyonlarımızla bölümlenmiş Parquet 2 kat daha hızlı çalışma süreleri önceki uygulamaya kıyasla. AWS Glue Veri Kataloğu sütun istatistiklerinin etkinleştirilmesi performansı daha da iyileştirdi 3x tarafından geçen yıla kıyasla. Aşağıdaki grafik, AWS Glue Data Catalog sütun istatistiklerinin kullanılmasından kaynaklanan ek destek de dahil olmak üzere, geçen yıl boyunca tam kıyaslama (tüm TPC-DS sorguları) için bu çalışma zamanı iyileştirmelerini göstermektedir.

Şekil 1: TPC-DS 3T iş yükünün toplam çalışma süresindeki iyileştirme

Aşağıdaki grafik, AWS Glue Data Catalog sütun istatistikleriyle ve olmadan geçen yıl boyunca en büyük performans iyileştirmesine sahip TPC-DS kıyaslamasından gelen en iyi sorguları sunar. AWS Glue Data Catalog'da istatistikler mevcut olduğunda performansın çok arttığını görebilirsiniz (Data Lake tablolarınız için istatistikleri nasıl alacağınızla ilgili ayrıntılar için lütfen şuraya bakın: AWS Glue Veri Kataloğu sütun istatistiklerini kullanarak sorgu performansını optimize etme). Özellikle çoklu birleştirme sorguları, AWS Glue Veri Kataloğu sütun istatistiklerinden en fazla faydalanacaktır çünkü optimize edici, doğru birleştirme sırasını ve dağıtım stratejisini seçmek için istatistikleri kullanır.

Şekil 2: TPC-DS sorgularında hızlanma

Sorgu performansının iyileştirilmesine katkıda bulunan bazı iyileştirmeleri tartışalım.

Tablo düzeyindeki istatistiklerle optimizasyon

Amazon Redshift'in tasarımı, büyük ölçekli veri zorluklarını üstün hız ve maliyet verimliliğiyle ele almasını sağlar. Büyük ölçüde paralel işleme (MPP) sorgu motoru, AI destekli sorgu iyileştiricisi, otomatik ölçekleme yetenekleri ve diğer gelişmiş özellikleri, Redshift'in petabaytlarca veriyi arama, toplama ve dönüştürme konusunda mükemmel olmasını sağlar.

Ancak en güçlü sistemler bile, satır sayısı meta verileri gibi son derece yanlış tablo istatistikleri gibi karşıt kalıplarla karşılaştıklarında performans düşüşü yaşayabilirler.

Bu önemli meta veriler olmadan, Redshift'in sorgu iyileştiricisi, özellikle sorgu yürütme sırasında veri dağıtımıyla ilgili olanlar olmak üzere, olası iyileştirmelerin sayısında sınırlı olabilir. Bu, genel sorgu performansı üzerinde önemli bir etkiye sahip olabilir.

Bunu örneklendirmek için, milyarlarca satır içeren büyük bir tablo ile sadece birkaç yüz bin satır içeren küçük bir tablo arasında iç birleştirmeyi içeren aşağıdaki basit sorguyu ele alalım.

select small_table.sellerid, sum(large_table.qtysold)
from large_table, small_table
where large_table.salesid = small_table.listid
 and small_table.listtime > '2023-12-01'
 and large_table.saletime > '2023-12-01'
group by 1 order by 1

Olduğu gibi yürütülürse, büyük tablo birleştirmenin sağ tarafında olacak şekilde, sorgu en iyi olmayan performansa yol açacaktır. Bunun nedeni, büyük tablonun, aşağıdaki diyagramda gösterildiği gibi, küçük tabloyla iç birleştirmeyi gerçekleştirmek için tüm Redshift hesaplama düğümlerine dağıtılması (yayınlanması) gerekmesidir.

Şekil 3: Hatalı tablo istatistikleri, basit bir iç birleştirme için hesaplama düğümleri arasında sınırlı optimizasyonlara ve büyük miktarda veri yayınlanmasına yol açar

Şimdi, satır sayısı gibi tablo istatistiklerinin doğru olduğu bir senaryoyu düşünün. Bu, Amazon Redshift sorgu iyileştiricisinin, en uygun birleştirme sırasını belirleme gibi daha bilinçli kararlar almasını sağlar. Bu durumda, iyileştirici sorguyu hemen yeniden yazarak büyük tabloyu iç birleştirmenin sol tarafına yerleştirir, böylece aşağıdaki diyagramda gösterildiği gibi Redshift hesaplama düğümleri arasında yayınlanan küçük tablo olur.

Şekil 4: Doğru tablo istatistikleri, basit bir iç birleştirme için hesaplama düğümleri arasında yüksek düzeyde optimizasyonlara ve çok az veri yayınlanmasına yol açar

Neyse ki, Amazon Redshift, yerel tablolar için doğru tablo istatistiklerini otomatik olarak çalıştırarak korur ANALİZ arka planda komut. Ancak harici tablolar (veri gölü tabloları) için, bir sonraki bölümde tartışacağımız gibi Amazon Redshift ile birlikte kullanılmak üzere AWS Glue Data Catalog sütun istatistikleri önerilir. Amazon Redshift'te sorguları optimize etme hakkında daha genel bilgiler için lütfen şu belgelere bakın: sorgu performansını etkileyen faktörler, veri yeniden dağıtımı, ve Amazon Redshift'in sorgu tasarlamaya yönelik en iyi uygulamaları.

AWS Glue Veri Kataloğu sütun istatistiklerinde iyileştirmeler

AWS Glue Data Catalog'un hesaplama özelliği vardır sütun düzeyinde istatistikler Amazon S3 destekli harici tablolar için. AWS Glue Data Catalog, ek veri hatlarına ihtiyaç duymadan sütunlar için NDV, Null Sayısı, Min/Maks ve Ort. sütun genişliği gibi sütun düzeyinde istatistikleri hesaplayabilir. Amazon Redshift maliyet tabanlı optimize edici, daha kaliteli sorgu planları oluşturmak için bu istatistikleri kullanır. İstatistikleri tüketmenin yanı sıra, yüksek kaliteli sorgu planları elde etmek için kardinalite tahminlerinde ve maliyet ayarlamasında da çeşitli iyileştirmeler yaptık ve böylece sorgu performansını iyileştirdik.

TPC-DS 3TB veri kümesi, bu AWS Glue Data Catalog sütun istatistikleri sağlandığında toplam sorgu yürütme süresinde %40 iyileştirme gösterdi. Bireysel TPC-DS sorguları, sorgu yürütme süresinde 5 kata kadar iyileştirme gösterdi. Yürütme süresinde daha büyük etkiye sahip sorgulardan bazıları Q85, Q64, Q75, Q78, Q94, Q16, Q04, Q24 ve Q11'dir.

Maliyet tabanlı optimizasyon aracının istatistiklerle daha iyi bir sorgu planı oluşturduğu ve yürütme süresini nasıl iyileştirdiği örneğini inceleyeceğiz.

Sorgu planı farklılıklarını istatistiklerle göstermek için TPC-DS Q64'ün daha basit versiyonunu ele alalım.

select i_product_name product_name
,i_item_sk item_sk
,ad1.ca_street_number b_street_number
,ad1.ca_street_name b_street_name
,ad1.ca_city b_city
,ad1.ca_zip b_zip
,d1.d_year as syear
,count(*) cnt
,sum(ss_wholesale_cost) s1
,sum(ss_list_price) s2
,sum(ss_coupon_amt) s3
FROM   tpcds_3t_alls3_pp_ext.store_sales
,tpcds_3t_alls3_pp_ext.store_returns
,tpcds_3t_alls3_pp_ext.date_dim d1
,tpcds_3t_alls3_pp_ext.customer
,tpcds_3t_alls3_pp_ext.customer_address ad1
,tpcds_3t_alls3_pp_ext.item
WHERE
ss_sold_date_sk = d1.d_date_sk AND
ss_customer_sk = c_customer_sk AND

ss_addr_sk = ad1.ca_address_sk and
ss_item_sk = i_item_sk and
ss_item_sk = sr_item_sk and
ss_ticket_number = sr_ticket_number and
i_color in ('firebrick','papaya','orange','cream','turquoise','deep') and
i_current_price between 42 and 42 + 10 and
i_current_price between 42 + 1 and 42 + 15
group by i_product_name
,i_item_sk
,ad1.ca_street_number
,ad1.ca_street_name
,ad1.ca_city
,ad1.ca_zip
,d1.d_year

İstatistikler Olmadan Aşağıdaki şekil Q64'ün mantıksal sorgu planını temsil eder. Birleşimlerin kardinalite tahmininin doğru olmadığını görebilirsiniz. Doğru olmayan kardinalitelerle, optimize edici daha yüksek yürütme süresine yol açan alt-optimum bir sorgu planı üretir.

İstatistiklerle Aşağıdaki şekil, AWS Glue Veri Kataloğu sütun istatistiklerini tükettikten sonraki mantıksal sorgu planını temsil eder. Vurgulanan değişikliklere dayanarak, JOIN'in kardinalite tahminlerinin birçok büyüklükte iyileştiğini ve bunun da optimize edicinin daha iyi bir birleştirme sırası ve birleştirme stratejisi seçmesine yardımcı olduğunu görebilirsiniz (yayın DS_BCAST_INNER vs. dağıtmak DS_DIST_BOTH). Değiştirme customer_address ve customer İç tablodan dış tabloya doğru birleştirme ve birleştirme stratejilerini dağıtma olarak yapmanın büyük etkisi vardır çünkü bu, düğümler arasındaki veri hareketini azaltır ve hash tablosundan taşmayı önler.

Şekil 5: İstatistikler olmadan Q64'ün mantıksal sorgu planı

Şekil 6: AWS Glue Veri Kataloğu sütun istatistiklerini tükettikten sonra Q64'ün mantıksal sorgu planı

Sorgu planındaki bu değişiklik Q64'ün sorgu yürütme süresini 383 saniyeden 81 saniyeye çıkardı.

AWS Glue Data Catalog sütun istatistiklerinin optimize edici için daha büyük avantajları göz önüne alındığında, AWS Glue kullanarak veri gölünüz için istatistik toplamayı düşünmelisiniz. İş yükünüz JOIN yoğun bir iş yüküyse, istatistik toplamak iş yükünüzde daha büyük bir gelişme gösterecektir. Şuraya bakın: AWS Glue Veri Kataloğu sütun istatistiklerinin oluşturulması AWS Glue Data Catalog'da istatistiklerin nasıl toplanacağına ilişkin talimatlar için.

Sorgu yeniden yazma optimizasyonu

Aynı ortak ifade üzerinde skaler toplamları biraz farklı tahminler kullanarak birleştiren yeni bir sorgu yeniden yazma kuralı getirdik. Bu yeniden yazma, TPC-DS sorguları Q09, Q28 ve Q88'de performans iyileştirmeleriyle sonuçlandı. Aşağıdaki parçayla verilen bu sorguların temsilcisi olarak Q09'a odaklanalım:

SELECT CASE
WHEN (SELECT COUNT(*)
FROM store_sales
WHERE ss_quantity BETWEEN 1 AND 20) > 48409437
THEN (SELECT AVG(ss_ext_discount_amt)
FROM store_sales
WHERE ss_quantity BETWEEN 1 AND 20)
ELSE (SELECT AVG(ss_net_profit)
FROM store_sales
WHERE ss_quantity BETWEEN 1 AND 20) END
AS bucket1,
<<4 more variations of the CASE expression above>>
FROM reason
WHERE r_reason_sk = 1

Toplamda, olgu tablosunun 15 taraması var store_sales, her biri farklı veri alt kümeleri üzerinde çeşitli toplamlar döndürüyor. Motor önce alt sorgu kaldırma işlemini gerçekleştirir ve CASE ifadelerindeki çeşitli ifadeleri çapraz ürünlerle bağlanan ilişkisel alt ağaçlara dönüştürür ve sonra bunlar tüm skaler toplamları işleyen tek bir alt sorguya birleştirilir. Aşağıda açıklık için SQL kullanılarak açıklanan Q09 için ortaya çıkan plan şu şekilde verilmiştir:

SELECT CASE WHEN v1 > 48409437 THEN t1 ELSE e1 END,
<4 more variations>
FROM (SELECT COUNT(CASE WHEN b1 THEN 1 END) AS v1,
AVG(CASE WHEN b1 THEN ss_ext_discount_amt END) AS t1,
AVG(CASE WHEN b1 THEN ss_net_profit END) AS e1,
<4 more variations>
FROM reason,
(SELECT *,
ss_quantity BETWEEN 1 AND 20 AS b1,
<4 more variations>
FROM store_sales
WHERE ss_quantity BETWEEN 1 AND 20 OR
<4 more variations>))
WHERE r_reason_sk = 1)

Genel olarak, bu yeniden yazma kuralı hem gecikmede (3 kattan 8 kata iyileştirmeler) hem de Amazon S3'ten okunan baytlarda (taranan baytlarda ve dolayısıyla maliyette 6 kattan 8 kata azalma) en büyük iyileştirmeleri sağlıyor.

Bölüm sütunları için Bloom filtresi

Amazon Redshift, erken ve etkili veri filtrelemesini etkinleştirmek için Amazon S3'teki harici tabloların veri sütunlarında Bloom filtrelerini zaten kullanıyor. Geçtiğimiz yıl, bu desteği bölüm sütunları için de genişlettik. Bloom filtresi, birleştirme ilişkisine uymayan satırları filtreleyerek birleştirme sorgularını ölçekte hızlandıran olasılıksal, bellek açısından verimli bir veri yapısıdır ve ağ üzerinden aktarılan veri miktarını önemli ölçüde azaltır. Amazon Redshift, sorgu çalışma zamanında Bloom filtrelerinden yararlanmak için hangi sorguların uygun olduğunu otomatik olarak belirler.

Bu optimizasyon TPC-DS sorguları Q05, Q17 ve Q54'te performans iyileştirmeleriyle sonuçlandı. Bu optimizasyon hem gecikmede (2x'ten 3x'e iyileştirme) hem de S3'ten okunan baytlarda (taranan baytlarda 9x'ten 15x'e ve dolayısıyla maliyette azalma) büyük iyileştirmelerle sonuçlandı.

Aşağıda, çalışma zamanı filtresiyle ilgili iyileştirmeleri gösteren Q05 sorgusunun alt sorgusu bulunmaktadır.

select s_store_id,
sum(sales_price) as sales,
sum(profit) as profit,
sum(return_amt) as returns,
sum(net_loss) as profit_loss
from
( select  ss_store_sk as store_sk,
ss_sold_date_sk  as date_sk,
ss_ext_sales_price as sales_price,
ss_net_profit as profit,
cast(0 as decimal(7,2)) as return_amt,
cast(0 as decimal(7,2)) as net_loss
from tpcds_3t_alls3_pp_ext.store_sales
union all
select sr_store_sk as store_sk,
sr_returned_date_sk as date_sk,
cast(0 as decimal(7,2)) as sales_price,
cast(0 as decimal(7,2)) as profit,
sr_return_amt as return_amt,
sr_net_loss as net_loss
from tpcds_3t_alls3_pp_ext.store_returns
) salesreturnss,
tpcds_3t_alls3_pp_ext.date_dim,
tpcds_3t_alls3_pp_ext.store
where date_sk = d_date_sk
and d_date between cast('1998-08-13' as date)
and (cast('1998-08-13' as date) +  14)
and store_sk = s_store_sk
group by s_store_id

Bölme sütunlarında bloom filtresi desteği olmadan Aşağıdaki şekil, Q05'in alt sorgusu için mantıksal sorgu planıdır. Bu, iki büyük olgu tablosunu ekler store_sales (8B satırları) ve store_returns (863M satır) ve ardından çok seçici boyut tablolarıyla birleşir date_dim ve sonra boyut tablosu deposuyla. Birleşmenin şu şekilde olduğunu gözlemleyebilirsiniz: date_dim tablo satır sayısını 9B'den 93M satıra düşürür.

Bölme sütunlarında bloom filtresi desteğiyle Bölme sütunlarında bloom filtresinin desteğiyle, artık bloom filtresini oluşturuyoruz d_date_sk sütunu date_dim masayı açın ve bloom filtrelerini aşağı doğru itin store_sales ve store_returns tablo. Bu bloom filtreleri her ikisindeki bölümleri filtrelemeye yardımcı olur store_sales ve store_returns tablo çünkü birleştirme bölümleme sütununda gerçekleşir (işlenen bölümleme sayısı 10 kat azalır).

Şekil 7: Bölüm sütunlarında bloom filtresi desteği olmadan Q05'in alt sorgusu için mantıksal sorgu planı

Şekil 8: Bölüm sütunlarında bloom filtresi desteğiyle Q05'in alt sorgusu için mantıksal sorgu planı

Genel olarak, bölüm sütunundaki bloom filtresi, işlenen bölüm sayısını azaltarak S3 listeleme çağrılarının azalmasına ve okunacak veri dosyalarının sayısının azalmasına (taranan baytlarda azalma) neden olacaktır. Sadece 89M satırı taradığımızı görebilirsiniz store_sales ve 4M satırdan store_returns Bloom filtresi nedeniyle. Bu, JOIN düzeyinde işlenecek satır sayısını azalttı ve genel sorgu performansını 2 kat, taranan baytları ise 9 kat artırmaya yardımcı oldu.

Sonuç

Bu gönderide, Amazon Redshift veri gölü sorgusu işlemedeki yeni performans iyileştirmelerini ve AWS Glue Data Catalog istatistiklerinin Amazon Redshift'teki veri gölü sorguları için sorgu planlarının kalitesini artırmaya nasıl yardımcı olduğunu ele aldık. Bu iyileştirmeler birlikte TPC-DS 3 TB kıyaslamasını 3 kat iyileştirdi. Kıyaslamamızdaki sorguların bazıları 12 kata kadar hız artışından faydalandı.

Özetle, Amazon Redshift artık AWS Glue Data Catalog sütun istatistikleri, bölüm sütunlarında bloom filtreleri, yeni sorgu yeniden yazma kuralları ve meta verilerin daha hızlı alınması gibi iyileştirmelerle gelişmiş sorgu performansı sunuyor. Bu iyileştirmeler varsayılan olarak etkindir ve Amazon Redshift kullanıcıları iş yükleri için daha iyi sorgu yanıt sürelerinden faydalanacaktır. Daha fazla bilgi için lütfen AWS teknik hesap yöneticinize veya AWS hesap çözümleri mimarınıza ulaşın. Size ek rehberlik ve destek sağlamaktan mutluluk duyacaklardır.

yazarlar hakkında

Kalaiselvi Kamaraj Amazon'da Kıdemli Yazılım Geliştirme Mühendisidir. Redshift Sorgu işleme ekibinde çeşitli projelerde çalışmıştır ve şu anda Redshift Data Lake için performansla ilgili projelere odaklanmaktadır.

lyonları işaretle Amazon Redshift ekibinde Baş Ürün Yöneticisidir. Veri gölleri ve veri ambarlarının kesiştiği noktada çalışır. AWS'ye katılmadan önce Mark, Dremio ve Vertica'da ürün liderliği rolleri üstlendi. Veri analitiği ve müşterilerin verileriyle dünyayı değiştirmelerini sağlama konusunda tutkuludur.

Asser Mustafa AWS'de Dallas, Teksas, ABD merkezli Baş Dünya Uzman Çözüm Mimarıdır. Dünya çapındaki müşterilerle ortaklık kurarak, kuruluşların bulut tabanlı çözümleri benimsemelerine, veri varlıklarının değerini en üst düzeye çıkarmalarına, eski altyapıları modernize etmelerine ve makine öğrenimi ve gelişmiş analizler gibi son teknoloji yetenekleri uygulamalarına yardımcı olmak için veri mimarileri, geçişleri ve stratejik veri vizyonlarının tüm yönleri hakkında onlara tavsiyelerde bulunur. AWS'ye katılmadan önce Asser, çeşitli veri ve analiz liderlik rolleri üstlendi ve New York Üniversitesi'nden MBA ve New York'taki Columbia Üniversitesi'nden Bilgisayar Bilimleri alanında MS derecesi aldı. Kuruluşların gerçek anlamda veri odaklı hale gelmelerini ve verilerinin dönüştürücü potansiyelini ortaya çıkarmalarını sağlama konusunda tutkuludur.

• 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/accelerate-amazon-redshift-data-lake-queries-with-column-level-statistics/