Da\u011f\u0131n\u0131k veri kaynaklar\u0131ndan gelen bilgileri tek bir \u00e7at\u0131 alt\u0131nda birle\u015ftirmek, modern i\u015f d\u00fcnyas\u0131n\u0131n en b\u00fcy\u00fck zorluklar\u0131ndan biridir. Peki, farkl\u0131 veritabanlar\u0131nda saklanan verilerden anlaml\u0131 raporlar olu\u015fturup, bu raporlar\u0131 veritaban\u0131 ba\u011f\u0131ms\u0131z olarak kolayca ta\u015f\u0131yabilir miyiz? \u0130\u015fte bu rehberde, SPL (Search Processing Language) raporlama sanat\u0131n\u0131n veritabanlar\u0131 aras\u0131 ta\u015f\u0131nabilir raporlar olu\u015fturmadaki g\u00fcc\u00fcn\u00fc ke\u015ffedece\u011fiz. Bu makale, sizi karma\u015f\u0131k veri entegrasyonu senaryolar\u0131ndan, esnek ve g\u00fc\u00e7l\u00fc raporlama \u00e7\u00f6z\u00fcmlerine ta\u015f\u0131yacak kapsaml\u0131 bir yol haritas\u0131 sunuyor.<\/p>\n

\n Uzman \u0130pucu: Bu tekniklerle, veri silolar\u0131n\u0131 ortadan kald\u0131rabilir ve operasyonel verimlili\u011finizi %30’a kadar art\u0131rabilirsiniz.\n <\/div>\n

G\u00fcn\u00fcm\u00fcz i\u015f ortam\u0131nda, veriler genellikle tek bir merkezi depoda bulunmaz. M\u00fc\u015fteri bilgileri bir CRM sisteminde (\u00f6rne\u011fin SQL Server), \u00fcr\u00fcn kullan\u0131m verileri bir NoSQL veritaban\u0131nda (\u00f6rne\u011fin MongoDB), finansal kay\u0131tlar ise eski bir ERP sisteminde (\u00f6rne\u011fin Oracle) tutulabilir. Bu durum, i\u015fletmelerin b\u00fct\u00fcnsel bir bak\u0131\u015f a\u00e7\u0131s\u0131 elde etmesini zorla\u015ft\u0131r\u0131r. Tek bir m\u00fc\u015fteri hakk\u0131ndaki tam resmi g\u00f6rmek veya operasyonel s\u00fcre\u00e7lerin u\u00e7tan uca performans\u0131n\u0131 analiz etmek istedi\u011fimizde, bu farkl\u0131 kaynaklardaki verileri bir araya getirmek kritik hale gelir.<\/p>\n

Veritabanlar\u0131 aras\u0131 raporlama ihtiyac\u0131, \u00e7e\u015fitli i\u015f senaryolar\u0131nda kendini g\u00f6sterir. \u00d6rne\u011fin, bir pazarlama y\u00f6neticisi, bir kampanyan\u0131n web sitesi ziyaret\u00e7ileri (Google Analytics), e-posta a\u00e7\u0131lma oranlar\u0131 (Mailchimp) ve sat\u0131\u015f d\u00f6n\u00fc\u015f\u00fcmleri (SQL CRM) \u00fczerindeki etkisini ayn\u0131 raporda g\u00f6rmek isteyebilir. Veya bir IT y\u00f6neticisi, farkl\u0131 sunuculardan (Linux loglar\u0131), a\u011f cihazlar\u0131ndan (SNMP verileri) ve uygulama performans izleme (APM) ara\u00e7lar\u0131ndan gelen verileri birle\u015ftirerek olas\u0131 bir sistem kesintisinin k\u00f6k nedenini ara\u015ft\u0131rmal\u0131d\u0131r. Bu t\u00fcr ihtiya\u00e7lar, geleneksel raporlama ara\u00e7lar\u0131n\u0131n s\u0131n\u0131rlar\u0131n\u0131 zorlar ve daha esnek, adaptif \u00e7\u00f6z\u00fcmlere kap\u0131 aralar.<\/p>\n

Ta\u015f\u0131nabilirlik ise bu denklemin di\u011fer \u00f6nemli par\u00e7as\u0131d\u0131r. \u0130\u015fletmeler zamanla teknoloji y\u0131\u011f\u0131n\u0131lar\u0131n\u0131 de\u011fi\u015ftirebilir, bulut platformlar\u0131na ge\u00e7ebilir veya farkl\u0131 veri depolama \u00e7\u00f6z\u00fcmleri benimseyebilir. Bu de\u011fi\u015fiklikler s\u0131ras\u0131nda, \u00f6nceden olu\u015fturulmu\u015f raporlar\u0131n s\u0131f\u0131rdan yaz\u0131lmas\u0131 hem zaman al\u0131c\u0131 hem de maliyetli bir s\u00fcre\u00e7tir. Veritaban\u0131 ba\u011f\u0131ms\u0131z olarak tasarlanm\u0131\u015f raporlar, altyap\u0131 de\u011fi\u015fikliklerinden minimum d\u00fczeyde etkilenerek, yat\u0131r\u0131m\u0131n korunmas\u0131n\u0131 sa\u011flar. Bu sayede, raporlama mant\u0131\u011f\u0131 bir kez olu\u015fturulduktan sonra, farkl\u0131 veri kaynaklar\u0131 veya platformlar aras\u0131nda kolayca ta\u015f\u0131nabilir, b\u00f6ylece s\u00fcrekli olarak de\u011fi\u015fen teknoloji manzaras\u0131nda esneklik ve \u00e7eviklik kazan\u0131l\u0131r. Dolay\u0131s\u0131yla, i\u015f kararlar\u0131n\u0131n daha h\u0131zl\u0131 ve do\u011fru al\u0131nabilmesi i\u00e7in, farkl\u0131 kaynaklardan gelen verileri birle\u015ftiren ve bu raporlar\u0131n gelecekteki altyap\u0131 de\u011fi\u015fikliklerine kar\u015f\u0131 dayan\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flayan \u00e7\u00f6z\u00fcmler elzemdir.<\/p>\n

SPL Raporlamas\u0131 Nedir ve Neden Bu Kadar G\u00fc\u00e7l\u00fcd\u00fcr?<\/h2>\n

SPL veya Search Processing Language, esasen Splunk platformunun kalbinde yer alan, veri arama, filtreleme, analiz etme ve g\u00f6rselle\u015ftirme i\u00e7in kullan\u0131lan g\u00fc\u00e7l\u00fc bir dildir. Ancak SPL’nin g\u00fcc\u00fc, sadece Splunk ile s\u0131n\u0131rl\u0131 de\u011fildir. Temelinde yatan veri i\u015fleme ve manip\u00fclasyon mant\u0131\u011f\u0131, herhangi bir veri kayna\u011f\u0131na uygulanabilir niteliktedir. SPL’yi \u00f6zel k\u0131lan \u015fey, SQL gibi geleneksel sorgulama dillerinden farkl\u0131 olarak, yap\u0131land\u0131r\u0131lm\u0131\u015f veya yap\u0131land\u0131r\u0131lmam\u0131\u015f veriler \u00fczerinde ayn\u0131 esneklikle \u00e7al\u0131\u015fabilmesidir. Log dosyalar\u0131, metin tabanl\u0131 veriler, JSON objeleri veya geleneksel ili\u015fkisel veritaban\u0131 tablolar\u0131; SPL, hepsini bir potada eritebilir.<\/p>\n

SPL’nin temel felsefesi, boru hatt\u0131 (pipeline) modeline dayan\u0131r. Bu modelde, veriler bir komuttan di\u011ferine aktar\u0131l\u0131r, her komut veriye belirli bir i\u015flem uygular ve sonu\u00e7 bir sonraki komuta iletilir. \u00d6rne\u011fin, index=web_logs status=200 | top clientip<\/code> komutu, web_logs<\/code> indeksindeki status=200<\/code> olan olaylar\u0131 bulur ve ard\u0131ndan en \u00e7ok istek yapan IP adreslerini listeler. Bu ard\u0131\u015f\u0131k i\u015flem, karma\u015f\u0131k veri analizlerini basit, okunabilir ve mod\u00fcler bir \u015fekilde ifade etmeyi m\u00fcmk\u00fcn k\u0131lar. Bu yap\u0131, veri ke\u015ffi ve sorun giderme s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131rken, rapor olu\u015fturmay\u0131 da basitle\u015ftirir.<\/p>\n

SPL’nin veritabanlar\u0131 aras\u0131 raporlama i\u00e7in neden bu kadar uygun oldu\u011funu birka\u00e7 maddede \u00f6zetleyebiliriz:<\/p>\n

\nVeri Kayna\u011f\u0131 Agnostik Yap\u0131:<\/strong> SPL, verinin nerede sakland\u0131\u011f\u0131na veya hangi formatta oldu\u011funa bak\u0131lmaks\u0131z\u0131n \u00e7al\u0131\u015fabilir. Bu, farkl\u0131 veritabanlar\u0131ndan (SQL, NoSQL), API’lardan, bulut hizmetlerinden veya dosya sistemlerinden gelen verileri tek bir mant\u0131kla i\u015fleyebilme yetene\u011fi anlam\u0131na gelir.<\/li>\n
G\u00fc\u00e7l\u00fc D\u00f6n\u00fc\u015ft\u00fcrme ve Analiz Yetenekleri:<\/strong> stats<\/code>, chart<\/code>, timechart<\/code>, join<\/code>, lookup<\/code> gibi komutlar, veriyi \u00f6zetleme, ili\u015fkilendirme, zaman serisi analizi yapma ve zenginle\u015ftirme konusunda inan\u0131lmaz bir esneklik sunar. Bu sayede, farkl\u0131 kaynaklardan gelen ham veriler kolayca anlaml\u0131 i\u015f bilgilerine d\u00f6n\u00fc\u015ft\u00fcr\u00fclebilir.<\/li>\n
Mod\u00fcler ve Okunabilir Yap\u0131:<\/strong> Boru hatt\u0131 yakla\u015f\u0131m\u0131, karma\u015f\u0131k sorgular\u0131n bile ad\u0131m ad\u0131m in\u015fa edilmesini sa\u011flar. Bu, raporlama mant\u0131\u011f\u0131n\u0131n anla\u015f\u0131lmas\u0131n\u0131 ve s\u00fcrd\u00fcr\u00fclmesini kolayla\u015ft\u0131r\u0131r.<\/li>\n
Tekrarlanabilirlik ve Otomasyon:<\/strong> Bir kez yaz\u0131lan bir SPL sorgusu, farkl\u0131 veri k\u00fcmeleri \u00fczerinde tekrar tekrar \u00e7al\u0131\u015ft\u0131r\u0131labilir ve otomatik raporlama i\u015f ak\u0131\u015flar\u0131na kolayca entegre edilebilir. Bu da, manuel veri toplama ve raporlama y\u00fck\u00fcn\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/li>\n<\/ul>\nBu \u00f6zellikler sayesinde, SPL raporlamas\u0131, i\u015fletmelerin da\u011f\u0131n\u0131k veri ortam\u0131nda bile tutarl\u0131, kapsaml\u0131 ve ta\u015f\u0131nabilir raporlar olu\u015fturmas\u0131n\u0131 sa\u011flayan stratejik bir ara\u00e7 haline gelmektedir. Geleneksel BI ara\u00e7lar\u0131n\u0131n belirli veri kaynaklar\u0131na ba\u011f\u0131ml\u0131l\u0131\u011f\u0131na kar\u015f\u0131l\u0131k, SPL, veri m\u00fchendislerine ve analistlere veri \u00fczerinde tam kontrol sa\u011flar ve yenilik\u00e7i analizler yapma \u00f6zg\u00fcrl\u00fc\u011f\u00fc tan\u0131r.<\/p>\n
Farkl\u0131 Veritabanlar\u0131ndan Veri Nas\u0131l Entegre Edilir? Kademeli Bir Yakla\u015f\u0131m<\/h2>\nFarkl\u0131 veritabanlar\u0131ndan veri entegrasyonu, SPL raporlamas\u0131n\u0131n temelini olu\u015fturur. Bu s\u00fcreci, kademeli bir yakla\u015f\u0131mla ele alabiliriz. \u00d6ncelikle, farkl\u0131 kaynaklardaki verilerinizi toplay\u0131p tek bir platforma getirmemiz, ard\u0131ndan bu verileri SPL benzeri sorgularla i\u015fleyebilece\u011fimiz bir yap\u0131ya kavu\u015fturmam\u0131z gerekiyor. \u0130\u015fte bu ad\u0131mlar\u0131 detayl\u0131ca inceleyelim:<\/p>\n
Ad\u0131m 1: Veri Toplama ve Normalle\u015ftirme<\/h3>\n\u00c7e\u015fitli kaynaklardan veri toplaman\u0131n farkl\u0131 yollar\u0131 vard\u0131r. En yayg\u0131n olanlar\u0131 ETL\/ELT s\u00fcre\u00e7leri, API entegrasyonlar\u0131 ve veri sanalla\u015ft\u0131rma katmanlar\u0131d\u0131r:<\/p>\n
\n\n      ETL\/ELT (Extract, Transform, Load \/ Extract, Load, Transform):<\/strong><\/p>\nBu, en geleneksel yakla\u015f\u0131md\u0131r. Verileri kaynak sistemlerden (SQL, NoSQL, Excel dosyalar\u0131 vb.) \u00e7ekeriz (Extract), ard\u0131ndan bu verileri raporlama gereksinimlerimize uygun hale getiririz (Transform) ve son olarak merkezi bir veri deposuna (data warehouse, data lake) y\u00fckleriz (Load). SPL’nin “Transform” ad\u0131m\u0131 burada devreye girer. Yani, SPL’nin sundu\u011fu filtreleme, birle\u015ftirme, \u00f6zetleme mant\u0131\u011f\u0131n\u0131, bu ETL s\u00fcre\u00e7lerinin “Transform” a\u015famas\u0131nda kullanabiliriz. \u00d6rne\u011fin, bir SQL veritaban\u0131ndan m\u00fc\u015fteri verilerini \u00e7ekerken, bir NoSQL veritaban\u0131ndan \u00fcr\u00fcn etkile\u015fim verilerini al\u0131p, bunlar\u0131 bir veri ambar\u0131nda SPL’nin join<\/code> ve stats<\/code> komutlar\u0131na benzer mant\u0131kla birle\u015ftirip \u00f6zetleyebiliriz. ETL ara\u00e7lar\u0131 (\u00f6rne\u011fin Apache NiFi, Airflow, Pentaho Data Integration) bu s\u00fcre\u00e7leri otomatize etmemize yard\u0131mc\u0131 olur.<\/p>\n
\n-- \u00d6rnek SQL Extract: M\u00fc\u015fteri verilerini \u00e7ekme\nSELECT customer_id, first_name, last_name, email FROM Customers;\n      <\/pre>\n<\/code><\/p>\n
<\/pre>\n<\/code>
\n\/\/ \u00d6rnek NoSQL Extract: \u00dcr\u00fcn etkile\u015fim verilerini \u00e7ekme (Node.js pseudo-kod)
\ndb.collection('product_interactions').find({ event_type: 'purchase' }).toArray((err, data) => {
\n  \/\/ Veriyi i\u015fleme (Transform) ve y\u00fckleme (Load)
\n});
\n      <\/code>\n    <\/li>\n
\n      API ve Ba\u011flay\u0131c\u0131lar (Connectors):<\/strong><\/p>\nPek \u00e7ok modern uygulama ve hizmet (Salesforce, Zendesk, Google Analytics vb.), REST API'ler arac\u0131l\u0131\u011f\u0131yla veri sa\u011flar. Bu API'lar\u0131 kullanarak verileri do\u011frudan \u00e7ekebilir ve bir merkezi sisteme aktarabiliriz. Splunk gibi platformlar, bu t\u00fcr API'lar i\u00e7in haz\u0131r ba\u011flay\u0131c\u0131lar sunar. E\u011fer Splunk kullanm\u0131yorsan\u0131z, Python gibi bir programlama dili ile kendi ba\u011flay\u0131c\u0131lar\u0131n\u0131z\u0131 yazabilir ve \u00e7ekti\u011finiz veriyi JSON veya CSV gibi standart formatlarda bir ara depolama alan\u0131na (\u00f6rne\u011fin Kafka, S3 bucket) aktarabilirsiniz. Daha sonra bu veriyi SPL benzeri bir ara\u00e7la sorgulayabilirsiniz.<\/p>\n
\n# \u00d6rnek Python ile API'dan veri \u00e7ekme\nimport requests\nimport json\n\napi_url = \"https:\/\/api.example.com\/customers\"\nheaders = {\"Authorization\": \"Bearer YOUR_TOKEN\"}\n\ntry:\n    response = requests.get(api_url, headers=headers)\n    response.raise_for_status() # HTTP hatalar\u0131n\u0131 yakala\n    customer_data = response.json()\n    \n    # Veriyi bir dosyaya kaydet veya bir mesaj kuyru\u011funa g\u00f6nder\n    with open(\"customer_api_data.json\", \"w\") as f:\n        json.dump(customer_data, f, indent=4)\n    print(\"M\u00fc\u015fteri verileri ba\u015far\u0131yla \u00e7ekildi ve kaydedildi.\")\n\nexcept requests.exceptions.RequestException as e:\n    print(f\"API iste\u011fi s\u0131ras\u0131nda bir hata olu\u015ftu: {e}\")\n      <\/pre>\n<\/code>\n    <\/li>\n
\n      Veri Sanalla\u015ft\u0131rma (Data Virtualization):<\/strong><\/p>\nVeriyi fiziksel olarak tek bir yere ta\u015f\u0131mak yerine, veri sanalla\u015ft\u0131rma platformlar\u0131, farkl\u0131 kaynaklardaki verileri sanal bir katman arac\u0131l\u0131\u011f\u0131yla birle\u015fik bir g\u00f6r\u00fcn\u00fcmde sunar. Bu sayede, tek bir sorgu ile birden fazla veri kayna\u011f\u0131n\u0131 ayn\u0131 anda sorgulayabilirsiniz. Bu katman, gelen sorgular\u0131 (SPL benzeri mant\u0131kla) farkl\u0131 kaynaklara delege eder, sonu\u00e7lar\u0131 birle\u015ftirir ve size tek bir sonu\u00e7 seti olarak sunar. Denodo, Tibco Data Virtualization gibi ara\u00e7lar bu alanda kullan\u0131l\u0131r. SPL'nin sorgu mant\u0131\u011f\u0131, bu t\u00fcr sanalla\u015ft\u0131rma katmanlar\u0131n\u0131n \u00fczerinde de uygulanabilir, \u00e7\u00fcnk\u00fc sanal katman, kaynak agnostik bir sorgulama aray\u00fcz\u00fc sunar.<\/p>\n<\/li>\n<\/ul>\n
Ad\u0131m 2: Veriyi SPL Benzeri Bir Ortamda Eri\u015filebilir K\u0131lma<\/h3>\nVerileri toplad\u0131ktan ve normalize ettikten sonra, bunlar\u0131 SPL'nin g\u00fcc\u00fcn\u00fc kullanabilece\u011fimiz bir ortama aktarmam\u0131z gerekir. E\u011fer Splunk kullan\u0131yorsan\u0131z, bu verileri do\u011frudan Splunk'a indexleyerek veya Splunk Connectors arac\u0131l\u0131\u011f\u0131yla eri\u015filebilir k\u0131larak i\u015fi kolayla\u015ft\u0131r\u0131rs\u0131n\u0131z. Ancak Splunk kullanm\u0131yorsan\u0131z, benzer yetenekleri sunan a\u00e7\u0131k kaynakl\u0131 veya ticari alternatifler de mevcuttur:<\/p>\n
\n\n      Data Lake (Veri G\u00f6l\u00fc) + Sorgu Motorlar\u0131:<\/strong><\/p>\nT\u00fcm ham verilerinizi bir veri g\u00f6l\u00fcnde (\u00f6rne\u011fin AWS S3, Azure Data Lake Storage, HDFS) depolayabilirsiniz. Daha sonra Apache Spark, Presto, Trino gibi da\u011f\u0131t\u0131k sorgu motorlar\u0131n\u0131 kullanarak bu veriler \u00fczerinde SPL'ye benzer sorgular \u00e7al\u0131\u015ft\u0131rabilirsiniz. Bu motorlar, SQL benzeri bir syntax sunsa da, karma\u015f\u0131k veri d\u00f6n\u00fc\u015f\u00fcmlerini ve birle\u015ftirmeleri SPL'nin stats<\/code>, join<\/code> mant\u0131\u011f\u0131na benzer \u015fekilde ger\u00e7ekle\u015ftirebilirler.<\/p>\n<\/li>\n
\n      Veri Ak\u0131\u015f Platformlar\u0131 (Data Streaming Platforms):<\/strong><\/p>\nApache Kafka gibi platformlar, farkl\u0131 kaynaklardan gelen ger\u00e7ek zamanl\u0131 verileri toplamak ve i\u015flemek i\u00e7in idealdir. Kafka Streams veya ksqlDB gibi ara\u00e7lar, akan veriler \u00fczerinde SPL'ye benzer filtreleme, d\u00f6n\u00fc\u015ft\u00fcrme ve birle\u015ftirme i\u015flemleri yapman\u0131z\u0131 sa\u011flar.<\/p>\n<\/li>\n
\n      \u00d6zel \u00c7\u00f6z\u00fcmler:<\/strong><\/p>\nKendi uygulaman\u0131z i\u00e7inde, verileri belirli bir formatta (\u00f6rne\u011fin JSON listesi) okuyup, Python'\u0131n pandas<\/code> k\u00fct\u00fcphanesi gibi ara\u00e7larla SPL'nin fonksiyonlar\u0131na benzer i\u015flemleri programatik olarak uygulayabilirsiniz. Bu yakla\u015f\u0131m, tam kontrol sa\u011flasa da, daha fazla geli\u015ftirme \u00e7abas\u0131 gerektirir.<\/p>\n<\/li>\n<\/ul>\n
Vaka Analizi: E-ticaret \u015eirketinin Birle\u015fik M\u00fc\u015fteri G\u00f6r\u00fcn\u00fcm\u00fc<\/strong><\/p>\n
Bir e-ticaret \u015firketi, m\u00fc\u015fteri verilerini MySQL (CRM), \u00fcr\u00fcn sipari\u015flerini PostgreSQL (\u0130\u015flem Veritaban\u0131) ve web sitesi etkile\u015fimlerini MongoDB (Kullan\u0131c\u0131 Davran\u0131\u015f\u0131) \u00fczerinde tutmaktad\u0131r. \u015eirket, m\u00fc\u015fterilerinin 360 derecelik bir g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc elde etmek ve hedefe y\u00f6nelik pazarlama kampanyalar\u0131 y\u00fcr\u00fctmek istiyor. Bu senaryoda:<\/p>\n
\nVeri Toplama:<\/strong> MySQL ve PostgreSQL'den veriler periyodik olarak ETL ara\u00e7lar\u0131yla \u00e7ekilerek bir Amazon S3 veri g\u00f6l\u00fcne CSV olarak at\u0131l\u0131r. MongoDB'den ise \u00fcr\u00fcn etkile\u015fim verileri JSON format\u0131nda S3'e aktar\u0131l\u0131r.<\/li>\n
Normalle\u015ftirme:<\/strong> ETL s\u00fcreci s\u0131ras\u0131nda, farkl\u0131 veritabanlar\u0131ndaki m\u00fc\u015fteri kimlikleri tek bir standart m\u00fc\u015fteri ID'sine d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Tarih formatlar\u0131 ve di\u011fer veri tipleri de standartla\u015ft\u0131r\u0131l\u0131r.<\/li>\n
SPL Benzeri Ortam:<\/strong> S3'teki veriler \u00fczerinde, AWS Athena (Presto tabanl\u0131) kullan\u0131larak SQL benzeri sorgularla SPL mant\u0131\u011f\u0131 uygulan\u0131r. \u00d6rne\u011fin:\n\n-- Athena'da SPL benzeri birle\u015ftirme ve \u00f6zetleme\nSELECT\n    c.customer_id,\n    c.first_name,\n    c.last_name,\n    COUNT(DISTINCT o.order_id) AS total_orders,\n    SUM(o.total_amount) AS total_spent,\n    COUNT(DISTINCT p.product_id) AS viewed_products_count\nFROM\n    mysql_customers c\nJOIN\n    postgresql_orders o ON c.customer_id = o.customer_id\nLEFT JOIN\n    mongodb_product_interactions p ON c.customer_id = p.customer_id\nWHERE\n    o.order_date >= '2023-01-01'\nGROUP BY\n    c.customer_id, c.first_name, c.last_name\nHAVING\n    total_spent > 1000\nORDER BY\n    total_spent DESC;\n      <\/pre>\n<\/code><\/p>\n
Bu SQL sorgusu, SPL'deki join<\/code>, stats count<\/code>, stats sum<\/code>, where<\/code>, group by<\/code>, having<\/code> ve sort<\/code> komutlar\u0131n\u0131n birle\u015fik mant\u0131\u011f\u0131n\u0131 yans\u0131t\u0131r. Athena, bu sorguyu do\u011frudan S3 \u00fczerindeki veriler \u00fczerinde \u00e7al\u0131\u015ft\u0131rarak fiziksel bir veri ta\u015f\u0131mas\u0131na gerek kalmadan raporlama imkan\u0131 sunar.<\/p>\n<\/li>\n<\/ol>\n
Bu kademeli yakla\u015f\u0131m, farkl\u0131 veri kaynaklar\u0131ndan gelen karma\u015f\u0131k verileri, SPL'nin analitik g\u00fcc\u00fcyle birle\u015ftirerek anlaml\u0131 ve ta\u015f\u0131nabilir raporlar olu\u015fturman\u0131n yolunu a\u00e7ar. \u00d6nemli olan, veri entegrasyon stratejinizi, SPL'nin sundu\u011fu esnek sorgulama ve analiz paradigmalar\u0131na uygun olarak tasarlamakt\u0131r.<\/p>\n
SPL ile Ta\u015f\u0131nabilir Raporlar Nas\u0131l Tasarlan\u0131r? \u0130leri Seviye Teknikler<\/h2>\nTa\u015f\u0131nabilirlik, bir raporun sadece mevcut veri kaynaklar\u0131n\u0131zla de\u011fil, gelecekteki olas\u0131 de\u011fi\u015fikliklerle de uyumlu olabilmesi anlam\u0131na gelir. SPL, bu esnekli\u011fi sa\u011flayan baz\u0131 ileri seviye teknikleri bar\u0131nd\u0131r\u0131r. Bu teknikleri kullanarak, raporlar\u0131n\u0131z\u0131 \"veritaban\u0131 agnostik\" hale getirebilir ve kolayca farkl\u0131 ortamlara adapte edebilirsiniz.<\/p>\n
1. Veri Kayna\u011f\u0131 Soyutlama ve Parametrizasyon<\/h3>\nEn temel ta\u015f\u0131nabilirlik prensibi, rapor mant\u0131\u011f\u0131n\u0131 somut veri kaynaklar\u0131ndan ay\u0131rmakt\u0131r. SPL'de, genellikle do\u011frudan indeksler veya kaynak tipleri belirtilir (index=web_logs<\/code>). Ancak ta\u015f\u0131nabilir raporlar i\u00e7in, bu ifadeleri parametrelerle de\u011fi\u015ftirebilir veya daha soyut katmanlar kullanabiliriz. \u00d6rne\u011fin, veri kayna\u011f\u0131n\u0131 bir de\u011fi\u015fken olarak tan\u0131mlay\u0131p, rapor \u00e7al\u0131\u015ft\u0131r\u0131l\u0131rken bu de\u011fi\u015fkenin de\u011ferini dinamik olarak atayabiliriz.<\/p>\n
E\u011fer SPL'nin native parametrelerini kullanam\u0131yorsak (Splunk d\u0131\u015f\u0131 bir ortamda), raporu \u00e7al\u0131\u015ft\u0131ran ara katmanda bu parametreleri y\u00f6netece\u011fiz. \u00d6rne\u011fin, Python betikleriyle olu\u015fturdu\u011fumuz raporlarda, veri kayna\u011f\u0131na i\u015faret eden bir URL veya dizin yolunu bir yap\u0131land\u0131rma dosyas\u0131ndan okuyabiliriz.<\/p>\n
\n| inputlookup data_source_mapping | search source_type=$data_type$\n| join type=left customer_id [| inputlookup customer_master_data | fields customer_id, region, segment]\n| stats count as total_events, dc(customer_id) as unique_customers by region, segment\n| chart count by region, segment\n      <\/pre>\n<\/code><\/p>\n
Yukar\u0131daki \u00f6rnekte, $data_type$<\/code> bir parametredir ve rapor \u00e7al\u0131\u015ft\u0131r\u0131l\u0131rken hangi t\u00fcr verinin (web_logs<\/code>, app_events<\/code> vb.) al\u0131naca\u011f\u0131n\u0131 belirler. inputlookup<\/code> komutlar\u0131 ise, veri kaynaklar\u0131n\u0131n e\u015fle\u015fmesini ve ana m\u00fc\u015fteri verilerini soyut bir \u015fekilde \u00e7eker. Bu yap\u0131, veri kaynaklar\u0131 de\u011fi\u015fse bile, raporun \u00e7ekirdek mant\u0131\u011f\u0131n\u0131n ayn\u0131 kalmas\u0131n\u0131 sa\u011flar.<\/p>\n
2. Ortak Veri Modelleri Kullan\u0131m\u0131<\/h3>\nFarkl\u0131 veritabanlar\u0131 genellikle ayn\u0131 varl\u0131klar\u0131 (m\u00fc\u015fteri, \u00fcr\u00fcn, sipari\u015f vb.) farkl\u0131 \u015femalar veya alan adlar\u0131yla temsil eder. Ta\u015f\u0131nabilir raporlar i\u00e7in, bu farkl\u0131 \u015femalar\u0131 tek bir ortak veri modeline \u00e7eviren bir katman olu\u015fturmak hayati \u00f6nem ta\u015f\u0131r. SPL i\u00e7inde bu, rename<\/code> komutuyla veya eval<\/code> ifadeleriyle ger\u00e7ekle\u015ftirilebilir.<\/p>\n
\u00d6rnek Ortak Veri Modeli:<\/strong><\/p>\n\n\n\n\n\n\n\nOrtak Alan Ad\u0131<\/th>\n MySQL Kar\u015f\u0131l\u0131\u011f\u0131<\/th>\n MongoDB Kar\u015f\u0131l\u0131\u011f\u0131<\/th>\n Log Kar\u015f\u0131l\u0131\u011f\u0131<\/th>\n<\/tr>\n<\/thead>\n
customer_id<\/code><\/td>\n customer_pk<\/code><\/td>\n user_uuid<\/code><\/td>\n user_id<\/code><\/td>\n<\/tr>\n
event_timestamp<\/code><\/td>\n order_date<\/code><\/td>\n interaction_time<\/code><\/td>\n _time<\/code><\/td>\n<\/tr>\n
product_code<\/code><\/td>\n item_code<\/code><\/td>\n product_id<\/code><\/td>\n prod_sku<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n-- SQL tabanl\u0131 veriden gelen veriyi ortak modele d\u00f6n\u00fc\u015ft\u00fcrme\nsource=sql_data\n| rename customer_pk as customer_id, order_date as event_timestamp\n| eval product_code = item_code\n| fields customer_id, event_timestamp, product_code, ...\n\n-- NoSQL tabanl\u0131 veriden gelen veriyi ortak modele d\u00f6n\u00fc\u015ft\u00fcrme\nsource=nosql_data\n| rename user_uuid as customer_id, interaction_time as event_timestamp\n| eval product_code = product_id\n| fields customer_id, event_timestamp, product_code, ...\n\n-- Sonra bu iki veri ak\u0131\u015f\u0131n\u0131 birle\u015ftirip analiz edebiliriz\n      <\/pre>\n<\/code><\/p>\n
Bu yakla\u015f\u0131m, rapor mant\u0131\u011f\u0131n\u0131 belirli bir veritaban\u0131n\u0131n \u015fema detaylar\u0131ndan ba\u011f\u0131ms\u0131z k\u0131lar. E\u011fer yeni bir veri kayna\u011f\u0131 eklenirse, sadece o kayna\u011f\u0131 ortak modele \u00e7eviren SPL komutlar\u0131n\u0131 eklemeniz yeterli olur, mevcut raporlar\u0131 de\u011fi\u015ftirmenize gerek kalmaz.<\/p>\n
3. JSON\/CSV Gibi Ara Formatlar Kullan\u0131m\u0131<\/h3>\nVerileri farkl\u0131 kaynaklardan \u00e7ektikten sonra, onlar\u0131 JSON veya CSV gibi evrensel, metin tabanl\u0131 formatlara d\u00f6n\u00fc\u015ft\u00fcrmek, ta\u015f\u0131nabilirli\u011fi art\u0131r\u0131r. Bu formatlar, neredeyse t\u00fcm programlama dilleri ve veri i\u015fleme ara\u00e7lar\u0131 taraf\u0131ndan kolayca okunabilir ve yaz\u0131labilir. Bir veritaban\u0131ndan veri \u00e7ekerken, bunu do\u011frudan JSON'a d\u00f6n\u00fc\u015ft\u00fcr\u00fcp, bir dosya sistemine veya bulut depolama alan\u0131na kaydedebilirsiniz. Daha sonra SPL'nin inputlookup<\/code> veya inputcsv<\/code> gibi komutlar\u0131n\u0131 kullanarak bu verileri i\u015fleyebilirsiniz.<\/p>\n
\n[\n  { \"customer_id\": \"C001\", \"event_timestamp\": \"2023-10-26T10:00:00Z\", \"product_code\": \"PROD_A\" },\n  { \"customer_id\": \"C002\", \"event_timestamp\": \"2023-10-26T10:05:00Z\", \"product_code\": \"PROD_B\" }\n]\n      <\/pre>\n<\/code><\/p>\n
<\/pre>\n<\/code>
\n| inputjson my_unified_data.json
\n| stats count by product_code
\n      <\/code><\/p>\n
Bu y\u00f6ntem, veri kaynaklar\u0131n\u0131z\u0131n arkas\u0131nda yatan karma\u015f\u0131kl\u0131\u011f\u0131 soyutlaman\u0131za yard\u0131mc\u0131 olur ve raporlama katman\u0131n\u0131n sadece standart bir dosyay\u0131 okumas\u0131 gerekti\u011fini garanti eder.<\/p>\n
4. Makrolar ve Arama Tan\u0131mlar\u0131<\/h3>\nSplunk gibi SPL tabanl\u0131 platformlarda, makrolar ve arama tan\u0131mlar\u0131 (saved searches) rapor par\u00e7ac\u0131klar\u0131n\u0131 ve sorgu mant\u0131klar\u0131n\u0131 yeniden kullan\u0131labilir hale getirmenin g\u00fc\u00e7l\u00fc yollar\u0131d\u0131r. Bir makro, parametre alabilen bir SPL kodu par\u00e7as\u0131d\u0131r. \u00d6rne\u011fin, belirli bir veri grubunu filtreleyen bir makro yazabilir ve bunu birden fazla raporda kullanabilirsiniz.<\/p>\n
\n-- Makro Tan\u0131m\u0131 (\u00f6rne\u011fin my_event_filter(status)<\/code>)\nmy_event_filter(200)<\/code> | stats count by host\n-- Makro i\u00e7eri\u011fi: index=web_logs status=$status$\n      <\/pre>\n<\/code><\/p>\n
Bu, raporlar\u0131n\u0131z\u0131 daha mod\u00fcler, daha kolay y\u00f6netilebilir ve ta\u015f\u0131nabilir hale getirir. Bir veri kayna\u011f\u0131n\u0131n ad\u0131 veya alan\u0131 de\u011fi\u015fti\u011finde, sadece makroyu g\u00fcncellemeniz yeterli olur, y\u00fczlerce raporu tek tek de\u011fi\u015ftirmenize gerek kalmaz.<\/p>\n
Bu ileri seviye teknikleri bir araya getirerek, SPL raporlar\u0131n\u0131z\u0131 sadece mevcut ihtiya\u00e7lar\u0131n\u0131z\u0131 kar\u015f\u0131lamakla kalmaz, ayn\u0131 zamanda gelecekteki veri altyap\u0131s\u0131 de\u011fi\u015fikliklerine kar\u015f\u0131 da dayan\u0131kl\u0131 hale getirirsiniz. Bu, uzun vadede zaman ve maliyet tasarrufu sa\u011flayan stratejik bir yakla\u015f\u0131md\u0131r.<\/p>\n
\n    Uzman \u0130pucu: Raporlar\u0131n\u0131z\u0131 tasarlarken, ba\u011f\u0131ml\u0131l\u0131klar\u0131 en aza indirmeye odaklan\u0131n. Her raporun, temel veri modelinizden ve parametrelerden beslenen, m\u00fcmk\u00fcn oldu\u011funca kendi kendine yeten bir yap\u0131ya sahip olmas\u0131, ta\u015f\u0131nabilirli\u011fi maksimize edecektir.\n  <\/div>\nMobil Uyumlu Raporlama Deneyimi Nas\u0131l Sa\u011flan\u0131r?<\/h2>\nG\u00fcn\u00fcm\u00fczde i\u015f d\u00fcnyas\u0131nda kararlar s\u0131kl\u0131kla ofis d\u0131\u015f\u0131ndan, hareket halindeyken veriliyor. Bu nedenle, SPL ile olu\u015fturdu\u011funuz raporlar\u0131n mobil cihazlarda da sorunsuz ve kullan\u0131c\u0131 dostu bir deneyim sunmas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Mobil uyumluluk, sadece raporlar\u0131n g\u00f6r\u00fcnt\u00fclenebilir olmas\u0131ndan \u00f6te, okunabilirlik, etkile\u015fim kolayl\u0131\u011f\u0131 ve performans gibi unsurlar\u0131 da kapsar.<\/p>\n
1. Duyarl\u0131 Tasar\u0131m (Responsive Design) \u0130lkeleri<\/h3>\nRaporlama panelleri veya web aray\u00fczleri geli\u015ftirirken, CSS media query'lerini kullanarak duyarl\u0131 tasar\u0131m ilkelerini uygulamak esast\u0131r. Bu, raporlar\u0131n ekran boyutuna g\u00f6re otomatik olarak d\u00fczenini ve stilini ayarlamas\u0131n\u0131 sa\u011flar. B\u00f6ylece, ayn\u0131 rapor hem b\u00fcy\u00fck masa\u00fcst\u00fc monit\u00f6rlerinde hem de k\u00fc\u00e7\u00fck ak\u0131ll\u0131 telefon ekranlar\u0131nda optimal bir \u015fekilde g\u00f6r\u00fcn\u00fcr.<\/p>\n
\n\n\n  \n    Sat\u0131\u015f Performans\u0131 Raporu<\/h3>\n  <\/div>\n  \n    \n      \n      \n    <\/div>\n    \n      \n      \n        \n          \n          B\u00f6lge<\/th> Toplam Sat\u0131\u015f<\/th><\/tr>\n        <\/thead>\n        
Kuzey<\/td> 150,000 TL<\/td><\/tr>\n          
G\u00fcney<\/td> 210,000 TL<\/td><\/tr>\n        <\/tbody>\n      <\/table>\n    <\/div>\n  <\/div>\n<\/div>\n\n\n