thắc mắc Hỏi về data engineer?

itachicitus · 25/2/23

zhenyuan0502 đã nói:
Còn nếu bạn không theo chuẩn, muốn mask nó ở tầng ETL thì đó là idea của bạn thôi, nếu bạn thấy nó vô hại nếu bị leak ra ở giữa process

Dài hạn thì phải đổi sang con khác, bất kỳ SE nào cũng sẽ nhìn ra như vậy, hoặc nhìn ra và không buồn làm do ko có động lực từ Director.

Cái này không đúng... Vì bài toán đề bài không có nói đến việc thanh toán. Cái thứ hai đang nói trường hợp làm CDC cho toàn hệ thống, ép chung 1 giải pháp mà không nhìn data model thì sẽ không có cách nào giải quyết được, kể cả có dùng oracle đi nữa vì cơ chế cài đặt cdc của tụi nó giống nhau.

VD Azure Data Lake Gen 2 thì mục đích chính chỉ là Data Staging nên dùng Cool là đã dư xăng. từ 150GB + 500GB, mỗi ngày +2GB thì mỗi tháng tầm 10-20USD

Nếu để query thẳng trên lake thì phải để hot chứ không phải là cool. Chi phí lưu trữ thường nhỏ hơn rất nhiều so với chi phí scan dữ liệu.

zhenyuan0502 · 25/2/23

itachicitus đã nói:
Cái này không đúng... Vì bài toán đề bài không có nói đến việc thanh toán. Cái thứ hai đang nói trường hợp làm CDC cho toàn hệ thống, ép chung 1 giải pháp mà không nhìn data model thì sẽ không có cách nào giải quyết được, kể cả có dùng oracle đi nữa vì cơ chế cài đặt cdc của tụi nó giống nhau.

Yes, tôi cũng không thấy cần phải mask data từ OLTP mysql, nó chả có dữ liệu cá nhân nào

mysql cho hệ thống hàng hoá, kho bãi, nhập xuất tồn, .... có tầm 200 tables, total size khoảng 150GB, table to nhất là 100GB

Nên không cần thiết phải nghĩ đến case masking data. Cũng là lý do tại sao core bank không bao giờ sử dụng mysql nếu data nó quá sensitive.

itachicitus đã nói:
Nếu để query thẳng trên lake thì phải để hot chứ không phải là cool. Chi phí lưu trữ thường nhỏ hơn rất nhiều so với chi phí scan dữ liệu.

Nếu không đòi hỏi stream reader nhiều quá thì cứ để cool, tội gì, scale được không lo lắm.

itachicitus · 25/2/23

zhenyuan0502 đã nói:
Yes, tôi cũng không thấy cần phải mask data từ OLTP mysql, nó chả có dữ liệu cá nhân nào

mongodb cho hệ thống bán hàng, quản lý cửa hàng, nhân sự, tồn kho cửa hàng, khách hàng, ... tầm 100 collection. Total size 500GB, col to nhất 300GB

Thông tin khách hàng ở đây nè. Cái này ở VN không chú trọng chứ nếu đã từng làm cho thị trường Âu Mỹ thì thông tin cá nhân không được phép đưa vào hệ thống report nơi mà nó có thể truy xuất dễ dàng không qua sự cho phép của khách hàng. Dữ liệu phải được anonymize lại, từ tên ngày sinh nơi ở SDT.

Nếu không đòi hỏi stream reader nhiều quá thì cứ để cool, tội gì, scale được không lo lắm.

Vậy nên mới nói DE phải hiểu yêu cầu của biz report. Nếu biz request 1 ngày 1 lần rồi cache thì nó sẽ ko có vấn đề gì, nhưng nếu nó là interactive queries thì performance sẽ cực kỳ tệ.

zhenyuan0502 · 25/2/23

itachicitus đã nói:
Thông tin khách hàng ở đây nè. Cái này ở VN không chú trọng chứ nếu đã từng làm cho thị trường Âu Mỹ thì thông tin cá nhân không được phép đưa vào hệ thống report nơi mà nó có thể truy xuất dễ dàng không qua sự cho phép của khách hàng. Dữ liệu phải được anonymize lại, từ tên ngày sinh nơi ở SDT.

Tôi consultant cho Enterprise Commercial ở VN thì đều bắt buộc phải chặt ở tầng DB, họ cũng rất aware điều đó chứ không có vụ nào mà đưa ra ngoài cả đâu, bài bản là phải thế. Còn đã ghi log có sensitive data thì phải encrypt và đưa vào một nơi khác, chứ không phải Lake. Gì chứ cái này tôi thấy DBA họ còn quan tâm hơn DE và chủ động hỏi luôn chứ chẳng cần DE nhắc cả, nhiệm vụ của họ.

Còn MongoDB có thể setup policy field luôn cả nhé.

itachicitus đã nói:
Vậy nên mới nói DE phải hiểu yêu cầu của biz report. Nếu biz request 1 ngày 1 lần rồi cache thì nó sẽ ko có vấn đề gì, nhưng nếu nó là interactive queries thì performance sẽ cực kỳ tệ.

query liên tục thì phải có cách đưa vào temp, mỗi ngày reset report một lần, tóm lại có cách để tối ưu cả. Bạn xem youtube bạn thấy nó nhảy số view như realtime không? Nhưng có khi qua ngày hôm sau nó recalculate lại thì số đó bị thay đổi. Task của DE thuần về optimize những cái này hơn là focus quá nhiều vào những task mà phía DA có thể làm đc, tất nhiên DE nó hiểu business là phải có, nhưng chỉ involve khi cần.

itachicitus · 25/2/23

zhenyuan0502 đã nói:
Còn MongoDB có thể setup policy field luôn cả nhé

Mongodb change stream ko có policy…. Nãy giờ mình nói với bác rồi, mình đang nói cdc chứ ko nói batch.

query liên tục thì phải có cách đưa vào temp

Interactive query chứ ko phải query 1 câu liên tục. Interactive dashboard cho phép người dùng filter và aggregation trên nhiều dimension. Cái này phải xử lý riêng chứ ko chỉ quăng cho DA là họ biết xử lý.

zhenyuan0502 · 25/2/23

itachicitus đã nói:
Mongodb change stream ko có policy…. Nãy giờ mình nói với bác rồi, mình đang nói cdc chứ ko nói batch.

Bạn đọc doc hay làm qua với mongo chưa? Aggregation Pipeline nó mask trước khi feed ra ngoài db bình thường, stream realtime nhé chứ không chỉ batch đâu.

itachicitus đã nói:
Interactive query chứ ko phải query 1 câu liên tục. Interactive dashboard cho phép người dùng filter và aggregation trên nhiều dimension. Cái này phải xử lý riêng chứ ko chỉ quăng cho DA là họ biết xử lý.

Việc interactive dashboard là thực hiện query liên tục cho mỗi lần tương tác, chiến lược làm sao cho UI/UX mượt mà, setup caching trong BI mấy bạn DA quá dư sức. Cần thiết thì chỉ help dựng con Redis rồi chỉ các bạn thao tác, làm sample một vài thôi chứ.

itachicitus · 25/2/23

zhenyuan0502 đã nói:
Bạn đọc doc hay làm qua với mongo chưa? Aggregation Pipeline nó mask trước khi feed ra ngoài db bình thường, stream realtime nhé chứ không chỉ batch đâu.

Việc interactive dashboard là thực hiện query liên tục cho mỗi lần tương tác, chiến lược làm sao cho UI/UX mượt mà, setup caching trong BI mấy bạn DA quá dư sức. Cần thiết thì chỉ help dựng con Redis rồi chỉ các bạn thao tác, làm sample một vài thôi chứ.

Vậy bây giờ DE quản lý 2 pipelines độc lập trong 2 codebase... Trong khi bản thân tel framework hỗ trợ xử lý chuyện đó...

Cái không hợp lý. Cách xử lý ko phải là cache. Mà thôi cái đó nó liên quan tới data modeling rồi nên mình ko bàn nữa.

the_ruler · 1/3/23

Hai bác này đi detail khi requirements mới cơ bản rồi hehe.
Ae làm thì đều hiểu là để ra được arch phù hợp cần cả tháng đi thu thập yêu cầu, đánh giá hệ thống, dữ liệu, budget etc. mà.
Cái này chỉ là 1 câu hỏi ở level phỏng vấn thôi, ra được 1 cái arch dạng PoC thôi. Mà ngay cả trong lúc phỏng vấn thì cũng cần ngồi trao đổi để clear thêm yêu cầu và chỉnh sửa arch cho phù hợp mà

trinhcechung · 1/3/23

Xin thực tập DA khó vl :

Công nhân data · 6/3/23

Bên DE này thì có thể làm những side projects như thế nào để cho vào CV nhỉ. Em search youtube chủ yếu là extract data từ API xong load vào S3 thôi @@

BanhXe0_ · 7/3/23

Các thím cho mình hỏi là khi DE debug thì các bác clean data như nào nhỉ ? em gặp rắc rối ở chổ là :
1.Khi dev em muốn xóa data kết quả để chạy lại (dev cycle : run etl-> clean db (*) -> modify code -> run etl -> ...) thì ở bước clean db thì nó gặp phải 1 vấn đề là : delete vài GB file parquet nó tốn quá nhìu time , vì quá nhìu parquet nhỏ(vài mb 1 file).
Em thường làm là bỏ luôn storage đó để delete sau , tạo storage khác (vidu trên s3 là em bỏ luôn bucket đó ,tạo bucket mới ,s3 rẻ mờ nên xài tẹt ga )

2. Vì vấn đề như trên : nên khi trên prod mà bị gì là tốn time chạy lại ETL từ đầu (layer bị lỗi -1) => các bác thiên về repair data hay xóa chạy từ đầu ?

the_ruler · 7/3/23

Công nhân data đã nói:
Bên DE này thì có thể làm những side projects như thế nào để cho vào CV nhỉ. Em search youtube chủ yếu là extract data từ API xong load vào S3 thôi @@

1. Ingestion data

Migrate một số data từ RDBMS (1st party) qua DWH/ Lake/ Lakehouse để phân tích
Kéo data từ các 2sd/3rd party data về để merge, phân tích, làm giàu: ví dụ công ty dùng hệ thống HRM, finance trên base.vn; chạy campaign quảng cáo trên FB, google Ads thì kéo qua API/ files về.
Cần quản lý đống job kia, scheduler cho nó: cronjob/ airflow/ etc.

2. Transform data

Kéo về xong thì cần clear, merge, transform đống data kia để ra được các data avail cho phân tích: cái này gọi là data modeling + design data model.
Phân tích, modeling tiếp để ra được insight data

3. Visualization + active data

Cắm các công cụ BI vào chỗ data có insight kia để làm report
Đẩy các data đó sang các hệ thống khác.

Bài toán ví dụ:

Kéo data từ nhiều nguồn về: 1st, 2sd, 3rd party về Lake/ LH, DWH, merge dữ liệu lại để ra list customers với nhiều thông tin khác nhau của customers
Cắm BI tool để lọc ra list customers phù hợp để chạy campaign, lưu lại list đó xuống
Bắn list kia sang các công cụ chạy campaign để quảng cáo.

BanhXe0_ đã nói:
Các thím cho mình hỏi là khi DE debug thì các bác clean data như nào nhỉ ? em gặp rắc rối ở chổ là :
1.Khi dev em muốn xóa data kết quả để chạy lại (dev cycle : run etl-> clean db (*) -> modify code -> run etl -> ...) thì ở bước clean db thì nó gặp phải 1 vấn đề là : delete vài GB file parquet nó tốn quá nhìu time , vì quá nhìu parquet nhỏ(vài mb 1 file).
Em thường làm là bỏ luôn storage đó để delete sau , tạo storage khác (vidu trên s3 là em bỏ luôn bucket đó ,tạo bucket mới ,s3 rẻ mờ nên xài tẹt ga )

2. Vì vấn đề như trên : nên khi trên prod mà bị gì là tốn time chạy lại ETL từ đầu (layer bị lỗi -1) => các bác thiên về repair data hay xóa chạy từ đầu ?

Cái này lúc design E(T)L pipeline phải design cho data fault tolerance.
Ví dụ design với mỗi batch EL dù có chạy bao nhiêu lần với dữ liệu đó (dữ liệu source của batch đó không đổi) đi chăng nữa nó cũng không làm sai lệch kết quả cuối, kể cả batch đó có là stateful hay stateless. Hoặc là cần back-fill dữ liệu, có back-fill bao nhiêu lần cũng được.
Lúc đó batch nào bị lỗi thì re-run lại batch đó thôi, kết quả của batch đó không bị ảnh hưởng.

Hạn chế snapshoot/ full-refresh data với những data lớn. Chứ bảng vài GB mà lần éo nào kéo ETL cũng full-refresh thì oẳng à.

itachicitus · 7/3/23

BanhXe0_ đã nói:
Các thím cho mình hỏi là khi DE debug thì các bác clean data như nào nhỉ ? em gặp rắc rối ở chổ là :
1.Khi dev em muốn xóa data kết quả để chạy lại (dev cycle : run etl-> clean db (*) -> modify code -> run etl -> ...) thì ở bước clean db thì nó gặp phải 1 vấn đề là : delete vài GB file parquet nó tốn quá nhìu time , vì quá nhìu parquet nhỏ(vài mb 1 file).
Em thường làm là bỏ luôn storage đó để delete sau , tạo storage khác (vidu trên s3 là em bỏ luôn bucket đó ,tạo bucket mới ,s3 rẻ mờ nên xài tẹt ga )

2. Vì vấn đề như trên : nên khi trên prod mà bị gì là tốn time chạy lại ETL từ đầu (layer bị lỗi -1) => các bác thiên về repair data hay xóa chạy từ đầu ?

Tại sao nó nhiều file nhỏ nhỉ, bạn giải thích kỹ hơn được không?

Anh Ken · 7/3/23

BanhXe0_ đã nói:
Các thím cho mình hỏi là khi DE debug thì các bác clean data như nào nhỉ ? em gặp rắc rối ở chổ là :
1.Khi dev em muốn xóa data kết quả để chạy lại (dev cycle : run etl-> clean db (*) -> modify code -> run etl -> ...) thì ở bước clean db thì nó gặp phải 1 vấn đề là : delete vài GB file parquet nó tốn quá nhìu time , vì quá nhìu parquet nhỏ(vài mb 1 file).
Em thường làm là bỏ luôn storage đó để delete sau , tạo storage khác (vidu trên s3 là em bỏ luôn bucket đó ,tạo bucket mới ,s3 rẻ mờ nên xài tẹt ga )

2. Vì vấn đề như trên : nên khi trên prod mà bị gì là tốn time chạy lại ETL từ đầu (layer bị lỗi -1) => các bác thiên về repair data hay xóa chạy từ đầu ?

có nhiều project như bác ruler có nói. Ngoài ra trước em học 1 khoá của Udacity có thể có thể áp dụng như:

Từ 1 nguồn dữ liệu lớn trên kaggle như tỉ lệ di cư của dân Mỹ từ 1930 - 2020 và thêm 1 số dữ liệu khác như nhiệt độ các tiểu bang của US thì xây dựng 1 data warehouse theo star schema/snowflake shema. Qua đó làm sao tính toán đc 1 vài report về tình hình di dân và tăng giảm nhiệt độ qua các tiểu bang chẳng hạn
Xây dựng data streaming bằng kafka, bài toán như ingest data streaming từ wiki rồi load vào, từ đó có thể xuất đc report dạng realtime hay không.

via theNEXTvoz for iPhone

Anh Ken · 7/3/23

Anh Ken đã nói:
có nhiều project như bác ruler có nói. Ngoài ra trước em học 1 khoá của Udacity có thể có thể áp dụng như:

Từ 1 nguồn dữ liệu lớn trên kaggle như tỉ lệ di cư của dân Mỹ từ 1930 - 2020 và thêm 1 số dữ liệu khác như nhiệt độ các tiểu bang của US thì xây dựng 1 data warehouse theo star schema/snowflake shema. Qua đó làm sao tính toán đc 1 vài report về tình hình di dân và tăng giảm nhiệt độ qua các tiểu bang chẳng hạn

Xây dựng data streaming bằng kafka, bài toán như ingest data streaming từ wiki rồi load vào, từ đó có thể xuất đc report dạng realtime hay không.

via theNEXTvoz for iPhone

à sorry em định rep bác cong_nhan_data về side projects

via theNEXTvoz for iPhone

BanhXe0_ · 7/3/23

itachicitus đã nói:
Tại sao nó nhiều file nhỏ nhỉ, bạn giải thích kỹ hơn được không?

Source (s3, DB) -> custom crawl -> save về s3 (về cơ bản nó vẫn là file/data raw -) -> pyspark read in df -> df.save(....).partition_by(....) -> Tại thời điểm này vì ycau partition nên save vào s3 sẽ ra rất nhìu file parquet nhỏ (vidu nhu la theo year/month/date)
bucket-name-id:
/result
/2023
/02
/07
data-date-07-Feb-2023.snappi.part1.parquet
data-date-07-Feb-2023.snappi.part2.parquet
....
/2022

Thành ra với 1 raw data (mình cho là 1 table) ban đầu đầu vào chỉ vài csv historical by year- tổng lại chắc 10GB , thì sau khi save ra parquet thì nó ra hằng hà sa số file nhỏ (vì yeu cau data này là partition theo date) . Nói côm na là 1 date (07-feb-2023) sẽ có tầm 5 files parquet nhỏ -> 1 year = 365x5 files -> 10 năm sẽ tầm 18.000 files bé (dung lượng tổng hình như ko tới 10GB)
Với case của mình , có khi 50 table thì tổng files paquet nhỏ nó lớn , mình ko để ý tổng dung lượng nhưng tông số file mình xóa là >300.000 trên mỗi lần chạy .-> Cái phí phạm ở đây là thời gian chờ empty bucket rất lâu= > mình chỉ đành workaround là : auto tạo bucket mới trước mỗi lần chạy .

itachicitus · 7/3/23

BanhXe0_ đã nói:
Source (s3, DB) -> custom crawl -> save về s3 (về cơ bản nó vẫn là file/data raw -) -> pyspark read in df -> df.save(....).partition_by(....) -> Tại thời điểm này vì ycau partition nên save vào s3 sẽ ra rất nhìu file parquet nhỏ (vidu nhu la theo year/month/date)
bucket-name-id:
/result
/2023
/02
/07
data-date-07-Feb-2023.snappi.part1.parquet
data-date-07-Feb-2023.snappi.part2.parquet
....
/2022

Thành ra với 1 raw data (mình cho là 1 table) ban đầu đầu vào chỉ vài csv historical by year- tổng lại chắc 10GB , thì sau khi save ra parquet thì nó ra hằng hà sa số file nhỏ (vì yeu cau data này là partition theo date) . Nói côm na là 1 date (07-feb-2023) sẽ có tầm 5 files parquet nhỏ -> 1 year = 365x5 files -> 10 năm sẽ tầm 18.000 files bé (dung lượng tổng hình như ko tới 10GB)
Với case của mình , có khi 50 table thì tổng files paquet nhỏ nó lớn , mình ko để ý tổng dung lượng nhưng tông số file mình xóa là >300.000 trên mỗi lần chạy .-> Cái phí phạm ở đây là thời gian chờ empty bucket rất lâu= > mình chỉ đành workaround là : auto tạo bucket mới trước mỗi lần chạy .

Chỗ lưu file xuống mình nghĩ bác có thể đặt lại max number of records per file dc https://stackoverflow.com/questions/65912908/how-to-specify-file-size-using-repartition-in-spark, lúc đó 1 ngày có thể chỉ cần 1 - 2 files thôi.

namkt123 · 7/3/23

Who_Am_I_? đã nói:
mình nghĩ bro nên chơi cả leetcode hoặc hackerrank nữa để phát triển tư duy.
Và đi làm mn cũng không dùng nhiều đến những thứ cao siêu như khai phá dữ liệu đâu
Còn kho dữ liệu thì bạn biết trước thì rất tốt rồi , nhưng lý thuyết rất rất khác thực tế.
Nên mình chỉ nghĩ là cần đi thực tập để va vào bài toán thực tế.
Thực chiến thật nhiều sẽ đem lại cho bạn những kinh nghiệm hữu ích
Good luck bro

Em vừa inbox anh rồi chúc anh 1 ngày tốt lành

itachicitus · 7/3/23

BanhXe0_ đã nói:
, có khi 50 table thì tổng files paquet nhỏ nó lớn , mình ko để ý tổng dung lượng nhưng tông số file mình xóa là >300.000 trên mỗi lần chạy .-> Cái phí phạm ở đây là thời gian chờ empty bucket rất lâu= > mình chỉ đành workaround là : auto tạo bucket mới trước mỗi lần chạy .

còn vụ này chắc bác phải thiết kế lại, có lý do gì mà mỗi lần chạy lại phải chạy tất cả 50 bảng vậy nhỉ?

BanhXe0_ · 7/3/23

itachicitus đã nói:
còn vụ này chắc bác phải thiết kế lại, có lý do gì mà mỗi lần chạy lại phải chạy tất cả 50 bảng vậy nhỉ?

Khi dev hay debug đấy bác:

thắc mắc Hỏi về data engineer?

Senior Member

Đã tốn tiền

Senior Member

Đã tốn tiền

Senior Member

Đã tốn tiền

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Đã tốn tiền

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Đã tốn tiền

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này