Нээлттэй эх сурвалжийн DataHub: LinkedIn-ийн мета өгөгдөл хайх, илрүүлэх платформ
Өгөгдөлд тулгуурласан шийдвэр гаргахын тулд их хэмжээний өгөгдөлд тулгуурладаг аливаа компанид хэрэгтэй мэдээллээ хурдан олох нь чухал юм. Энэ нь өгөгдөл хэрэглэгчдийн (шинжээчид, машин сургалтын хөгжүүлэгчид, өгөгдөл судлаачид, мэдээллийн инженерүүд гэх мэт) бүтээмжид нөлөөлөөд зогсохгүй, чанарын машин сургалтын (ML) дамжуулах шугамаас хамаарах эцсийн бүтээгдэхүүнүүдэд шууд нөлөөлдөг. Нэмж дурдахад, машин сургалтын платформыг хэрэгжүүлэх, бүтээх хандлага нь мэдээжийн хэрэг: онцлог, загвар, хэмжигдэхүүн, өгөгдлийн багц гэх мэтийг дотооддоо илрүүлэх арга тань юу вэ гэсэн асуултыг төрүүлдэг.
Энэ нийтлэлд бид нээлттэй лицензийн дагуу мэдээллийн эх сурвалжийг хэрхэн нийтэлсэн тухай ярих болно Төслийн эхэн үеэс эхлэн мета өгөгдөл хайх, илрүүлэх платформ дээр . LinkedIn нь нээлттэй эхийн хувилбараас тусдаа DataHub-ийн өөрийн хувилбарыг хадгалдаг. Бидэнд яагаад хоёр тусдаа хөгжүүлэлтийн орчин хэрэгтэй байгааг тайлбарлаж, дараа нь нээлттэй эхийн WhereHow-ийг ашиглах анхны арга барилын талаар ярилцаж, DataHub-ийн дотоод (үйлдвэрлэлийн) хувилбарыг дээрх хувилбартай харьцуулах болно. . Бид хоёр репозиторыг синхрончлох үүднээс нээлттэй эхийн шинэчлэлтүүдийг түлхэж, хүлээн авах шинэ автомат шийдлийнхээ талаар дэлгэрэнгүй хуваалцах болно. Эцэст нь бид нээлттэй эхийн DataHub-г хэрхэн ашиглаж эхлэх зааварчилгааг өгч, түүний архитектурын талаар товч ярих болно.
NowHub нь DataHub болсон!
LinkedIn-ийн мета өгөгдлийн баг өмнө нь танилцуулсан (WhereHow-ийн залгамжлагч), LinkedIn-ийн хайлт, мета өгөгдөл илрүүлэх платформ, мөн үүнийг нээх төлөвлөгөөгөө хуваалцсан. Энэ мэдэгдлийн дараахан бид DataHub-ийн альфа хувилбарыг гаргаж, олон нийтэд түгээсэн. Түүнээс хойш бид хадгалах санд байнга хувь нэмрээ оруулж, хамгийн их хүссэн функцүүдийг нэмж, асуудлыг шийдвэрлэхийн тулд сонирхож буй хэрэглэгчидтэй хамтран ажиллаж байна. Одоо бид албан ёсны хувилбарыг зарлаж байгаадаа баяртай байна .
Нээлттэй эхийн хандлагууд
LinkedIn-ийн өгөгдөл, хаанаас ирснийг хайж олох анхны портал WhereHows нь дотоод төсөл хэлбэрээр эхэлсэн; мета өгөгдлийн баг үүнийг нээсэн . Түүнээс хойш баг нь үргэлж хоёр өөр кодын баазыг хадгалсаар ирсэн бөгөөд нэг нь нээлттэй эх сурвалж, нөгөө нь LinkedIn-ийн дотоод хэрэглээнд зориулагдсан байдаг - учир нь LinkedIn-ийн хэрэглээний тохиолдлуудад зориулж боловсруулсан бүх бүтээгдэхүүний онцлог нь ерөнхийдөө өргөн хүрээний үзэгчдэд хэрэглэгдэх боломжгүй байсан. Нэмж хэлэхэд, WhereHows нь нээлттэй эх сурвалж биш зарим дотоод хамааралтай (дэд бүтэц, номын сан гэх мэт). Дараагийн жилүүдэд WhereHows олон давталт, хөгжлийн мөчлөгийг туулсан нь хоёр кодын синхрончлолыг хадгалах нь том сорилт болсон. Мета өгөгдлийн баг олон жилийн турш дотоод болон нээлттэй эхийн хөгжүүлэлтийг синхрончлохыг хичээсэн янз бүрийн арга барилыг туршиж үзсэн.
Эхний оролдлого: "Эхлээд нээлттэй эх сурвалж"
Бид эхлээд "нээлттэй эх сурвалжийн эхний" хөгжүүлэлтийн загварыг дагаж мөрдөж байсан бөгөөд ихэнх хөгжүүлэлт нь нээлттэй эхийн агуулахад хийгддэг бөгөөд дотоод байршуулалтад зориулж өөрчлөлтүүд хийгдсэн байдаг. Энэ аргын асуудал нь кодыг дотооддоо бүрэн хянаж үзэхээс өмнө эхлээд GitHub руу шилжүүлдэгт оршино. Нээлттэй эхийн агуулахаас өөрчлөлт хийж, шинэ дотоод байршуулалт хийх хүртэл бид үйлдвэрлэлийн ямар ч асуудал олохгүй. Муу байршуулсан тохиолдолд багцаар нь өөрчлөлт оруулсан тул буруутанг тодорхойлоход бас маш хэцүү байсан.
Нэмж дурдахад, энэ загвар нь бүх өөрчлөлтийг эхлээд нээлттэй эхийн репозитор руу түлхэж, дараа нь дотоод репозитор руу шилжүүлэхийг албадсан тул хурдан давталт хийх шаардлагатай шинэ функцуудыг хөгжүүлэх үед багийн бүтээмжийг бууруулсан. Боловсруулах хугацааг багасгахын тулд шаардлагатай засвар эсвэл өөрчлөлтийг эхлээд дотоод репозитор дээр хийж болох боловч хоёр репозитор синхрончлолгүй байсан тул эдгээр өөрчлөлтүүдийг нээлттэй эхийн агуулах руу буцаан нэгтгэх үед энэ нь маш том асуудал болсон.
Энэ загвар нь бүрэн функцтэй захиалгат вэб программуудаас илүү хуваалцсан платформ, номын сан эсвэл дэд бүтцийн төслүүдэд хэрэгжүүлэхэд илүү хялбар байдаг. Нэмж дурдахад, энэ загвар нь эхний өдрөөсөө нээлттэй эх сурвалжийг эхлүүлдэг төслүүдэд тохиромжтой, гэхдээ WhereHows нь бүрэн дотоод вэб програм хэлбэрээр бүтээгдсэн. Бүх дотоод хамаарлыг бүрэн арилгах нь үнэхээр хэцүү байсан тул бид дотоод сэрээгээ хадгалах шаардлагатай байсан ч дотоод сэрээгээ хадгалж, ихэвчлэн нээлттэй эхийг хөгжүүлэх нь тийм ч сайн үр дүнд хүрсэнгүй.
Хоёр дахь оролдлого: "Эхлээд дотоод"
**Хоёр дахь оролдлого болгон бид "дотоод анхны" хөгжлийн загвар руу шилжсэн бөгөөд ихэнх хөгжүүлэлт нь дотооддоо явагддаг бөгөөд нээлттэй эх кодыг тогтмол өөрчилж байдаг. Хэдийгээр энэ загвар нь бидний хэрэглээнд хамгийн тохиромжтой боловч төрөлхийн асуудалтай байдаг. Бүх ялгааг нээлттэй эхийн репозитор руу шууд түлхэж, дараа нь нэгтгэх зөрчлийг дараа нь шийдвэрлэхийг оролдох нь сонголт боловч цаг хугацаа их шаарддаг. Ихэнх тохиолдолд хөгжүүлэгчид өөрсдийн кодыг шалгах болгондоо үүнийг хийхгүй байхыг хичээдэг. Үүний үр дүнд үүнийг бага багаар, багцаар хийх бөгөөд ингэснээр дараа нь нэгтгэх зөрчлийг шийдвэрлэхэд илүү хэцүү болно.
Гурав дахь удаагаа ажилласан!
Дээр дурдсан хоёр амжилтгүй оролдлого нь WhereHows GitHub репозиторыг удаан хугацаанд хуучирсан хэвээр үлдээсэн. Баг нь бүтээгдэхүүний онцлог, архитектурыг үргэлжлүүлэн сайжруулснаар LinkedIn-д зориулсан WhereHow-ийн дотоод хувилбар нь нээлттэй эхийн хувилбараас илүү дэвшилтэт болсон. Тэр ч байтугай шинэ нэртэй болсон - DataHub. Өмнө нь бүтэлгүйтсэн оролдлогууд дээр үндэслэн баг нь өргөтгөх боломжтой, урт хугацааны шийдлийг боловсруулахаар шийдсэн.
Аливаа шинэ нээлттэй эхийн төслийн хувьд LinkedIn-ийн нээлттэй эх сурвалжийн баг төслийн модулиудыг бүхэлд нь нээлттэй эх сурвалжаар боловсруулсан хөгжлийн загварыг зөвлөж, дэмждэг. Хувилбартай олдворуудыг нийтийн репозиторт байршуулж, дараа нь дотоод LinkedIn олдвор руу дахин шалгана. . Энэхүү хөгжүүлэлтийн загварыг дагах нь зөвхөн нээлттэй эхийг ашигладаг хүмүүст ашигтай төдийгүй илүү модульчлагдсан, өргөтгөх боломжтой, залгах боломжтой архитектурыг бий болгодог.
Гэсэн хэдий ч DataHub гэх мэт төлөвшсөн арын программ нь энэ төлөвт хүрэхийн тулд ихээхэн цаг хугацаа шаардах болно. Энэ нь бүх дотоод хамаарлыг бүрэн арилгахаас өмнө нээлттэй эх үүсвэрээр бүрэн ажиллаж хэрэгжүүлэх боломжийг үгүйсгэдэг. Тийм ч учраас бид нээлттэй эх сурвалжийг илүү хурдан бөгөөд хамаагүй бага өвдөлтөөр оруулахад туслах хэрэгслүүдийг боловсруулсан. Энэхүү шийдэл нь мета өгөгдлийн баг (DataHub хөгжүүлэгч) болон нээлттэй эх сурвалжийн нийгэмлэгийн аль алинд нь ашигтай. Дараах хэсгүүдэд энэ шинэ хандлагын талаар ярилцах болно.
Нээлттэй эхийн хэвлэлийн автоматжуулалт
Мета өгөгдлийн багийн нээлттэй эхийн DataHub-д хандах хамгийн сүүлийн арга бол дотоод кодын сан болон нээлттэй эхийн агуулахыг автоматаар синк хийх хэрэгсэл боловсруулах явдал юм. Энэ хэрэгслийн дээд түвшний онцлогууд нь:
- Үүнтэй төстэй LinkedIn кодыг нээлттэй эх сурвалжтай синк хийнэ үү .
- Лицензийн толгой хэсгийг үүсгэх, ижил төстэй .
- Дотоод амлалтын бүртгэлээс нээлттэй эх сурвалжийн бүртгэлийг автоматаар үүсгэнэ.
- Нээлттэй эхийн бүтцийг эвдэж буй дотоод өөрчлөлтүүдээс урьдчилан сэргийлэх .
Дараах дэд хэсгүүд нь дээр дурьдсан сонирхолтой асуудлуудтай функцуудыг судлах болно.
Эх кодын синхрончлол
Ганц GitHub репозитор болох DataHub-ийн нээлттэй эхийн хувилбараас ялгаатай нь DataHub-ийн LinkedIn хувилбар нь олон репозиторуудын хослол юм (дотоод гэж нэрлэдэг) ). DataHub интерфэйс, мета өгөгдлийн загварын номын сан, мета өгөгдлийн агуулахын арын үйлчилгээ болон урсгалын ажлууд нь LinkedIn дээрх тусдаа агуулахуудад байрладаг. Гэсэн хэдий ч, нээлттэй эхийн хэрэглэгчдэд хялбар болгохын тулд бид DataHub-ийн нээлттэй эхийн хувилбарт зориулсан ганц репозитортой болсон.
Зураг 1: Хадгалах газар хоорондын синхрончлол LinkedIn DataHub ба нэг репозитор DataHub нээлттэй эх сурвалж
Автоматжуулсан бүтээх, түлхэх, татах ажлын урсгалыг дэмжихийн тулд манай шинэ хэрэгсэл нь эх файл бүрт тохирох файлын түвшний зураглалыг автоматаар үүсгэдэг. Гэсэн хэдий ч, багаж хэрэгсэл нь анхны тохиргоог шаарддаг бөгөөд хэрэглэгчид доор үзүүлсэн шиг өндөр түвшний модулийн зураглалыг өгөх ёстой.
{
"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"
]
}Модулийн түвшний зураглал нь энгийн JSON бөгөөд түлхүүрүүд нь нээлттэй эхийн агуулах дахь зорилтот модулиуд бөгөөд утгууд нь LinkedIn репозиторууд дахь эх модулиудын жагсаалт юм. Нээлттэй эхийн агуулах дахь аливаа зорилтот модулийг хэдэн ч тооны эх модулиар тэжээж болно. Эх модуль дахь хадгалах сангийн дотоод нэрийг зааж өгөхийн тулд ашиглана уу Баш маягаар. Модулийн түвшний зураглалын файлыг ашиглан хэрэгслүүд нь холбогдох директоруудын бүх файлыг сканнердах замаар файлын түвшний зураглалын файлыг үүсгэдэг.
{
"${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,
}Файлын түвшний зураглалыг хэрэгслээр автоматаар үүсгэдэг; Гэсэн хэдий ч үүнийг хэрэглэгч гараар шинэчлэх боломжтой. Энэ нь LinkedIn-ийн эх файлыг нээлттэй эхийн агуулах дахь файлд 1:1-ээр буулгасан зураглал юм. Файлын холбоог автоматаар үүсгэхтэй холбоотой хэд хэдэн дүрэм байдаг:
- Нээлттэй эх сурвалж дахь зорилтот модулийн олон эх үүсвэрийн модулиудын хувьд зөрчил үүсч болно, жишээлбэл, ижил , нэгээс олон эх модульд байгаа. Зөрчилдөөнийг шийдвэрлэх стратегийн хувьд манай хэрэгслүүд "сүүлийн нэг нь ялна" гэсэн сонголтыг хийдэг.
- "null" гэдэг нь эх файл нь нээлттэй эхийн репозиторийн хэсэг биш гэсэн үг юм.
- Нээлттэй эх сурвалжийг илгээх эсвэл задлах бүрийн дараа энэ зураглал автоматаар шинэчлэгдэж, хормын хувилбар үүсдэг. Энэ нь сүүлийн үйлдлээс хойш эх кодын нэмэлт, устгалыг тодорхойлоход шаардлагатай.
Үйлдлийн бүртгэл үүсгэх
Нээлттэй эх сурвалжийн амлалтад зориулсан логууд нь дотоод хадгалалтын бүртгэлийн бүртгэлийг нэгтгэснээр автоматаар үүсгэгддэг. Доорх нь манай хэрэглүүрийн үүсгэсэн бүртгэлийн бүртгэлийн бүтцийг харуулах жишээ бүртгэлийн бүртгэл юм. Амлалт нь тухайн амлалтад эх сурвалжийн репозиторуудын аль хувилбаруудыг багцалж байгааг тодорхой зааж өгөх ба үүргийн бүртгэлийн хураангуйг өгдөг. Үүнийг шалгаад үзээрэй Манай багаж хэрэгслээр үүсгэсэн бүртгэлийн бүртгэлийн бодит жишээг ашиглан.
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.0Хамааралтай байдлын туршилт
LinkedIn байна , энэ нь дотоод олон бүтээгдэхүүнд өөрчлөлт оруулах нь хамааралтай олон бүтээгдэхүүнүүдийн угсралтыг зөрчихгүй байхыг баталгаажуулахад тусалдаг. Нээлттэй эхийн DataHub репозитор нь олон бүтээгдэхүүн биш бөгөөд энэ нь ямар ч олон бүтээгдэхүүнээс шууд хамааралтай байж болохгүй, гэхдээ нээлттэй эхийн DataHub эх кодыг татаж авах олон бүтээгдэхүүний багцын тусламжтайгаар бид энэ хамаарлын тестийг ашиглах боломжтой хэвээр байна. Иймээс нээлттэй эхийн DataHub репозиторыг тэжээж буй олон бүтээгдэхүүнд гарсан аливаа өөрчлөлт (дараа нь ил гарч болзошгүй) нь бүрхүүлийн олон бүтээгдэхүүнд бүтээх үйл явдлыг өдөөдөг. Тиймээс, боодолтой бүтээгдэхүүнийг бүтээхэд амжилтгүй болсон аливаа өөрчлөлт нь анхны бүтээгдэхүүнийг хийхээс өмнө туршилтанд тэнцэхгүй бөгөөд буцаагдана.
Энэ нь нээлттэй эхийн бүтээцийг эвдэж, түүнийг гүйцэтгэх үед илрүүлдэг аливаа дотоод үйлдлээс урьдчилан сэргийлэх ашигтай механизм юм. Үүнгүйгээр, бид DataHub нээлттэй эхийн репозитор руу дотоод өөрчлөлтүүдийг багцлан хийдэг тул ямар дотоод үүрэг нь нээлттэй эхийн агуулах бүтэлгүйтсэнийг тодорхойлоход хэцүү байх болно.
Нээлттэй эхийн DataHub болон манай үйлдвэрлэлийн хувилбар хоорондын ялгаа
Өнөөдрийг хүртэл бид DataHub репозиторын хоёр хувилбарыг синхрончлох шийдлийнхээ талаар ярилцсан боловч эхний ээлжинд хоёр өөр хөгжлийн урсгал хэрэгтэй болсон шалтгааныг тайлбарлаагүй байна. Энэ хэсэгт бид DataHub-ийн нийтийн хувилбар болон LinkedIn сервер дээрх үйлдвэрлэлийн хувилбаруудын ялгааг жагсааж, эдгээр ялгааны шалтгааныг тайлбарлах болно.
Зөрчлийн нэг эх үүсвэр нь манай үйлдвэрлэлийн хувилбар нь LinkedIn-ийн Offspring (LinkedIn-ийн дотоод хамаарлын инжекторын хүрээ) гэх мэт хараахан нээлттэй эх сурвалж биш кодын хамааралтай байгаатай холбоотой юм. Төрөл нь динамик тохиргоог удирдахад илүүд үздэг арга учраас дотоод кодын санд өргөн хэрэглэгддэг. Гэхдээ энэ нь нээлттэй эх сурвалж биш юм; Тиймээс бид нээлттэй эх сурвалжийн DataHub-ийн нээлттэй эх сурвалжийг олох хэрэгтэй болсон.
Өөр шалтгаанууд бас бий. Бид LinkedIn-ийн хэрэгцээнд зориулж мета өгөгдлийн загварт өргөтгөлүүдийг бий болгож байгаа тул эдгээр өргөтгөлүүд нь ихэвчлэн LinkedIn-д маш өвөрмөц байдаг бөгөөд бусад орчинд шууд хамаарахгүй байж болно. Жишээлбэл, бид оролцогчийн ID болон бусад төрлийн мета өгөгдлийн хувьд маш тодорхой шошготой байдаг. Тиймээс бид DataHub-ийн нээлттэй эхийн мета өгөгдлийн загвараас эдгээр өргөтгөлүүдийг хассан. Бид олон нийттэй харилцаж, тэдний хэрэгцээ шаардлагыг ойлгохын хэрээр шаардлагатай бол эдгээр өргөтгөлүүдийн нийтлэг нээлттэй эхийн хувилбарууд дээр ажиллах болно.
Нээлттэй эх сурвалжийн нийгэмлэгт ашиглахад хялбар, дасан зохицоход хялбар байдал нь DataHub-ийн хоёр хувилбарын зарим ялгааг өдөөсөн. Урсгал боловсруулах дэд бүтцийн ялгаа нь үүний тод жишээ юм. Хэдийгээр манай дотоод хувилбар нь удирддаг урсгал боловсруулах тогтолцоог ашигладаг ч, бид өөр дэд бүтцийн хамаарлыг бий болгохоос зайлсхийдэг тул нээлттэй эхийн хувилбарт суулгасан (дангаараа) урсгал боловсруулалтыг ашиглахаар сонгосон.
Ялгаатай байдлын өөр нэг жишээ бол олон GMS биш харин нээлттэй эхийн хэрэгжилтэд нэг GMS (Ерөнхий мета өгөгдлийн дэлгүүр) байх явдал юм. GMA (Generalized Metadata Architecture) нь DataHub-ийн арын архитектурын нэр бөгөөд GMS нь GMA-ийн контекст дэх мета өгөгдлийн дэлгүүр юм. GMA нь өгөгдлийн бүтэц бүрийг (жишээ нь, өгөгдлийн багц, хэрэглэгчид гэх мэт) өөрийн мета өгөгдлийн санд түгээх, эсвэл өгөгдлийн бүтцийн зураглалыг агуулсан бүртгэлтэй бол олон өгөгдлийн бүтцийг нэг мета өгөгдлийн санд хадгалах боломжийг олгодог маш уян хатан архитектур юм. GMS шинэчлэгдсэн. Ашиглахад хялбар болгох үүднээс бид нээлттэй эхийн DataHub-д бүх өөр өөр өгөгдлийн бүтцийг хадгалдаг ганц GMS жишээг сонгосон.
Хоёр хэрэгжилтийн ялгааны бүрэн жагсаалтыг доорх хүснэгтэд үзүүлэв.
Бүтээгдэхүүний онцлог
LinkedIn DataHub
Нээлттэй эхийн DataHub
Дэмжигдсэн өгөгдлийн бүтэц
1) Өгөгдлийн багц 2) Хэрэглэгчид 3) Метрик 4) ML онцлог 5) График 6) Хяналтын самбар
1) Өгөгдлийн багц 2) Хэрэглэгчид
Мэдээллийн багцад зориулсан дэмжигдсэн мета өгөгдлийн эх сурвалжууд
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Кафка 8) MongoDB 9) MySQL 10) Oracle 11) 12) Өмнөх 12) 13) Терадата 13) Вектор 14)
Hive Kafka RDBMS
Pub-sub
Нийлсэн Кафка
Урсгал боловсруулах
Managed
Суулгасан (бие даасан)
Хамааралтай тарилга ба динамик тохиргоо
LinkedIn төл
Барилгын хэрэгсэл
Ligradle (LinkedIn-ийн дотоод Gradle боодол)
CI / CD
CRT (LinkedIn-ийн дотоод CI/CD)
болон
Мета мэдээллийн дэлгүүрүүд
Түгээмэл олон GMS: 1) Dataset GMS 2) Хэрэглэгчийн GMS 3) Metric GMS 4) Онцлог GMS 5) Chart/Chapboard GMS
Ганц GMS: 1) Өгөгдлийн багц 2) Хэрэглэгчид
Docker контейнер дахь бичил үйлчилгээ
програмыг ашиглах, түгээх ажлыг хялбаршуулдаг . DataHub дахь үйлчилгээний хэсэг бүр нь нээлттэй эх сурвалж бөгөөд үүнд Кафка, , и , өөрийн гэсэн Docker дүрстэй. Docker контейнеруудыг зохион байгуулахын тулд бид ашигласан .
Зураг 2: Архитектур DataHub *нээлттэй эх сурвалж**
Та дээрх зурган дээрээс DataHub-ийн өндөр түвшний архитектурыг харж болно. Дэд бүтцийн бүрэлдэхүүн хэсгүүдээс гадна дөрвөн өөр Docker контейнертэй:
datahub-gms: мета өгөгдөл хадгалах үйлчилгээ
datahub-frontend: програм , DataHub интерфэйсээр үйлчилдэг.
datahub-mce-хэрэглэгч: програм , энэ нь мета өгөгдлийн өөрчлөлтийн үйл явдал (MCE) дамжуулалтыг ашиглаж, мета өгөгдлийн санг шинэчилдэг.
datahub-mae-хэрэглэгч: програм , энэ нь мета өгөгдлийн аудитын үйл явдлын урсгалыг (MAE) ашигладаг бөгөөд хайлтын индекс болон график мэдээллийн санг үүсгэдэг.
Нээлттэй эхийн агуулахын баримт бичиг ба төрөл бүрийн үйлчилгээний чиг үүргийн талаар илүү дэлгэрэнгүй мэдээллийг агуулсан.
DataHub дээрх CI/CD нь нээлттэй эх сурвалж юм
Нээлттэй эхийн DataHub репозитор ашигладаг тасралтгүй нэгтгэх болон тасралтгүй байршуулах зориулалттай. Аль аль нь GitHub сайн интеграцтай бөгөөд тохируулахад хялбар байдаг. Олон нийтийн эсвэл хувийн компаниудын боловсруулсан ихэнх нээлттэй эхийн дэд бүтцийн хувьд (жишээ нь. ), Нийгэмлэг ашиглахад хялбар болгох үүднээс Docker дүрсүүдийг үүсгэж, Docker Hub-д байршуулдаг. Docker Hub-д олдсон аливаа Docker дүрсийг энгийн тушаалаар хялбархан ашиглаж болно .
DataHub нээлттэй эхийн репозиторыг ашиглах бүрдээ бүх Docker зургуудыг автоматаар бүтээж, Docker Hub-д "хамгийн сүүлийн үеийн" шошготойгоор байрлуулдаг. Хэрэв Docker Hub зарим нь тохируулагдсан бол , нээлттэй эхийн агуулах дахь бүх шошгуудыг Docker Hub-д харгалзах шошгоны нэрээр гаргадаг.
DataHub ашиглах
Энэ нь маш энгийн бөгөөд гурван энгийн алхамаас бүрдэнэ.
- Нээлттэй эхийн агуулахыг клон хийж, бүх Docker контейнеруудыг docker-compose-г ашиглан өгөгдсөн docker-compose скриптийг ашиглан хурдан эхлүүлэх боломжтой.
- Мөн өгөгдсөн тушаалын мөрийн хэрэгслийг ашиглан хадгалах санд өгсөн жишээ өгөгдлийг татаж авна уу.
- Хөтөч дээрээ DataHub-г үзээрэй.
Идэвхтэй хянадаг мөн хурдан асуултанд тохируулсан. Хэрэглэгчид GitHub репозитор дээр шууд асуудал үүсгэж болно. Хамгийн гол нь бид бүх санал хүсэлт, санал хүсэлтийг хүлээн авч, талархаж байна!
РџР »Р ° РЅС <РЅР ° Р ± САРРґЭсарС ‰ РμРμ
Одоогоор нээлттэй эхийн DataHub-д зориулсан бүх дэд бүтэц эсвэл микро үйлчилгээ нь Docker контейнер хэлбэрээр бүтээгдсэн бөгөөд системийг бүхэлд нь ашиглан зохион байгуулж байна. . Алдартай, өргөн тархсан байдлыг харгалзан үзвэл , бид ойрын ирээдүйд Kubernetes дээр суурилсан шийдлийг өгөхийг хүсч байна.
Мөн бид DataHub-ийг нийтийн үүлэн үйлчилгээнд ашиглах түлхүүр гардуулах шийдлийг өгөхөөр төлөвлөж байна , буюу . LinkedIn-ийг Azure руу шилжүүлсэн тухай саяхан зарласан тул энэ нь мета өгөгдлийн багийн дотоод тэргүүлэх чиглэлтэй нийцэх болно.
Эцэст нь хэлэхэд, DataHub-ийн альфа хувилбарыг үнэлж, бидэнд асуудлуудыг тодорхойлж, баримт бичгийг сайжруулахад тусалсан нээлттэй эх сурвалжийн нийгэмлэгийн DataHub-ийг анх нэвтрүүлсэн бүх хүмүүст баярлалаа.
Эх сурвалж: www.habr.com