Tránh viết các truy vấn SQL hoàn toàn trong SSIS

Question

Làm việc trên một dự án Kho dữ liệu, người đã cho chúng tôi hướng dẫn được khuyên rằng chúng ta phải sử dụng các truy vấn SQL để xác định rất nhiều chuyển đổi luồng dữ liệu. bộ nhớ trên hộp ETL vì vậy chúng tôi muốn để quá trình xử lý vào hộp DB. Điều này có thực sự được khuyến khích không? Sự cân bằng giữa việc dựa vào các công cụ GUI khi thực thi một loạt các kịch bản SQL trên gói Tích hợp của bạn ở đâu?

Và thành thật mà nói, tôi muốn tránh viết các truy vấn SQL nhiều nhất có thể. (nhưng đó là bên cạnh vấn đề. Tôi thực sự muốn xem xét điều này một cách khách quan.)

Answer 1

Câu trả lời là: nó phụ thuộc, nhưng bạn muốn chọn cái này hay cái kia cho bất kỳ công việc nào và tránh trộn lẫn hai nơi có thể.

Nói chung, tốt nhất là hãy làm mọi thứ có thể trong công cụ hoặc làm mọi thứ có thể trong mã thủ tục được lưu trữ. Khi bạn có một lượng đáng kể phân chia logic giữa các lớp, hệ thống trở nên khó theo dõi và gỡ lỗi hơn.

• Trường hợp công cụ có thể làm biến đổi không có dữ liệu dòng trở thành vụng về và phức tạp, bạn có thể sử dụng công cụ và cố gắng có ít hoặc không có logic trong truy vấn. Điều này có nghĩa rằng một lớp duy nhất có logic nghiệp vụ và nó sẽ khá rõ ràng nơi để tìm nó. Tuy nhiên, các công cụ ETL có xu hướng xử lý các phép biến đổi phức tạp cao tương đối kém. Điểm ngọt cho loại phương pháp này là trên các hệ thống mà bạn có một số lượng lớn các nguồn dữ liệu nhưng các phép biến đổi tương đối đơn giản.

• Nếu bạn có các phép biến đổi tương đối phức tạp, bạn có thể nên tắt tất cả logic nghiệp vụ và chuyển đổi thành một lớp thủ tục được lưu trữ. Mã SQL tốt hơn khi triển khai các phép biến đổi phức tạp theo cách có thể bảo trì - tôi có nó trên cơ sở khá tốt, khoảng một nửa tất cả các dự án kho dữ liệu trong các lĩnh vực ngân hàng và bảo hiểm sử dụng loại kiến ​​trúc này vì lý do chính xác đó.
  
  Trong trường hợp này, công cụ ETL có thể được sử dụng để thực hiện các bản sao dữ liệu tương đối câm. Dữ liệu nguồn có thể được sao chép vào các khu vực dàn dựng về cơ bản nguyên văn và sau đó được chọn bởi một cơ thể của mã thủ tục được lưu trữ thực hiện ETL. Công cụ ETL có thể được sử dụng cho các bản sao dữ liệu, các hoạt động tải khối lượng lớn, ghi nhật ký, lên lịch và các nhiệm vụ khung khác.

Trong cả hai trường hợp, bạn nên chọn một cách tiếp cận. Nếu không, bạn có thể kết thúc với logic nghiệp vụ trải rộng trên các lớp khai thác, khung nhìn cơ sở dữ liệu, luồng dữ liệu và mã thủ tục được lưu trữ. Logic trải rộng trên nhiều lớp khó kiểm tra hơn nhiều.

Khi tất cả logic (ví dụ) chứa trong các thủ tục được lưu trữ hoặc các công việc chuyển đổi ETL tập trung, bạn có thể kiểm tra một biến đổi đã cho. Sự rõ ràng trong thiết kế cũng giúp bảo trì và kiểm toán.

Answer 2

Tôi nghĩ đây là một câu hỏi khó; và một điều thú vị nữa.

Một lý do để sử dụng SSIS là cải thiện khả năng bảo trì, IMHO. Nếu bạn đóng gói tất cả các logic trong các câu lệnh SQL (và bạn chắc chắn có thể!), Bạn có xu hướng làm hỏng lý do này khi sử dụng SSIS ngay từ đầu. Bạn không thể thực sự "nhìn thấy dòng dữ liệu" nữa.

Mặt khác, tôi cảm thấy có những lúc mà một câu lệnh SQL được đặt tốt có giá trị của nó. Ví dụ khi bạn đọc dữ liệu từ một bảng và vì bất kỳ lý do nào đã biết bạn sẽ chỉ cần các hàng thỏa mãn điều kiện X Tôi không thấy lý do đọc toàn bộ bảng và trong bước tiếp theo "có điều kiện phân tách phần lớn nó đi".
Điều tôi không biết là điều này có ý nghĩa gì về hiệu suất, bằng cách này. SSIS có đủ thông minh để xem điều gì đang xảy ra và thay đổi "đọc toàn bộ bảng và điều kiện-chia-nó" thành "chọn Y từ trong đó X" khi đang di chuyển (hoặc khi xây dựng/triển khai) không?

Câu hỏi lớn là nơi vẽ đường kẻ. Và điều này tùy thuộc vào mức độ nhất định đối với những người làm việc trong quy trình ETL của bạn. Nếu mọi người từng hỗ trợ quá trình này biết SQL từ khi bắt đầu, bạn có thể hỗ trợ tốt hơn số lượng SQL trong ETL cao hơn nếu bạn có đồng nghiệp (hoặc khách hàng, hoặc những người thừa kế bạn quan tâm) mà hầu như không hiểu những gì đang xảy ra trong tất cả SQL của bạn , hãy để một mình thay đổi/cải thiện/thêm vào nó.

Vì vậy, tôi nghĩ rằng điểm mấu chốt là không sử dụng cũng như không làm mọi thứ trong SQL là tốt hơn. Cố gắng tạo nên một số quy tắc đơn giản phù hợp với yêu cầu của bạn và mọi người có thể sống cùng, sau đó theo dõi chúng. Điều này sẽ mang lại cho bạn giá trị cao nhất từ ​​việc sử dụng SSIS.

Answer 3

Nói chung khi bạn muốn xử lý từng hàng riêng lẻ, hãy sử dụng luồng dữ liệu, nếu không thì tốt hơn nên sử dụng lệnh Sql.

Cá nhân tôi muốn thực hiện bằng cách viết SQL nơi tôi có thể. Dễ dàng hơn để tối ưu hóa sau và (thường) nhanh hơn. Google sẽ cung cấp nhiều câu trả lời chi tiết hơn.

Một yếu tố khác để nghĩ đến là nhà cung cấp mà bạn sử dụng cho kết nối của mình.

Bạn cần đưa ra quyết định dựa trên nhu cầu của mình. Chúng tôi sử dụng DB postgres, vì vậy chúng tôi phải tạo một tải các bảng dàn dựng cho một số quy trình, giúp tăng tốc độ toàn bộ.

Bạn cũng nên xem xét hộp đang chạy, nếu bạn có một hộp DB mạnh mẽ và một hộp ETL nhỏ, sẽ không có điểm khi chạy bất kỳ thứ gì.

Nếu bạn thực hiện tất cả quá trình xử lý trên hộp ETL, bạn cũng sẽ kéo rất nhiều dữ liệu trên mạng.

Kiểm tra các liên kết này để giúp bạn bắt đầu:

ssistalk.com/category/SSIS/SSIS-tiên tiến kỹ thuật/

msdn.microsoft.com/en-us/library/ms141031.aspx

weblogs.sqlteam.com/jamesn/Default.aspx

Answer 4

Tôi thấy rằng việc sử dụng mã SQl không chỉ chạy nhanh hơn mà còn nhanh hơn để phát triển và dễ bảo trì hơn nhiều.

Answer 5

Máy chủ SQL thực hiện một số việc tốt và những thứ khác không tốt. Tôi sử dụng SSIS để nhập hoặc xuất dữ liệu từ SQL Server. Trong quá trình di chuyển, tôi sử dụng SSIS ở nơi có ý nghĩa. Tôi có thể dễ dàng làm việc trên cơ sở mỗi hàng, mà không phải là rất hiệu quả trong SQL Server (con trỏ). Để nói rằng bạn không nên sử dụng phép biến đổi và luồng dữ liệu trên một hộp ETL, bởi vì nó quá đắt trên hộp ETL giống như nói 'đừng lái xe quá nhanh, vì nó khiến động cơ hoạt động'. Mục đích của một ETL và SSIS là thực hiện một số xử lý mà SQL Sever không hoạt động tốt và di chuyển nó đến một công cụ thực hiện.

Answer 6

Đã sử dụng đúng công cụ cho công việc. Nói chung, bạn làm hầu hết mọi thứ trong SSIS, với một số điều được thực hiện trong SQL "thuần túy". Ví dụ, trong trường hợp bạn làm rất nhiều UPDATE (sự khác biệt bảng trên bảng kích thước trong một mô hình chiều, nói), bạn thực sự không muốn thực hiện một CẬP NHẬT cho mỗi hàng.Trong trường hợp này, bạn thực hiện chèn thường xuyên vào một bảng tạm thời và sau đó thực hiện cập nhật trong SQL, tham gia vào các khóa thích hợp.