Veri Mühendisliğinin Etkili Yüzü Maxim Bushmin Bu Alanın Geleceğini Nasıl Görüyor?
Veri Mühendisliği Alanı Hızla Gelişiyor ve Bu Bilişim Uzmanlarının İş Piyasasını Çok Sıcak Hale Getirdi.
iş unvanının on yıl öncesine kadar neredeyse yok olduğunu bilmek yanlış değil. Yine de kuruluşların yazılım mühendisliğinde kayda değer bir akıma ihtiyaç duyması bu iş unvanının oluşmasına ve hızla ilerleme yolunda ilerlemesine neden olmuştur.
Veri mühendisinin sorumlulukları sabit değildir ve veri uzmanının çalıştığı şirkete bağlıdır. Ancak, veri mühendislerinin günlük görevlerini yerine getirmek için ortak beceriler öğrenmeleri gerekir. Bir veri mühendisinin sahip olması gereken geleneksel becerilerden bağımsız olarak, gelecekte veri mühendislerinin iki beceriye sahip olması beklenmektedir: bulut teknolojileri ve SaaS ürünleriyle çalışma, kodlamaya daha az, izlemeye daha fazla zaman ayırma. Şimdi bu becerileri daha detaylı inceleyelim.
Veri mühendisliği dünyasında, Maxime Beauchemin tanınmış bir figürdür.
Facebook ve Airbnb’deki ilk veri mühendislerinden biri olarak viral Apache Airflow aracını yazdı, açık kaynak yaptı ve kısa bir süre sonra Apache Superset’i geliştirdi. Bu cihaz, verileri dikkatli bir şekilde keşfederek toplama ve analiz ekosistemini önemli ölçüde değiştirdi. Şu anda Bushman, çalışma alanı makine öğrenimi algoritmalarının kullanabileceği verilerin görselleştirilmesi olan bir girişim olan Preset’in CEO’su ve kurucu ortağıdır.
Bushman, son on yılda veri mühendisliği dünyasının en etkili figürlerinden biri olmuştur. The Rise of the Data Engineer adlı 2017 tarihli kişisel blog gönderisinde şirketlere veri mühendisliğinin neden BT dünyasındaki en önemli mesleklerden biri olduğunu gösterdi. Bushman, doğru veri ölçeklendirmesi ve hassas analitik için veri ekiplerinin ETL’yi yönetmesi, veri boru hatları oluşturması ve veri altyapılarını ölçeklendirmesi için uzman bir veri mühendisine ihtiyaç duyduğuna inanıyor.
Veri mühendisi, öncelikle verileri almak, depolamak, analiz etmek, görselleştirmek ve etkili bir şekilde kullanmak için platformlar oluşturmaya ve optimize etmeye odaklanan bir veri ekibinin üyesidir.
Bu alanda çalışan birçok profesyonelin neredeyse aklını kurcalayan soru, veri mühendisliği alanının önümüzdeki beş yılda nerede olacağı ve bu alandaki uzmanların ne yapacağıdır. Yerelleşme süreci nasıl olacak, bulut bu alanda nasıl bir rol oynayacak ve birçok uzmanın aklına gelebilecek diğer sorular? Bu yazımızda Sayın Bushmin’in bazı bakış açılarını ve öngörülerini inceleyeceğiz.
Bulut, veri mühendislerinin görevlerini değiştirmede önemli bir rol oynayacak.
Bushman, kısa bir süre önce, veri mühendislerinin ölçeklenebilir ve hızlı bir veri ambarı olan Hive ile ilgili şeyleri yapmak için çok zaman harcamak zorunda kaldıklarına dikkat çekiyor. Ayrıca, veri iletim hattının çeşitli unsurlarını yönetmekten sorumluydular. Başka bir deyişle, veri mühendisliği sıkıcı ve zaman alıcı bir süreçti ve pek çekici değildi. “Bir projenin ilk görevlerini yerine getirmek için çok zaman harcamak zorundaydınız, bu da işin tükenmesine neden oluyordu. Öyle ki, bazen temel bir görevi tamamlamak için 10 ila 12 saat çalışmak zorunda kalıyordunuz.” 2021’de veri mühendisleri, BigQuery, Snowflake, Firebolt, Databricks ve diğer bulut depolama teknolojilerinin bilgi işlem gücü sayesinde büyük işleri çok hızlı bir şekilde yapabilir. Bu geliştirme, bulut tabanlı, SaaS ve NoSQL veritabanı teknolojileri sayesinde büyük ölçüde basitleştirildi, ancak hikayenin tamamı bu değil.
“Bulut gerçekten de işleri önemli ölçüde basitleştirdi, ancak bilgi işlem maliyetlerinize dikkat etmelisiniz ve ay sonunda, kullanabileceğiniz kaynak sınırı olmadığı için cüzdan bakiyenizin hızla tükendiğini görebilirsiniz. ,” diyor Bushman. Sizde yok ve sebepsiz yere depolama alanı veya işlem gücü kullanmanız nedeniyle ihtiyacınızdan fazlasını harcayabilirsiniz.”
Veri mühendisleri artık işlem gücünü ve depolama alanını yönetmekten sorumlu olmadığından, görevleri altyapı geliştirmeden veri yığını geliştirmeye veya özel rollere dayalı yaklaşımlara kayacaktır.
Bu değişimi “veri güvenilirliği mühendisliği” adı verilen bir kavramın ortaya çıkmasında görebiliriz. Bu durumda veri mühendisi, veri altyapısını yönetmekten, bulut tabanlı sistemlerin performansını izlemekten sorumludur.
Veri yönetişimi konusunda fikir birliğine varmak daha zor hale gelecek
Sadece birkaç yıl öncesine kadar, veri mühendisleri ve teknolojiden anlayan analistlerin şirketteki veri kütüphanecilerine benzer roller üstlendiği veri ekiplerinin yapısı oldukça merkeziydi. Veri yönetişimi pek bir anlam ifade etmiyordu ve mühendisler çeşitli kaynaklardan sorunsuz bir şekilde veri topladı.
Bushman şöyle diyor: “Bugün, şirketleri ilgilendiren, dağıtılmış yönetişim adı verilen bir kavramla karşı karşıyayız. Her ekibin kendi analiz alanı vardır, ekip yapıları merkezi olmayan olma eğilimindedir ve veri bilimcileri gibi ekip üyeleri yalnızca iyi veriler talep eder. Gerçek şu ki, veri ambarları organizasyonu birçok yönden yansıtır. Bir şeyleri yaparken fikir birliğinin esas olduğunu kabul ediyoruz, ancak bu, her şeyi yapma sürecini mutlaka kolaylaştırmayacaktır. veya metriklerin tanımı, fikir birliği eksikliği sorunlara neden olabilir.”
Bushman, özellikle verilerin örgütsel kaynaklardan farklı şekillerde elde edilmesi durumunda fikir birliğine varmanın kolay olmayacağına işaret ediyor.
Ekipler hangi verilerin özel olduğu veya kuruluşun hangi farklı bölümlerinin kendileriyle paylaştığı konusunda anlaşmazlarsa, bu fazlalık ve tutarsızlık sorunlarına yol açar.
Şu anda, veri odaklı ekipler şirketin tüm verilerinden sorumludur. Daha doğrusu topladıkları ve kullandıkları verilerin sahibi onlar. Veriler farklı gruplar tarafından paylaşıldığından ve daha büyük ölçekte açığa çıktığından, daha dikkatli hazırlanmalı ve uygulama programlama arayüzleri (API’ler) daha takıntılı bir şekilde geliştirilmelidir.
Değişiklik yönetimi hala bir sorundur, ancak doğru araçlar yardımcı olabilir
Bushman, 2017’de ilk veri mühendisliği makalesini yazdığında şuna dikkat çekti: “Verilerin doğası değiştiğinde, bunun şirket performansı üzerinde çarpıcı bir etkisi olacaktır. İleriye dönük yönetimin olmaması, böyle bir alanda teknik ve kültürel boşluklara neden olacaktır. durum.
Kaynak kodu veya veri kümeleri değiştirildiğinde veya güncellendiğinde panolar, raporlar ve diğer veri odaklı ürünler gibi aşağı akış katmanlarında hatalar göreceğiz. Alt katmanlardaki problemler çözülmezse yapılan analizler pratikte geçersiz olacaktır. Bu veri bozulması kuruluşlar için maliyetli olacaktır ve bu sorunu çözmek için çok zaman harcanmalıdır.
Çoğu zaman, arızalar herhangi bir belirgin belirti olmadan gelir. Bu gibi durumlarda veri mühendisliği ekipleri neyin yanlış gittiğini, kimin etkilendiğini ve sorunu nasıl düzeltebileceklerini anlamaya çalışır. Günümüzde veri mühendisliği ekipleri, etkili iletişim ve veri güvenilirliğinin iki kritik ölçüsünü vurgulayan daha sağlam bir araç seti ve kuruluş kültürü oluşturmak için DoApps ve yazılım mühendisliği en iyi uygulamalarına giderek daha fazla güveniyor.
Bushman, “Veri görünürlüğü, veri mühendisliği ekiplerinin sorunları belirleyip düzeltmesine ve hatta başarısızlıkların insanları nasıl etkilediğine dair fikir edinmesine yardımcı oluyor” diyor. Bununla birlikte, değişim yönetimi teknik olduğu kadar kültüreldir. “Değişimi yönetmek, ekip üyelerinin süreçleri, merkezi veri platformunu ve iş akışlarını yakından izlemesi gerektiği anlamına gelir.”
Özel ve genel veriler arasında bir ayrım yoksa, kimin hangi verileri kullandığını ve veriler ters giderse buna neyin sebep olduğunu bilmek zordur. Verinin doğasını analiz etmek ve veri yönetişimi ilkesine dikkat etmek, gelecekte veri odaklı projelerin başarı faktörlerinden biridir.
Airbnb’deyken Bushman, verilere erişimi sistematik hale getirmek ve tüm Airbnb çalışanlarının verileri keşfetmesi, anlaması ve güvenmesi için güçlendirecek Dataportal’ı tasarlamaya koyuldu. Bu tür araçlar, bir kuruluşun hangi çalışanlarının veya bölümlerinin verilerdeki değişikliklerden etkilendiğini beyan ederken, verilere yönetimin uygulanması konusunda çok özel bir çalışma yapmazlar.
Veri değişmez olmalıdır. Yoksa işler çığırından çıkar
Veriler üzerinde işlem yapması beklenen tasarım araçları, bu araçların gücü olarak kabul edilen yazılım mühendisliği modellerinden ödünç alınmıştır. Ancak bazı ölçütler ETL ardışık düzenleriyle çalışmayı etkiler.
Bushman, “Veritabanındaki bir sütunun adını değiştirmek istersem, bunu yapmak nispeten zordur çünkü ETL’mizi yeniden çalıştırmamız ve SQL iletişim kutularını düzenlememiz gerekir,” diyor. Veri iletim hatları ve veri yapıları değiştiğinde sistem performansını etkiler. Genel olarak, değişikliklerin uygulanması zordur ve bazen beklenmeyen çökmelere neden olur. Örneğin, büyük bir tabloya periyodik olarak veri yükleyen ve bu verilerin bir kısmını bırakmak isteyen artımlı bir işleminiz olduğunu varsayalım. Veri ardışık düzenini durdurmanız, altyapıyı iki kez yapılandırmanız ve yeni sütunlar eklemeniz gerekecek. Oluşturulursa, yeni iş mantığını konuşlandırın ve eskisini atın.
Veri mühendisliği araçları, özellikle veri hacmi ve iş akışları büyürse bu konuda pek yardımcı olmaz. Bu alandaki en etkili çözüm, varlıkları korumak ve verilerdeki değişiklikleri önlemektir. Ayrıca, değişiklikler kaçınılmazsa, her şey belgelenmelidir.
Veri mühendisleri, bulut teknolojilerinden ve SaaS ürünlerinden kapsamlı bir şekilde yararlanacak.
On yıl önce, şirketler verilerini depolamak için şirket içi altyapıya güveniyordu. Bu dönemde, veri mühendisleri makinelerini kurmak ve yapılandırmak için çok zaman harcadılar. Bu nedenle, büyük veri ile çalışmak için birincil teknolojiler, organizasyonel ortamlara özgü araçlar olarak ortaya çıkmıştır.
Ardından, bulut hizmeti sağlayıcıları, veri yönetimi sürecini basitleştirecek hizmetler vaadiyle alana girdi. Böylece veri mühendisleri iş problemlerini çözmeye daha fazla zaman ayırabilir.
Snowflake ve Databricks gibi bulut hizmeti sağlayıcıları ve teknoloji şirketleri, büyük verilerle çalışma sürecini basitleştirdi. Bugün, mevcut teknoloji uzmanları veri toplamanın kalitesi, yönetişimi ve biçimi üzerinde daha yakın kontrol uygulamakta ve ürünler arası entegrasyon sürecini optimize etmektedir.
Veri mühendislerinin işlerini tamamlamak için yalnızca bir Apache Foundation aracı kullandığı günler geride kaldı. Bugün, atanan görevleri gerçekleştirmek için sayısız araca erişimleri var ve her zaman en iyi aracı seçmeye çalışıyorlar. Bu nedenle, veri mühendisliği ekosistemleri alanında iyi bilgiye sahip olmaları ve bu kriterlere göre en iyi cihazı seçmek için kritik kriterleri nasıl belirleyeceklerini bilmeleri gerekir.
İşi yapmak için doğru aracı seçmek kolay değildir. Ne yazık ki, kararlı bir veri platformu oluşturmak için cihazları entegre etmek, veri mühendislerinin karşılaştığı başka bir zorluktur. Bazı veri mühendisleri, bilgi toplamak ve altyapı dağıtımını otomatikleştirmek için altyapıyı kod olarak kullanır. Bu eğilim, bir veri mühendisinin kısa sürede ihtiyaç duyduğu zorunlu becerilerden biri haline gelecek gibi görünüyor.
Veri mühendisleri kodlamaya daha az, izlemeye daha fazla zaman ayıracak
Kısaca, veri mühendisleri, karmaşık veri işlem hatlarını tasarlamak ve geliştirmek için Scala ve Spark gibi özel ETL araçlarını kullanmak zorunda kalmayacak.
Veri madenciliği için, çeşitli veri kaynaklarından bilgi çıkarma süreçlerini programlamak için Airbyte gibi teknolojilere erişebilecekler. Ayrıca, veri indirmek veya yüklemek eskisinden daha erişilebilir hale geldi. Örneğin, Snowflake altyapısı, bir tablodaki blob depolama kaynaklarından dosya yükleme işlemini basitleştirir. Böylece veri uzmanları, bunu yapmak için tek satırlık bir SQL komutu kullanabilir.
Dönüşüm aşamasında, ancak veri mühendislerine verilerini veri ambarında depolamak ve SQL’i veri dönüştürmenin birincil dili olarak kullanmak için yeni bir paradigma sağlar. Daha doğrusu, veri dönüştürme süreci ETL’den ELT’ye kayacaktır.
Böyle bir durumda, bir iş akışının kurulumu şimdikinden daha basit hale gelir ve bu bağlamda modern veri yığınını kullanabiliriz. Veri yığını, veri iş akışlarının karmaşıklığını azaltmayı ve görevlerin hızını artırmayı amaçlayan bir dizi teknolojiyi ifade eder. Modern veri yığınları, veri analistlerinin işlevlerini bağımsız olarak gerçekleştirmelerine olanak tanır ve artık ham verileri toplamak ve dönüştürmek için veri mühendislerinin yardımına ihtiyaç duymaz. Bu, veri mühendislerinin artık veri ekiplerinde yeri olmayacağı anlamına mı geliyor? Cevap olumsuz. Veri mühendisinin rolü, daha operasyon odaklı bir kısma yönelecektir. Yeni nesil veri mühendisleri, veri güvenilirliğini artırmaya odaklanacak.
Gelecekte, bir veri mühendisinin aşağıdaki sorumluluklara sahip olması beklenmektedir:
- Veri iş akışlarının yürütülmesini izleyin ve öngörülemeyen olaylar durumunda uyarıları yapılandırın
- Verilerin kullanılacağı altyapının hazırlanması
- Kodların doğruluğunu ve otomatik dağıtımı doğrulamak için CI/CD modeline dayalı veri iletim hatları oluşturma
- Her zaman veri kalitesinin sağlanması
Birkaç yıl önce yazılım geliştirmede gördüğümüze benzer şekilde, yazılım güvenilirlik mühendislerinin (SRE) yükselişiyle birlikte veri dünyasında da benzer bir eğilim görebiliriz. Daha spesifik olmak gerekirse, “Veri Güvenilirliği Mühendisi” adında yeni bir iş unvanı göreceğiz. Verilerin kullanılabilir ve güvenilir olmasını sağlarlar.
Bu gibi durumlarda, veri mühendisleri öncelikle Hizmet Düzeyi Göstergelerini (SLI) ve Hizmet Düzeyi Hedeflerini (SLO) tanımlamaktan sorumludur. Gelecekte, veri mühendisleri olay müdahalesinde önemli bir rol oynayacaktır. Bu alandaki sürekli gelişmelerin perspektifi, veri mühendisinin iş unvanının gelecekte köklü değişikliklere uğrayacağını göstermektedir.
Yeni nesil veri mühendisleri, belirli bir veri ürünü üzerinde çalışmayacak ve veri odaklı ekiplerin daha verimli sonuçlar üretmesine yardımcı olacaktır. Bu amaçla, doğru araç setini sağlamaktan sorumlu olacaklardır. “Veri Ağı Paradigması” olarak bileceğimiz şey budur.
Böylece gelecekte finansal raporlar için panolar oluşturmanız gerektiğinde ürün sahipleri, veri analistleri ve veri mühendislerinden oluşan bir ekibe ihtiyacınız olmayacak. Veri analisti bağımsız olacak ve ekibin kendisi için hazırladığı araçları kullanarak gerekli verileri hızla çıkaracak ve ardından bu ham verilere dayalı kritik göstergeleri hesaplayacaktır.