ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್: ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಮೆಟಾಡೇಟಾ ಹುಡುಕಾಟ ಮತ್ತು ಡಿಸ್ಕವರಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್

ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್: ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಮೆಟಾಡೇಟಾ ಹುಡುಕಾಟ ಮತ್ತು ಡಿಸ್ಕವರಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್

ಡೇಟಾ-ಚಾಲಿತ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡಲು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರುವ ಯಾವುದೇ ಕಂಪನಿಗೆ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯುವುದು ಅತ್ಯಗತ್ಯ. ಇದು ಡೇಟಾ ಬಳಕೆದಾರರ (ವಿಶ್ಲೇಷಕರು, ಯಂತ್ರ ಕಲಿಕೆ ಡೆವಲಪರ್‌ಗಳು, ಡೇಟಾ ವಿಜ್ಞಾನಿಗಳು ಮತ್ತು ಡೇಟಾ ಎಂಜಿನಿಯರ್‌ಗಳು ಸೇರಿದಂತೆ) ಉತ್ಪಾದಕತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಲ್ಲದೆ, ಗುಣಮಟ್ಟದ ಯಂತ್ರ ಕಲಿಕೆ (ML) ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುವ ಅಂತಿಮ ಉತ್ಪನ್ನಗಳ ಮೇಲೆ ನೇರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಯಂತ್ರ ಕಲಿಕೆಯ ವೇದಿಕೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಥವಾ ನಿರ್ಮಿಸುವ ಪ್ರವೃತ್ತಿಯು ಸ್ವಾಭಾವಿಕವಾಗಿ ಪ್ರಶ್ನೆಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ: ವೈಶಿಷ್ಟ್ಯಗಳು, ಮಾದರಿಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು, ಡೇಟಾಸೆಟ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಆಂತರಿಕವಾಗಿ ಅನ್ವೇಷಿಸಲು ನಿಮ್ಮ ವಿಧಾನ ಯಾವುದು.

ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಮುಕ್ತ ಪರವಾನಗಿ ಅಡಿಯಲ್ಲಿ ಡೇಟಾ ಮೂಲವನ್ನು ಹೇಗೆ ಪ್ರಕಟಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ ಡೇಟಾಹಬ್ ನಮ್ಮ ಮೆಟಾಡೇಟಾ ಹುಡುಕಾಟ ಮತ್ತು ಅನ್ವೇಷಣೆ ವೇದಿಕೆಯಲ್ಲಿ, ಯೋಜನೆಯ ಆರಂಭಿಕ ದಿನಗಳಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಲ್ಲಿ ಹೇಗೆ. LinkedIn ಓಪನ್ ಸೋರ್ಸ್ ಆವೃತ್ತಿಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಡೇಟಾಹಬ್‌ನ ತನ್ನದೇ ಆದ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ನಮಗೆ ಎರಡು ಪ್ರತ್ಯೇಕ ಅಭಿವೃದ್ಧಿ ಪರಿಸರಗಳು ಏಕೆ ಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಮೂಲಕ ನಾವು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ನಂತರ ಓಪನ್ ಸೋರ್ಸ್ WhereHows ಅನ್ನು ಬಳಸುವ ಆರಂಭಿಕ ವಿಧಾನಗಳನ್ನು ಚರ್ಚಿಸಿ ಮತ್ತು ನಮ್ಮ ಆಂತರಿಕ (ಉತ್ಪಾದನೆ) ಆವೃತ್ತಿಯ DataHub ಅನ್ನು ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ GitHub. ಎರಡೂ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಸಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ತೆರೆದ ಮೂಲ ನವೀಕರಣಗಳನ್ನು ತಳ್ಳಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ನಮ್ಮ ಹೊಸ ಸ್ವಯಂಚಾಲಿತ ಪರಿಹಾರದ ಕುರಿತು ನಾವು ವಿವರಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂತಿಮವಾಗಿ, ನಾವು ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್ ಅನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಸೂಚನೆಗಳನ್ನು ನೀಡುತ್ತೇವೆ ಮತ್ತು ಅದರ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಚರ್ಚಿಸುತ್ತೇವೆ.

ವೇರ್‌ಹೌಸ್ ಈಗ ಡೇಟಾಹಬ್ ಆಗಿದೆ!

ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಮೆಟಾಡೇಟಾ ತಂಡವು ಹಿಂದೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ ಡೇಟಾಹಬ್ (ವೇರ್‌ಹೌಸ್‌ನ ಉತ್ತರಾಧಿಕಾರಿ), ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಹುಡುಕಾಟ ಮತ್ತು ಮೆಟಾಡೇಟಾ ಡಿಸ್ಕವರಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಅದನ್ನು ತೆರೆಯುವ ಯೋಜನೆಗಳನ್ನು ಹಂಚಿಕೊಂಡಿದೆ. ಈ ಪ್ರಕಟಣೆಯ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ನಾವು DataHub ನ ಆಲ್ಫಾ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಸಮುದಾಯದೊಂದಿಗೆ ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ. ಅಂದಿನಿಂದ, ನಾವು ನಿರಂತರವಾಗಿ ರೆಪೊಸಿಟರಿಗೆ ಕೊಡುಗೆ ನೀಡಿದ್ದೇವೆ ಮತ್ತು ಹೆಚ್ಚು ವಿನಂತಿಸಿದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಆಸಕ್ತ ಬಳಕೆದಾರರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ. ಅಧಿಕೃತ ಬಿಡುಗಡೆಯನ್ನು ಘೋಷಿಸಲು ನಾವು ಈಗ ಸಂತೋಷಪಡುತ್ತೇವೆ GitHub ನಲ್ಲಿ ಡೇಟಾಹಬ್.

ತೆರೆದ ಮೂಲ ವಿಧಾನಗಳು

ವೇರ್ಹೌಸ್, ಡೇಟಾವನ್ನು ಹುಡುಕಲು ಲಿಂಕ್ಡ್‌ಇನ್ನ ಮೂಲ ಪೋರ್ಟಲ್ ಮತ್ತು ಅದು ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ, ಆಂತರಿಕ ಯೋಜನೆಯಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು; ಮೆಟಾಡೇಟಾ ತಂಡವು ಅದನ್ನು ತೆರೆಯಿತು 2016 ರಲ್ಲಿ ಮೂಲ ಕೋಡ್. ಅಂದಿನಿಂದ, ತಂಡವು ಯಾವಾಗಲೂ ಎರಡು ವಿಭಿನ್ನ ಕೋಡ್‌ಬೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದೆ-ಒಂದು ಓಪನ್ ಸೋರ್ಸ್ ಮತ್ತು ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಆಂತರಿಕ ಬಳಕೆಗಾಗಿ-ಒಂದು ಲಿಂಕ್ಡ್‌ಇನ್ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಎಲ್ಲಾ ಉತ್ಪನ್ನ ವೈಶಿಷ್ಟ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವಿಶಾಲ ಪ್ರೇಕ್ಷಕರಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ವೇರ್‌ಹೌಸ್ ಕೆಲವು ಆಂತರಿಕ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆ (ಮೂಲಸೌಕರ್ಯ, ಗ್ರಂಥಾಲಯಗಳು, ಇತ್ಯಾದಿ) ಅದು ತೆರೆದ ಮೂಲವಲ್ಲ. ನಂತರದ ವರ್ಷಗಳಲ್ಲಿ, ವೇರ್‌ಹೌಸ್ ಅನೇಕ ಪುನರಾವರ್ತನೆಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಚಕ್ರಗಳ ಮೂಲಕ ಸಾಗಿತು, ಎರಡು ಕೋಡ್‌ಬೇಸ್‌ಗಳನ್ನು ಸಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸುವುದು ದೊಡ್ಡ ಸವಾಲಾಗಿದೆ. ಆಂತರಿಕ ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಅಭಿವೃದ್ಧಿಯನ್ನು ಸಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ಮೆಟಾಡೇಟಾ ತಂಡವು ವರ್ಷಗಳಲ್ಲಿ ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ.

ಮೊದಲ ಪ್ರಯತ್ನ: "ಮೊದಲು ತೆರೆದ ಮೂಲ"

ನಾವು ಆರಂಭದಲ್ಲಿ "ಓಪನ್ ಸೋರ್ಸ್ ಫಸ್ಟ್" ಡೆವಲಪ್‌ಮೆಂಟ್ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಹೆಚ್ಚಿನ ಅಭಿವೃದ್ಧಿಯು ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಆಂತರಿಕ ನಿಯೋಜನೆಗಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನದ ಸಮಸ್ಯೆಯೆಂದರೆ, ಕೋಡ್ ಅನ್ನು ಯಾವಾಗಲೂ ಆಂತರಿಕವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಅದನ್ನು GitHub ಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ. ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಿಂದ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವವರೆಗೆ ಮತ್ತು ಹೊಸ ಆಂತರಿಕ ನಿಯೋಜನೆಯನ್ನು ಮಾಡುವವರೆಗೆ, ನಾವು ಯಾವುದೇ ಉತ್ಪಾದನಾ ಸಮಸ್ಯೆಗಳನ್ನು ಕಾಣುವುದಿಲ್ಲ. ಕಳಪೆ ನಿಯೋಜನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗಿರುವುದರಿಂದ ಅಪರಾಧಿಯನ್ನು ನಿರ್ಧರಿಸುವುದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿತ್ತು.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಷಿಪ್ರ ಪುನರಾವರ್ತನೆಗಳ ಅಗತ್ಯವಿರುವ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಈ ಮಾದರಿಯು ತಂಡದ ಉತ್ಪಾದಕತೆಯನ್ನು ಕಡಿಮೆಗೊಳಿಸಿತು, ಏಕೆಂದರೆ ಇದು ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಮೊದಲು ತೆರೆದ ಮೂಲ ಭಂಡಾರಕ್ಕೆ ತಳ್ಳಲು ಮತ್ತು ನಂತರ ಆಂತರಿಕ ರೆಪೊಸಿಟರಿಗೆ ತಳ್ಳಲು ಒತ್ತಾಯಿಸಿತು. ಸಂಸ್ಕರಣಾ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಅಗತ್ಯವಿರುವ ಸರಿಪಡಿಸುವಿಕೆ ಅಥವಾ ಬದಲಾವಣೆಯನ್ನು ಮೊದಲು ಆಂತರಿಕ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಮಾಡಬಹುದು, ಆದರೆ ಆ ಬದಲಾವಣೆಗಳನ್ನು ತೆರೆದ ಮೂಲ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಮತ್ತೆ ವಿಲೀನಗೊಳಿಸುವಾಗ ಇದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಯಿತು ಏಕೆಂದರೆ ಎರಡು ರೆಪೊಸಿಟರಿಗಳು ಸಿಂಕ್ ಆಗಿಲ್ಲ.

ಪೂರ್ಣ-ವೈಶಿಷ್ಟ್ಯದ ಕಸ್ಟಮ್ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಿಂತ ಹಂಚಿಕೆಯ ಪ್ಲ್ಯಾಟ್‌ಫಾರ್ಮ್‌ಗಳು, ಲೈಬ್ರರಿಗಳು ಅಥವಾ ಮೂಲಸೌಕರ್ಯ ಯೋಜನೆಗಳಿಗೆ ಈ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈ ಮಾದರಿಯು ಮೊದಲ ದಿನದಿಂದ ಮುಕ್ತ ಮೂಲವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಯೋಜನೆಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ, ಆದರೆ ವೇರ್‌ಹೌಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಆಂತರಿಕ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನಂತೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಎಲ್ಲಾ ಆಂತರಿಕ ಅವಲಂಬನೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಮೂರ್ತಗೊಳಿಸುವುದು ನಿಜವಾಗಿಯೂ ಕಷ್ಟಕರವಾಗಿತ್ತು, ಆದ್ದರಿಂದ ನಾವು ಆಂತರಿಕ ಫೋರ್ಕ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕಾಗಿತ್ತು, ಆದರೆ ಆಂತರಿಕ ಫೋರ್ಕ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಮತ್ತು ಹೆಚ್ಚಾಗಿ ತೆರೆದ ಮೂಲವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಸಾಕಷ್ಟು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ.

ಎರಡನೇ ಪ್ರಯತ್ನ: "ಇನ್ನರ್ ಫಸ್ಟ್"

**ಎರಡನೆಯ ಪ್ರಯತ್ನವಾಗಿ, ನಾವು "ಆಂತರಿಕ ಮೊದಲ" ಅಭಿವೃದ್ಧಿ ಮಾದರಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದ್ದೇವೆ, ಅಲ್ಲಿ ಹೆಚ್ಚಿನ ಅಭಿವೃದ್ಧಿಯು ಆಂತರಿಕವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನಿಯಮಿತವಾಗಿ ತೆರೆದ ಮೂಲ ಕೋಡ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಈ ಮಾದರಿಯು ನಮ್ಮ ಬಳಕೆಯ ಪ್ರಕರಣಕ್ಕೆ ಸೂಕ್ತವಾಗಿದ್ದರೂ, ಇದು ಅಂತರ್ಗತ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಎಲ್ಲಾ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೇರವಾಗಿ ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಗೆ ತಳ್ಳುವುದು ಮತ್ತು ನಂತರ ವಿಲೀನ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದಾಗಲೆಲ್ಲಾ ಇದನ್ನು ಮಾಡದಿರಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಪರಿಣಾಮವಾಗಿ, ಇದನ್ನು ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಕಡಿಮೆ ಆಗಾಗ್ಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇದರಿಂದಾಗಿ ವಿಲೀನ ಸಂಘರ್ಷಗಳನ್ನು ನಂತರ ಪರಿಹರಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ.

ಮೂರನೇ ಬಾರಿ ಅದು ಕೆಲಸ ಮಾಡಿದೆ!

ಮೇಲೆ ತಿಳಿಸಲಾದ ಎರಡು ವಿಫಲ ಪ್ರಯತ್ನಗಳ ಪರಿಣಾಮವಾಗಿ WhereHows GitHub ರೆಪೊಸಿಟರಿಯು ದೀರ್ಘಕಾಲದವರೆಗೆ ಹಳೆಯದಾಗಿ ಉಳಿದಿದೆ. ತಂಡವು ಉತ್ಪನ್ನದ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಸುಧಾರಿಸುವುದನ್ನು ಮುಂದುವರೆಸಿತು, ಇದರಿಂದಾಗಿ ಲಿಂಕ್ಡ್‌ಇನ್‌ಗಾಗಿ ವೇರ್‌ಹೌಸ್‌ನ ಆಂತರಿಕ ಆವೃತ್ತಿಯು ಓಪನ್ ಸೋರ್ಸ್ ಆವೃತ್ತಿಗಿಂತ ಹೆಚ್ಚು ಮುಂದುವರಿದಿದೆ. ಇದು ಹೊಸ ಹೆಸರನ್ನು ಸಹ ಹೊಂದಿದೆ - DataHub. ಹಿಂದಿನ ವಿಫಲ ಪ್ರಯತ್ನಗಳ ಆಧಾರದ ಮೇಲೆ, ತಂಡವು ಸ್ಕೇಲೆಬಲ್, ದೀರ್ಘಕಾಲೀನ ಪರಿಹಾರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಿರ್ಧರಿಸಿತು.

ಯಾವುದೇ ಹೊಸ ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ, ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಓಪನ್ ಸೋರ್ಸ್ ತಂಡವು ಯೋಜನೆಯ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮುಕ್ತ ಮೂಲದಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಯನ್ನು ಸಲಹೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲಿಸುತ್ತದೆ. ಆವೃತ್ತಿಯ ಕಲಾಕೃತಿಗಳನ್ನು ಸಾರ್ವಜನಿಕ ಭಂಡಾರಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಆಂತರಿಕ ಲಿಂಕ್ಡ್‌ಇನ್ ಕಲಾಕೃತಿಯನ್ನು ಬಳಸಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ ಬಾಹ್ಯ ಲೈಬ್ರರಿ ವಿನಂತಿ (ELR). ಈ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುವುದು ತೆರೆದ ಮೂಲವನ್ನು ಬಳಸುವವರಿಗೆ ಮಾತ್ರ ಉತ್ತಮವಲ್ಲ, ಆದರೆ ಹೆಚ್ಚು ಮಾಡ್ಯುಲರ್, ವಿಸ್ತರಿಸಬಹುದಾದ ಮತ್ತು ಪ್ಲಗ್ ಮಾಡಬಹುದಾದ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಆದಾಗ್ಯೂ, DataHub ನಂತಹ ಪ್ರಬುದ್ಧ ಬ್ಯಾಕ್-ಎಂಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಈ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಲು ಗಮನಾರ್ಹ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಆಂತರಿಕ ಅವಲಂಬನೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಮೂರ್ತಗೊಳಿಸುವ ಮೊದಲು ತೆರೆದ ಸೋರ್ಸಿಂಗ್ ಸಂಪೂರ್ಣ ಕಾರ್ಯ ಅನುಷ್ಠಾನದ ಸಾಧ್ಯತೆಯನ್ನು ಇದು ತಡೆಯುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಮುಕ್ತ ಮೂಲ ಕೊಡುಗೆಗಳನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ಕಡಿಮೆ ನೋವಿನೊಂದಿಗೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುವ ಸಾಧನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಈ ಪರಿಹಾರವು ಮೆಟಾಡೇಟಾ ತಂಡ (ಡೇಟಾಹಬ್ ಡೆವಲಪರ್) ಮತ್ತು ಓಪನ್ ಸೋರ್ಸ್ ಸಮುದಾಯ ಎರಡಕ್ಕೂ ಪ್ರಯೋಜನವನ್ನು ನೀಡುತ್ತದೆ. ಮುಂದಿನ ವಿಭಾಗಗಳು ಈ ಹೊಸ ವಿಧಾನವನ್ನು ಚರ್ಚಿಸುತ್ತವೆ.

ಓಪನ್ ಸೋರ್ಸ್ ಪಬ್ಲಿಷಿಂಗ್ ಆಟೊಮೇಷನ್

ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್‌ಗೆ ಮೆಟಾಡೇಟಾ ತಂಡದ ಇತ್ತೀಚಿನ ವಿಧಾನವೆಂದರೆ ಆಂತರಿಕ ಕೋಡ್‌ಬೇಸ್ ಮತ್ತು ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿಂಕ್ ಮಾಡುವ ಸಾಧನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು. ಈ ಟೂಲ್ಕಿಟ್ನ ಉನ್ನತ ಮಟ್ಟದ ವೈಶಿಷ್ಟ್ಯಗಳು ಸೇರಿವೆ:

1. ಲಿಂಕ್ಡ್‌ಇನ್ ಕೋಡ್ ಅನ್ನು ಓಪನ್ ಸೋರ್ಸ್‌ನಿಂದ ಸಿಂಕ್ ಮಾಡಿ rsync.
2. ಪರವಾನಗಿ ಶಿರೋಲೇಖ ಉತ್ಪಾದನೆ, ಹೋಲುತ್ತದೆ ಅಪಾಚೆ ಇಲಿ.
3. ಆಂತರಿಕ ಕಮಿಟ್ ಲಾಗ್‌ಗಳಿಂದ ಓಪನ್ ಸೋರ್ಸ್ ಕಮಿಟ್ ಲಾಗ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಿ.
4. ತೆರೆದ ಮೂಲ ನಿರ್ಮಾಣಗಳನ್ನು ಒಡೆಯುವ ಆಂತರಿಕ ಬದಲಾವಣೆಗಳನ್ನು ತಡೆಯಿರಿ ಅವಲಂಬನೆ ಪರೀಕ್ಷೆ.

ಕೆಳಗಿನ ಉಪವಿಭಾಗಗಳು ಆಸಕ್ತಿದಾಯಕ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುವ ಮೇಲೆ ತಿಳಿಸಲಾದ ಕಾರ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ.

ಮೂಲ ಕೋಡ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್

ಒಂದೇ ಗಿಟ್‌ಹಬ್ ರೆಪೊಸಿಟರಿಯಾಗಿರುವ ಡೇಟಾಹಬ್‌ನ ಓಪನ್ ಸೋರ್ಸ್ ಆವೃತ್ತಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಡೇಟಾಹಬ್‌ನ ಲಿಂಕ್ಡ್‌ಇನ್ ಆವೃತ್ತಿಯು ಬಹು ರೆಪೊಸಿಟರಿಗಳ ಸಂಯೋಜನೆಯಾಗಿದೆ (ಆಂತರಿಕವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಬಹುಉತ್ಪನ್ನಗಳು) ಡೇಟಾಹಬ್ ಇಂಟರ್ಫೇಸ್, ಮೆಟಾಡೇಟಾ ಮಾಡೆಲ್ ಲೈಬ್ರರಿ, ಮೆಟಾಡೇಟಾ ವೇರ್‌ಹೌಸ್ ಬ್ಯಾಕೆಂಡ್ ಸೇವೆ ಮತ್ತು ಸ್ಟ್ರೀಮಿಂಗ್ ಉದ್ಯೋಗಗಳು ಲಿಂಕ್ಡ್‌ಇನ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಓಪನ್ ಸೋರ್ಸ್ ಬಳಕೆದಾರರಿಗೆ ಸುಲಭವಾಗಿಸಲು, DataHub ನ ಓಪನ್ ಸೋರ್ಸ್ ಆವೃತ್ತಿಗಾಗಿ ನಾವು ಒಂದೇ ರೆಪೊಸಿಟರಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಚಿತ್ರ 1: ರೆಪೊಸಿಟರಿಗಳ ನಡುವೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಂದೇಶ ಡೇಟಾಹಬ್ ಮತ್ತು ಒಂದೇ ಭಂಡಾರ ಡೇಟಾಹಬ್ ಮುಕ್ತ ಸಂಪನ್ಮೂಲ

ಸ್ವಯಂಚಾಲಿತ ಬಿಲ್ಡ್, ಪುಶ್ ಮತ್ತು ಪುಲ್ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಬೆಂಬಲಿಸಲು, ನಮ್ಮ ಹೊಸ ಉಪಕರಣವು ಪ್ರತಿ ಮೂಲ ಫೈಲ್‌ಗೆ ಅನುಗುಣವಾದ ಫೈಲ್-ಮಟ್ಟದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಟೂಲ್‌ಕಿಟ್‌ಗೆ ಆರಂಭಿಕ ಕಾನ್ಫಿಗರೇಶನ್ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಕೆಳಗೆ ತೋರಿಸಿರುವಂತೆ ಉನ್ನತ ಮಟ್ಟದ ಮಾಡ್ಯೂಲ್ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಒದಗಿಸಬೇಕು.

{
  "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 ಆಗಿದ್ದು, ಅದರ ಕೀಗಳು ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಗುರಿ ಮಾಡ್ಯೂಲ್‌ಗಳಾಗಿವೆ ಮತ್ತು ಮೌಲ್ಯಗಳು ಲಿಂಕ್ಡ್‌ಇನ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿನ ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳ ಪಟ್ಟಿಯಾಗಿದೆ. ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿನ ಯಾವುದೇ ಗುರಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳಿಂದ ನೀಡಬಹುದು. ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ರೆಪೊಸಿಟರಿಗಳ ಆಂತರಿಕ ಹೆಸರುಗಳನ್ನು ಸೂಚಿಸಲು, ಬಳಸಿ ಸ್ಟ್ರಿಂಗ್ ಇಂಟರ್ಪೋಲೇಷನ್ ಬ್ಯಾಷ್ ಶೈಲಿಯಲ್ಲಿ. ಮಾಡ್ಯೂಲ್-ಮಟ್ಟದ ಮ್ಯಾಪಿಂಗ್ ಫೈಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಪರಿಕರಗಳು ಸಂಬಂಧಿತ ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮೂಲಕ ಫೈಲ್-ಮಟ್ಟದ ಮ್ಯಾಪಿಂಗ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತವೆ.

{
  "${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,
}

ಫೈಲ್ ಮಟ್ಟದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಉಪಕರಣಗಳಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗಿದೆ; ಆದಾಗ್ಯೂ, ಇದನ್ನು ಬಳಕೆದಾರರಿಂದ ಹಸ್ತಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಬಹುದು. ಇದು ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಫೈಲ್‌ಗೆ ಲಿಂಕ್ಡ್‌ಇನ್ ಮೂಲ ಫೈಲ್‌ನ 1:1 ಮ್ಯಾಪಿಂಗ್ ಆಗಿದೆ. ಫೈಲ್ ಅಸೋಸಿಯೇಷನ್‌ಗಳ ಈ ಸ್ವಯಂಚಾಲಿತ ರಚನೆಗೆ ಸಂಬಂಧಿಸಿದ ಹಲವಾರು ನಿಯಮಗಳಿವೆ:

• ಓಪನ್ ಸೋರ್ಸ್‌ನಲ್ಲಿ ಟಾರ್ಗೆಟ್ ಮಾಡ್ಯೂಲ್‌ಗಾಗಿ ಬಹು ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಘರ್ಷಗಳು ಉಂಟಾಗಬಹುದು, ಉದಾ. FQCN, ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಸಂಘರ್ಷ ಪರಿಹಾರ ತಂತ್ರವಾಗಿ, ನಮ್ಮ ಪರಿಕರಗಳು "ಕೊನೆಯದು ಗೆಲ್ಲುತ್ತದೆ" ಆಯ್ಕೆಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿರುತ್ತದೆ.
• "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

ಅವಲಂಬನೆ ಪರೀಕ್ಷೆ

ಲಿಂಕ್ಡ್‌ಇನ್ ಹೊಂದಿದೆ ಅವಲಂಬನೆ ಪರೀಕ್ಷೆ ಮೂಲಸೌಕರ್ಯ, ಆಂತರಿಕ ಬಹುಉತ್ಪನ್ನಕ್ಕೆ ಬದಲಾವಣೆಗಳು ಅವಲಂಬಿತ ಬಹುಉತ್ಪನ್ನಗಳ ಜೋಡಣೆಯನ್ನು ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಓಪನ್ ಸೋರ್ಸ್ DataHub ರೆಪೊಸಿಟರಿಯು ಬಹು-ಉತ್ಪನ್ನವಲ್ಲ, ಮತ್ತು ಇದು ಯಾವುದೇ ಬಹು-ಉತ್ಪನ್ನದ ನೇರ ಅವಲಂಬನೆಯಾಗಿರಬಾರದು, ಆದರೆ ಮುಕ್ತ ಮೂಲ DataHub ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪಡೆಯುವ ಬಹು-ಉತ್ಪನ್ನ ಹೊದಿಕೆಯ ಸಹಾಯದಿಂದ, ನಾವು ಇನ್ನೂ ಈ ಅವಲಂಬನೆ ಪರೀಕ್ಷೆಯನ್ನು ಬಳಸಬಹುದು ವ್ಯವಸ್ಥೆ ಹೀಗೆ, ಓಪನ್ ಸೋರ್ಸ್ DataHub ರೆಪೊಸಿಟರಿಯನ್ನು ಪೋಷಿಸುವ ಯಾವುದೇ ಬಹುಉತ್ಪನ್ನಗಳಿಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಯು (ನಂತರ ಬಹಿರಂಗಗೊಳ್ಳಬಹುದು) ಶೆಲ್ ಮಲ್ಟಿಪ್ರೊಡಕ್ಟ್‌ನಲ್ಲಿ ಬಿಲ್ಡ್ ಈವೆಂಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಹೊದಿಕೆಯ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ಮಿಸಲು ವಿಫಲವಾದ ಯಾವುದೇ ಬದಲಾವಣೆಯು ಮೂಲ ಉತ್ಪನ್ನವನ್ನು ಒಪ್ಪಿಸುವ ಮೊದಲು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.

ಇದು ಮುಕ್ತ ಮೂಲ ನಿರ್ಮಾಣವನ್ನು ಮುರಿಯುವ ಮತ್ತು ಬದ್ಧತೆಯ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಯಾವುದೇ ಆಂತರಿಕ ಬದ್ಧತೆಯನ್ನು ತಡೆಯಲು ಸಹಾಯ ಮಾಡುವ ಉಪಯುಕ್ತ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಇದು ಇಲ್ಲದೆ, ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿ ಬಿಲ್ಡ್ ವಿಫಲಗೊಳ್ಳಲು ಯಾವ ಆಂತರಿಕ ಬದ್ಧತೆ ಕಾರಣವಾಯಿತು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಡೇಟಾಹಬ್ ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಆಂತರಿಕ ಬದಲಾವಣೆಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡುತ್ತೇವೆ.

ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್ ಮತ್ತು ನಮ್ಮ ಉತ್ಪಾದನಾ ಆವೃತ್ತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು

ಈ ಹಂತದವರೆಗೆ, DataHub ರೆಪೊಸಿಟರಿಗಳ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ನಮ್ಮ ಪರಿಹಾರವನ್ನು ನಾವು ಚರ್ಚಿಸಿದ್ದೇವೆ, ಆದರೆ ನಮಗೆ ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಎರಡು ವಿಭಿನ್ನ ಅಭಿವೃದ್ಧಿ ಸ್ಟ್ರೀಮ್‌ಗಳು ಏಕೆ ಬೇಕು ಎಂಬ ಕಾರಣಗಳನ್ನು ನಾವು ಇನ್ನೂ ವಿವರಿಸಿಲ್ಲ. ಈ ವಿಭಾಗದಲ್ಲಿ, ನಾವು ಡೇಟಾಹಬ್‌ನ ಸಾರ್ವಜನಿಕ ಆವೃತ್ತಿ ಮತ್ತು ಲಿಂಕ್ಡ್‌ಇನ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಉತ್ಪಾದನಾ ಆವೃತ್ತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಕಾರಣಗಳನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

ನಮ್ಮ ಉತ್ಪಾದನಾ ಆವೃತ್ತಿಯು ಲಿಂಕ್ಡ್‌ಇನ್ನ ಆಫ್‌ಸ್ಪ್ರಿಂಗ್ (ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಆಂತರಿಕ ಅವಲಂಬನೆ ಇಂಜೆಕ್ಷನ್ ಫ್ರೇಮ್‌ವರ್ಕ್) ನಂತಹ ಇನ್ನೂ ತೆರೆದ ಮೂಲವಲ್ಲದ ಕೋಡ್‌ನಲ್ಲಿ ಅವಲಂಬನೆಯನ್ನು ಹೊಂದಿದೆ ಎಂಬ ಅಂಶದಿಂದ ವ್ಯತ್ಯಾಸದ ಒಂದು ಮೂಲವಾಗಿದೆ. ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ಆದ್ಯತೆಯ ವಿಧಾನವಾಗಿದೆ ಏಕೆಂದರೆ ಸಂತತಿಯನ್ನು ಆಂತರಿಕ ಕೋಡ್‌ಬೇಸ್‌ಗಳಲ್ಲಿ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಆದರೆ ಇದು ತೆರೆದ ಮೂಲವಲ್ಲ; ಆದ್ದರಿಂದ ನಾವು ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್‌ಗೆ ಮುಕ್ತ ಮೂಲ ಪರ್ಯಾಯಗಳನ್ನು ಹುಡುಕಬೇಕಾಗಿದೆ.

ಇತರ ಕಾರಣಗಳೂ ಇವೆ. ನಾವು ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಅಗತ್ಯಗಳಿಗಾಗಿ ಮೆಟಾಡೇಟಾ ಮಾದರಿಗೆ ವಿಸ್ತರಣೆಗಳನ್ನು ರಚಿಸುವುದರಿಂದ, ಈ ವಿಸ್ತರಣೆಗಳು ವಿಶಿಷ್ಟವಾಗಿ ಲಿಂಕ್ಡ್‌ಇನ್‌ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿರುತ್ತವೆ ಮತ್ತು ಇತರ ಪರಿಸರಗಳಿಗೆ ನೇರವಾಗಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಭಾಗವಹಿಸುವವರ ಐಡಿಗಳು ಮತ್ತು ಇತರ ರೀತಿಯ ಹೊಂದಾಣಿಕೆಯ ಮೆಟಾಡೇಟಾಕ್ಕಾಗಿ ನಾವು ನಿರ್ದಿಷ್ಟ ಲೇಬಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಈಗ ಈ ವಿಸ್ತರಣೆಗಳನ್ನು DataHub ನ ಓಪನ್ ಸೋರ್ಸ್ ಮೆಟಾಡೇಟಾ ಮಾದರಿಯಿಂದ ಹೊರಗಿಟ್ಟಿದ್ದೇವೆ. ನಾವು ಸಮುದಾಯದೊಂದಿಗೆ ತೊಡಗಿಸಿಕೊಂಡಾಗ ಮತ್ತು ಅವರ ಅಗತ್ಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಾಗ, ಅಗತ್ಯವಿರುವಲ್ಲಿ ಈ ವಿಸ್ತರಣೆಗಳ ಸಾಮಾನ್ಯ ಮುಕ್ತ ಮೂಲ ಆವೃತ್ತಿಗಳಲ್ಲಿ ನಾವು ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.

ಬಳಕೆಯ ಸುಲಭತೆ ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಸಮುದಾಯಕ್ಕೆ ಸುಲಭವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವುದು DataHub ನ ಎರಡು ಆವೃತ್ತಿಗಳ ನಡುವಿನ ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪ್ರೇರೇಪಿಸಿತು. ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ವ್ಯತ್ಯಾಸಗಳು ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ. ನಮ್ಮ ಆಂತರಿಕ ಆವೃತ್ತಿಯು ನಿರ್ವಹಿಸಲಾದ ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣಾ ಚೌಕಟ್ಟನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ, ನಾವು ತೆರೆದ ಮೂಲ ಆವೃತ್ತಿಗಾಗಿ ಅಂತರ್ನಿರ್ಮಿತ (ಸ್ವತಂತ್ರ) ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆಯನ್ನು ಬಳಸಲು ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ಅದು ಮತ್ತೊಂದು ಮೂಲಸೌಕರ್ಯ ಅವಲಂಬನೆಯನ್ನು ರಚಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ವ್ಯತ್ಯಾಸದ ಇನ್ನೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಬಹು GMS ಗಳ ಬದಲಿಗೆ ಒಂದೇ GMS (ಜನರಲೈಸ್ಡ್ ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್) ಅನ್ನು ತೆರೆದ ಮೂಲ ಅನುಷ್ಠಾನದಲ್ಲಿ ಹೊಂದಿದೆ. GMA (ಜನರಲೈಸ್ಡ್ ಮೆಟಾಡೇಟಾ ಆರ್ಕಿಟೆಕ್ಚರ್) ಎಂಬುದು ಡೇಟಾಹಬ್‌ಗಾಗಿ ಬ್ಯಾಕ್-ಎಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಹೆಸರು, ಮತ್ತು GMS ಎಂಬುದು GMA ಸಂದರ್ಭದಲ್ಲಿ ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್ ಆಗಿದೆ. GMA ತುಂಬಾ ಹೊಂದಿಕೊಳ್ಳುವ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಗಿದ್ದು, ಪ್ರತಿಯೊಂದು ಡೇಟಾ ರಚನೆಯನ್ನು (ಉದಾ. ಡೇಟಾಸೆಟ್‌ಗಳು, ಬಳಕೆದಾರರು, ಇತ್ಯಾದಿ) ತನ್ನದೇ ಆದ ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್‌ಗೆ ವಿತರಿಸಲು ಅಥವಾ ಡೇಟಾ ರಚನೆಯ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಹೊಂದಿರುವ ನೋಂದಾವಣೆ ಇರುವವರೆಗೆ ಒಂದೇ ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಬಹು ಡೇಟಾ ರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. GMS ಅನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ. ಬಳಕೆಯ ಸುಲಭತೆಗಾಗಿ, ಓಪನ್ ಸೋರ್ಸ್ DataHub ನಲ್ಲಿ ಎಲ್ಲಾ ವಿಭಿನ್ನ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಒಂದೇ GMS ನಿದರ್ಶನವನ್ನು ನಾವು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ.

ಎರಡು ಅನುಷ್ಠಾನಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ಕೆಳಗಿನ ಕೋಷ್ಟಕದಲ್ಲಿ ನೀಡಲಾಗಿದೆ.

ಉತ್ಪನ್ನ ಲಕ್ಷಣಗಳು
ಲಿಂಕ್ಡ್‌ಇನ್ ಡೇಟಾಹಬ್
ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್

ಬೆಂಬಲಿತ ಡೇಟಾ ರಚನೆಗಳು
1) ಡೇಟಾಸೆಟ್‌ಗಳು 2) ಬಳಕೆದಾರರು 3) ಮೆಟ್ರಿಕ್‌ಗಳು 4) ML ವೈಶಿಷ್ಟ್ಯಗಳು 5) ಚಾರ್ಟ್‌ಗಳು 6) ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು
1) ಡೇಟಾಸೆಟ್‌ಗಳು 2) ಬಳಕೆದಾರರು

ಡೇಟಾಸೆಟ್‌ಗಳಿಗಾಗಿ ಬೆಂಬಲಿತ ಮೆಟಾಡೇಟಾ ಮೂಲಗಳು
1) ಅಂಬ್ರಿ 2) ಕೌಚ್‌ಬೇಸ್ 3) ದಾಲಿಡ್ಸ್ 4) ಎಸ್ಪ್ರೆಸೊ 5) HDFS 6) ಹೈವ್ 7) ಕಾಫ್ಕಾ 8) ಮೊಂಗೋಡಿಬಿ 9) MySQL 10) ಒರಾಕಲ್ 11) ಪಿನೋಟ್ 12) ಪ್ರೆಸ್ಟೊ 12) ಬಿ 13) ಟೆರಾಡಾಟಾ 13) ವೆಕ್ಟರ್ 14) ವೆನಿಸ್
ಹೈವ್ ಕಾಫ್ಕಾ RDBMS

ಪಬ್-ಉಪ
ಲಿಂಕ್ಡ್‌ಇನ್ ಕಾಫ್ಕಾ
ಸಂಗಮ ಕಾಫ್ಕಾ

ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆ
ಮ್ಯಾನೇಜ್ಡ್
ಎಂಬೆಡೆಡ್ (ಸ್ವತಂತ್ರ)

ಅವಲಂಬನೆ ಇಂಜೆಕ್ಷನ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್
ಲಿಂಕ್ಡ್‌ಇನ್ ಸಂತತಿ
ವಸಂತ

ಟೂಲಿಂಗ್ ಅನ್ನು ನಿರ್ಮಿಸಿ
ಲಿಗ್ರಾಡ್ಲ್ (ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ಆಂತರಿಕ ಗ್ರ್ಯಾಡಲ್ ಹೊದಿಕೆ)
ಗ್ರ್ಯಾಡ್ಲೆವ್

ಸಿಐ / ಸಿಡಿ
CRT (ಲಿಂಕ್ಡ್‌ಇನ್ನ ಆಂತರಿಕ CI/CD)
ಟ್ರಾವಿಸ್ಸಿಐ ಮತ್ತು ಡಾಕರ್ ಹಬ್

ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್ಸ್
ಬಹು GMS ವಿತರಿಸಲಾಗಿದೆ: 1) ಡೇಟಾಸೆಟ್ GMS 2) ಬಳಕೆದಾರ GMS 3) ಮೆಟ್ರಿಕ್ GMS 4) ವೈಶಿಷ್ಟ್ಯ GMS 5) ಚಾರ್ಟ್/ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ GMS
ಇದಕ್ಕಾಗಿ ಏಕ GMS: 1) ಡೇಟಾಸೆಟ್‌ಗಳು 2) ಬಳಕೆದಾರರು

ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್

ಡಾಕರ್ ಇದರೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆ ಮತ್ತು ವಿತರಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಕಂಟೈನರೈಸೇಶನ್. DataHub ನಲ್ಲಿನ ಸೇವೆಯ ಪ್ರತಿಯೊಂದು ಭಾಗವು ಕಾಫ್ಕಾದಂತಹ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಮುಕ್ತ ಮೂಲವಾಗಿದೆ, Elasticsearch, ನಿಯೋ 4 ಜೆ и MySQL, ತನ್ನದೇ ಆದ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಹೊಂದಿದೆ. ನಾವು ಬಳಸಿದ ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ಡಾಕರ್ ಕಂಪೋಸ್.

ಚಿತ್ರ 2: ವಾಸ್ತುಶಿಲ್ಪ ಡೇಟಾಹಬ್ *ಮುಕ್ತ ಸಂಪನ್ಮೂಲ**

ಮೇಲಿನ ಚಿತ್ರದಲ್ಲಿ ನೀವು DataHub ನ ಉನ್ನತ ಮಟ್ಟದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನೋಡಬಹುದು. ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳ ಜೊತೆಗೆ, ಇದು ನಾಲ್ಕು ವಿಭಿನ್ನ ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ:

ಡೇಟಾಹಬ್-ಜಿಎಂಎಸ್: ಮೆಟಾಡೇಟಾ ಶೇಖರಣಾ ಸೇವೆ

ಡೇಟಾಹಬ್-ಫ್ರಂಟೆಂಡ್: ಅಪ್ಲಿಕೇಶನ್ ಆಡಲು, DataHub ಇಂಟರ್ಫೇಸ್ ಸೇವೆ.

datahub-mce-consumer: ಅಪ್ಲಿಕೇಶನ್ ಕಾಫ್ಕಾ ಸ್ಟ್ರೀಮ್ಸ್, ಇದು ಮೆಟಾಡೇಟಾ ಬದಲಾವಣೆ ಈವೆಂಟ್ (MCE) ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಮೆಟಾಡೇಟಾ ಸ್ಟೋರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.

datahub-mae-consumer: ಅಪ್ಲಿಕೇಶನ್ ಕಾಫ್ಕಾ ಸ್ಟ್ರೀಮ್ಸ್, ಇದು ಮೆಟಾಡೇಟಾ ಆಡಿಟ್ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್ (MAE) ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಹುಡುಕಾಟ ಸೂಚ್ಯಂಕ ಮತ್ತು ಗ್ರಾಫ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ.

ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿ ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಮೂಲ DataHub ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ವಿವಿಧ ಸೇವೆಗಳ ಕಾರ್ಯಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

DataHub ನಲ್ಲಿ CI/CD ಮುಕ್ತ ಮೂಲವಾಗಿದೆ

ಓಪನ್ ಸೋರ್ಸ್ DataHub ರೆಪೊಸಿಟರಿಯನ್ನು ಬಳಸುತ್ತದೆ ಟ್ರಾವಿಸ್ಸಿಐ ನಿರಂತರ ಏಕೀಕರಣಕ್ಕಾಗಿ ಮತ್ತು ಡಾಕರ್ ಹಬ್ ನಿರಂತರ ನಿಯೋಜನೆಗಾಗಿ. ಎರಡೂ ಉತ್ತಮ GitHub ಏಕೀಕರಣವನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಹೊಂದಿಸಲು ಸುಲಭವಾಗಿದೆ. ಸಮುದಾಯ ಅಥವಾ ಖಾಸಗಿ ಕಂಪನಿಗಳು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಹೆಚ್ಚಿನ ತೆರೆದ ಮೂಲ ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ (ಉದಾ. ಸಂಗಮ), ಸಮುದಾಯದ ಸುಲಭ ಬಳಕೆಗಾಗಿ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಡಾಕರ್ ಹಬ್‌ಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಡಾಕರ್ ಹಬ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ಯಾವುದೇ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಸರಳ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಬಳಸಬಹುದು ಡಾಕರ್ ಪುಲ್.

DataHub ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಗೆ ಪ್ರತಿ ಬದ್ಧತೆಯೊಂದಿಗೆ, ಎಲ್ಲಾ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ ಮತ್ತು "ಇತ್ತೀಚಿನ" ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಡಾಕರ್ ಹಬ್‌ಗೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ. ಡಾಕರ್ ಹಬ್ ಅನ್ನು ಕೆಲವರೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿ ಶಾಖೆಗಳನ್ನು ಹೆಸರಿಸುವುದು, ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಡಾಕರ್ ಹಬ್‌ನಲ್ಲಿ ಅನುಗುಣವಾದ ಟ್ಯಾಗ್ ಹೆಸರುಗಳೊಂದಿಗೆ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ.

ಡೇಟಾಹಬ್ ಅನ್ನು ಬಳಸುವುದು

DataHub ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಮೂರು ಸರಳ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

1. ಓಪನ್ ಸೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡಿ ಮತ್ತು ತ್ವರಿತ ಪ್ರಾರಂಭಕ್ಕಾಗಿ ಒದಗಿಸಿದ ಡಾಕರ್-ಕಂಪೋಸ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡಾಕರ್-ಕಂಪೋಸ್‌ನೊಂದಿಗೆ ಎಲ್ಲಾ ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿ.
2. ಒದಗಿಸಲಾದ ಕಮಾಂಡ್ ಲೈನ್ ಉಪಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಒದಗಿಸಲಾದ ಮಾದರಿ ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ.
3. ನಿಮ್ಮ ಬ್ರೌಸರ್‌ನಲ್ಲಿ DataHub ಅನ್ನು ಬ್ರೌಸ್ ಮಾಡಿ.

ಸಕ್ರಿಯವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಗಿಟ್ಟರ್ ಚಾಟ್ ತ್ವರಿತ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಬಳಕೆದಾರರು ನೇರವಾಗಿ GitHub ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸಬಹುದು. ಬಹು ಮುಖ್ಯವಾಗಿ, ನಾವು ಎಲ್ಲಾ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಸಲಹೆಗಳನ್ನು ಸ್ವಾಗತಿಸುತ್ತೇವೆ ಮತ್ತು ಪ್ರಶಂಸಿಸುತ್ತೇವೆ!

ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು

ಪ್ರಸ್ತುತ, ಓಪನ್ ಸೋರ್ಸ್ ಡೇಟಾಹಬ್‌ಗಾಗಿ ಪ್ರತಿಯೊಂದು ಮೂಲಸೌಕರ್ಯ ಅಥವಾ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಅನ್ನು ಡಾಕರ್ ಕಂಟೇನರ್‌ನಂತೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಯೋಜಿಸಲಾಗಿದೆ ಡಾಕರ್-ಸಂಯೋಜನೆ. ಜನಪ್ರಿಯತೆ ಮತ್ತು ವ್ಯಾಪಕತೆಯನ್ನು ನೀಡಲಾಗಿದೆ ಕುಬರ್ನೆಟ್ಸ್, ನಾವು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ ಆಧಾರಿತ ಪರಿಹಾರವನ್ನು ಒದಗಿಸಲು ಬಯಸುತ್ತೇವೆ.

ಸಾರ್ವಜನಿಕ ಕ್ಲೌಡ್ ಸೇವೆಯಲ್ಲಿ DataHub ಅನ್ನು ನಿಯೋಜಿಸಲು ಟರ್ನ್‌ಕೀ ಪರಿಹಾರವನ್ನು ಒದಗಿಸಲು ನಾವು ಯೋಜಿಸಿದ್ದೇವೆ ಆಕಾಶ ನೀಲಿ, AWS ಅಥವಾ Google ಮೇಘ. ಅಜೂರ್‌ಗೆ ಲಿಂಕ್ಡ್‌ಇನ್‌ನ ವಲಸೆಯ ಇತ್ತೀಚಿನ ಪ್ರಕಟಣೆಯನ್ನು ನೀಡಲಾಗಿದೆ, ಇದು ಮೆಟಾಡೇಟಾ ತಂಡದ ಆಂತರಿಕ ಆದ್ಯತೆಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ ಆದರೆ ಕನಿಷ್ಠವಲ್ಲ, DataHub ಆಲ್ಫಾಗಳನ್ನು ರೇಟ್ ಮಾಡಿದ ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಸುಧಾರಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದ ಮುಕ್ತ ಮೂಲ ಸಮುದಾಯದಲ್ಲಿ DataHub ನ ಎಲ್ಲಾ ಆರಂಭಿಕ ಅಳವಡಿಕೆದಾರರಿಗೆ ಧನ್ಯವಾದಗಳು.

ಮೂಲ: www.habr.com