Pandas’ın kurucusundan AI, Apache Arrow ve yazılım mühendisliğinin geleceği [YouTube]

• Pandas ve Apache Arrow’u geliştirme deneyimine dayanarak, yapay zeka çağında da yüksek performanslı veri sistemleri ve yazılım tasarlamada uzmanlık, muhakeme ve zevkin kilit olduğunu düşünüyor
• Apache Arrow, tablo biçimli veriler için genel amaçlı, bellek içi tabanlı bir katman olarak sistemler arası aktarımı ve işlemeyi standartlaştırıyor; onu benimseyen sistem sayısı arttıkça birlikte çalışabilirliğin değeri de büyüyor
• DuckDB ve DataFusion gibi sofistike sistemleri LLM’lerin ortalama kod üretimiyle ikame etmek zor; açık kaynağın rekabet gücü yalnızca kodu değil, uzun sürede biriken güven ve kalite geçmişini de kapsıyor
• Yapay zeka araçları, inisiyatifi yüksek geliştiricilerin üretkenliğini büyük ölçüde artırıyor; ancak ne yapılacağı net değilse ortalama çözümler ve kodlar birikerek ajanların da içinden çıkmakta zorlanacağı bir ajan bataklığı (agentic tarpit) oluşturabiliyor
• Gelecekte dil sözdizimi ve elle kod yazmaktan çok mimari, problem tanımı, iletişim ve sonuçları ayırt etme becerisi önem kazanacak; organizasyonlar artan karar alma yükünü ve token maliyetlerini de yönetmek zorunda kalacak

---

Pandas’tan AI geliştirici araçlarına uzanan kariyer

• Wes McKinney yaklaşık 18 yıl önce Python Pandas’ı geliştirdi ve 2010’da açık kaynak proje olarak yayımladı
• Python for Data Analysis kitabı Python veri bilimi ekosisteminde yaygın biçimde kullanıldı; sonrasında açık kaynak geliştirmeyi sürdürebilecek şirketler ve iş modelleri kurma çalışmalarına katıldı
• Cloudera’da çeşitli açık kaynak geliştiricilerle birlikte Apache Arrow’u başlattı; Arrow ekosistemi ve Parquet geliştirmesinde de rol aldı
• Ursa Computing daha sonra Voltron Data’ya dönüştü; Voltron Data tasfiye edildikten sonra da Posit ile ilişkisini sürdürdü
• Şu anda veri bilimi kütüphanelerinden çok AI geliştirici araçları ve altyapısına odaklanan yeni bir şirket kurarak, yapay zekayla yazılım mühendisliği üretkenliğini artırmanın yollarını araştırıyor

Apache Arrow’un yaygınlaşma süreci

• Arrow, tablo biçimli veriler için genel amaçlı bellek içi veri taban katmanı olarak bellek içi işlemeyi ve sistemler arası veri aktarımını hızlandırıyor, birlikte çalışabilirliği artırıyor
• Başlarda kullanıcı ve tüketici sistem sayısı az olduğu için benimseme teşviki düşüktü; farklı açık kaynak topluluklarının tek bir biçim üzerinde uzlaşmasının zor olacağına dair şüpheler de vardı
  • Yeni birleştirici standart oluşturulduğunda, mevcut 13 standardın 14’e çıkması gibi XKCD tarzı bir sorun kolayca ortaya çıkabiliyor
  • Arrow, aynı problemi çözen güvenilir alternatiflerin neredeyse bulunmadığı bir ortamda kararlı bir implementasyon sunup benimsenmeyi bekleyerek büyüdü
• Teknolojinin kendisi son 5-6 yılda büyük ölçüde değişmedi; ancak daha fazla sistem benimsedikçe ağ etkisine yakın bir değer artışı ortaya çıktı
• DataFusion, sorgu motorunu sıfırdan yazmadan ürüne göre genişletilebildiği için yaklaşık 30-40 şirket tarafından dahili bileşen olarak kullanılıyor olabilir
  • Akış veri motoru geliştiren Arroyo, Cloudflare tarafından satın alındı; ardından Arrow ve DataFusion, Cloudflare’in akış veri altyapısının bir bölümünde kullanılmaya başladı
  • DataFusion Comet, Spark hızlandırmada kullanılıyor

Yapay zekanın kolayca ikame edemeyeceği sistem yazılımları

• DataFusion ve DuckDB, vibe coding ile hızlıca muadili üretilebilecek türden projeler değil
• LLM’ler mevcut kodları ve yaklaşımları ortalama alma eğiliminde olduğundan, son teknoloji bir sorgu motoru gibi uzmanlarca incelikle kurgulanmış sistemleri yakın vadede ortaya çıkarmaları zor
• Bu tür projeler, enjeksiyon kalıplı plastik oyuncaklardan çok, ustaların monte ettiği hassas İsviçre saatlerine benziyor
  • Bu, AI’ın bunları asla yapamayacağı anlamına gelmiyor; ancak şu an için ikame edilme olasılığı düşük
• Açık kaynak projelerinin değeri yalnızca implementasyondan değil, topluluğun uzun sürede biriktirdiği güvenden de gelir
  • Bakımcıların topluluğun çıkarlarını gözettiğine dair inanç
  • Tedarik zinciri saldırılarına karşı savunma yapılacağı ve ciddi hataların düzeltileceği beklentisi
  • Tutarlı biçimde iyi tasarlanmış, güvenilir yazılım sunma geçmişi
• McKinney, 2013’ten bu yana Pandas geliştirmesine derinden dahil olmadı; bugün projeyi büyük bir geliştirici grubu sürdürüyor
  • Bu nedenle teşekkür ve desteğin gerçek bakımcılara yönelmesi gerektiğini düşünüyor
• Yapay zekayla günde 10 bin satır kod üretmek mümkün olsa bile, geçmişte biriken kalite standartlarını karşılamayan çıktılar yayımlanamaz; bu yüzden üretim miktarından çok inceleme ve kaliteyi koruma daha önemli bir mesele haline geliyor

Oyunlardan ve matematikten programlamaya

• 1990’ların sonunda Nintendo 64’teki GoldenEye 007 oyununa kapıldı; 1997 sonu veya 1998 başında GeoCities’te bir hayran sitesi kurarak speedrun topluluğuna katıldı
• O dönemde web sitesini elle yönetiyordu; ancak rekabetçi programlamada iyi olan Kisman’ın site güncellemelerini C++ programıyla otomatikleştirdiğini görünce, yetenekli bir programcının ürettiği otomasyonun etkisini deneyimledi
• Lisede matematik yarışmalarına ve bilgisayar kullanımına ilgi duydu; MIT’de ise çocukluktan beri programlama yapan akranları arasında büyük bir beceri farkı hissetti
• Saf matematik diploması alırken karmaşıklık ve algoritmalar gibi teorik bilgisayar biliminin bazı alanlarını inceledi; ancak Java ile yaşadığı olumsuz deneyimler nedeniyle programlamanın kendisine fazla ilgi duymadı
• Programlamayı problem çözmeyi ve kişisel üretkenliği artıran bir araç olarak gördükten sonra ciddi biçimde içine girmeye başladı

Finans araştırmalarından doğan Pandas

• 2007’de, 22 yaşındayken nicel bir hedge fonunda işe başladı; beklediği formül ağırlıklı araştırmaların aksine, birçok analizin Excel elektronik tabloları ve elle yapılan işlemlere dayandığını gördü
• MATLAB ve R de kullanılıyordu, ancak daha çok yardımcı araç konumundaydı; MATLAB kodunu sunuculara dağıtmak için her sunucuya pahalı lisanslar gerekiyordu
• Araştırmadan üretime uzanan işler için sistem kurmaya uygun bir açık kaynak dile ihtiyaç olduğunu düşündü
• Bir iş arkadaşının önerisiyle 2008 başında Python ve bilimsel hesaplama kütüphanelerini kullanmaya başladı; mevcut araştırma araçlarını Python’da yeniden geliştirirken Pandas’ın ilk biçimi ortaya çıktı
• Üretkenliği artıran araçlar yapmak ve başkalarının bu araçlarla daha verimli çalıştığını görmek, onda oyunlardaki speedrun rekabetine benzer bir odaklanma duygusu yarattı

Basit kullanıcı deneyimi ve içerideki teknik borç

• McKinney, yalnızca tek bir kişiye uyan karmaşık AI araçlarından ziyade başkalarının da anlayıp kullanabileceği basit ve tutarlı araçlara önem veriyor
• Aşırı kişiselleştirilmiş araç setleri yapısal olarak karmaşık hale gelip, yapan kişi dışında kimsenin içinde yolunu bulamadığı Winchester Mystery House benzeri bir duruma dönüşebilir
• Pandas’ın ilk implementasyonu, iç mimariden çok insanların anlayıp yazması kolay API’lere ve kullanılabilirliğe odaklandı
• İç yapının dağınıklığı uzun süre bakım yükü yarattı; ancak Pandas’ın başarısı, yazılımın mükemmel bir mimariye sahip olmadan da büyük başarı kazanabileceğini gösterdi

NumPy’nin rolü ve sınırları

• NumPy, Jim Hugunin’in 1990’ların ortasında başlattığı çok boyutlu dizi kütüphanesi Numeric ile bellek eşleme gibi büyük ölçekli dizi özellikleri ekleyen Numarray kolunun Travis Oliphant tarafından 2005-2006 civarında birleştirilmesiyle ortaya çıktı
• O dönemde Matplotlib, SciPy, istatistik ve doğrusal regresyon araçları NumPy dizileri etrafında çalıştığı için, yeni bir veri aracının ekosisteme katılabilmesi adına NumPy uyumluluğu şarttı
• NumPy, büyük ölçekli çok boyutlu sayı ve tamsayı dizilerine odaklanıyordu; veritabanları veya sayısal olmayan veriler için bir temel olarak tasarlanmamıştı
• İlk Pandas, NumPy’yi temel aldı ve sayısal olmayan verilerdeki kısıtları aşmaya çalıştı
  • Sayı veya boolean olmayan değerler NumPy dizisi içinde Python nesneleri olarak saklanıyordu
  • String verilerde nesne ek yükü ve dolaylı referanslar oluştuğu için verim düşüktü
• Bu sınırlar daha sonra Pandas gibi sistemler için alternatif bir bellek içi temel olan Arrow’u geliştirme motivasyonu oldu

Python veri bilimi ekosisteminin büyümesi

• Girişim sermayesi alan birçok şirket, her işletmenin Google benzeri veri altyapısı kurması gerektiğini savunarak büyük veri açık kaynak projelerine ciddi yatırım akmasını sağladı
• Her şirketin aynı ölçekte altyapıya ihtiyacı yoktu; ancak bu finansman olmasaydı Arrow için gereken geliştiricileri bir araya getirmek muhtemelen çok daha zor olurdu
• O dönemde sektör, veri bilimi ve veri bilimcisinin ne anlama geldiği; iş, istatistik ve yazılım becerilerini birlikte taşıyan insanların nereden bulunacağı konusunda rekabet ediyordu
• Python, çok fazla programlama deneyimi olmayan ama istatistik bilen kişilerin de veri bilimine erişebilmesini sağladı
  • Python for Data Analysis ve scikit-learn gibi araçlar öğrenildiğinde 2-3 hafta içinde işte faydalı analizler yapılmaya başlanabiliyordu
  • Önce Scala gibi bir dil öğrenmek gerekseydi giriş bariyerinin daha yüksek, öğrenme süresinin de daha uzun olacağını düşünüyor

Pandas’ın yayımlanması ve Arrow organizasyonunun oluşması

• Pandas’ın 2009 yılbaşı gecesi yayımlanmasına karar verildi; 2010 Şubat’taki ilk PyCon sunumu, Python topluluğuyla ciddi biçimde bağ kurmasını sağladı
• McKinney 2010’da Duke’ta istatistik doktora programına başladı; ancak finans şirketlerinin Python veri araçlarına ilgisini ve Pandas’ın büyüme potansiyelini görünce ara verdi
• O dönemde Pandas 0.1, tüm join türlerini bile desteklemeyecek kadar sınırlıydı; projenin büyümesine odaklanmak için lisansüstü eğitimden ayrıldı
• Finans teknolojisi işi üzerinde düşündükten sonra Python for Data Analysis kitabını yazmaya ve bir BI girişimi kurmaya yöneldi; 2013’te BI pazarında Looker ile rekabet etmenin zor olacağına karar vererek Cloudera’ya katıldı
• Cloudera’da Impala geliştiricileriyle bağ kurdu; daha sonra Iceberg ve Databricks gibi alanlarda çalışan birçok mühendisle tanıştı ve bu deneyim sonraki kariyerinin temelini oluşturdu
• Arrow projesi 2016 başında Cloudera’da başladı; ancak o dönemde kurumsal yazılım pazarında deneysel teknoloji için özel ekip bütçesi ayırmak zordu
• 2016-2018 arasında finans şirketlerinde Arrow’u gerçek sistemlere uygulayarak veri işleme iş yüklerini hızlandırdı ve Parquet’yi iyileştirdi
• 2018’de çeşitli şirketler Arrow geliştirmesine finansman sağlamak istedi; ancak finans şirketi kuralları gereği dış fonları yönetmek zor olduğundan, şirket sponsorluğu alabilecek bağımsız bir organizasyon Nisan ayında kuruldu
  • Nvidia dahil donanım şirketleri ve finans şirketlerinden oluşan yaklaşık 6 sponsor katıldı
  • Yaklaşık 8 kişilik bir geliştirici ekibi oluşturuldu
• Ticari fırsatı doğruladıktan sonra 2020’de COVID-19 döneminde Ursa Computing’e dönüştü

Veri mühendisliğinde hâlâ süren sorunlar

• Günümüzde de veri alanı, veriyi A’dan B’ye taşımak, biçim dönüştürmek, belleğe yüklemek, sorgu ve dönüşümleri verimli çalıştırmak gibi sorunları tekrar tekrar çözüyor
• Pandas, beklenenden çok daha fazla kurumsal veri akışını taşıyan bir temel haline geldi; bugün geçmişte insanların yazdığından daha fazla Pandas kodunu LLM’lerin üretiyor olması muhtemel
• DuckDB, 20 yıl önceki bir geliştiricinin hayal etmekte zorlanacağı kadar güçlü bir araç
  • Ücretsiz kurulup farklı ortamlarda çalıştırılabiliyor
  • Telefonda ve web tarayıcısında bile çalışabiliyor
  • Tek bir makinede karmaşık kurulum olmadan yüksek performanslı analiz sunuyor
• Uzun süren rahatsızlıklar ve deneme yanılmalar, DuckDB ve Arrow gibi teknolojilere duyulan ihtiyacı netleştirdi; Parquet dahil birçok çözüm, Google gibi büyük internet şirketlerinin maliyet ve zaman azaltmak için geliştirdiği teknolojilerden etkilendi
• Parquet en iyi format değil, ancak geçmişe göre çok gelişti ve neredeyse tüm sistemler destekliyor
  • Vortex ve Lance gibi özelleşmiş alternatifler olsa da yeterince iyi uyumluluğu sayesinde kullanılmaya devam ediyor
• Yapay zeka sektörün ilgisini üzerine çekince veri mühendisliğinin gündem değeri azaldı; Databricks yeni bir veri motoru duyursa bile eskisine göre daha az ilgi görüyor
• Buna karşılık veri aracı geliştiricileri için modayı kovalamadan teknik olgunluğa odaklanabilecek alan oluştu; test yazmak gibi tekrarlı ve zahmetli işlerde AI’dan yararlanılabiliyor

Veritabanı teknolojilerine yakınsama

• Büyük veri döneminin önemli derslerinden biri, veritabanı araştırmacılarının makalelerinden ve konferans sonuçlarından daha erken yararlanmak gerektiğiydi
• TU Munich, CWI, MIT, CMU ve Berkeley gibi kurumların veritabanı araştırmalarını okuyup uygulayan ve işbirliği yapan bir yaklaşım önemli
• NoSQL ve ilişkisel olmayan depolama odaklı dönemde, ölçeklenebilir sistemler büyük ek yük getirerek iyi yapılmış tek makine, tek thread implementasyonlardan daha yavaş olabiliyordu
• Frank McSherry ve Michael Isard gibi isimlerin yer aldığı Scalability! But at what COST? çalışması, ölçeklenebilirlik uğruna ödenen maliyet sorununu ele alıyor
• Modern veri stack’i yeniden veritabanı teknolojileri ve kolonsal işleme etrafında yakınsıyor
  • Polars, Daft ve DataFusion Arrow kullanıyor
  • dbt’nin yeni motoru ADBC’den yararlanıyor
  • Databricks Photon, Arrow kullanıp kullanmadığından bağımsız olarak kolonsal yapıyı benimsiyor
• Başlıca sistemler benzer mimarilere ve yaklaşımlara yakınsadıkça, artık temel işleme yönteminden çok yazılımın pratikte ne kadar kolay kullanılabildiği daha önemli bir mesele haline geliyor

Hadoop’tan DuckDB’ye uzanan kullanılabilirlik iyileşmesi

• Hadoop döneminde Java ve XML yapılandırma dosyaları ile sayısız ayar kalemi nedeniyle, gerçek işe başlamadan önce yaklaşık iki günün kurulumla geçtiği durumlar olabiliyordu
• Spark, kelime sayımını tek satırda yazdırabilmesiyle büyük bir iyileşmeydi; ancak hâlâ altyapı ve yapılandırma dosyaları hazırlamak gerekiyordu
• DuckDB’nin kurulum ve çalıştırma biçimi, veri sistemlerinin ne kadar basitleşebileceğini gösteren bir kullanılabilirlik modeli
• Dağıtık sistemler de makul varsayılanlar ve hemen çalışan ayarlar sunarak operasyonel karmaşıklığı azaltabilmeli
• DuckDB, istemci-sunucu alanına da genişliyor ve MotherDuck ile yakın çalışıyor

Üretken AI için multimodal veri katmanı

• Mevcut lakehouse’lar tablo biçimli veri ve Parquet merkezli; ancak üretken AI ile büyük model eğitimi ve ince ayarı için görüntü, video, metin, belge ve loglar birlikte gerekiyor
• LanceDB’nin ele aldığı multimodal veri lakehouse’u gerçek bir kurumsal probleme karşılık geliyor
• Büyük ölçekli yapılandırılmamış veriden embedding üretmek elektrik ve GPU zamanı tükettiği için, ortaya çıkan embedding’lerin kendisi de hesaplama maliyeti nedeniyle ekonomik değer kazanıyor
• Üretim ortamlarında ham verileri ve üretilen sonuçları güvenilir biçimde saklayacak, yönetecek ve işleyecek veri depoları gerekiyor
• Her şirket kendi multimodal deposunu kurarsa hatalar, veri kaybı ve performans sorunları tekrar tekrar yaşanabilir; bu yüzden uzman yazılım sağlayıcılarının ortak çözümler sunması daha verimli
• Iceberg tablolarını doğrudan işletmek mümkün olsa bile Databricks, Snowflake ve AWS gibi sağlayıcılara yönetim bırakıldığında operasyonel karmaşıklık azalır; aynı mantık üretken AI’a yönelik multimodal veriler için de geçerli
• Üretken AI veri pazarında, belge vektör arama ve yüksek QPS işlemeden veri yaşam döngüsü yönetimine kadar farklı katmanları çözmek için hâlâ alan var

AI çağında geliştiricinin rekabet gücü

• McKinney bir dönem kendisinin de yazılım mühendisi olarak geleceği olup olmadığını düşündü; ancak AI’ın insanları inisiyatif seviyesi üzerinden daha belirgin biçimde ayırdığı kanaatine vardı
• İnisiyatifi yüksek kişiler, ne yapılacağını düşünüp iyi sonucu ayırt edebilen zevk ve muhakemeleri sayesinde AI’dan büyük üretkenlik artışı elde edebilir
• LLM’ler çoğu problem için ortalama ve risksiz B+ seviyesinde bir yaklaşım sunar; ancak kullanıcının yerine deneyim, zevk ve muhakeme oluşturmaz
• İyi muhakeme olmadan üretilen kod eklenmeye devam ederse karmaşık bir bataklık oluşur; ajanlar da bağlam ve yapının ağırlığı altında çalışmayı sürdürmekte zorlanır
• Geçmişte insanlar doğrudan implementasyon yaparken teknik beceri ve muhakemeyi birlikte geliştiriyordu; gelecekte elle kod yazma süresi azaldıkça sistem anlayışı ve tasarım becerisinin ayrıca geliştirilmesi gerekecek

AI çağında ne çalışılmalı?

• Yeni geliştiricilerin yalnızca Python veya Java sözdizimini öğrenmek yerine yazılım tasarımı ve mimarisi ile veri sistemlerinin yapısını çalışması gerekiyor
• Veri mühendisliğinde Lambda mimarisi ve Kappa mimarisi gibi farklı sistemlerin nasıl çalıştığını ve hangi sorunlara uygun olduğunu anlamak gerekiyor
• Ajanlara istenen sonucu doğru iletebilmek ve yanlış yöne gittiklerinde bunu fark edebilmek şart
• Kullanıcı A ile B arasında hangisinin daha iyi olduğuna karar veremiyorsa ajan da doğru seçimi onun yerine garanti edemez
• Yazılım mühendisleri, veri mühendisleri ve veri bilimcilerinin tamamı kod yazmaktan çok problem tanımı ve iletişime daha fazla zaman ayırabilir
• Ne istediğinizi açıklayamıyorsanız AI’dan da istediğiniz sonucu alamazsınız; yalnızca organizasyona AI eklemek üretkenliği ve ekonomik sonucu otomatik olarak artırmaz
• Deneyim ve muhakemesi yetersiz kişilere AI verildiğinde, faydalı çıktıdan çok başkalarının temizlemesi gereken borcu topluca üreten bir slop cannon haline gelebilir

Artan karar yükü ve organizasyonların AI yatırımı

• Önümüzdeki 2-5 yılda geliştirici işe alımı, teknik mülakatlar ve rol ayrımları karmaşık ve hızlı değişen bir hal alabilir
• Geçmişte ekipler toplantılar, sprint planlaması ve planlama pokeriyle yapılacak iş konusunda ortak güven oluşturur, ardından implementasyonu paylaşırdı
• Artık mevcut çevik planlama süreci Claude’un planlama modu içine sıkışıyor ve tek bir geliştiricinin tek başına çok sayıda seçim yapması gereken durumlar oluşuyor
• Bir günde eskisinden 10 kat fazla karar vermek zorunda kalan geliştirici, karar yorgunluğu ve belirsizlik nedeniyle durabilir
• Hızlı karar verip verimli bir yol belirleyen kişiler AI’ın üretkenliğinden yararlanabilir; ancak ne yapması gerektiğinden emin olmayanlara AI bu sorunu çözmez
• Şirketler Anthropic ve OpenAI’a büyük meblağlar öderken AI yatırımının geri dönüşünü görmekte zorlanabilir
  • Bazı olumlu sonuçların yanında israf, düşük kaliteli çıktılar ve bu çıktıları temizleme maliyeti de oluşur
  • AI model sağlayıcıları token satışı sürdükçe gelir elde eder; ancak müşteri şirketler daha sıkı token bütçeleri uygulayabilir

Açık ağırlıklı modeller ve token ekonomisi

• McKinney, açık ağırlıklı Çin modeli GLM 5.2’yi fiziksel altyapıda çalıştırdı ve sonuçların iyi olduğunu değerlendirdi
• GLM 5.2 küçük bir model değil; düzgün çalıştırmak için yaklaşık 8 adet B200 GPU gerekiyor
  • Bir B200’ün fiyatının yaklaşık 30 bin-50 bin dolar olduğu tahmin ediliyor
  • Toplam donanım maliyeti yaklaşık 250 bin-400 bin dolara ulaşabilir
• Uzun vadede açık ağırlıklı modellerin kalitesi artıp donanım ucuzladıkça, harici AI şirketlerine sürekli ödeme yapmak yerine kişisel sunucunun elektrik masrafını üstlenmenin mümkün hale gelmesini umuyor
• Son 30 günde kullanılan token’lar API liste fiyatıyla hesaplandığında yaklaşık 37 bin dolar ediyordu; ancak gerçek model sağlayıcısına ödenen tutar bunun çok altındaydı
• Mevcut token fiyatlarında büyük ölçekli sübvansiyonlar bulunuyor olabilir; uzun vadede hangi maliyet yapısının sürdürülebilir olduğu belirsiz
• AI benimseme oranı da sektörün ilgisi kadar homojen değil; bazı şirketler yönetim kurulu ve CTO seviyesinde yalnızca tartışma aşamasında kalıp fiili uygulamaya başlamamış uzun kuyrukta yer alıyor