Açık Kaynak DataHub: LinkedIn Meta Veri Arama ve Keşif Platformu
İhtiyaç duyduğunuz verileri hızlı bir şekilde bulmak, veriye dayalı kararlar almak için büyük miktarda veriye dayanan herhangi bir şirket için çok önemlidir. Bu yalnızca veri kullanıcılarının (analistler, makine öğrenimi geliştiricileri, veri bilimcileri ve veri mühendisleri dahil) üretkenliğini etkilemekle kalmaz, aynı zamanda kaliteli bir makine öğrenimi (ML) hattına bağlı olan son ürünler üzerinde de doğrudan bir etkiye sahiptir. Ek olarak, makine öğrenimi platformlarını uygulamaya veya oluşturmaya yönelik eğilim doğal olarak şu soruyu gündeme getiriyor: özellikleri, modelleri, metrikleri, veri kümelerini vb. dahili olarak keşfetme yönteminiz nedir?
Bu yazımızda bir veri kaynağını açık lisans altında nasıl yayınladığımızdan bahsedeceğiz. projenin ilk günlerinden itibaren meta veri arama ve keşfetme platformumuzda . LinkedIn, DataHub'un kendi sürümünü açık kaynak sürümünden ayrı olarak korur. Neden iki ayrı geliştirme ortamına ihtiyacımız olduğunu açıklayarak başlayacağız, ardından açık kaynak WhereHows'u kullanmaya yönelik ilk yaklaşımları tartışacağız ve DataHub'ın dahili (üretim) sürümünü aşağıdaki sürümle karşılaştıracağız. . Ayrıca, her iki veri deposunu da senkronize tutmak için açık kaynak güncellemelerini göndermeye ve almaya yönelik yeni otomatik çözümümüzle ilgili ayrıntıları da paylaşacağız. Son olarak, açık kaynak DataHub'ı kullanmaya nasıl başlayacağınıza dair talimatlar vereceğiz ve mimarisini kısaca tartışacağız.
WhereHows artık bir DataHub!
LinkedIn'in meta veri ekibi daha önce sunmuştu (Nerede Hows'un halefi), LinkedIn'in arama ve meta veri keşif platformu ve onu açmaya yönelik planlar paylaşıldı. Bu duyurudan kısa bir süre sonra DataHub'un alfa sürümünü yayınladık ve bunu toplulukla paylaştık. O zamandan bu yana, depoya sürekli olarak katkıda bulunduk ve en çok talep edilen özellikleri eklemek ve sorunları çözmek için ilgilenen kullanıcılarla birlikte çalıştık. Şimdi resmi sürümü duyurmaktan mutluluk duyuyoruz .
Açık Kaynak Yaklaşımları
LinkedIn'in verileri ve bunların nereden geldiğini bulmaya yönelik orijinal portalı WhereHows, dahili bir proje olarak başladı; meta veri ekibi onu açtı . O zamandan bu yana, LinkedIn kullanım senaryoları için geliştirilen tüm ürün özellikleri genel olarak daha geniş bir kitleye uygulanamadığı için ekip her zaman iki farklı kod tabanını (biri açık kaynak için, diğeri LinkedIn'in dahili kullanımı için) korudu. Ayrıca WhereHows'un açık kaynak olmayan bazı iç bağımlılıkları (altyapı, kütüphaneler vb.) vardır. Takip eden yıllarda WhereHows birçok yineleme ve geliştirme döngüsünden geçti ve bu da iki kod tabanını senkronize tutmayı büyük bir zorluk haline getirdi. Meta veri ekibi, dahili ve açık kaynak geliştirmeyi senkronize tutmaya çalışmak için yıllar boyunca farklı yaklaşımlar denedi.
İlk deneme: "Önce kaynağı açın"
Başlangıçta çoğu geliştirmenin açık kaynak deposunda gerçekleştiği ve değişikliklerin dahili dağıtım için yapıldığı "önce açık kaynak" geliştirme modelini izledik. Bu yaklaşımın sorunu, kodun dahili olarak tamamen incelenmeden önce her zaman GitHub'a gönderilmesidir. Açık kaynak deposunda değişiklikler yapılana ve yeni bir dahili dağıtım yapılana kadar herhangi bir üretim sorunu bulamayacağız. Kötü dağıtım durumunda, suçluyu belirlemek de çok zordu çünkü değişiklikler gruplar halinde yapılıyordu.
Ek olarak bu model, hızlı yinelemeler gerektiren yeni özellikler geliştirirken ekibin verimliliğini azalttı, çünkü tüm değişikliklerin önce açık kaynak bir havuza, ardından da dahili bir havuza gönderilmesini zorunlu kılıyordu. İşlem süresini azaltmak için, gerekli düzeltme veya değişiklik ilk önce dahili depoda yapılabilirdi, ancak iş bu değişiklikleri açık kaynak depoya geri birleştirmeye geldiğinde, iki depo senkronize olmadığı için bu büyük bir sorun haline geldi.
Bu modelin paylaşılan platformlar, kütüphaneler veya altyapı projeleri için uygulanması, tam özellikli özel web uygulamalarına göre çok daha kolaydır. Ayrıca bu model, açık kaynak kodlu olarak ilk günden başlayan projeler için idealdir ancak WhereHows tamamen dahili bir web uygulaması olarak oluşturulmuştur. Tüm dahili bağımlılıkları tamamen soyutlamak gerçekten zordu, bu yüzden dahili çatalı korumamız gerekiyordu, ancak dahili çatalı korumak ve çoğunlukla açık kaynak geliştirmek pek işe yaramadı.
İkinci deneme: “Önce iç”
**İkinci bir girişim olarak, çoğu geliştirmenin şirket içinde gerçekleştiği ve açık kaynak kodunda düzenli olarak değişikliklerin yapıldığı "önce şirket içi" geliştirme modeline geçtik. Her ne kadar bu model bizim kullanım durumumuz için en uygun model olsa da, doğası gereği bazı sorunları da var. Tüm farklılıkları doğrudan açık kaynak deposuna göndermek ve daha sonra birleştirme çakışmalarını çözmeye çalışmak bir seçenektir ancak zaman alıcıdır. Çoğu durumda geliştiriciler, kodlarını her incelediklerinde bunu yapmamaya çalışırlar. Sonuç olarak, bu işlem toplu olarak çok daha az sıklıkta yapılacak ve dolayısıyla birleştirme çakışmalarının daha sonra çözülmesi daha zor hale gelecektir.
Üçüncü kez işe yaradı!
Yukarıda bahsedilen iki başarısız deneme, WhereHows GitHub deposunun uzun süre güncelliğini yitirmesine neden oldu. Ekip, ürünün özelliklerini ve mimarisini geliştirmeye devam etti; böylece WhereHows for LinkedIn'in dahili sürümü, açık kaynak sürümünden daha gelişmiş hale geldi. Hatta yeni bir adı bile vardı: DataHub. Ekip, önceki başarısız girişimlere dayanarak ölçeklenebilir, uzun vadeli bir çözüm geliştirmeye karar verdi.
Herhangi bir yeni açık kaynak projesi için LinkedIn'in açık kaynak ekibi, projenin modüllerinin tamamen açık kaynakta geliştirildiği bir geliştirme modeli önerir ve destekler. Sürümü oluşturulmuş yapıtlar genel bir depoya dağıtılır ve ardından kullanılarak dahili bir LinkedIn yapıtında tekrar kontrol edilir. . Bu geliştirme modelini takip etmek yalnızca açık kaynak kullananlar için iyi olmakla kalmaz, aynı zamanda daha modüler, genişletilebilir ve takılabilir bir mimariyle sonuçlanır.
Ancak DataHub gibi olgun bir arka uç uygulamasının bu duruma ulaşması önemli miktarda zaman gerektirecektir. Bu aynı zamanda, tüm iç bağımlılıklar tamamen soyutlanmadan önce, tam olarak çalışan bir uygulamanın açık kaynak olarak kullanılması olasılığını da engeller. Bu nedenle açık kaynak katkılarını daha hızlı ve çok daha az zahmetle yapmamıza yardımcı olacak araçlar geliştirdik. Bu çözüm hem meta veri ekibine (DataHub geliştiricisi) hem de açık kaynak topluluğuna fayda sağlar. Aşağıdaki bölümlerde bu yeni yaklaşım tartışılacaktır.
Açık Kaynak Yayıncılık Otomasyonu
Metadata ekibinin açık kaynak DataHub'a yönelik en son yaklaşımı, dahili kod tabanını ve açık kaynak deposunu otomatik olarak senkronize eden bir araç geliştirmektir. Bu araç setinin üst düzey özellikleri şunları içerir:
- LinkedIn kodunu açık kaynakla/açık kaynaktan senkronize edin, benzer .
- Lisans başlığı oluşturma, buna benzer .
- Dahili taahhüt günlüklerinden açık kaynak taahhüt günlüklerini otomatik olarak oluşturun.
- Açık kaynak yapılarını bozan dahili değişiklikleri şu şekilde önleyin: .
Aşağıdaki alt bölümlerde, ilginç sorunları olan yukarıda bahsedilen işlevler incelenecektir.
Kaynak kodu senkronizasyonu
Tek bir GitHub deposu olan DataHub'un açık kaynak sürümünün aksine, DataHub'un LinkedIn sürümü birden fazla havuzun (dahili olarak adlandırılır) birleşimidir. ). DataHub arayüzü, meta veri modeli kitaplığı, meta veri ambarı arka uç hizmeti ve akış işleri, LinkedIn'deki ayrı depolarda bulunur. Ancak açık kaynak kullanıcılarının işini kolaylaştırmak amacıyla DataHub'ın açık kaynak sürümü için tek bir havuzumuz var.
Şekil 1: Depolar arasındaki senkronizasyon LinkedIn Veri Merkezi ve tek bir depo Veri Merkezi açık kaynak
Otomatik oluşturma, gönderme ve çekme iş akışlarını desteklemek için yeni aracımız otomatik olarak her kaynak dosyaya karşılık gelen dosya düzeyinde bir eşleme oluşturur. Ancak araç seti ilk yapılandırmayı gerektirir ve kullanıcıların aşağıda gösterildiği gibi yüksek düzeyli bir modül eşlemesi sağlaması gerekir.
{
"datahub-dao": [
"${datahub-frontend}/datahub-dao"
],
"gms/impl": [
"${dataset-gms}/impl",
"${user-gms}/impl"
],
"metadata-dao": [
"${metadata-models}/metadata-dao"
],
"metadata-builders": [
"${metadata-models}/metadata-builders"
]
}Modül düzeyinde eşleme, anahtarları açık kaynak deposundaki hedef modüller ve değerleri LinkedIn depolarındaki kaynak modüllerin listesi olan basit bir JSON'dur. Açık kaynak deposundaki herhangi bir hedef modül, herhangi bir sayıda kaynak modül tarafından beslenebilir. Kaynak modüllerdeki depoların dahili adlarını belirtmek için şunu kullanın: Bash tarzında. Araçlar, modül düzeyinde bir eşleme dosyası kullanarak, ilişkili dizinlerdeki tüm dosyaları tarayarak dosya düzeyinde bir eşleme dosyası oluşturur.
{
"${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
"${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
"${metadata-models}/metadata-builders/build.gradle": null,
}Dosya düzeyinde eşleme, araçlar tarafından otomatik olarak oluşturulur; ancak kullanıcı tarafından manuel olarak da güncellenebilir. Bu, LinkedIn kaynak dosyasının açık kaynak deposundaki bir dosyayla 1:1 eşlenmesidir. Dosya ilişkilendirmelerinin bu otomatik oluşturulmasıyla ilişkili birkaç kural vardır:
- Açık kaynaktaki bir hedef modül için birden fazla kaynak modülü olması durumunda, çatışmalar ortaya çıkabilir, örneğin; birden fazla kaynak modülde mevcut. Bir çatışma çözümü stratejisi olarak araçlarımız varsayılan olarak "sonuncu olan kazanır" seçeneğini kullanır.
- "null", kaynak dosyanın açık kaynak havuzunun parçası olmadığı anlamına gelir.
- Her açık kaynak gönderimi veya çıkarılmasından sonra bu eşleme otomatik olarak güncellenir ve bir anlık görüntü oluşturulur. Bu, son eylemden bu yana kaynak kodunda yapılan ekleme ve silme işlemlerini tanımlamak için gereklidir.
Taahhüt günlükleri oluşturma
Açık kaynak taahhütlerine yönelik taahhüt günlükleri, dahili depoların taahhüt günlüklerinin birleştirilmesiyle otomatik olarak oluşturulur. Aşağıda, aracımız tarafından oluşturulan taahhüt günlüğünün yapısını gösteren örnek bir taahhüt günlüğü bulunmaktadır. Bir taahhüt, kaynak depolarının hangi sürümlerinin söz konusu taahhütte paketlendiğini açıkça belirtir ve taahhüt günlüğünün bir özetini sağlar. Şunu kontrol et araç setimiz tarafından oluşturulan bir taahhüt günlüğünün gerçek bir örneğini kullanarak.
metadata-models 29.0.0 -> 30.0.0
Added aspect model foo
Fixed issue bar
dataset-gms 2.3.0 -> 2.3.4
Added rest.li API to serve foo aspect
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Bağımlılık testi
LinkedIn'de var Bu, dahili bir çoklu üründe yapılan değişikliklerin bağımlı çoklu ürünlerin montajını bozmamasını sağlamaya yardımcı olur. Açık kaynak DataHub deposu çoklu ürün değildir ve herhangi bir çoklu ürüne doğrudan bağımlı olamaz, ancak açık kaynak DataHub kaynak kodunu getiren çoklu ürün sarmalayıcının yardımıyla bu bağımlılık testini yine de kullanabiliriz Bu nedenle, açık kaynak DataHub deposunu besleyen çoklu ürünlerden herhangi birinde yapılan herhangi bir değişiklik (daha sonra ortaya çıkabilecek), kabuk çoklu ürününde bir derleme olayını tetikler. Bu nedenle, sarmalayıcı ürün oluşturmada başarısız olan herhangi bir değişiklik, orijinal ürünü işleme koymadan önceki testlerde başarısız olur ve geri alınır.
Bu, açık kaynak yapısını bozan ve bunu taahhüt zamanında tespit eden herhangi bir dahili taahhüdün önlenmesine yardımcı olan kullanışlı bir mekanizmadır. Bu olmadan, DataHub açık kaynak deposundaki dahili değişiklikleri toplu olarak yaptığımız için, hangi dahili işlemin açık kaynak kodlu veri havuzu yapısının başarısız olmasına neden olduğunu belirlemek oldukça zor olacaktır.
Açık kaynak DataHub ile üretim versiyonumuz arasındaki farklar
Bu noktaya kadar DataHub depolarının iki sürümünü senkronize etmeye yönelik çözümümüzü tartıştık ancak ilk etapta neden iki farklı geliştirme akışına ihtiyaç duyduğumuzun nedenlerini hala özetlemedik. Bu bölümde DataHub'ın public sürümü ile LinkedIn sunucularındaki üretim sürümü arasındaki farkları listeleyip, bu farklılıkların nedenlerini açıklayacağız.
Tutarsızlıkların bir kaynağı, üretim sürümümüzün, LinkedIn'in Offspring'i (LinkedIn'in dahili bağımlılık enjeksiyon çerçevesi) gibi henüz açık kaynak olmayan kodlara bağımlılıklara sahip olmasından kaynaklanmaktadır. Offspring, dinamik yapılandırmayı yönetmek için tercih edilen yöntem olduğundan dahili kod tabanlarında yaygın olarak kullanılır. Ancak açık kaynak değil; bu nedenle açık kaynak DataHub'a açık kaynak alternatifleri bulmamız gerekiyordu.
Başka nedenler de var. LinkedIn'in ihtiyaçlarına yönelik meta veri modeline yönelik uzantılar oluşturduğumuzdan, bu uzantılar genellikle LinkedIn'e çok özeldir ve diğer ortamlar için doğrudan geçerli olmayabilir. Örneğin, katılımcı kimlikleri ve diğer eşleşen meta veri türleri için çok özel etiketlerimiz var. Bu nedenle artık bu uzantıları DataHub'ın açık kaynak meta veri modelinden hariç tuttuk. Toplulukla etkileşime geçip ihtiyaçlarını anladığımızda, gerektiğinde bu uzantıların ortak açık kaynaklı sürümleri üzerinde çalışacağız.
Açık kaynak topluluğu için kullanım kolaylığı ve daha kolay uyarlama, DataHub'ın iki sürümü arasındaki bazı farklılıklara da ilham kaynağı oldu. Akış işleme altyapısındaki farklılıklar buna iyi bir örnektir. Dahili sürümümüz yönetilen bir akış işleme çerçevesi kullansa da, başka bir altyapı bağımlılığı oluşturmayı önlediği için açık kaynak sürümü için yerleşik (bağımsız) akış işlemeyi kullanmayı seçtik.
Farkın bir başka örneği, açık kaynak uygulamasında birden fazla GMS yerine tek bir GMS'nin (Genelleştirilmiş Meta Veri Deposu) bulunmasıdır. GMA (Genelleştirilmiş Meta Veri Mimarisi), DataHub'un arka uç mimarisinin adıdır ve GMS, GMA bağlamındaki meta veri deposudur. GMA, her veri yapısını (ör. veri kümeleri, kullanıcılar vb.) kendi meta veri deposuna dağıtmanıza veya veri yapısı eşlemesini içeren kayıt defteri olduğu sürece birden fazla veri yapısını tek bir meta veri deposunda saklamanıza olanak tanıyan çok esnek bir mimaridir. GMS güncellendi. Kullanım kolaylığı için, tüm farklı veri yapılarını açık kaynak DataHub'da saklayan tek bir GMS örneğini seçtik.
İki uygulama arasındaki farkların tam listesi aşağıdaki tabloda verilmiştir.
Ürün Özellikleri
LinkedIn DataHub
Açık Kaynak DataHub
Desteklenen Veri Yapıları
1) Veri Kümeleri 2) Kullanıcılar 3) Metrikler 4) ML Özellikleri 5) Grafikler 6) Kontrol Panelleri
1) Veri Kümeleri 2) Kullanıcılar
Veri Kümeleri için Desteklenen Meta Veri Kaynakları
1) 2) Kanepe tabanı 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektör 14)
Hive Kafka RDBMS
Pub-sub
Konfluent Kafka
Akış İşleme
Yönetilen
Gömülü (bağımsız)
Bağımlılık Ekleme ve Dinamik Yapılandırma
LinkedIn Yavrusu
Yapı Aletleri
Ligradle (LinkedIn'in dahili Gradle sarmalayıcısı)
CI / CD
CRT (LinkedIn'in dahili CI/CD'si)
ve
Meta Veri Depoları
Dağıtılmış çoklu GMS: 1) Veri Seti GMS'si 2) Kullanıcı GMS'si 3) Metrik GMS 4) Özellik GMS'si 5) Harita/Gösterge Paneli GMS'si
Aşağıdakiler için tek GMS: 1) Veri Kümeleri 2) Kullanıcılar
Docker kapsayıcılarındaki mikro hizmetler
uygulama dağıtımını ve dağıtımını basitleştirir . DataHub'daki hizmetin her parçası, Kafka gibi altyapı bileşenleri de dahil olmak üzere açık kaynaktır. , и , kendi Docker görüntüsüne sahiptir. Kullandığımız Docker kapsayıcılarını düzenlemek için .
Şekil 2: Mimari Veri Merkezi *açık kaynak**
Yukarıdaki görselde DataHub'ın üst düzey mimarisini görebilirsiniz. Altyapı bileşenlerinin yanı sıra dört farklı Docker konteyneri vardır:
datahub-gms: meta veri depolama hizmeti
datahub-ön uç: uygulama DataHub arayüzüne hizmet ediyor.
datahub-mce-tüketici: uygulama , meta veri değiştirme olayı (MCE) akışını kullanan ve meta veri deposunu güncelleyen.
datahub-mae-tüketici: uygulama Bir meta veri denetim olayı akışını (MAE) kullanan ve bir arama dizini ve grafik veritabanı oluşturan.
Açık kaynak kod deposu belgeleri ve çeşitli hizmetlerin işlevleri hakkında daha ayrıntılı bilgi içerir.
DataHub'daki CI/CD açık kaynaktır
Açık kaynak DataHub deposunun kullandığı sürekli entegrasyon için sürekli dağıtım için. Her ikisinin de iyi bir GitHub entegrasyonu vardır ve kurulumu kolaydır. Topluluk veya özel şirketler tarafından geliştirilen çoğu açık kaynak altyapısı için (ör. ), topluluk tarafından kullanım kolaylığı sağlamak amacıyla Docker görüntüleri oluşturulur ve Docker Hub'a dağıtılır. Docker Hub'da bulunan herhangi bir Docker görüntüsü basit bir komutla kolayca kullanılabilir .
DataHub açık kaynak deposuna yapılan her taahhütte, tüm Docker görüntüleri otomatik olarak oluşturulur ve "en son" etiketiyle Docker Hub'a dağıtılır. Docker Hub bazılarıyla yapılandırılmışsa , açık kaynak deposundaki tüm etiketler aynı zamanda Docker Hub'da karşılık gelen etiket adlarıyla birlikte yayınlanır.
DataHub'ı kullanma
çok basittir ve üç basit adımdan oluşur:
- Açık kaynak deposunu klonlayın ve hızlı bir başlangıç için sağlanan docker-compose betiğini kullanarak tüm Docker kapsayıcılarını docker-compose ile çalıştırın.
- Depoda sağlanan örnek verileri, yine sağlanan komut satırı aracını kullanarak indirin.
- Tarayıcınızda DataHub'a göz atın.
Aktif Olarak Takip Ediliyor hızlı sorular için de yapılandırılmıştır. Kullanıcılar doğrudan GitHub deposunda da sorunlar oluşturabilir. En önemlisi, tüm geri bildirimleri ve önerileri memnuniyetle karşılıyor ve takdir ediyoruz!
Gelecek için planlar
Şu anda açık kaynak DataHub'a yönelik her altyapı veya mikro hizmet, bir Docker konteyneri olarak oluşturulmuştur ve tüm sistem, Docker konteyneri kullanılarak yönetilmektedir. . Popülerliği ve yaygınlığı göz önüne alındığında yakın gelecekte Kubernetes tabanlı bir çözüm de sunmak istiyoruz.
Ayrıca DataHub'ı aşağıdaki gibi genel bir bulut hizmetine dağıtmak için anahtar teslim bir çözüm sağlamayı planlıyoruz: , veya . LinkedIn'in Azure'a geçişine ilişkin son duyuru göz önüne alındığında, bu, meta veri ekibinin dahili öncelikleriyle uyumlu olacaktır.
Son olarak, DataHub alfalarını derecelendiren ve sorunları tespit etmemize ve belgeleri geliştirmemize yardımcı olan, açık kaynak topluluğundaki DataHub'u ilk benimseyenlere teşekkür ederiz.
Kaynak: habr.com