ETL: trích xuất từ ​​200 bảng - luồng dữ liệu SSIS hoặc T-SQL tùy chỉnh?


12

Dựa trên phân tích của tôi, một mô hình thứ nguyên hoàn chỉnh cho kho dữ liệu của chúng tôi sẽ yêu cầu trích xuất từ ​​hơn 200 bảng nguồn. Một số bảng này sẽ được trích xuất như một phần của tải tăng dần và các bảng khác sẽ là toàn bộ tải.

Để lưu ý, chúng tôi có khoảng 225 cơ sở dữ liệu nguồn tất cả cùng một lược đồ.

Từ những gì tôi đã thấy, việc xây dựng luồng dữ liệu đơn giản trong SSIS với nguồn OLE DB và đích OLE DB yêu cầu các cột và loại dữ liệu được xác định tại thời điểm thiết kế. Điều này có nghĩa là cuối cùng tôi sẽ kết thúc với hơn 200 luồng dữ liệu chỉ để trích xuất.

Từ góc độ bảo trì, điều này gây cho tôi một vấn đề lớn. Nếu tôi cần thực hiện một số thay đổi sâu rộng đối với mã trích xuất, tôi sẽ phải sửa đổi 200 luồng dữ liệu khác nhau.

Một tùy chọn khác, tôi đã viết một tập lệnh nhỏ đọc cơ sở dữ liệu nguồn, tên bảng và cột tôi muốn trích xuất từ ​​một tập hợp các bảng siêu dữ liệu. Mã này chạy trong nhiều vòng lặp và sử dụng SQL động để trích xuất từ ​​các bảng nguồn thông qua một máy chủ được liên kết và OPENQUERY.

Dựa trên các thử nghiệm của tôi, điều này vẫn không nhanh bằng việc sử dụng luồng dữ liệu SSIS với nguồn và đích OLEDB. Vì vậy, tôi tự hỏi những loại thay thế tôi có. Những suy nghĩ cho đến nay bao gồm:

  1. Sử dụng EZAPI để tạo các gói SSIS theo chương trình với luồng dữ liệu đơn giản. Các bảng và cột cần trích xuất sẽ đến từ cùng các bảng siêu dữ liệu được đề cập trước đó.
  2. Mua phần mềm bên thứ 3 (thành phần luồng dữ liệu động)

Cách tốt nhất để tiếp cận điều này là gì? Khi nói đến lập trình .NET Tôi là người mới bắt đầu, vì vậy thời gian cần thiết để tăng tốc chỉ với những điều cơ bản cũng là một mối quan tâm.


1
Vì tất cả 225 cơ sở dữ liệu có cùng một lược đồ, có thể duy trì chế độ xem liên kết dữ liệu từ tất cả 225 cơ sở dữ liệu và trỏ gói SSIS vào đó không? Mặc dù điều này có vẻ giống như một công cụ ghi đè và không nhất thiết phải thực hiện một cách kỳ diệu, nhưng nó có vẻ dễ quản lý hơn 225 gói SSIS (ngay cả khi bạn quản lý một số tự động hóa ở đó). Bạn cũng có thể đi được nửa đường và xây dựng chế độ xem cho từng bộ cơ sở dữ liệu, ví dụ: cơ sở dữ liệu 1-25, 26-50, 51-75, v.v.
Aaron Bertrand

Các cơ sở dữ liệu nằm trên nhiều máy chủ mà tôi nghĩ làm cho nó phức tạp hơn. Tôi thực sự đã cố gắng tạo một chế độ xem các bảng khác nhau trên hộp phát triển của mình dựa trên 225 cơ sở dữ liệu và việc đọc dữ liệu rất chậm.
8kb

1
Vâng, bạn sẽ chỉ muốn một khung nhìn để tham chiếu cơ sở dữ liệu trên cùng một máy chủ. Và một lần nữa, một chế độ xem chống lại tất cả 225 bảng sẽ không thực hiện một cách kỳ diệu, nhưng tôi nghĩ bạn vẫn có thể phân chia và chinh phục và không có 225 luồng dữ liệu.
Aaron Bertrand

Câu trả lời:


12

Tôi sẽ không muốn có 200 luồng dữ liệu trong một gói. Thời gian chỉ cần mở ra và xác nhận sẽ khiến bạn già trước thời gian.

EzAPI rất thú vị nhưng nếu bạn chưa quen với .NET SSIS, ồ không, bạn không muốn điều đó. Tôi nghĩ rằng bạn sẽ dành nhiều thời gian hơn để tìm hiểu về mô hình đối tượng SSIS và có thể xử lý COM hơn là thực sự hoàn thành công việc.

Vì tôi lười biếng, tôi sẽ cắm BIML như một tùy chọn miễn phí mà bạn không liệt kê. Từ một câu trả lời trên SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604

  • Biml là một con thú thú vị. Varigence sẽ rất vui khi bán cho bạn giấy phép cho Mist nhưng không cần thiết. Tất cả những gì bạn cần là BIDSHelper và sau đó duyệt qua BimlScript và tìm kiếm một công thức gần đúng với nhu cầu của bạn. Khi bạn đã có điều đó, hãy nhấp vào nút menu ngữ cảnh nhạy cảm trong BIDSHelper và whoosh, nó sẽ tạo ra các gói.

Tôi nghĩ rằng nó có thể là một cách tiếp cận cho bạn là tốt. Bạn xác định BIML mô tả cách các gói của bạn hoạt động và sau đó tạo chúng. Trong kịch bản bạn mô tả nơi bạn thực hiện thay đổi và phải sửa N gói, không, bạn sửa định nghĩa của bạn về vấn đề và tạo lại gói.

Hoặc nếu bạn đã đủ quen thuộc với khung công tác thì hãy sử dụng thứ gì đó như EzAPI để sửa và sửa tất cả những thứ bị hỏng. Heck, vì bạn đã gắn thẻ này là năm 2005, bạn cũng có thể dùng thử PacMan nếu bạn cần thực hiện sửa đổi hàng loạt cho các gói hiện có.

Cân nhắc thiết kế SSIS

Nói chung, tôi cố gắng làm cho các gói của mình tập trung vào giải quyết một nhiệm vụ duy nhất (tải dữ liệu bán hàng). Nếu điều đó đòi hỏi 2 luồng dữ liệu, vì vậy hãy là nó. Điều tôi ghét kế thừa là một gói từ trình hướng dẫn xuất nhập với nhiều luồng dữ liệu không liên quan trong một gói. Phân tách chúng thành một cái gì đó giải quyết một vấn đề rất cụ thể. Nó làm cho các cải tiến trong tương lai ít rủi ro hơn khi diện tích bề mặt giảm. Một lợi ích nữa là tôi có thể làm việc với việc tải DimProductstrong khi minion của tôi đang xử lý SnowflakeFromHellgói tải .

Sau đó sử dụng (các) gói chính để phối hợp các luồng công việc con. Tôi biết bạn đang ở trên 2005 nhưng bản phát hành SSIS của SQL Server 2012 là đồ ngủ của mèo. Tôi thích mô hình triển khai dự án và sự tích hợp chặt chẽ mà nó cho phép giữa các gói.

TSQL vs SSIS (câu chuyện của tôi)

Đối với cách tiếp cận TSQL thuần túy, trong một công việc trước đó, họ đã sử dụng một công việc 73 bước để sao chép tất cả dữ liệu Informix của họ vào SQL Server. Nó thường mất khoảng 9 giờ nhưng có thể kéo dài đến 12 hoặc hơn. Sau khi họ mua SAN mới, nó đã giảm xuống còn khoảng hơn 7 giờ. Quá trình logic tương tự, được viết lại trong SSIS là một phụ 2 giờ nhất quán. Dễ dàng yếu tố lớn nhất trong việc giảm thời gian đó là sự song song "miễn phí" mà chúng tôi đã sử dụng SSIS. Công việc Đại lý đã chạy tất cả các nhiệm vụ nối tiếp. Gói chính về cơ bản đã chia các bảng thành các đơn vị xử lý (5 bộ tác vụ song song của "chạy bản sao bảng 1", bảng 2, v.v.) trong đó tôi đã cố gắng chia các nhóm thành các đơn vị công việc có kích thước bằng nhau. Điều này cho phép các bảng tham chiếu tra cứu 60 hoặc hơn được nhập nhanh chóng và sau đó quá trình xử lý bị chậm lại khi nó vào "

Điểm cộng khác đối với tôi khi sử dụng SSIS là tôi có được cấu hình "miễn phí", ghi nhật ký và truy cập vào các thư viện .NET cho dữ liệu vuông tôi cần để khoét vào một lỗ tròn. Tôi nghĩ rằng có thể dễ dàng duy trì (bỏ bảo trì) gói SSIS hơn là cách tiếp cận TSQL thuần túy nhờ vào bản chất đồ họa của con thú.

Như mọi khi, phụ cấp của bạn có thể khác nhau.


BIML trông rất thú vị. Tôi cũng đã xem xét việc tạo mỗi luồng dữ liệu dưới dạng một gói riêng biệt và sau đó gọi chúng thông qua gói chính. Bạn có nghĩ rằng điều đó tốt hơn không? Ngoài ra, tò mò nếu bạn có ý kiến ​​về cách tiếp cận T-SQL. Nó chậm hơn nhưng tôi đã thử nó và nó sẽ hoạt động.
8kb

Tôi đã cập nhật phản hồi của mình với những suy nghĩ về thiết kế và cách tiếp cận
tsL

0

Bạn đã đề cập bạn có 200 bảng nguồn và 225 cơ sở dữ liệu. Tôi giả sử 200 bảng nguồn là tổng số tất cả các bảng từ tất cả 225 cơ sở dữ liệu (vì nếu bạn có 200 bảng trong mỗi cơ sở dữ liệu sẽ đưa tổng số bảng của bạn lên 45000). Bạn cũng đã đề cập rằng lược đồ của cơ sở dữ liệu là giống nhau cho cơ sở dữ liệu 225.

Trước tiên, bạn có thể xây dựng các gói SSIS cho 1 cơ sở dữ liệu và sau đó khi bạn lên lịch cho công việc của mình, bạn chỉ cần thay đổi chuỗi kết nối cơ sở dữ liệu bằng cấu hình gói (nếu SQL 2005 của bạn, thì bạn sẽ sử dụng mô hình triển khai gói). Như đã đề cập trong các phản hồi trước đó, SQL 2012 có những cách mới để định cấu hình các đối tượng của bạn bằng mô hình triển khai dự án.

Bạn có thể nhận thêm thông tin về cấu hình gói với SSIS tại đây http://www.sql-server-performance.com/2007/package-configuration-2005/

Bạn có thể nhận thêm thông tin về việc sử dụng các tham số dự án từ đây, /programming/15206184/how-to-configure-ssis-2012-project-to-run-under-different-en môi-configurat

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.