BÜYÜK VERİ SAKLAMA
Teknolojik gelişmeler, araştırmacıların imkan ve kabiliyetlerini gün geçtikçe arttırmaktadır. Yapay zeka ve ilintili alanlarda donanımsal, yazılımsal ve hesapsal tekniklerdeki gelişmelerle birlikte veri merkezli iş süreçleri önem kazanmıştır. Bu durum veri saklama, veri aktarma ve veri işleme süreçlerinin yönetilmesi gereksinimini doğurmuştur. Üretim alanlarındaki her bir cihazın veri kaynağı olarak görüldüğü nesnelerin interneti yaklaşımı ile beraber büyük miktarda veri oluşması ve bu verilerden gerçek zamanlı veya gerçeğe yakın zamanlı çıktılar üretilmesine yönelik birçok çözüm literatürde yer bulmuştur. Bulut teknolojileri kullanılarak büyük veri ve nesnelerin interneti başlıkları altında birçok çalışma yapılmış ve çeşitli problemlere odaklanan çözümler ortaya atılmıştır. Büyük veri ve nesnelerin interneti başlıklarında tekikleyici olan web devrimleri ve endüstriyel devrimler bu iki kavramın evlenmesine imkan sağlamıştır. Bu gelişmeler kurumlarda paradigma değişimlerini de beraberinde getirmiş ve büyük veri enstrümanlarını kullanabilen, analitik süreçleri işletebilen anahtar kişilerin endüstriyel ortamlarda konumlandırılması yönünde bir eğilim oluşmuştur.
Verinin elde edilmesinden, iş zekası veya operasyonel gösterge araçlarınca raporlanmasına kadar birbirine entegre birçok süreç mevcuttur. Dijitalleşme, izlenebilirlik ve analitik kabiliyetin arttırılması gibi hedefler kuruluşların öncelikleri arasındadır. Analitik kabiliyetler bağlamında makine öğrenmesi algoritmalarının işletilmesi, modellerin eğitilmesi, eğitilen modellerin yazılım servisi olarak sunulması ve çıktılarının çeşitli dijital ortamlara raporlanması başlıkları da büyük veri süreçleriyle entegre bir şekilde çalışmak durumundadır.
Bu yazıda, büyük verinin saklanması ve işlenmesi konusunda ortaya atılmış bazı kavramlara ve tasarımsal yaklaşımlara değinilmiştir. Büyük verinin saklanması konusundaki kavramsal kırılımların anlaşılması için veri tabanı, veri ambarı, veri gölü ve gölevi yapılarını ele alalım. Bu kavramları ele alırken birçok sinir ucuna da temas etmiş olacağız.
Veri Tabanı:
Veri tabanı, kendi kendini tanımlayan entegre kayıtlardan oluşan bir koleksiyon olarak ele alınabilir. 1960'lı yıllardaki ilk kuşak örneklerde kayıtların başka kayıtları işaretçiler aracılığıyle bağlantıda tutması prensibi üzerine kurulu olan ve navigasyonel veri tabanı sistemi tasarımı şeklinde ifade edilen bu tasarımı 1970'li yıllarda ilişkisel veri tabanı modeli takip etmiştir [1]. 1980'li yılların başında IBM’in ilk kişisel bilgisayarının (Personal Computer / PC) piyasaya sürülmesi [2] ve bir kitle pazar standardı (mass market standard) haline gelmesiyle birlikte birçok gelişme yaşanmıştır. 1982 yılında “Bilgisayar” Time dergisi tarafından yılın makinesi şeklinde nitelendirilmiştir. Bilgisayar satışlarındaki devasa artışı, ilişkisel veri tabanlarının ticarileşmesi ve çok sayıda yazılım ürünün piyasaya sunulması takip etmiştir. Bu kaldıraç etkisiyle beraber, yapılandırılmış sorgu dili (SQL) standart olarak ele alınmaya başlanmıştır. 1990’lı yıllarda internetin kullanılabilir olmasıyla istemci-sunucu mantığında hizmet veren veri tabanı sistemleri internet bağlaçları (connector) geliştirdiler. Aynı dönemde ilişkisel veri tabanı yönetimi araçlarının sahip olduğu karakteristik özelliklerde ayrışmalar belirmiştir. Bunun en önemli örneklerinden biri çok boyutlu veri yönetimi yapmaya yönelik gruplama ve birleştirme operasyonlarında verimlilik artışı sağlayan çevrimiçi analitik süreçlerle (Online Analytical Processing / OLAP) operasyonlarını gerçekleştiren analitik veri tabanlarıdır [3]. Üzerinde yapılandırılmış ve dönüştürülmüş veriyi tutmaya yönelik bu yaklaşım “Veri Ambarı” ifadesiyle ele alınmıştır [4]. İnternet ve ağ teknolojilerindeki gelişmeler neticesinde heterojen verilerde çoğalma yaşanmış ve sabit şema düzeninin yetersiz kaldığı durumlar da çoğalmıştır. 1996 yılında Genişletilebilir İşaretleme dili (XML) ortaya atılmış hem içiçe yapılandırılmış veriler hem de şemasız veriler için bir çözüm alternatifi olmuştur [5]. İnternet ve multimedya verilerinin artmasıyla veri tabanı yapılarında da yapılandırılmamış veriyi yönetebilecek yapılara doğru evrimleşen bir süreç yaşanmış ve 1998 yılında NoSQL ifadesi ilk defa Carlo Strozzi tarafından telafuz edilmiştir [6, 7, 8]. İlk ifadesiyle “ilişkisel olmayan (no sql)” anlamına atıf yapılmış olsa da yaklaşık on yıl sonra Eric Evans tarafından yeniden irdelenerek “sadece ilişkisel değil (not only sql)” anlamında ele alınması tavsiye edilmiştir. 2001 yılında XML’in yarı yapılandırılmış veri için daha optimize çalışabilecek bir türü olarak değerlendirilebilecek JavaScript Nesne Gösterimi (JSON) sunulmuştur [9]. JSON mantıksal bir veri modeli olmayıp bir serileştirme formatıdır. JSON formatı günümüzde NoSQL veri tabanlarıyla yakın ilişkidedir. NoSQL veri tabanları çizge (graph), döküman saklama ve anahtar-değer (key-value) saklama veri tabanları gibi alt başlıklar içermektedir.
NoSQL veri tabanı sistemleri Amazon, Google, Twitter ve Facebook gibi büyük internet şirketleriyle beraber gelişimini sürdürdü. Bu şirketler veriyi yönetirken geleneksel ilişkisel veri tabanı yönetim sistemlerinin baş etmekte zorlandığı farklı durumlara NoSQL çözümler ve alışılagelmiş yaklaşımlar dışındaki çözümler üzerinden cevap aradılar.
2003–2004 yıllarında Google’ın paylaştığı çalışmalar neticesinde dağıtık veri saklayabilen Google Dosya Sistemi[10] ve Google MapReduce[11] sistemi tanıtıldı. Böylece veri tabanı kullanımında konvansiyonel sınırların dışında yeni yaklaşımlar, yeni kırılımlar belirmiş oldu. Bu gelişme, veri saklama terminolojisinde değişiklikler yaratarak veri koleksiyonları ve veri gölü gibi yeni terimlerin ön plana çıkmasına sebep olmuş bir gelişme olarak karşımıza çıkmaktadır.
Veri ambarı kavramına geçmeden önce açık kaynak kodlu ilişkisel veri tabanı örneği olarak PostgreSQL [12], açık kaynak kodlu NoSQL veri tabanı örneği olarak Apache Cassandra[13] verilebilir.
Veri Ambarı:
Veri ambarı, yukarıdaki kısımlarda belirtildiği üzere ilişkisel veri tabanlarının kendi içerisinde işlevsel olarak farklılaşması neticesinde ortaya çıkmış, çok boyutlu veri yönetimi yapmaya yönelik gruplama ve birleştirme operasyonlarında verimlilik artışı sağlayan yapılardır. Çeşitli kaynaklardan gelen verinin detaylı bir görünümünü oluşturmak, veri ambarı oluşturma sürecini tarif etmektedir [14]. Günümüzde “analitik veri tabanı” şeklinde de ele alınabilecek bu yaklaşım dönüştürülmüş veriyi tutmaya yönelik optimize olduğundan iş zekası ve gösterge araçlarıyla entegre kullanılarak raporlama faaliyetlerinde kritik rol üstlenmektedir. Genel kullanımı hesaplamalar ve analitik işlemler olduğundan değişkenlere sorgu atma sürecini optimize eden özellikler barındırır. Genellikle kolon yönlü (column oriented) veri tabanları bu amaçlarla kullanılan veri ambarlarına örnek olarak verilebilir. Günümüzde veri ambarı olarak nitelendirilen yapılar veri gölü gibi derin saklama (deep storage) alanları, akan veri araçları (streaming — stream processing), operasyonel gösterge (dashboarding) araçları ve iş zekası araçlarıyla entegre olabilecek bağlantı araçlarını da bünyesinde barındırmaktadır. Veri ambarlarının genel kullanıcısı veya tüketicisi “Veri Analisti” pozisyonunda çalışan kişilerdir. Açık kaynak kodlu veri ambarına örnek olarak Apache Druid [15] gösterilebilir. Birçok sektörde ticari yazılım aracı olarak karşılaşabileceğimiz yazılımlara Google BigQuery [16], Amazon Redshift [17] ve SAP HANA [18] örnek gösterilebilir.
Veri Gölü:
Veri gölü, tüm ham verinin saklandığı, analiz için organizasyondaki kişilerin erişimine açık tek bir veri deposu olması fikrine dayanan bir kavram olarak karşımıza çıkmaktadır [19]. Veri gölü yapısı, veri ambarı yapısından farklı olarak şemalı veya yapılandırılmış veriyi tutmaya zorlamaz. Veri kaynağının sağladığı şekliyle veriyi saklamaya yönelik olduğundan, ham veri deposu olarak değerlendirilebilir. Veri ambarları, yapısı gereği analiz için dönüştürülmüş, düzenlenmiş verileri sakladığından organizasyondaki kişileri, tekleştirilmiş bir veri modeli ve şema yapısına zorlamaktadır. Bu haliyle veri ambarları sadece küçük organizasyonlar için bütünüyle bir veri deposu işlevini yerine getirebilmektedir.
Karmaşıklığı yüksek ve büyük organizasyonlarda bir model ortaya koyabilmek için her biri kendi veri modeline sahip olan, etki alanı odaklı veya iş alanı odaklı tasarım desenlerinden “Sınırlı Bağlam (Bounded Context)” deseninde [20] birden çok model gerekmektedir [19]. Bu gereksinimler veri ambarı yapısından veri gölü yapısına geçişi zorunlu kılmıştır. Veri gölünün çıkışında önderlik eden bir başka gereksinim de veri analizinin iş süreçlerine yerleşerek ilgi odağı olmasında yatmaktadır. Derin analizler yapacak kişiler çoğunlukla “Veri Bilimci” pozisyonunda çalışmaktadır. Bir veri bilimci geçerli bir model ortaya koyabilmek için ön işleme, öznitelik çıkarma gibi bazı operasyonları işletir ve dolayısıyla model için kullandığı verinin nasıl toplandığına ve kalitesine duyarlıdır. Bu bakımdan veri bilimci için dönüştürülmüş veri kadar ham veri üzerinde çalışabilmek de önemlidir.
Google Dosya Sistemi ve Google MapReduce sisteminin ortaya konulmasıyla kapı aralanan veri gölü yaklaşımı, Apache Hadoop ekosistemiyle birlikte yaygınlaşmış ve kabul görmüştür. Halen daha günümüzde veri gölü olarak kullanılan veri depolarında Hadoop Dosya Sistemi’nin kullanıldığı görülmektedir. Veri gölü yaklaşımı, veriyi formatından bağımsız bir şekilde saklayabilen ve verinin sorgulandığı ana kadar şema veya meta veri gereksinimi duymayan bir karaktere sahiptir [21]. Bu haliyle şema eksikliğinden veya benzer sebeplerden, verinin anlaşılamaz bir hale gelmesi ve veri gölünün “veri bataklığı”’na dönüşmesi kaygısı dikkate değerdir [22]. Veri gölünde saklanacak veriler hakkındaki verileri barındıran meta veri deposu [23] bu kaygıları gidermek noktasında hafifletici bir temel bileşen olsa da bu sorunları tam olarak çözememektedir. Bu problemlere ilave olarak, büyük veri bağlamında düşünüldüğünde verinin göle yazılması, gölden okunması ve sorgulanması başlıklarında da dikkat edilmesi gereken, veri gölünü bataklığa çevirebilecek bir takım noktalar mevcuttur. Veri gölü kavramı ham veri için bir büyük veri bileşeni olarak konumlandığından, bir çeşit saklama alanı sunar. Uzun süre bu saklama alanı, sunucuların dosya sistemleri üzerinden sağlanmış bir alanla sunulmuştur. Halen geçerli kabul edilen Hadoop Dosya Sistemi de bunun örneklerindendir. Bu yapı bir çeşit saklama alanı yönetimi yapmakta ve dosya sistemi üzerinden dağıtık depolamaya yönelik yapılandırmalar içermektedir. Teknolojik gelişmelerle birlikte büyük veri yönetiminde yazılım-tanımlı saklama alanı (software-defined storage) kurguları ortaya çıkmış ve dosya sistemi dışındaki saklama tiplerinde de ölçeklenebilir ve dağıtık çözümler sunabilen yapılar kendisine yer bulmuştur. Bu çözümlere örnek olarak Ceph [24] gösterilebilir. Açık kaynaklı yazılım-tanımlı depolama teknolojisi olarak Ceph, dosya sistemi tipi dışında blok ve nesne deposu (object storage) tiplerini de uygulayabilir. Ceph, sunucuların formatsız disk alanlarına yerleşerek bu üç tipi de uygulayabilecek bir dağıtık depolama alanı sunabilecek şekilde ilgili alanları yapılandıran bir yazılım aracıdır.
Dosya sistemi dışındaki tiplerin uygulanabilmesi, veri gölü bağlamında da önemli etkiler doğurmuştur. Veri gölü özelinde en kritik etkiyi nesne deposu yapmıştır. Nesne deposu, döküman, ses, görüntü ve video dosyaları gibi çeşitli formatlara sahip dosyaları, türden veya boyuttan bağımsız olarak “nesne” adı verilen ayrı bir veri birimi şeklinde saklayan bir yapıdır. Tüm nesneler, nesne deposunda hiyerarşik mimariye sahip klasörler yerine, düz bir şekilde ad uzayıyla / ad boşluğuyla birlikte saklanır [25]. Bu yapı, dosya hiyerarşisine sahip olmadığı için meta veri yönünden hem daha esnek hem daha zengindir [26]. Nesne deposuna REST API ile HTTP protokolü üzerinden erişim sağlanabilirken, iletim TCP/IP protokolü üzerinden sağlanabilir. Oluşturma, okuma, güncelleştirme ve silme gibi komutlar HTTP üzerinden işletilebilir [27]. Diğer bir saklama tipi olan blok saklama tipinden farklı olarak nesne deposu, işletim sisteminin doğrudan erişimine açık olmayıp, uygulamalar ya da diğer bir yorumuyla API üzerinden erişim sağlanan bir alandır [28]. Erişimin API üzerinden yürütülebilmesi ve doğrudan nesneyle ilgili erişim ve işlem kabiliyeti sunmasından kaynaklı olarak günümüz genel bulut şirketlerinin iş yapış biçimi olan “kullandığın kadar öde” gibi iş modellerine de uyumlu bir yapı ihtiva eder. Bu da uygulamaları için sunucu yerine sadece saklama alınana ihtiyaç duyan yazılım geliştiriciler veya bireysel kullanıcılar için maliyet düşürecek bir fayda sağlamaktadır. Benzer şekilde fonksiyonel olarak ayrışmış, saklama ve saklanan nesneye erişme özelliği sunan bir birim olarak ele alındığında sunucusuz modelde [29, 30] hizmet veren yazılımlar açısından da maliyet düşürücü bir etki sunar.
Veri gölünün depo görevi gören saklama alanına göl saklama alanı (lake storage) veya derin saklama alanı da denmektedir [31]. Göl saklama alanının performansı, temelde okuma ve yazmayla ilgili olduğundan bu iki başlıktaki süreçleri optimize edecek çalışmalar yapılmıştır. Veri dosya formatı, meta veri deposu ve veri tablo formatı gibi veri gölünü bir üst seviyeye terfi ettirecek unsurlar Gölevi başlığında irdelenmiştir.
Gölevi:
Gölevi [32], veri gölünün yönetiminin maksimum verimde yapıldığı ve veri gölünün metaforik olarak adeta bir veri ambarı kabiliyetlerinde kullanıldığı, bütüncül bir yaklaşımdır. Gölevi tasarımı veri dosya formatı, meta veri deposu ve veri tablo formatı yapılandırmaları tamamlanmış, çeşitli sorgu motorları aracılığıyla sorgu atılabilen ve iş zekası araçlarıyla entegre olabilen bir nesne deposu üzerine yani üst seviye bir veri gölünü merkez alarak inşa edilmiştir [33]. Gölevi, merkezindeki veri gölüne ilave olarak büyük veri işleme araçları (Apache Spark vb.), veri ambarı, iş zekâsı ve makine öğrenmesi araçlarının bir arada kullanıldığı bir platform mantığındadır. Gölevi yapısı Şekil -1 (esin kaynağı [33]) üzerinden betimlenmiştir.
Şekil 1: Gölevi yapısı
Veri bataklığına dönüşmeyecek bir veri gölünün tasarım süreçleri 4 başlıkta toparlanabilir [34].
- Ham verinin nesne deposunda saklanması.
- Ham veri dosyalarının analiz edilmek amacıyla boyut ve biçim yönünden optimize edilmesi.
- Şema yönetimi ve versiyonlama yapabilecek bir meta veri deposu aracının eklenmesi.
- Optimize edilmiş veri setlerini kullanacak sorgu motorları ve iş zekası araçlarına entegrasyonun sağlanması.
Gölevi platform yapısının tam anlamıyla anlaşılması için veri dosya formatı, meta veri deposu, ve veri tablo formatlarının bilinmesi kritiktir. Belki bir başka yazıda bu başlıklara ve akan veri araçlarıyla olan ilişkilerine değinmek güzel olabilir. Daha detaylı bilgi edinmek veya konuyla ilişkili başka başlıkları merak edenler için yüksek lisans tezime [35] göz atmalarını tavsiye edebilirim. Tezime erişim için YÖK Ulusal Tez merkezini ziyaret edebilirsiniz.
Referanslar:
[1] Codd, E.F., 1970. A relational model of data for large shared data banks. Communications of the ACM, 13(6), pp.377–387.
[2] https://en.wikipedia.org/wiki/Personal_computer
[3] Shoshani, A. (1997, May). OLAP and statistical databases: Similarities and differences. In Proceedings of the sixteenth ACM SIGACT-SIGMODSIGART symposium on Principles of database systems (pp. 185–196).
[4] Li, C., & Wang, X. S. (1996, November). A data model for supporting on-line analytical processing. In Proceedings of the fifth international conference on Information and knowledge management (pp. 81–88).
[5] Florescu, D., & Fourny, G. (2013). JSONiq: The history of a query language. IEEE internet computing, 17(5), 86–90
[6] NoSQL–Vikipedi. (t.y.). erişim tarihi 10.09.2022. https://en.wikipedia.org/wiki/NoSQL
[7] Strozzi, C. (t.y.). Shell-Ware Utilities, erişim tarihi 10.09.2022, http://www.strozzi.it/shared/swu/
[8] Strozzi, C. (2015). NoSQL Relational Database Management System: Home Page, erişim tarihi 10.09.2022, http://www.strozzi.it/cgi- 48 bin/CSA/tw7/I/en_US/NoSQL/Home%20Page
[9] Crockford, D. (2006). The application/json media type for javascript object notation (json) (No. rfc4627).
[10] Ghemawat, S., Gobioff, H., & Leung, S. T. (2003, October). The Google file system. In Proceedings of the nineteenth ACM symposium on Operating systems principles (pp. 29–43).
[11] Dean, J., & Ghemawat, S. (2004). MapReduce: Simplified data processing on large clusters.
[12] https://www.postgresql.org/
[13] https://cassandra.apache.org/
[14] Gardner, S.R., 1998. Building the data warehouse. Communications of the ACM, 41(9), pp.52–60.
[16] https://cloud.google.com/bigquery
[17] https://aws.amazon.com/redshift/
[18] https://www.sap.com/products/technology-platform/hana/what-is-sap-hana.html
[19] Martin F. (2015) DataLake, erişim tarihi 10.09.2022, https://martinfowler.com/bliki/DataLake.html
[20] Martin F. (2014) BoundedContext, erişim tarihi 10.09.2022, https://martinfowler.com/bliki/BoundedContext.html
[21] Walker, C., & Alrehamy, H. (2015, August). Personal data lake with data gravity pull. In 2015 IEEE Fifth International Conference on Big Data and Cloud Computing (pp. 160–167). IEEE.
[22] Srivastava K. (2014). Four Common Mistakes that Makes for Toxic Data Lakes, erişim tarihi 10.09.2022, http://www.forbes.com/sites/ciocentral/2014/11/25/fourcommonmistakes-that-make-for-toxic-data-lakes/
[23] Pasha F. (2022) Why We Need Hive Metastore, erişim tarihi 10.09.2022, https://blog.jetbrains.com/big-data-tools/2022/07/01/why-we-needhive-metastore
[24] https://docs.ceph.com/en/quincy
[25]https://www.ambedded.com.tw/en/technology/tech_objectstorage_s3.html#:~:text=Ceph%20Object%20Storage%20supports% 20two,of%20the%20OpenStack%20Swift%20API
[26] https://www.netapp.com/data-storage/storagegrid/what-is-object-storage/
[27] Jacop G. (2012) Advantages of using an object storage system, erişim tarihi 10.09.2022, https://www.techtarget.com/searchstorage/tip/Advantages-of-usingan-object-storage-system>, erişim tarihi 10.09.2022
[28] https://www.worldstream.com/en/news/block-storage-vs-object-storage-understanding-the-differences
[29] Mike R. (2018) Serverless Architectures, erişim tarihi 10.09.2022, https://martinfowler.com/articles/serverless.html
[30] Arda Ç. (2017) Serverless Nedir?, erişim tarihi 10.09.2022, https://devnot.com/2017/serverless-nedir/
[31] Javier R. (2020) Big Data File Formats Explained, erişim tarihi 10.09.2022, https://towardsdatascience.com/big-data-file-formats-explaineddfaabe9e8b33#:~:text=How%20you%20store%20the%20data,Buffers %2C%20Parquet%2C%20and%20ORC
[32] Armbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021, January). Lakehouse: a new generation of open platforms that unify data warehousing and advanced analytics. In Proceedings of CIDR.
[33]https://www.databricks.com/dataaisummit/session/data-lakehouse-and-data-mesh-two-sides-same-coin
[34] https://lakefs.io/data-lakes/
[35] Oğuzhan Yüce, nesnelerin interneti odağında büyük veri için tahmine dayalı analitik mimarisi , 2022
