Cốt cách và cách code

Khi mà ai cũng bảo là phải học code đi, tuy nhiên khi học code thì sẽ có nhiều thể loại nhiều cách thức khác nhau

Data Engineering và cách tiếp cận vấn đề

Câu chuyện này bắt đầu từ một ngành mà mình cảm thấy là mình hiểu khá là rõ, đó là Data Engineering. Ngành Data Engineering cũng phát triển khá mạnh trong những năm gần đây, khi Big Data lên ngôi và tất cả các doanh nghiệp đều hướng đến chuyển đổi số và bắt đầu xây dựng những kho dữ liệu của mình. Cùng với sự phát triển của Data Engineering (mình sẽ viết là DE cho ngắn gọn), những ngành lân cận và sử dụng sức mạnh của Data cũng rầm rộ phát triển, như Data Analytics, Data Science, Machine Learning Engineer, thu hút rất nhiều người trong và ngoài ngành tech cùng nhảy vào học hỏi.

Photo by Stephen Dawson on Unsplash

Nằm giữa Data và Engineering, DE là ngành thu hút được nhân lực từ cả hai phía, từ những bạn biết phân tích dữ liệu mà muốn nhảy vào những thứ system và technical hơn, cho đến các bạn đang làm dev mà cũng muốn nhảy sang nghiên cứu về data processing, về big data system. DE trở thành một mảnh đất mới, nơi giao thoa giữa 2 nền văn hoá có nhiều sự khác biệt.

Với kinh nghiệm đã loay hoay ở cả hai bên đầu chiến tuyến, mình nhận thấy là có một sự khác biệt nhẹ về cách mà các bạn xuất phát từ gốc Data và các bạn có gốc Developer tiếp cận vấn đề và xây dựng giải pháp. Các engineering practices thì có thể được nới lỏng ra, cách xây dựng logic chuyển sang chạy trên các thể loại notebooks, các phương pháp testing và debugging trở nên khó khăn hơn. Thay vì xử lý các data gọn ghẽ đầy đủ typing và format từ databases, nay thì các bạn lại phải làm quen với những data sources với đủ thứ vấn đề, từ thiếu định dạng, dữ liệu thừa thiếu hoặc thậm chí còn có thể sai.

Code, là tiếng nói chung của cả hai bên trong việc cùng giải quyết được những vấn đề trước mắt. Tuy nhiên, vì điểm bắt đầu khác nhau, nên tư duy giải quyết vấn đề của dân Data và dân Dev sẽ khác nhau, và dẫn đến sự khác nhau về cách họ dùng code để xây dựng giải pháp.

Cách code của dân Dev và dân Data

Nói là dân Dev hay là dân Data thì cũng không chưa chuẩn xác lắm, mà chắc phải xuất phát từ những bài toán mà từ đầu mọi người đã được trained, để giải.

Tư duy theo steps

Dev ở đây, là mình sẽ nói về các bạn software developer, và cách các bạn được đào tạo và hướng dẫn để giải toán các bài toán từ phía software. Khi xây dựng và thiết kế một tính năng ở trong một sản phẩm software, bất kể là bạn làm backend hay là frontend, thì thứ mà mọi người luôn nhắm đến đó là workflow mà bạn cần xử lý. Khi bạn nhìn một vấn đề từ phía của một user và hệ thống, từ hành động hoặc behavior của users, sẽ dẫn đến các sự thay đổi tuần tự step-by-step mà bạn sẽ mường tượng ra. Bạn có thể gạch đầu dòng và viết ra logic ở từng bước một. Ví dụ đi, bạn làm một trang ecommerce đơn giản, và user ấn vào trang của một sản phẩm; server của bạn sẽ làm một số step (mình viết đơn giản thôi)

• Step 1: Frontend dựng lên khung html của trang

• Step 2: Đồng thời, Frontend gửi API call đến backend để lấy các thông tin về sản phẩm

• Step 3: Backend truy vấn từ các service khác nhau như là Inventory, SKU, Promotion và dựng lên API response có các thông tin về sản phẩm, giảm giá và hàng tồn kho, cùng các sản phẩm có liên quan

• Step 4: Frontend nhận thông tin từ backend và render ra trang sản phẩm

Mỗi bước ở bên trong các step ở trên có thể tách nhỏ hơn ra thành các bước cụ thể, tuỳ xem mình có thể viết nó cặn kẽ đến đâu. Ví dụ như step 3 có thể tách thành các bước 3.1, 3.2, 3.3 nếu mình viết đầy đủ ra truy vấn đến các service nhỏ hơn, hoặc là các truy vấn vào đến tận database, hoặc là xử lý các lỗi khi API có vấn đề.

Khi các bài toán được xử lý và break nhỏ thành các steps thế này, thì đặc điểm của bài toán là expectation của nó rất là rõ ràng. Khi làm đến step nào, thì bạn đã biết là kết thúc của cái step thì chuyện gì sẽ phải xảy ra, và có đầy đủ expectation ở từng step của quá trình. Và bởi vì bạn hiểu rõ được chuyện gì nên xảy ra ở bước ngay sau đó, bạn sẽ có thể đặt debugger, đặt breakpoint và chạy đoạn code từng dòng một và nắm bắt xem chuyện gì đang xảy ra, mình làm gì không đúng trong đoạn xử lý này mà dẫn đến sai sót.

Với tư duy này, việc của người viết code, đó là biến những expectation này thành những dòng code, và đảm bảo cho nó chính xác từng bước từng bước. Nó như xây dựng một căn nhà theo bản vẽ thiết kế, chi tiết và tỉ mỉ để đạt đúng yêu cầu được đề ra.

Tư duy theo insight

Về hướng giải quyết của data, thì bài toán tiêu biểu lại là khi bạn có một đống dữ liệu trước mắt, và bạn có một vấn đề mù mờ là phải đào ra các insight có giá trị từ đống dữ liệu trước mắt. Đó là vấn đề của Data exploratory analysis.

Bởi vì bạn không có một hướng đi nào cụ thể, không có expectation nào nhất định với cái đống data trước mắt, thế nên bạn sẽ phải thử, play around với cái đống dữ liệu đó. Có thể là print thử ra 10 dòng và kiểm tra xem dữ liệu trước mắt nó thế nào, định dạng định nghĩa nó ra làm sao; tìm min, max, quartile của các dữ liệu trước mắt xem nó ra làm sao, group by count để đếm thử số lượng xem nó distribute thế nào. Bạn phải vọc vào và ngâm cứu cái đống dữ liệu trước mắt và xem nó có cái gì đã.

Khi bắt đầu nắm rõ hơn về characteristics của dữ liệu trước mắt, đó là lúc bạn nghiên cứu xem cách xử lý dữ liệu thế nào; có cần phải data cleaning, như thế nào là data sạch, như thế nào là data sử dụng được hay là không, có cần sampling hoặc là loại bỏ extremes. Đó là khi bạn bắt đầu xây dựng ra các giả thuyết của mình (hypothesis), và sau đó lập ra cách để chứng minh hoặc loại bỏ giả thuyết của mình.

Giả thuyết được đặt ra sẽ có sai có đúng, và người xử lý data sau khi tìm được hướng đi hợp lý, họ sẽ lưu lại kết quả của bước trước, đi theo giả thuyết đã tìm ra và tiếp tục đến khi nào họ đào ra được insights về dữ liệu trước mắt. Tuy nhiên, nếu họ dò được và cảm thấy mình đi sai hướng, hoặc là xử lý dữ liệu chưa đủ, họ có thể sẽ phải nhảy lại vào bước trước, để bổ sung vào những bước họ đã đi ở phía trên.

Với phương thức vừa đi vừa dò đường như vậy, các bạn với gốc data analytics sẽ thường tư duy theo chặng. Họ nghiên cứu và mày mò cách xử lý dữ liệu, và khi đó họ sẽ đi qua được những chặng trong giai đoạn xử lý, họ sẽ lưu lại các bước trước đó của họ cùng với các ghi chép hoặc phân tích tạm thời. Cách xử lý dữ liệu này vô cùng phù hợp khi dùng với notebook, xây ra chặng đường đãi cát tìm vàng, biến từ data thô ban đầu thành những insights có giá trị.

Cách code là một spectrum

Hai cách xử lý vấn đề mà mình giải thích ở trên rất là khác biệt, như mình mô tả là xây dựng công trình với đãi cát tìm vàng; đơn giản vì bài toán được đề ra cũng rất khác biệt, nên cách tiếp cận vấn đề nó cũng tự nhiên khác nhau.

Nhưng đó cũng chỉ là hai thái cực đối lập, và còn rất nhiều thứ khác nằm ở giữa. Hai ví dụ mình lấy là feature development và data exploratory analysis, nằm ở hai đầu đối lập, và nó xây dựng thành một spectrum để giải toán các bài toán ở giữa.

Giả dụ như Data Integration, khi bạn phải tích hợp dữ liệu từ các bên với nhau, ví dụ một bài toán đơn giản có thể là bài toán kéo dữ liệu từ hệ thống về Data Lake. Bạn phải phân tích dữ liệu của data source, tìm từ format, định dạng đến definition, các trường hợp cần phải làm data cleaning hoặc là cast sang đúng định dạng mà bạn cần. Tuy nhiên, sau khi đã xây dựng được cách tiếp cận dữ liệu, thì integration của bạn sẽ được xây thành các workflow, và các bước biến chuyển data của bạn sẽ phải codify thành một logic chặt chẽ step-by-step. Tuỳ vào mức độ chặt chẽ của integration, mà bạn cũng có thể xây dựng test cases, integration tests, đầy đủ như một bài toán xây dựng feature. Nó nằm trên spectrum giữa hai thái cực mà mình viết, và nó lại gần với bên Engineering hơn.

Nhưng với bài toán Data Transformation and Visualization, thì nó lại chuyên sâu hơn về Data. Bạn cần phải biến từ data dạng thô thành multidimensional data cube, để bạn có thể xây dựng visualization, slide and dice theo các hướng khác nhau của data cube. Bạn sẽ vẫn phải làm các steps về xử lý dữ liệu và làm đến data modeling exercise; tuy nhiên, bạn lại không có nhiệm vụ về phân tích đến insights cuối cùng. Bạn sẽ phải nghiên cứu và phân tích data rất nhiều để có thể xây dựng ra được data cube hợp lý, đủ các trường dimensions và facts, để thể hiện ra đủ các khía cạnh mà một người xem report hoặc dashboard có thể ngẫm nghĩ và đào sâu hơn; sau đó bạn mới phải xây các bước transformation thật là chặt chẽ đầy đủ để đảm bảo những dữ liệu thô sẽ được biến đổi một cách chính xác và có thể kiểm tra và validate một cách dễ dàng. Một bài toán thiên về data nhiều hơn, nhưng vẫn cần engineering mindsets để đảm bảo về độ chặt chẽ của các bước xử lý trước.

Đương nhiên, không thể thiếu khi nhắc đến các bài toán của data science. Data Science thì đôi khi có thể chia thành 2 giai đoạn khác nhau. Giai đoạn nghiên cứu tìm tòi, để xây dựng model ban đầu, xây dựng params và hyperparams, thì có thiên nhiều hơn về mặt data processing. Giai đoạn về productionize/model serving, khi các model được chuyển lên để làm inference, hoặc reinforcement learning, thì lại thêm khá nhiều yếu tố về engineering, làm sao để thiết lập các workflow cho việc xử lý dữ liệu, store, retrain và update lại model đang có.

Kết

Tuy cùng là code để xử lý bài toán, nhưng cách tư duy về code của Data và Engineering lại có một chút khác biệt; nó tạo thành một cách spectrum về tư duy xử lý, đi cùng với bài toán cần phải giải. Có thể bạn sẽ thiên về một bên nào đó hơn, nhưng chắc chắn là nên biết cả hai, và có một sự thấu hiểu từ cả hai phía, để các bạn có thể làm việc cùng nhau tốt hơn.