Bu, BookMyShow'un Baş Teknoloji Sorumlusu Mahesh Vandi Chalil'in ortak yazdığı bir konuk gönderisidir.

BookMyShow (BMS), Hindistan'ın önde gelen bir eğlence şirketidir; filmler, oyunlar, konserler ve spor etkinlikleri için çevrimiçi bir biletleme platformu sağlar. Hindistan, Sri Lanka, Singapur, Endonezya ve Orta Doğu'daki müşterilere yıllık çalışma oranı bazında (COVID öncesi) 200 milyona kadar bilet satan BookMyShow ayrıca çevrimiçi bir medya akış hizmeti ve uçtan uca yönetim sunuyor. tüm türlerde sanal ve yer üstü eğlence deneyimleri.

Pandemi, BMS'ye 15 yıllık analitik çözümümüzü AWS'de modern bir veri mimarisine taşıma ve modernleştirme fırsatı verdi. Bu mimari modern, güvenli, yönetilen ve maliyeti optimize edilmiş bir mimaridir ve petabaytlara ölçeklenebilme özelliğine sahiptir. BMS, yalnızca dört ayda şirket içi ve diğer bulut platformlarından AWS'ye taşındı ve modernize edildi. Bu proje, uygulama taşıma projemizle paralel olarak yürütüldü ve depolamada %90, analitik harcamalarında %80 maliyet tasarrufu sağladı.

BMS analitik platformu, satış ve pazarlama, finans ve iş ortakları (örn. sinemalar ve etkinlik sahipleri) için iş ihtiyaçlarını karşılar ve izleyici, kişiselleştirme, fiyatlandırma ve veri bilimi ekipleri için uygulama işlevselliği sağlar. Önceki analitik çözümünde, diğer bulut depolama alanında yaklaşık 40 TB veri olmak üzere toplam 80 TB'ın üzerinde birden fazla veri kopyası vardı. Veriler şirket içinde ve bulutta çeşitli veri depolarında depolandı. Organik olarak büyüyen ekipler, bireysel projeler için teknoloji yığınlarını seçme özgürlüğüne sahipti ve bu da çeşitli araçların, teknolojilerin ve uygulamaların çoğalmasına yol açtı. Kişiselleştirme, hedef kitle, veri mühendisliği, veri bilimi ve analitik için ayrı ekipler, alım, veri işleme ve görselleştirme için çeşitli ürünler kullandı.

Bu gönderi, BMS'nin geçiş ve modernizasyon yolculuğunu ve BMS, AWS ve AWS Çözüm Ortağı'nın nasıl olduğunu tartışıyor Minfy Teknolojileri ekip, geçişi dört ayda başarıyla tamamlamak ve maliyet tasarrufu sağlamak için birlikte çalıştı. Göç ilkelerini kullanarak AWS modern veri mimarisi projeyi büyük bir başarıya dönüştürdü.

Önceki analiz platformundaki zorluklar

• Çeşitli Teknoloji: Birden çok ekip, çeşitli ürünleri, dilleri ve yazılım sürümlerini kullandı.
• Daha Büyük Geçiş Projesi: Analitik modernizasyonu, uygulama geçişiyle paralel bir proje olduğundan, temel uygulamalardaki ve proje zaman çizelgelerindeki değişiklikleri dikkate almak için planlama çok önemliydi.
• Kaynaklar: Uygulama geçiş projesinden kaynak karmaşası yaşandı ve mevcut sistemlerle ilgili çok az belge vardı.
• Veri : Birden fazla veri kopyası vardı ve tek bir gerçek kaynağı yoktu; her veri deposu, iş birimi için bir görünüm sağladı.
• Alım Ardışık Düzenleri: Karmaşık veri ardışık düzenleri, verileri çeşitli veri depolarında çeşitli frekanslarda taşıdı. Tıklama akışları, saklı yordamlar ve Spark işleri için işlem sistemlerinden ve MQTT'den (Message Queue Telemetry Transport mesajlaşma protokolü) 100'den fazla Kafka tüketicisi aracılığıyla Cloudera'ya veri almak için birden fazla yaklaşımımız vardı. Spark, Alteryx, Beam, NiFi ve daha fazlasında veri alımı için yaklaşık 100 işimiz vardı.
• Hadoop Kümeleri: Hadoop kümelerinin sabit maliyetlerle yapılandırıldığı büyük özel donanım. Şirket içi Cloudera kurulumu, veri mühendisliği, hedef kitle ve kişiselleştirme toplu işleme iş yüklerinin çoğunu karşıladı. Ekipler, kitle ve kişiselleştirme uygulamalarımız için HBase ve Hive uygulamalarını gerçekleştirdi.
• Veri ambarı: Veri mühendisliği ekibi, şirket içi veri ambarı olarak TiDB'yi kullandı. Ancak, her tüketici ekibinin analiz için ihtiyaç duyduğu verilere ilişkin kendi bakış açısı vardı. Bu silolu mimari geliştikçe, bu ayrı ortamları korumak için pahalı depolama ve işletim maliyetleri ortaya çıktı.
• Analitik Veritabanı: Analitik ekibi, diğer işlemsel sistemlerden elde edilen verileri ve normal olmayan verileri kullandı. Ekip, Alteryx'i bir görselleştirme aracıyla kullanarak kendi çıkarma, dönüştürme ve yükleme (ETL) boru hattına sahipti.

Proje başarısına yol açan geçiş ilkeleri izlendi:

• İş işlevselliğine göre öncelik verin.
• 1. Günden itibaren modern bir veri mimarisi oluştururken en iyi uygulamaları uygulayın.
• Yalnızca gerekli verileri taşıyın, verileri standartlaştırın ve hedefte en uygun biçimde saklayın. Veri fazlalığını mümkün olduğunca kaldırın. Değişiklikler müdahaleci olduğunda gelecek için optimizasyon kapsamını işaretleyin.
• Veri biçimlerini, birimleri, yönetişimi ve güvenliği göz önünde bulundurarak veri mimarisini oluşturun.
• İşleri yeniden barındırılan, yeniden yazılan ve kullanımdan kaldırılan olarak kategorize ederek ELT ve işleme işlerini basitleştirin. Kanonik veri biçimini, dönüştürmeyi, zenginleştirmeyi, sıkıştırmayı ve depolama biçimini Parquet olarak sonlandırın.
• İşletmeler için kritik önem taşıyan makine öğrenimi (ML) işlerini yeniden barındırın.
• Hedeflerimize ulaşmak için geriye doğru çalışın ve ilerlemek için engelleri kaldırın ve kararları değiştirin.
• İlk seçenek olarak sunucusuz seçenekleri kullanın ve kullanım başına ödeme yapın. Doğru yaklaşımı seçmek için yeniden mimarinin maliyetini ve çabasını değerlendirin. Her bileşen ve hizmet için bunu doğrulamak üzere bir konsept kanıtı yürütün.

Bu geçişte başarılı olmak için uygulanan stratejiler:

• Takımı – Analitik taşıma projesinin bir parçası olarak veri mühendisliği, analitik ve veri biliminden kişilerle birleşik bir ekip oluşturduk. Hizalama için veriler veya zaman çizelgesi ile ilgili kritik kararlar gerektiğinde saha güvenilirlik mühendisliği (SRE) ve uygulama ekipleri dahil edildi. Analitik, veri mühendisliği ve veri bilimi ekipleri, planlama, kodu anlama ve yinelemeli olarak mevcut veri kaynaklarına, veri boru hatlarına ve işleme işlerine bakarak önemli ölçüde zaman harcadı. AWS ekibi ve Minfy Technologies'in iş ortağı ekibi, BMS'nin veri alımı, veri işleme, veri ambarı, makine öğrenimi ve analitik panolarındaki bileşenlerin her biri için bir kavram kanıtının ardından bir geçiş planına ulaşmasına yardımcı oldu.
• Atölyeler – AWS ekibi bir dizi atölye çalışması ve derinlemesine çalışma günleri düzenledi ve analitik hizmetlerini dağıtmaya yönelik teknoloji ve en iyi uygulamalar konusunda BMS ekibine koçluk yaptı. AWS ekibi, BMS'nin kavram kanıtları (POC'ler) aracılığıyla her senaryo (veri geçişi, veri ardışık düzeni, veri işleme, görselleştirme ve makine öğrenimi) için geçiş yaklaşımının yapılandırmasını ve faydalarını keşfetmesine yardımcı oldu. Ekip, geçiş için mevcut kodda gereken değişiklikleri yakaladı. BMS ekibi ayrıca aşağıdaki AWS hizmetleriyle de tanıştı:
• Kavramın ispatı – İş ortağı ve AWS ekibinin yardımıyla BMS ekibi, geçiş yaklaşımını doğrulamak için birden çok kavram kanıtı uyguladı:
  • Çalışma zamanını, gerekli kod değişikliklerini ve maliyeti kontrol ettiğimiz Amazon EMR'de Spark işlerinin toplu işlenmesini gerçekleştirdik.
  • Uçtan uca işlem hattını test ederek Amazon EMR'de tıklama akışı analizi işleri yürüttü. Ekip üzerinde kavram kanıtlamaları gerçekleştirdi AWS IoT Çekirdeği MQTT protokolü ve Amazon S3'e akış için.
  • Makine öğrenimi modelleri Amazon SageMaker'a taşındı ve Amazon MWAA ile düzenlendi.
  • Özelliklerin ve oluşturma süresinin değerlendirildiği örnek QuickSight raporları ve panoları oluşturuldu.
  • Verilerin yüklenmesi, sorgu performansı ve maliyetin değerlendirildiği Amazon Redshift için temel senaryolar için yapılandırılmıştır.
• Çaba ve maliyet analizi – Ekip aşağıdaki değerlendirmeleri gerçekleştirdi:
  • Alım ardışık düzenleri, her bir mağazadaki veri yapısındaki fark, veri kaynağına yönelik mevcut iş ihtiyacının temeli, geçişten önce verileri ön işleme etkinliği, Amazon S3'e veri geçişi ve değişiklik verisi yakalama (CDC) karşılaştırması AWS'de taşınan uygulamalar.
  • Yaklaşık 200 işi taşıma çabası değerlendirildi, hangi işlerin gereksiz olduğu veya işlevsel açıdan iyileştirilmesi gerektiği belirlendi ve hedef durum için bir taşıma listesi tamamlandı. MQTT iş akışı kodunun sunucusuz hale getirilmesi zaman alıcıydı ve şu tarihte yeniden barındırılmasına karar verildi: Amazon Elastik Bilgi İşlem Bulutu (Amazon EC2) ve modernizasyon Amazon Kinesis bir sonraki aşamada.
  • 400'den fazla rapor ve pano gözden geçirildi, geliştirmeye aşamalar halinde öncelik verildi ve iş kullanıcısı gereksinimleri yeniden değerlendirildi.

Önerilen mimari için seçilen AWS bulut hizmetleri:

• veri gölü – Tüm ham ve işlenmiş veriler için tek bir bilgi gerçeğini depolamak üzere veri gölü olarak Amazon S3'ü kullandık, böylece veri depolama ve depolama maliyetlerinin kopyalarını azalttık.
• yeme – Mevcut mimaride birden çok doğruluk kaynağımız olduğundan, Amazon S3'e geçişten önce ortak bir yapıya ulaştık ve ön işleme yapmak için mevcut işlem hatları değiştirildi. Bu tek seferlik ön işleme işleri, kaynak veriler şirket içinde olduğu için Cloudera'da ve buluttaki veriler için Amazon EMR'de çalıştırıldı. AWS Glue ETL kullanarak AWS bulutundaki işlemsel sistemlerden alım için yeni veri hatları tasarladık.
• İşlemde – İşleme işleri, çalışma süresine göre iki kategoriye ayrıldı: toplu ve gerçek zamanlıya yakın. Toplu işlemler ayrıca değişen çalışma sürelerine ve HBase gibi Hadoop uygulama gereksinimlerine sahip geçici Amazon EMR kümelerine ayrıldı. Gerçek zamanlıya yakın işler, tıklama akışı analitiği için bir Amazon EMR kalıcı kümesinde ve işlemsel sistemlerden bir veri ardışık düzeninde sağlandı. AWS bulutundaki işlemsel sistemlerden yeni veri ardışık düzenleri için AWS Glue ETL kullanarak sunucusuz bir yaklaşımı benimsedik.
• Veri deposu – Veri ambarımız olarak Amazon Redshift'i seçtik ve sorgu modellerine göre verilerin nasıl dağıtılacağını planladık.
• Görselleştirme – Amazon QuickSight'ta raporları aşamalı olarak oluşturduk ve iş talebine göre öncelik sırasına koyduk. İş kullanıcılarıyla mevcut ihtiyaçlarını tartıştık ve gerekli acil raporları belirledik. Rapor ve pano oluşturma aşamalarını tanımladık ve raporları Amazon QuickSight'ta oluşturduk. Gelecekte harici kullanıcılar için katıştırılmış raporları kullanmayı planlıyoruz.
• Makine öğrenme – Amazon SageMaker'da özel makine öğrenimi modelleri dağıtıldı. Mevcut Airflow DAG'leri Amazon MWAA'ya taşındı.
• Yönetişim, güvenlik ve uyumluluk – ile yönetişim Amazon Gölü Oluşumu 1. Günden itibaren benimsenmiştir. AWS Glue Data Catalog'u kaynak ve hedef olarak kullanılan verilere referans verecek şekilde yapılandırdık. Ödeme bilgileri veri gölünde olduğu için Ödeme Kartı Endüstrisi (PCI) yönergelerine uymak zorundaydık, dolayısıyla gerekli güvenlik politikalarını sağladık.

Çözüme genel bakış

BMS modern veri mimarisi

Aşağıdaki diyagram, modern veri mimarimizi göstermektedir.

Mimari aşağıdaki bileşenleri içerir:

1. Kaynak sistemler – Bunlar aşağıdakileri içerir:
   • MariaDB'de depolanan işlem sistemlerinden alınan veriler (rezervasyon ve işlemler).
   • Kafka tüketicileri aracılığıyla DataOps MariaDB'ye kullanıcı etkileşimi tıklama akışı verileri.
   • MongoDB'den üyeler ve koltuk tahsisi bilgileri.
   • Belirli teklifler ve ödeme bilgileri için SQL Server.
2. Veri hattı – Bir Amazon EMR kalıcı kümesindeki Spark işleri, Kafka kümelerinden gelen tıklama akışı verilerini işler.
3. veri gölü – Kaynak sistemlerden alınan veriler, optimize edilmiş veri sorgulama için öneklerle ilgili Amazon S3 klasörlerinde depolandı. Amazon S3 için, kaynak ve veri türüne göre ham, özetlenmiş ve ekip veya hizmetle ilgili verileri farklı üst klasörlerde depolamak için bir hiyerarşi izledik. Farklı servislerin log ve temp klasörlerine ekiplerin gereksinimlerine göre yaşam döngüsü politikaları eklendi.
4. Veri işleme – Geçici Amazon EMR kümeleri, verileri hedef kitle, kişiselleştirme ve analiz ekipleri için seçilmiş bir biçimde işlemek için kullanılır. Küçük dosya birleştirme işleri, tıklama verilerini daha büyük bir dosya boyutuna birleştirir ve bu da tek seferlik sorgular için maliyet tasarrufu sağlar.
5. Yönetim – AWS Lake Formation, veri gölünde depolanan verilerin şemasını ve şemadaki sürüm değişikliklerini yakalamak için AWS Glue tarayıcılarının kullanımına olanak tanır. AWS Lake Formation'daki Veri Kataloğu ve güvenlik ilkesi; Amazon Redshift, Amazon Athena, Amazon QuickSight ve veri bilimi işlerindeki roller ve kullanıcılar için verilere erişim sağlar. AWS Glue ETL işleri, işlenen verileri planlanmış aralıklarla Amazon Redshift'e yükler.
6. Sorguları – Analitik ekibi, veri gölündeki iş ekiplerinden gelen tek seferlik sorguları gerçekleştirmek için Amazon Athena'yı kullandı. Rapor geliştirme aşamalı olduğundan, verilerin dışa aktarılması için Amazon Athena kullanıldı.
7. Veri deposu – Amazon Redshift, satış ekipleri, yönetim ve üçüncü taraflar (ör. tiyatrolar ve etkinlikler) için raporların işlendiği ve hızlı erişim için saklandığı veri ambarı olarak kullanıldı. Toplam satışları, film satış eğilimlerini, üye davranışını ve ödeme modlarını analiz etmek için görünümler burada yapılandırılır. Denormalize tablolar için gerçekleştirilmiş görünümler, meta veriler için farklı şemalar ve işlem ve davranış verileri kullanıyoruz.
8. Raporlar – Çeşitli işletme, pazarlama ve ürün kullanım senaryoları için Amazon QuickSight raporlarını kullandık.
9. Makine öğrenme – Amazon SageMaker'da dağıtılan modellerden bazıları şunlardır:
   • İçerik popülerliği – Kullanıcılar için önerilen içeriğe karar verir.
   • Canlı etkinlik popülerliği – Canlı eğlence etkinliklerinin farklı bölgelerdeki popülaritesini hesaplar.
   • Trend olan aramalar – Bölgeler arasında trend olan aramaları tanımlar.

Walkthrough

Geçiş yürütme adımları

Veri mühendisliği, analitik ve veri bilimi için araçları, hizmetleri ve süreçleri standart hale getirdik:

• veri gölü
  • Archival DB, BigQuery, TiDB ve analitik veritabanından taşınacak kaynak verileri tanımladı.
  • Birden çok iş ekibine hitap eden ve verilerin kopyalarını ve dolayısıyla depolama ve işletme maliyetlerini azaltan standart bir veri modeli oluşturun. Standart bir biçime geçişi kolaylaştırmak için mevcut işler değiştirildi.
  • Kaynak sistemleri, gereken kapasiteyi, beklenen büyümeyi, sahipleri ve erişim gereksinimlerini belirledi.
  • Çeşitli kaynaklardan Amazon S3'e toplu veri taşıma işlemini gerçekleştirin.
• yeme
  • İşlem sistemleri – Mevcut Kafka kuyruklarını ve tüketicilerini korudu.
  • Tıklama akışı verileri – MQTT protokolü için AWS IoT Core'u kullanmak üzere bir konsept kanıtı başarıyla gerçekleştirildi. Ancak AWS IoT Core'da yayınlamak için uygulamada değişiklikler yapmamız gerektiğinden, bunu daha sonra mobil uygulama modernizasyonunun bir parçası olarak uygulamaya karar verdik. MQTT sunucusunu Amazon EC2'de yeniden barındırmaya karar verdik.
• İşlemde
• İşle ilgili veri boru hatlarını listeledi ve bunları minimum değişiklikle taşıdı.
• İş yüklerini kritik işler, gereksiz işler veya optimize edilebilecek işler olarak kategorize edin:
  • Spark işleri Amazon EMR'ye taşındı.
  • HBase işleri, HBase ile Amazon EMR'ye taşındı.
  • Hive tabanlı işlerde depolanan meta veriler, AWS Glue Data Catalog'u kullanacak şekilde değiştirildi.
  • NiFi işleri, Amazon EMR'de çalıştırılan Spark'ta basitleştirildi ve yeniden yazıldı.
• Amazon EMR kümeleri, tıklama akışı ve kişiselleştirme iş yüklerinin akışı için tek bir kalıcı küme olarak yapılandırıldı. Diğer tüm Spark ETL'lerini çalıştırmak veya işleri işlemek için birden çok geçici küme kullandık. Maliyetlerden tasarruf etmek için görev düğümleri için Spot Bulut Sunucuları kullandık. Küçük dosyaları ve sıkıştırılmış dosya biçimi dönüştürmelerini birleştirmek için veri depolamayı belirli işlerle optimize ettik.
• AWS Glue tarayıcıları, Amazon S3'te yeni veriler belirledi. AWS Glue ETL işleri dönüştürüldü ve işlenen verileri Amazon Redshift veri ambarına yükledi.
• Veri deposu
  • İşletmenin ihtiyaç duyduğu kritik raporları, iş yükü ve gelecekte ihtiyaç duyulacak raporları göz önünde bulundurarak kategorize ederek veri ambarı şemasını tanımladı.
  • Amazon Redshift'e yüklenen artımlı veriler, somutlaştırılmış görünümler ve kullanıma göre sorguları ayarlamak için hazırlama alanını tanımladı. İşlem ve birincil meta veriler, tüm veri analizi ve raporlama gereksinimlerini karşılamak için Amazon Redshift'te depolanır. Sırasıyla Amazon QuickSight gösterge panoları ve segmentasyon işleri için veri kaynağı olarak kullanmak üzere Amazon Redshift'te somutlaştırılmış görünümler ve denormalize edilmiş tablolar oluşturduk.
  • Son iki yılın verilerini Amazon Redshift'e yükleyerek Amazon Redshift kümesini en iyi şekilde kullandı ve kullanıldı Amazon Kırmızıya Kaydırma Spektrumu geçmiş verileri harici tablolar aracılığıyla sorgulamak için. Bu, Amazon Redshift kümesinin kullanım ve maliyetinin dengelenmesine yardımcı oldu.
• Görüntüleme
  • 1. Aşamada satış ve pazarlama ekibi için Amazon QuickSight panoları oluşturuldu:
    • Satış özeti raporu – Bölge, şehir, sinema, tiyatro, tür ve daha fazlasına göre ülke çapındaki satışlara genel bir bakış elde etmek için bir yönetici özeti panosu.
    • Canlı eğlence – Canlı eğlence dikey etkinlikleri için özel bir rapor.
    • Kuponlar – Satın alınan ve kullanılan kuponlar için bir rapor.
    • KitapASmile – Bir hayır kurumu girişimi olan BookASmile için verileri analiz etmek için bir pano.
• Makine öğrenme
  • Mevcut iş gereksinimlerine göre taşınacak makine öğrenimi iş yüklerini listeledi.
  • Öncelikli makine öğrenimi işleme işleri, Amazon EMR'de devreye alındı. Modeller, kaynak ve hedef olarak Amazon S3'ü kullanacak şekilde değiştirildi ve işlevselliği kullanmak için yeni API'ler kullanıma sunuldu. Filmler, canlı etkinlik tıklama akışı analizi ve kişiselleştirme için Amazon SageMaker'da makine öğrenimi modelleri devreye alındı.
  • Airflow düzenlemesindeki mevcut yapılar Amazon MWAA'ya taşındı.
• Güvenlik
  • AWS Lake Formation, Amazon S3'te depolanan veriler için merkezi kataloğun temeli olan AWS Glue Data Catalog ile veri gölünün temeliydi. Bu, izleyici, kişiselleştirme, analitik ve veri bilimi ekipleri dahil olmak üzere çeşitli işlevler tarafından verilere erişim sağladı.
  • Kişisel olarak tanımlanabilir bilgiler (PII) ve ödeme verileri veri gölünde ve veri ambarında saklanıyordu, bu nedenle PCI yönergelerine uymamız gerekiyordu. Bekleyen ve aktarılan verilerin şifrelenmesi, her hizmet düzeyinde (Amazon S3, AWS Glue Data Catalog, Amazon EMR, AWS Glue, Amazon Redshift ve QuickSight) düşünüldü ve yapılandırıldı. Farklı kullanıcı grupları ve ayrıcalıklar için net roller, sorumluluklar ve erişim izinleri şu adreste listelendi ve yapılandırıldı: AWS Kimlik ve Erişim Yönetimi (IAM) ve bireysel hizmetler.
  • Amazon QuickSight kullanıcı erişimi için Microsoft Active Directory ile mevcut çoklu oturum açma (SSO) entegrasyonu kullanıldı.
• Otomasyon
  • Kullandığımız AWS CloudFormation tüm çekirdek ve analitik hizmetlerinin oluşturulması ve değiştirilmesi için.
  • Amazon EMR'de Spark işlerini düzenlemek için AWS Step Functions kullanıldı.
  • Planlanmış işler, iş gereksinimlerine göre Amazon Redshift'e veri yüklemek için AWS Glue'da yapılandırıldı.
  • Analitik hizmetlerinin izlenmesi, Amazon Bulut İzleme metrikler ve örneklerin ve yapılandırmanın doğru boyutlandırılması sağlandı. Amazon EMR'deki Spark işi performansı, yerel Spark günlükleri ve Spark kullanıcı arabirimi (UI) kullanılarak analiz edildi.
  • Zaman içinde veri depolama maliyetlerini optimize etmek için veri gölüne yaşam döngüsü ilkeleri uygulandı.

Modern bir veri mimarisinin faydaları

Modern bir veri mimarisi bize aşağıdaki avantajları sağladı:

• ölçeklenebilirlik – Sabit bir altyapıdan, talep üzerine ölçeklendirmeye yönelik yapılandırma ile gereken minimum altyapıya geçtik. Amazon EMR ve Amazon Redshift gibi hizmetler, bunu yalnızca birkaç tıklamayla yapmamızı sağlıyor.
• Çeviklik – Tekerleği yeniden icat etmek yerine amaca yönelik yönetilen hizmetler kullanıyoruz. Otomasyon ve izleme, hızlı bir şekilde değişiklik yapmamızı sağlayan temel hususlardı.
• Serverless – Amazon S3, AWS Glue, Amazon Athena, AWS Step Functions gibi sunucusuz hizmetlerin benimsenmesi ve AWS Lambda Yeni filmler veya başlatılan etkinliklerle işimizde ani artışlar olduğunda bizi destekleyin.
• Tasarruf – Depo büyüklüğümüz %90 oranında küçültüldü. Analitik ve makine öğrenimine yönelik toplam harcamamız %80 oranında azaldı.

Sonuç

Bu gönderide, size AWS'deki modern bir veri mimarisinin BMS'nin verileri kurumsal sınırlar arasında kolayca paylaşmasına nasıl yardımcı olduğunu gösterdik. Bu, BMS'nin geniş ölçekte hız ve çeviklikle kararlar almasına izin verdi; birleşik veri erişimi, güvenlik ve yönetişim yoluyla uyumluluğu sağlayın; performanstan ödün vermeden sistemleri düşük maliyetle ölçeklendirmek. AWS ve Minfy Technologies ekipleriyle birlikte çalışmak, BMS'nin doğru teknoloji hizmetlerini seçmesine ve geçişi dört ayda tamamlamasına yardımcı oldu. BMS, grafik veritabanlarını kullanarak inovasyona zemin hazırlayan ve müşteri deneyimini iyileştirmek için makine öğrenimi projelerimizi geliştiren bu güncellenmiş mimari ile ölçeklenebilirlik ve maliyet optimizasyonu hedeflerine ulaştı.

Yazarlar Hakkında

Mahesh Vandi Chalil Hindistan'ın önde gelen eğlence merkezi BookMyShow'da Baş Teknoloji Sorumlusu. Mahesh, yirmi yılı aşkın bir küresel deneyime sahiptir ve müşterileri memnun eden ölçeklenebilir ürünler oluşturma konusunda tutkuluyken inovasyonu en büyük hedef olarak tutar ve ekibini sürekli olarak bunları hedeflemeye motive eder. Mahesh, enerjisini hem kurum içinde hem de dışında gelecek nesil teknoloji liderleri ve girişimcileri yaratmaya ve beslemeye harcıyor. Gururlu bir koca ve iki kız babası ve boş zamanlarında kriket oynuyor.

Priya Jathar AWS'de Dijital Yerel İş segmentinde çalışan bir Çözüm Mimarıdır. Uygulama Geliştirme, Veritabanı ve Analitik alanlarındaki uzmanlığıyla birlikte yirmi yılı aşkın BT deneyimine sahiptir. İş hedeflerine ulaşmak için yeni teknolojilerle yenilik yapmaktan hoşlanan bir inşaatçıdır. Şu anda müşterilerin Bulutta Geçiş Yapmasına, Modernleştirmesine ve Yenilik Yapmasına yardımcı oluyor. Boş zamanlarında resim yapmayı ve bahçıvanlık ve yemek pişirme becerilerini geliştirmeyi seviyor.

Vatsal Şah Mumbai, Hindistan merkezli AWS'de Kıdemli Çözüm Mimarıdır. Ürün mühendisliği, SRE ve bulut mimarisinde liderlik rolleri de dahil olmak üzere dokuz yıldan fazla endüstri deneyimine sahiptir. Şu anda, büyük girişimlerin bulut operasyonlarını kolaylaştırmasına ve bulutta ölçeklendirmelerine yardımcı olmaya odaklanıyor. Ayrıca yapay zeka ve Makine Öğrenimi kullanım durumlarında uzmanlaşmıştır.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/big-data/how-bookmyshow-saved-80-in-costs-by-migrating-to-an-aws-modern-data-architecture/