Bu blog bütünsel olarak şunları ele alacaktır: (a) Veri depolama nedir? (b) Veri ambarı için veri modelleme yaklaşımları (c) AWS'deki veri ambarı ve son olarak (d) Yönetilen Hizmet kullanılarak operasyonel yükün azaltılmasına yönelik veri ambarı. Meslekten olmayan birinin bakış açısından " " anlayalım Veri ambarının ne olduğunu Wikipedia'ya göre, kurumsal veri ambarı (EDW) olarak da bilinen veri ambarı (DW veya DWH), raporlama ve veri analizi için kullanılan bir sistemdir ve temel bir bileşeni olarak kabul edilir. Veri ambarları, bir veya daha fazla farklı kaynaktan gelen entegre verilerin merkezi depolarıdır. Güncel ve geçmiş verileri, kuruluş genelinde çalışanlar için analitik raporlar oluşturmak amacıyla kullanılan tek bir yerde saklarlar. Bu, şirketlerin verilerini sorgulamalarına, içgörüler elde etmelerine ve kararlar almalarına olanak tanıdığı için faydalıdır. iş zekasının Temel anlamda, bir işletmenin veri odaklı bir organizasyon haline gelmesine yardımcı olmak için içgörüleri (iş zekası) toplama, depolama ve verimli bir şekilde sağlama sanatıdır. Bir bakıma bu başka bir işlem veritabanıdır ancak analitik iş yükleri için optimize edilmiştir. Yukarıdaki şemaya göre veriler kaynaktan toplanır, kullanıma göre dönüştürülür (ETL/ELT) ve iş zekası araçları aracılığıyla DWH/Data mart ve Insights'ta depolanır. ELT (ETL vs ELT), Cloud DWH (AWS Redshift, Google Big Query, Snowflake, Databricks) ve diğer Yönetilen Veri çözümlerinin mevcut olmadığı ve son zamanlarda basitleştirilip ölçeklendirildiği şirket içi kurulum günlerinde bunların hepsi basit görünüyordu DWH'nin erişimi. Bu blogda her şeyi tek tek anlayalım. Basitleştirmek adına, sonsuz bilgi işlem ve depolamanın olmadığı ve işlem sisteminin analitik sorguları verimli bir şekilde işleyemediği varsayımıyla devam edelim. Depolama açısından ideal olan, analitik sorguları (Dilimleme/küp/Küp vb.) verimli bir şekilde işleyen ve gerekli gecikmeyi sağlayan bir veri ambarı tasarlamak için etkili bir yola ihtiyaç duyulan yer burasıdır. Bütün bunlar için yönelik iki teorik tasarım modeli ortaya çıktı: Veri Ambarı tasarımına (a) Bill Inmon – Yukarıdan Aşağıya yaklaşımı (EDW) ve (b) Ralph Kimball – Aşağıdan yukarıya yaklaşım (Data mart). Inmon'un yaklaşımı küresel ölçekte merkezi olarak inşa etmek ve yavaş inşayı hesaba katmaktır; Kimball'ın yöntemi ise silolar halinde bağımsız bir veri pazarı oluşturup daha sonra birbirine bağlanmaktır. Hangi modelin en iyisi olduğuna veya hangisini seçeceğimize dalmayalım. Benim durumumda kısaca her iki model de işe yarıyor ve bu tamamen organizasyonun kullanım senaryosuna ve olgunluğuna bağlı. Bu tasarımdaki bir diğer önemli nokta, daha hızlı sorgulama ve boyutluluğun önemli bir pivotu olan "Veri Temsili", Yıldız Şeması, Kar Tanesi şeması veya Yıldız ve kar tanesi Hibritini kullanan Boyutsal modellemedir. Tek önemli çıkarım, sonsuz lojistiğe rağmen iyi bir Veri Ambarı tasarımının çok boyutlu bir sorunu çözebileceğidir. Bu yüzden görmezden gelmemek daha iyi. bir sonraki adımı, şirket içinden (Teradata, IBM DB2, Oracle, vb.) Bulut DW'ye (Snowflake, Redshift, BigQuery, vb.) kadar değişebilen tercih edilen platformdur. Geleneksel bir veri ambarı oluşturmak karmaşıktır ve devam eden yönetim ve bakım zorlu ve pahalı olabilir. Bir sonraki bölümde, AWS Redshift ile nasıl derleme yapılacağına derinlemesine bakacağız (şirket içi mi daha iyi, Bulut mu yoksa hangi bulut DWH'nin daha iyi olduğu tartışması yok). Bir DW oluşturmanın Amazon Redshift, kullanımı basit ve uygun maliyetli, analiz sorguları için olağanüstü performans sağlayan, tam olarak yönetilen, petabayt ölçekli, kurumsal düzeyde bir veri ambarıdır. Amazon Redshift, yama uygulama, yedekleme ve donanım tedariği gibi görevleri otomatikleştirerek geleneksel veri ambarlarının gerektirdiği operasyonel ek yükü azaltır. Veri ambarınızın altyapısını ve performans temellerini özelleştirebileceğiniz bir Amazon Redshift kümesi yapılandırabilirsiniz. Amazon Redshift ayrıca Amazon Redshift kümesini DWH'nin ötesinde kullanmanıza olanak tanıyan Redshift Spectrum, Datashare, Redshift ML ve Sunucusuz kurulum da sağlar. Kuruluma giden yol, Veri toplama için hangi hizmetlerden yararlanılacağını tanımlayın (AWS DMS, DynamoDB, EMR, Glue, Kinesis, S3, SSH Host vb.) Etkileşim kurmanın bir yolunu tanımlayın (Sorgu analiz araçları ve Yönetim Arayüzleri) Redshift MPP mimarisini anlayın (Dağıtılmış, hiçbir şey paylaşılmaz) Gerekli veri boyutu, büyüme, düğüm ve sorgu performansıyla Kümeyi (DC2, DS2 veya RA3) başlatın Gerekli Veri türü, şema türü, sıkıştırma, arabellek, kodlama ile kullanım senaryosuna veya DWH uygulamasına göre veritabanı şeması tasarlayın Farklı dosya türleri için COPY, minimum değişiklik için INSERT ve bakım için ANALYZE & VACUUM kullanarak veri yükleme Sorgu optimizasyonu ve performans iyileştirmesi gerçekleştirin Harici tablo için Spectrum ve sıfır kopya için Veri paylaşımı kullanarak S3'ten yararlanın Derinlemesine içgörüler için Redshift ML'yi kullanın İçgörü elde etmek için BI araçlarına yönelik AWS Quicksight'tan yararlanın. Şu ana kadar Cloud DWH kullanmak mantıklı geliyor ancak ? Aşağıdaki resimde Veri Gölleri ve Veri Ambarlarının birlikte nasıl sorunsuz bir şekilde çalıştığı açıklanmaktadır. AWS RDS, besleyen, uygun maliyetli ve dayanıklı bir çözüm sunan veri kaynağı olarak hizmet verir. Veriler daha sonra ETL işlemleri kullanılarak dönüştürülür ve Redshift'e dahil edilir. Athena, Glue, Spectrum, Lake Formation ve diğerleri gibi ek AWS hizmetleri, kapsamlı bir Veri Çözümü oluşturma konusundaki boşluğu doldurmada önemli bir rol oynuyor. bu, DWH + Data Lake/Veri için Yönetilen Hizmetler çözümüne nasıl uyuyor Amazon S3'ü Sonuç olarak, bu blog Veri Ambarı'nın temellerini kapsıyor, hem teorik olarak hem de teknoloji yığınına odaklanarak uygulama yaklaşımını derinlemesine inceliyor. Ayrıca, daha geniş veri çözümleri yelpazesine nasıl sorunsuz bir şekilde entegre olduğuna dair kuşbakışı bir görünüm elde ediyoruz.
