Chỉ cần “lỡ tay” google về việc học Data/AI, 10 phút sau Facebook của bạn sẽ dày đặc quảng cáo các khoá học với những câu từ hoa mỹ nhất: Ngành hot nhất, tốp thu nhập cao nhất, cơ hội việc làm rất nhiều, lương nghìn đô, nghề trending,…. Nghe mà sướng trợn mắt 🤣
Nhưng bạn nào trái ngành học Data Analytics ra đi xin việc sẽ biết cái khổ khi tìm đỏ mắt không ai tuyển, có offer thì lương chưa được 10 triệu. Lúc đó bạn sẽ trở về mặt đất ngay lập tức.
Data Analytics là một ngành thú vị, nhưng hiện nay, người mới học rất khó xin việc làm và nó không có màu hồng như các trung tâm hay kể. Vì mọi người đổ xô đi học data nên vài nơi bất chấp sự thật về thị trường việc làm để bán khoá học. Họ dùng các bài báo ở Mỹ, phương tây, lấy mức lương và các số liệu thống kê ở chỗ khác về đánh lận người học.
Mình cũng là một người tự học chuyển ngành sang Data, nên muốn chia sẻ một chút với các bạn đang muốn dấn thân. Hy vọng cung cấp một góc nhìn khác để các bạn cân nhắc chính xác hơn.
Lưu ý:
Công ty của mình đang làm là công ty của Mỹ, có chi nhánh ở Việt Nam, và mình cũng từng đi nộp loanh quanh khu vực ĐNA nên mình sẽ nói ở thị trường Mỹ và Việt Nam thôi.
Bài viết này không có ý khuyên bạn đừng học Data Analytics, mình chỉ muốn cảnh bảo một tương lai không phải màu hồng như các trung tâm hay vẽ ra thôi
Nếu bạn thấy bạn thực sự muốn làm và đam mềm ngành này => CHIẾN
Data Analyst là con đường nhẹ nhàng nhất để vào ngành Data ?
Khi các bạn chuyển ngành, luôn có những yêu cầu về chuyên môn và kỹ thuật, gọi chung là entry barrier (rào cản vào nghề).
Trong khi các vị trí Data Engineer, Data Scientist có những rào cản rất lớn về kỹ thuật và học thuật, thì Data Analyst lại dễ bước chân vào hơn, vì nó là sự giao thoa giữa công nghệ và một chuyên ngành nào đó (tài chính, retail, marketing, operation, SCM, ….)
Một vị trí Data Analyst cần các yếu tố cơ bản:
Kỹ năng phân tích dữ liệu (bao gồm tư duy và kỹ năng công nghệ)
Chuyên môn ở mảng mà bạn đang phân tích
Kỹ năng giao tiếp
Việc chuyển qua làm Data Analyst dễ vì 2 trong số 3 yếu tố đó không thuộc ngành kỹ thuật mà thuộc về chuyên môn khác. Chính bản thân mình cũng chọn con đường này vì nó nhẹ nhàng, đỡ sốc hơn.
Nhưng đừng hiểu nhầm. Data Analyst có entry barrier thấp hơn các vị trí khác, không có nghĩa là nó dễ hơn các vị trí đó.
Vì sao Data Analyst dễ thất nghiệp?
1/ Việc đã ít, lại còn bị cạnh tranh
Vì tính chất giao thoa giữa chuyên môn và kỹ thuật, bạn sẽ không thể có việc nếu không rành chuyên môn mà công ty đang cần phân tích. Và bạn sẽ phải cạnh tranh với những người có chuyên môn mạnh.
Một xu hướng bây giờ là các công ty đang tìm cách phân phối chức năng Analytics về từng phòng ban cụ thể.
Phòng data (hoặc IT) vẫn sẽ có Data Analyst nhưng chỉ cần số lượng rất ít, chuyên setup data model, chuyên phân tích các vấn đề về bản chất của data thu thập được, sau đó các phòng ban khác sẽ tuyển người biết làm chuyên môn để query vào dạng ad-hoc. Ví dụ:
Phòng marketing sẽ tuyển thêm Marketing Analyst, vừa biết marketing, vừa mạnh các kỹ năng về data.
Phòng tài chính sẽ tuyển Financial Analyst ,….
Hoặc cũng có các công ty lập nên các Analytics Department, sau đó tuyển Marketing Analyst, Financial Analyst, cho vào chung một bộ phận, và giảm bớt tuyển Data Analyst thuần tuý.
Công ty mình cũng nhận nhiều project thiết kế và tạo Data Model để các phòng ban khác query vào rồi kéo thả trong PowerBI. Có nhiều doanh nghiệp họ outsourcing luôn phần Data Analytics ra ngoài như vậy, đôi khi sẽ rẻ vừa hiệu quả hơn là xây dựng đội ngũ nội bộ.
Với xu hướng này, việc làm Data Analyst thuần kỹ thuật sẽ ngày càng ít đi.
Bạn – những người mới – sẽ chịu sự cạnh tranh khốc liệt từ các senior ở các ngành khác nhảy qua. Họ chỉ cần bổ sung thêm skill về Data, kết hợp các yếu tố có sẵn như chuyên môn tốt, leadership, communication skills,…
Họ không có cái mác Intern hay Fresher.Cạnh tranh với nhóm này thì hụt hơi!
2/ Cơ hội việc làm nhiều nhưng không dành cho Data Analyst và cũng ít tuyển fresher/intern
Các bạn có thể đọc thấy ngành Data đang rất HOT và nhiều cơ hội việc làm. Nhưng có thứ những quảng cáo khoá học không bao giờ nói với bạn. …
Nhiều ở mảng nào? Ngành data có rất nhiều vị trí: Data Analyst, Data Engineer, Data Scientist, Data Analytics Engineer, Database Administrator, AI Engineer…
Nhiều ở đâu? Ở Mỹ hay ở Việt Nam? Hay ở Châu Âu
Nhiều lúc nào? Cách đây 5 năm? 10 năm? Hay khi nào?
Hiện tại ở Việt Nam, thị trường việc làm ngành data cũng khá sôi động. Nhưng trong khi thị trường Mỹ luôn có chỗ cho intern, chương trình hợp tác để nuôi dưỡng tài năng, thị trường Việt Nam lại chỉ muốn tuyển người làm được việc ngay.
Vì thế thị trường việc làm Data ở Việt Nam bị lệch hẳn sang hướng từ Associate level trở lên. Hiếm khi nào tuyển fresher, intern, vì không nhiều doanh nghiệp có đủ nguồn lực tài chính, thời gian để training và chờ nhóm này phát triển.
Đó là về level, còn về vị trí, trong 3 vị trí chính Data Analyst / Data Engineer / Data Scientist thì thực tế tuyển dụng Data Analyst là hiếm nhất.
Doanh nghiệp chủ yếu tuyển Data Engineer (DE) vì nhóm này có thể tạo tác động trực tiếp lên hệ thống một cách tức thì. Chỉ cần có một bạn DE setup và migrate được hệ thống data cũ chậm chạp của công ty lên Cloud hoặc số hoá nó thành các hệ thống On-premise là thấy công ty khác hẳn liền. (Lưu ý là Data Engineer cũng hiếm khi tuyển fresher và intern nhé). Cái nào có tác dụng liền thì tất nhiên sẽ được ưu tiên.
Data Scientist thì mình chỉ thấy tuyển từ Middle hoặc từ 1 năm kinh nghiệm trở lên, và cũng là làm cho các dự án nước ngoài chứ không phải Việt Nam.
Các công ty về AI tại Việt Nam thì toàn tuyển người top thôi, hoặc bạn phải theo các chương trình residency (ươm mầm tài năng) từ rất lâu trước chứ không phải cứ học vài khoá học là xong. Mà AI đang cao trào nên các vị trí cho Data Scientist mở cũng nhiều lắm.
3/ Kinh tế suy thoái
Kinh tế suy thoái khiến cho các công ty cắt giảm ngân sách của team data lại vì không phải team nào cũng đem lại hiệu quả ngay. Vì thế họ sẽ có xu hướng tuyển người biết nhiều thứ.
Data Analyst mà biết thêm chút Machine learning thì càng hiệu quả để làm việc với Data Scientist. Data Analyst mà thêm kiến thức Data Engineer thì chúng ta sẽ có role Data Analytics Engineer, làm được nhiều thứ hơn, cần thì ETL luôn, biết xài Spark Airflow này nọ, giảm tải cho team, giảm gánh nặng tài chính cho công ty nữa.
Từ các ý trên, ai còn nghĩ ngành Data này học xong có việc luôn thì nên cẩn thận coi lại background của mình đã.
4/ Chưa kể giờ còn có AI!
Chính trong PowerBI đã có AI thể tự generate DAX function để vẽ chart chỉ bằng cách nhập yêu cầu theo ngôn ngữ tự nhiên, các module dự đoán, và khả năng gắn với các predictive model,…. Có sẵn hết. Gắn là chạy. Có thể các công nghệ này chưa chín tới, nhưng bạn sẽ thấy mọi thứ thay đổi nhanh thôi.
PowerBI giờ đã trang bị AI
Mình cũng dùng ChatGPT rất nhiều, vì nó thực sự giảm rất nhiều khối lượng công việc. Tất nhiên là dùng phải cẩn thận, mình phải hiểu rõ kết quả, mình chỉ nhờ nó làm bớt việc tay chân thôi. Sự tiện dụng của ChatGPT trong lập trình là không thể chối cãi.
ChatGPT có thể xử lý những cấu SQL phức tạp
Trong Tinh Tế có anh Thầy Giáo Sang có thể solo viết nguyên cái web app để ảnh dạy học nhờ ChatGPT.
Chat GPT không thay thế được một Data Analyst, nhưng nó cho công ty một lý do để không tuyển thêm người mới, mà nâng cấp team của họ lên với công cụ tốt hơn. Chuyện entry level data analyst thiếu việc vì AI theo mình là không thể tránh khỏi.
Những thắc mắc về nghề Data Analyst
1/ Phải cực giỏi Python mới gọi là dân data???
Các bạn nhìn vào giáo trình Data Analyst của vài trung tâm thấy dạy Python là chính. Lên các hội nhóm thấy vài anh chị lâu năm “gatekeeping” cái ngành này. Kiểu data analyst thì phải thế này thế kia, tech stack phải cỡ này, data phải cỡ trăm triệu dòng,… blah blah
Mình không nghĩ vậy. Tuỳ thị trường và công ty mà họ sẽ có những khái niệm rất khác nhau về một Data Analyst.
Có công ty thì cần bạn giỏi SQL là đủ, data infrastructure có đội Data Engineer lo rồi. Clean data này họ cũng có DE lo luôn ròi.
Có công ty thì đòi bạn phải giỏi cả Python.
Có chỗ Data xấu quá mà không có DE thì tuyển DA rành pandas, chỗ có DE thì tuyển DA mạnh về phân tích.
Có công ty đòi bạn phải master PowerBI, có công ty lại cần người giỏi Excel + VBA,…
Muôn hình vạn trạng. Mỗi quốc gia, mỗi ngành mỗi khác.
Miễn là bạn phân tích được dữ liệu, dù chỉ 1000 dòng thôi, nhưng tìm ra được các thông tin quan trọng và tạo sự tác động tích cực cho công ty, bạn chính là data analyst.
Tuỳ năng lực và độ phức tạp mà mức lương sẽ khác nhau. Nhưng phân tích dữ liệu thì không nhất thiết phải phức tạp.
2/ Mới học Data Analytics ra có được lương nghìn đô không?
Mình khẳng định luôn là được nhưng chuyện lương nghìn USD nó không hoàn toàn thuộc phạm trù bạn giỏi kỹ năng Data cỡ nào (vì như đã nói ở trên, Data Analyst không chỉ biết mỗi data). Vấn đề còn nằm ở chỗ bạn có biết tiếng anh hay không và công ty của bạn làm thế nào.
Đôi khi bạn không giỏi kỹ thuật lắm, nhưng bạn giao tiếp tốt, bạn rành chuyên môn, bạn có kỹ năng về leadership, làm việc với client được. Thì những giá trị đó sẽ bù lại. Quan trọng là các kỹ năng của bạn có thể kiếm tiền về cho công ty cỡ nào.
Các trung tâm hay nói học ra lương nghìn đô, nhưng công ty VN sẵn sàng bỏ ra nghìn USD cho một vị trí entry, cho một người mới là rất khó.
Còn nếu chỗ bạn apply một công ty Mỹ hay một công ty làm outsourcing các dự án tính bằng tiền đô thì chi ra $1,000 lại rất đơn giản với họ vì số tiền đó chả bao nhiêu so với quy mô dự án. Nhưng mà những kèo này thì … không nhiều.
Một thực trạng chung của ngành IT mà mình quan sát được: Không tiếng anh = lương thấp dù nhiều năm kinh nghiệm. Úp to chứ lúc deal thấp hơn nữa. Nhiều công ty lợi dụng việc bạn ko biết tiếng anh để ép giá.
3/ Tự học trên mạng có ra làm Data Analyst được không
Chắc chắn là được, nhưng còn tuỳ người. Bạn hoàn toàn có thể tự học kỹ năng data nhưng chuyên môn thì mình không chắc. Tuỳ xuất phát điểm và chuyên môn làm việc trước đó mà mỗi người mỗi khác. Rồi cách học nữa. Có người chỉ học mỗi 1 khoá data analyst, có người sẽ học thêm các thứ râu ria,….
Từ lý thuyết học ra làm việc thực tế nó rất khác các bạn ạ.
Ví dụ như các bạn học trên Datacamp cẳng hạn. Họ dạy SQL cũng gọi là ổn. Nhưng nếu bạn học theo track DA của họ thì lại thiếu mất phần setup một cái database SQL hay dùng các database client hay các tính năng như Store Procedure, các kỹ thuật Partition, Indexing,…. Thành ra các bạn bị giới hạn ở chỗ chỉ biết query, trong khi thực tế đi làm thì phải tương tác với database ở mức cao hơn vậy.
Nên các bạn cần chuẩn bị thêm các “giá trị khác” của bản thân để bù lại trong thời gian đầu.
4/ Học trung tâm có ổn không?
Chất lượng trung tâm thế nào thì mình không không nói được vì mình chưa bao giờ học ở đó. Nhưng rất khó để 1 khoá học có thể đáp ứng được nhu cầu, vì thị trường bây giờ đòi hỏi rất đa dạng như đã kể ở trên.
Mình có coi giáo trình của một trung tâm rất lớn thấy họ dạy rất sát thực tế việc làm DA ở Việt Nam, nhưng coi phản hồi học viên thấy quá trình dạy không ổn lắm. Có trong tâm khác cũng nổi tiếng thì dạy toàn Python với Machine Learning.
Nói chung cái này thì tuỳ mỗi người thôi. Có người cầm tay chỉ việc thì lúc nào cũng nhanh. Nhưng phải lựa các chỗ uy tín. Với mình thấy các khoá học giờ đắt quá.
Đừng học IT hay Data chỉ vì nghe trung tâm quảng cáo
Trung tâm nói lương cao
Không có gì sai khi chọn học một ngành nghề vì tiền cả. Là người Châu Á, chúng ta quá quen với kiểu muốn con cái học bác sỹ, kỹ sư để mong con cái có thu nhập tốt, công danh sáng lạng. Nhưng lương IT ở Việt Nam không cao như nước ngoài hay trên internet hay nói đâu các bạn.
Mình thấy ở Việt Nam có nhiều cách kiếm tiền khoẻ hơn đi làm IT.
Trước đây mình có công ty riêng, biz riêng. Và mình thấy với cùng mức độ nỗ lực thì kinh doanh đem lại cho mình nhiều tiền hơn. Tuy nhiên vì mình có mục tiêu rất cụ thể, không phải vì tiền, nên mình chấp nhận và có thể bền bỉ học tiếp.
Có một câu chuyện khá hay mình đọc được trên Reddit, đó là người giàu có ở thung lũng Silicon không phải là mấy anh lập trình, mà là bà bán mì Ramen góc đường, net worth hàng chục triệu USD. Các anh dev luôn vui vẻ chi tiền khủng ở đây để bù lại những áp lực công việc của họ.
Nếu vấn đề của bạn là muốn kiếm tiền thì mình tin là có nhiều con đường khác nhanh hơn và dễ hơn, đỡ nhức đầu hơn. Không nhất thiết phải đâm đầu vào đây nếu bạn không thích nó.
Nếu bạn muốn theo đuổi vì cảm thấy nó hợp, sống với con số, biểu đồ nó làm bạn thoải mái, bạn muốn tạo giá trị bằng con đường này…. Thì mình ủng hộ bạn hết cỡ.
Trung tâm nói học ra có việc hoặc hỗ trợ việc làm
Khi các trung tâm nói là hỗ trợ việc làm, tức là họ đang lấp liếm. Thực ra họ chỉ hỗ trợ các bạn TÌM VIỆC cho đến khi có việc thì thôi. Còn bao lâu có việc thì họ không nói và mức độ hỗ trợ tới đâu cũng vô cùng mơ hồ.
Mình nằm vùng trong hàng chục group tuyển dụng việc data, mình kết nối với nhiều HR trên Linkedln và theo dõi việc làm Linkedin rất nhiều. Nhưng chả có chỗ nào cho thấy cái sự “HOT” “ nhu cầu cao” như các khoá học nói cả. Toàn bán khoá học với cả lừa đảo nhập liệu thôi.
Mình tin là những người dạy học ở các trung tâm đều là các anh chị có chuyên môn cao và biết thực tế thị trường, những quảng cáo kia là do team marketing dựa trên “truyền thông ở một vũ trụ song song nào đó” viết nên. Nên nếu các trung tâm có đọc được bài này thì hy vọng mọi người điều chỉnh lại cho đúng hơn
Data analytics là một kỹ năng quan trọng và ai cũng cần. Không theo chuyên nghiệp về data cũng nên học để nâng cấp skillset, tư duy,…
Nhưng chốt lại là không có chuyện cứ học data analyst ra là sẽ có việc, offer nghìn đô liền nhé anh em. Phải có các yếu tố khác nữa.
Chúng ta rất dễ bỏ qua lượng dữ liệu được tạo ra hàng ngày – từ điện thoại thông minh, cuộc gọi Zoom cho đến máy rửa bát có kết nối Wi-Fi.
Người ta ước tính rằng thế giới sẽ tạo và lưu trữ 200 Zettabyte dữ liệu vào năm 2025. Mặc dù việc lưu trữ lượng dữ liệu này là một thách thức, nhưng việc rút lấy giá trị từ đó còn phức tạp hơn.
Từ năm 2020 đến năm 2022, tổng khối lượng dữ liệu doanh nghiệp sẽ tăng từ 1 lên 2,02 petabyte (PB). Tăng trung bình hàng năm 42,2% trong hai năm.
Có thể bạn đã quen với thuật ngữ “Dữ liệu lớn” (big data) – và quy mô của thị trường này đang tiếp tục tăng lên.
Thị trường phân tích big data dự kiến đạt 103 tỷ đô vào năm 2023, với chất lượng dữ liệu kém khiến nền kinh tế Mỹ thiệt hại lên tới 3,1 nghìn tỷ đô la mỗi năm.
Các công ty trong danh sách Fortune 1000 có thể kiếm thêm thu nhập ròng hơn 65 triệu đô, chỉ bằng cách tăng khả năng truy cập dữ liệu của họ lên 10%.
Điều này nghĩa là điều quan trọng trong kinh doanh là các công ty có thể thu được giá trị từ dữ liệu của họ nhằm cung cấp thông tin tốt hơn cho các quyết định kinh doanh, bảo vệ doanh nghiệp và khách hàng cũng như phát triển doanh nghiệp.
Để làm được điều này, doanh nghiệp phải tuyển những người có bộ kỹ năng cụ thể phù hợp với chiến lược và quản trị dữ liệu, chẳng hạn như data engineer, data scientist và ML engineer.
Bài viết này sẽ trình bày tất cả những điều cơ bản về data engineer bao gồm các vai trò, chức năng và trách nhiệm chung.
Bạn cũng sẽ hiểu rõ hơn về tầm quan trọng của data engineer và tìm hiểu cách bắt đầu thu được nhiều giá trị hơn từ dữ liệu của mình.
Dừng lại chút nào, nếu bạn đang #open_to_work, thử nghía qua các công việc đang tuyển trên Gamba nhé. Vào LINK NÀY để xem các job Data hoặc scan QR Code ở bên dưới nhé.
Xem và ứng tuyển các ‘data’ job
Data Engineering là gì?
Khi nói đến việc tăng thêm giá trị cho dữ liệu, có nhiều điều bạn phải tính đến – cả bên trong và bên ngoài công ty.
Công ty của bạn có thể tạo dữ liệu từ các hệ thống hoặc sản phẩm nội bộ, tích hợp với các ứng dụng và nhà cung cấp bên thứ ba, đồng thời phải cung cấp dữ liệu ở định dạng cụ thể cho những người dùng (nội bộ và bên ngoài) và các trường hợp sử dụng khác nhau.
Dữ liệu được tạo và thu thập từ doanh nghiệp của bạn có thể có các yêu cầu tuân thủ như SOC2 hoặc Thông tin nhận dạng cá nhân (PII) mà bạn bắt buộc phải bảo vệ về mặt pháp lý.
Trong trường hợp này, bảo mật trở thành ưu tiên hàng đầu đối với dữ liệu, điều này dẫn đến những thách thức kỹ thuật đối với dữ liệu đang chuyển và ở trạng thái nghỉ.
Dữ liệu của bạn không chỉ phải an toàn mà còn phải có sẵn cho người dùng cuối, tuân thủ các yêu cầu kinh doanh và có tính toàn vẹn (tính chính xác và nhất quán).
Nếu dữ liệu được bảo mật nhưng không sử dụng được, nó không thể tăng thêm giá trị cho công ty. Có nhiều khía cạnh đối với một chiến lược quản trị dữ liệu đòi hỏi các kỹ năng chuyên biệt.
Đây là lúc data engineer (kỹ sư dữ liệu) phát huy tác dụng.
Vai trò của Data Engineer
Một kỹ sư dữ liệu giống như một con dao đa năng Thụy Sĩ trong không gian dữ liệu. Data Engineer có nhiều vai trò và trách nhiệm, thường phản ánh một hoặc nhiều phần quan trọng của data engineering, đã đề cập bên trên.
Vai trò của một kỹ sư dữ liệu sẽ thay đổi tùy thuộc vào nhu cầu cụ thể của tổ chức của bạn.
Vai trò của một kỹ sư dữ liệu là lưu trữ, trích xuất, chuyển đổi, tải, tổng hợp và xác thực dữ liệu. Điều này bao gồm:
Xây dựng quy trình dữ liệu (data pipeline và lưu trữ dữ liệu hiệu quả cho các công cụ cần truy vấn dữ liệu.
Phân tích dữ liệu, đảm bảo dữ liệu tuân thủ các quy tắc và quy định quản trị dữ liệu.
Hiểu ưu và nhược điểm của các phương án lưu trữ và truy vấn dữ liệu.
Ví dụ: một doanh nghiệp có thể đang sử dụng Amazon Web Services (AWS) làm nhà cung cấp dịch vụ đám mây và bạn muốn lưu trữ và truy vấn dữ liệu từ các hệ thống khác nhau.
Phương án tốt nhất sẽ khác nhau tùy thuộc vào việc dữ liệu của bạn có cấu trúc hay không có cấu trúc (hoặc thậm chí bán cấu trúc), chuẩn hóa hay không chuẩn hóa và liệu bạn cần dữ liệu ở định dạng dữ liệu hàng hay cột.
Dữ liệu của bạn có quan trọng / dựa trên giá trị không? Có các mối quan hệ phức tạp giữa các dữ liệu không? Dữ liệu có cần được xử lý hoặc kết hợp với các tập dữ liệu khác không?
Tất cả những quyết định này ảnh hưởng đến cách một data engineer nhập, xử lý, quản lý và lưu trữ dữ liệu.
Data Team gồm những ai? Ảnh: phData
Cách data engineer gia tăng giá trị
Thay vì mô tả trừu tượng, đây là kịch bản: CEO muốn biết doanh nghiệp của bạn có thể tiết kiệm được bao nhiêu tiền bằng cách mua hàng loạt nguyên vật liệu và phân phối chúng đến các địa điểm khác nhau.
Bạn cần có khả năng xác định cách tính phí lại bất kỳ vật liệu không sử dụng nào cho các đơn vị kinh doanh khác nhau.
Điều này có thể cần bạn tổng hợp dữ liệu từ hệ thống ERP, hệ thống chuỗi cung ứng, các nhà cung cấp bên thứ ba và dữ liệu xung quanh cấu trúc doanh nghiệp nội bộ.
Trước đây, một số công ty có thể đã cố gắng tạo báo cáo này trong Excel, nhờ nhiều nhà phân tích kinh doanh và kỹ sư đóng góp vào việc khai thác và thao tác dữ liệu.
Kỹ sư dữ liệu cho phép một tổ chức thu thập dữ liệu một cách hiệu suất và hiệu quả từ nhiều nguồn khác nhau, nói chung là lưu dữ liệu đó vào một hồ dữ liệu (data lake) hoặc thành một số chủ đề Kafka.
Khi dữ liệu đã được thu thập từ mỗi hệ thống, data engineer có thể xác định cách kết hợp tối ưu các bộ dữ liệu.
Với điều đó, các kỹ sư dữ liệu có thể xây dựng các quy trình dữ liệu cho phép dữ liệu chảy ra khỏi hệ thống nguồn.
Kết quả của quy trình dữ liệu này sau đó được lưu ở một vị trí riêng biệt – thường ở định dạng mà các công cụ thông minh kinh doanh khác nhau có thể truy vấn.
Các kỹ sư dữ liệu cũng chịu trách nhiệm đảm bảo rằng các quy trình dữ liệu này có đầu vào và đầu ra chính xác. Điều này thường liên quan đến việc đối chiếu dữ liệu hoặc các quy trình dữ liệu bổ sung để xác nhận đối với các hệ thống nguồn.
Các kỹ sư dữ liệu cũng phải đảm bảo rằng các quy trình dữ liệu lưu chuyển liên tục và thông tin luôn được cập nhật, sử dụng các công cụ giám sát và thực hành SRE (Site Reliability Engineering – kỹ thuật quản lý độ tin cậy) khác nhau.
Nói một cách dễ hiểu, data engineer gia tăng giá trị khi họ tự động hóa và tối ưu hóa các hệ thống phức tạp, biến dữ liệu thành một tài sản kinh doanh có thể truy cập và sử dụng được.
ELT và ETL
Quy trình dữ liệu có nhiều loại khác nhau và vai trò của data engineer là biết nên sử dụng chiến lược nào và tại sao.
Hai chiến lược phổ biến nhất xoay quanh các khái niệm trích xuất, tải và chuyển đổi (ELT) dữ liệu. Trước tiên, dữ liệu luôn phải được trích xuất theo cách nào đó từ một nguồn dữ liệu, nhưng những gì sẽ xảy ra tiếp theo không đơn giản như vậy.
ELT thường thấy trong các kiến trúc hồ dữ liệu hoặc hệ thống cần dữ liệu trích xuất thô từ nhiều nguồn. Điều này cho phép các quy trình và hệ thống khác nhau xử lý dữ liệu từ cùng trích xuất.
Nếu bạn kết hợp dữ liệu từ nhiều hệ thống và nguồn khác nhau, sẽ có lợi khi đồng định vị dữ liệu đó và lưu trữ ở một nơi trước khi thực hiện chuyển đổi sang dữ liệu.
MẸO CHUYÊN NGHIỆP: Nói chung, luồng công việc loại ELT chính là một quy trình ELT-L, nơi dữ liệu đã chuyển đổi sau đó được tải vào một vị trí khác để tiêu thụ như Snowflake, AWS Redshift hoặc Hadoop.
Ngược lại, quy trình ETL (trích xuất, chuyển đổi, tải) đặt việc tính toán nặng khi chuyển đổi trước khi tải kết quả vào tệp hệ thống, cơ sở dữ liệu hoặc kho dữ liệu.
Kiểu cách này thường không hiệu quả so với quy trình ELT, vì dữ liệu cho mỗi lô hoặc luồng thường được yêu cầu từ các hệ thống phụ thuộc hoặc liên quan.
Điều này nghĩa là trên mỗi lần thực thi, bạn sẽ phải truy vấn lại dữ liệu từ các hệ thống cần thiết, thêm tải cho các hệ thống đó và thêm thời gian chờ dữ liệu có sẵn.
Tuy nhiên, trong trường hợp các chuyển đổi đơn giản được áp dụng cho một nguồn dữ liệu duy nhất, ETL có thể thích hợp hơn vì nó làm giảm độ phức tạp của hệ thống, nhưng có khả năng phải trả giá bằng khả năng trao quyền dữ liệu (data enablement)
Khuyến nghị chung là sử dụng các quy trình ELT khi có thể để tăng hiệu suất, tính khả dụng và khả năng trao quyền của dữ liệu.
Hiệu suất
Việc có dữ liệu chính xác và sẵn có cho data engineer không đơn giản. Dữ liệu cũng phải hiệu quả.
Khi xử lý gigabyte, terabyte hoặc thậm chí petabyte dữ liệu, các quy trình và kiểm tra phải được thực hiện để đảm bảo dữ liệu đáp ứng các thỏa thuận mức dịch vụ (SLA) và gia tăng giá trị cho doanh nghiệp nhanh nhất có thể.
Điều quan trọng nữa là xác định ý nghĩa của hiệu suất đối với dữ liệu của bạn.
Các data engineer cần tính đến tần suất họ nhận được dữ liệu mới, thời gian chạy quá trình chuyển đổi và mất bao lâu để cập nhật điểm đến đích của dữ liệu.
Các đơn vị kinh doanh thường muốn thông tin cập nhật càng sớm càng tốt, đồng thời có những điểm dừng và chuyển động trong hành trình của dữ liệu mà các data engineer phải tính đến.
Ví dụ:
Hãy tưởng tượng nếu công ty của bạn là một hãng hàng không và bạn muốn cung cấp giá cho khách hàng dựa trên đầu vào từ nhiều hệ thống khác nhau để đưa ra mức giá cho khách hàng.
Nếu giá của bạn quá cao, khách hàng sẽ đặt vé với các hãng hàng không khác. Nếu giá của bạn quá thấp, tỷ suất lợi nhuận của bạn sẽ bị ảnh hưởng.
Đột nhiên, kênh đào Suez bị tắc nghẽn và các tàu vận tải vận chuyển dầu không thể đi ra khỏi Ả-rập Xê-út, làm gián đoạn chuỗi cung ứng toàn cầu và khiến giá dầu và khí đốt tăng cao.
Máy bay thương mại sử dụng rất nhiều nhiên liệu, lên tới gần 20 tỷ gallon mỗi năm. Điều này sẽ ảnh hưởng đáng kể đến chi phí vận hành doanh nghiệp của bạn và phải được phản ánh nhanh nhất có thể trong việc định giá của bạn.
Để điều này xảy ra, các kỹ sư dữ liệu phải thiết kế và triển khai các quy trình dữ liệu hiệu quả và hoạt động tốt.
Tích hợp liên tục và phân phối liên tục
Code không bao giờ là một giải pháp kiểu “lên và quên”. Các yêu cầu về quản trị dữ liệu, công cụ, thực hành tốt nhất, quy trình bảo mật và các yêu cầu kinh doanh luôn nhanh chóng thay đổi và thích ứng; môi trường sản xuất của bạn cũng phải như vậy.
Điều này có nghĩa là việc triển khai cần phải được tự động hóa và có thể xác minh được.
Các kiểu triển khai phần mềm cũ hơn thường dẫn đến việc chạy bản dựng, sao chép và dán kết quả vào máy chủ sản xuất của bạn và thực hiện “smoke test” thủ công để xem ứng dụng có hoạt động như mong đợi hay không.
Việc này không thể mở rộng và gây rủi ro cho doanh nghiệp của bạn.
Nếu bạn đang thử nghiệm trực tiếp trên môi trường sản xuất, bất kỳ lỗi hoặc vấn đề nào mà bạn có thể đã bỏ qua trong quá trình kiểm thử (hoặc bất kỳ ảnh hưởng nào của môi trường cụ thể lên mã của bạn), sẽ dẫn đến trải nghiệm khách hàng kém vì những lỗi hoặc lỗi này sẽ xảy ra với người dùng cuối.
Thực tiễn tốt nhất để đẩy code lên là thiết lập các quy trình tự động để xác minh code hoạt động như mong đợi trong các tình huống khác nhau.
Điều này thường được thực hiện với các bài kiểm thử đơn vị và kiểm thử tích hợp.
Các kiểm thử đơn vị xác minh rằng các đoạn mã riêng lẻ sẽ tạo ra các đầu ra mong đợi một cách độc lập với mã khác sử dụng đoạn mã đó.
Những điều này là để xác minh logic phức tạp trong từng đoạn mã, cũng như cung cấp bằng chứng rằng mã thực thi đúng như mong đợi.
Một cấp độ khác từ đó là kiểm tra tích hợp. Việc này đảm bảo rằng các đoạn mã hoạt động cùng nhau và tạo ra (các) đầu ra mong đợi cho một tập hợp các đầu vào nhất định.
Đây thường là lớp kiểm tra quan trọng hơn, vì nó đảm bảo rằng các hệ thống tích hợp với nhau như mong đợi.
Bằng cách kết hợp các bài kiểm thử đơn vị và kiểm thử tích hợp với các chiến lược triển khai hiện đại như triển khai xanh lam-xanh lá (blue – green deployment), xác suất tác động đến khách hàng và doanh nghiệp của bạn bằng mã mới sẽ giảm đáng kể.
Mọi thứ đều được xác thực dựa trên các bài kiểm thử đã thiết lập trước khi các thay đổi được đưa vào môi trường.
Phục hồi sau thảm họa
Nhiều doanh nghiệp tập trung vào việc cung cấp càng nhiều giá trị cho khách hàng càng nhanh càng tốt, nhưng điều quan trọng là đảm bảo rằng bạn có kế hoạch trong trường hợp hệ thống gặp sự cố.
Trong khi nhiều công ty phụ thuộc rất nhiều vào các nhà cung cấp đám mây để giảm thiểu thời gian ngừng hoạt động và đảm bảo SLA, thất bại chắc chắn sẽ xảy ra.
Điều này có nghĩa là các hệ thống phải được thiết kế để chịu được lỗi hệ thống nghiêm trọng.
Khôi phục sau thảm họa trong data engineering thường rơi vào chỉ số:
Mục tiêu thời gian khôi phục (RTO)
Mục tiêu điểm phục hồi (RPO)
Trong trường hợp xảy ra tình huống khôi phục thảm họa, các doanh nghiệp cần phải có các tiêu chuẩn để hiểu tác động đến khách hàng của họ và hệ thống của họ sẽ không hoạt động trong bao lâu.
Các kỹ sư dữ liệu chịu trách nhiệm đưa các quy trình vào đúng vị trí để đảm bảo rằng các quy trình dữ liệu, cơ sở dữ liệu và kho dữ liệu đáp ứng các chỉ số này.
Ví dụ:
Hãy tưởng tượng nếu công ty của bạn là một hãng hàng không và bạn cần cung cấp cho khách hàng khả năng đặt vé máy bay, nhưng đột nhiên, trung tâm dữ liệu của bạn phát nổ.
Doanh nghiệp của bạn đã thiết lập quy trình đồng bộ hóa dữ liệu để sao chép dữ liệu sang một trung tâm dữ liệu khác, nhưng quy trình đó đã bị gián đoạn và xảy ra mất mát dữ liệu.
Bạn cần thiết lập lại cơ sở dữ liệu chính trong bộ ứng dụng của mình từ cơ sở dữ liệu được sao chép.
RPO thể hiện lượng dữ liệu bị mất trong khoảng thời gian đó và RTO thể hiện thời gian khách hàng không thể đặt chuyến bay.
Các kỹ sư dữ liệu thường xuyên phải đánh giá, thiết kế và triển khai các hệ thống để giảm thiểu tác động đến khách hàng trong trường hợp hỏng hóc.
Data Governance là gì?
Một chiến lược quản trị dữ liệu (data governance) là điều cần thiết cho sự thành công của tổ chức và dữ liệu của nó.
Đây là một chủ đề rất phức tạp mà chúng tôi đã đề cập ở những nơi khác, nhưng ở cấp độ cao, quản trị dữ liệu được cấu trúc như sau:
Data Governance là gì? Ảnh: phData
Để dữ liệu của bạn cung cấp giá trị cho doanh nghiệp đồng thời giảm thiểu rủi ro và chi phí, bạn sẽ cần xác định và thực thi câu trả lời cho khá nhiều câu hỏi:
Ai có quyền truy cập vào dữ liệu của tôi?
Làm cách nào để kiểm tra và cung cấp quyền truy cập?
Dữ liệu được lưu trữ vật lý như thế nào trong một hệ thống và trên các hệ thống?
Công ty của tôi tuân theo các tiêu chuẩn và thông lệ mã hóa dữ liệu nào?
Làm cách nào để xác thực dữ liệu trong các báo cáo khác nhau đến từ đâu?
Làm cách nào để xác thực tính đúng đắn của một báo cáo mà tôi đang đưa ra quyết định kinh doanh quan trọng?
Làm cách nào để người dùng tìm thấy dữ liệu trong hệ thống của tôi?
Đây là những câu hỏi rất phức tạp thường có câu trả lời phức tạp và đòi hỏi kiến thức từ các lĩnh vực kinh doanh và công nghệ khác nhau:
Doanh nghiệp của bạn cần xác định cách dữ liệu làm tăng giá trị cho tổ chức.
Nhân viên bảo mật của bạn cần xác định các tiêu chí để mã hóa và quản lý truy cập.
Các kỹ sư dữ liệu của bạn cần có khả năng liên kết dữ liệu với nhau và làm chủ các kho dữ liệu cho người dùng cuối.
Tất cả điều này cần được quản lý và thực thi bởi các thành viên đa chức năng trong tổ chức.
Data Governance khác với Data Engineering như thế nào?
Quản trị dữ liệu tập trung hơn vào quản trị dữ liệu và kỹ thuật dữ liệu tập trung vào thực thi dữ liệu.
Mặc dù kỹ sư dữ liệu là một phần của chiến lược quản trị dữ liệu tổng thể, nhưng quản trị dữ liệu bao gồm nhiều thứ hơn là thu thập và quản lý dữ liệu.
Khó mà nói một tổ chức có một thực tiễn quản trị dữ liệu hiệu quả nếu không có các kỹ sư dữ liệu thực hiện nó.
Ví dụ: hãy xem một số câu hỏi của chúng tôi ở trên, lưu ý các kỹ sư dữ liệu và cách họ hoàn thành từng nhiệm vụ.
Ai có quyền truy cập vào dữ liệu?
Trong thực tiễn quản trị dữ liệu, các quy tắc và quy định xác định ai nên có quyền truy cập vào các phần thông tin cụ thể trong tổ chức.
Nếu là công ty vận chuyển, bạn có thể cần tách biệt dữ liệu mà nhà cung cấp và khách hàng có thể xem tại bất kỳ thời điểm nào hoặc đảm bảo rằng các nhà cung cấp khác nhau không thể xem thông tin về các nhà cung cấp khác.
Điều này yêu cầu các ràng buộc về phân loại, gắn thẻ và truy cập dữ liệu.
Nếu bạn đang thu thập dữ liệu từ các hệ thống khác nhau, kỹ sư dữ liệu chịu trách nhiệm áp dụng các quy tắc phân loại và gắn thẻ khi thu thập.
Điều này có thể bao gồm việc thêm các điểm dữ liệu bổ sung vào dữ liệu đã thu thập hoặc lưu trữ dữ liệu riêng biệt trên đĩa.
Sau đó, khi dữ liệu được tổng hợp hoặc chuyển đổi, kết quả cuối cùng phải bao gồm cùng thông tin này. Khi thiết lập các ràng buộc truy cập đối với dữ liệu, kỹ sư dữ liệu cũng phải thực thi các chính sách được yêu cầu.
Làm cách nào điều chỉnh và cung cấp quyền truy cập?
Để được coi là tuân thủ nhiều quy định bắt buộc của doanh nghiệp, bạn phải có khả năng theo dõi ai có quyền truy cập vào dữ liệu của bạn và những thay đổi đối với quyền truy cập đó.
Điều này cũng bao gồm việc thông báo cho người dùng dữ liệu về những thay đổi đối với dữ liệu.
Nếu bạn là người tiêu dùng của một tập hợp dữ liệu và nó thay đổi mà bạn không biết, hệ thống có thể bị hỏng. Điều này có nghĩa là việc có thể theo dõi ai và ai nên sử dụng dữ liệu là rất quan trọng.
Mặc dù các thực tiễn quản trị dữ liệu xác định những quy tắc đó nên là gì, nhưng trách nhiệm của các kỹ sư dữ liệu là đưa những quy tắc đó vào đúng vị trí.
Điều này có nghĩa là thiết lập các quy tắc IAM trong AWS hoặc Microsoft Azure để đảm bảo rằng một số vai trò nhất định chỉ có thể đọc dữ liệu từ các nguồn và hệ thống khác nhau.
Sau đó, nhóm bảo mật có trách nhiệm xác thực rằng người dùng chỉ có quyền truy cập vào các vai trò thích hợp.
Làm thế nào dữ liệu được lưu trữ vật lý trong một hệ thống và trên toàn hệ thống?
Kỹ sư dữ liệu chịu trách nhiệm lưu trữ dữ liệu được thu thập và chuyển đổi ở nhiều vị trí khác nhau tùy thuộc vào yêu cầu của doanh nghiệp.
Mỗi bộ công cụ và vị trí sẽ có các cách khác nhau để dữ liệu được lưu trữ và truy cập, và kỹ sư dữ liệu phải tính đến các giới hạn, lợi ích và trường hợp sử dụng cho từng vị trí và tập hợp dữ liệu.
Ví dụ:
Giả sử doanh nghiệp của bạn đang nhập một triệu bản ghi mỗi ngày cho một nguồn dữ liệu cụ thể.
Nếu bạn đang lưu trữ tệp này trên đĩa, bạn không thể chỉ thêm vào một tệp đơn lẻ, (Nó giống như mò kim đáy bể!)
Nếu bạn đang cố gắng tạo báo cáo hoặc cung cấp cho người dùng cuối một phần thông tin cụ thể, bạn sẽ không bao giờ có thể tìm thấy nó.
Các kỹ sư dữ liệu sẽ:
Biết rằng dữ liệu này cần được phân vùng trên các tệp và thư mục khác nhau trong hệ thống tệp của bạn để tách dữ liệu.
Đánh giá dữ liệu và cách dữ liệu được tải và sử dụng để xác định cách thích hợp để chia nhỏ dữ liệu.
Xác định cách cập nhật các phần dữ liệu cụ thể khi các thay đổi được áp dụng cho nguồn dữ liệu.
Quản trị dữ liệu và các quy tắc xung quanh nó có thể xác định quyền truy cập dữ liệu vào các phân vùng đó và có thể yêu cầu các chỉ số hiệu suất của dữ liệu đó.
Tuy nhiên, các thành viên của nhóm quản trị dữ liệu sẽ không có bộ kỹ năng để thiết lập các vai trò truy cập đó hoặc lấy các chỉ số đó.
Data Science là gì?
Nếu bạn đang cố gắng tìm kiếm giá trị từ các tập dữ liệu khác nhau, bạn sẽ bắt đầu từ đâu?
Ví dụ: nếu bạn có dữ liệu về khách hàng và đơn hàng của họ, bạn có thể cố gắng tìm ra những mặt hàng bổ sung nào bạn có thể bán cho họ dựa trên các đơn hàng khác. Nếu bạn có thể biết tương quan giữa khách hàng và việc mua hàng của họ, bạn có thể bán thêm cho các đơn hàng trong tương lai.
Điều này có thể đơn giản nếu bạn có một nhóm khách hàng và đơn hàng nhỏ.
Bạn có thể thuê các nhà phân tích kinh doanh (business analyst) là chuyên gia trong công ty của bạn và đã làm việc với khách hàng trong nhiều năm để có thể suy ra những gì khách hàng muốn.
Nhưng…
Điều gì sẽ xảy ra nếu bạn có hàng triệu khách hàng và hàng triệu giao dịch?
Điều gì sẽ xảy ra nếu bạn có các nhà cung cấp bên ngoài cung cấp cho bạn thông tin bổ sung về khách hàng của bạn?
Điều gì sẽ xảy ra nếu dữ liệu của bạn không có cấu trúc và không thể dễ dàng kết hợp với các tập dữ liệu khác?
Làm thế nào để bạn biết rằng các phần thông tin cụ thể thực sự có mối tương quan và đưa ra quyết định dựa trên dữ liệu chứ không phải cảm tính?
Đây là lúc khoa học dữ liệu (data science) đi vào bức tranh.
Các nhà khoa học dữ liệu được giao nhiệm vụ sử dụng các phương pháp, quy trình, thuật toán và hệ thống khoa học để trích xuất những hiểu biết kinh doanh có giá trị từ dữ liệu có cấu trúc và phi cấu trúc.
Mô hình hóa dữ liệu là gì?
Để hiểu kết quả công việc của nhà khoa học dữ liệu trông như thế nào, chúng ta phải hiểu mô hình dữ liệu là gì.
Mô hình hóa dữ liệu là quá trình dữ liệu được xác định, phân tích và cấu trúc để tạo ra một đầu ra có ý nghĩa.
Điều này thường có nghĩa là nhập dữ liệu từ nhiều nguồn khác nhau, cấu trúc nó thành các thực thể và mối quan hệ khác nhau, thực hiện các phép tính đối với dữ liệu và xác thực đầu ra.
Data Modeling là gì? Ảnh: phData
Mục tiêu của mô hình hóa dữ liệu là để minh họa hoặc tính toán các kết nối giữa các điểm và cấu trúc dữ liệu.
Quay trở lại ví dụ về khách hàng và giao dịch của chúng ta, mô hình dữ liệu sẽ cho chúng ta thấy các khách hàng và giao dịch khác nhau liên quan với nhau như thế nào, vì vậy chúng tôi có thể bắt đầu thực hiện một số phân tích thống kê về mức độ liên quan chặt chẽ của chúng.
Một đầu ra tiềm năng của mô hình dữ liệu này là những khách hàng đã mua tã có khả năng mua nước rửa tay cao hơn 80% so với những khách hàng không mua.
Ngoài ra còn có các loại mô hình dữ liệu khác nhau:
Mô hình vật lý: lược đồ hoặc khuôn khổ về cách dữ liệu được lưu trữ vật lý trên đĩa hoặc trong cơ sở dữ liệu.
Mô hình khái niệm: cấu trúc và khái niệm kinh doanh cấp cao.
Mô hình dữ liệu logic: các kiểu thực thể, kiểu dữ liệu và thuộc tính, mối quan hệ giữa các thực thể.
Cách nhà khoa học dữ liệu gia tăng giá trị
Các nhà khoa học dữ liệu thường có nền tảng toán học, thống kê và lập trình vững chắc.
Khi làm việc với Dữ liệu lớn, rất khó xác định giá trị theo cách thủ công. Còn nhớ “mò kim đáy bể” chứ?
Thay vào đó, các nhà khoa học dữ liệu phải làm việc với dữ liệu để xác thực các lý thuyết và mô hình thống kê.
Trong ví dụ về mô hình dữ liệu của chúng ta, chúng ta có thể xác định rằng những khách hàng đã mua tã có khả năng mua nước rửa tay cao hơn 80% so với những khách hàng không mua.
Mặc dù đây là một kết luận đơn giản và hợp lý, nhưng đôi khi các tổ chức có những mối quan hệ phức tạp hơn giữa dữ liệu của họ và giá trị kinh doanh.
Cũng có thể là tổ chức của bạn có quá nhiều dữ liệu mà bạn thậm chí không biết bắt đầu từ đâu.
Các công ty trong danh sách Fortune 1000 có thể kiếm thêm thu nhập ròng hơn 65 triệu đô la bằng cách tăng khả năng truy cập dữ liệu của họ lên 10%.
Đây là lý do tại sao các công ty cần có các nhà khoa học dữ liệu tạo mô hình dữ liệu và thực hiện phân tích trên dữ liệu – giúp các đơn vị kinh doanh có thể truy cập được.
Rất thực tế là doanh nghiệp của bạn có thể bán kèm hoặc bán thêm các dịch vụ cho khách hàng hiệu quả hơn hoặc doanh nghiệp của bạn có thể tiết kiệm tiền bằng cách sử dụng các mô hình dữ liệu để dự đoán việc sử dụng tài nguyên.
Phân tích dự đoán (Predictive analysis) là gì?
Mặc dù bán chéo và bán thêm (cross sell và up sell) dịch vụ là một khái niệm bình thường đối với hầu hết các doanh nghiệp bán sản phẩm hoặc dịch vụ, nhưng phân tích dự đoán sẽ bổ sung một lớp giá trị kinh doanh khó hình thành hơn.
Giả sử bạn là một công ty vận chuyển và bạn đã được CEO giao nhiệm vụ tối đa hóa lợi nhuận và giảm thiểu chi phí hoạt động. Đây là mục tiêu của mọi doanh nghiệp, phải không?
Bạn sẽ bắt đầu từ đâu?
Bạn có thể cố gắng xác định các tuyến đường vận chuyển thường xuyên được sử dụng và đảm bảo rằng bạn có xe tải thường xuyên giao hàng qua lại mà không phải chờ đợi giữa các chuyến hàng quá lâu.
Tuy nhiên:
Làm thế nào để bạn xác định thời tiết sẽ ảnh hưởng đến điều kiện lái xe như thế nào?
Làm thế nào để bạn tối ưu hóa các tuyến đường trong trường hợp một cây cầu bị sập?
Làm thế nào để bạn biết được thời điểm lý tưởng để lái xe qua từng thành phố mà không gặp phải lượng lớn giao thông?
Đây là một ví dụ tuyệt vời khác về việc một mô hình dữ liệu và các nhà khoa học dữ liệu bổ sung thêm rất nhiều giá trị.
Nhà khoa học dữ liệu chịu trách nhiệm lập mô hình từng điểm dữ liệu có thể ảnh hưởng đến tuyến đường vận chuyển, tính toán các rủi ro và tác động của từng điểm theo chương trình và tính toán các kết luận để thông báo cho doanh nghiệp về cách hoạt động.
Với phân tích dự đoán, doanh nghiệp của bạn có khả năng tìm thấy mối tương quan giữa các dữ liệu mà trước đây được cho là vô dụng hoặc không có khả năng ảnh hưởng đến các tình huống khác nhau.
Data Engineer khác với Data Scientist ra sao?
Đối với các nhà khoa học dữ liệu để có thể mô hình hóa dữ liệu một cách hiệu quả, các thực tiễn quản trị dữ liệu phải được áp dụng để đảm bảo chất lượng và độ chính xác của dữ liệu.
Sau đó, các kỹ sư dữ liệu chịu trách nhiệm ban hành các chính sách này và giám sát chất lượng và hiệu suất dữ liệu. Các kỹ sư dữ liệu cũng cung cấp nguồn dữ liệu mà các nhà khoa học dữ liệu sử dụng để tạo mô hình dữ liệu.
Mặc dù các kỹ sư dữ liệu có thể thực hiện các chuyển đổi và tổng hợp quy mô lớn trên dữ liệu, nhưng cần phải có một phân tích để xác định cách dữ liệu nên được xử lý.
Kỹ sư dữ liệu phải biết dữ liệu có liên quan như thế nào và nó nên được thao tác như thế nào để tạo ra kết quả mong muốn.
Trong các ví dụ cơ bản, một kỹ sư dữ liệu có thể hợp tác với doanh nghiệp để vạch ra điều này, nhưng trong các hệ thống phức tạp hơn, một nhà khoa học dữ liệu cần phải phân tích thêm.
Trong một số trường hợp, mô hình dữ liệu có thể yêu cầu một thuật toán và quy trình biến đổi phức tạp hơn so với một kỹ sư dữ liệu tổng quát có thể xử lý.
Có thể có các phương trình toán học phức tạp và phân tích thống kê phải được lấy từ một mẫu thử nghiệm hoặc ví dụ quy mô nhỏ và được sản xuất hóa.
Đây là lúc bạn cần tuyển một ML Engineer (kỹ sư học máy).
Kỹ sư học máy (Machine Learning Engineer) là gì?
Kỹ sư học máy là giao điểm của kỹ thuật dữ liệu và khoa học dữ liệu.
Những kỹ sư này thường có nền tảng toán học vững chắc hơn một kỹ sư dữ liệu điển hình, nhưng không đến mức như một nhà khoa học dữ liệu.
Các kỹ sư này có thể tận dụng các khuôn khổ và công cụ kỹ thuật dữ liệu trong hệ sinh thái dữ liệu lớn, áp dụng các mô hình dữ liệu do các nhà khoa học dữ liệu tạo ra cho dữ liệu đó và sản xuất hóa quá trình triển khai các mô hình này.
Đây không phải là một nhiệm vụ đơn giản.
Các kỹ sư học máy cần phải thành thạo về cấu trúc dữ liệu và thuật toán, cả từ góc độ toán học và tính toán.
Để mô hình dữ liệu được sản xuất, dữ liệu phải được nhập vào mô hình và các tính toán chạy trong môi trường hiệu suất cao.
Điều này có nghĩa là có khả năng xử lý hàng terabyte dữ liệu thời gian thực để thúc đẩy các quyết định kinh doanh.
Các kỹ sư học máy làm việc với các nhà khoa học dữ liệu như thế nào?
Khi các nhà khoa học dữ liệu làm việc với dữ liệu để chứng minh các mô hình, công việc thường được thực hiện trong các môi trường như Python hoặc R, bên trong một sổ ghi chép phân tích như Jupyter.
Sổ này này chạy với một cụm để dịch các truy vấn thành một công cụ dành riêng cho nền tảng dữ liệu lớn như Spark.
Mặc dù cách tiếp cận này giảm thiểu kinh nghiệm phát triển và thời gian cần thiết để thu được giá trị, nhưng nó đòi hỏi thêm nhiều việc để sản xuất hóa. Thường bao gồm:
Kiểm tra chất lượng dữ liệu
Tối ưu hóa hiệu suất truy vấn
Tạo hệ sinh thái CI / CD xung quanh những thay đổi đối với mô hình
Đưa dữ liệu từ nhiều nguồn khác nhau vào mô hình dữ liệu
Học máy và các kỹ thuật khoa học dữ liệu cho các hệ thống phân tán
Mặc dù một số kỹ năng này trùng lặp với kỹ sư dữ liệu (nhập dữ liệu, kiểm tra chất lượng dữ liệu, v.v.), các trách nhiệm và kỹ năng cần thiết được tập trung đáng kể vào một số lĩnh vực kỹ thuật dữ liệu.
Những kỹ năng cần thiết của Data Engineer?
Không có câu trả lời đơn giản cho câu hỏi này – nhưng hãy cùng tìm hiểu một số điều cơ bản
Lưu trữ và tính toán dữ liệu
Dữ liệu có thể được lưu trữ ở nhiều định dạng tệp khác nhau trong hệ thống tệp và theo những cách khác nhau trong cơ sở dữ liệu và kho dữ liệu.
Mỗi định dạng khác nhau này được tối ưu cho một trường hợp sử dụng cụ thể và các kỹ sư dữ liệu chịu trách nhiệm tìm hiểu công cụ phù hợp cho công việc.
Ví dụ: nếu bạn đang lưu trữ dữ liệu trên đĩa trong một hồ dữ liệu, có một số tùy chọn phổ biến cho các định dạng dữ liệu:
Parquet
Avro
ORC
Các định dạng dữ liệu này thường được điều khiển bởi một trung tâm theo dõi vị trí của dữ liệu để truy vấn dữ liệu.
Tùy thuộc vào công cụ bạn đang sử dụng, cú pháp truy vấn, mẫu truy cập, hiệu suất và khả năng sẽ khác nhau. Các ví dụ phổ biến bao gồm:
Apache Hive
Databricks Delta Lake
AWS Glue Catalog
Dữ liệu cũng có thể được lưu trữ trong các nền tảng dựa trên luồng cho phép các hệ thống phân tán cao.
Đây thường là một kiến trúc pub / sub cho phép nhiều người tiêu thụ dữ liệu nhận các bản cập nhật từ một nhà xuất bản dữ liệu. Các ví dụ phổ biến bao gồm:
Apache Kafka
AWS Kinesis và AWS Kinesis Firehose
RabbitMQ
Khi dữ liệu đã được lưu trữ, thông thường nó sẽ cần được xử lý để đạt được trạng thái mong muốn.
Điều này có thể liên quan đến việc lấy dữ liệu từ nhiều nguồn khác nhau, kết hợp dữ liệu đó với nhau, thực hiện tổng hợp trên đó và sau đó đưa kết quả vào vị trí cuối cùng.
Có nhiều phương án tính toán thường được sử dụng trong quy trình dữ liệu:
Apache Spark
Databricks
AWS Glue
Đầu ra của các quy trình dữ liệu này sau đó thường sẽ được đưa trở lại vào một hồ dữ liệu, sử dụng các định dạng dữ liệu và vị trí truyền dữ liệu được đề cập bên trên.
Trong một số trường hợp, khách hàng muốn đưa dữ liệu này vào cơ sở dữ liệu hoặc kho dữ liệu như Snowflake hoặc AWS Redshift.
Các công cụ này cho phép điều chỉnh hiệu suất dữ liệu hơn nữa, trao quyền dữ liệu và tích hợp với công cụ của bên thứ ba.
Hiểu biết về Cloud và On-Premises
Nhiều công ty có hệ thống on-premises (tại chỗ) và đang chuyển sang các giải pháp dựa trên đám mây như Amazon Web Services (AWS) và Microsoft Azure.
Điều này đòi hỏi một tập hợp các kỹ năng khác nhau và các kỹ sư phải có khả năng hiểu được sự khác biệt trong cách các hệ thống này hoạt động.
Nói chung, khi làm việc với khối lượng công việc tại chỗ, các kỹ sư không tập trung vào thời gian thực thi và mức sử dụng bộ nhớ cho đến khi chúng trở thành những người hàng xóm xấu tính với các quy trình khác trên cùng một máy chủ hoặc cụm.
Vì công ty trả tiền cho phần cứng chứ không phải theo mô hình dựa trên mức tiêu thụ, nên việc cho phép các quy trình chạy lâu hơn một chút sẽ dễ dàng hơn là dành nhiều thời gian để tối ưu hiệu suất.
Tuy nhiên, khi làm việc trên nền tảng đám mây, nhiều giải pháp chạy trên mô hình dựa trên mức tiêu thụ được gắn với những thứ như sử dụng bộ nhớ, thời gian thực thi và yêu cầu lưu trữ.
Điều này có thể dẫn đến chi phí đáng kể khi chuyển trực tiếp khối lượng công việc tại chỗ lên đám mây.
Kỹ sư dữ liệu cần có khả năng hiểu các mô hình định giá khác nhau và điều chỉnh các giải pháp cho phù hợp.
Điều này có nghĩa là hiểu biết cơ bản về các chiến lược bán hàng, các khoản phí mà một công ty sẽ phải chịu và cách thực hiện các giải pháp trong cả hai hệ sinh thái.
Toán học
Đối với nhiều kỹ sư dữ liệu, quá trình chuyển đổi dữ liệu thành siêu thị data và các tập dữ liệu được sắp xếp không đơn giản như việc kết hợp một vài tập dữ liệu.
Trong nhiều trường hợp, việc tổng hợp cần được thực hiện dựa trên dữ liệu nguồn để tính toán những thứ như các giá trị thống kê như trung vị, độ lệch chuẩn và phương sai.
Toán học cũng rất quan trọng khi xem xét các cấu trúc dữ liệu khác nhau để lưu trữ dữ liệu hoặc các thuật toán để xử lý dữ liệu.
Điều quan trọng là phải hiểu các tác động về hiệu suất của việc lưu trữ dữ liệu trong một cấu trúc cụ thể hoặc thực hiện các thuật toán nhất định dựa trên một tập dữ liệu nhất định.
Ví dụ:
Bạn biết rằng dữ liệu của mình được lưu trữ và phân vùng theo ngày tải, nhưng bạn cần kết hợp dữ liệu đó dựa trên khóa doanh nghiệp (business key). Đối với một kỹ sư dữ liệu, đây là một tín hiệu đáng báo động.
Bằng sự hiểu biết về cấu trúc dữ liệu và thuật toán, kỹ sư sẽ hiểu rằng họ sẽ phải quét toàn bộ bảng trên dữ liệu, đọc từng phân vùng và tệp riêng lẻ để thực hiện hành động đó.
Điều này có thể ổn đối với các tập dữ liệu nhỏ, nhưng chắc chắn là không khả thi khi bạn đang ở trong hệ sinh thái Dữ liệu lớn.
Tập trung vào Chất lượng
Ngay cả khi quá trình nhập và quản lý dữ liệu của bạn được tối ưu hóa 100% và có hiệu suất cao, sẽ không ý nghĩa gì nếu dữ liệu không chính xác.
Một kỹ sư dữ liệu phải có khả năng hiểu kết quả cuối cùng là gì, cũng như các phương pháp và công cụ cho phép xác nhận dữ liệu.
Các kỹ sư dữ liệu có thể sử dụng các công cụ như Deequ và Great Expectations để cung cấp khuôn khổ và công cụ cho chất lượng dữ liệu và phát hiện lỗi dữ liệu.
Các bài kiểm thử phải được viết dựa trên dữ liệu để đảm bảo dữ liệu là như mong đợi và được giám sát về sự sai lệch trong dữ liệu.
Một data engineer lành nghề có thể lập hồ sơ, giám sát và cảnh báo khi dữ liệu nằm ngoài phạm vi và thông số có thể chấp nhận được.
Tại sao Kỹ thuật Dữ liệu lại Quan trọng hơn Bao giờ hết?
Kiến thức là sức mạnh – và nó không thể đúng hơn trong xã hội ngày nay. Các công ty lớn đang tạo, nhập và xử lý nhiều dữ liệu hơn bao giờ hết.
Dữ liệu là một thành phần quan trọng đối với tri thức và như chúng ta đã chứng minh qua các ví dụ khác nhau, quá trình biến dữ liệu thành tri thức có thể rất phức tạp.
Có nhiều cấp độ xử lý và phân tích dữ liệu khác nhau và có thể có những trường hợp trong tổ chức của bạn nơi mà kinh nghiệm trong lĩnh vực và thực tiễn kinh doanh cụ thể có thể cung cấp cho một cá nhân mức độ hiểu biết mà dữ liệu có thể sao lưu.
Tuy nhiên, lượng kiến thức mà Dữ liệu lớn có thể tạo ra về doanh nghiệp của bạn và tác động của nó đối với doanh nghiệp của bạn thường bị bỏ qua (và áp đảo).
Trong suốt bài viết này, chúng ta đã nói về các kỹ sư dữ liệu, nhà khoa học dữ liệu, kỹ sư học máy và cách mỗi người trong số họ có một vị trí cụ thể trong hệ sinh thái dữ liệu lớn.
Những chuyên gia này thường là những nguồn lực có kinh nghiệm và đắt tiền mà một tổ chức tuyển vào, tạo ra một rào cản gia nhập khó có thể vượt qua.
Tuy nhiên, chưa bao giờ có thời điểm quan trọng hơn để đầu tư vào các nguồn lực này.
Hãy cùng xem một số ví dụ về những gì các phương pháp này đã cho phép các công ty thực hiện.
Định giá động
Các nhà bán lẻ lớn như Amazon và các hãng hàng không thường sử dụng giá động cho hàng hóa của họ.
Điều này cho phép định giá cập nhật nhất dựa trên các mô hình dữ liệu được tạo bởi các nhà khoa học dữ liệu, được thực hiện bởi các kỹ sư học máy và được cung cấp bởi các kỹ sư dữ liệu.
Bạn có thể đã thường xuyên kiểm tra giá của các hãng hàng không để thử và kiếm được một món hời hoặc kiểm tra Amazon để xem liệu một mặt hàng cụ thể mà bạn quan tâm có được giảm giá hay ở mức giá tốt hơn so với các đối thủ cạnh tranh hay không.
Điều có thể bạn chưa biết là Amazon cập nhật giá lên đến 2.500.000 lần một ngày.
Điều này được hỗ trợ bởi mô hình dữ liệu do Amazon xây dựng để tối đa hóa lợi nhuận và duy trì tính cạnh tranh trong thị trường thương mại điện tử khổng lồ. Đây là cách công ty kiếm được 35% doanh thu hàng năm.
Một ví dụ khác về định giá động là các khách sạn Marriott.
Là một trong những chuỗi khách sạn lớn nhất trên thế giới, họ có hơn 6.500 khách sạn trên toàn cầu và giá phòng bị ảnh hưởng bởi nhiều yếu tố khác nhau.
Để định giá phòng khách sạn của mình một cách cạnh tranh, họ sẽ phải thuê hàng trăm đến hàng nghìn nhà phân tích để kiểm tra những thứ như tình hình kinh tế địa phương và toàn cầu, thời tiết, tình trạng sẵn có và hành vi đặt phòng, hủy đặt phòng,…
Điều này không khả thi trên quy mô lớn. Thay vào đó, họ sử dụng tính năng định giá động được xây dựng dựa trên các mô hình dữ liệu, dẫn đến doanh thu mỗi phòng tăng 5%.
Tiếp thị kỹ thuật số và phát triển sản phẩm
Trong nền kinh tế toàn cầu, điều quan trọng là phải hiểu rằng tiếp thị không phải là một động lực phù hợp với tất cả. Các chiến dịch tiếp thị và quảng cáo thành công sẽ trông khác ở Mỹ khi so sánh với Trung Quốc.
Ngay cả trong một quốc gia cụ thể, có thể có các khu vực của quốc gia có tín ngưỡng, kiểu thời tiết và sở thích khác nhau.
Để thúc đẩy doanh số bán hàng, thông thường trong tiếp thị là có một chiến dịch nhắm mục tiêu đến một đối tượng cụ thể.
Một ví dụ tuyệt vời về điều này là Airbnb, vào năm 2014 đã muốn điều chỉnh trải nghiệm tìm kiếm theo nhân khẩu học và địa lý.
Họ nhận thấy rằng các quốc gia châu Á nhất định thường có tỷ lệ thoát cao khi truy cập trang chủ.
Phân tích thêm dữ liệu, họ phát hiện ra rằng người dùng sẽ nhấp vào liên kết “Vùng lân cận”, bắt đầu duyệt ảnh và sau đó không bao giờ quay lại để đặt chỗ.
Để giải quyết vấn đề này, công ty đã tạo ra một phiên bản được thiết kế lại cho người dùng ở các quốc gia đó, thay thế các liên kết vùng lân cận bằng các điểm đến du lịch hàng đầu.
Điều này dẫn đến tăng 10% chuyển đổi.
Một ví dụ tuyệt vời khác là Coca-Cola, vào năm 2017 đã tiết lộ rằng hương vị Cherry Sprite được lấy cảm hứng từ dữ liệu thu thập từ các vòi nước uống tự phục vụ, nơi khách hàng tự pha chế đồ uống của họ.
Những chiếc máy này được thiết lập để theo dõi hương vị mà khách hàng đang trộn ở các khu vực khác nhau trên thế giới.
Sau đó, công ty chỉ cần tổng hợp các biến thể của sự kết hợp đồ uống và biến nó thành một mặt hàng có thể mua được.
Kết
Hy vọng rằng bạn sẽ rời khỏi hướng dẫn này với sự hiểu biết tốt hơn về những gì một data engineer làm và cách họ có thể giúp tổ chức của bạn đưa ra quyết định tốt hơn với dữ liệu.
DataOps Engineer (kỹ sư DataOps) là người nắm rất rõ quy trình xây dựng một sản phẩm dữ liêu và phân tích. Các hoạt động dữ liệu (data operation) hoặc sản xuất dữ liệu (data production) là một loạt các bước liên hoàn từ lấy dữ liệu thô, qua một loạt các bước xử lý và chuyển đổi, và xuất ra thành phẩm dưới dạng các bảng điều khiển, các dự đoán, kho dữ liệu hoặc bất cứ gì doanh nghiệp yêu cầu. Hãy coi các hoạt động dữ liệu giống như một nhà máy.
Hầu hết các tổ chức vận hành nhà máy dữ liệu này bằng phương pháp thủ công. Qua việc khảo sát, chúng tôi thấy các nhà khoa học dữ liệu và chuyên gia dữ liệu dành hơn 50% thời gian để thực hiện các thủ tục mang tính hỗ trợ cho các hoạt động dữ liệu.
Hình 1. Dây chuyền lắp ráp ô tô
Hình 1 là dây chuyền lắp ráp ô tô đầu thế kỷ 20. Trong hình, mọi người xếp thành một hàng để lắp ráp các linh kiện. Rất nhiều tổ chức dữ liệu điều hành các hoạt động dữ liệu giống như một nhà máy sản xuất ô tô hàng trăm năm tuổi. Cũng như các công ty ô tô giảm chi phí bằng cách sản xuất hàng loạt, các công ty ở năm 2021 cũng đưa kỹ sư dữ liệu (data engineer) và nhà khoa học dữ liệu (data scientist) vào “dây chuyền”. Hãy tưởng tượng nếu một công ty ô tô đi yêu cầu các kỹ sư thiết kế đi chế tạo chúng thử mà xem. Đó là tình trạng của phân tích dữ liệu ngày nay.
Hình 2. Nhà máy tự động
Kỹ sư DataOps giúp biến đổi những thứ trong Hình 1 thành nhà máy tự động (Hình 2). Các quy trình và luồng công việc được thiết kế và tự động hóa cao. Còn các kỹ sư, nhà khoa học và phân tích dữ liệu thì ở văn phòng, thực hiện việc lập trình rô-bốt và thiết kế các quy trình tự động để tạo ra các phiên bản sản phẩm được cải tiến liên tục, tức là các phân tích.
Kỹ sư DataOps thiết kế dây chuyền dữ liệu để các kỹ sư dữ liệu và nhà khoa học dữ liệu có thể phân tích thông tin nhanh chóng và ít sai sót nhất có thể. Có thể nói rằng Kỹ sư DataOps là người nắm rõ quy trình và luồng công việc tổng thể, còn nhà khoa học dữ liệu và những người khác thì làm việc bên trong quy trình đó.
Vậy DataOps là gì?
DataOps là một tập hợp các phương pháp thực hành, chuẩn mực văn hóa và các mô thức kiến trúc giúp cho các chuyên gia dữ liệu phân phối giá trị một cách nhanh chóng.
DataOps cho phép:
Thử nghiệm và đổi mới nhanh chóng để cung cấp thông tin phân tích cho khách hàng
Tỷ lệ lỗi thấp
Cộng tác với nhiều nhóm người, công nghệ và môi trường phức tạp
Đo lường và giám sát kết quả rõ ràng
DataOps thiết lập một cổng xử lý để tự động hóa các luồng sản xuất dữ liệu và phát triển phân tích để đội dữ liệu (data team) hoạt động hiệu quả, đổi mới và ít mắc lỗi. Trong bài này, chúng ta sẽ khám phá vai trò của Kỹ sư DataOps trong việc thúc đẩy tổ chức dữ liệu đạt được mức năng suất cao hơn.
Hình 3. Value Pipeline và Innovation Pipeline
Hành trình của dữ liệu
Quy trình dữ liệu (The Data Pipeline) là một chuỗi các bước chuyển hóa dữ liệu thô thành thông tin phân tích (insight) để tạo ra giá trị. Quy trình này đi băng qua nhiều vai trò và tổ chức. Các bước trong quy trình được biểu diễn thành vòng tròn trong Hình 3. Các kỹ sư dữ liệu, nhà khoa học, nhà phân tích, ban quản trị và các vai trò khác làm việc bên trong các vòng tròn này hoặc tạo các phân đoạn quy trình kết hợp được với những quy trình khác.
Quy trình giá trị (The Value Pipeline) đại diện cho các hoạt động dữ liệu mà ở đó dữ liệu được chuyển đổi thành các biểu đồ, đồ thị và các phân tích khác có giá trị cho tổ chức.
Còn Quy trình đổi mới (The Innovation Pipeline) thì bao gồm việc phát triển phân tích, QA (quality assurance), triển khai và phần còn lại của quy trình quản lý thay đổi cho Quy trình giá trị.
Các chuyên gia dữ liệu hoạt động tại nhiều điểm khác nhau trong những quy trình này.
Nói chung, chúng ta muốn chắc chắn rằng Quy trình giá trị sẽ thực thi mà không phát sinh lỗi và chúng ta muốn triển khai mạch lạc các phân tích mới mà không vi phạm bất kỳ điều gì hoặc sinh ra phản ứng phụ.
DataOps Engineer chính là người giúp cho toàn bộ hệ thống hoạt động tốt hơn. Nếu tổ chức dữ liệu muốn vận hành Quy trình giá trị mạnh mẽ như nhà máy 6 sigma (six sigma factory), nó phải có khả năng thực hiện và triển khai các cải tiến quy trình nhanh chóng như một startup ở Silicon Valley.
Kỹ sư dữ liệu thực hiện việc chuyển hóa dữ liệu. Sản phẩm của họ là dữ liệu. Sản phẩm của nhà khoa học dữ liệu là mô hình và phân khúc. Sản phẩm của nhà phân tích dữ liệu là biểu đồ, đồ thị và biểu diễn trực quan. Còn Kỹ sư DataOps vẽ ra một đường quanh các vai trò này và thúc đẩy sự cộng tác tốt hơn trong data team.
Khi nào được coi là “Hoàn thành”
Nhiều người làm dữ liệu có cách hiểu rất hạn hẹp về “hoàn thành”. Chẳng hạn một người đang xây dựng một loạt SQL hoặc một sổ Jupyter. Họ hoàn thành phần việc của mình và bàn giao cho một người khác thì họ đã “xong” nhiệm vụ rồi chăng?
Định nghĩa hạn hẹp về 2 chữ “hoàn thành” mà nhiều chuyên gia dữ liệu sử dụng chỉ đúng ở trong môi trường không cần biết hay không quan tâm đến trở ngại của những vai trò khác như triển khai, giám sát và duy trì thành phần đó. Một chuyên gia như vậy chỉ tập trung vào nhiệm vụ, chứ không phải vào giá trị. Khó khăn sẽ xảy ra nếu bạn thấy những điều này trong team data:
Quăng nó qua production đi – để bọn họ tự mò
Định nghĩa “hoàn thành” là “Tôi xong rồi, không đụng vào nữa nhé”.
“Tôi chỉ lo đúng việc của mình”
Nếu có vấn đề thì đó là “Vấn đề của ai đó, không phải tôi”
Giả câm, giả điếc
Tập trung vào nhiệm vụ, không màng tới giá trị
Tập trung vào dự án, bỏ bê sản phẩm
“Hy vọng mọi thứ suôn sẻ”
Dựa dẫm vào kiểm thử thủ công
Không muốn nhận ca khó
DataOps có cái nhìn rộng hơn, tổng quan hơn.
“Hoàn thành” nghĩa là chức năng đó chạy tốt trong môi trường production và làm cho khách hàng / người dùng hài lòng. Thay vì tập trung vào một nhiệm vụ, kiểm thử nhỏ lẻ và ít phản hồi thì DataOps tập trung vào việc tăng giá trị. Thông qua kiểm thử tự động, DataOps hợp thức hóa sự cộng tác nhuần nhuyễn giữa kiểm thử, giám sát, theo dõi, triển khai và phối hợp nhiệm vụ (Hình 4).
Hình 4. DataOps Engineer thúc đẩy sự cộng tác trong data team
Tự động hóa Nugget
Các nhà khoa học và phân tích dữ liệu tạo ra cái gọi là nugget of code (cụm mã). Các nugget có thể là mã ETL làm nhiệm vụ điều khiển Informatica (1 công cụ), chuyển đổi SQL, một chút Python hoặc XML. Bất kể tính nhất quán hay mục đích của nó là gì, thì các nugget phải được kiểm tra kỹ lưỡng trước khi được đưa vào các dây chuyền lớn hơn (quy trình).
Dưới đây là các ví dụ về các cách mà Kỹ sư DataOps làm việc với “cụm mã” trong hệ thống DataOps:
Bổ sung vào quy trình
Tạo kiểm thử
Vận hành nhà máy
Tự động triển khai
Làm với nhiều người
Đo lường thành công
Bật chế độ DataOps tự phục vụ
Các kỹ sư DataOps thường không giải quyết các vấn đề dữ liệu bằng cách tạo ra các “nugget”. Mà họ giải quyết các vấn đề về quy trình bằng cách sử dụng tự động hóa vào kiểm thử, triển khai và duy trì các nugget này trong hệ thống. Bằng cách tự động hóa công việc quản lý liên quan đến các nugget này, Kỹ sư DataOps cho phép người tạo nugget làm việc nhanh và liên tục hơn.
DataOps áp dụng tự động hóa để làm mạch lạc luồng công việc. Theo nguyên tắc chung, bất kỳ hoạt động nào được thực hiện thủ công từ ba lần trở lên đều phải được tự động hóa. Kỹ sư DataOps tạo ra các lịch trình tự động và lịch trình điện toán đám mây.
Dưới đây là một số ví dụ phổ biến về tự động DataOps:
Tự động hóa production – thay thế các thủ tục thủ công để thực thi các hoạt động dữ liệu bằng tự động hóa
Theo dõi / kiểm thử dữ liệu production – tạo các bài kiểm thử để phát hiện lỗi trước khi đưa đến khách hàng, theo dõi các quy trình sản xuất và phát triển theo thời gian thực
Môi trường tự phục vụ – cung cấp cho/đội ngũ cách thức tạo dữ liệu và các công cụ phù hợp theo nhu cầu
Kiểm thử hàm và hồi quy – tự động hóa kiểm thử phát triển và triển khai
Tự động hóa dữ liệu kiểm thử – tạo dữ liệu kiểm thử theo yêu cầu
Tự động hóa triển khai – triển khai với thao thác thủ công tối thiểu
Các thành phần được chia sẻ – chuẩn hóa và thường xuyên tái sử dụng “các nugget”, các quy trình và hạ tầng
Đo lường quy trình – xây dựng bảng điều khiển cho mọi khía cạnh của vòng đời dữ liệu để có tính minh bạch.
DataOps Engineering là về việc thực hiện các quy trình vô hình và làm cho chúng rõ ràng hơn. DataOps xác định hoặc dự đoán các lỗi trong tương lai để chúng có thể được giải quyết sớm và tránh những ảnh hưởng tiêu cực đến sự tổng quan và phân tích người dùng.
Những thách thức khi triển khai tự động hóa dữ liệu phản ánh một số khó khăn sau:
Không ai chịu trách nhiệm
Không đủ thời gian làm tự động hóa
Không ai quan tâm
Ai cũng lo làm tác vụ, thay vì xây dựng quy trình tốt hơn
Cho rằng tự động hóa không quan trọng bằng làm dữ liệu
Không như nhà phát triển phần mềm, dữ liệu không thể tự động hóa được
Làm thủ công là cách để hoàn thành công việc
Khi một nhiệm vụ như tự động hóa không được công nhận là quan trọng, không ai chịu trách nhiệm về nó. Trong nhiều tổ chức dữ liệu, có quan điểm cho rằng trở thành nhà khoa học dữ liệu là hình thức đóng góp cao nhất. Do tác động của tự động hóa lên năng suất của nhóm, không có gì ngạc nhiên khi các Kỹ sư DevOps hàng đầu là một trong những vị trí được trả cao nhất trong ngành phần mềm.
Mục tiêu của kỹ sư DataOps là tự động hóa các quy trình của tổ chức:
Giảm lãng phí.
Tăng cường tái sử dụng. Bớt “sáng tạo lại bánh xe”
Giảm sai số và thời gian thất bại.
Tăng cường kiểm soát phiên bản.
Phát hiện chênh lệch và cải thiện việc kiểm thử.
Đảm bảo các tiêu chuẩn bảo mật dữ liệu được áp dụng vào quy trình.
Thực hiện báo cáo về mọi mặt của quy trình và vòng đời dữ liệu của data team
Kỹ sư DataOps cũng là bà con với Kỹ sư DevOps, nhưng quen thuộc với các công cụ và phương pháp của hệ sinh thái dữ liệu hơn. Điều tuyệt vời và đầy thách thức ở vai trò này là nó đòi hỏi một số kỹ năng khác nhau trong nhiều lĩnh vực.
Bộ kỹ năng cho Kỹ sư DataOps như sau:
Một ngôn ngữ script: Python, Bash
Ngôn ngữ dữ liệu: SQL
Kiểm soát mã nguồn: git
Công cụ DataOps: DataKitchen
Công cụ cấu hình DevOps: Terraform, Puppet, Docker / K8s
Kỹ năng quy trình: Các phương pháp & công cụ Agile như JIRA
Làm quen với chuỗi công cụ mà các kỹ sư dữ liệu, nhà khoa học, nhà phân tích và ban quản trị sử dụng
Với tư cách là người quản lý hoặc trưởng nhóm, bạn có thể tự hỏi liệu mình có cần thuê Kỹ sư DataOps hay không và cần dành bao nhiêu tài nguyên của nhóm cho DataOps. Không có một câu trả lời đúng phù hợp với tất cả các tổ chức.
Các nhóm phát triển phần mềm tiên tiến dành khoảng 23% thời gian của họ cho DevOps. Các nhóm dữ liệu thì dành khoảng 3% thời gian của họ cho các nhiệm vụ DataOps. Chúng tôi khuyên bạn nên tăng mức này lên khoảng 15%. Điều đó có thể đạt được bằng cách kêu gọi sự tham gia của mọi người hoặc thuê một đội chuyên nghiệp từ bên ngoài. Vấn đề ở đây là đầu tư vào DataOps sẽ mang lại rất nhiều lợi ích.
Hình 5. Phân bổ thời gian trước và sau DataOps
Việc đầu tư vào DataOps tác động đến toàn bộ data team (hình 5). Với DataOps, các kỹ sư dữ liệu, nhà khoa học, nhà phân tích và người dùng dành nhiều thời gian hơn để tạo ra giá trị, giảm trục trặc kỹ thuật hoặc triển khai các thay đổi vào production và ít tốn thời gian đi sửa lỗi, họp hành và quản lý các phát sinh.
Hình 6. DataOps giảm thời gian triển khai và giảm lỗi
Các thang đo chân chính mà DataOps tác động là độ trễ và lỗi triển khai (hình 6). DataOps cắt giảm thời gian triển khai từ tuần / tháng xuống giờ / phút. Nó làm giảm đáng kể tỷ lệ lỗi dữ liệu trong hầu hết các tổ chức dữ liệu xuống gần như bằng không. Khi năng suất cao, ít sai sót và người dùng hài lòng, môi trường làm việc của nhóm dữ liệu sẽ thú vị hơn rất nhiều. Nghe có vẻ kì khôi, nhưng DataOps mang niềm vui vào phân tích dữ liệu và nụ cười tươi thắm cho data team.
