Reply
 
Thread Tools
  #41  
Old 18-12-2019, 19:53
Chief Bean's Avatar
Chief Bean Chief Bean is offline
Senior Member
Join Date: 12-2009
Posts: 133
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by ez-aqua View Post
Như vậy, mình hiểu là như thế này, Google Big Query/Hive là nơi lưu những dữ liệu mà mình tổng hợp sẵn, join sẵn mọi thứ, thành một bảng phẳng rồi lưu trên đó. Khi có update xảy ra, mình sẽ phải tổng hợp lại version mới, vào xóa toàn bộ cái partition chứa dữ liệu cũ rồi append cái mới vào.

Ví dụ

Mình có 3 partition tháng 10, 11, 12

Tháng 10 và 11 đã chốt sổ nên sẽ không update nữa, nhưng tháng 12 là tháng đang diễn ra, vì vậy hàng ngày sẽ có những update mới cho những đơn hàng đang xử lý.
Thì hàng ngày mình sẽ phải chạy lại lệnh ETL của toàn bộ dữ liệu tháng 12 tính đến ngày hôm nay, để ra version mới cho cả những đơn hàng lập từ hôm trước có update mới, và những dòng mới chưa được extract từ trước, rồi vào GG BigQuery/Hive xóa toàn bộ partition chứa dữ liệu của tháng 12, rồi nhét lại dữ liệu của tháng 12 extract được hôm nay vào partition của tháng 12.

Lúc mình ETL thì mình join mọi thứ cần thiết vào, cào phẳng bảng fact để sau khi vào data warehouse rồi thì không phải join nữa.

Mình hiểu như vậy đúng không nhỉ?

Có một điều lạ là mình xem doc trên Google (mình chỉ lướt) thấy vẫn có SCD2, vẫn có DIM, Fact, vẫn có lệnh Merge. Hive cũng có loại bảng hỗ trợ update, hoặc có những work around với việc update SCD 2, chứ ko đến mức là cào phẳng bảng.

Mình làm đồ của Microsoft nhưng khá hứng thú với cái ý tưởng của Hive, dù chỉ mới sờ thử chơi cái Hive qua Hive Table trong Spark của Databricks.

Với cho mình hỏi là tổng hợp sơ data trước khi nhét data vào BigQuery/Hive ở đâu nhỉ, theo như hệ thống của mình thì mình đang cần làm Accumulating Snapshot cho các đơn hàng (VD Đơn hàng 1, Khách hàng, Người bán, Ngày nhận đơn, ai nhận đơn, ngày ship, ship bởi ai, ngày giao, ngày khiếu nại, ngày kết thúc....), với hệ thống bảng quan hệ chằng chịt, thì cái lệnh tổng hợp, join được thực hiện ở Source Data hay ở đâu nhỉ. Hiện giờ mình quyết định làm luôn trên source data cho lẹ (đang bị hối quá rồi), dùng sức mạnh của source để join, detect change chỉ cần có thay đổi ở 1 khâu là extract lại cả cái snapshot cho đơn hàng đó, có đủ dữ liệu rồi thì mang nó qua Spark/Data Warehouse transform, đã test và tạm thời không có vấn đề gì về performance, nhưng chẳng biết sau này sẽ trở thành quái quỷ gì luôn.


1355308
Trước hết về merge operator này có nhiều cách để implement nhưng về cơ bản là old_data + new_data using windown function by row_number or using merge join. Về cơ bản là một expensive computation.
BTW some folks in Uber có 1 project khá hay tên là Hudi để giải quyết vấn đề upsert (update + insert). Ref https://hudi.incubator.apache.org/


>>> Ví dụ

Mình có 3 partition tháng 10, 11, 12

Tháng 10 và 11 đã chốt sổ nên sẽ không update nữa, nhưng tháng 12 là tháng đang diễn ra, vì vậy hàng ngày sẽ có những update mới cho những đơn hàng đang xử lý.
Thì hàng ngày mình sẽ phải chạy lại lệnh ETL của toàn bộ dữ liệu tháng 12 tính đến ngày hôm nay, để ra version mới cho cả những đơn hàng lập từ hôm trước có update mới, và những dòng mới chưa được extract từ trước, rồi vào GG BigQuery/Hive xóa toàn bộ partition chứa dữ liệu của tháng 12, rồi nhét lại dữ liệu của tháng 12 extract được hôm nay vào partition của tháng 12.

-> Solution có thể là partition daily và nếu hôm nay thay đổi thì cứ insert overwrite table xxxx partition(day=20191202) select * from xxx where day=20191201 union all select * new_data.
Hệ này cứ overwrite lại nếu muốn update. Write là cheap operation. Còn muốn keep cái snapshot partition nào thì keep cái đó ví dụ như nếu muốn lưu lại tháng 11 thì keep partition 20191130 thôi.


>>> Với cho mình hỏi là tổng hợp sơ data trước khi nhét data vào BigQuery/Hive ở đâu nhỉ, theo như hệ thống của mình thì mình đang cần làm Accumulating Snapshot cho các đơn hàng (VD Đơn hàng 1, Khách hàng, Người bán, Ngày nhận đơn, ai nhận đơn, ngày ship, ship bởi ai, ngày giao, ngày khiếu nại, ngày kết thúc....), với hệ thống bảng quan hệ chằng chịt, thì cái lệnh tổng hợp, join được thực hiện ở Source Data hay ở đâu nhỉ. Hiện giờ mình quyết định làm luôn trên source data cho lẹ (đang bị hối quá rồi), dùng sức mạnh của source để join, detect change chỉ cần có thay đổi ở 1 khâu là extract lại cả cái snapshot cho đơn hàng đó, có đủ dữ liệu rồi thì mang nó qua Spark/Data Warehouse transform, đã test và tạm thời không có vấn đề gì về performance, nhưng chẳng biết sau này sẽ trở thành quái quỷ gì luôn.

Thường hệ này thì người ta nhét raw_data thường là dạng file có thể csv/json upload lên s3, hdfs, ﹾﹾﹾ, or database. Rồi từ đó mình clean data rồi join đủ kiểu ở fact table. Chỗ join/clean data tạo ra fact là nơi để query engine như Spark/Hive/Bigquery/Presto xử lý.

Mình giải thích vậy có thắc mắc gì cứ hỏi.
Reply With Quote
  #42  
Old 18-12-2019, 20:49
ez-aqua's Avatar
ez-aqua ez-aqua is offline
Member
Join Date: 11-2013
Posts: 54
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by Chief Bean View Post
Trước hết về ....[/url]
Quote:
-> Solution có thể là partition daily và nếu hôm nay thay đổi thì cứ insert overwrite table xxxx partition(day=20191202) select * from xxx where day=20191201 union all select * new_data.
Hệ này cứ overwrite lại nếu muốn update. Write là cheap operation. Còn muốn keep cái snapshot partition nào thì keep cái đó ví dụ như nếu muốn lưu lại tháng 11 thì keep partition 20191130 thôi.
Như vậy theo mình hiểu là thế này
Ví dụ partition day = 20191218 cho tới lúc 12h trưa có

TableX
ID |Name | Count |UpdatedDate
1|ABC | 3 | 7:00
2|BCD | 4 | 8:00 AM

Đến 6h tối, mình extract mới được các dòng sau, và hiện đang nằm trong staging
STG_TableX
1| ABCD |10 |16:00
3| DEF | 5 |17:00

Trong đó dòng có ID = 1 ở source tên đã được sửa từ "ABC" thành "ABCD" và Count đã biến từ 3 thành 10, và có thêm 1 dòng ID = 3 nữa là DEF và Count = 5.

Thì mình sẽ cần làm là kiểu

SELECT * INTO #TableXTemp FROM TableX //Tạm thời ghi tất cả dữ liệu trong TableX ra một chỗ khác

TRUNCATE TABLE TableX //Xóa toàn bộ TableX

INSERT INTO TableX
SELECT *, ROW() OVERPARTITION ID ORDER BY UpdatedDate DESC
FROM
(
SELECT *, FROM #TableXTemp
UNION ALL
SELECT *FROM STG_TableX
)
WHERE RowNum = 1

//Lấy ra version mới nhất, RowNum 1 là version mới nhất của ID đó vì nó đã được xếp theo thứ tự của Updated Date.

Kiểu như thế này đúng không bác. Nếu mà thế này thì mình thấy y chang một cái hướng dẫn workaround khi làm SCD2 cho Hive mình thấy trên mạng.

Quote:
Thường hệ này thì người ta nhét raw_data thường là dạng file có thể csv/json upload lên s3, hdfs, ﹾﹾﹾ, or database. Rồi từ đó mình clean data rồi join đủ kiểu ở fact table. Chỗ join/clean data tạo ra fact là nơi để query engine như Spark/Hive/Bigquery/Presto xử lý.
Mình thấy cái phương pháp này rất chuẩn với các dữ liệu kiểu event append only, và dữ liệu rất lớn (Mỗi ngày extract ra chừng >1.000.000 dòng). Nhưng hệ thống mình đang làm không lớn như vậy (các entity trong DB chính mới chỉ ~3.000.000 records), và có tính thay đổi rất cao.

Hiện giờ hệ thống mình kiểu này, vd mình có một dòng là đơn hàng, nhưng thông tin của nó thì phân tán ra khắp các bảng,

Bảng đơn hàng có: ID đơn, Ngày lập đơn, Giá tiền, Trạng thái đơn hiện tại
Bảng thông tin các bên trong đơn hàng có: ID đơn, ID người bán, ID người mua
2 bảng trên quan hệ 1:1
....

Và cái cuối cùng mình extract ra sẽ là
ID, Ngày lập đơn, Giá tiền, Trạng thái đơn hiện tại, ID người bán, ID người mua

Như vậy khi extract, mình phải bắt sự kiện thay đổi ở cả 2 bảng, chỉ cần ID đó có sự thay đổi ở bất kì bảng nào trong 2 bảng này thì mình phải extract lại toàn bộ, và mình hiện tại là đang join luôn trên extract, và hiện tại mình không tìm thấy cách nào khả thi hơn. Extract xong rồi thì mới đem qua Spark hay đâu đó transform, ví dụ như cái trạng thái đơn hiện tại nó đang là số 1, 2, 3 gì đó thì mình biến nó thành text "chưa hoàn thành", "đã hoàn thành" chẳng hạn.

Việc join trên extract lúc đầu mình phản đối nhưng sau rồi mình ko tài nào tìm ra được cách nào tốt hơn, với cả bị hối nên giờ quyết định làm luôn. Ở transform chủ yếu là parse text, filter, transform text gì đó thôi.
_______________________________
Bên mình cũng có những entity kiểu append only, kiểu hiện tại công ty mình gần đây đang thuê 1 bên khác làm gia công một số việc nhập liệu chân tay, và muốn phân tích performance dựa vào log. Thì hiện tại đống log đó đang được ghi thẳng vào... database. Và khi mình khảo sát thử thì 6 tháng đến giờ mới chỉ có 700.000 dòng thôi, mình ước tính độ lớn nếu xuất cả bảng đó ra file CSV thì cũng không hơn 400MB. Nói thế để thấy dữ liệu của bên mình ít nhất ở thời điểm hiện tại là rất nhỏ (so với cái gọi là big data) để phải bắt buộc mang những thứ hầm hố như Spark, Hive ra để quẩy.

Lúc đầu mình rất muốn mang những thứ hầm hố nhất vô dự án, nhưng sau thấy dữ liệu không đủ lớn (thời gian khởi động cái cluster lên còn lâu hơn thời gian dùng SQL transform , chưa kể các overhead khác), rồi tầm vóc công ty/lãnh đạo chưa đến, mình suốt ngày phải đi giải thích mấy cái đồ A, đồ B để làm cái quái gì, tại sao design thế này thế kia nên giờ mình cũng nản, làm đơn giản, nhanh nhất có thể. Đến khi nào họ thực sự hiểu mình đang cần gì, đang gặp vấn đề gì, thực có nhu cầu, hiểu nó là gì thì lúc đó mình mới bày vẽ. 1355308
Reply With Quote
  #43  
Old 19-12-2019, 10:04
Chief Bean's Avatar
Chief Bean Chief Bean is offline
Senior Member
Join Date: 12-2009
Posts: 133
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by ez-aqua View Post
Như vậy theo mình hiểu là thế này
Ví dụ partition day = 20191218 cho tới lúc 12h trưa có

TableX
ID |Name | Count |UpdatedDate
1|ABC | 3 | 7:00
2|BCD | 4 | 8:00 AM

Đến 6h tối, mình extract mới được các dòng sau, và hiện đang nằm trong staging
STG_TableX
1| ABCD |10 |16:00
3| DEF | 5 |17:00

Trong đó dòng có ID = 1 ở source tên đã được sửa từ "ABC" thành "ABCD" và Count đã biến từ 3 thành 10, và có thêm 1 dòng ID = 3 nữa là DEF và Count = 5.

Thì mình sẽ cần làm là kiểu

SELECT * INTO #TableXTemp FROM TableX //Tạm thời ghi tất cả dữ liệu trong TableX ra một chỗ khác

TRUNCATE TABLE TableX //Xóa toàn bộ TableX

INSERT INTO TableX
SELECT *, ROW() OVERPARTITION ID ORDER BY UpdatedDate DESC
FROM
(
SELECT *, FROM #TableXTemp
UNION ALL
SELECT *FROM STG_TableX
)
WHERE RowNum = 1

//Lấy ra version mới nhất, RowNum 1 là version mới nhất của ID đó vì nó đã được xếp theo thứ tự của Updated Date.

Kiểu như thế này đúng không bác. Nếu mà thế này thì mình thấy y chang một cái hướng dẫn workaround khi làm SCD2 cho Hive mình thấy trên mạng.



Mình thấy cái phương pháp này rất chuẩn với các dữ liệu kiểu event append only, và dữ liệu rất lớn (Mỗi ngày extract ra chừng >1.000.000 dòng). Nhưng hệ thống mình đang làm không lớn như vậy (các entity trong DB chính mới chỉ ~3.000.000 records), và có tính thay đổi rất cao.

Hiện giờ hệ thống mình kiểu này, vd mình có một dòng là đơn hàng, nhưng thông tin của nó thì phân tán ra khắp các bảng,

Bảng đơn hàng có: ID đơn, Ngày lập đơn, Giá tiền, Trạng thái đơn hiện tại
Bảng thông tin các bên trong đơn hàng có: ID đơn, ID người bán, ID người mua
2 bảng trên quan hệ 1:1
....

Và cái cuối cùng mình extract ra sẽ là
ID, Ngày lập đơn, Giá tiền, Trạng thái đơn hiện tại, ID người bán, ID người mua

Như vậy khi extract, mình phải bắt sự kiện thay đổi ở cả 2 bảng, chỉ cần ID đó có sự thay đổi ở bất kì bảng nào trong 2 bảng này thì mình phải extract lại toàn bộ, và mình hiện tại là đang join luôn trên extract, và hiện tại mình không tìm thấy cách nào khả thi hơn. Extract xong rồi thì mới đem qua Spark hay đâu đó transform, ví dụ như cái trạng thái đơn hiện tại nó đang là số 1, 2, 3 gì đó thì mình biến nó thành text "chưa hoàn thành", "đã hoàn thành" chẳng hạn.

Việc join trên extract lúc đầu mình phản đối nhưng sau rồi mình ko tài nào tìm ra được cách nào tốt hơn, với cả bị hối nên giờ quyết định làm luôn. Ở transform chủ yếu là parse text, filter, transform text gì đó thôi.
_______________________________
Bên mình cũng có những entity kiểu append only, kiểu hiện tại công ty mình gần đây đang thuê 1 bên khác làm gia công một số việc nhập liệu chân tay, và muốn phân tích performance dựa vào log. Thì hiện tại đống log đó đang được ghi thẳng vào... database. Và khi mình khảo sát thử thì 6 tháng đến giờ mới chỉ có 700.000 dòng thôi, mình ước tính độ lớn nếu xuất cả bảng đó ra file CSV thì cũng không hơn 400MB. Nói thế để thấy dữ liệu của bên mình ít nhất ở thời điểm hiện tại là rất nhỏ (so với cái gọi là big data) để phải bắt buộc mang những thứ hầm hố như Spark, Hive ra để quẩy.

Lúc đầu mình rất muốn mang những thứ hầm hố nhất vô dự án, nhưng sau thấy dữ liệu không đủ lớn (thời gian khởi động cái cluster lên còn lâu hơn thời gian dùng SQL transform , chưa kể các overhead khác), rồi tầm vóc công ty/lãnh đạo chưa đến, mình suốt ngày phải đi giải thích mấy cái đồ A, đồ B để làm cái quái gì, tại sao design thế này thế kia nên giờ mình cũng nản, làm đơn giản, nhanh nhất có thể. Đến khi nào họ thực sự hiểu mình đang cần gì, đang gặp vấn đề gì, thực có nhu cầu, hiểu nó là gì thì lúc đó mình mới bày vẽ. 1355308

Hệ này xử lý thím cần chia ra các layer example hiện tại bên mình đang làm:
- ods : raw_data nghĩa là 1 bản copy từ source ko xử lý gì cả
- cdm: Nơi data sẽ được xử lý như clean/join để tạo ra fact, dimension tables phục vụ cho BI - báo cáo chứ ko phải same data model của application/source nữa.
- ads: Nơi aggregation data được chứa để tạo ra các report dạng summarize các con số ....

Theo design trên thì mỗi lần bác muốn update thì cứ query ở tầng raw rồi overwrite lại thôi.
Partition theo daily nghĩa là snapshot theo ngày. Muốn theo dõi diễn biến rõ hơn thì partition theo hourly mà cái này costly hơn.

>>> Mình thấy cái phương pháp này rất chuẩn với các dữ liệu kiểu event append only, và dữ liệu rất lớn (Mỗi ngày extract ra chừng >1.000.000 dòng). Nhưng hệ thống mình đang làm không lớn như vậy (các entity trong DB chính mới chỉ ~3.000.000 records), và có tính thay đổi rất cao.

Thường hệ này con số như này thì rất nhỏ có thể không nên chọn hệ này vì ko đáng + setup cost cao hơn.
Thường hệ này hoạt động có hiệu quả thì data cỡ 100 triệu records trở lên và join cỡ > 50 với nhau mỗi table có khoảng vài triệu đến vài chục triệu.

Với data nhỏ như quy mô của thím thì mình khuyên vẫn nên xài rmbs như Postgres/Oracle/SQL Server cho khoẻ. Trừ khi nào gặp vấn đề về scale như data vượt quá disk hay query lâu .... nhiều concurrent users.
Reply With Quote
  #44  
Old 19-12-2019, 10:42
ez-aqua's Avatar
ez-aqua ez-aqua is offline
Member
Join Date: 11-2013
Posts: 54
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by Chief Bean View Post
Hệ này xử lý thím cần chia ra các layer example hiện tại bên mình đang làm:
- ods : raw_data nghĩa là 1 bản copy từ source ko xử lý gì cả
- cdm: Nơi data sẽ được xử lý như clean/join để tạo ra fact, dimension tables phục vụ cho BI - báo cáo chứ ko phải same data model của application/source nữa.
- ads: Nơi aggregation data được chứa để tạo ra các report dạng summarize các con số ....
Mình có đọc mấy cái khái niệm ODS gì đó ở trong một cái sách hướng dẫn làm DWH nào đó, nhưng sau này khi làm theo mấy cái mô hình của M$ thì mình không còn thấy khái niệm này nữa.

Nhưng theo mình hiểu sẽ là, sẽ có 1 database ODS khác được replicate y chang cái source Database, bên source có gì thì ở cái ODS này có nguyên mẫu y chang vậy. Rồi sau đó ở cái Database này, mình mới clean/join để tạo ra dim table và fact table, chế cháo kiểu gì đó để ra đúng chuẩn Dimensional Modeling của Kimball, rồi lưu vào CDM.

Còn ADS là nơi lưu các Aggregated Table, và thậm chí còn được join dim fact sẵn luôn nhỉ, ví dụ ở CDM là grain atomic theo transaction thì ở ADS kia hàng tháng sẽ chạy và được group by lên grain tháng , để việc query nhanh và dễ dàng hơn.

Mình hiểu thế đúng không nhỉ. Nếu như mình hiểu đúng cái ODS thì mình cảm thấy cái Database backup được Sync y chang từ Production của công ty mình có thể được coi là ODS nhỉ. Hiện tại mình cào dữ liệu cho Data Warehouse là cào từ cái DB backup này chứ ko lấy trực tiếp từ Production.

Còn đối với Unstructured, Semi-Structured thì cái Data Lake chứa dữ liệu nguyên gốc kia chính là ODS nhỉ. Bạn xác nhận dùm là mình hiểu đúng không nhé.

Cái vụ join sẵn thì ở hệ thống mình dùng Analysis Service với Power BI. Ở trên Analysis Service engineer hiểu và handle được vụ table relationship với filter propagation sẵn trên centralized semantic model trên cloud, nên là cũng ko cần join sẵn, cứ Dim Fact là được, Power BI với Analysis Service cân được

Quote:
Theo design trên thì mỗi lần bác muốn update thì cứ query ở tầng raw rồi overwrite lại thôi.
Partition theo daily nghĩa là snapshot theo ngày. Muốn theo dõi diễn biến rõ hơn thì partition theo hourly mà cái này costly hơn.
Như vậy có nghĩa là, vd mình muốn update cho ngày 20191218 thì:

1. Mình query lại toàn bộ những data trong ngày 20191218, transform vào rồi ghi đè hoàn toàn luôn, chứ không cần incremental load.

2. Vẫn incremental load, union all cũ mới rồi đánh row num theo ID order by date để lấy version mới nhất.

Bác chọn dùm mình cụ thể là cách 1 hay cách 2 hay cả 2 cách đều sai nhé, chứ mình vẫn chưa hiểu lắm câu xác nhận của bác.

Mà sao cảm thấy thế này thì sẽ ko handle được tính lịch sử kiểu như SCD Type 2 nhỉ. Mình thấy SCD Type2 2 là sự kì diệu của Dimensional Modeling, nhưng nếu ko có dim fact mà extract phẳng hoàn toàn mới từ source thế này thì làm sao track được lịch sử nhỉ, vì giá trị ở source lúc này là mới nhất chứ không phải lúc event diễn ra nữa.

Quote:
>>> Mình thấy cái phương pháp này rất chuẩn với các dữ liệu kiểu event append only, và dữ liệu rất lớn (Mỗi ngày extract ra chừng >1.000.000 dòng). Nhưng hệ thống mình đang làm không lớn như vậy (các entity trong DB chính mới chỉ ~3.000.000 records), và có tính thay đổi rất cao.

Thường hệ này con số như này thì rất nhỏ có thể không nên chọn hệ này vì ko đáng + setup cost cao hơn.
Thường hệ này hoạt động có hiệu quả thì data cỡ 100 triệu records trở lên và join cỡ > 50 với nhau mỗi table có khoảng vài triệu đến vài chục triệu.

Với data nhỏ như quy mô của thím thì mình khuyên vẫn nên xài rmbs như Postgres/Oracle/SQL Server cho khoẻ. Trừ khi nào gặp vấn đề về scale như data vượt quá disk hay query lâu .... nhiều concurrent users.
Đồng ý, lúc đầu mình tính phang con Azure Data Warehouse (Giờ nó đổi tên thành Azure Synapse Analytic rồi), mà giá nó đắt kinh hoàng, bọn mình chạy thử có vài ngày plan thấp nhất đã bay chục đô. Tầm vóc công ty như hiện tại chắc chắn ko ai điên duyệt cả ngàn đô 1 tháng cho nó cả. Sau này scale thì move từ SQL Server lên Synapse Analytic thấy chẳng có vấn đề gì. Thấy Synapse Analytic y chang SQL Server, chỉ khác có mỗi bên dưới 1 cái là SMP còn 1 cái là MPP thôi.

Vụ Query lâu, vượt disk thì mình nghĩ là ko sợ, vì bọn mình sẽ có một lớp Analysis Service để serve data chứ người ta sẽ ko truy cập trực tiếp vào data warehouse (Tuy nhiên lãnh đạo có hiểu nổi cái này là gì mà duyệt hay không thì mình ko chắc), lúc này DWH chỉ còn là nơi lưu data thôi. Analysis Service refresh data hàng ngày từ DWH lên cache của nó, rồi người ta sẽ live connection vô Analysis Service để query. DWH chắc chỉ phục vụ ad-hoc query do engineer làm là chính thôi. Analysis Service Scale thoải mái, thích thì bay lên tận S10 5000$ 1 tháng cũng được, có tiền hay không thôi.
1355308

Last edited by ez-aqua; 19-12-2019 at 10:48.
Reply With Quote
  #45  
Old 20-12-2019, 14:45
Chief Bean's Avatar
Chief Bean Chief Bean is offline
Senior Member
Join Date: 12-2009
Posts: 133
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

>>> Mình hiểu thế đúng không nhỉ. Nếu như mình hiểu đúng cái ODS thì mình cảm thấy cái Database backup được Sync y chang từ Production của công ty mình có thể được coi là ODS nhỉ.

Đúng rồi. Tức là 1 replicate/copy 1 bản của source vào DataWarehouse. Có nhiều mục đích/lý do cho việc này.
- đảm bảo sự độc lập. Không tác động nhiều để source Ví dụ dùng database mà nhiều anh vào cứ join hoài ảnh hưởng performance chưa kể hold 1 table quá lâu có thể ảnh hướng để transaction ....
- quá trình lấy dữ liệu đơn giản.
- có thể backup/copy/snapshot data từ source.


>>> Hiện tại mình cào dữ liệu cho Data Warehouse là cào từ cái DB backup này chứ ko lấy trực tiếp từ Production.

Thường thì theo mô hình Master-Slave/Primary-Secondary cho db thì lấy data từ Slave/Replication Server chứ ko lấy master.


>>> Còn ADS là nơi lưu các Aggregated Table, và thậm chí còn được join dim fact sẵn luôn nhỉ, ví dụ ở CDM là grain atomic theo transaction thì ở ADS kia hàng tháng sẽ chạy và được group by lên grain tháng , để việc query nhanh và dễ dàng hơn.

ADS thì có quyền query trực tiếp từ ODS lên để build 1 summary gì đó. Nhưng thường ưu tiên lấy data từ CDM vì ở CDM đã clean, join sẳn gọi là chuẩn bị sẳn hay standarize sẳn nên dùng ở đó cho hợp chuẩn. Hơn nữa sau này muốn đổi gì ở tầng CDM thì các tầng trên sẽ follow trên. Tránh việc là đổi ở CDM nhưng các report ở trên query trực tiếp từ ODS dẫn đến đổi hàng loạt khó kiểm soát.


>>> Còn đối với Unstructured, Semi-Structured thì cái Data Lake chứa dữ liệu nguyên gốc kia chính là ODS nhỉ. Bạn xác nhận dùm là mình hiểu đúng không nhé.

Đúng rồi.


>>> Cái vụ join sẵn thì ở hệ thống mình dùng Analysis Service với Power BI. Ở trên Analysis Service engineer hiểu và handle được vụ table relationship với filter propagation sẵn trên centralized semantic model trên cloud, nên là cũng ko cần join sẵn, cứ Dim Fact là được, Power BI với Analysis Service cân được

JOIN sẳn ở đây có nghĩa là người dùng ko cần join nhiều table với nhau để lấy được kết quả nữa. Ví dụ 100 người cùng join 10 tables với nhau trên scale 100 triệu records sẽ tốn biết bao nhiêu tài nguyên hệ thống ....

Còn nếu on-demand thì nếu concurrent user thấp + còn resource thì vẫn ok nhưng ko scale được.


>>> Như vậy có nghĩa là, vd mình muốn update cho ngày 20191218 thì:

1. Mình query lại toàn bộ những data trong ngày 20191218, transform vào rồi ghi đè hoàn toàn luôn, chứ không cần incremental load.

2. Vẫn incremental load, union all cũ mới rồi đánh row num theo ID order by date để lấy version mới nhất.

Bác chọn dùm mình cụ thể là cách 1 hay cách 2 hay cả 2 cách đều sai nhé, chứ mình vẫn chưa hiểu lắm câu xác nhận của bác.

Mà sao cảm thấy thế này thì sẽ ko handle được tính lịch sử kiểu như SCD Type 2 nhỉ. Mình thấy SCD Type2 2 là sự kì diệu của Dimensional Modeling, nhưng nếu ko có dim fact mà extract phẳng hoàn toàn mới từ source thế này thì làm sao track được lịch sử nhỉ, vì giá trị ở source lúc này là mới nhất chứ không phải lúc event diễn ra nữa.


Cái này mình ví dụ thôi. Tức là khoảng data nào bị change thì phải query và join/group by lại khoảng đó.

Ví dụ mình có 1 fact table cho package - lưu lại lịch sử của các packages và user muốn xem lịch sử của 3 tháng gần đây. Vấn đề là giao hàng thường mất cỡ 1 tuần từ khi khởi tạo đến khi giao hàng. Nếu mình muốn keep tất cả các data trên 1 partition - vì cách này lợi khi query thì mình chỉ filter các package created trong 1 tuần gần đây và join summary, group by gì đó còn các package còn lại thì lấy từ last partition filter out ra mấy cái gần 1 tuần rồi union lại với nhau trong partition mới.



>>> Đồng ý, lúc đầu mình tính phang con Azure Data Warehouse (Giờ nó đổi tên thành Azure Synapse Analytic rồi), mà giá nó đắt kinh hoàng, bọn mình chạy thử có vài ngày plan thấp nhất đã bay chục đô. Tầm vóc công ty như hiện tại chắc chắn ko ai điên duyệt cả ngàn đô 1 tháng cho nó cả. Sau này scale thì move từ SQL Server lên Synapse Analytic thấy chẳng có vấn đề gì. Thấy Synapse Analytic y chang SQL Server, chỉ khác có mỗi bên dưới 1 cái là SMP còn 1 cái là MPP thôi.

Vụ Query lâu, vượt disk thì mình nghĩ là ko sợ, vì bọn mình sẽ có một lớp Analysis Service để serve data chứ người ta sẽ ko truy cập trực tiếp vào data warehouse (Tuy nhiên lãnh đạo có hiểu nổi cái này là gì mà duyệt hay không thì mình ko chắc), lúc này DWH chỉ còn là nơi lưu data thôi. Analysis Service refresh data hàng ngày từ DWH lên cache của nó, rồi người ta sẽ live connection vô Analysis Service để query. DWH chắc chỉ phục vụ ad-hoc query do engineer làm là chính thôi. Analysis Service Scale thoải mái, thích thì bay lên tận S10 5000$ 1 tháng cũng được, có tiền hay không thôi.

Uhm nên look into MPP nếu mà RBMS ko chịu nổi. Lên hệ này tốn rất nhiều tiền. Ngay cả big corp cũng chảy máu mũi với cost của hệ này.
Reply With Quote
  #46  
Old 23-12-2019, 10:31
ez-aqua's Avatar
ez-aqua ez-aqua is offline
Member
Join Date: 11-2013
Posts: 54
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by Chief Bean View Post

Đúng rồi. Tức là 1 replicate/copy 1 bản của source vào DataWarehouse. Có nhiều mục đích/lý do cho việc này.
- đảm bảo sự độc lập. Không tác động nhiều để source Ví dụ dùng database mà nhiều anh vào cứ join hoài ảnh hưởng performance chưa kể hold 1 table quá lâu có thể ảnh hướng để transaction ....
- quá trình lấy dữ liệu đơn giản.
- có thể backup/copy/snapshot data từ source.

Thường thì theo mô hình Master-Slave/Primary-Secondary cho db thì lấy data từ Slave/Replication Server chứ ko lấy master.
OK mình cảm thấy mình hiểu hơn rồi. Vậy cái lớp ODS này có thể coi là lớp:

- Lưu giữ data ở dạng nguyên bản nhất.

- Do data được lưu ở dạng nguyên bản -> quá trình replicate/copy/sync diễn ra nhanh chóng => không làm ảnh hưởng đến OLTP (lock bảng, high IO). Còn những tác vụ ELT cho để tạo ra DIM FACT phức tạp sẽ không còn phải làm trực tiếp ở OLTP nữa mà sẽ làm ở ODS.

Mình hay nói là Data Warehouse dùng để cách li các vấn đề ra khỏi OLTP, nhưng mình luôn có một trăn trở rằng nếu join ngay trên OLTP thì cái tính cách li này sẽ bị mất đi ít nhiều. Thì giờ đã hiểu sẽ có 1 lớp ODS để hạn chế việc phải sử dụng sức mạnh của OLTP để xử lý data.

Tầng này trong cái mô hình của M$ nó gọi là Store. Giờ mới hiểu hơn được cái chữ Store đó nghĩa là gì.



Quote:
ADS thì có quyền query trực tiếp từ ODS lên để build 1 summary gì đó. Nhưng thường ưu tiên lấy data từ CDM vì ở CDM đã clean, join sẳn gọi là chuẩn bị sẳn hay standarize sẳn nên dùng ở đó cho hợp chuẩn. Hơn nữa sau này muốn đổi gì ở tầng CDM thì các tầng trên sẽ follow trên. Tránh việc là đổi ở CDM nhưng các report ở trên query trực tiếp từ ODS dẫn đến đổi hàng loạt khó kiểm soát.
Cái CDM mình chưa rõ lắm nhưng có thể coi là DDS (Dimensional Data Store) không nhỉ. Ở tầng này thì data được chuyển về dạng Dimension (Dim - Fact). Dĩ nhiên là data khi đi từ ODS qua đây thì sẽ được clean, join, integrate, transform thành Dim-Fact. Hay là chuyển về dạng flat table join sẵn cũng là ở tầng này. Mình thấy thế đúng không nhỉ.

Ở trong mô hình của Microsoft nó gọi cái này là "model".



Quote:
Cái này mình ví dụ thôi. Tức là khoảng data nào bị change thì phải query và join/group by lại khoảng đó.

Ví dụ mình có 1 fact table cho package - lưu lại lịch sử của các packages và user muốn xem lịch sử của 3 tháng gần đây. Vấn đề là giao hàng thường mất cỡ 1 tuần từ khi khởi tạo đến khi giao hàng. Nếu mình muốn keep tất cả các data trên 1 partition - vì cách này lợi khi query thì mình chỉ filter các package created trong 1 tuần gần đây và join summary, group by gì đó còn các package còn lại thì lấy từ last partition filter out ra mấy cái gần 1 tuần rồi union lại với nhau trong partition mới.
Nói tóm lại là, để thay đổi trong hệ append only này, thì theo một mốc thời gian nhất định, mình vào ODS query lại hoàn toàn, được bao nhiêu thì overwrite luôn cái đó vào cái partition chứa data của khoảng thời gian đó.

Mình hiểu đúng chưa nhỉ.

Mà cho mỉnh hỏi là bên bác dùng GG Big Query cho tầng nào, theo mình thấy có thể là CDM và ADS. Mô hình thực hiện sẽ là hàng ngày vô ODS query, clean, transform thành Dim-Fact hay flat table gì đó rồi nhét vào CDM. Rồi sau đó cứ đến đúng định kì thì chui vào CDM aggregate lên grain cao hơn cho người dùng xài rồi nhét vào ADS. Có phải vậy không nhỉ.

Mà sao thấy cái ADS có phần giống với OLAP (tầng Serve trong mô hình của M$). Nhưng mà OLAP trong stack của Microsoft nó là cái Analysis Services, nó hốt nguyên khối data từ tầng model, cậy columnar storage để lưu trữ số lượng lớn data trong một cache có giới hạn, có khả năng aggregation khủng, đồng thời cung cấp semantic layer (làm sẵn table relationship, filter propagation, calculated column, calculated table...) Chứ không aggregate sẵn như thế này....

1355308

Last edited by ez-aqua; 23-12-2019 at 10:39.
Reply With Quote
  #47  
Old 19-02-2020, 11:05
cauthungoaihang's Avatar
cauthungoaihang cauthungoaihang is offline
Senior Member
Join Date: 06-2008
Posts: 177
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Xin phép các thím đào mộ topic này lên để nhờ vả

Mấy hôm trước mình có pm trao đổi với thím thớt, nay post lên đây để nhờ thớt và các thím chia sẻ ít kinh nghiệm để bắt đầu xây dựng 1 cái Data Warehouse luôn. Nói DW cho nó oai, chứ thực ra mình đang phụ trách mảng Phân tích số liệu cho một công ty, việc hàng ngày là lên mạng gom 1 đống file số liệu các kiểu về, kiểm tra, format lại, copy dán này kia để đưa về dạng chuẩn và lưu vào các folder. Khâu phân tích thì đang dùng Power BI Desktop để lấy dữ liệu từ folder và visualize.

Phần Power BI thì mình làm khá tốt (ít ra là tự thấy thế hehe ), nhưng phần tải-clean-transform-lưu dữ liệu thì cực kỳ vất vả, dễ sai sót và hay quên Mình có tập tành dùng Python + Task schedule trong Windows cho nó tự tải, nếu là link tải file thì đơn giản là mở link và save, nếu là html thì mình dùng Selenium cho nó mở và dùng Beautiful Soup lọc dữ liệu cần thiết ra lưu vào .csv. Có một số vấn đề như sau:

1. Hiện giờ mình có rất nhiều file .py (mình chỉ viết trong spyder) chạy bằng Task schedule, cũng không chắc nó có chạy không, nó chạy xong cũng không biết có lỗi gì không, phải vô kiểm tra file tải về => có cách nào quản lý các file này chuyên nghiệp hơn không?

2. Mình tính thay vì lưu vào các file excel hoặc csv thì dựng một database và đẩy thẳng vô. Tính thuê 1 cái VPS, cài Postgresql lên đó đẩy các dữ liệu vào, tạo sẵn các view cần dùng, sau đó dùng Power BI connect vô => các thím thấy có vấn đề gì không, có cách nào tốt hơn không?

3. Mình chưa đụng tới Scrapy, nghe nói tốt hơn Selenium và Beautiful Soup. Thím nào có kinh nghiệm dùng 3 cái này thì tư vấn cho mình với.

Thanks các thím nhé
__________________
Nothing to sign
Reply With Quote
  #48  
Old 19-02-2020, 19:07
ez-aqua's Avatar
ez-aqua ez-aqua is offline
Member
Join Date: 11-2013
Posts: 54
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by cauthungoaihang View Post
Xin phép các thím đào mộ topic này lên để nhờ vả

Mấy hôm trước mình có pm trao đổi với thím thớt, nay post lên đây để nhờ thớt và các thím chia sẻ ít kinh nghiệm để bắt đầu xây dựng 1 cái Data Warehouse luôn. Nói DW cho nó oai, chứ thực ra mình đang phụ trách mảng Phân tích số liệu cho một công ty, việc hàng ngày là lên mạng gom 1 đống file số liệu các kiểu về, kiểm tra, format lại, copy dán này kia để đưa về dạng chuẩn và lưu vào các folder. Khâu phân tích thì đang dùng Power BI Desktop để lấy dữ liệu từ folder và visualize.

Phần Power BI thì mình làm khá tốt (ít ra là tự thấy thế hehe ), nhưng phần tải-clean-transform-lưu dữ liệu thì cực kỳ vất vả, dễ sai sót và hay quên Mình có tập tành dùng Python + Task schedule trong Windows cho nó tự tải, nếu là link tải file thì đơn giản là mở link và save, nếu là html thì mình dùng Selenium cho nó mở và dùng Beautiful Soup lọc dữ liệu cần thiết ra lưu vào .csv. Có một số vấn đề như sau:

1. Hiện giờ mình có rất nhiều file .py (mình chỉ viết trong spyder) chạy bằng Task schedule, cũng không chắc nó có chạy không, nó chạy xong cũng không biết có lỗi gì không, phải vô kiểm tra file tải về => có cách nào quản lý các file này chuyên nghiệp hơn không?

2. Mình tính thay vì lưu vào các file excel hoặc csv thì dựng một database và đẩy thẳng vô. Tính thuê 1 cái VPS, cài Postgresql lên đó đẩy các dữ liệu vào, tạo sẵn các view cần dùng, sau đó dùng Power BI connect vô => các thím thấy có vấn đề gì không, có cách nào tốt hơn không?

3. Mình chưa đụng tới Scrapy, nghe nói tốt hơn Selenium và Beautiful Soup. Thím nào có kinh nghiệm dùng 3 cái này thì tư vấn cho mình với.

Thanks các thím nhé
Cái bạn đang làm là đúng chuẩn Data warehouse rồi, không cần dữ liệu cứ phải lớn thì mới được gọi là data warehouse đâu.

Mình đọc thì thấy giải pháp data của bạn là đang ở máy vật lý ở công ty (File py rồi task scheduler gì đó....) chứ không dùng cloud. Mảng này mình không có kinh nghiệm, vì mình làm là full trên cloud. Nhưng nếu bạn muốn lên cloud, và học theo mô hình của M$ thì



Trong mô hình này, phần khoanh đỏ là phần Store. Bạn tập hợp hết raw data vào đây.

Sau đó, sẽ có một cỗ máy giúp bạn parse-transform dữ liệu semi-structured và un-structured rất khủng là Spark. Bạn chạy nó trên Hadoop cluster (Azure có HD Insights, còn AWS hình như là Elastic MapReduce thì phải) hay managed Spark như Databricks (Thấy cả AWS lẫn Azure đều có) đều được. Spark này có Python nên mình nghĩ là thoải mái, mình practice python toàn dùng notebook của Databricks. Mà cho mình hỏi là file HTML đó như thế nào mà phải chơi Selenium vậy (Mình hiểu thì đây là công cụ cho tester người ta test automation), tự động làm hành động nào đó.... Tại sao ko mở HTML như file text rồi parse bằng regular expression nhỉ. Mà nói chung là mình cũng không có rành mấy vụ như crawl data trên web.

Nếu mà là job của Databricks thì mình có thử Automated Job và đến giờ thì nó khởi động lên và chạy. Lỗi thì nó sẽ hiện lên trong danh sách history.

Bên mình toàn dữ liệu trong database ra nên là cứ thế dùng một cái data ochestration (ở Azure thì mình dùng factory) move qua Data warehouse rồi transform theo ý muốn thôi, hiện giờ không cần làm việc với JSON, XML hay phải parse TXT file gì cả. Lúc đầu mình muốn vẽ ra case, cố ép để xài Spark lắm mà không có nổi. Overhead nếu cố dùng là quá lớn. (Thời gian khởi động Spark cluster còn lâu quá cha hơn thời gian transform, công maintain cluster, rồi tiền trả, không có người biết pyspark/scala...) Nên dẹp. Khi nào có nhu cầu thực sự rồi xài.

Còn cái vụ làm cái SQL là chuẩn rồi, transform xong thì bạn load cái đám dữ liệu đã được transform đó vô trong một cái database là chuẩn. Query rất dễ dàng, có máy chủ để query ở bất cứ nơi nào, SQL nhiều người biết (So với việc lưu thành phẩm bằng file CSV trong 1 cái data lake rồi Analyst phải dùng đồ chơi như Spark để mò vào). Nhưng mà mình nghĩ bạn nên chơi luôn cái managed cloud database ấy (Nếu bạn xài Azure thì có Azure SQL), xài rất sướng. chứ chơi con virtual machine rồi cài database lên maintain, config đồ chắc điên luôn. Có cái database rồi thì dùng Power BI direct query trực tiếp trên database đó, hoặc import đều OK. Còn nếu muốn sướng cho Analyst level max thì quất luôn cái Analysis Services rồi Power BI live connection vào.

Quy mô của doanh nghiệp của bạn là thế nào nhỉ. Rồi câu hỏi với data là thế nào. Behavior của data có phải update/delete (nhiều) hay không, hay là append only. Nếu biết rõ hơn thì mình có thể đưa ra được những nhận định tốt hơn. Nhất là về phần data modeling của data warehouse.

Như mình biết thì modeling với data warehouse sẽ có dạng denormalize toàn bộ (bảng cào phẳng) và denormolize một phần (Star-Schema). Tùy vào nhu cầu mà bạn sẽ có lựa chọn về modeling của nó. 1355308

Last edited by ez-aqua; 19-02-2020 at 19:27.
Reply With Quote
  #49  
Old 20-02-2020, 14:20
cauthungoaihang's Avatar
cauthungoaihang cauthungoaihang is offline
Senior Member
Join Date: 06-2008
Posts: 177
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by ez-aqua View Post
Cái bạn đang làm là đúng chuẩn Data warehouse rồi, không cần dữ liệu cứ phải lớn thì mới được gọi là data warehouse đâu.

Mình đọc thì thấy giải pháp data của bạn là đang ở máy vật lý ở công ty (File py rồi task scheduler gì đó....) chứ không dùng cloud. Mảng này mình không có kinh nghiệm, vì mình làm là full trên cloud. Nhưng nếu bạn muốn lên cloud, và học theo mô hình của M$ thì



Trong mô hình này, phần khoanh đỏ là phần Store. Bạn tập hợp hết raw data vào đây.

Sau đó, sẽ có một cỗ máy giúp bạn parse-transform dữ liệu semi-structured và un-structured rất khủng là Spark. Bạn chạy nó trên Hadoop cluster (Azure có HD Insights, còn AWS hình như là Elastic MapReduce thì phải) hay managed Spark như Databricks (Thấy cả AWS lẫn Azure đều có) đều được. Spark này có Python nên mình nghĩ là thoải mái, mình practice python toàn dùng notebook của Databricks. Mà cho mình hỏi là file HTML đó như thế nào mà phải chơi Selenium vậy (Mình hiểu thì đây là công cụ cho tester người ta test automation), tự động làm hành động nào đó.... Tại sao ko mở HTML như file text rồi parse bằng regular expression nhỉ. Mà nói chung là mình cũng không có rành mấy vụ như crawl data trên web.

Nếu mà là job của Databricks thì mình có thử Automated Job và đến giờ thì nó khởi động lên và chạy. Lỗi thì nó sẽ hiện lên trong danh sách history.

Bên mình toàn dữ liệu trong database ra nên là cứ thế dùng một cái data ochestration (ở Azure thì mình dùng factory) move qua Data warehouse rồi transform theo ý muốn thôi, hiện giờ không cần làm việc với JSON, XML hay phải parse TXT file gì cả. Lúc đầu mình muốn vẽ ra case, cố ép để xài Spark lắm mà không có nổi. Overhead nếu cố dùng là quá lớn. (Thời gian khởi động Spark cluster còn lâu quá cha hơn thời gian transform, công maintain cluster, rồi tiền trả, không có người biết pyspark/scala...) Nên dẹp. Khi nào có nhu cầu thực sự rồi xài.

Còn cái vụ làm cái SQL là chuẩn rồi, transform xong thì bạn load cái đám dữ liệu đã được transform đó vô trong một cái database là chuẩn. Query rất dễ dàng, có máy chủ để query ở bất cứ nơi nào, SQL nhiều người biết (So với việc lưu thành phẩm bằng file CSV trong 1 cái data lake rồi Analyst phải dùng đồ chơi như Spark để mò vào). Nhưng mà mình nghĩ bạn nên chơi luôn cái managed cloud database ấy (Nếu bạn xài Azure thì có Azure SQL), xài rất sướng. chứ chơi con virtual machine rồi cài database lên maintain, config đồ chắc điên luôn. Có cái database rồi thì dùng Power BI direct query trực tiếp trên database đó, hoặc import đều OK. Còn nếu muốn sướng cho Analyst level max thì quất luôn cái Analysis Services rồi Power BI live connection vào.

Quy mô của doanh nghiệp của bạn là thế nào nhỉ. Rồi câu hỏi với data là thế nào. Behavior của data có phải update/delete (nhiều) hay không, hay là append only. Nếu biết rõ hơn thì mình có thể đưa ra được những nhận định tốt hơn. Nhất là về phần data modeling của data warehouse.

Như mình biết thì modeling với data warehouse sẽ có dạng denormalize toàn bộ (bảng cào phẳng) và denormolize một phần (Star-Schema). Tùy vào nhu cầu mà bạn sẽ có lựa chọn về modeling của nó. 1355308
Thanks thím thớt vì các thông tin rất hữu ích

Mình xài Selenium là vì một số site nó chạy JavaScript, vô site, bấm nút 1 lúc nó mới chạy và lấy được HTML, nếu chỉ send request thì không lấy được gì cả. Mình thấy selenium cũng chậm và bất tiện nên đang học Scrapy để chuyển qua.

Vụ xài server VPS là vì hồi trước mình có xài rồi nên có tí kinh nghiệm, hiện tại thì dựng database cũng tàm tạm rồi. SQL trên cloud nghe nói nhiều nhưng mình chưa thử bao giờ, để mai mốt thử xem, nếu giá hợp lý thì triển luôn

Data từ rất nhiều nguồn, nhưng mà size thì nhỏ (nhiều nguồn mỗi ngày chỉ phát sinh 1 dòng ^^), và chủ yếu là thêm vào dữ liệu sẵn có chứ không xóa dữ liệu cũ đi. Các dữ liệu chủ yếu liên quan về mặt thời gian và địa lý, chứ không có relationship gì mấy. Phân tích dừng lại ở mức cơ bản, nên mình nghĩ Power BI connect vô Database là okie, sau này data nhiều lên rồi sẽ quất cái Analysis Service

Update tí là khi xài Scrapy mình thấy nó cung cấp khá đầy đủ đồ chơi, từ crawl, đọc dữ liệu, cả ghi dữ liệu vào database. Nghe nói có Scrapyd là server để quản lý các tác vụ nữa, mình đang test, nếu làm được thì cực kỳ phù hợp
__________________
Nothing to sign
Reply With Quote
  #50  
Old 20-02-2020, 14:51
ez-aqua's Avatar
ez-aqua ez-aqua is offline
Member
Join Date: 11-2013
Posts: 54
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by cauthungoaihang View Post
Thanks thím thớt vì các thông tin rất hữu ích

Mình xài Selenium là vì một số site nó chạy JavaScript, vô site, bấm nút 1 lúc nó mới chạy và lấy được HTML, nếu chỉ send request thì không lấy được gì cả. Mình thấy selenium cũng chậm và bất tiện nên đang học Scrapy để chuyển qua.

Vụ xài server VPS là vì hồi trước mình có xài rồi nên có tí kinh nghiệm, hiện tại thì dựng database cũng tàm tạm rồi. SQL trên cloud nghe nói nhiều nhưng mình chưa thử bao giờ, để mai mốt thử xem, nếu giá hợp lý thì triển luôn

Data từ rất nhiều nguồn, nhưng mà size thì nhỏ (nhiều nguồn mỗi ngày chỉ phát sinh 1 dòng ^^), và chủ yếu là thêm vào dữ liệu sẵn có chứ không xóa dữ liệu cũ đi. Các dữ liệu chủ yếu liên quan về mặt thời gian và địa lý, chứ không có relationship gì mấy. Phân tích dừng lại ở mức cơ bản, nên mình nghĩ Power BI connect vô Database là okie, sau này data nhiều lên rồi sẽ quất cái Analysis Service

Update tí là khi xài Scrapy mình thấy nó cung cấp khá đầy đủ đồ chơi, từ crawl, đọc dữ liệu, cả ghi dữ liệu vào database. Nghe nói có Scrapyd là server để quản lý các tác vụ nữa, mình đang test, nếu làm được thì cực kỳ phù hợp
Nói chung mình ko rành vụ crawl web data, nhưng mà nếu mà do javascript phải bấm thì web mới generate data, thì bạn thử tìm cách bắt luôn được cái địa chỉ API của nó rồi request trực tiếp vào cái API đó xem. Chứ selenium thấy cực quá.

Nếu mà bạn append only thì quá sướng luôn. Data mà lớn, append-only, có mốc thời gian rõ ràng thì cứ columnstore, partition mà dã. Chứ như mình do hầu hết các bảng fact quan trọng đều sẽ ở dạng Accumulating snapshot. Bên mình làm là gia công xử lý thông tin cho người ta, mỗi thực thể đi vào hệ thống của mình sẽ phải trải qua các bước xử lý từ lúc nhận cho đến khi kết thúc, và người ta muốn phân tích xem cái thực thể đó phải trải qua những bước nào và mất bao lâu. Đồng thời không có rule chốt sổ nên bọn chúng đều có thể đội mồ sống dậy bất kì lúc nào, kể cả những thực thể từ 1 năm trước. Nói chung update điên cuồng.

Về vụ modeling, mình thấy cái việc chọn Star-Schema hay flat-table sẽ chủ yếu nằm ở việc bạn có update hay không và bạn có muốn tìm "thằng nào không có hay không". VD nếu bạn làm flat table, bạn sẽ không bao giờ trả lời được câu hỏi kiểu "tìm thằng nào không có đơn hàng nào" (vì ko có đơn nào thì không bao giờ cái tên đó xuất hiện được trong bảng fact). Với việc update, nếu bạn có star-schema thì update đơn giản hơn rất nhiều. Hay bạn muốn chơi mix SCD 1, 2, kiểu field thì SCD 1 (VD như tên công ty) nhưng field khác lại là SCD2 (Thành phố công ty đó đóng quân, có thể tháng này nó đổi trụ sở tháng khác nó đổi trụ sở)... thì mình nghĩ Star-schema tốt hơn nhiều. Có thể sẽ cần đến snow-flake nếu bạn có vấn đề với việc tìm những thằng không có, đánh đổi thì sẽ là performance. Bạn càng phải join nhiều thì performance càng bị ảnh hưởng.

Bạn thử xem fact của data của bạn là dạng additive hay là periodic snapshot. Additive nghĩ là bạn dùng hàm sum thoải mái, aggregate sao cũng được. (Ví dụ đơn hàng 1 ngày 1 Giá 10$, đơn hàng 2 ngày 2 giá 20$ thì tổng số tiền hàng tháng đó là 30$.). Còn Semi additive bạn không aggregate trên dimension thời gian được. (VD ngày 1 trong kho cam dư 10kg, táo dư 20 kg. ngày 2 cam dư 20kg táo dư 10 kg). Bạn có thể aggregate rằng ngày 1 tôi dư tổng cộng 30 kg cả cam lẫn táo, nhưng không được tính tổng số cam dư trong tháng là 30kg (NGày 1 cam 10, + ngày 2 cam 20). Mình thấy bạn ghi dữ liệu địa lí thì mình e rất có khả năng dính vào dạng periodic snapshot này. (VD nhiệt độ từng vùng)

Nói chung việc bạn phải đối mặt với dữ liệu rất nhiều nguồn + nhỏ nhưng lại append-only thì đó cũng là một kiểu khó khăn và thuận lợi. Còn như bên mình thì ít nguồn nhưng dữ liệu trong bản thân những nguồn đó rất hỗn loạn, phải handle update và monitor update rất nặng, đó cũng là một kiểu khó khăn và thuận lợi. Mình thấy rút cục thì data lớn hay nhỏ nó cũng chẳng quan trọng nữa. Vì lớn nó đều có vấn đề của lớn và nhỏ cũng đều có vấn đề của nhỏ. Mà đôi khi lớn còn dễ vì ít nhất khi mình tìm tài liệu, mình cảm thấy tìm các solution đối phó với data lớn dễ hơn là data nhỏ.

Mà cho mình hỏi bạn chơi cái Power BI là bạn đang chơi bảng phẳng hay có nhiều table link với nhau. Vì mình cảm thấy như những gì bạn nói thì có vẻ bạn đang dùng Power BI report bảng phẳng?
1355308

Last edited by ez-aqua; 20-02-2020 at 14:55.
Reply With Quote
Reply

« Previous Thread | Next Thread »
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT +7. The time now is 07:29.