ETL vs ELT:We Posit, You Judge

Tiết lộ đầy đủ:Vì bài viết này được tác giả bởi một công ty tập trung vào ETL với khả năng mạnh mẽ trong việc thao túng dữ liệu lớn bên ngoài cơ sở dữ liệu, những điều sau đây sẽ không khách quan đối với nhiều người. Tuy nhiên, nó vẫn có ý nghĩa là trình bày thức ăn để suy nghĩ và mở ra cơ sở để thảo luận.

Kể từ những ngày đầu thành lập, các kiến ​​trúc sư kho dữ liệu (DWA) đã được giao nhiệm vụ tạo và đưa vào một kho dữ liệu với dữ liệu được định dạng và có nguồn gốc khác nhau. Do sự tăng trưởng đáng kể về khối lượng dữ liệu, các DWA tương tự này được thử thách để triển khai các hoạt động tích hợp và dàn dựng dữ liệu của chúng một cách hiệu quả hơn. Câu hỏi về việc liệu việc chuyển đổi dữ liệu sẽ xảy ra bên trong hay bên ngoài cơ sở dữ liệu đích đã trở thành một câu hỏi quan trọng vì liên quan đến hiệu suất, sự tiện lợi và hậu quả tài chính.

Trong các hoạt động ETL (trích xuất, chuyển đổi, tải), dữ liệu được trích xuất từ ​​các nguồn khác nhau, được chuyển đổi riêng biệt và được tải vào cơ sở dữ liệu DW và có thể là các mục tiêu khác. Trong ELT, các phần trích xuất được đưa vào cơ sở dữ liệu dàn duy nhất cũng xử lý các phép biến đổi.

ETL vẫn thịnh hành bởi vì thị trường phát triển mạnh mẽ với những người chơi đã được chứng minh như Informatica, IBM, Oracle - và IRI với Voracity, kết hợp các biến đổi FACT (Fast Extract), CoSort hoặc Hadoop và tải hàng loạt trong cùng một Eclipse GUI - để trích xuất và chuyển đổi dữ liệu. Cách tiếp cận này tránh tạo gánh nặng cho cơ sở dữ liệu được thiết kế để lưu trữ và truy xuất (tối ưu hóa truy vấn) với chi phí chuyển đổi dữ liệu quy mô lớn.

Tuy nhiên, với sự phát triển của công nghệ cơ sở dữ liệu mới và các thiết bị phần cứng như Oracle Exadata có thể xử lý các phép biến đổi ‘trong một hộp’, ELT có thể là một giải pháp thực tế trong một số trường hợp nhất định. Và có những lợi ích cụ thể khi cô lập các lớp dàn (tải) và lớp ngữ nghĩa (biến đổi).

Một ưu điểm được trích dẫn của ELT là sự cô lập của quá trình tải khỏi quá trình chuyển đổi, vì nó loại bỏ sự phụ thuộc vốn có giữa các giai đoạn này.

Chúng tôi lưu ý rằng cách tiếp cận ETL của IRI vẫn tách biệt chúng vì Voracity phân chia dữ liệu trong hệ thống tệp (hoặc HDFS). Bất kỳ đoạn dữ liệu nào bị ràng buộc cho cơ sở dữ liệu đều có thể được thu thập, làm sạch và chuyển đổi bên ngoài trước khi tải (được sắp xếp trước). Điều này loại bỏ gánh nặng của việc chuyển đổi quy mô lớn khỏi cơ sở dữ liệu (cũng như các công cụ BI / phân tích, v.v.).

Khối lượng dữ liệu và ngân sách thường là những yếu tố quyết định việc DWA nên phát triển giải pháp ETL hay ELT. Trong bài viết trên blog ITToolbox của anh ấy “Vậy cái gì tốt hơn, ETL hay ELT?”, Vincent McBurney đưa ra những ưu và nhược điểm của mình đối với một trong hai cách tiếp cận, mà tôi đã nhắc lại ở đây bên dưới và sau đó theo dõi từng cách với một phản hồi điển hình mà IRI ETL người dùng định hướng thực hiện đúng điểm (theo cảnh báo chủ quan ban đầu của tôi):

Ưu điểm ETL

• ETL có thể cân bằng khối lượng công việc và chia sẻ khối lượng công việc với RDBMS - và trên thực tế, loại bỏ khối lượng công việc đó bằng cách chuyển đổi dữ liệu qua chương trình SortCL hoặc Hadoop mà không cần mã hóa trong Voracity
• ETL có thể thực hiện các hoạt động phức tạp hơn trong sơ đồ luồng dữ liệu đơn lẻ thông qua bản đồ dữ liệu - như với ánh xạ Voracity và sơ đồ luồng công việc cũng tóm tắt, mở Tập lệnh 4GL so với SQL
• ETL có thể mở rộng quy mô bằng phần cứng riêng biệt - trên các hộp hàng hóa, bạn có thể tự tìm nguồn và tự duy trì với chi phí thấp hơn nhiều so với các thiết bị của một nhà cung cấp
• ETL có thể xử lý phân vùng và song song độc lập với mô hình dữ liệu, bố cục cơ sở dữ liệu và kiến ​​trúc mô hình dữ liệu nguồn - mặc dù các công việc của Voracity’s CoSort SortCL hoàn toàn không cần phải phân vùng…
• ETL có thể xử lý dữ liệu trong luồng, vì nó chuyển từ nguồn sang đích - hoặc theo đợt nếu điều đó cũng hợp lý
• ETL không yêu cầu đồng vị trí của các tập dữ liệu để thực hiện công việc đó - cho phép bạn duy trì các nền tảng nguồn dữ liệu hiện có mà không phải lo lắng về đồng bộ hóa dữ liệu
• ETL nắm bắt lượng lớn siêu dữ liệu ngày nay- một người dàn DB có thể làm điều đó tốt hay trực quan đến mức nào?
• ETL có thể chạy trên phần cứng SMP hoặc MPP - một lần nữa bạn có thể quản lý và khai thác hiệu quả hơn về chi phí và không phải lo lắng về việc tranh chấp hiệu suất với DB
• ETL xử lý thông tin theo từng hàng và điều đó dường như hoạt động tốt với việc tích hợp dữ liệu vào các sản phẩm của bên thứ ba - vẫn tốt hơn là toàn bộ khối, bảng hoặc (các) tệp -at-a-time, mà Voracity chạy với số lượng lớn.

Nhược điểm ETL

• Cần đầu tư thêm phần cứng cho các công cụ ETL - trừ khi bạn chạy nó trên (các) máy chủ cơ sở dữ liệu
• Thêm chi phí xây dựng hệ thống ETL hoặc cấp phép các công cụ ETL - vẫn rẻ hơn so với các thiết bị ELT, nhưng rẻ hơn vẫn là các công cụ IRI như Voracity kết hợp Fast Extract (FACT) và CoSort để tăng tốc ETL mà không phức tạp như vậy
  
• Hiệu suất có thể bị giảm của phương pháp tiếp cận dựa trên hàng - đúng vậy và tại sao khả năng lập hồ sơ, thu thập, chuyển đổi và xuất dữ liệu của Voracity nhanh hơn
• Các kỹ năng chuyên biệt và đường cong học tập cần thiết để triển khai công cụ ETL - trừ khi bạn đang sử dụng GUI công thái học như Voracity’s cung cấp nhiều tùy chọn thiết kế công việc trong cùng một IDE Eclipse
• Giảm tính linh hoạt do phụ thuộc vào nhà cung cấp công cụ ETL - Tôi không chắc điều đó được cải thiện như thế nào bằng cách dựa vào một nhà cung cấp thiết bị / ELT duy nhất để thay thế; không phải sự độc lập của nhà cung cấp có phải là chìa khóa của sự linh hoạt và tiết kiệm chi phí không?
• Dữ liệu cần phải di chuyển qua một lớp nữa trước khi đưa vào data mart - trừ khi mart chỉ là một đầu ra khác của quy trình ETL, điển hình của hoạt động Voracity đa mục tiêu.

Ưu điểm ELT

• ELT tận dụng phần cứng công cụ RDBMS để có khả năng mở rộng - nhưng cũng đánh thuế các tài nguyên DB dành cho việc tối ưu hóa truy vấn. Các phép biến đổi CoSort và Hadoop trong Voracity sử dụng các thuật toán mở rộng tuyến tính và hợp nhất tác vụ, chứ không phải bộ nhớ hoặc tài nguyên I / O của DB
• ELT luôn giữ tất cả dữ liệu trong RDBMS - điều này tốt miễn là dữ liệu nguồn và dữ liệu đích nằm trong cùng một DB
• ELT được song song hóa theo tập dữ liệu và I / O đĩa thường được tối ưu hóa ở cấp công cụ để có thông lượng nhanh hơn - vâng, nhưng điều đó thậm chí còn giống với các biến đổi bên ngoài không cạnh tranh với tài nguyên máy chủ DB
• ELT mở rộng quy mô miễn là phần cứng và công cụ RDBMS có thể tiếp tục mở rộng - chi phí bao nhiêu so với phương án thay thế ở trên?
• ELT có thể đạt được tốc độ thông lượng gấp 3 đến 4 lần trên nền tảng MPP RDBMS được điều chỉnh thích hợp - đặt thiết bị ở mức hiệu suất Voracity so với các công cụ ETL nhưng với chi phí gấp 20 lần.
• Chuyển đổi ELT được thực hiện trên máy chủ RDBMS sau khi cơ sở dữ liệu nằm trên nền tảng đích và nó không còn gây căng thẳng cho mạng nữa - vì vậy, nó đặt áp lực lên cơ sở dữ liệu (người dùng) thay thế?
• ELT có các đặc tả chuyển đổi đơn giản thông qua SQL - không đơn giản, linh hoạt hoặc giàu tính năng như cú pháp CoSort SortCL hoặc ánh xạ trường kéo và thả trong GUI của Voracity’s Eclipse.

Nhược điểm ELT

• Các công cụ hạn chế có sẵn với sự hỗ trợ đầy đủ cho ELT - và với giá rất cao cho các thiết bị DB chào hàng hiệu suất khối lượng lớn
• Mất thống kê theo dõi thời gian chạy chi tiết và dòng dữ liệu - đặc biệt là phân tích tác động của siêu dữ liệu đối với các thay đổi đối với tệp, bảng hoặc các nguồn không có cấu trúc khác nhau
• Mất tính mô-đun do thiết kế dựa trên bộ cho hiệu suất - và mất chức năng / tính linh hoạt từ đó
• Việc chuyển đổi sẽ sử dụng tài nguyên Cơ sở dữ liệu, có khả năng ảnh hưởng đến hiệu suất báo cáo BI - chưa kể đến hiệu suất của truy vấn và các hoạt động DB khác

Các kiến ​​trúc kết hợp như ETLT, TELT và thậm chí TETLT sau đó đang nổi lên trong nỗ lực khắc phục những điểm yếu trong một trong hai cách tiếp cận. Nhưng những điều này dường như làm tăng thêm mức độ phức tạp cho các quy trình đã trở nên chật chội. Thực sự không có bất kỳ viên đạn bạc nào và nhiều dự án tích hợp dữ liệu đã thất bại do SLA, chi phí vượt mức và độ phức tạp.

Chính vì những lý do này mà IRI đã xây dựng Voracity để tích hợp dữ liệu thông qua chương trình CoSort SortCL trong các hệ thống tệp hiện có hoặc các loại vải Hadoop mà không cần mã hóa lại. Voracity là nền tảng định hướng ETL duy nhất (mặc dù cũng hỗ trợ ELT) cung cấp cả hai tùy chọn cho việc chuyển đổi dữ liệu bên ngoài. Ngoài hiệu suất vượt trội về giá cả trong việc di chuyển và thao tác dữ liệu, Voracity còn bao gồm:

• chuyển đổi dữ liệu nâng cao, chất lượng dữ liệu, MDM và báo cáo
• thay đổi từ từ các thứ nguyên, thay đổi thu thập dữ liệu, liên kết dữ liệu
• cấu hình dữ liệu, tạo mặt nạ dữ liệu, tạo dữ liệu thử nghiệm và quản lý siêu dữ liệu
• các tập lệnh 4GL đơn giản mà bạn hoặc trình hướng dẫn, sơ đồ và hộp thoại Eclipse tạo và quản lý
• thực thi liền mạch trong Hadoop MR2, Spark, Spart Stream Storm và Tez
• hỗ trợ cho các Kết nối Thông minh erwin (chuyển đổi từ các công cụ ETL khác)
• trình điều khiển MongoDB gốc và các kết nối tới các nguồn NoSQL, Hadoop, đám mây và kế thừa khác
• báo cáo được nhúng, số liệu thống kê và các chức năng dự đoán, liên kết KNIME và Splunk cũng như nguồn cấp dữ liệu công cụ phân tích.

Xem thêm:

• http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
• http://www.iri.com/solutions/data-integration/etl
• http://www.iri.com/solutions/data-integration/elt
• http://www.iri.com/solutions/data-integration/implement