Bu, Belcorp'ta Veri Mimarisi Direktörü Kıdemli Veri Mimarları'ndan Diego Benavides ve Luis Bendezú'nun konuk yazısıdır.

Belcorp, Kuzey, Orta ve Güney Amerika'da (AMER) yaklaşık 50 ülkeye tahsis edilmiş, 13 yılı aşkın süredir bölgede kozmetik ürünleri sağlayan ana ambalajlı tüketim malları (CPG) şirketlerinden biridir. Peru'da doğan ve kendi ürün fabrikası Kolombiya'da bulunan Belcorp, her zaman eğrinin önünde kaldı ve iş modelini müşteri ihtiyaçlarına göre uyarladı ve stratejisini teknolojik trendlerle güçlendirerek her seferinde daha iyi bir müşteri deneyimi sağladı. Buna odaklanan Belcorp, karar verme için verilerin kullanımını teşvik eden kendi veri stratejisini uygulamaya başladı. Bu stratejiye dayalı olarak, Belcorp veri mimarisi ekibi, iş ve analitik ekiplerinin daha iyi pazarlama stratejilerinde veya yeni ürünlerde hayata geçirilen hipotezler ve öngörüler oluşturmak için kullandıkları işlevsel verileri tüketmelerine olanak tanıyan bir veri ekosistemi tasarladı ve uyguladı. Bu gönderi, 2021'nin sonunda rapor edilen platform olaylarının sayısını azaltmak, işletmenin gerektirdiği SLA'ları optimize etmek ve Amazon EMR kullanırken daha düşük maliyetli olmak için 2020 boyunca gerçekleştirilen bir dizi sürekli iyileştirmeyi detaylandırmayı amaçlıyor. şirket için %30'a varan tasarruf.

Eğrinin önünde kalmak için, daha güçlü şirketler, ana iş stratejilerini geliştirmelerine ve hatta verileri ana itici güç olarak kullanarak yenilerini oluşturmalarına olanak tanıyan bir veri stratejisi oluşturdu. Bölgedeki ana paketlenmiş tüketici ürünleri (CPG) şirketlerinden biri olarak Belcorp bir istisna değildir; son yıllarda veriye dayalı karar verme sürecini uygulamak için çalışıyoruz.

Tüm iyi veri stratejilerinin iş hedefleriyle uyumlu olduğunu ve ana iş kullanım durumlarına dayandığını biliyoruz. Şu anda, tüm ekip çabalarımız nihai tüketicilere odaklanmıştır ve neredeyse tüm iş girişimleri hiper kişiselleştirme, fiyatlandırma ve müşteri katılımı ile ilgilidir.

Bu girişimleri desteklemek için veri mimarisi departmanı, veri entegrasyonu, yalnızca tek bir doğruluk kaynağı, veri yönetişimi ve veri kalitesi çerçeveleri, veri kullanılabilirliği, veri erişilebilirliği ve optimize edilmiş pazara sunma süresi gibi veri hizmetleri sağlar. büyük şirketler. Tüm bu hizmetleri destekleyecek minimum yetenekler sağlamak için ölçeklenebilir, esnek ve uygun maliyetli bir veri ekosistemine ihtiyacımız vardı. Belcorp bu maceraya birkaç yıl önce aşağıdakiler gibi AWS hizmetlerini kullanarak başladı: Amazon Elastik Bilgi İşlem Bulutu (Amazon EC2), AWS Lambda, AWS Fargate, Amazon EMR'si, Amazon DinamoDB, ve Amazon Kırmızıya Kaydırmaşu anda ana analitik çözümlerimizi verilerle besleyen .

Büyüdükçe, veri hacmi ve daha karmaşık veri çözümü gereksinimleri açısından mimari tasarımımızı ve işleme çerçevemizi sürekli olarak geliştirmek zorundaydık. Ayrıca veri bütünlüğünü, veri kalitesini ve hizmet düzeyi anlaşmalarını (SLA'lar) garanti altına almak için kalite ve izleme çerçevelerini benimsememiz gerekiyordu. Tahmin edebileceğiniz gibi, bu kolay bir iş değil ve kendi stratejisini gerektiriyor. 2021'in başında ve tespit ettiğimiz kritik olaylar nedeniyle operasyonel istikrar etkilendi ve iş sonuçlarını doğrudan etkiledi. Dahil edilen daha karmaşık iş yükleri nedeniyle faturalandırma da etkilendi ve bu da platform maliyetlerinde beklenmedik bir artışa neden oldu. Yanıt olarak, üç zorluğa odaklanmaya karar verdik:

• Operasyonel kararlılık
• Maliyet etkinliği
• Hizmet Seviyesi Anlaşmaları

Bu gönderi, 2021'de Belcorp'un Amazon EMR'ye dayalı veri işleme çerçevesi üzerinden gerçekleştirdiğimiz bazı eylem noktalarını detaylandırıyor. Ayrıca bu eylemlerin daha önce bahsedilen zorluklarla yüzleşmemize nasıl yardımcı olduğunu ve veri mimarisi ekibinin şirkete ana katkısı olan Belcorp'a ekonomik tasarruf sağladığını da tartışıyoruz.

Çözüme genel bakış

Belcorp'un veri ekosistemi, mimari tasarımımızı tanımlayan ve bize az çok teknolojik esnek seçenekler sunan yedi temel yetenek sütunundan (aşağıdaki şemada gösterildiği gibi) oluşur. Veri platformumuz, Zhamak Dehghani tarafından şu yazıda belirtildiği gibi, ikinci nesil veri platformlarının bir parçası olarak sınıflandırılabilir. Monolitik Veri Gölünün Ötesine Dağıtılmış Bir Veri Meshine Nasıl Geçilir?. Aslında, makalede belirtildiği gibi bir Lakehouse yaklaşımının tüm sınırlamalarına ve kısıtlamalarına sahiptir. Lakehouse: Veri Ambarı ile Gelişmiş Analitiği Birleştiren Yeni Nesil Açık Platformlar .

Belcorp'un veri platformu iki ana kullanım durumunu destekler. Bir yandan, verilerin görselleştirme araçları kullanılarak tüketilmesini sağlayarak self servisi teşvik eder. Öte yandan, veri bilimcileri veya veri analistleri gibi son kullanıcılara, gelişmiş analitik uygulamalara daha uygun dağıtılmış veri ambarları ve nesne depolama aracılığıyla işlevsel veriler sağlar.

Aşağıdaki referans tasarımı, bu kullanım durumları için işlevsel veriler sağlamaktan sorumlu ana iki katmanı açıklamaktadır. Veri işleme katmanı iki alt katmandan oluşmaktadır. Birincisi, analitik havuzlarındaki tüm veri iş yüklerini ve veri aşamalarını düzenlemekten sorumlu bir dizi API REST hizmetine sahip yerleşik, şirket içi bir Python çözümü olan Belcorp'un Data Lake Integrator'ıdır. Ayrıca her Amazon EMR Spark işi için ayrılacak kaynakları dağıtmak için bir kontrol noktası olarak da çalışır. İşleme alt katmanı esas olarak, bir Scala çerçevesi kullanılarak geliştirilen tüm Spark işlerini düzenlemek, izlemek ve sürdürmekten sorumlu olan EMR kümesinden oluşur.

Kalıcı depo katmanı için kullanıyoruz Amazon Basit Depolama Hizmeti (Amazon S3), referans mimari tasarımına dayalı olarak operasyonel ve işlevsel amaçlara sahip bir dizi veri aşaması tasarladığımız analitik iş yükleri için bir veri deposu olarak nesne depolama. Depo tasarımını daha derinlemesine tartışmak bu yazının kapsamı dışındadır, ancak bunun veri kullanılabilirliği, veri erişilebilirliği, veri tutarlılığı ve veri kalitesi ile ilgili tüm ortak zorlukları kapsadığını unutmamalıyız. Ayrıca, daha önce bahsedilen tasarımın bize miras bıraktığı tüm sınırlamalara ve kısıtlamalara rağmen, iş modelinin gerektirdiği tüm Belcorp ihtiyaçlarını karşılar.

Artık dikkatimizi bu yazının asıl amacına çevirebiliriz.

Bahsettiğimiz gibi, 2021'in başında kritik olaylar (bazıları daha önce de vardı) ve beklenmedik maliyet artışları yaşadık ve bu da bizi harekete geçmeye motive etti. Aşağıdaki tablo, dikkatimizi çeken bazı ana konuları listelemektedir.

Bu sorunlarla yüzleşmek için stratejileri değiştirmeye karar verdik ve nedenini belirlemek için her sorunu analiz etmeye başladık. Liderlerin üzerinde çalışmamızı istediği üç zorluğa dayalı iki eylem çizgisi belirledik. Aşağıdaki şekil bu çizgileri ve zorlukları özetlemektedir.

Veri gölü mimarisi eylem satırı, olayları oluşturan ana sorunların bir parçası olarak belirlediğimiz tüm mimari boşlukları ve kullanımdan kaldırılmış özellikleri ifade eder. Spark geliştirme en iyi uygulamaları eylem satırı, geliştirme yaşam döngüsü sırasında kötü uygulamalar nedeniyle kararsızlığa neden olan geliştirilmiş Spark veri çözümüyle ilgilidir. Bu eylem hatlarına odaklanan liderlerimiz, olay sayısını azaltmak ve sunduğumuz hizmetin kalitesini garanti altına almak için üç zorluk tanımladı: operasyonel istikrar, maliyet verimliliği ve SLA'lar.

Bu zorluklara dayanarak, projenin başarısını ölçmek için üç KPI tanımladık. Jira olayları, değişikliklerimizin olumlu bir etkisi olduğunu doğrulamamızı sağlar; haftalık faturalandırma, liderlere uyguladığımız değişikliklerin bir kısmının maliyeti kademeli olarak optimize edeceğini gösteriyor; ve çalışma zamanı, iş kullanıcılarına pazarlamak için daha iyi bir zaman sağlar.

Ardından, sonraki adımları ve ilerlemenin nasıl ölçüleceğini tanımladık. İzleme çerçevemize dayanarak, ortaya çıkan neredeyse tüm olayların veri işleme ve kalıcı veri havuzu katmanlarıyla ilgili olduğunu belirledik. Sonra onları nasıl çözeceğimize karar vermeliydik. Operasyonel istikrarı sağlamak ve iş üzerinde bir etki yaratmamak için reaktif düzeltmeler yapabilir veya olağan çalışma şeklimizi değiştirebilir, her sorunu analiz edebilir ve çerçevemizi optimize etmek için nihai bir çözüm sağlayabiliriz. Tahmin edebileceğiniz gibi, çalışma şeklimizi değiştirmeye karar verdik.

Ana etkileri ve zorlukları belirlemek için bir ön analiz gerçekleştirdik. Ardından, eylem satırlarımıza dayalı olarak aşağıdaki eylemleri ve iyileştirmeleri önerdik:

• Veri gölü mimarisi – EMR kümesini yeniden tasarladık; şimdi çekirdek ve görev düğümlerini kullanıyoruz
• Kıvılcım geliştirme en iyi uygulamaları – Spark parametrelerini optimize ettik (RAM belleği, çekirdekler, CPU'lar ve yürütücü numarası)

Bir sonraki bölümde, hedeflerimize ulaşmak için önerilen eylemleri ve iyileştirmeleri ayrıntılı olarak açıklıyoruz.

Eylemler ve iyileştirmeler

Önceki bölümde bahsettiğimiz gibi, mimari ekip tarafından yapılan analiz, üç zorlukla yüzleşmemize yardımcı olacak bir eylemler ve iyileştirmeler listesiyle sonuçlandı: operasyonel kararlılık, düşük maliyetli bir veri ekosistemi ve SLA'lar.

Daha ileri gitmeden önce, Belcorp veri işleme çerçevesi hakkında daha fazla ayrıntı vermenin tam zamanı. Scala programlama dilini kullanarak Apache Spark'ı temel alarak oluşturduk. Veri işleme çerçevemiz, geliştirme ekiplerine karmaşık veri ardışık düzenlerini uygulamak için güçlü bir araç sağlayan ve Apache Spark teknolojisini kullanarak en karmaşık iş gereksinimlerini karşılayan bir dizi ölçeklenebilir, parametrelenebilir ve yeniden kullanılabilir Scala yapıtından oluşur. Belcorp DevOps çerçevesi aracılığıyla, her yapıtı birkaç üretim dışı ortama dağıtıyoruz. Ardından, EMR kümesinin analitik platform içindeki her bir kavramsal alana başvuruda bulunan Scala yapılarını kullanarak tüm rutinleri başlattığı üretime geçiyoruz. Döngünün bu kısmı, ekiplere bir dereceye kadar esneklik ve çeviklik sağlar. Ancak bir an için Apache Spark teknolojisini kullanarak geliştirdiğimiz yazılımın kalitesini unuttuk.

Bu bölümde, Belcorp veri işleme çerçevesini optimize etmek ve mimariyi iyileştirmek için uyguladığımız eylemlere ve iyileştirmelere giriyoruz.

EMR kümesini yeniden tasarlama

Belcorp veri gölünün mevcut tasarımı ve uygulaması ilk versiyon değil. Şu anda sürüm 2.0'dayız ve ilk uygulamanın başlangıcından bugüne kadar, veri işleme katmanını uygulamak için farklı EMR küme tasarımları denedik. Başlangıçta, dört düğümlü sabit bir küme kullandık (aşağıdaki şekilde gösterildiği gibi), ancak otomatik ölçeklendirme özelliği başlatıldığında ve Belcorp'un veri iş yükleri arttığında, kaynak kullanımını ve maliyetleri optimize etmek için onu oraya taşımaya karar verdik. Ancak, otomatik olarak ölçeklenen bir EMR kümesinin de farklı seçenekleri vardır. Her birinin minimum ve maksimum sayısıyla çekirdek ve görev düğümleri arasında seçim yapabilirsiniz. Ayrıca, İsteğe Bağlı veya Spot Bulut Sunucularını seçebilirsiniz. Spot Bulut Sunucusu kaybı olasılığını azaltmak için EMR bulut sunucusu filolarını kullanarak optimize edilmiş bir tahsis stratejisi de uygulayabilirsiniz. Amazon EMR kaynak tahsis stratejileri hakkında daha fazla bilgi için bkz. Amazon EMR'de esneklik ve dayanıklılık için kıvılcım geliştirmeleri ve Kapasitesi optimize edilmiş Spot Bulut Sunucuları ile dayanıklılık ve maliyet için Amazon EMR'yi optimize etme.

Tüm bu yetenekleri test ettik, ancak bazı sorunlar bulduk.

İlk olarak, AWS, Amazon EMR ile ilgili birçok yetenek ve işlevsellik sunsa da, kullanmak istediğiniz teknoloji hakkında bir dereceye kadar bilginiz yoksa, kullanım örnekleri ortaya çıktıkça birçok sorunla karşılaşabilirsiniz. Bahsettiğimiz gibi Belcorp veri ekosisteminin bir parçası olarak Amazon EMR üzerinden Apache Spark veri işleme motorunu kullanmaya karar verdik ancak birçok sorunla karşılaştık. Ne zaman bir olay ortaya çıksa, operasyonel ve destek görevlerinin bir parçası olarak, sorumlu veri mimarı ekibini onu düzeltmek için motive etti. Neredeyse tüm bu reaktif düzeltmeler, bu olayları verimli bir şekilde çözmek için farklı alternatifleri denemek için Amazon EMR yapılandırmasının değiştirilmesiyle ilgiliydi.

Neredeyse tüm olayların kaynak tahsisi ile ilgili olduğunu anladık, bu nedenle örnek türleri, düğüm sayısını artırma, otomatik ölçeklendirme için özelleştirilmiş kurallar ve filo stratejileri gibi birçok yapılandırma seçeneğini test ettik. Bu son seçenek, düğüm kaybını azaltmak için kullanıldı. 2020'nin sonunda, 24/7 minimum üç İsteğe Bağlı çekirdek düğüm kapasitesi ve 25'e kadar İsteğe Bağlı çekirdek düğümü ölçeklendirme yeteneğiyle etkinleştirilen otomatik ölçeklendirmeye sahip bir EMR kümesinin bize istikrarlı bir veri işleme sağladığını doğruladık. platform. 2021'in başında, EMR kümesi içindeki veri işleme rutinlerinin bir parçası olarak daha karmaşık Spark işleri dağıtıldı ve bu da tekrar operasyonel istikrarsızlığa neden oldu. Ayrıca, faturalandırma beklenmedik bir şekilde artıyordu ve bu durum, sağlıklı operasyonel istikrarı korumak ve maliyetleri optimize etmek için ekiplerinin EMR kümesini yeniden tasarlaması gereken liderleri uyardı.

Kısa süre sonra, tüm çekirdek düğümleri İsteğe Bağlı tüketimde tutmak yerine Spot Bulut Sunucularını kullanarak mevcut faturalandırmanın %40'ına kadar azaltmanın mümkün olduğunu fark ettik. Uygulamak istediğimiz başka bir altyapı optimizasyonu, bir dizi çekirdek düğümü görev düğümleriyle değiştirmekti, çünkü neredeyse tüm Belcorp veri iş yükleri bellek yoğundur ve kaynak verileri okumak ve sonuç veri kümesini yazmak için Amazon S3'ü kullanır. Buradaki soru, mevcut tasarımın faydalarını kaybetmeden bunun nasıl yapılacağıydı. Bu soruyu yanıtlamak için, aşağıdakilerle ilgili soruları açıklığa kavuşturmak için AWS Hesap Ekibimiz ve AWS Analytics ve Büyük Veri Uzmanı YG'mizden rehberlik aldık:

• Amazon EMR'de Apache Spark uygulaması
• Üretim ortamları için çekirdek ve görev düğümü en iyi uygulamaları
• Amazon EMR'de Spot Bulut Sunucusu davranışı

Herhangi bir değişikliği uygulamadan önce kesinlikle bu üç ana noktayı ele almanızı öneririz çünkü önceki deneyimlerimize göre karanlıkta değişiklik yapmak maliyetli ve düşük performans gösteren Amazon EMR uygulamasına yol açabilir. Bunu akılda tutarak, EMR kümesini kullanmak için yeniden tasarladık. EMR tarafından yönetilen ölçeklendirme, mümkün olan en düşük maliyetle en iyi performans için kümenizi otomatik olarak yeniden boyutlandırır. Gün boyunca veri iş yüklerini desteklemek için her zaman açık olan (28/24) üç İsteğe Bağlı çekirdek düğüme sahip maksimum 7 kapasite birimi tanımladık. Ardından, Spot Bulut Sunucularından oluşan kalan 22 görev düğümünü desteklemek için minimum HDFS yetenekleri sağlamak için altı İsteğe Bağlı çekirdekten oluşan bir otomatik ölçeklendirme sınırı belirledik. Bu son yapılandırma, 1:6 oranını koruyarak altı görev düğümünü desteklemek için en az bir çekirdek düğümümüz olduğuna dair AWS uzmanlarının tavsiyelerine dayanmaktadır. Aşağıdaki tablo küme tasarımımızı özetlemektedir.

Aşağıdaki şekil, güncellenmiş ve mevcut küme tasarımımızı göstermektedir.

Spark parametrelerini ayarlama

hakkında herhangi bir iyi kitap olarak Apache Spark Size şunu söyleyebilirim, Spark parametre ayarı, bir Spark uygulamasını üretimde dağıtmadan önce incelemeniz gereken ana konudur.

Spark parametrelerini ayarlamak, her Spark uygulaması için kaynakları (CPU'lar, bellek ve yürütücü sayısı) ayarlama görevidir. Bu gönderide, sürücü örneği kaynaklarına odaklanmıyoruz; uygulayıcılara odaklanıyoruz çünkü Belcorp'un uygulamasında bulduğumuz ana sorun bu.

Spark uygulama geliştirmede birleştirme işlemi ve önbellek stratejileriyle ilgili iyileştirmeler uyguladıktan sonra, bu uygulamalardan bazılarının EMR kümesinde fazla tahmin edilen kaynaklarla atandığını fark ettik. Bu, Spark uygulamalarının kaynaklara atandığı, ancak kaynakların yalnızca %30'unun kullanıldığı anlamına gelir. Aşağıdaki Ganglia raporu, testlerimizden biri sırasında yakaladığımız bir Spark uygulama işi için kaynak tahsisinin fazla tahminini göstermektedir.

Bu davranışın büyük bir sonucu, doğru şekilde kullanılmayan EMR düğümlerinin büyük çapta konuşlandırılmasıydı. Bu, bir Spark uygulaması gönderiminin gerektirdiği otomatik ölçeklendirme özelliği nedeniyle çok sayıda düğümün sağlandığı, ancak bu düğümlerin kaynaklarının çoğunun ücretsiz tutulduğu anlamına gelir. Bunun temel bir örneğini bu bölümde daha sonra göstereceğiz.

Bu kanıtla, bazı Spark uygulamalarımızın Spark parametrelerini ayarlamamız gerektiğinden şüphelenmeye başladık.

Önceki bölümlerde bahsettiğimiz gibi, Belcorp veri ekosisteminin bir parçası olarak, ana sorumluluğu her Spark uygulamasının çalıştırmalarının merkezi kontrolünü sürdürmek olan bir Data Pipelines Integrator oluşturduk. Bunu yapmak için Spark parametre yapılandırmasını içeren bir JSON dosyası kullanır ve her birini gerçekleştirir. spark-submit aşağıdaki örnek kodda gösterildiği gibi Livy hizmetini kullanarak:

'/usr/lib/spark/bin/spark-submit' '--class' 'LoadToFunctional' '--conf' 'spark.executor.instances=62' '--conf' 'spark.executor.memory=17g' '--conf' 'spark.yarn.maxAppAttempts=2' '--conf' 'spark.submit.deployMode=cluster' '--conf' 'spark.master=yarn' '--conf' 'spark.executor.cores=5' 's3://<bucket-name>/FunctionalLayer.jar' '--system' 'CM' '--country' 'PE' '--current_step' 'functional' '--attempts' '1' '--ingest_attributes' '{"FileFormat": "zip", "environment": "PRD", "request_origin": "datalake_integrator", "next_step": "load-redshift"}' '--fileFormat' 'zip' '--next_step' 'load-redshift'

Bu JSON dosyası, EMR kümesine gönderdiğimiz bir dahili sistem ve ülkeyle ilgili her Spark uygulamasının Spark parametre yapılandırmasını içerir. Aşağıdaki örnekte, CM sistemin adıdır ve PE, verilerin geldiği ülke kodudur:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 15, "executorMemory": "45g", "numExecutors": 50 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Bu yaklaşımla ilgili sorun, daha fazla uygulama ekledikçe, bu yapılandırma dosyalarının yönetiminin daha karmaşık hale gelmesidir. Ayrıca, uzun zaman önce iş yüklerinin daha ucuz olduğu zamanlarda tanımlanan varsayılan bir yapılandırmayla ayarlanmış çok sayıda Spark uygulamamız vardı. Dolayısıyla bazı şeylerin değişmesi bekleniyordu. Kalibre edilmemiş parametrelere sahip bir Spark uygulaması örneği aşağıdaki şekilde gösterilmektedir (sadece örnek için dört yürütücü örneği kullanıyoruz). Bu örnekte, Spark'ın en iyi uygulamalarından hiçbirini izlemeden yürütücülere çok fazla kaynak ayırdığımızı fark ettik. Bu, sağlanmasına neden oluyordu şişman uygulayıcılar (Spark argo kullanarak) bunların her birini en az bir düğümde tahsis etmek. Bunun anlamı, 10 yürütücü kullanılarak gönderilecek bir Spark uygulaması tanımlarsak, kümenin en az 10 düğümüne ihtiyacımız olur ve yalnızca bir çalıştırma için 10 düğüm kullanırız ki bu bizim için çok pahalıydı.

Spark parametre ayarlama zorluklarıyla uğraşırken, uzman tavsiyelerine uymak her zaman iyi bir fikirdir. Belki de en önemli tavsiyelerden biri, bir Spark uygulamasında kullanmanız gereken yürütücü çekirdek sayısıyla ilgilidir. Uzmanlar öneriyor bir yürütücünün dört veya beş çekirdeğe sahip olması gerekir. Hadoop Dosya Sistemleri G/Ç kısıtlamaları nedeniyle daha önce Hadoop ekosisteminde Spark uygulamalarını geliştirdiğimiz için bu kısıtlamaya aşinaydık. Yani, bir yürütücü için yapılandırılmış daha fazla çekirdeğimiz varsa, tek bir HDFS veri düğümünde daha fazla G/Ç işlemi gerçekleştiririz ve HDFS'nin yüksek eşzamanlılık nedeniyle bozulduğu iyi bilinir. Amazon S3'ü depolama olarak kullanırsak bu kısıtlama sorun olmaz, ancak JVM'nin aşırı yüklenmesi nedeniyle öneri devam eder. Unutmayın, G/Ç işlemleri gibi daha fazla operasyonel göreviniz olsa da, her bir yürütücünün JVM'sinin yapacak daha çok işi vardır, bu nedenle JVM'nin değeri düşer.

Bu gerçekler ve önceki bulgularla, bazı Spark uygulamalarımız için atanan kaynakların yalnızca %30'unu kullandığımızı fark ettik. Yalnızca en uygun kaynakları tahsis etmek ve EMR düğümlerinin aşırı kullanımını önemli ölçüde azaltmak için Spark iş parametrelerini yeniden kalibre etmemiz gerekiyordu. Aşağıdaki şekil, önceki yapılandırmamıza dayalı olarak %50'lik bir düğüm azalması gözlemleyebildiğimiz bu iyileştirmenin faydalarının bir örneğini sunmaktadır.

CM sistemiyle ilgili Spark uygulamasını optimize etmek için aşağıdaki optimize edilmiş parametreleri kullandık:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 5, "executorMemory": "17g", "numExecutors": 62 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Sonuçlar

Bu gönderide, AWS veri teknolojilerini ve şirket içi platformları kullanan liderler tarafından tanımlanan iki eylem satırına ve üç zorluğa dayalı olarak Belcorp veri ekosistemini iyileştirme projemizin başarı öyküsünü paylaşmak istedik.

Tanımlanan KPI'lara dayalı olarak en başından beri hedeflerimiz konusunda nettik, bu nedenle Mayıs 2021'in sonunda bildirilen JIRA olaylarının sayısında kayda değer bir azalma olduğunu doğrulayabildik. Aşağıdaki rakamlar, önceki aylara göre %75'e varan bir azalma göstererek Mart'ı kritik bir zirve olarak gösteriyor.

Bu olay azaltımına dayanarak, EMR kümesinde çalışan neredeyse tüm Spark iş rutinlerinin, aşağıdaki şekilde gösterildiği gibi %60'a varan bir azalmayla en karmaşık iki Spark işi de dahil olmak üzere bir çalışma zamanı optimizasyonundan yararlandığını anladık.

Ekibin yaptığı iyileştirmelerin belki de en önemli katkısı, doğrudan haftalık faturalandırmayla ilgili. Örneğin, Amazon EMR'nin yeniden tasarımı, birleştirme işlemi iyileştirmeleri, uygulanan önbellek en iyi uygulamaları ve Spark parametre ayarlaması - bunların tümü, küme kaynaklarının kullanımında kayda değer bir azalma sağladı. Bildiğimiz gibi, Amazon EMR, herhangi bir iş yapıp yapmadıklarına bakılmaksızın, küme düğümlerinin açık olduğu süreye göre faturalandırmayı hesaplar. Bu nedenle, EMR küme kullanımını optimize ettiğimizde, ürettiğimiz maliyetleri de optimize ettik. Aşağıdaki şekilde gösterildiği gibi, sadece 2 ayda, Mart ve Mayıs ayları arasında %40'a varan fatura indirimi sağladık. İyileştirmeler olmadan oluşturulacak yıllık faturalandırmanın %26'sına kadar tasarruf sağlayacağımızı tahmin ediyoruz.

Sonuç ve sonraki adımlar

Veri mimarisi ekibi, Belcorp veri ekosisteminin sürekli iyileştirmelerinden sorumludur ve her zaman sınıfının en iyisi bir mimari elde etmek, daha iyi mimari çözüm tasarımları yapmak, maliyeti optimize etmek ve en otomatikleştirilmiş, esnek ve ölçeklenebilir çerçeveler

Aynı zamanda, bu veri ekosisteminin geleceğini, yeni iş ihtiyaçlarına nasıl uyum sağlayabileceğimizi, yeni iş modelleri oluşturabileceğimizi ve mevcut mimari boşlukları nasıl giderebileceğimizi düşünüyoruz. Şu anda veri ürünleri, veri ağı ve göl evleri gibi yeni yaklaşımlara dayanan yeni nesil Belcorp veri platformu üzerinde çalışıyoruz. Bu yeni yaklaşımların ve kavramların, veri platformu tasarımımızın ikinci neslinde mevcut mimari boşluklarımızı kapatmamıza yardımcı olacağına inanıyoruz. Ek olarak, geliştirme döngüsü sırasında daha fazla çeviklik elde etmek için iş ve geliştirme ekiplerini daha iyi organize etmemize yardımcı olacak. Veri çözümlerini bir veri ürünü olarak düşünüyoruz ve ekiplere yapı taşları olarak kullanabilecekleri bir dizi teknolojik bileşen ve otomatik çerçeve sağlıyoruz.

Teşekkürler

Liderlerimize, özellikle Kurumsal Veri Mimarisi Direktörü Jose Israel Rico'ya ve bize müşteri odaklı olmamız konusunda ilham veren, en yüksek standartlarda ısrar eden ve her teknik kararı destekleyen Teknoloji, Veri ve Dijital Sorumlusu Venkat Gopalan'a teşekkür ederiz. sanatın durumu hakkında daha güçlü bir bilgi üzerine.

Yazarlar Hakkında

Diego Benavides Belcorp'un Global ve Kurumsal Veri Ekosistem Mimarisi'nin tasarımı, uygulanması ve sürekli iyileştirilmesinden sorumlu Kıdemli Veri Mimarıdır. Telekomünikasyon, bankacılık ve perakende gibi birçok endüstri alanında büyük veri ve gelişmiş analitik teknolojileriyle çalışma deneyimine sahiptir.

Luis Bendezu Belcorp'ta Kıdemli Veri Mühendisi olarak çalışıyor. Bir dizi AWS hizmetini kullanarak sürekli iyileştirmelerden ve yeni veri gölü özelliklerini uygulamaktan sorumludur. Ayrıca yazılım mühendisi olarak, API'ler tasarlama, birçok platformu entegre etme, uygulamaları ayırma ve manuel işleri otomatikleştirme deneyimine sahiptir.

Mar Ortiz AWS'de Çözüm Mimarı Associate olarak çalışan bir biyomühendis. Bulut bilişim ve medya, veritabanları, bilgi işlem ve dağıtılmış mimari tasarımı gibi çeşitli teknolojilerle çalışma deneyimine sahiptir.

Raul Hugo LATAM finans şirketlerinde ve küresel telekom şirketlerinde SysAdmin, DevOps mühendisi ve bulut uzmanı olarak 12 yıldan fazla deneyime sahip bir AWS Kıdemli Çözüm Mimarıdır.

Kaynak: https://aws.amazon.com/blogs/big-data/how-belcorp-decreased-cost-and-improved-reliability-in-its-big-data-processing-framework-using-amazon-emr- yönetilen-ölçekleme/