ETL là gì?
1. Khái niệm
ETL = Extract – Transform – Load
Quá trình ELT là công cụ ETL sẽ trích xuất tất cả dữ liệu từ những hệ thống nguồn đa dạng khác nhau và sau đó chuyển đổi dữ liệu như áp dụng những biến đổi dữ liệu (nối chuỗi, tính toán,…), sau đó sẽ tải dữ liệu vào trong hệ thống Data Warehouse.
Khi xây dựng cơ sở hạ tầng ETL, bạn sẽ phải tích hợp dữ liệu từ nhiều nguồn khác nhau. Do đó, bạn cần lên kế hoạch và test một cách cẩn thận để đảm bảo rằng bạn chuyển đổi dữ liệu chính xác.
ETL
Một trường hợp sử dụng phổ biến cho ETL là trong data warehouse. Quá trình ETL chuẩn bị OLTP data, ví dụ như dữ liệu transaction hằng ngày từ tài chính, ERP hay CRM, để load vào data warehouse cho mục đích báo cáo hoặc phân tích bằng các công cụ BI.
ETL process
Quy trình ETL cổ điển là sử dụng batch processing. ETL jobs chạy hàng ngày, hàng tuần hoặc hàng tháng để xử lý một lượng lớn dữ liệu từ hệ thống nguồn:
Tham chiếu dữ liệu (Reference data) – Tạo một tập dữ liệu tham chiếu định nghĩa các giá trị được cho phép. Ví dụ, trong field dữ liệu data về 1 đất nước, chỉ định một list các country code được phép.
Trích xuất dữ liệu (Data extraction) – Trích xuất dữ liệu từ các nguồn, chuyển đổi các định dạng như RDBMS, XML, JSON, CSV, etc. thành một định dạng tiêu chuẩn. Cơ sở cho sự thành công của các bước ETL tiếp theo là trích xuất dữ liệu một cách chính xác.
Data validation – Validate dữ liệu để đảm bảo rằng nó bao gồm các thông tin cần thiết cũng như đúng định dạng – Nếu không đảm bảo bước này, các bước sau của quá trình ETL có thể sẽ không hoạt động. Ví dụ: nếu bạn chỉ muốn các ngày từ năm trước, hãy lược bỏ bất kỳ giá trị nào cũ hơn 12 tháng. Phân tích các dữ liệu bị lược bỏ để có thể phát hiện các vấn đề, chỉnh sửa lại source data và modify quá trình trích xuất để giải quyết các vấn đề trong các batch tiếp theo.
Chuyển đổi dữ liệu (Data transformation) – Chuyển đổi dữ liệu bằng cách làm sạch (loại bỏ các dữ liệu trùng lặp), xác minh tính toàn vẹn của nó và tổng hợp hoặc tái cấu trúc để việc phân tích dễ dàng hơn. Ví dụ, nếu bạn muốn phân tích doanh thu, bạn có thể tổng hợp số tiền của invoices theo ngày hoặc theo tháng. Bạn sẽ cần phải lập trình ra các công thức tính toán để có thể chuyển đổi dữ liệu một cách chính xác.
Staging – Thông thường, bạn sẽ không load dữ liệu đã được transformed vào thẳng production data warehouse mà sẽ load dữ liệu vào môi trường staging, để có thể roll back nếu có vấn đề xảy ra. Bạn cũng có thể tạo các báo cáo audit tại bước này.
Load data vào warehouse (Load to data warehouse) – Nếu mọi thứ có vẻ đã ổn, đẩy data vào production data warehouse, ghi đè các dữ liệu cũ hoặc quản lý các phiên bản cũ dựa vào timestamp.
Một số ví dụ về ETL
Trích xuất dữ liệu:
Trích xuất dữ liệu là bước đầu tiên của quá trình ETL. Trích xuất dữ liệu có nhiều loại – data được copy trực tiếp từ thiết bị lưu trữ, load thông qua APIs, stream bằng các tools như Kafka, etc. Hãy xem xét một ví dụ đơn giản: data files upload lên FTP server và cần phải load vào bảng trong data warehouse.
Công thức dưới đây sử dụng Type 4 Slowly Changing Dimension – data được modified được lưu vào 1 table riêng và quản lý lịch sử bằng timestamp.
Để trích xuất dữ liệu nguồn được transferred thông quan FTP, đồng thời quản lý các versions cũ hơn của data:
Duy trì 2 bảng – 1 bảng mục tiêu (target table) và một bảng chứa các version cũ hơn được quản lý theo timestamps của mỗi data field (history table)
Tạo trigger tự động phát các hiện file mới trong một thư mục được chỉ định ở FTP server và pulls chúng về ETL machine.
Load data từ source file vào một bảng tạm
Load bảng mục tiêu hiện có vào một temporary lookup file.
Với mỗi record ở source record, làm như sau:
Validate source data record và nếu không pass quá trình validate, thì lưu vào reject table.
Kiểm tra các record với lookup table. Nếu không tồn tại, load vào target table như một record mới.
Nếu record không tồn tại ở lookup table, và giá trị bị thay đổi thì lưu giá trị mới vào history table, sau đó load giá trị mới vào target table, overwrite lại giá trị cũ. Nếu giá trị không đổi thì không cần làm gì.
Surrogate Key Generation
Surrogate key là data field được thêm bởi các kỹ sư ETL để quản lý data tới từ các nguồn khác nhau. Surrogate key là duy nhất, định nghĩa bằng số, map với “natural keys” gốc ở source data, như là customer IDs hoặc transaction IDs.
Một số “Từ khóa” (Terminology) về các Keys
<cite>Key. A key is one or more data attributes that uniquely identify an entity. In a physical database a key would be formed of one or more table columns whose value(s) uniquely identifies a row within a relational table. </cite><cite>Composite key. A key that is composed of two or more attributes. </cite><cite>Natural key. A key that is formed of attributes that already exist in the real world. For example, U.S. citizens are issued a Social Security Number (SSN) that is unique to them (this isn't guaranteed to be true, but it's pretty darn close in practice). SSN could be used as a natural key, assuming privacy laws allow it, for a Person entity (assuming the scope of your organization is limited to the U.S.). </cite><cite>Surrogate key. A key with no business meaning.</cite><cite>Candidate key. An entity type in a logical data model will have zero or more candidate keys, also referred to simply as unique identifiers (note: some people don't believe in identifying candidate keys in LDMs, so there's no hard and fast rules). For example, if we only interact with American citizens then SSN is one candidate key for the Person entity type and the combination of name and phone number (assuming the combination is unique) is potentially a second candidate key. Both of these keys are called candidate keys because they are candidates to be chosen as the primary key, an alternate key or perhaps not even a key at all within a physical data model. </cite><cite>Primary key. The preferred key for an entity type.</cite><cite>Alternate key. Also known as a secondary key, is another unique identifier of a row within a table. </cite><cite>Foreign key. One or more attributes in an entity type that represents a key, either primary or secondary, in another entity type.</cite>
Use surrogate keys as primary keys in database development because it can speed up joins between tables. Instead of using a character string (the business key) to join two records, they started to use integer-based surrogate keys to reduce the complexity (think of composite keys) and improve the speed of joins.
Chi tiết về surrogate key và natural key có thể tham khảo thêm tại:
sites.google.com/site/dbi202databasesystem/..
Để load data đồng thời tạo ra surrogate key – Overwrite data hiện có:
Chọn natural keys ở source data.
Tạo mapping table, map tất các giá trị của natural keys vào surrogate key (The table should include a value that denotes the maximum key number of the last data field loaded.)
Thực thi quá trình load cho mỗi source file:
Validate rằng mapping table map các values của source data một cách chính xác.
Với từng data record, kiểm tra xem surrogate key đã tồn tại ở target table hay chưa (If so, overwrite the same record.)
Nếu surrogate key không tồn tại, add một entry mới vào mapping table, và add một record mới vào target table, sau đó tăng maximum key lên 1.
Một quy trình tương tự, phức tạp hơn một chút có thể được thiết kế để loaddữ liệu trong khi vẫn giữ phiên bản cũ của dữ liệu.
Header và Trailer Processing
Nhiều data source, bao gồm legacy sources và network traffic data, có những record được sắp xếp trong blocks với header gồm standard descriptive data và trailer ở cuối.
Ví dụ bạn có input records trông như sau:
2008/04/23
Geometry
Algebra
Trigonometry
Calculus
0004
End of data set
Record đầu tiên là header record chứa thông tin về ngày, 2 records cuối là trailer records, ở giữa là data records.
Để process header và payload:
Loại xử lý này thường dễ thực hiện nhất bằng cách sử dụng ETL processing tool. Lựa chọn tool mà bạn muốn, trích xuất dữ liệu và add thêm 1 separator bên trong file chỉ định các phần header, body và trailer của data.
Sử dụng separator, chia data vào 3 bảng: headers, body và trailers
Tham chiếu đến tài liệu của định dạng header và trailer, convert thành dạng có thể sử dụng trong bảng header and trailer.
Đảm bảo rằng bạn một record ID map data với headers và trailers
DaTA MASKING
Một yêu cầu thường gặp trong các dự án liên quan đến dữ liệu là mask, xáo trộn hoặc làm ẩn danh dữ liệu. Điều này có thể cần thiết khi:
Khi testing hoặc staging data (để ngăn các data nhạy cảm của khách hàng lưu trên các non-production servers)
Khi chuyển OLTP data sang data warehouse, data sẽ có thể cần làm ẩn danh để giảm thiểu các vấn đề bảo mật, đồng thời giữ thông tin có tính business-relevant trong mỗi data record.
Các phương pháp:
Substitution – thay thế giá trị của các data nhạy cảm bằng fake data từ một dictionary table
Masking – Thêm các ký tự như để thay thế các data nhạy cảm. VD: số thẻ credit 16 số, thì thay 12 số đầu là , chỉ giữ lại 4 số cuối.
Hashing – Sử dụng one-way function để chuyển các sensitive data thành các giá trị hoàn toàn khác, nhưng vẫn giữ nguyên size và format như bản gốc
Shuffling – xáo trộn data một cách ngẫu nhiên
Randomization – tạo ra data một cách ngẫu nhiên để thay thế các data nhạy cảm gốc.
Data Quality và Data Cleansing
Bất cứ ETL process nào cũng phải validate tính toàn vẹn dữ liệu của data.
Xem xét 1 data quality process đơn giản gồm 2 tests sau:
Syntax test – phát hiện các records có data pattern sai, ký tự invalid, data types bị sai, etc.
Reference test – phát hiện các records có data pattern đúng nhưng không match với reference data – VD, một order chứa một sản phẩm không tồn tại trong products table.
Để tạo một data cleansing process tự động:
Với dates, kiểm tra xem date có đúng format và thoải mãn business rules không (vd: orders nên là từ tuần trước)
Với IDs, kiểm tra xem có gồm các ký tự đúng và số ký tự có nằm trong dải được chấp nhận không
Với address, kiểm tra syntax, và check các component với dictionary table các giá trị như tên nước, thành phố, và tên đường, etc.
Với số điện thoại, kiểm tra format, cho phép các format số điện thoại quốc tế, và kiểm tra country code, so sánh với dictionary table.
Tương tự kiểm tra các data fields khác trong dữ liệu của bạn
Lưu các data fields có lỗi vào 1 reject file, để có thể xử lý các vấn đề và sửa dữ liệu bằng tay.
Với bất kỳ issue nào được tìm thấy, báo warning nếu lỗi không nghiêm trọng, và lưu vào target table. Thông báo error nếu đó là lỗi nghiêm trọng và không lưu vào target table.
3 cách để build 1 ETL process
Build ETL Pipeline với batch processing:
Như đã trình bày ở trên
Build etl pipeline với stream processing:
Các xử lý dữ liệu hiện đại thường bao gồm dữ liệu real-time, ví dụ như web analytics từ một e-commerce website lớn. Trong trường hợp này, bạn sẽ không thể trích xuất được dữ liệu bằng cách sử dụng các batch lớn. Thay vào đó, bạn sẽ sử dụng data stream ETL pipeline. Theo đó, khi client applications ghi dữ liệu vào data source thì bạn sẽ cần làm sạch và chuyển đổi nó trong quá trình nó được chuyển đến target data source.
Có nhiều công cụ xử lý stream cho bạn sử dụng, ví dụ như Apache Samza, Apache Storm, và Apache Kafka.
Sơ đồ sau mô tả một ETL pipeline sử dụng Kafka:
Để xây dựng 1 stream processing ETL data pipeline với Kafka, bạn cần phải:
Trích xuất dữ liệu vào Kafka: Confluent JDBC connector kéo mỗi row của source table và ghi chúng như các cặp key/value vào một Kafka topics (a feed where records are stored and published) (Xem thêm: cloudkarafka.com/blog/part1-kafka-for-begin..). Các applications quan tâm tới state của bảng sẽ đọc từ topic này. Khi client applications thêm row vào source table, Kafka tự động ghi chúng như messages mới vào Kafka topic, enable một real-time data stream. Lưu ý rằng, bạn cũng có thể tự triển khai một database connection mà không cần sử dụng các sản phẩm thương mại của Confluent.
Pull dữ liệu từ Kafka topics: ETL application trích xuất messages từ Kafka topic dưới dạng các Avro records (Xem thêm về Avro tại đây: en.wikipedia.org/wiki/Apache_Avro), tạo một Avro schema file, và deserialize (hazelcast.com/glossary/deserialization) chúng. Sau đó tạo ra KStream objects từ các message.
Transform data trong KStream objects: Bằng cách sử dụng Kafka Stream API (kafka.apache.org/documentation/streams), stream processor sẽ nhận mỗi lần một record, xử lý nó và produces 1 hoặc nhiều output records cho downstream processors. Các processor này có thể transform mỗi lần 1 message, filter chúng dựa vào các conditions, và và thực hiện các thao tác dữ liệu trên nhiều message, ví dụ như tổng hợp.
Load data tới các hệ thống khác: ETL application sẽ vẫn giữ enriched data, và giờ sẽ cần phải stream nó lên các target system, như là data warehouse hay data lake. Trong ví dụ này, Confluent đề xuất sử dụng S3 Sink Connector để stream data tới Amazon S3. Bạn có thể integrate với những hệ thống khác như là Redshift data warehouse bằng cách sử dụng Amazon Kinesis.
Xây dựng 1 data pipeline tự động không có ETL
Công nghệ cloud data warehouse cho phép đạt được các mục tiêu của ETL mà không cần phải xây dựng hệ thông ETL.
Các bước thông thường sẽ như sau:
Chọn data source và import dữ liệu: Chọn data source từ danh sách, nhập credentials và định nghĩa destination tables. Các tools sẽ tự động kéo dữ liệu cho bạn, và có thể là làm cả các việc như chuẩn bị dữ liệu, làm sạch dữ liệu, etc.
Chạy các câu query để chuyển đổi dữ liệu: Chọn bảng, chạy các câu lệnh SQL với raw data. Bạn có thể lưu query và export bảng kết quả dưới dạng csv, excel, etc.
Thực hiện phân tích dữ liệu với các công cụ BI.
Giờ đây bạn đã biết 3 cách để xây dựng quy trình ETL, bạn có thể hiểu như 3 giai đoạn phát triển của ETL. ETL thì dùng được, nhưng nó chậm và sẽ sớm trở thành out-of-date. Nếu bạn muốn tổ chức của bạn tối ưu các giá trị từ data, thì đã đến lúc sử dụng ELT workflow.
Vấn đề với ETL và ELT
Quy trình ETL truyền thống là tiêu chuẩn trong nhiều tổ chức lớn. Tuy nhiên nó khó để build và test, cồng kềnh khi maintain. Do đó, nhiều tổ chức đang dịch chuyển sang data warehouse infrastructure mới hỗ trợ Extract Load Transform (ELT)
ELT
Với quy trình ELT, bạn sẽ trích xuất data trước, sau đó chuyển luôn tới 1 centralized data repository. Sau đó, data transform sẽ được thực hiện khi cần thiết. Phương pháp này nhận dữ liệu trước các nhà phân tích nhanh hơn nhiều so với ETL đồng thời đơn giản hóa kiến trúc.
Hơn nữa, kho dữ liệu đám mây và cơ sở hạ tầng data lake ngày nay hỗ trợ khả năng lưu trữ dồi dào và khả năng mở rộng tính toán. Do đó, không còn cần thiết phải ngăn kho dữ liệu “bùng nổ” bằng cách giữ cho dữ liệu nhỏ và summarized thông qua các phép biến đổi trước khi tải. Có thể duy trì nhóm dữ liệu khổng lồ trên đám mây với chi phí thấp trong khi tận dụng các công cụ ELT để tăng tốc và đơn giản hóa việc xử lý dữ liệu.
Cơ sở hạ tầng Data Warehouse: Full và Incremental loading trong ETL.
Một trong những mục tiêu cuối cùng của việc có một quy trình ETL hiệu quả và ETL Data Warehouse , là khả năng truy vấn dữ liệu một cách đáng tin cậy, có được thông tin chi tiết và tạo hình ảnh trực quan. ETL Data Warehouse nắm giữ một số lợi thế cho các tổ chức, cho phép họ thu thập tất cả dữ liệu của họ trong toàn tổ chức (nghĩ rằng ERP, CRM, thông tin thanh toán, số liệu bán hàng) và truy vấn dữ liệu này, sử dụng nó để tìm các mẫu và mối quan hệ, xác định sự không hiệu quả, tạo báo cáo và đánh giá KPI.
Theo truyền thống, khi dữ liệu được load vào ETL Data Warehouse, nó có thể được xem bằng các công cụ như Tableau và Qlik.
Một trong những yếu tố quan trọng nhất của quy trình ETL là luồng dữ liệu vào ETL Data Warehouse.
Chuyển đổi và staging source data
Với việc dữ liệu được thu thập và lưu trữ trong nhiều hệ thống khác nhau, mỗi hệ thống có cách lưu trữ dữ liệu riêng, quá trình thu thập và đối chiếu dữ liệu này và làm cho dữ liệu này trở nên hữu ích cho người dùng cuối. Từ đó, ETL được sử dụng.
Đầu tiên, dữ liệu được trích xuất từ các hệ thống khác nhau, mỗi hệ thống có định dạng riêng. Sau đó, nó được chuyển đổi thành một định dạng tiêu chuẩn và có thể sử dụng được trên toàn hệ thống. Giai đoạn này chủ yếu bao gồm việc loại bỏ dữ liệu không liên quan hoặc sai sót, áp dụng các quy tắc và kiểm tra tính toàn vẹn của dữ liệu.
Sau đó là giai đoạn staging. Và cuối cùng data được publish vào ETL Data Warehouse và load vào target tables. Tuy nhiên, nếu có lỗi, corrupt dữ liệu, trùng lặp hoặc miss records, độ tin cậy của ETL Data Warehouse sẽ bị ảnh hưởng. Dữ liệu được load sẽ bao gồm dữ liệu lịch sử – các bản ghi đã tồn tại, chẳng hạn như các giao dịch của năm trước – cũng như dữ liệu mới liên tục được thêm vào.
Do đó, cần thiết phải có ETL Data Warehouse testing, để đảm bảo dữ liệu ở ETL Data Warehouse valid, chính xác và hoàn chỉnh. Với quy trình ETL, dữ liệu sẽ đi qua một pipeline trước khi tới ETL Data Warehouse. Toàn độ pipeline sẽ phải được test để đảm bảo mỗi data type của dữ liệu đề được chuyển đổi và sao chép như kỳ vọng.
Điểm khác biệt giữa full và incremental loading
Có 2 phương thức load dữ liệu vào data warehouse chính:
Full load: toàn bộ tập dữ liệu được dumped, loaded và sau đó hoàn toàn bị thay thế hoàn toàn (tức là bị xóa và thay thế) bằng tập dữ liệu mới. Không có thông tin additional nào, ví dụ như timestamp là là được yêu cầu.
Ví dụ: một cửa hàng load tất cả doanh số của mình thông qua quy trình ETL lên data warehouse vào cuối mỗi ngày. Giả sử 5 lần bán hàng đã được thực hiện vào thứ Hai, do đó, vào đêm thứ Hai, một bảng gồm 5 bản ghi sẽ được tải lên. Sau đó, vào thứ Ba, 3 lần bán hàng khác đã được thực hiện và cần được thêm vào. Vì vậy, vào tối thứ Ba, giả sử full load, 5 bản ghi của thứ Hai cũng như 3 bản ghi của thứ Ba sẽ được tải lên – một hệ thống không hiệu quả, mặc dù tương đối dễ thiết lập và duy trì.
Incremental load: chỉ sự khác biệt giữa target và source dataa được load thông qua quy trình ETL trong data warehouse. Có 2 loại Incremental load, tùy thuộc vào khối lượng dữ liệu bạn đang load; streaming incremental load và batch incremental load.
Theo ví dụ trước, cửa hàng đã thực hiện 3 lần bán hàng vào Thứ Ba sẽ chỉ tải thêm 3 bản ghi vào bảng bán hàng, thay vì tải lại tất cả các bản ghi. Điều này có ưu điểm là tiết kiệm thời gian và tài nguyên, nhưng làm tăng độ phức tạp.
Incremental loading chắc chắn là sẽ nhanh hơn rất nhiều so với full load. Hạn chế chính của loại load này là khả năng bảo trì. Không giống như full load, với incremental load, bạn không thể chạy lại toàn bộ load nếu có lỗi. Ngoài ra, các tệp cần phải được load theo thứ tự, do đó, nếu lỗi sẽ gây ra vấn đề khi các dữ liệu khác xếp hàng (queue up).
Ngày nay, các tổ chức đang rời xa việc xử lý và tải dữ liệu theo các batch lớn, ưu tiên xử lý real-time bằng cách sử dụng stream processing, có nghĩa là khi các ứng dụng client ghi dữ liệu vào data source, dữ liệu được xử lý, chuyển đổi và được lưu vào target data store. Điều này giúp loại bỏ nhiều nhược điểm của quá trình xử lý và loading truyền thóng, tăng tốc độ và giảm độ phức tạp.
Redshift ETL: 3 cách để load data vào AWS Redshift
Tự xây Redshift ETL Pipeline
Các best practices:
COPY từ nhiều file có cùng szie – Redshift sử dụng kiến trúc Massively Parallel Processing (MPP) (tương tự Hadoop). Workloads được chia nhỏ và phân phối cho nhiều “slices” trong các compute nodes, chạy các task một cách song song. Đảm bảo rằng mỗi slice nhận được cùng một lượng công việc bằng cách chia nhỏ dữ liệu thành các tệp có kích thước bằng nhau, từ 1MB-1GB.
Bulk load từ S3 – lấy dữ liệu từ các nguồn dữ liệu và phân đoạn (stage) nó trong S3 trước khi load lên Redshift. Sử dụng Amazon manifest files để liệt kê các tệp cần load lên Redshift từ S3, tránh trùng lặp. Sử dụng temporary staging tables để chứa các data cho việc chuyển đổi, và chạy câu lệnh ALTER TABLE APPEND để swap dữ liệu từ staging table sang target table. Câu lệnh này sẽ nhanh hơn CREATE TABLE AS hay INSERT INTO
Nhiều bước trong 1 transaction – các commits tới Redshift đắt. Nếu như bạn có nhiều transformations, đừng commit tới Redshift sau mỗi lần chuyển đổi. Chạy nhiều câu lệnh SQL để transform data, và chỉ khi đã đạt được dạng final thì mới commit lên Redshift. Dưới đây là 1 ví dụ:
Begin
CREATE temporary staging_table;
INSERT INTO staging_table SELECT .. FROM source (transformation logic);
DELETE FROM daily_table WHERE dataset_date =?;
INSERT INTO daily_table SELECT .. FROM staging_table (daily aggregate);
DELETE FROM weekly_table WHERE weekending_date=?;
INSERT INTO weekly_table SELECT .. FROM staging_table(weekly aggregate);
Commit
Thực hiện maintain các bảng một cách thường xuyên: Redshift là columnar database. Để tránh các lỗi liên quan đến performace theo thời gian, hãy chạy thao tác VACUUM để sắp xếp lại bảng và loại bỏ các block đã xóa. Thường xuyên chạy thao tác ANALYZE để cập nhật statistics metadata Redshift Query Optimizer tạo ra các kế hoạch truy vấn chính xác. Analyze & Vacuum Utility giúp bạn lên lịch việc này một cách tự động.
Sử dụng workload management – Redshift được tối ưu hóa chủ yếu cho các read queries. Để tránh các commit – heavy commits như ETL chạy chậm, hãy sử dụng Redshift’s Workload Management engine (WLM). Define một hàng workload queue riêng cho ETL runtime. Configure để chạy với 5 slots trở xuống, và tận dụng các dynamic memory parameters.
Sử dụng UNLOAD để trích xuất các result sets lớn – trong Redshift, fetching một số lượng lớn các rows bằng cách sử dụng SELECT làm overload khiến các cluster leader node dừng chạy, và cả cluster sẽ dừng theo. Thay vào đó, hãy sử dụng lệnh UNLOAD để trích xuất các tập kết quả lớn trực tiếp tới S3, ghi dữ liệu song song vào nhiều tệp mà không làm ngưng trệ leader node.
Sử dụng Amazon Redshift Spectrum cho các xử lý ad hoc – Với các phân tích ad hoc ngoài ETL process thông thường (VD: data từ one-time marketing promotion), thì có thể query trực tiếp từ S3. Amazon Redshift Spectrum có thể run các ad hoc querry với big data trong S3 data lake mà không cần tới ETL.
Quản lý ETL health hằng ngày với các câu query diagnostic – sử dụng monitoring scripts do Amazon cung cấp để theo dõi hiệu suất ETL và giải quyết sớm các sự cố trước khi chúng ảnh hưởng đến khả năng load dữ liệu.
Xem thêm trong tài liệu sau:
Kết hợp Redshift với Glue
AWS Glue offer những tính năng sau:
Integrated Data Catalog— persistent metadata store lưu trữ các table definitions, job definitions , và control information khác để giúp bạn quản lý quy trình ETL. Glue tự động tạo partitions để làm cho các truy vấn hiệu quả hơn.
Automatic schema discovery— Glue crawlers connect với dữ liệu của bạn, chạy một list classifiers để xác định lược schema tốt nhất cho dữ liệu của bạn và metadata thích hợp trong Data Catalog.
Code generation— Glue tự động tạo ra Scala hoặc Python code, được viết cho Apache Spark, để trích xuất, chuyển đổi, làm phẳng, enrich và load data.
Developer endpoints— Glue kết nối với IDE của banj và cho phép bạn edit các ETL script được tạo tự động. Bạn có thể add các custom readers, writers, hoặc transformations làm custom libraries.
Job scheduler— Glue chạy các ETL jobs song song, trên cơ sở pre-scheduled, on – demand hoặc trigger bởi 1 event. Nó cho phép bạn define các dependecies để xây dựng các quy trình ETL phức tạp. Logs được đẩy sang CloudWatch.
Sử dụng các tool bên thứ ba
Bạn có thể tận dụng một số công cụ ETL đám mây được tích hợp sẵn với Amazon Redshift. Ưu điểm chính của các dịch vụ này là chúng được tích hợp sẵn với hàng chục nguồn dữ liệu bên ngoài, trong khi Glue chỉ được tích hợp với cơ sở hạ tầng của Amazon.
Nếu tất cả dữ liệu của bạn đều có trên Amazon, Keo dán có lẽ sẽ là lựa chọn tốt nhất. Hãy chạy một stimulation để so sánh chi phí, vì chúng sẽ thay đổi tùy use case.
ETL Testing process
Business requirements—xác định scope của project, expected outcome, data model và các business rules liên quan.
Data sources— kiểm tra data source locations và formats, thực hiện đếm dữ liệu và verrify rằng các cột và kiểu dữ liệu đáp ứng yêu cầu, xem xét các khóa và xóa dữ liệu trùng lặp.
Test cases—xác định các ETL mapping scenarios chính và tạo các câu lệnh SQL mô phỏng chúng.
Trích xuất dữ liệu và run tests— chạy tests trên dữ liệu được trích xuất và sửa lỗi, trước khi transform.
Transform data— đảm bảo target data types và values match map với các mappings yêu cầu và business rules.
Load into data warehouse— xác nhận rằng tất cả dữ liệu đã được load và dữ liệu không hợp lệ đó đã bị reject và được load vào đến vị trí thích hợp (rejects table, etc).
ETL testing report—tạo cáo thông báo kết quả test ETL, nơi các vấn đề xảy ra và những gì đã được thực hiện.