Bài viết chuyên sâu

[DE] Về DataWarehouse ...

[DE] Về DataWarehouse ...

by Admin Dathoc -
Number of replies: 0

Về DataWarehouse Implementing - 3 parts- Vài trải nghiệm
Đấy, dạo gần đây tôi và các bạn đều thấy các anh chị em mới học DA, DE, DS thường hay nhầm lẫn, đi sai hướng, hoặc chưa có trải nghiệm nhiều về CÁCH LÀM TINH GỌN dữ liệu trong đó là datawarehouse -DW, cho một mục tiêu tìm ý nghĩa của dữ liệu trên nghiệp vụ.
👉Ý là - hình như chúng ta đôi chỗ HIỂU CHƯA ĐÚNG hoặc chưa rõ về một số CÁCH LÀM, KHÁI NIỆM khi gia công dữ liệu và phân tích tìm ý nghĩa trên dữ liệu, trên quá trình: LÀM TINH GỌN dữ liệu trong đó là DW.
.
.
.
.
Vậy mình xin share một quan điểm cảm nhận cá nhân tiếp xúc từ 1998 với DW và tới 2017 tiếp cận tới khối dữ liệu lớn của Honda, xin chia sẻ vài trải nghiệm tới anh chị em.
👉Và là trải nghiệm cá nhân, nên có thể ĐÚNG với anh chị em này và SAI với anh chị em khác. Điều đó dễ hiểu thôi. Cũng mong muốn chia sẻ là MỞ và anh chị em hoàn toàn có thể bổ sung để bài chia sẻ được tốt hơn.
.
.
👉Đầu tiên chúng ta cần thống nhất quy trình xử lý phân tích dữ liệu từ khi bạn tìm kiếm, có dữ liệu, cho tới khi ra được ý nghĩa của chúng, cụ thể những công đoạn:
1. Móc nối vào các nơi cung dữ liệu. Thu thập, tạo các ống lưu chuyển dữ liệu trỏ về Hồ chứa (datalake), Tạo hồ chứa (datalake - DL) - thông thường bạn KHÔNG NÊN dùng SQL, mà bạn dùng công cụ chuyên biệt hoặc export toàn bộ dữ liệu bạn cần ra
2. Biến đổi trực tuyến (online), biến đổi tại chỗ (offline) trong quá trình thu thập (transform lần 1) rồi lưu vào hồ chứa (DL) - thông thường anh chị e mới học thì làm single process (python, r...) sau này làm multiprocess (spark, presto, impala...)
3. Tạo datawarehouse - DW/mart. Tinh gọn, biến đổi tiếp dữ liệu, để phục vụ mục tiêu nghiệp vụ tìm ý nghĩa (transform lần 2) và: Lưu vào dữ liệu khối nghiệp vụ (DW - datamart, DM) - thông thường dữ liệu nhỏ ace dùng MS SQL hay bất cứ rdbms nào; dữ liệu lớn a chị em tìm tới dữ liệu cột: parquet, cassandra, scylla, couchbase .. để làm
4. Áp dụng data từ (3) vào phục vụ cho các thuật toán, giải thuật, mô hình máy học. Chạy test thu lại kết quả. Truy vấn data để Visualize, xem hiểu visual. Tinh gọn tiếp, biến đổi tiếp (transform lần 3) nếu cần - thông thường ace vớ ngay những tool FREE: excel, power bi, tableau... sau đó SẾP sẽ bắt anh chị e tự tạo app riêng HTML JS; về mô hình máy học thì thường là các thư viện chung, dựng sẵn có sẵn; khi cần đặc thù sẽ tuy biến tạo riêng mô hình
5. Đánh giá ý nghĩa và kết quả. Nếu OK với các giả định thì tạo quy trình tự động từ 1 tới 5. Nếu NOT OK, thì làm lại với dữ liệu khác từ 1
6. Một số bạn có thể hỏi là: vậy Thuật toán, Mô hình máy học... anh lấy ở đâu. Xin thưa, đó là cả một Phòng ban nghiệp vụ khác, cái mà chúng ta hay gọi là Data Scientist, họ sẽ lo cái này. Nếu tổ chức bạn không có cái này: bạn hoàn toàn dựa trên những thư viện chuẩn là làm phân tích ý nghĩa trên dữ liệu được. Còn tuỳ những mô hình máy học, hoặc thuật toán phân tích đặc thù.. mới cần Phòng ban riêng.
Tôi không rõ bạn làm PHÂN TÍCH DỮ LIỆU nhỏ hay bé, chữ số hay âm thanh hình ảnh. Xong nhìn chung 99% các tổ chức công ty làm về PHÂN TÍCH DỮ LIỆU text số liệu, text câu chữ, hình ảnh, âm thanh..họ đều làm theo quy trình 5 bước trên.
Và cá nhân tôi phải nói thêm rằng: Nếu team, tổ chức của bạn không làm ĐÚNG theo 5-6 bước trên, vậy team bạn đang làm mất thời gian hoặc làm KHÔNG HIỆU quả công việc phân tích dữ liệu.
.
.
👉Vậy theo cá nhân hiểu - hàm lượng SQL chỉ nằm trong bước 4. Xong một số bạn mới vào, một số tổ chức không có Datawarehouse/mart và thọ trường làm TRÁI KHOÁY thế này:
1. Móc nối vào các nơi cung dữ liệu. Thu thập ...bằng SQL
2. Biến đổi trực tuyến (online), biến đổi tại chỗ (offline) ...bằng SQL
3. KHÔNG tạo datawarehouse/mart...
4. Truy vấn data ...ra luôn công cụ Visualized FREE để view xem
5. Đánh giá ý nghĩa. Rồi làm lại từ 1
... và họ kêu trời kêu đất lên CHẬM, PHI LÍ...rồi hỏi lung tung lên: join thế nào, groupy thế nào.. select(select()) thế nào...để chúng em visualize được tốt???
.
.
Sau khi đồng ý với quy trình trên, ta sẽ thấy có nhắc nhiều tới công việc LÀM TINH GỌN, và biến đổi nhiều lần. Anh chị em thường dùng các từ ngữ như ETL, ELT, Wrangling, Transform, Cleanse.... Và quy trình trên có nhắc tới khái niệm datawarehouse.
👉Vậy chúng ta thống nhất tiếp:
- Datawarehouse, theo định nghĩa sách 1998_Datawarehouse Tookkits của Laura Reeves... is the queryable presentation resource for an enterprise’s data and this presentation resource must not be organized around an entity-relation model because, if you use entity-relation modeling, you will lose understandability and performance. Also, the data warehouse is frequently updated on a controlled load basis as data is corrected, snapshots are accumulated, and statuses and labels are changed...
- Wiki nêu:... is a system used for reporting and data analysis and is considered a core component of business intelligence.[1] DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data in one single place[2] that are used for creating analytical reports for workers throughout the enterprise...
- Gurus nêu: ...is process for collecting and managing data from varied sources to provide meaningful business insights. A Data warehouse is typically used to connect and analyze business data from heterogeneous sources. The data warehouse is the core of the BI system which is built for data analysis and reporting.
.
.
👉Vậy nếu xem các KHÁI NIỆM trên, bạn và tôi đều ĐỒNG Ý với nhau vài ý kiến sau là:
- DW nơi nó phục vụ chủ yếu thể loại data dạng chữ số, và phù hợp với bài toán Phân tích Thống kê số; dự báo dữ liệu chữ số; nơi chứa Dữ liệu lịch sử, và được Tổng hợp chuyên biệt; được Chi tiết chuyên biệt
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: DW nó khác với Database cả về kiến trúc lẫn thể hiện dữ liệu trên đó. Database là bạn thể hiện dữ liệu phục vụ cho ỨNG DỤNG PHẦN MỀM cụ thể. còn Datawarehouse là bạn thể hiện dữ liệu để phục vụ TINH GỌN DATA, data có thể nhiều , rất nhiều; data có thể được thiết kế CHI TIẾT hơn; data có thể được TỔNG HỢP SẴN nhiều hơn.... để PHÂN TÍCH 1 nghiệm vụ nhất định.
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: data DW cần có những chi tiết cụ thể nhất, rõ ràng nhất, để tránh việc khi truy vấn xong, người làm BI, DA sẽ phải sử dụng thêm tính toán trên SQL mới ra được thông tin chi tiết
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: data DW cần có những TỔNG HỢP SỐ LIỆU để phục vụ một nhu cầu phần tích; tránh đưa việc đó vào lệnh truy vấn SQL của người làm BI, DA
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: data DW cần có những thể hiện LỊCH SỬ SỐ LIỆU để phục vụ phân tích lịch sử
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: thường thì nguời ta không sửa xoá data trên DW
- DW nó khác với data thô, có hoặc chưa có trên Database đó là: thường thì làm tăng tốc truy vấn lẫn lưu data tới lượng lớn nhất định; bạn sẽ phải đưa bài toán TỪ thiết kế DW cố định 1 lõi storage SANG distributed storage; cũng như distributed query để tăng tốc truy vấn
.
.
-----------------------------------------------------------

👉0. Những điều gì phản ánh một DW tốt?
- Nó cần phải có những pipeline tốt, dẫn data TỰ ĐỘNG từ mọi nơi về nó. Vậy đơn giản xem DW đã có cái này chưa?
- Nó cần áp dụng opensource, hoặc legal application, quản trị chuyên biệt, hơn là cloud; vì đa phần những công ty Quốc dân là dùng on-premise hơn các giải pháp cloud. Và thông thường cloud sẽ làm bạn lười đi
- Nó cần có mục tiêu: có thể áp dụng phân tích REALTIME với cấu trúc logic tính toán distributed realtime end-2-end: các state-of-the-art đã nêu rất nhiều: trước khi nó được lưu xuống ổ cứng; hay nói cách khách dữ liệu sẽ được view trên Visualize trước khi đc offline view và tính toán lần nữa, cụ thể:
+ filebeat-kafka-elk
+ cubejs-kafka-heron-kibana/prometheus
+ snowplowjs-kafka-spark-vega/mapd
+ divolte-kafka-heron-kibana/prometheus
+ flink-kafka-heron-kibana/prometheus
.
.
- Nó cần có mục tiêu: có thể áp dụng phân tích OFFLINE đủ mạnh, lớn, rộng, phân tán; độ rủi ro khi một server bị mất liên lạc; dễ dàng khôi phục; có rất nhiều pattern distributed storatge, distributed query
+mssql/oracle-sql-powerbi/tableau
+hdfs-mapreduce-vega/mapd
+hive-presto/trino-spark-vega/mapd
+couchbase-vega/mapd
+scylla-vega/mapd
+hdfs-impala-vega
.
.
- Nó cần phải được truy vấn ĐƠN GIẢN HẾT MỨC có thể. Có nghĩa là dữ liệu ra với câu lệnh Select... Where ... là xong; hoặc riêgn Select... thôi. Chứ nếu bạn lại thêm loop select, hoặc có groupby hoặc join... điều đó có nghĩa là DW của bạn chưa tốt. Hoặc team BI dùng python, spark, presto, impala, csql... read, connect... sql vào cũng chần đơn giản hết mức có thể.
- Nó cần phải được truy vấn NHANH HẾT MỨC có thể. Có nghĩa là dữ liệu ra sau khi truy vấn cần tính bằng ms (mili giây) cho gb data, hoặc s (giây) cho trăm GB, TB data trên ổ cứng, và DW nào đó mà bạn đợi 2 phút, 5phút... 20 phút cho kết quả: vậy có nghĩa là data trên DW thiết kế chưa hiệu quả; kiến trúc DW chưa hiệu quả
- Nó cần sử dụng mô hình thiết kế dữ liệu dạng STAR cho tối ưu performance với rdbms; hay dạng columnar kèm in-mem processing cho distributed query tối ưu
- Nó cần CHỨA những dữ liệu ĐÚNG CHUẨN cho phép toán thống kê đó, thuật toán đó, mô hình máy học đó.. mà team BI DA đang cần. Mình nhắc lại nhé: nó cần đúng chuẩn, ví dụ:
+ BI team cần data: Tính các doanh số của thứ 7 hàng tuần trong 3 tháng gần đây? - vậy trong DW của bạn chắc chán phải có một bảng, và một field là dành cho tên THỨ trong 1 tuần; và field Tổng hợp doanh số trong ngày THỨ đó trong tuần.
+ BI team cần sử dụng timeseries với window +3?: - Vậy có nghĩa là DW của bạn bắt buộc phải có field và bảng, trong đó nhóm các dữ liệu có ngày và thời gian theo WINDOWS (biến đầu vào xử lý 1 khoảng thời gian cho timeseries), và CÓ SẴN DỮ LIỆU TỔNG HỢP tổng hợp khi thay đổi window+1 +2 +3
.
.
+ BI team cần tính toán và tìm hiểu mật độ THAY ĐỔI HỘ KHẨU từng thành viên hộ gia đình ? - Vậy bắt buộc trong DW cần phải có trường, cột, bảng nêu rõ Ngày X1, bạn Y thuộc ID gia đình Z, di chuyển chỗ ở tới ĐIA CHỈ 1; Ngày X2, bạn Y thuộc ID gia đình Z, di chuyển chỗ ở tới ĐIA CHỈ 2, địa chỉ CHÍNH THỨC;
+ BI team cần tính toán và tìm hiểu các trường A, B, C, D ... cho thuật toán logistic regression? ? - Vậy bắt buộc trong DW cần phải có trường, cột, bảng có các trường A,B,C,D... và thay vào dữ liệu đang có, là các dữ liệu 0,1; hoặc dữ liệu thứ tự 1,2,3...
+ BI team cần tính toán và tìm hiểu dữ liệu kmeans (dữ liệu không giám sát), vì dữ liệu hỗn độn quá.. họ muốn tổng hợp theo field giờ mua hàng kèm lượt thích loại hàng nào đó; vị trí cửa hàng kèm số lượng order ... để tìm ra khoảng time phục vụ khách loại hàng gì tốt nhất?; - Vậy bắt buộc trong DW cần phải có trường, cột, bảng chỉ TỔNG HỢP riêng cho đơn hàng thoe giờ; theo cửa hàng; theo chấm điểm yêu thích; theo số lượng tại thời gian, cửa hàng đó;
+ BI team cần tính toán và tìm hiểu dữ liệu random forest (dữ liệu không có giám sát) để tính xác suất ai đó sẽ mua hàng gì khi vào shop?: tương tự như kmeans, xong lần này họ sẽ yêu cầu rõ nếu trong dữ liệu có: già trẻ? lứa tuổi? mua bao nhiêu lần trong tuần? quay lại số lần trong tháng? - Vậy DW data phải chuẩn bị từng đấy field và tổng hợp cộng các dữ liệu đó theo fact.
+ BI team cần áp dụng máy học deepface-recorgition (đang có sẵn) và cần training thêm để nhận diện khuôn mặt từ khác xem tỷ lệ ai với ai trong db có, xem số lần khách A quay lại hoặc đứng vị trí đó? - Vậy DW sẽ là nhóm trích xuất ảnh từ video cam; rồi làm sạch, cắt khuôn mặt ảnh từ shop trích xuất ra; lưu xuống bảng; để BI truy vấn lấy link ảnh; rồi lấy file ảnh; để training; sau đó BI sẽ tự test và kiểm tra dữ liệu đúng và đủ.
+ BI team cần áp dụng máy học phân tích câu chữ chat với supporter, hay comment lên mặt hàng của shop để tổng hợp ai nói cái gì? chê hay khen? - Vậy DW sẽ là nhóm trích xuất câu chữ chat; câu chữ comment; rồi qua api lọc text word segment (thường do nhóm DS chuẩn bi): rồi lưu sang bảng cột; id khách hàng; nói cái gì; nói khen; nói chê.
- Nó có thể scalable dày lên, rộng ra cả bề dọc lẫn bề ngang; sẽ tất yếu các DW là như thế: vì đơn giản nó PHỤC VỤ PHÂN TÍCH, chứ không phải phục vụ cho HỆ THỐNG PHẦN MỀM.. hiện tại các nền tảng thuộc container làm hộ bạn điều này - SCALABILITY- rất tốt. Vậy build container các công nghệ trên thôi.
👉 Ảnh dưới là vài ví dụ dùng docker với những tools ETL
.
.
👉1. Vậy những dữ liệu số câu chữ, cần tổng hợp thế nào, và thiết kế thế nào trên DW?
- VD, trên database của bạn là:
Bảng User: id; ng van x; nam;
Bảng địa chỉ: id; id_user; số nhà 10 hàng bún;
Bảng sở thích: id, id_user; thích đọc sách
Bảng hàng hóa: id, lạc/rau/thịt
Bảng mua hàng: id, id_user; id_item; time_order_item (10:00 14-1-2022)
- Vậy trên DW nên là (ch phù hợp mọi loại phân tích sau này) thống kê giới tính, nhà cửa; họ hàng; tên họ; mật độ mua bán
+ dimension address table: id; homenum; lane; street; district; city; active_date ------------> n001, 10, 0, hàng bún, ba dinh, hanoi, 14-1-2022
+ dimension hobby table: id; hobbyname_full; hobby_action; hoppy_type ------------> h001, thích đọc sách, đọc, sách
+ dimension user table: id; name; first_name; mid_name, last_name; gender------------> u001, x, van, nguyen, 1
+ dimension item table: id; item_name; vol------------> i001, thịt/rau, 21
+ fact user table: id_user; id_hobby; id_add; aggregated_same_lastname; aggregated_same_hobby_action; aggregated_same_hobby_type; aggregated_same_street; aggregated_same_lane; aggregated_same_city; ; aggregated_same_gender;
------------> u001,h001,n001,17,2,3,13,45,300,500,30001,
+ fact trans table: id_user; id_item; id_shop; aggregated_same_shop; aggregated_same_order_item_yearly; aggregated_count_return_item_yearly;
------------> u001,h001,s001,12,2
👉2. Vậy dữ liệu thời gian cần chi tiết thế nào trên DW?
- VD, trên database của bạn là: id; ng van x; sinh năm 11-2-1973
- Vậy trên DW nên là (ch phù hợp mọi loại phân tích sau này):
+ dimension table: id; birddate; birdmonth; birdyear; birthdayname------------> u001, 11, 2, 1973, 3
+ fact table: id_user; aggregated_same_birdmonth; aggregated_same_birddate ; aggregated_same_birthdayname ------------> u001, 7000,3000,2300,5000
👉3. Những thuật toán thuộc TIME SERIES, thì data trên DW được chuẩn bị thế nào?
- VD, BI cần tính khung 2-3-4 tháng 1 lần hiệu quả mua 1 mặt hàng x
+ dimension table: các bảng, tên hàng X, thời gian đặt hàng Y, user A
+ fact table: id_X, id_Y, aggregate_2month_count,, aggregate_3month_count,, aggregate_4month_count, ...., id_user
.
.
👉4. Những thuật toán thuộc REGRESSION, thì data trên DW được chuẩn bị thế nào?
- VD logistic regression, BI team cần tính toán và tìm hiểu các trường A, B, C, D ... cho thuật toán logistic regression? ?
+ dimension table: các bảng, các trường A,B,C,D... thay dữ liệu thực tế là 0,1 hoặc thứ hạng, 1,2,3
+ fact table: id_A, id_B...., id_user
👉5. Những thuật toán thuộc MÁY HỌC KHÔNG GIÁM SÁT, thì data trên DW được chuẩn bị thế nào?
- VD kmeans, BI team cần n khối dữ liệu và ko cần đủ data, từ thời gian X tới Y, từ địa điểm A tới B?
+ dimension table: các bảng, trường dữ liệu có thời gian từ X, thời gian tư Y, đia điểm A, đia điểm B, và User.. và có thể null dữ liệu khác, xong cần đủ dữ liệu thời gian và địa điểm
+ fact table: id_timeX, id_timeY, id_location A, id_locationB, id_user
👉6. Những thuật toán thuộc MÁY HỌC GIÁM SÁT, thì data trên DW được chuẩn bị thế nào?
- VD randomforest, BI team cần n trường dữ liệu A,B,C,D,E và phải có meaning data, tránh null lên đó; từ thời gian X tới Y?
+ dimension table: các bảng, trường dữ liệu A,B,C,D,E, và User và full đủ đồng dữ liệu
+ fact table: id_A, id_B...., id_user
.
.
-----------------------------------------------------------

👉 Bổ sung kiến thức sách năm 2013 về thiết kế DW cho các ngành nghề cụ thể. Các business nào cần các ngành nghề này nên tham khảo họ xử lý DW thế nào, để mình yêu cầu team làm tương tụ. Mình nghĩ chỉ cần làm tương tự thôi đã giảm nhiều workload về lọ mọ bới móc data của team BI rồi.
Cụ thể năm 2013 về thiết kế DW có sách DataWarehouse ToolKits (đã share bên dưới), họ nêu những pattern thiết kế DW cho mọi loại báo cáo, dự báo có thể cần tới dữ liệu chuyên biệt cho các NGHỀ sau:
- Chương 3, về Bán Lẻ
- Chương 4, về Kho
- Chương 5, về Thu mua
- Chương 6, về Quản trị đơn hàng
- Chương 7, về Kế toán
- Chương 8, về Quan hệ khách hàng
- Chương 9, về Nhân sự
- Chương 10, về Các dịch vụ tài chính
- Chương 11, về Hỗ trợ từ xa
- Chương 12, về Giao thông
- Chương 13, về Giáo dục
- Chương 14, về Y tế
- Chương 15, về Thương mại điện tử
- Chương 16, về Bảo hiểm
Đặc biệt mỗi CASE có show mistakes hay gặp, và checklist rõ ràng để bạn audit lại team mình có làm đúng chưa?
Dưới đây là vài Nghề cơ bản mình xin trích chéo ở dưới.
.
.
👉 Sang 2014, Springer có cho ra sách về DW khá chi tiết hơn về bề dọc hơn là bền ngang theo nghề so với sách 2013. Bạn có thể tham khảo. Tại đây bạn sẽ đc thấy nhiều KIỂU THIẾT KẾ và mô hình thiết kế tập trung hoặc phân tán, dựng data nhiều chiều không gian, với DW hợp với anh chị em muốn mở rộng và customize tối ưu DW cho dữ liệu ngành nghề tổ chức mình.
.
.
👉 7. Những thiết kế chuẩn cho BÁN LẺ - retailers, thì data trên DW được chuẩn bị thế nào?
- Sách về DW năm 1998 (link share sách bên dưới) chapter 14 đã tổng kết mẫu thiết kế DW để tính toán aggregation
- Sách về DW năm 2012 cho mô hình Agile (link share sách bên dưới) Chương 6, cũng đưa mấy thiết kế DW cho các mô hình về DỊch vụ
- Sách 2013 về DW cho mô hình RIÊNG bài toán Bán lẻ
- Cụ thể lưu ý sau qua 1 vd:
+ VD Bạn sẽ thấy riêng fact về sale cho đơn hàng transaction, họ đã rất chi tết về ngày tháng, lượng sale và các bảng dimension kèm theo (xem ảnh)
👉 8. Những thiết kế chuẩn cho CRM - quản lý khách hàng, thì data trên DW được chuẩn bị thế nào?
- Sách 2013 về DW cho mô hình RIÊNG bài toán Quan hệ khác hàng
- Cụ thể lưu ý sau 1vd:
+ VD Bạn sẽ thấy quy định rõ lượng LẦN ĐẦU mua hàng, và quản lý data LẦN ĐẦU mua thế nào (xem ảnh)
👉 9. Những thiết kế chuẩn cho ACCOUNTING - kế toán, thì data trên DW được chuẩn bị thế nào?
- Sách 2013 về DW cho mô hình RIÊNG bài toán Kế Toán
- Cụ thể lưu ý sau 1vd:
+ VD Bạn sẽ thấy quy định rõ lượng tiền từ đầu năm từ kế hoạch, tới việc ký thanh toán, tới các chi trả và các bảng dimension kèm theo (xem ảnh)
👉 10. Những thiết kế chuẩn cho HUMAN RESOURCE - quản trị nhân sự, thì data trên DW được chuẩn bị thế nào?
- Sách 2013 về DW cho mô hình RIÊNG bài toán Nhân sự
- Cụ thể lưu ý sau 1vd:
+ VD Bạn sẽ thấy với text bạn input địa chỉ, họ sẽ không yêu cầu Khách phải điền nhiều box vào; xong họ có những parser để bóc tách từng câu chữ trong địa chỉ của Nhân sự và các bảng dimension kèm theo (xem ảnh)
.
.
👉 11. Bạn làm dữ liệu số, câu chữ text, vậy tôi hiểu DW của bạn rồi, vậy khi tôi làm phân tích nhận diện hình ảnh, âm thanh thì DW là gì?
- Dữ liệu thô: sẽ là những stream video từ cam; sẽ là chat post từ forum, trang mạng xã hội, livestream
- Dữ liệu mà coi là DW của vision và text nlp, audio nlp trong Máy học phải trải qua những công đoạn:
+ Xử lý về khuôn mặt, cần nhận biết detect face shape trước -> rồi classify nhóm những khuôn mặt tương tự có tỷ lệ cao -> chỉnh chất lượng, chuyển tông -> là DW của công việc chb data cho test mô hình -> tiếp training -> tạo mô hình (là DW của công việc dựng mô hình)
+ Xử lý về dáng hình, bề ngoài, màu sắc, text, số trên ảnh (tương tự)
+ Xử lý về segment phạm vi xâm phạm vùng qua vẽ 1 live vector: tạo vector và định danh khối hình va chạm đường line vector (tương tự)
+ Xử lý âm thanh -> thu âm, tạo file -> extract file sang số -> nhóm và phân loại để tạo DW thô (tương tự)
👉 12. Công việc tiếp theo cần làm gì sau khi có DW đúng chuẩn?
Sau khi có DW và data đúng chuẩn, thông thường BI hoặc DA hoặc DS team sẽ tiếp tục:
- Check lại data đúng format theo yêu cầu team chưa
- Transform theo những nhu cầu RIÊNG của team BI, DA, DS đó (hoặc nếu kỹ hơn sẽ phải chb cái này trước khi đưa vào DW)
- Transform theo biến đổi đầu vào phù hợp với thuật toán đặc thù
- Làm giàu data theo yêu cầu
- Chạy test, visualize trên chart, check mô hình với data (text chữ, text số, ảnh, âm thanh...) đang có. Tìm biến dị lạ.
- Dùng chính những data trên DW để làm data cho việc tạo mô hình dự đoán
- Báo cáo lại team DE về công việc chb data như vậy đã phù hợp với team BI, DA, DS chưa
.
.
👉 13. Những điều gì nâng tầm tốc độ truy vấn của một DW, từ gb/giây lên chục, trăm bd/giây, tb/giây?
Để nâng tầm tốc độ truy vấn DW
- Sách 1998 về DW yêu cầu bạn cần chi tiết hết mức có thể trong các Dimension table. Tức là KHÔNG ĐƯỢC PHÉP TÌM KIẾM trong chuỗi (in-string) của trường dữ liệu. Do đó, mỗi chữ số, câu từ sẽ được định rõ trường data riêng, nên sẽ RÀNH RỌT việc search trên field đó. Tức là nếu bạn càng chi tiết, có thể data sẽ dày lên, và do đó DW sẽ đồ sộ lên. Xong vì chi tiết nên bạn cần query cái gì nó cũng đã được phân loại rõ
+ VD dữ liệu kiểu ngày, cần có các field riêng, gồm: field tên ngày thứ trong tuần, field ngày, field tháng, field năm
+ VD dữ liệu kiểu địa chỉ số nhà: cần có riêng: field số nhà, field tên ngõ, field tên phố..
+ VD dữ liệu kiểu tổng sale: fact table: field id hàng, field tổng sale tuần, field tổng sale tháng, field tổng hoàn đơn không mua, field theo nhà CC..... còn dimension table cần: tên hàng, loại, lượng bán, ngày bán (chi tiết thứ ngày tháng năm)....
- Sách 2013 về DW đã cho ví dụ từng KHÓM, trường nội dung mà bạn định báo cáo, cụ thể:
+ Nhóm về nghề Bán lẻ, như bạn nhìn ảnh ---> VD Bạn sẽ thấy riêng fact về sale cho đơn hàng transaction, họ đã rất chi tết về ngày tháng, lượng sale và các bảng dimension kèm theo
+ Nhóm về nghề Nhân sự, như bạn nhìn ảnh --->VD Bạn sẽ thấy với text bạn input địa chỉ, họ sẽ không yêu cầu Khách phải điền nhiều box vào; xong họ có những parser để bóc tách từng câu chữ trong địa chỉ của Nhân sự và các bảng dimension kèm theo
+ Nhóm về nghề Kế toán, nhu bạn thấy trong ảnh ---> VD Bạn sẽ thấy quy định rõ lượng tiền từ đầu năm từ kế hoạch, tới việc ký thanh toán, tới các chi trả và các bảng dimension kèm theo
- Sách 2014 về DW có những tính toán toán học rất hay về..
+ Tối ưu khi bạn dùng Spartial data measure cho tối ưu thiết kế và truy vấn (chương 11)
+ Tối ưu lưu data dạng CUBE, theo đo lường bạn muốn (xem ảnh)
- Cách tôi tạo docker-flink, docker-spark, docker-kafka .. để đơn giản trên 1 host, tôi tính toán distributed được
- Cách tôi tạo docker-presto/trino .. để đơn giản trên 1 host, tôi query distributed được
.
.
👉 14. Những điều gì bạn sẽ bị CHẬM ĐI hoặc làm SAI đi, hoặc GÂY MẤT TIME của bạn khi không có DW?
Vậy có thể kết luận
- Nếu bạn KHÔNG CÓ, hoặc quan tâm không thấu đáo thới thiết kế DW, điều đó có nghĩa là BI và DA phải tiếp tục biến đổi nhiều về data họ lấy được từ nguồn. Những người năng lực kém họ chỉ biết SQL, python pandas thì.. họ xử lý data 1 luồng. Ai khá hơn sử dụng presto, impala, spark, pyspark... xử lý đc đa luồng nhanh hơn. Cũng có nghĩa có những khả năng kiến thức vượt ngoài tầm của họ.
- Nếu bạn KHÔNG CÓ, hoặc quan tâm không thấu đáo thới thiết kế DW, có nghĩa tổ chức của bạn luôn phải sẵn sàng update 2 database vì đơn giản, tổ chức sẽ ko bao giờ cho BI hay DA DS đào bới trực tiếp với DB cập nhật dữ liệu (db chỉ có thể là production). Nói cách khách tổ chức phải làm một mapping với DB thứ 2, và họ phải tốt thêm tài nguyên để quản trị DB này. Thế thì thay vao đó tại sao họ không tạo luôn 1 team để build DW rõ ràng.
- Nếu bạn KHÔNG CÓ, hoặc quan tâm không thấu đáo thới thiết kế DW, có nghĩa bạn chưa tạo được nền tảng tìm ý nghĩa trên data tối ưu. Bạn vẫn phải hùng hục tay chân. Bạn vẫn phải chờ đợi những thời gian biến đổi dữ liệu; chuẩn bị dữ liệu ngăn cản cho việc UPDATE Ý NGHĨA trên dữ liệu. Dẫn tới có thể Ý NGHĨA bị sai, bị chậm, bị biến tướng, méo mó... không phản ánh đúng dữ liệu thực tế
.
.
- Nếu bạn không chuẩn bị một DW có phục vụ TỐC ĐỘ CAO, thì chắc chỉ 2-3 năm bạn phải build lại một lại thiết kế DW khác. Vì đơn giản ngày qua ngày data trên DW sẽ dày và nhiều lên. Các câu query trước dữ liệu ít nó có vẻ nhanh, xong giờ nó không phù hợp, lại trở thành chậm
- Nếu bạn không chuẩn bị một DW có kèm ONLINE REALTIME analytics, thì bạn vẫn sẽ phải chờ đợi một team nhóm nào đó họ online để phục vụ bạn những báo cáo mà chỉ offline mới làm được
- Nếu bạn không chuẩn bị một DW có thiết kế distributed, vậy bạn sẽ không scale nó lên được.
.
.
Mời bạn bổ sung để bài viết tốt hơn!
Gluk!
Bạn có thể Google đối chiếu, hoặc mở dathoc.net/bookda để xem các sách này.