Làm thế nào để tiếp cận một nhiệm vụ ETL?

Một số mẹo ETL chung

1. Hãy xem xét tổ chức nó theo lượt đích (ví dụ:tất cả các mã để tạo ra Thứ nguyên khách hàng sống trong cùng một mô-đun, bất kể nguồn nào). Điều này đôi khi được gọi là ETL hướng đối tượng. Nó giúp cho việc tìm kiếm mọi thứ trở nên dễ dàng hơn nhiều và sẽ tăng khả năng bảo trì cho mã của bạn.

2. Nếu cơ sở dữ liệu SQL2000 là một mớ hỗn độn, bạn có thể sẽ thấy rằng các luồng SSISdata là một cách vụng về để xử lý dữ liệu. Theo quy luật, cấp công cụ ETL kém với độ phức tạp; giống như một nửa số dự án datawarehouse trong các công ty tài chính được thực hiện với mã quy trình được lưu trữ như một quyết định kiến ​​trúc rõ ràng - chính vì lý do này. Nếu bạn phải đặt một lượng lớn các thanh tra mã, hãy cân nhắc đặt tất cả của mã trong mầm.
   
   Đối với một hệ thống liên quan đến nhiều quá trình lọc hoặc biến đổi phức tạp, phương pháp 100% mầm dễ bảo trì hơn nhiều vì nó là cách khả thi duy nhất để đặt tất cả các phép chuyển đổi và logic nghiệp vụ vào một nơi. Với các hệ thống ETL / cải tiến hỗn hợp, bạn phải xem xét ở nhiều nơi để theo dõi, khắc phục sự cố, gỡ lỗi hoặc thay đổi toàn bộ quá trình chuyển đổi.

3. Điểm hấp dẫn của các công cụ ETL là trên các hệ thống mà bạn có số lượng nguồn dữ liệu lớn hơn với các phép biến đổi tương đối đơn giản.

4. Làm cho mã có thể kiểm tra được, vì vậy bạn có thể chọn ngoài các thành phần và cách ly chứng thực. Mã chỉ có thể được thực thi từ bên trong luồng dữ liệu phức tạp trong công cụ ETL khó kiểm tra hơn nhiều.

5. Làm cho việc trích xuất dữ liệu trở nên ngu ngốc với logic nobusiness và sao chép vào khu vực kinh doanh. Nếu bạn có businesslogic trải rộng trên các lớp trích xuất và biểu mẫu, bạn sẽ có các định dạng không thể được kiểm tra trong sự cô lập và khiến bạn khó tìm ra lỗi. Nếu quá trình biến đổi chạy từ một khu vực tổ chức, bạn sẽ làm giảm sự phụ thuộc cứng vào hệ thống nguồn, một lần nữa tăng cường khả năng kiểm tra. Đây là một chiến thắng đặc biệt trên các kiến ​​trúc dựa trên mầm vì nó cho phép một cơ sở mã gần như hoàn toàn đồng nhất.

6. Xây dựng một trình xử lý thứ nguyên thay đổi chậm chung chung hoặc sử dụng một trình xử lý thứ nguyên thay đổi từ từ nếu có. Điều này làm cho việc kiểm tra đơn vị chức năng này trở nên dễ dàng hơn. Nếu điều này có thể không được kiểm tra, kiểm tra hệ thống không cần phải kiểm tra tất cả các trường hợp góc, chỉ đơn thuần là liệu dữ liệu được trình bày có chính xác hay không. Điều này không phức tạp như nó nghe - Bài cuối cùng tôi viết khoảng 600 hoặc 700 dòng mã T-SQL. Điều này cũng xảy ra tương tự đối với bất kỳ chức năng chà rửa thông thường nào.

7. Nạp tăng dần nếu có thể.

8. Công cụ mã của bạn - để nó thực hiện các mục nhập nhật ký, có thể ghi lại các chẩn đoán như tổng số kiểm tra hoặc số lượng. Nếu không có điều này, việc khắc phục sự cố gần như là không thể. Ngoài ra, kiểm tra xác nhận là một cách hay để nghĩ đến việc xử lý lỗi cho điều này (số hàng trong một hàng bằng nhau có đếm bằng b không, mối quan hệ A:B có thực sự là 1:1 hay không).

9. Sử dụng khóa tổng hợp. Việc sử dụng các khóa tự nhiên từ các hệ thống nguồn liên kết hệ thống của bạn với các nguồn dữ liệu và gây khó khăn cho việc thêm các nguồn bổ sung. Các khóa và mối quan hệ trong hệ thống phải luôn thẳng hàng - không có giá trị rỗng. Đối với các lỗi, "không được ghi lại", hãy tạo một mục "lỗi" hoặc "không được ghi lại" cụ thể trong bảng thứ nguyên và khớp với chúng.

10. Nếu bạn xây dựng một Kho dữ liệu hoạt động (chủ đề của nhiều cuộc chiến tranh tôn giáo), đừng tái chế các khóa ODS trong lược đồ sao. Bằng mọi cách, hãy kết hợp trên các khóa ODS để xây dựng các thứ nguyên, nhưng khớp trên một khóa tự nhiên. Điều này cho phép bạn tùy ý thả và tạo lại ODS - có thể thay đổi cấu trúc của nó - mà không làm ảnh hưởng đến các lược đồ sao. Có khả năng này là một chiến thắng bảo trì thực sự, vì bạn có thể thay đổi cấu trúc ODS hoặc triển khai lại ODS một cách thô bạo bất kỳ lúc nào.

Điểm 1-2 và 4-5 có nghĩa là bạn có thể xây dựng một hệ thống mà tất cả của mã cho bất kỳ hệ thống con nhất định nào (ví dụ:một thứ nguyên duy nhất hoặc bảng dữ kiện) nằm ở một và chỉ một nơi trong hệ thống. Loại kiến ​​trúc này cũng tốt hơn cho số lượng nguồn dữ liệu lớn hơn.

Điểm 3 là một điểm đối nghịch với điểm 2. Về cơ bản, sự lựa chọn giữa công cụ SQL và ETL là một chức năng của độ phức tạp chuyển đổi và số lượng hệ thống nguồn. Dữ liệu càng đơn giản và số lượng nguồn dữ liệu càng lớn thì trường hợp tiếp cận dựa trên công cụ càng mạnh. Dữ liệu càng phức tạp thì trường hợp chuyển sang kiến ​​trúc dựa trên các thủ tục được lưu trữ càng mạnh. Nói chung tốt hơn là sử dụng hoàn toàn hoặc hầu như chỉ sử dụng cái này hoặc cái kia chứ không phải cả hai.

Điểm 6 giúp hệ thống của bạn kiểm tra dễ dàng hơn. Kiểm tra SCD hoặc bất kỳ chức năng dựa trên thay đổi nào là khó khăn, vì bạn phải có khả năng trình bày nhiều phiên bản của dữ liệu nguồn cho hệ thống. Nếu bạn chuyển chức năng quản lý thay đổi sang mã cơ sở hạ tầng, bạn có thể kiểm tra nó một cách riêng biệt với các tập dữ liệu thử nghiệm. Đây là một chiến thắng trong thử nghiệm, vì nó làm giảm mức độ phức tạp của các yêu cầu kiểm tra hệ thống của bạn.

Điểm 7 là mẹo hiệu suất chung mà bạn sẽ cần quan sát đối với khối lượng dữ liệu lớn. Lưu ý rằng bạn có thể chỉ cần tải tăng dần cho một số phần của hệ thống; đối với các bảng và kích thước tham chiếu nhỏ hơn mà bạn có thể không cần.

Điểm 8 là vô ích đối với bất kỳ quá trình không có đầu. Nếu nó nổi lên trong đêm, bạn muốn có một số cơ hội chiến đấu để xem những gì đã xảy ra vào ngày hôm sau. Nếu mã không ghi lại chính xác những gì đang xảy ra và bắt lỗi, bạn sẽ gặp khó khăn hơn nhiều trong việc khắc phục sự cố.

Điểm 9 cung cấp cho kho dữ liệu một cuộc sống của riêng nó. Bạn có thể dễ dàng thêm và bớt các hệ thống nguồn khi kho có khóa riêng. Khóa kho cũng cần thiết để triển khai các thứ nguyên thay đổi chậm.

Điểm 10 là một chiến thắng trong việc duy trì và triển khai, vì ODS có thể được cấu trúc lại nếu bạn cần thêm hệ thống mới hoặc thay đổi bản ghi. Điều đó cũng có nghĩa là một thứ nguyên có thể được tải từ nhiều nơi trong ODS (suy nghĩ:thêm các điều chỉnh kế toán thủ công) mà không phụ thuộc vào các khóa ODS.