Aralık ayı başında ölümcül bir hata yaparak geliştirici olarak hayatımda bir dönüm noktası oluşturdum ve şirket bünyesinde Veri Mühendisliği (DE) ekibine geçtim. Bu yazımda DE ekibinde iki ay çalıştığım süre boyunca yaptığım bazı gözlemleri paylaşacağım.
Neden Veri Mühendisliği?
DE'ye yolculuğum 2019 yazında başladı. Hadi gidelim ve orada aydınlanmaya ulaştım. Konuyla, çalışma algoritmalarıyla ve hatta onlarla ilgilenmeye başladım , sonra uygulamanın kapsamını düşündüm ve şirketimizdeki pratik uygulamanın dağıtılmış veritabanları olduğunu hemen keşfettik.
Ekibimiz tam olarak ne yapıyor? Tüm modayı takip eden erkekler ve kızlar gibi biz de Veriye Dayalı Bir Şirket olmak istiyoruz. Bunun mümkün olabilmesi için en azından şirketin ihtiyaç duyduğu raporları oluşturmak için kullanılabilecek güvenilir bir depolama tesisi kurmamız gerekiyor. Ancak en önemli şey bu depodaki verilere güvenilmesi gerektiğidir. Üstelik bu verileri kullanarak sistemin durumunu t zamanında geri yükleyebilmeniz gerekir. Tüm bunlar, mikro hizmetlerin cesur yeni dünyasında yaşadığımız gerçeğiyle karmaşıklaşıyor ve bu ideoloji, her hizmetin kendi küçük işlevselliğini uyguladığını, veritabanının kendi işi olduğunu ve onu en azından her gün silebileceğini, ancak en azından her gün silebileceğini ima ediyor. aynı zamanda hizmetin durumunu alıp işleyebilmemiz gerekir.
Veriye Dayalı Olmak İstiyorsanız Önce Olaya Dayalı Olun
O kadar basit değil. Olaylar farklıdır ve geliştirici ile veri mühendisi bunlara farklı şekilde bakar. Olaylardan bahsetmek ayrı bir yazının konusu olduğundan burada bu konuya girmeyeceğim. Ayrıca böyle bir makale zaten var Martin Fowler adında biri var, onun şöhretini elinden almayacağım, bırakın o da ünlü olsun.
Genel olarak düşünülecek çok şey var ve bu alanın çekici olmasının nedeni de bu. Öyle ki şirketimizde bir Veri Mühendisi, ETL/ELT boru hatlarını yazan bir kişiden çok daha geniş bir sorumluluk alanına sahiptir (bu kısaltmaların ne anlama geldiğini bilmiyorsanız, lütfen buraya gelin). . İçeriğe dayalı reklamcılık olarak).
Depolama mimarisi, veri modelleme, veri güvenliğiyle ilgili sorunlar ve elbette işlem hatlarının kendisi ile ilgileniyoruz. Ayrıca, bir yandan varlığımızın ürün geliştiriciler için çok külfetli olmadığından ve sisteme yeni özellikler eklerken gereksinimlerimizden olabildiğince az dikkatlerinin dağılması gerektiğinden, diğer yandan da bunları analistler ve BI ekibi için depolama verilerinde uygun şekilde düzenlenmiş olarak sağlamanız gerekir. Biz böyle yaşıyoruz.
Geliştirme aşamasından geçişteki zorluklar
İşe başladığım ilk gün, sizlerle paylaşmak istediğim bir takım zorluklarla karşılaştım.
1. İlk gördüğüm şey tuling ve bazı uygulamaların olmamasıydı. Örneğin testlerin kod kapsamını ele alalım. Geliştirme aşamasında olan yüzlerce test çerçevemiz var. Verilerle çalışırken her şey daha karmaşıktır. Evet, ETL işlem hatlarını test verileri üzerinde test edebiliriz, ancak hepsini manuel olarak yapmamız ve her özel durum için çözümler aramamız gerekiyor. Sonuç olarak, test kapsamı çok daha kötüdür. Neyse ki, izleme ve kayıt şeklinde başka bir geri bildirim katmanı daha var, ancak bu zaten proaktif olmaktan ziyade tepkisel tepki vermemizi gerektiriyor ki bu da sinir bozucu ve sinir bozucu.
2. DE perspektifinden dünya, sıradan bir ürün geliştiricisine hiç de göründüğü gibi değil (tabii ki okuyucu öyle değil ve o zaten her şeyi biliyor, ama ben bilmiyordum ve şimdi batırıyorum) yukarı). Bir geliştirici olarak, kendi mikro hizmetimi oluşturuyorum, verileri [seçtiğiniz veritabanına] koyuyorum, durumumu oraya kaydediyorum, kimliğe göre bir şeyler alıyorum ve bunda sorun yok. Servis yavaş, siparişler kafa karıştırıcı, hepsi bu. Benden durumumu başka bir hizmette aramamı istiyorlar, bu yüzden bazı RabbitMQ'ya bir etkinlik atacağım ve hepsi bu. Ve burada yine yukarıda anlatılan olaylar konusuna döndük.
Hizmetin operasyonel çalışma için ihtiyaç duyduğu şey, tarihsel veriler açısından bize uymuyor, bu nedenle hizmet sözleşmelerinin yeniden işlenmesi ve geliştirme ekipleriyle yakın çalışma sorunu başlıyor. Şirketimizde ne tür bir Olay Odaklı olduğu konusunda hemfikir olmamızın kaç saatimizi aldığını hayal bile edemezsiniz.
3. Kafanızla düşünmeniz gerekir. Hayır, geliştiricilerin düşünmediğini kastetmiyorum (gerçi ben kimim ki herkes adına konuşayım), sadece ürün geliştirmede çoğu zaman zaten bir tür mimariye sahipsiniz ve birikimden farklı karışımları kesiyorsunuz. Elbette bu planlama ve düşünmeyi gerektirir, ancak bu, asıl sorunun bunu iyi ve verimli bir şekilde yapmak olduğu akış çalışmasıdır.
Bizim için bu o kadar basit değil çünkü çeşitli sistem bileşenlerinin sıcak ve rahat bir monolitten vahşi mikro hizmet ormanının dünyasına aktarılması o kadar kolay değil. Hizmet olayları yaymaya başladığında, veriler artık farklı göründüğü için depolamayı doldurma mantığını yeniden düşünmeniz gerekir. Artık bir geliştirici olarak değil, bir veri mühendisi olarak çok ve ayrıntılı düşünmeniz gereken yer burasıdır. Günlerinizi bir defter ve kalemle ya da tahtanın başında bir keçeli kalemle geçirmeniz normal bir hikaye. Çok zor, düşünmeyi sevmiyorum, üretmeyi de seviyorum.
4. Belki de en önemli şey bilgidir. Bilgimiz eksik olduğunda ne yaparız? Stackoverflow'u kim söyledi? Bu kişiyi odadan çıkarın. Gidip konuyla ilgili belgeleri, kitapları okuyoruz, ayrıca forumlar, buluşmalar ve konferanslar düzenleyen bir topluluk da var. Dokümantasyon harika, ancak ne yazık ki eksik olabilir. Cosmos DB'yi birçok projede kullanıyoruz. Bu ürünün belgelerini okumada iyi şanslar. Tek kurtuluş kitaplardır, ne mutlu ki varlar ve bulunabilirler, çok fazla temel bilgi içeriyorlar ve çok ve sürekli okumak gerekiyor. Ama sorun toplumda.
Artık bölgemizde en az bir tane yeterli konferans veya buluşma bulmak zor. Hayır, elbette Data kelimesiyle çok fazla karşılaşılıyor ancak bu kelimenin yanında genellikle ML veya AI gibi tuhaf kısaltmalar bulunuyor. Yani bu bizim için değil, kendimize nasıl nöron bulaştıracağımızdan değil, depolama tesislerinin nasıl inşa edileceğinden bahsediyoruz. Bu yenilikçiler her şeyi ele geçirdi. Sonuç olarak toplumsuz kalıyoruz. Bu arada, Veri Mühendisiyseniz ve iyi toplulukları tanıyorsanız lütfen yorumlara yazın.
Toplantının sonuçları ve duyurusu
Sonunda ne elde ederiz? İlk deneyimim bana, bir veri mühendisinin yerine geçmenin her geliştirici için faydalı olacağını söylüyor. Bu sadece olaylara farklı bakmamızı ve geliştiricilerin verilerine nasıl davrandığını gördüğümüzde gözlerimizin kan çanağına dönmesine şaşırmamamızı sağlıyor. Yani, eğer şirketinizde bir DE varsa, bu adamlarla konuşun, (kendiniz hakkında) birçok yeni şey öğreneceksiniz.
Ve son olarak duyuru. Gün içinde konumuzla ilgili buluşma bulmak zor olduğundan, kendi buluşmamızı yapmaya karar verdik. Neden daha kötüyüz? Şans eseri harika bir şeye sahibiz ve buradan arkadaşlarımız Bizim gibi veri mühendislerinin haksız yere dikkatten mahrum bırakıldığını düşünenler.
Bu fırsattan yararlanarak ilgilenen herkesi, 27.02.2020 Şubat XNUMX'de Dodo Pizza ofisinde gerçekleşecek olan “DE ya da DIE” başlıklı umut verici ilk topluluk buluşmamıza davet ediyorum. Ayrıntılar şu adreste: .
Bir şey olursa ben orada olacağım, geliştiriciler konusunda ne kadar yanıldığımı yüzüme bizzat söyleyebilirsiniz.
Kaynak: habr.com