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

Công việc thường làm về phân tích dữ liệu bạn đang làm tại tổ chức bạn, ...có giống những nơi khác làm không?

Công việc thường làm về phân tích dữ liệu bạn đang làm tại tổ chức bạn, ...có giống những nơi khác làm không?

by Admin Dathoc -
Number of replies: 0

#koolj_dataengineering

#sql

#elt

#etl

#datawarehouse

#datacrawling


Mình thấy gần đây một số bạn ĐANG LÀM NGHỀ PHÂN TÍCH DỮ LIỆU, hoặc chuẩn bị GIA NHẬP LÀNG PHÂN TÍCH DỮ LIỆU, mong muốn có cái nhìn đầy đủ hơn về 3 ý:

- Công việc thường làm về phân tích dữ liệu bạn đang làm tại tổ chức bạn, ...có giống những nơi khác làm không

- Công việc tôi đang muốn chuyển đổi sang làm Phân tích dữ liệu từ: lập trình viên, nhân viên sale, nhân viên từ các ngành khác... vậy tôi cần chuẩn bị những gì.

- Thời gian học SQL  hay những kiến thức về SQL chiếm bao nhiêu % những cái cần phải học, phải làm để làm tốt nghề: Phân tích dữ liệu.


Vậy trên quan điểm cá nhân, xin chia sẻ trải nghiệm và giải đáp một số thắc mắc trên với nghề: Phân tích dữ liệu, Làm dữ liệu ...ít nhất qua trải nghiệm của cá nhân mình từng xử lý công việc về data các tổ chức.


0. Đầu tiên phải thống nhất một số khái niệm công việc và vai trò phạm vi (theo quan điểm cá nhân hiện ở Việt Nam) có liên quan tới nghề làm data, phân tích dữ liệu:

🎯 Nhân viên Data Engineering - DE: Gần như các tổ chức nhỏ và không chuyên nghiệp ở VN không quan tâm lắm vai trò này. Và cứ nghĩ thuê một bạn Data Analyst, BI, hay Data Scientist hay DevOps... là có thể làm tốt chức năng này. Xong ko phải thế, Data Engineering giúp các khâu sau trong Phân tích dữ liệu và làm dữ liệu: lấy data về lake, biến đổi data, phân bổ data vào data mart cần loại dạng data gì. Đôi khi vai trò này cũng làm luôn việc áp dụng thuật toán để dự đoán tín hiệu từ data; hay thiết kế luôn datawarehouse cho các bên khác; hoặc thiết kế visualize từ data.

🎯 Nhân viên Data Analyst, BI - DA: 99% các bạn làm data và phân tích dữ liệu ở VN và được thuê vào làm là chỉ chăm chăm vào: móc lấy data từ database đang chạy cho ứng dụng, hoặc database backup. Rồi dùng các phương pháp biến đổi qua SQL, qua python lại lưu lại vào bảng khác vào chính database đó, hoặc qua csv. Rồi lại dùng các phương tiện visualize, thuật toán lấy data ra và view, hoặc áp dụng thuật toán để đưa ra gợi ý cho trưởng phòng.

🎯 Nhân viên Data Scientist - DS: các bạn này thì chỉ có những công ty lớn, hoặc công ty có đầu tư mới thuê được. Các bạn này chuyên nghĩ ra các thuật toán hoặc xem xét biến đổi từ kết quả các thuật toán để tạo lại thuật toán tối ưu hơn. Đôi không liên quan gì tới việc có được dữ liệu. Và họ rất cần ai đó, team khác chuẩn bị cho họ dữ liệu để áp dụng thử các thuật toán của họ. Xong vì sếp chưa thuê được ai, nên họ lại trở thành người thu thập và phân tích dữ liệu

🎯 Nhân viên Developer frontend, backend -DEV: Các nhân viên này...đôi khi chẳng liên quan gì tới việc làm data hay phân tích dữ liệu. Xong vì nhân viên thiếu, tiền chi phí sếp phân bổ không còn nữa. Nên chính họ lại trở thành át chủ bài để các sếp giao việc lấy data và làm phân tích data. Vậy họ phải học thêm các khái niệm mới từ Phân tích dữ liệu

🎯 Nhân viên DevOps: Chính xác là các bạn này không làm những công việc thuộc Phân tích dữ liệu. Xong vai trò của họ lại khá quan trọng vì đầu mối các tài nguyên ở đâu chạy cái gì gần như họ nắm hết: Vậy các phân tích viên phải nhờ họ để cấp quyền hoặc tài nguyên cho phép lưu chuyển data, hoặc cho phép vào đâu làm gì các tài nguyên của tổ chức. Cũng có liên đới tới nghề.

🎯 Nhân viên Sale, Marketing - SM: Cuối cùng là nhóm "chém gió", vì đa phần nghề của họ là quảng bá sản phẩm, nghĩ ra chiêu trò, chiến lược, để pr sp thương hiệu tốt nhất. Xong họ BẮT BUỘC phải gắn với những kết quả phân tích dữ liệu, để đưa ra chiến lược sale, marketing hợp lý hơn. Không thì họ sẽ "chém gió" "gây bão" toàn trượt, toàn sai. Nên họ vẫn liên quan tới chuỗi nghề: Phân tích dữ liệu, làm data. Và đôi khi trong nhiều tổ chức không có kinh phí, chính họ lại đảm nhiệm vai trò thu thập và phân tích dữ liệu.

.

.

Khi vai trò trên đã thống nhất, cần phải xem quy trình làm Phân tích dữ liệu, làm dữ liệu ...chung nhất là gì - theo cá nhân là như sau:

Bước 1: Lấy dữ liệu, crawl dữ liệu từ các bên, chu chuyển về bể dữ liệu (lake) theo batch hoặc stream

Bước 2: Làm sạch, biến đổi lần 1 ngay tại lúc lấy, hoặc trong quá trình chu chuyển

Bước 3: Thiết kế datawarehouse, biến đổi lần 2, để tạo ra những logic dữ liệu phục vụ từng phòng ban phân tích trên data từ datawarehouse

Bước 4: Visualize hoặc áp dụng thuật toán trên khối dữ liệu từ datawarehouse; nhận xét phù hợp; loại bỏ không phù hợp

Bước 5: Kết luận ra ý nghĩa từ dữ liệu; làm lại từ bước 2 nếu dữ liệu không phù hợp; bổ sung update thuật toán từ bước 4 nếu thuật toán không tối ưu; 

.

.

Khi vai trò trên đã thống nhất, quy trình đã thống nhất, dẫn tới những hiểu lầm hoặc quan điểm chưa đúng về nghề. Cụ thể:


1. Cần phải tách biệt quan điểm: Bạn là người LÀM DỮ LIỆU, LẤY DỮ LIỆU VÀ XỬ LÝ RIÊNG; chứ không phải LÀM TẮC NGHẼN và gây quá tải Hệ quản trị cơ sở dữ liệu đang chạy trên Ứng dụng của tổ chức:

- Vì sao lại như vậy: vì rất nhiều tổ chức vừa và nhỏ, họ chưa có kinh phí để bổ sung tài nguyên xử lý phân tích dữ liệu riêng. Họ chỉ có kinh phí thuê nhân viên về làm phân tích. Vậy bạn sẽ nhanh chóng làm các việc như: SQL ngay vào DB đang chạy của hệ thống (đang go production) hoặc một hệ backup, rồi câu query của bạn có thể là: SELECT ... WHERE... GROUPBY ... UNION...JOIN...; hoặc SELECT ..(SELECT).. để bạn có được data. Hành động này đơn thuần bạn làm tắc nghẽn hệ thống quản trị dữ liệu đang chạy.

- Vì sao, vì bạn đang học và làm nghề về OLAP - online analytical processing, hơi ngược với... các hệ thống đang chạy (Tiki, Sendo, Mua vé tàu, bán vé xem phim.... đang được thiết kế là OLTP). Các hệ quản trị DB dành cho OLTP - online transaction processing, họ - kiến trúc sư hệ thống- đã nghĩ nát óc để nó đc transaction nhanh nhất có thể: điển hình là những csld bảng quan hệ; các tên tuổi lớn về db server như: MS SQL, Oracle, ... sẽ có thể không có đối thủ để làm các úng dụng OLTP.

- Vậy có thể bạn hỏi: về trh database: Nếu ko query vào thì làm sao có đc data. Rất nhiều cách khác mà bạn ko làm tắc nghẽn: chunk data sang một nơi khác và bạn tha hồ chọc ngoáy. Hoặc chỉ query những giờ ...ngoài giờ, hoặc không cao điểm. Sau đó bạn dùng mapreduce dataframe spark, nó sẽ nhanh gấp 40 -100 lần phương pháp bạn đang biến đổi bằng SQL

- Chưa hết, data đâu chỉ có trên database, mà có nhiều nơi khác các các xử lý khác để có được: thông tin tài nguyên hệ thống, data file log, crawl trên web, cắt ảnh trên livestream camera, thu âm sound; scan document để lấy text.... Xong nên tìm cách móc vào và không gây tắc nghẽn hệ đang có, ví dụ:

- Data là thông tin máy, tài nguyên (ổ cứng, ram, cpu), data file log (vào ra id, số click, duyệt, truy cập...) bạn nên sủ dụng filebeat để đưa thông tin sang elasticsearch lưu cho dễ search. Từ khoá là ELK với filebeat. Hoặc Nifi.

- Data là ảnh, sound, bạn không nên chọc trực tiếp vào stream. Có thể camera đã quá tải. Phổ thông bây giờ hệ thống cam nào cũng có phần cgi http để nó stream ảnh ra sau mỗt 200ms, bạn có thể từ đó lấy data ảnh mô phỏng như clip hơn là trực tiếp rtsp. Sound tương tự, trích xuất blob lưu về local file

- Data bề mặt web, có rất nhiều công cụ để lấy nó hiệu quả: webdriver là một lựa chọn

- Data từ DB, tuỳ từng loại: nên là chunk sang parquet, hoặc sqoop stream một DB tương tự khác.

.

.

2. Cần phải biết từng dạng loại dữ liệu nào phù hợp với kiểu phân tích tìm ý nghĩa nào từ dữ liệu.

- Ở đây muốn nói, khi bạn có data và làm sạch, bạn cũng ko rõ là loại data nào thì phù hợp với thuật toán phân tích nào.

- Với loại data dạng 01, yes/no tức là binary chỉ có 2 lựa chọn: nên sử dụng các thuật toán phân tích: logistic regression, svm, bayes, knn

- Với loại data dạng category: hạng 1, hạng 2, hạng 3; phân loại A, B, C.... nên dụng các thuật toán phân tích: decision tree, knn, svm, random forest, mạng nơ ron

- Với loại data dạng số liên tục, nên dùng: linear regression, cart, time series, mạng nơ ron

- Với loại data dạng ảnh, âm thanh, cần convert, biến đổi map sang những phần khung dữ liệu nhỏ hơn, đoạn nhỏ hơn...dùng mạng nơ ron để phân tích


3. Cần phải biết các công cụ tối ưu cho bước, công việc step đang làm. Cần gợi ý cho các trưởng phòng hiểu các so sánh về tốc độ xử lý khi chỉ có ngần ấy tài nguyên RAM, CPU, thì một số tool công nghệ sẽ làm hiệu quả hơn trong một vài khâu, hơn so với tool công nghệ đang có

- Ví dụ có nhiều bài viết trên internet cho bạn ưu nhược của việc xử lý chu chuyển stream data qua các công nghệ: Sqoop, Flume, Kafka, Flink, Heron, RabbitMQ, MQTT

- Ví dụ có nhiều demo clip YouTube đưa cho bạn tốc độ xử lý biến đổi data của SQL so với Mapreduce HDFS, và Mapreduce Spark 

- Ví dụ có nhiều luận điểm trên medium cho bạn biết khi nào bạn dùng loại dạng db nào làm bể chứa để tiện phân tích dữ liệu: CSV, Kudu, Avro, Parquet, HBase, Hive...

- Càng có nhiều git, kaggle... cho bạn cũng chỉ là nhận diện khuôn mặt, hay lọc đếm đối tượng, nhưng nhiều thuật giải khác nhau.

Quan trọng bạn chọn cái gì cho tối ưu step bạn đang làm, phù hợp với cơ sở hạ tầng bạn đang có.

.

.

4. Cần phải biết lập trình ứng dụng: Bạn tìm Ý NGHĨA từ dữ liệu; và SHOW CHO NGƯỜI KHÁC XEM. Vậy bạn cần biết viết một ứng dụng phần mềm hoàn chỉnh; hoặc bạn phải biết sử dụng thành thạo những tool SHOW Ý NGHĨA từ dữ liệu. Đó mới là cái cuối cùng Sếp cần bạn.

- Chính xác các công ty vừa và nhỏ không đủ chi phí để làm một ứng dụng hoàn thiện. Nên đôi khi chính phân tích viên sẽ phải hoàn thiện toàn bộ một ứng dụng hoàn chỉnh để nêu ý nghĩa từ dữ liệu: thu thập data, viết api gọi nhận, viết frontend view, viết api thuật toán xử lý, đưa kết quả trả về... đâm ra là gánh nặng với phân tích viên. Nhưng sự thực là thế.

- Vậy phân tích viên trong hoàn cảnh này bạn sẽ phải bám vào tool đang có và mở rộng hơn, cần biết lập trình để tạo ra ứng dụng trình bày thành quả của mình phân tích. Tất nhiên ở đây không bảo ép buộc bạn phải giỏi các việc trên; xong xu thế bạn trong tương lai nên biết. 


5. Cần phải đổi mới tư duy đào bới dữ liệu: Bạn là người hỗ trợ các giám đốc, trưởng phòng tìm hiểu Ý NGHĨA từ dữ liệu họ, tổ chức có; vậy nếu họ có dữ liệu, họ đã có thể tự tổng hợp ra được rồi; vậy bạn ở đó làm gì?

- Nhiều tổ chức, các luồng dữ liệu qua lại, nếu bạn nắm bắt nhanh, bạn sẽ quản trị được: thu thập phân tích, làm báo cáo. Nếu không có bạn các sếp cũng sẽ có nhiều cách để biết được tổng quan, hay biết được dự đoán được nguyên nhân có những xu thế này xu thế kia.

- Vậy phải chăng bạn ở đó hơi thừa??? Không, bạn đứng đó để: quản trị các luông data, giám sát các luồng data, và áp dụng thuật toán cho các dự đoán có cơ sở. Tim ý nghĩa từ data rõ ràng, và thuyết phục hơn dự đoán từ sếp.

- Bạn đứng đó, để thu thập thêm data những data mà sếp, tổ chức chưa có. Bạn làm cách nào chưa rõ. Xong đó mới là điều sếp cần bạn.


6. Cần phải tránh dựa vào cloud: Thuật toán tìm ý nghĩa từ dữ liệu, cũng như tool công cụ visualize dữ liệu MIỄN PHÍ...rất rất gần bạn. Các thuật toán cỡ 50 năm rồi. Bạn chỉ cần dùng nó là đủ. Không cần nghĩ thêm cái mới. Cloud là một phương tiện tiện ích mới dễ cho startup. Bạn không nên dựa vào cloud để thui chột, lu mờ đi kiến thức xử lý dữ liệu vì...cloud họ sẽ làm tắt, làm nhanh...nhiều khâu mà bạn không rõ. Và đôi khi cloud là nơi đánh cắp dữ liệu từ tổ chức bạn.

- Có thể các công cụ Google, Azure, hay AWS đã làm cho bạn cảm thấy rất tiện lợi và ...ko cần suy nghĩ hơn là: thuê một bạn biết bật tắt tool của cloud là ok rồi. Xong bạn quên rằng, dữ liệu bạn càng nhiều thì năng lượng tính toán của cloud càng tốn. Và khi đó bạn sẽ phải quay lại giải pháp on-premise, tức là thuê máy và cơ sở của mình và làm riêng.

- Thêm nữa để data trên cloud, có nghĩa là bạn đang để một nơi khác, không phải trong kho nhà bạn. Vậy bạn cần thuê private network cloud cho an toàn, hoặc private server. Hơn là bạn chỉ thuê dịch vụ hoặc chỗ chứa, như thế rất nguy hiểm.

.

.

7. Cần phân biệt rõ: DATABASE là chứa data và logic phục vụ cho XỬ LÝ TỐI ƯU NHẤT cho ứng dụng; còn DATAWAREHOUSE chứa data và logic cho PHÂN TÍCH NGHIỆP VỤ.

- Một số bạn có thể comment là: Ơ thế em có data và database - DB đang chạy của hệ thống ứng dụng rồi, tụi e sẽ lấy data sql từ đó và ...cần gì tới warehouse, tới mart? Không đúng các bạn ạ. Khi bạn sử dụng database cái đang có của ứng dụng, tổ chức; cái đang vận hành, đang chạy trơn tru.... làm nơi lấy dữ liệu, rồi biến đổi dữ liệu trên sql, rồi mong muốn đầu ra là kèm thuật toán hay visualize đầu ra trực tiếp trên data đó, thì đơn thuần bạn đang làm tắc nghẽn tài nguyên vận hành của database cái vốn để cho ứng dụng; chứ không phải mục tiêu lấy data để phân tích. Thêm nữa, database của ứng dụng không thể bao phủ hết các đòi hỏi data và data format cho các thuật toán và lựa chọn visualize của bạn. Điều đó sẽ làm các câu SQL của các bạn bị phức tạp lên; điều đó làm việc tài nguyên năng lượng (vốn có để phục vụ ứng dụng) lại bỏ ra để tính toán để có được data các bạn mong muốn. Sẽ gây tắc nghẽn, hoặc đó là cách làm không hiệu quả!

- Vậy để hiệu quả hơn việc chuẩn bị data cho visualize cho áp dụng thuật toán; người ta nghĩ ra datawarehouse - DW; một số bạn đã và đang làm phân tích dữ liệu chưa rõ có gì khác giữa DW và DB. Một ví dụ là:

+ Nếu bạn cần data và logic DB để phục vụ ứng dụng thì nó sẽ thế này: bảng đơn hàng (gồm mã hàng, chi nhánh, ai mua, số lượng, thành tiền, thời gian mua, thanh toán...), bảng người mua (gồm mauser, tên người mua, email, số thẻ, đơn hàng, ngày mua ....) và bảng hàng hoá (gồm mã hàng, tên hàng, xuất xứ, ngày nhập, đáo hạn...) và bạn xử lý logic cho vào ra ứng dụng Bán hàng online

+ Nếu bạn cần data để phân tích: Tính phân bổ loại hàng bán được và doanh số, dự đoán số hàng bán chạy trong tháng tới từ data 3 tháng đã qua???: vậy khi đó các phân tích viên sẽ cần bạn hỗ trợ làm data và phân bổ vào DW  hoặc datamart (là một dạng khác của DB) gồm các bảng ví dụ thế này: bảng fact (gồm: tổng tiền, id loại hàng, id chi nhánh, thứ ngày trong tuần ), bảng dimension1 (gồm id chi nhánh, tên chi nhánh, địa chỉ, khoảng cách tới trung tâm), bảng dimension2 (gồm id hàng, tên hàng, nguồn từ đâu, ngày nhập, số ngày hết hạn). 

Do vậy, DB trên chỉ dành những thông tin phục vụ ứng dụng; bên cạnh đó DW lại có những thông tin khác, nhiều chiều hơn; cần được cung cấp để tổng hợp giúp cho người xử lý phân tích. Và với DW này bạn hoàn toàn có thể dùng timeseries hoặc logistic regression để dự đoán loại hàng nào tháng tiếp theo sẽ được bán được nhanh hết nếu có các dữ liệu quá khứ. Với DW này người làm phân tích sẽ thấy tiện hơn khi query.

Do vậy, các bạn phân tích vẫn cần một ai đó để làm công việc chuẩn bị data, đưa data vào DW, và mình từ DW đó sql data ra, để visualize hoặc áp dụng thuật toán. Và trong nhiều tổ chức, vì không đủ kinh phí, nên chính các bạn phân tích viên sẽ phải làm công việc chuẩn bị data này.

.

.

8. Một Datawarehouse - DW như thế nào được gọi là TỐT cho bạn lấy dữ liệu từ đó để phân tích, để visualize?

- Một DW được gọi là TỐT và hiệu quả, khi ngay ở trên đó đã có những tổng hợp dữ liệu; ngay ở trên đó đã bóc tách dữ liệu theo không gian và thời gian; ở trên đó đã gộp những thông tin nội tại và ảnh hưởng bên ngoài xung quanh của thông tin cần phân tích

- Một DW được gọi là TỐT và hiệu quả khi bạn dùng SQL query hoặc mapreduce vào đó chỉ cần 1 Select và 1 Where là đủ. Vì một lý do nào đó bạn đụng tới JOIN, AGGR, hay UNION hay COUNT hay SELECT(SELECT) thì DW đó là DW không hiệu quả ... điều đó có nghĩa là bạn NÊN quay lại xử lý từ DB thì tốt hơn. Đã có DW là đã có một logic data được tổng hợp rồi, bóc tách data cho mình rồi. Còn nếu DW chưa làm được điều đó. Nên bỏ đi và xây một DW mới.

- Một DW được gọi là TỐT và thông thường nó cần query gộp và duyệt toàn record nhanh, cũng như gộp nhiều bản ghi càng nhanh càng tốt: Vậy điều này chỉ có thể làm khi bạn dùng DW cới thiết kế database dạng cột, hàng, key value. Còn nếu các bạn sử dụng database bảng quan hệ, nó sẽ làm chậm và giảm đi quá trình duyệt dữ liệu khi data bạn lớn (từ 100gb tới 2 tb). Hay nói cách khách khi dữ liệu phân tích không quá lớn thì khi đó DW dạng bảng quan hệ là ok. Còn khi data lớn, nhiều, khối lượng dữ liệu hàng TB khi đó cần các giải pháp database cột, hàng, hoăc keyvalue. Kết hợp với tính toán query phi tập trung - distributed query: hdfs, couchbase, presto, spark mapreduce 

.

.

9. Cần phải học Đạo đức nghề trong CNTT: vì bạn đang nắm trong tay kho vàng dữ liệu số. Bạn đang đứng trên dải mong manh giữa anh công nhân và tên tội phạm. Cần sáng suốt để lựa chọn!

10. Lưu ý về Hợp đồng, điều khoản - các bạn sinh viên mới, nhân viên vào nghề, dễ bị loè: Ở VN gần đây, 2-3 năm trở lại đây các startup ít tiền toàn có kiểu việc kỹ theo hợp đồng thế này:
- Họ khi ký hợp đồng sẽ KHÔNG nói về việc: cắt giảm giờ làm, dẫn tới cắt giảm lương, thu nhập; hoặc bắt nhân viên chịu nợ lương vì lý do này kia.
- Họ khi ký hợp đồng rất niềm nở và không nói rõ: em sẽ phải làm gì, hoặc họ giao việc e gì; mà họ hay ghi: bên B phải hoàn thành các công việc được giao; Bên A sẽ bổ sung và giao các công việc theo chỉ đạo. Nếu mà ghi như thế: thì họ bảo e (là kỹ thuật phân tích data) đi bắt gôn bóng cũng hay. Họ bảo em (dev lập trình viên) đi làm tester cũng hay. Họ bảo em (nhân viên AI) đi phát triển module backend login hộ anh...cũng hay. Lúc đó bạn sẽ cúi đầu nhận thôi. Không làm thì... chắc là phải biến!
- Họ khi ký hợp đồng: sẽ không nói hoặc chưa quy định: nếu bên A (công ty thuê) phá sản, tức là không có khả năng chi trả lương, thì đền bù bên B (là bạn) như thế nào.

Vậy anh gợi ý e cần làm rõ với cái bên định tuyển em là:
- Tôi ký với công ty là lương hàng năm: vd: 240 triệu. Vậy chia trung bình mỗi tháng là 20tr. Và là lương sau thuế. Đây là gọi là mức lương ký hợp đồng -MLKHD
- Tôi CẦN và BẮT BUỘC bên công ty trả lương MLKHD vào cuối tháng lao động. 1 tháng lao động trung bình 22-24 ngày công. Và
- Tổ chức không được phép nợ lương MLKHD
- Tổ chức không được phép giảm giờ làm và tiếp theo là giảm lương MLKHD như đã ghi.
- Tổ chức nếu khó khăn MLKHD, hay chuẩn bị phá sản,... cần thông báo trước 15 ngày.
- Tổ chức nếu 2 tháng liên tiếp không trả đủ mức lương MLKHD. Tôi xin phép nghỉ việc vì không đảm bảo MLKHD.
- Tôi cần ghi rõ các phạm vi và công việc theo chuyên môn X, Y ,Z. Nếu ngoài các chuyên môn, cần thương lượng với tôi, trước khi giao việc. Hoặc tôi có quyền dừng hợp đồng và đền bù lương tháng đang có khi chuyên môn BẮT tôi phải làm, tôi cho là không phù hợp.

.

.

Vậy đọc tới đây chắc các fans của group đã hiểu: thời gian 10% và phân bổ cho việc học SQL cũng như tầm quan trọng 10% của SQL trong quá trình Phân tích dữ liệu. Vì sao lại 10% vì xem xét tất cả các công việc trên, cái bạn cần học là:

+ Biến đổi dữ liệu trên các hàm thư viện dựng sẵn trên các ngôn ngữ python, java, scala

+ Biến đổi dữ liệu với spark mapreduce

+ Lưu chuyển dữ liệu với nifi, kafka...

+ Lưu dữ liệu xuống và đọc dữ liệu lên với  spark dataframe, redis, parquet, hdfs, qua impala, spark, pyspark

+ Học nguyên lý và cách dựng một datawarehouse, datamart

+ Học thêm n1ql, hql, cql ...hơn là sql

+ Học thuật toán cơ bản thống kê, thuật toán xử lý phân loại hình ảnh, âm thanh

+ Học định dạng dữ liệu, làm sạch dữ liệu

+ Học loại dữ liệu nào phân tích với thuật toán nào

+ Học cách đọc ý nghĩa từ kết quả sau khi chạy với thuật toán

+ Học visualize dữ liệu

+ Học dựng app để show visualize

+ Cuối cùng mới cần bạn: học SQL cơ bản.


Nhờ các fans của group bổ sung!

Gluk!