Có ngôn ngữ / giao diện chuẩn cho ETL lập trình trong SQL Server không?

Tôi hiện đang trong quá trình tạo ETL cho kho dữ liệu của chúng tôi. Chúng tôi đang sử dụng SSIS 2008, nhưng chúng tôi đang gặp vấn đề, trong đó lớn nhất là khó sử dụng lại các thành phần. Chúng tôi có các gói riêng cho mỗi bảng và mỗi gói sẽ lấy đầu vào một số biến từ gói cha. Khi chúng tôi thay đổi các biến đầu vào này, chúng tôi bắt buộc phải đi vào từng gói (hiện tại chúng tôi có 15 hoặc hơn, nhưng con số này sẽ tăng lên đáng kể) và sửa đổi gói để xử lý các thay đổi đó. Ngoài ra còn có các vấn đề khác, bao gồm việc không thể chạy SQL tùy ý để trích xuất, khả năng ghi nhật ký kém, v.v.

Toàn bộ quá trình này sẽ mạnh mẽ hơn nhiều nếu có cách phát triển mã ETL của chúng tôi, cho phép tái sử dụng mã, thư viện chung, kiểm tra đơn vị tốt hơn, v.v. Có ngôn ngữ / API ETL tiêu chuẩn thực tế cho SQL Server không? Tôi đang tìm cách tránh các công cụ GUI càng nhiều càng tốt.

Chỉnh sửa: Tôi nên đề cập đến nền tảng của tôi. Tôi không phải là một DBA và không được đào tạo DBA chính thức (hoặc không chính thức), về cơ bản tôi đã tìm ra những thứ này khi tôi đi cùng, vì vậy có nhiều khả năng tôi đang cố gắng làm những điều không phù hợp với SSIS hoặc tiếp cận ETL này dự án từ góc độ sai. Ngoài ra, tôi hiện đang làm việc trong chính phủ tiểu bang, vì vậy mọi giải pháp yêu cầu mua gói phần mềm mới đều không nằm trong khả năng.

Đây là một trong những nhiệm vụ của chúng tôi. Chúng tôi đang sử dụng Gói SSIS duy nhất để tải từng bảng trong kho của mình. Mỗi gói Fact và gói Dimension thường giống nhau, chúng chỉ khác nhau ở

• Trích xuất từ ​​cơ sở dữ liệu nguồn
• Thao tác trong luồng dữ liệu
• Sáp nhập vào bảng đích

Những gì tôi muốn có thể làm (mà tôi thấy khó thực hiện trong SSIS)

• Tải truy vấn trích xuất từ ​​một tệp văn bản. Khi các nhà phát triển viết và kiểm tra các truy vấn trích xuất của họ, tôi không cần phải thao tác truy vấn của họ theo bất kỳ cách nào trước khi SSIS chạy nó và tôi không phải cắt và dán truy vấn vào đối tượng Nguồn DB.
• Kiểm tra từng thành phần riêng lẻ. Tôi có thể kiểm tra quy trình ETL hoàn chỉnh cho một bảng riêng lẻ, không phụ thuộc vào các bảng khác.
• Thực hiện sửa đổi logic được chia sẻ ở một nơi, không phải chỉnh sửa từng gói riêng lẻ. Mọi gói đều tải dữ liệu vào các bảng kiểm toán theo cùng một cách, nếu tôi muốn thay đổi dữ liệu được tải đã kiểm toán, tôi không muốn phải chỉnh sửa tất cả 15 gói (con số này sẽ lớn hơn nhiều theo thời gian).

Toàn bộ quá trình cảm thấy như nó sẽ dễ thực hiện hơn và mạnh mẽ hơn nếu được thực hiện theo chương trình với việc sử dụng mã chia sẻ đúng cách.

Có một công cụ cho phép điều này - http://www.varigence.com/products/biml.html

Có phiên bản thương mại, nhưng chúng tôi cũng bao gồm một số chức năng BIML trong BIDS Helper, một công cụ miễn phí. http://bidshelper.codeplex.com/

Tôi rất vui được trả lời bất kỳ câu hỏi nào mà bạn có thể có về nó.

Đây là một công cụ mà công ty tôi cung cấp.

Khi đọc nó, tôi nghĩ ngay đến việc giới thiệu các công cụ của Varigence. Tuy nhiên, tôi thấy rằng một trong những kiến ​​trúc sư trưởng tại Varigence, John Welch, đã đến đây trước tôi.

Các công cụ của Varigence là một lớp trừu tượng trên SSIS. Lợi thế cung cấp là khả năng xác định "công cụ" có thể tái sử dụng, do đó cung cấp tính nhất quán trên nhiều gói. Bạn xác định cách các gói nên được cấu trúc và cách chúng khác nhau trên cơ sở cá nhân - các đầu ra "được biên dịch" từ các công cụ của Varigence là các gói SSIS.

Hãy nghĩ về nó như là SQL động cho các gói SSIS. Với GUI. Thực sự thực sự mát mẻ.

Tôi đã thử sử dụng SSIS nhiều lần và đã từ bỏ nó. IMO sẽ dễ dàng hơn nhiều khi chỉ cần làm tất cả những gì tôi cần trong C #. SSIS quá phức tạp, nó có quá nhiều vấn đề, và nó không đáng. Sẽ tốt hơn nhiều nếu dành nhiều thời gian hơn để cải thiện các kỹ năng C # hơn là dành cùng thời gian cho việc học SSIS - bạn sẽ nhận được nhiều lợi nhuận hơn từ việc đào tạo của mình. Tôi không cần phải đi sâu vào chi tiết ở đây - Ayende đã viết một bản tóm tắt tuyệt vời mà tôi không có gì để thêm vào .

Ngoài ra, việc tìm kiếm và duy trì chức năng trong một giải pháp VS rất dễ dàng hơn nhiều. Kiểm tra đơn vị với VS rất dễ dàng. Tất cả những gì tôi cần làm là kiểm tra nguồn trong Subversion và xác minh cách tải. Đơn vị kiểm tra các gói SSIS rất liên quan để đặt nó ở mức độ nhẹ.

Bên cạnh đó, có những tình huống khi SSIS đã âm thầm thất bại trong việc đưa vào một số cột trong một số hàng, chỉ bỏ qua chúng mà không đưa ra ngoại lệ. Chúng tôi đã dành rất nhiều thời gian để khắc phục sự cố và tìm hiểu những gì đang xảy ra. Phát triển một giải pháp thay thế trong C # chỉ mất chưa đầy một giờ và hoạt động mà không gặp vấn đề gì trong hai năm.

Ngoài ra Rhino ETL dường như là thực sự mát mẻ.

Có một vài cuộc thảo luận tương tự về stackoverflow .

Cá nhân, tôi xử lý càng nhiều quá trình ETL càng tốt trong SQL. Tôi sử dụng SSIS để nhập từ các nguồn dữ liệu kỳ lạ như các trang FTP hoặc Excel, nhưng đó chỉ là để lấy dữ liệu thô vào cơ sở dữ liệu nơi SQL làm phần còn lại.

Tình hình hiện tại của tôi tương đối đơn giản ở chỗ hầu hết dữ liệu nằm trong các cơ sở dữ liệu MS SQL khác, nơi tôi có thể thiết lập các máy chủ được liên kết. Nếu bạn phải kết nối với các nền tảng khác, tôi khuyên bạn nên sử dụng OPENQUERYvà BULK INSERT. Chúng có thể được xây dựng theo chương trình nếu cần thiết và giữa hai trong số chúng có thể kết nối với hầu hết các loại dữ liệu.

Tôi sử dụng SQL vì đó là những gì tôi biết rõ nhất, nhưng nó có một số lợi thế khách quan. Đáng chú ý nhất, nó đã được sử dụng: không cần phải học hoặc trả tiền cho một công cụ mới. Đó là một kỹ năng có sẵn rộng rãi, điều quan trọng đối với sếp của bạn nếu không phải với bạn. Vì nó hoạt động trong cơ sở dữ liệu, đăng nhập rất dễ dàng. Nó dựa trên mã văn bản đơn giản, vì vậy nó dễ dàng được tìm kiếm và hoạt động tốt với kiểm soát nguồn. Nó rất ổn định, với rất ít cơ hội nhà cung cấp thay đổi mọi thứ và phá vỡ khả năng tương thích ngược. Nó có thể ít nhất là nhanh như bất kỳ ngôn ngữ RBAR nào.

Nếu bạn cần thêm, tôi khuyên dùng .NET, nếu chỉ vì nó được sử dụng trong SSIS và SQLCLR. Tôi sử dụng các ứng dụng C # để quản lý quy trình ETL tổng thể - bắt đầu các bước phụ, theo dõi đầu ra của chúng, gửi e-mail. Nhưng hầu hết tất cả những điều này có thể được thực hiện với SQL Agent, dbmail, v.v.

Có bất kỳ lý do nào bạn không thể sử dụng SQL cho ETL của mình không? Những gì nó đã không thể làm cho bạn?