“Sıfır Kopya Entegrasyonu” terimini seviyorum. Bunu ben bulmadım, Data Collaboration Alliance’dı,[1]
bu onunla geldi. Data Collaboration Alliance, federal erişimle birlikte verilerin yerelleştirilmiş kontrolünü destekleyen Kanada merkezli bir savunuculuk grubudur.
Terim hakkında sevdiğim şey, ne kadar çağrıştırıcı olduğu. Herkes, tüm entegrasyonun verileri kopyalamaktan ve dönüştürmekten ibaret olduğunu bilir. Bunu bir API aracılığıyla veya ETL (Dönüşüm ve Yüklemeyi Çıkarın) veya Data Lake tarzı ELT (Yükü Çıkarın ve belki sonunda Dönüştürmek için başkasına bırakın) yoluyla yapın. Her iki durumda da, entegrasyonun özünde bir kaynaktan bir hedefe veri kopyalamak olduğunu onlarca yıllık deneyimden biliyoruz.
Bu nedenle “kopyasız kopyalama” çok çağrıştırıcıdır. Sizi temel varsayımlarınızı yeniden düşünmeye zorlar.
Seviyoruz çünkü yıllardır yaptığımız ve hiçbir zaman bir isme sahip olmadığımız şeyi anlatıyor. Bu makalede, etkinleştirme teknolojisini biraz daha derinlemesine inceleyeceğim (yani, Sıfır Kopya Entegrasyonunun çalışması için yerinde neye ihtiyacınız var), ardından bir örnek olay incelemesi yapacağım ve son olarak “yap” ile bitireceğim. Kelimenin tam anlamıyla sıfır kopya mı demek istiyorsun?
Etkinleştirme Teknolojisi
ne olduğunu düşünmek için etkinleştirme teknoloji, önce ne olduğunu düşünmemiz gerekiyor devre dışı bırakma teknoloji. Başka bir deyişle, şu anda bunu yapmamızı engelleyen geleneksel teknolojinin nesi var?
Ana sorun, her bir uygulama sisteminin veya aracın kendi veri modeli tarafından nasıl tamamen gizlendiğidir. İki uygulamayı entegre etmek veya bir uygulamayı bir veri ambarıyla entegre etmek, hedef modele uyması için bir kaynak modelde ifade edilen verileri elde etmek anlamına gelir. Bu, bir angarya olmasına rağmen, farklı terimleri eşlemek kadar basit değildir. Bir kaynak sistem bir çalışanı “işçi” olarak adlandırırsa ve bir hedef sistem onları “personel” olarak adlandırırsa, yapılacak biraz haritalama vardır. Ancak bu, entegrasyonla ilgili daha derin sorunlara kıyasla önemsizdir.
Gerçek sorunlar, bir sistem verileri farklı şekilde yapılandırdığında veya bir sistem farklı bir soyutlama düzeyinde çalıştığında ortaya çıkar. İki sistem aynı (veya daha kötüsü, benzer) öğeler için farklı tanımlayıcılar kullandığında şiddetlenir. Bu her zaman olur ve üstesinden gelmek ilk bakışta göründüğünden daha zordur. Esasen entegrasyonun zor olmasının nedeni budur. Jeff Bezos’un tüm uygulamaların API’ler aracılığıyla iletişim kurması gerektiğine dair ünlü fermanı bile bu sorunu çözmüyor. Her API bir veri modelidir. Her API’nin kendi dili vardır. Her API, verileri belirli bir soyutlama düzeyinde veya başka bir düzeyde ortaya koyar. Her API, kendi yerel tanımlayıcılarını kullanan bir uygulamanın ön yüzüdür.
Bu nedenle, elbette, her entegrasyon, verileri kaynak model biçiminden hedefe kopyalar.
Bu büyüyü bozmak için dört şey yapmamız gerekiyor (ilk başta zor gibi görünse de, bu yığında çalıştığınızda bunların bedavaya geldiğini anlıyorsunuz):
- Verilerin tüm kullanıcıları için tek bir paylaşılan yapı
- Verilerin tüm kullanıcıları için paylaşılan bir semantik
- Paylaşılan tanımlayıcılar
- Satıcılar arası sorgu federasyonu
Semantik ve Bilgi Grafiklerinden bahsediyorum. Paylaşılan yapı üçlüdür. Başka bir yapı yoktur ve bu nedenle verilerinizi yeniden yapılandırmanıza gerek yoktur. RDF yapıdır. Vaka incelemesinde bunun daha somut bir örneğini göreceğiz.
Paylaşılan semantik, çekirdek model dediğimiz şeydedir. Bu dizideki diğer birçok makalede ve kitaplarımda, firmanın tüm bilgilerinin ortak bir modeline sahip olmanın önemini vurguluyorum. Birçoğu, ulaşılamaz olduğuna inandıkları için isteksizdir. Bu. Karmaşık kuruluşların bile özünde nispeten basit (1000’den az kavram) kavramlar dizisi olduğunu düzinelerce büyük anlaşmada kanıtladık. Bu paylaşılan modelin etrafında şekillenmesi, bir kez sorgulama ve birçok kaynaktan veri alma olanağı sağlar.
Üçüncü noktaya göre, paylaşılan tanımlayıcılar URI’ler/IRI’lerdir. URI’lerin/IRI’lerin büyüsü, meta verilere ihtiyaç duymamaları ve faydalı olmaları için belgelere ihtiyaç duymamalarıdır. İlişkisel bir tablodaki bir kimlik, yalnızca meta verileri olan DB, Tablo ve Sütun’u biliyorsanız bir anlam ifade eder. Bu, bir JSON belgesindeki anahtara veya bir API’deki alanlara benzer. Kimlik bulanık.
RDF’de, tanımlayıcı küresel olarak benzersizdir (tüm uygulayıcıların %99’u tarafından takip edilen en iyi uygulama, tanımlayıcıları ya sahip olduğunuz bir alan adına ya da purl.org ya da web kimliği gibi güvenebileceğiniz bir alan adına dayandırmaktır). Ayrıca, en iyi uygulama, yetkilendirmeye tabi olarak bir URI/IRI’yi çözümleme yeteneği sağlamaktır. URI, evrensel bir tanımlayıcı değil, tek tip bir tanımlayıcıdır. Bu, URI’nin tek bir şeye atıfta bulunduğu anlamına gelir, ancak bunu yapan tek tanımlayıcı olmayabilir. Varlık çözümlemesi yoluyla, iki URI’nin aynı şeyi ifade ettiğini keşfettiğimizde, şunu not edebiliriz (başka bir üçlü ile, tek yapının bu olduğunu unutmayın):URI1 baykuş:sameAs :URI2 .
Son olarak, sorunsuz bir şekilde birleştirme yeteneği, kopyalamayı önlemek için önemli bir bileşendir. Geleneksel veri ambarı veya veri gölü, bütünleştirme = ortak yerleşim ve tabii ki ortak yerleşimin kopyalama anlamına geldiği şeklindeki zımni kararı almıştır. Standartlarla uyumlu üçlü depo (RDF Graph) veritabanı satıcılarının tümü, sorguların şeffaf bir şekilde birleştirilmesine izin veren SPARQL protokolünü destekler. Açıkçası, federasyonun işleri yavaşlatma potansiyeli var ve bazı planlamalar genellikle yerinde.
Vaka Çalışması – Yatırım Bankası
Büyük bir yatırım bankasıyla çalıştık. Banka ile ilk projemiz hukuk departmanındaydı. Özellikle, kayıt tutma sınıflandırmasının otomasyonuna yardımcı oluyorduk. Bunu yapmak için, bir dizi sistemden veri çıkardık. Tüm SharePoint sitelerini, paylaşılan klasörleri ve paylaşılan veritabanlarını birkaç farklı kaynaktan aldık ve paralel olarak oluşturduğumuz çekirdek modele uygun olarak üçlü hale getirdik. Organizasyon yapılarını ve maliyet merkezlerini finansal sistemlerinden çıkardık, “üçe katladık” ve çekirdek modele uygun hale getirdik. Ayrıca İK ve çeşitli yetkilendirme sistemlerinden çalışanlar ve yükleniciler hakkında önemli veriler elde ettik – bilgileri sınıflandırma sürecinde bize yardımcı olabilecek üçlü veriler.
Sponsorumuzun doğru olduğu ortaya çıkan hipotezi, bir dizi kayıt hakkındaki bağlamsal verilerin iç gözlemlenmesiyle akılda tutma sınıflandırmasında çok iyi bir ilk kesimin inşa edilebileceğiydi. Yani, havuzun kuruluşun hangi bölümüne ait olduğu, hangi maliyet merkezine fatura edildiği, depoyu kimin kurduğu ve kimlerin katkıda bulunduğu ve bunların iş tanımlarının ne olduğu.
Proje iyi çalıştı ve firma içinde bunu daha da iyileştirmek ve ilk çalışmayı temel almak için daha uzun vadeli bir proje ortaya çıkardı. Bu arada, çekirdeği şirket içindeki diğer birçok alanda genişlettik.
Yıllar sonra, bir Tech Asset projesinde çalışan sponsor, çalışan verilerine ihtiyaç duyuyordu. Onlara, bu diğer projenin ihtiyaç duydukları çalışan verilerinin çoğunu üçe katladığını ve verileri taze tutan bir ardışık düzende olduğunu söyledik.
Sirenin kopya tabanlı entegrasyon şarkısı o kadar güçlü ki sponsorlar, “Harika, hadi şu çalışan verilerinin bir kopyasını alıp kendi kullanımımıza uyarlayalım” dediler.
Onlara kopyalamaya gerek olmadığını ve gerçekten bir yeniden yapılandırmaya gerek olmadığını veya mümkün olmadığını hatırlatmak zorunda kaldık. Bir çalışanla ilgili her gerçek üçlüdür. Şunu söyleyebiliriz: Emp1 :raporlarKime :Kuruluş1veya bu :Emp1 :hasEmail “[email protected]”. Bu verilerin tüketicisi ya “Bu gerçeklerden bazılarıyla ilgilenmiyorum” diyebilir ya da ilgilendikleri ek bilgilerle gerçeklere ekleme yapabilir, ancak yeniden yapılandırmaya, yeniden adlandırmaya ya da başka herhangi bir şeye gerek yoktur. kaynak verileri değiştirmenin yolu.
Ve federasyon ile gerektiği gibi tüketebilirler.
Kelimenin tam anlamıyla ‘Sıfır Kopya’ mı Demek İstiyorum?
Zeki okuyucular, örnek olay incelememizde bile kopyalanmış İK ve yetkilendirme sistemlerinden gelen veriler üçlü depoya. Verileri taze tutan bir ardışık düzen olduğundan da bahsetmiştik, bu da elbette kopyaları da ima ediyor.
Eski sistemler yerinde kaldığı sürece kopyalara ihtiyaç duyulacaktır. Ancak eski sistemlere ihtiyaç duyulmayan uzun vadeli bir geleceğe doğru gidiyoruz. Bilgi grafiği yerleştirildikten sonra, yeni işlevsellik doğrudan yerinde oluşturulabilir. Bu noktada, kaynak / altın / usta orijinal olacağından, gerçekten kopyalamaya gerek kalmayacaktır.
Bu arada, belki de buna yapmanız gereken “Son Kopya” demeliyiz.
Ayrıca, federasyonun girişinde uyardığımız gibi, sorguları birleştirme eylemi koordinasyon ve gecikme endişelerini beraberinde getirir. Bunun çözümü genellikle yerel bir kopya oluşturmaktır. Bununla birlikte, bu kopya, bir biçimden diğerine dönüştürmek için insan emeği uygulanan bir kopyadan çok bir önbellek gibidir. Amaçlarımız açısından, bir önbellek kopya sayılmaz (veya en azından ortadan kaldırılması gereken bir kopya olarak sayılmaz).
Özet
“Sıfır Kopya Entegrasyonu”, Data Collaboration Alliance tarafından ortaya atılan bir terimdir. Aynı zamanda geleneksel düşünceye meydan okur ve aynı zamanda böyle bir mimarinin ihtiyaç duyacağı gereksinimlere güçlü bir şekilde işaret eder. Biz tamamen bu memeden yanayız.
[1] https://www.datacollaboration.org/zero-copy-integration
