DataHub nguồn mở: Nền tảng khám phá và tìm kiếm siêu dữ liệu của LinkedIn
Việc tìm kiếm dữ liệu bạn cần một cách nhanh chóng là điều cần thiết đối với bất kỳ công ty nào dựa vào lượng lớn dữ liệu để đưa ra quyết định dựa trên dữ liệu. Điều này không chỉ ảnh hưởng đến năng suất của người dùng dữ liệu (bao gồm các nhà phân tích, nhà phát triển máy học, nhà khoa học dữ liệu và kỹ sư dữ liệu) mà còn có tác động trực tiếp đến các sản phẩm cuối cùng phụ thuộc vào quy trình máy học (ML) chất lượng. Ngoài ra, xu hướng triển khai hoặc xây dựng nền tảng máy học đương nhiên đặt ra câu hỏi: phương pháp khám phá nội bộ các tính năng, mô hình, số liệu, bộ dữ liệu, v.v. là gì?
Trong bài viết này, chúng tôi sẽ nói về cách chúng tôi xuất bản nguồn dữ liệu theo giấy phép mở trong nền tảng tìm kiếm và khám phá siêu dữ liệu của chúng tôi, bắt đầu từ những ngày đầu của dự án . LinkedIn duy trì phiên bản DataHub của riêng mình tách biệt với phiên bản nguồn mở. Chúng tôi sẽ bắt đầu bằng cách giải thích lý do tại sao chúng tôi cần hai môi trường phát triển riêng biệt, sau đó thảo luận về các phương pháp tiếp cận ban đầu để sử dụng WhereHows nguồn mở và so sánh phiên bản DataHub (sản xuất) nội bộ của chúng tôi với phiên bản trên . Chúng tôi cũng sẽ chia sẻ thông tin chi tiết về giải pháp tự động mới của chúng tôi để đẩy và nhận các bản cập nhật nguồn mở nhằm giữ cho cả hai kho lưu trữ được đồng bộ hóa. Cuối cùng, chúng tôi sẽ cung cấp hướng dẫn về cách bắt đầu sử dụng DataHub nguồn mở và thảo luận ngắn gọn về kiến trúc của nó.
WhereHows hiện là DataHub!
Nhóm siêu dữ liệu của LinkedIn đã trình bày trước đây (kế thừa của WhereHows), nền tảng khám phá siêu dữ liệu và tìm kiếm của LinkedIn cũng như các kế hoạch chung để mở nó. Ngay sau thông báo này, chúng tôi đã phát hành phiên bản alpha của DataHub và chia sẻ nó với cộng đồng. Kể từ đó, chúng tôi đã liên tục đóng góp vào kho lưu trữ và làm việc với những người dùng quan tâm để bổ sung các tính năng được yêu cầu nhiều nhất và giải quyết các vấn đề. Bây giờ chúng tôi vui mừng thông báo bản phát hành chính thức .
Các phương pháp tiếp cận nguồn mở
WhereHows, cổng thông tin ban đầu của LinkedIn để tìm kiếm dữ liệu và nguồn gốc của dữ liệu, bắt đầu như một dự án nội bộ; nhóm siêu dữ liệu đã mở nó . Kể từ đó, nhóm luôn duy trì hai cơ sở mã khác nhau—một dành cho nguồn mở và một dành cho sử dụng nội bộ của LinkedIn—vì không phải tất cả các tính năng sản phẩm được phát triển cho các trường hợp sử dụng LinkedIn thường có thể áp dụng cho đối tượng rộng hơn. Ngoài ra, WhereHows có một số phần phụ thuộc nội bộ (cơ sở hạ tầng, thư viện, v.v.) không phải là nguồn mở. Trong những năm sau đó, WhereHows đã trải qua nhiều lần lặp lại và chu kỳ phát triển, khiến việc giữ cho hai cơ sở mã được đồng bộ hóa là một thách thức lớn. Nhóm siêu dữ liệu đã thử các cách tiếp cận khác nhau trong nhiều năm để cố gắng giữ cho sự phát triển nội bộ và nguồn mở được đồng bộ.
Lần thử đầu tiên: "Nguồn mở trước"
Ban đầu, chúng tôi tuân theo mô hình phát triển "nguồn mở đầu tiên", trong đó hầu hết quá trình phát triển diễn ra trong kho lưu trữ nguồn mở và các thay đổi được thực hiện để triển khai nội bộ. Vấn đề với cách tiếp cận này là mã luôn được đẩy lên GitHub trước khi được xem xét nội bộ đầy đủ. Cho đến khi các thay đổi được thực hiện từ kho lưu trữ nguồn mở và triển khai nội bộ mới được thực hiện, chúng tôi sẽ không tìm thấy bất kỳ vấn đề sản xuất nào. Trong trường hợp triển khai kém, việc xác định thủ phạm cũng rất khó khăn vì các thay đổi được thực hiện theo đợt.
Ngoài ra, mô hình này làm giảm năng suất của nhóm khi phát triển các tính năng mới yêu cầu lặp lại nhanh chóng, vì nó buộc tất cả các thay đổi trước tiên phải được đẩy vào kho lưu trữ nguồn mở và sau đó được đẩy sang kho lưu trữ nội bộ. Để giảm thời gian xử lý, việc sửa chữa hoặc thay đổi bắt buộc có thể được thực hiện trong kho lưu trữ nội bộ trước tiên, nhưng điều này đã trở thành một vấn đề lớn khi hợp nhất những thay đổi đó trở lại kho lưu trữ nguồn mở vì hai kho lưu trữ không đồng bộ.
Mô hình này dễ triển khai hơn nhiều đối với các nền tảng, thư viện hoặc dự án cơ sở hạ tầng dùng chung so với các ứng dụng web tùy chỉnh đầy đủ tính năng. Ngoài ra, mô hình này lý tưởng cho các dự án bắt đầu nguồn mở ngay từ ngày đầu, nhưng WhereHows được xây dựng như một ứng dụng web hoàn toàn nội bộ. Thực sự rất khó để loại bỏ hoàn toàn tất cả các phụ thuộc nội bộ, vì vậy chúng tôi cần giữ lại phân nhánh nội bộ, nhưng việc giữ phân nhánh nội bộ và phát triển phần lớn nguồn mở không hiệu quả lắm.
Nỗ lực thứ hai: “Nội tâm đầu tiên”
**Trong nỗ lực thứ hai, chúng tôi đã chuyển sang mô hình phát triển "nội bộ đầu tiên", trong đó hầu hết quá trình phát triển diễn ra nội bộ và các thay đổi được thực hiện đối với mã nguồn mở một cách thường xuyên. Mặc dù mô hình này phù hợp nhất với trường hợp sử dụng của chúng tôi nhưng nó có những vấn đề cố hữu. Trực tiếp đẩy tất cả các khác biệt vào kho lưu trữ nguồn mở và sau đó cố gắng giải quyết xung đột hợp nhất sau này là một tùy chọn, nhưng việc này tốn thời gian. Trong hầu hết các trường hợp, các nhà phát triển cố gắng không làm điều này mỗi khi họ xem lại mã của mình. Kết quả là, việc này sẽ được thực hiện ít thường xuyên hơn, theo đợt và do đó khiến việc giải quyết xung đột hợp nhất sau này trở nên khó khăn hơn.
Lần thứ ba nó hoạt động!
Hai lần thử không thành công được đề cập ở trên đã dẫn đến kho lưu trữ WhereHows GitHub bị lỗi thời trong một thời gian dài. Nhóm tiếp tục cải thiện các tính năng và kiến trúc của sản phẩm để phiên bản nội bộ của WhereHows dành cho LinkedIn trở nên tiên tiến hơn phiên bản nguồn mở. Nó thậm chí còn có một tên mới - DataHub. Dựa trên những nỗ lực thất bại trước đó, nhóm đã quyết định phát triển một giải pháp lâu dài và có thể mở rộng.
Đối với bất kỳ dự án nguồn mở mới nào, nhóm nguồn mở của LinkedIn tư vấn và hỗ trợ mô hình phát triển trong đó các mô-đun của dự án được phát triển hoàn toàn bằng nguồn mở. Các tạo phẩm đã được phiên bản được triển khai vào một kho lưu trữ công cộng và sau đó được kiểm tra lại vào một tạo phẩm LinkedIn nội bộ bằng cách sử dụng . Việc đi theo mô hình phát triển này không chỉ tốt cho những người sử dụng nguồn mở mà còn mang lại kết quả là một kiến trúc mô-đun hơn, có khả năng mở rộng và có thể cắm được hơn.
Tuy nhiên, một ứng dụng back-end hoàn thiện như DataHub sẽ cần một lượng thời gian đáng kể để đạt được trạng thái này. Điều này cũng ngăn cản khả năng tìm nguồn mở để triển khai hoạt động đầy đủ trước khi tất cả các phụ thuộc nội bộ được trừu tượng hóa hoàn toàn. Đó là lý do tại sao chúng tôi đã phát triển các công cụ giúp chúng tôi đóng góp nguồn mở nhanh hơn và ít vất vả hơn. Giải pháp này mang lại lợi ích cho cả nhóm siêu dữ liệu (nhà phát triển DataHub) và cộng đồng nguồn mở. Các phần sau đây sẽ thảo luận về cách tiếp cận mới này.
Tự động hóa xuất bản mã nguồn mở
Cách tiếp cận mới nhất của nhóm Siêu dữ liệu đối với DataHub nguồn mở là phát triển một công cụ tự động đồng bộ hóa cơ sở mã nội bộ và kho lưu trữ nguồn mở. Các tính năng cấp cao của bộ công cụ này bao gồm:
- Đồng bộ hóa mã LinkedIn với/từ nguồn mở, tương tự .
- Tạo tiêu đề giấy phép, tương tự như .
- Tự động tạo nhật ký cam kết nguồn mở từ nhật ký cam kết nội bộ.
- Ngăn chặn các thay đổi nội bộ phá vỡ các bản dựng nguồn mở bằng cách .
Các phần phụ sau đây sẽ đi sâu vào các hàm nêu trên có những vấn đề thú vị.
Đồng bộ hóa mã nguồn
Không giống như phiên bản nguồn mở của DataHub, là một kho lưu trữ GitHub duy nhất, phiên bản LinkedIn của DataHub là sự kết hợp của nhiều kho lưu trữ (được gọi nội bộ ). Giao diện DataHub, thư viện mô hình siêu dữ liệu, dịch vụ phụ trợ kho siêu dữ liệu và các công việc phát trực tuyến nằm trong các kho lưu trữ riêng biệt trên LinkedIn. Tuy nhiên, để giúp người dùng nguồn mở dễ dàng hơn, chúng tôi có một kho lưu trữ duy nhất cho phiên bản nguồn mở của DataHub.
Hình 1: Đồng bộ hóa giữa các kho lưu trữ LinkedIn Trung tâm dữ liệu và một kho lưu trữ duy nhất Trung tâm dữ liệu mã nguồn mở
Để hỗ trợ các quy trình xây dựng, đẩy và kéo tự động, công cụ mới của chúng tôi sẽ tự động tạo ánh xạ cấp tệp tương ứng với từng tệp nguồn. Tuy nhiên, bộ công cụ yêu cầu cấu hình ban đầu và người dùng phải cung cấp ánh xạ mô-đun cấp cao như hiển thị bên dưới.
{
"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"
]
}Ánh xạ cấp mô-đun là một JSON đơn giản có khóa là các mô-đun đích trong kho lưu trữ nguồn mở và các giá trị là danh sách các mô-đun nguồn trong kho LinkedIn. Bất kỳ mô-đun đích nào trong kho lưu trữ nguồn mở đều có thể được cung cấp bởi bất kỳ số lượng mô-đun nguồn nào. Để chỉ ra tên nội bộ của kho lưu trữ trong mô-đun nguồn, hãy sử dụng theo phong cách Bash. Bằng cách sử dụng tệp ánh xạ cấp mô-đun, các công cụ này sẽ tạo tệp ánh xạ cấp độ tệp bằng cách quét tất cả các tệp trong các thư mục được liên kết.
{
"${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,
}Ánh xạ cấp độ tệp được các công cụ tự động tạo ra; tuy nhiên, người dùng cũng có thể cập nhật nó theo cách thủ công. Đây là ánh xạ 1:1 của tệp nguồn LinkedIn tới tệp trong kho lưu trữ nguồn mở. Có một số quy tắc liên quan đến việc tự động tạo liên kết tệp này:
- Trong trường hợp có nhiều mô-đun nguồn cho một mô-đun đích trong nguồn mở, xung đột có thể phát sinh, ví dụ: giống nhau , tồn tại trong nhiều mô-đun nguồn. Là một chiến lược giải quyết xung đột, các công cụ của chúng tôi mặc định sử dụng tùy chọn “người cuối cùng thắng”.
- "null" có nghĩa là tệp nguồn không phải là một phần của kho lưu trữ nguồn mở.
- Sau mỗi lần gửi hoặc trích xuất nguồn mở, ánh xạ này sẽ tự động được cập nhật và ảnh chụp nhanh được tạo. Điều này là cần thiết để xác định các bổ sung và xóa khỏi mã nguồn kể từ hành động cuối cùng.
Tạo nhật ký cam kết
Nhật ký cam kết cho các cam kết nguồn mở cũng được tạo tự động bằng cách hợp nhất nhật ký cam kết của các kho lưu trữ nội bộ. Dưới đây là nhật ký cam kết mẫu để hiển thị cấu trúc của nhật ký cam kết do công cụ của chúng tôi tạo ra. Một cam kết chỉ rõ phiên bản nào của kho nguồn được đóng gói trong cam kết đó và cung cấp bản tóm tắt về nhật ký cam kết. Kiểm tra cái này sử dụng ví dụ thực tế về nhật ký cam kết do bộ công cụ của chúng tôi tạo ra.
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.0Kiểm tra phụ thuộc
LinkedIn có , điều này giúp đảm bảo rằng những thay đổi đối với nhiều sản phẩm nội bộ không phá vỡ việc lắp ráp nhiều sản phẩm phụ thuộc. Kho lưu trữ DataHub nguồn mở không phải là nhiều sản phẩm và nó không thể là phần phụ thuộc trực tiếp của bất kỳ nhiều sản phẩm nào, nhưng với sự trợ giúp của trình bao bọc nhiều sản phẩm tìm nạp mã nguồn DataHub nguồn mở, chúng ta vẫn có thể sử dụng thử nghiệm phụ thuộc này Do đó, bất kỳ thay đổi nào (mà sau này có thể bị lộ) đối với bất kỳ sản phẩm đa sản phẩm nào cung cấp kho lưu trữ DataHub nguồn mở sẽ kích hoạt sự kiện xây dựng trong đa sản phẩm shell. Do đó, bất kỳ thay đổi nào không tạo được sản phẩm bao bọc đều không đạt các thử nghiệm trước khi đưa vào sản phẩm gốc và bị hoàn nguyên.
Đây là một cơ chế hữu ích giúp ngăn chặn bất kỳ cam kết nội bộ nào phá vỡ bản dựng nguồn mở và phát hiện nó tại thời điểm cam kết. Nếu không có điều này, sẽ rất khó để xác định cam kết nội bộ nào đã khiến quá trình xây dựng kho lưu trữ nguồn mở không thành công, vì chúng tôi thực hiện hàng loạt các thay đổi nội bộ đối với kho lưu trữ nguồn mở DataHub.
Sự khác biệt giữa DataHub nguồn mở và phiên bản sản xuất của chúng tôi
Cho đến thời điểm này, chúng tôi đã thảo luận về giải pháp đồng bộ hóa hai phiên bản kho DataHub, nhưng chúng tôi vẫn chưa nêu ra lý do tại sao ngay từ đầu chúng tôi cần hai luồng phát triển khác nhau. Trong phần này, chúng tôi sẽ liệt kê những khác biệt giữa phiên bản công khai của DataHub và phiên bản sản xuất trên máy chủ LinkedIn, đồng thời giải thích lý do cho những khác biệt này.
Một nguồn gốc của sự khác biệt bắt nguồn từ thực tế là phiên bản sản xuất của chúng tôi có các phần phụ thuộc vào mã chưa phải là nguồn mở, chẳng hạn như Offspring của LinkedIn (khung chèn phụ thuộc nội bộ của LinkedIn). Con cháu được sử dụng rộng rãi trong các cơ sở mã nội bộ vì đây là phương pháp được ưa thích để quản lý cấu hình động. Nhưng nó không phải là nguồn mở; vì vậy chúng tôi cần tìm các lựa chọn thay thế nguồn mở cho DataHub nguồn mở.
Ngoài ra còn có những lý do khác. Khi chúng tôi tạo các tiện ích mở rộng cho mô hình siêu dữ liệu cho nhu cầu của LinkedIn, các tiện ích mở rộng này thường rất cụ thể cho LinkedIn và có thể không áp dụng trực tiếp cho các môi trường khác. Ví dụ: chúng tôi có các nhãn rất cụ thể cho ID người tham gia và các loại siêu dữ liệu trùng khớp khác. Vì vậy, hiện tại chúng tôi đã loại trừ các tiện ích mở rộng này khỏi mô hình siêu dữ liệu nguồn mở của DataHub. Khi chúng tôi tương tác với cộng đồng và hiểu nhu cầu của họ, chúng tôi sẽ làm việc trên các phiên bản nguồn mở phổ biến của các tiện ích mở rộng này nếu cần.
Tính dễ sử dụng và khả năng thích ứng dễ dàng hơn đối với cộng đồng nguồn mở cũng tạo ra một số điểm khác biệt giữa hai phiên bản DataHub. Sự khác biệt trong cơ sở hạ tầng xử lý luồng là một ví dụ điển hình về điều này. Mặc dù phiên bản nội bộ của chúng tôi sử dụng khung xử lý luồng được quản lý nhưng chúng tôi đã chọn sử dụng xử lý luồng tích hợp (độc lập) cho phiên bản nguồn mở vì nó tránh tạo ra sự phụ thuộc cơ sở hạ tầng khác.
Một ví dụ khác về sự khác biệt là có một GMS (Cửa hàng siêu dữ liệu tổng quát) duy nhất trong triển khai nguồn mở thay vì nhiều GMS. GMA (Kiến trúc siêu dữ liệu tổng quát) là tên của kiến trúc back-end cho DataHub và GMS là kho lưu trữ siêu dữ liệu trong ngữ cảnh của GMA. GMA là kiến trúc rất linh hoạt cho phép bạn phân phối từng cấu trúc dữ liệu (ví dụ: tập dữ liệu, người dùng, v.v.) vào kho siêu dữ liệu của riêng nó hoặc lưu trữ nhiều cấu trúc dữ liệu trong một kho siêu dữ liệu duy nhất miễn là sổ đăng ký chứa ánh xạ cấu trúc dữ liệu trong GMS đang được cập nhật. Để dễ sử dụng, chúng tôi đã chọn một phiên bản GMS duy nhất lưu trữ tất cả các cấu trúc dữ liệu khác nhau trong DataHub nguồn mở.
Danh sách đầy đủ về sự khác biệt giữa hai cách triển khai được đưa ra trong bảng bên dưới.
Đặc tính sản phẩm
Trung tâm dữ liệu LinkedIn
Trung tâm dữ liệu nguồn mở
Cấu trúc dữ liệu được hỗ trợ
1) Bộ dữ liệu 2) Người dùng 3) Số liệu 4) Tính năng ML 5) Biểu đồ 6) Trang tổng quan
1) Bộ dữ liệu 2) Người dùng
Nguồn siêu dữ liệu được hỗ trợ cho tập dữ liệu
1) 2) Đế đi văng 3) 4) 5) HDFS 6) Tổ ong 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Nhanh chóng 12) 13) Siêu dữ liệu 13) Vectơ 14)
Hive Kafka RDBMS
Pub-sub
Kafka hợp lưu
Xử lý luồng
Quản lý
Nhúng (độc lập)
Cấu hình động và tiêm phụ thuộc
LinkedIn Con cháu
Xây dựng công cụ
Ligardle (Trình bao bọc Gradle nội bộ của LinkedIn)
CI / CD
CRT (CI/CD nội bộ của LinkedIn)
và
Cửa hàng siêu dữ liệu
Nhiều GMS phân tán: 1) GMS tập dữ liệu 2) GMS người dùng 3) GMS số liệu 4) GMS tính năng 5) GMS biểu đồ/trang tổng quan
GMS duy nhất cho: 1) Bộ dữ liệu 2) Người dùng
Vi dịch vụ trong vùng chứa Docker
đơn giản hóa việc triển khai và phân phối ứng dụng với . Mọi phần của dịch vụ trong DataHub đều là nguồn mở, bao gồm các thành phần cơ sở hạ tầng như Kafka, , и , có hình ảnh Docker riêng. Để sắp xếp các vùng chứa Docker, chúng tôi đã sử dụng .
Hình 2: Kiến trúc Trung tâm dữ liệu *mã nguồn mở**
Bạn có thể thấy kiến trúc cấp cao của DataHub trong hình trên. Bên cạnh các thành phần cơ sở hạ tầng, nó còn có bốn vùng chứa Docker khác nhau:
datahub-gms: dịch vụ lưu trữ siêu dữ liệu
datahub-frontend: ứng dụng , phục vụ giao diện DataHub.
datahub-mce-consumer: ứng dụng , sử dụng luồng sự kiện thay đổi siêu dữ liệu (MCE) và cập nhật kho siêu dữ liệu.
datahub-mae-người tiêu dùng: ứng dụng , sử dụng luồng sự kiện kiểm tra siêu dữ liệu (MAE) và tạo cơ sở dữ liệu đồ thị và chỉ mục tìm kiếm.
Tài liệu kho lưu trữ nguồn mở và chứa thông tin chi tiết hơn về chức năng của các dịch vụ khác nhau.
CI/CD trên DataHub là nguồn mở
Kho lưu trữ DataHub mã nguồn mở sử dụng để hội nhập liên tục và để triển khai liên tục. Cả hai đều có khả năng tích hợp GitHub tốt và dễ cài đặt. Đối với hầu hết cơ sở hạ tầng nguồn mở được phát triển bởi cộng đồng hoặc các công ty tư nhân (ví dụ: ), Docker image được tạo và triển khai lên Docker Hub để cộng đồng dễ sử dụng. Bất kỳ hình ảnh Docker nào được tìm thấy trong Docker Hub đều có thể dễ dàng sử dụng bằng một lệnh đơn giản .
Với mỗi cam kết đối với kho lưu trữ nguồn mở DataHub, tất cả hình ảnh Docker sẽ được tự động xây dựng và triển khai lên Docker Hub với thẻ "mới nhất". Nếu Docker Hub được cấu hình với một số , tất cả các thẻ trong kho mã nguồn mở cũng được phát hành với tên thẻ tương ứng trong Docker Hub.
Sử dụng DataHub
rất đơn giản và bao gồm ba bước đơn giản:
- Sao chép kho lưu trữ nguồn mở và chạy tất cả các vùng chứa Docker bằng docker-compose bằng cách sử dụng tập lệnh docker-compose được cung cấp để bắt đầu nhanh chóng.
- Tải xuống dữ liệu mẫu được cung cấp trong kho lưu trữ bằng công cụ dòng lệnh cũng được cung cấp.
- Duyệt DataHub trong trình duyệt của bạn.
Được theo dõi tích cực cũng được cấu hình cho các câu hỏi nhanh. Người dùng cũng có thể tạo sự cố trực tiếp trong kho GitHub. Quan trọng nhất, chúng tôi hoan nghênh và đánh giá cao mọi phản hồi và đề xuất!
Kế hoạch cho tương lai
Hiện tại, mọi cơ sở hạ tầng hoặc vi dịch vụ cho DataHub nguồn mở đều được xây dựng dưới dạng bộ chứa Docker và toàn bộ hệ thống được điều phối bằng cách sử dụng . Với sự phổ biến và rộng rãi , chúng tôi cũng muốn cung cấp giải pháp dựa trên Kubernetes trong tương lai gần.
Chúng tôi cũng có kế hoạch cung cấp giải pháp chìa khóa trao tay để triển khai DataHub trên dịch vụ đám mây công cộng như , hoặc . Với thông báo gần đây về việc LinkedIn chuyển sang Azure, điều này sẽ phù hợp với các ưu tiên nội bộ của nhóm siêu dữ liệu.
Cuối cùng nhưng không kém phần quan trọng, xin cảm ơn tất cả những người sử dụng DataHub đầu tiên trong cộng đồng nguồn mở, những người đã đánh giá bản alpha của DataHub và giúp chúng tôi xác định các vấn đề cũng như cải thiện tài liệu.
Nguồn: www.habr.com