Thầy Hồ Tú Bảo - Tri thức ẩn và tri thức hiện

Với nhiều năm nghiên cứu về trí tuệ và nhận thức, thầy Hồ Tú Bảo đã giúp mình và khán giả “điểm danh chỉ mặt” những vùng tri thức mà con người vẫn còn mù mờ, bằng một cách rất dễ hiểu. Trong kho tàng chia sẻ đồ sộ của thầy, mình đặc biệt ấn tượng với khái niệm tri thức ẩn và tri thức hiện. Theo cách mình hiểu, tri thức hiện là những kiến thức có thể dữ liệu hoá, đo đạc và số hoá - thứ mà con người có thể truyền đạt cho máy. Còn tri thức ẩn lại thuộc về cảm xúc, trực giác, mùi vị, tâm trạng - những điều không thể mã hoá, và chính là phần “soul” khiến con người khác biệt với máy móc. Một quyết định “đúng đắn” - không chỉ “chính xác” - là kết quả của sự kết hợp hài hoà giữa hai loại tri thức ấy.

Thầy Nguyễn Phụ Hoàng Lân - Tư duy đặt câu hỏi và khám phá tri thức

Phong thái tự tin và nền tảng toán học vững chắc của thầy khiến mình tin rằng thầy là một “cây đa cây đề” trong giới học thuật. Thầy nói nhiều về cách đặt câu hỏi và tự học - những điều tưởng đơn giản nhưng lại là cốt lõi để mở ra tri thức. Mình đặc biệt tâm đắc với quan điểm: để hiểu một vấn đề mới, ta phải “thử - nháp - dự đoán” để nhận ra quy luật. Tri thức không đến từ việc học thuộc, mà từ quá trình tự mình mày mò, sai và sửa. Những định lý mà mình nhớ nhất là những bài toán mà mình phải tự vật lộn để chứng minh.

Cô Lê Mai Hương - Khi AI bước vào cánh cổng trường học

Với vai trò là một nhà quản lý giáo dục, cô Hương chia sẻ góc nhìn rất thực tế về việc AI đang len lỏi vào từng ngóc ngách của hệ thống giáo dục - từ giảng dạy, đánh giá cho đến vận hành. Cô giúp mình nhận ra rõ hơn cả cơ hội lẫn thách thức mà AI mang lại, cũng như cách các nhà trường đang thử nghiệm để ứng dụng công nghệ mà không đánh mất tinh thần giáo dục.

Cô Tống Liên Anh - Giữ bản thể co người giữa cơn bão AI

Cô Liên Anh đặt ra một câu hỏi khiến mình trăn trở: “Nếu phụ thuộc vào AI, liệu chúng ta có còn là chính mình?”. Cô chia sẻ trải nghiệm tại Phần Lan - nơi con người được khuyến khích kết nối lại với thiên nhiên - như một lời nhắc nhở rằng, giữa guồng quay công nghệ, ta đừng quên gốc rễ bản thể con người. Từ đó, mình tự hỏi: có phải chúng ta đang quá tập trung và bị cuốn vào cơn bão này mà quên mất chính mình?

Xuyên suốt buổi toạ đàm, điều mình cảm nhận sâu sắc nhất là: dù có trong tay những công cụ mạnh mẽ như AI, con người vẫn cần rèn luyện trí óc và nuôi dưỡng tâm hồn. Chỉ khi đó, ta mới có thể sử dụng công cụ một cách hiệu quả, thay vì bị nó dẫn dắt, phụ thuộc hay tệ hơn là thoái hoá trí tuệ, méo mó nhân cách.

P/S 1: Thiết kế toà nhà Viện nghiên cứu cao cấp về Toán đẹp quá <3.
P/S 2: Logo của VIASM giống với cục Prime Radiant trong Foundation của Isaac Asimov nhỉ?

Ghen tuông là một cảm xúc thật kỳ lạ.
Nó khiến ta vừa đau, vừa xấu hổ, nhưng cũng khiến ta nhận ra mình vẫn còn biết yêu, biết sợ mất đi điều quý giá. Ẩn sau ghen tuông là mong muốn rất con người: được yêu, được quan tâm, được là ai đó đặc biệt trong lòng người khác.

Khi tình yêu trở thành sự nắm giữ

Trong tình yêu, thường thấy nhất ở tình yêu đôi lứa, con người thường mang theo bản năng chiếm hữu.
Ta muốn người mình yêu chỉ thuộc về bản thân mình - như thể yêu là được toàn quyền giữ lấy. Ta nghĩ rằng: “Nếu người ấy yêu tôi, họ không thể yêu ai khác.”
Nhưng tình yêu và sự sở hữu thật ra là hai thứ khác nhau. Sở hữu là muốn giữ lại, còn tình yêu thật sự là muốn trao đi.

Khi tình yêu bị nhốt trong chiếc lồng của sự sở hữu, nó không còn là dòng chảy tự nhiên nữa. Nó trở nên tù túng, khép kín, và dần héo úa. Ta không còn yêu người kia như cái cách họ tồn tại, mà chỉ yêu cảm giác họ mang lại cho ta. Và khi cảm giác ấy bị lung lay, khi ta bất an rằng cảm giác họ mang lại cho ta không đáp ứng đủ cho ta, nỗi sợ từ đó khởi sinh. Nỗi sợ ấy chính là bản chất của ghen tuông.

Nỗi sợ giấu trong trái tim

Thực ra, ghen tuông không xuất phát từ sự xấu xa, mà từ nỗi sợ.
Sợ mất đi tình cảm, sợ không còn được quan tâm, sự không còn là “duy nhất”. Cái sự sợ hãi ấy bắt nguồn từ cảm giác chưa đủ đầy bên trong - khi ta cần tình yêu của người khác để chứng minh giá trị của mình. Hay rộng hơn, ta cần một sự nuôi dưỡng cảm xúc từ ngoại cảnh.

Vì thế, khai ai đó ghen, điều họ thực sự cần không phải là thêm lời hứa, mà là sự an toàn nội tâm - cảm giác rằng, ngay cả khi bị quên lãng, họ vẫn đủ để được yêu thương, vẫn có thể tự yêu chính mình.

Bản chất tình yêu là ánh sáng

Tình yêu đẹp nhất là khi nó được tự do lan toả.
Giống như ánh sáng mặt trời, nó toả ra vì bản thân nó là ánh sáng, chứ không cần sự tán dương khen thưởng chấp nhận đáp trả từ bất kỳ ai.

Khi ta yêu mà không mưu cầu, không muốn giữ, không muốn chiếm, tình yêu trở nên trong trẻo lạ thường.
Ta không mất hạnh phúc khi người mình yêu cũng biết yêu thương người khác, vì ta hiểu rằng: yêu thương không phải chiếc bánh chia phần, mà là ngọn lửa, càng truyền đi càng trở nên rực rỡ.

Tự đủ để không cần sở hữu

Muốn bước ra khỏi ghen tuông, ta không cần phải gồng lên ngăn cản tâm trí bằng chuỗi lệnh cấm “đừng ghen, ghen là xấu xí”, mà cần học cách nuôi dưỡng sự đủ đầy trong trái tim mình.

Khi ta cảm thấy đủ, ta không còn sợ mất.
Khi ta hiểu yêu thương là dòng chảy tự nhiên, ta sẽ không cố chặn nó lại.
Khi ta biết cách yêu chính mình, ta sẽ nhìn người khác bằng ánh mắt bao dung hơn.

Và rồi, như một điều trong sách vở hay thước phim, ta bắt đầu có thể thương được cả người từng làm mình tổn thương. Vì khi đó, ta nghiệm ra rằng, ai cũng từng sợ hãi như ta, từng yếu đuối, từng lo mất đi điều mình yêu.

Chiếc bóng của yêu thương

Ghen tuông là chiếc bóng của tình yêu.
Bóng càng dài khi ánh sáng trong lòng ta yếu ớt.
Nội tâm đủ sáng, bóng sẽ tự tan.

Ta không cần giữ tình yêu bằng tay.
Chỉ cần giữ ngọn lửa trong tim vẫn cháy.
Vì tình yêu thật sự, chẳng thể nào rời bỏ người biết yêu bằng tự do.

Đây là một đoạn trích trong cuốn Utopia của Thomas More, nói về cách mà một hội đồng thành phố nên vận hành để tránh những quyết định vội vàng, bồng bột. Đọc đến đoạn này, ở thời điểm hiện tại của nhận thức, mình cảm thấy đồng cảm sâu sắc. Thực hành “chậm lại” — sống trong khoảnh khắc thay vì chỉ lướt qua — giúp mình thấy rõ hơn sự tinh tế của thực tại, mở rộng lòng đồng cảm và sự thấu hiểu.

Phản ứng đầu tiên của mình trước một thông tin mới thường là phản kháng. Nếu không có khoảnh khắc lắng lại, có lẽ mình đã bỏ qua nhiều điều thú vị. Khi cho bản thân một nhịp chậm, mình có cơ hội nén cảm xúc, để thông tin mới hòa vào nhận thức, rồi từ từ phối kết, tìm cách thấu hiểu, cảm thông, xác định ranh giới và củng cố niềm tin. Ngoại trừ những người cố tình đưa ra thông tin sai lệch vì mục đích không trong sáng, mình tin rằng đa số chúng ta đều có thiện ý, đúng sai chỉ khác nhau ở góc nhìn. Nhờ vậy, việc lắng nghe trở thành một hành trình: ban đầu có thể mệt mỏi vì phải “thỏa thuận” với chính mình để chấp nhận điều lạ lẫm, nhưng khi tìm được cách hóa giải, mình lại thấy trân trọng và yêu mến người đối diện hơn — vì đã hiểu được họ.

Gần đây, mình chọn giao tiếp qua những kênh chậm mà chín chắn hơn, như email hay thư tay. Một phần vì mình không muốn bị cuốn vào cảm giác “đã xem mà chưa trả lời” thường gặp ở tin nhắn. Một phần vì mình đang rèn luyện cách phân bổ thời gian tập trung: ví dụ, hẹn trước 15 phút trao đổi công việc với đồng nghiệp A, và trong 15 phút đó mình hoàn toàn dành cho A, từ chối mọi thứ khác. Với tin nhắn liên tục, nhiều người, nhiều chuyện, ta dễ bị cuốn đi và giải quyết hời hợt. Một lý do khác mình ưa thích kênh chậm: nó phản ánh sự chuẩn bị. Mình tin rằng đối tác khi gửi email đã cân nhắc kỹ lưỡng, chắt lọc thông tin để truyền đạt. Đón nhận một nội dung như vậy, mình thấy dễ chịu hơn nhiều so với những mẩu tin nhanh, ngắt quãng, buộc phải hỏi đi hỏi lại mà vẫn chưa nắm được ý chính. Hơn nữa, cách trình bày, chọn từ, cấu trúc văn bản cũng là những tín hiệu giúp mình hình dung phần nào hoàn cảnh và tính cách của người gửi.

Mình nghiệm ra rằng: muốn nhanh thì phải chuẩn, muốn chuẩn thì phải đúng (Make It Work, Make It Right, Make It Fast). Mà muốn làm đúng thì nền móng phải vững chắc, chính xác — điều ấy không thể vội vàng. Thời thế xoay vần, công nghệ đổi thay, nhưng mình vẫn giữ niềm tin mãnh liệt vào những giá trị cốt lõi bền vững.

Dựa trên tiểu thuyết Mưa đỏ của nhà văn Chu Lai, bộ phim “Mưa Đỏ: Máu xương đổ xuống - Đất trời lưu danh” tái hiện lại bối cảnh lịch sử hào hùng ấy. Phim không chỉ khắc hoạ sự khống liện của chiến tranh, mà còn hướng đến khơi gợi sự đồng cảm, tinh thần hoà hợp và trân trọng giá trị hoà bình ngày hôm nay.

Về nội dung, ngay từ đầu bộ phim đã mở ra bằng hình ảnh sự tòng quân của cả hai chiến tuyến. Điều này khiến mình kỳ vọng rằng sẽ được cùng khán giả chứng kiến câu chuyện từ cả hai phía. Nếu được khai thác tốt, phim có thể tránh đi lối tuyên truyền phân cực thắng - thua, thiện - ác, ta - địch quen thuộc, mang lại cho khán giả một góc nhìn cảm thông hơn với những người lính miền Nam. Nếu làm được điều đó, mình tin rằng sự thấu hiểu và chia sẻ sẽ khơi gợi tinh thần hàn gắn, hoà bình, đoàn kết, góp phần khắc phục những vết rạn nứt quá khứ để cùng nhau xây dựng một Việt Nam mạnh mẽ hơn.

Tuy nhiên, hy vọng đó chỉ kéo dài khoảng 30 phút đầu phim, khi đạo diễn khéo léo dựng lên bối cảnh của hai tuyến: tiểu đội lính miền Bắc đầy hào khí, mộng mơ, quả cảm vì lý tưởng; song song là Quang - một chiến sĩ Việt Nam Cộng Hoà tham chiến với lòng dũng cảm và nghĩa khí. Những hoạt cảnh tiếp theo khắc hoạ sự khốc liệt, gian khổ của cuộc chiến, tinh thần quyết tâm giành giật cứ điểm quan trọng. Đến giai đoạn này, bộ phim dành cho các chiến sĩ Việt Minh cảm xúc cao hơn, không còn khắc hoạ sâu đời sống bên kia chiến tuyến, mà chủ yếu thể hiện sự áp đặt vô lý từ tướng lĩnh và tổng thống Việt Nam Cộng Hoà vào chiến trường. Điều này có thể khiến cảm xúc khán giả dễ bị phân cực, không còn sự cân bằng như kỳ vọng ban đầu.

Xét về tổng thể, Mưa đỏ là bộ phim đáng xem, đặc biệt trong dịp Quốc Khánh như một cách để hoà mình vào không khí ngày lễ. Về mặt kỹ thuật, phim được thực hiện rất chỉn chu: từ góc máy, âm thanh, ánh sáng. đến biên đạo võ thuật và các hình ảnh mang tính biểu tượng sâu sắc. Đoàn làm phim đa dành nhiều tháng trời khảo sát hơn 10 tỉnh thành để dựng phim trường rộng gần 50ha bên bờ sông Thạch Hãn, phục dựng Thành cổ Quảng Trị cùng hệ thống hầm hào, chiến luỹ với độ chân thực cao. Sự tỉ mỉ còn thể hiện ở việc tái hiện chính xác phục trang và vũ khí của giai đoạn 1972.

Một điểm cộng khác là diễn xuất của dàn diễn viên trẻ. Dù chưa nhiều tên tuổi nổi bật, họ mang đến cảm xúc tự nhiên, đặc biệt qua ánh mắt và biểu cảm đầy chân thực, hoà hợp hoàn toàn với bối cảnh. Cách kể chuyện mạch lạc, thắt nút, mở nút hợp lý, và đến cuối phim vẫn đủ sức níu chân khán giả ở lại đến phần credit - một minh chứng rõ ràng cho sức hút của tác phẩm.

Quan trọng hơn, Mưa đỏ không chỉ tái hiện một trận chiến khốc liệt, mà còn khơi gợi nơi người xem sự thấu cảm và trân trọng hoà bình hôm nay. Bộ phim nhắc chúng ta nhớ rằng sau những mất mát và chia cắt, điều còn lại và cần được gìn giữ chính là tinh thần hoà hợp, đoàn kết để cùng nhau xây dựng một Việt Nam sánh vai với các bạn bè quốc tế.

Một Sprint kéo dài 2 tuần thường được coi là hợp lý: đủ ngắn để điều chỉnh chiến lược khi cần thiết, đủ dài để hoàn thiện một phase hoặc một tính năng, tạo ra một output vừa vặn khi kết thúc. Tuy nhiên, trên thực tế quản lý, luôn có những công việc chen ngang xuất hiện - thường là nhiệm vụ khẩn cấp, không thể chờ đến cuối Sprint. Nếu bỏ qua, dự án có thể đánh mất cơ hội hoặc đi sai hướng. Nếu đưa ngay vào Sprint đang chạy, thì vừa vi phạm nguyên tắc cam kết, vừa khiến team khó thực hiện trọn vẹn cả backlog cũ lẫn mới. Đây là một tình huống tiến thoái lưỡng nan mà mình từng nhiều lần gặp phải.

Ý chính tóm gọn

• Không thể tránh hoàn toàn việc chen ngang trong Sprint -> cần cơ chế để xử lý.
• Reserve Space = 20% effort dành cho công việc đột xuất, khẩn cấp.
• Low Prioriry backlog có thể “lấp chỗ trống” nhưng sẵn sàng bị thay thế.
• Nếu Reserve Space luôn bị vượt quá -> phải xem lại kế hoạch dự án và kỳ vọng của các Stakeholders.
• Kết hợp kỷ luật của Scrum với linh hoạt thực tế -> giúp team vừa ổn định, vừa thích ứng.

Phân tích vấn đề

Như đã nêu ở phần mở đầu, các vấn đề có thể kể đến trong trường hợp này gồm:

• Nếu bỏ qua: có nguy cơ bỏ lỡ cơ hội quan trọng, dự án đi chệch mục tiêu.
• Nếu nhồi thêm vào Sprint: team bị quá tải, backlog cam kết từ đầu khó hoàn thành, chất lượng tổng thể giảm.

Kinh nghiệm thực tế cho thấy, việc này không thể giải quyết bằng cách áp dụng lý thuyết một cách cứng nhắc, mà cần có một cơ chế linh hoạt để hấp thụ các biến động.

Giải pháp: Reserve Space trong Sprint

Mình đã thử áp dụng một ý tưởng gọi là Reserve Space - tức dành trước một phần dung lượng Sprint để xử lý các công việc khẩn cấp. Cách làm như sau:

1. Khi lập kế hoạch Sprint:
   • Chỉ commit backlog chính (Normal Backlog) ở mức khoảng 80% effort tổng Sprint.
   • 20% effort còn lại dành cho Reserve Space.
2. Cách sử dụng Reserve Space:
   • Nếu có công việc khẩn cấp (Critical Backlog), chúng sẽ được đưa vào phần Reserve Space.
   • Các backlog ưu tiên thấp (Low Priority Backlog) có thể được xếp tạm trong Reserve Space để team thực hiện nếu không có việc chen ngang, nhưng sẵn sàng bị loại bỏ nếu cần nhường chỗ cho backlog quan trọng hơn.
3. Khi Reserve Space bị vượt quá:
   • Nếu Sprint nào cũng xuất hiện quá nhiều backlog khẩn cấp vượt ngoài Reserve Space, đó là tín hiệu cần xem xét lại dự án: có thể team đang hứa hẹn quá mức hoặc kỳ vọng từ stakeholders chưa thực tế.

Bài học rút ra

Scrum mang lại sự kỷ luật trong cam kết, nhưng thực tế quản lý dự án luôn có biến số. Thay vì máy moc bỏ qua hoặc nhồi nhét backlog chen ngang, việc chủ động thiết kế một khoảng dung lượng dự phòng trong Sprint giúp đội ngũ vừa giữ được sự ổn định, vừa linh hoạt khi tình huống bất ngờ xảy đến.

• UFW không chặn được các gói tin từ bên trong mạng nội bộ khi mapping port với Docker container (thường dùng trong tham số của docker run -p {internal-ip}:{expose-port}:{container-port}).
• Phương án 1: Sử dụng firewall từ Cloud Provider.
• Phương án 2: Sử dụng iptables để chặn các gói tin từ bên trong mạng nội bộ.

# Block all traffics 
sudo iptables -I DOCKER-USER -i {network_interface} -j DROP

# Keep connection states ESTABLISHED, RELATED
sudo iptables -I DOCKER-USER -i eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Each allowing rule will be added
sudo iptables -I DOCKER-USER -i {network_interface} -m conntrack -p tcp --ctstate NEW --ctorigsrc {source_ip} --ctorigdstport {destination_port} -j ACCEPT

Kịch bản

Hạ tầng

Dịch vụ

Các dịch vụ đang chạy trong docker container, các cổng (port) được mapping như bảng sau.

Mục tiêu

• Chặn toàn bộ các gói tin từ Internet vào máy chủ B.
• Chặn toàn bộ các gói tin từ bên trong mạng nội bộ vào máy chủ B.
• Mở cho duy nhất máy chủ C được phép truy cập vào máy chủ B qua cổng 3307
• Mở cho duy nhất máy chủ A được phép truy cập vào máy chủ B qua cổng 3306

Thực thi

Lưu ý: Kịch bản này chứa lỗi, không sử dụng trong môi trường thực tế.

• Bind dịch vụ MySQL 1 và MySQL 2 trên máy chủ B với cổng 3306 và 3307 trên cổng mạng nội bộ.

# Môi trường: Máy chủ B
docker run --name mysql-1 -d -p 10.0.0.2:3306:3306 mysql:5.7 
docker run --name mysql-2 -d -p 10.0.0.2:3307:3306 mysql:5.7

• Dùng ufw làm firewall trên máy chủ B.

# Môi trường: Máy chủ B

# Chặn toàn kết nối vào
ufw default deny incoming

# Mở cổng 3306 cho máy chủ A
ufw allow from 10.0.0.1/32 to any port 3306

# Mở cổng 3307 cho máy chủ C
ufw allow from 10.0.0.3/32 to any port 3307

Vấn đề

• UFW không chặn được các gói tin ¹ khi mapping port với Docker container (thường dùng trong tham số của docker run -p {internal-ip}:{expose-port}:{container-port}).
• Một số bài viết ² tìm cách chèn thêm các rules vào chain DOCKER-USER của iptables nhưng chỉ hiệu quả để chặn các gói tin đến từ bên ngoài, không chặn được các gói tin từ bên trong mạng nội bộ như kịch bản đề ra.

Phương án

1. Sử dụng firewall từ Cloud Provider

• Đối với các dịch vụ cloud chuyên nghiệp như AWS, GCP, Azure, các máy chủ sẽ được quản lý bởi firewall của cloud provider. Với sự hỗ trợ của hệ thống mạng ảo VPC, họ tích hợp firewall tầng mạng thay vì sử dụng các firewall tầng phần mềm ^{3 4 5}. Vì vậy, việc chặn sẽ hiệu quả và không ảnh hưởng vì các phần mềm xung đột với nhau.

2. Sử dụng iptables trên từng máy chủ

• Dùng chain DOCKER-USER để quản lý các rule của Docker thay vì các chain mặc định. Mục đích của việc này là để tách biệt các rule định nghĩa cho Docker với các rule khác ¹.
• Các rules viết phải sử dụng extension conntrack⁶ vì sau khi gói tin vào DOCKER-USER đã qua bộ lọc DNAT ¹, địa chỉ và cổng đã có thể bị thay đổi.
• Lệnh thêm rules vào chain DOCKER-USER trên máy chủ B:

Lưu ý: iptables có thể làm mất kết nối điều khiển nếu bạn cấu hình sai. Hãy chắc chắn có phương án truy cập thay thế trong trường hợp mất kết nối.

# Môi trường: Máy chủ B
# Chặn toàn bộ gói tin từ Internet 
sudo iptables -I DOCKER-USER -i eth0 -j DROP
sudo iptables -I DOCKER-USER -i eth0 -j LOG --log-prefix "Dropped packet: " --log-level 4

# Chặn toàn bộ gói tin nội bộ
sudo iptables -I DOCKER-USER -i eth1 -j DROP
sudo iptables -I DOCKER-USER -i eth1 -j LOG --log-prefix "Dropped packet: " --log-level 4

# Giữ các kết nối ở trạng thái ESTABLISHED, RELATED
# Rule này sẽ giúp bạn giải quyết tình trạng kết nối ra ngoài đã thiết lập nhưng lại bị chặn.
sudo iptables -I DOCKER-USER -i eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Mở cho duy nhất máy chủ A truy cập cổng 3306 qua mạng nội bộ
sudo iptables -I DOCKER-USER -i eth1 -m conntrack -p tcp --ctstate NEW --ctorigsrc 10.0.0.1 --ctorigdstport 3306 -j ACCEPT

# Mở cho duy nhất máy chủ C truy cập cổng 3307 qua mạng nội bộ
sudo iptables -I DOCKER-USER -i eth1 -m conntrack -p tcp --ctstate NEW --ctorigsrc 10.0.0.3 --ctorigdstport 3307 -j ACCEPT

• Sử dụng Bash với công cụ cat, parallel, sed, sort cho kết quả tối ưu nhất.

Giới thiệu

Khi làm việc với dữ liệu thô, theo trạng thái từng từ, mỗi từ một dòng (thường dùng trong làm từ điển), dữ liệu thường bị thừa ra. Nguyên nhân là do dữ liệu trùng nhau, các kí tự thừa (\r, \n, space) ở đầu và cuối các từ làm bộ lọc nhầm lẫn cho rằng đây là các từ khác nhau. Vậy nên bài toán đặt ra trong quá trình làm sạch dữ liệu là xóa các kí tự thừa ở đầu và cuối của từ, sắp xếp và lọc các từ trùng nhau.

Trong làm việc với dữ liệu ít, công việc đó đơn giản, thậm chí làm việc với các phần mềm bảng tính như Excel cũng có thể giải quyết vấn đề. Tuy nhiên, với dữ liệu bắt đầu từ 100 Mb đến hàng GB, TB thì ta phải có một số thủ thuật. Trong bài viết này mình sẽ chia sẻ kinh nghiệm vài lần xử lý và số liệu benchmark.

Thử nghiệm lọc trùng lần thứ nhất

Điều kiện

Máy tính cá nhân với cấu hình:

• OS: Ubuntu 14.04
• RAM: 4GB
• CPU: Intel® Core™ i5-2430M CPU @ 2.40GHz × 4

Dữ liệu được phân bổ:

• 1k.txt: 1,000 dòng đầu tiên của tệp dữ liệu.
• 100k.txt: 100,000 dòng đầu tiên của tệp dữ liệu gốc.
• 6tr.txt: Tệp dữ liệu gốc chứa khoảng 6 triệu dòng.

Phương thức thực hiện

Mình sẽ sử dụng 3 ngôn ngữ để tiện so sánh: Bash, R, và Python.
Theo những cách trước đây, sẽ sử dụng ngôn ngữ Bash và hàm có sẵn của hệ điều hành linux là sort và uniq.

cat <input-file> | sort | uniq <output-file>

Sau khi lọc trùng sẽ thu được output đã sắp xếp. Vì lệnh uniq chỉ được thực hiện sau khi đã sắp xếp input nên bắt buộc phải sort trước khi lọc trùng.

Sau một thời gian tiếp cận, mình biết thêm ngôn ngữ R được đánh giá rất tốt dùng cho Thống kê. Vậy nên mình đã cài đặt và thử nghiệm trong công việc lọc trùng. Đối với R, sau khi nhập dữ liệu, ta không cần phải sắp xếp.

Cuối cùng với ngôn ngữ Python, dùng thư viện collections.Counter để đưa dữ liệu vào bộ đếm. Sau đó ghi ra file.

Kết quả

Nhận xét

Như vậy, dùng Bash xử lý file 72MB sẽ phải mất thời gian khoảng 48s để thực hiện, đối với R thì mất 71s (trong đó 28s để đọc dữ liệu). Riêng đối với Python chỉ mất khoảng 6s cho tất cả các công đoạn.

Tuy nhiên với đầu ra của dữ liệu thì chênh lệch nhau khá lớn giữa các ngôn ngữ. Sau khi kiểm tra các file đầu ra của bộ input 100k, không tìm thấy sự khác nhau của output giữa các ngôn ngữ. Tuy nhiên lại có một phát hiện khác khi sử dụng lệnh cat -v đối với file 1k-python.out, cuối mỗi dòng xuất hiện ký tự ^M (\r trong Windows).

Hơn nữa, sau khi xem kĩ các file output, nhận thấy các kí tự thừa khoảng trống đằng sau nhưng vẫn không bị lọc.

Rút kinh nghiệm

• Với khả năng tối ưu nhất, mình sẽ sử dụng Python để thực hiện các lần thử nghiệm tiếp theo.
• Tiền xử lý dữ liệu (pre-process) bằng cách xoá hết các khoảng trống trước và sau của mỗi dòng.
• Sử dụng đa luồng (multi-thread) để tăng tốc độ xử lý của CPU.

Thử nghiệm lần hai

Điều kiện

• Tương tự như điều kiện của lần 1.
• Thêm file full.txt chứa toàn bộ dữ liệu cần xử lý (khoảng 500 MB).

Phương thức thực hiện

Trước hết, xoá hết các ký tự khoảng trống, \n, \r ở trước và sau mỗi dòng.
Sử dụng hàm map(str.strip, data) của Python sau khi đọc file để thực hiện tác vụ trên. Các bước thử nghiệm tương tự lần trước.

Kết quả

Nhận xét

• Với 2 file 1k.txt và 100k.txt, khi chưa có sự trùng lặp nhiều về các từ chứa kí tự trống 2 đầu, dung lượng file tương đồng với cách sử dụng Bash. Có thể kết luận mỗi dòng chứa thêm kí tự ^M đã làm dung lượng file tăng lên đáng kể.
• Đối với output của tập đầu vào 6tr.txt, dung lượng đã giảm so với tập Bash ban đầu khoảng 30 KB.
• Khi xử lý với bộ dữ liệu nặng hơn, RAM bị quá tải. Khi đọc file, mặc dù số lượng biến ít, nhưng giá trị của biến sẽ phải nạp tương ứng với kích thước file đọc vào (trong trường hợp full.txt là 499 MB). Nếu như chạy toàn bộ sẽ hết dung lượng RAM và thời gian chạy sẽ rất lâu do phải đợi bộ nhớ giải phóng. Các lệnh chạy này xử lý trên RAM, không ảnh hưởng tới CPU nên việc multi-thread không cấp bách bằng việc chia nhỏ file để load. Dung lượng RAM còn lại (khi chạy song song các chương trình khác) cũng rất quan trọng. Đối với bộ dữ liệu 6tr.txt, khi chạy cùng Google Chrome xảy ra tình trạng xử lý lâu, mất tới 60s thay vì 6s như trong trường hợp chạy chỉ cùng các trình editor đơn thuần.

Rút kinh nghiệm

• Cắt nhỏ file ra thành từng phần nhỏ để xử lý.

Thử nghiệm lần ba

Điều kiện

• Cấu hình và dữ liệu tương tự lần 1.

Phương thức thực hiện

Mình chưa tìm ra cách tối ưu khi load file và xử lý trên Python, vì vậy sẽ thử nghiệm với Bash để tìm cách cải tiến.

Trước đây, dòng lệnh để xử lý dữ liệu là cat <input-file> | sort | uniq <output-file>. Khi sử dụng lênh trên phát sinh một số vấn đề:

• Dùng 3 hàm liền nhau, lặp lại công việc bị thừa.
• Chưa xử lý được vấn đề có các ký tự thừa ở đầu và cuối dòng.
• Chạy đơn luồng, không tận dụng được CPU.

Mình đã khắc phục như sau:

• Dùng sed để xoá các ký tự không mong muốn.
• Dùng sort với tham số -us (-u: unique, -s: stable). Khi sử dụng hai tham số này, ta đã có thể tối ưu việc xoá bỏ các dòng trùng nhau, sắp xếp, đọc file và chạy song song.

Bước 1: Tiền xử lý xoá khoảng trống

Với hàm sed, không có tham số tối ưu khi lọc dữ liệu nên chỉ chạy 1 luồng. Ta được kết quả:

Để tối ưu hơn, mình sử dụng công cụ GNU parallel để sed data. Câu lệnh tiền xử lý xoá khoảng trắng sẽ trở thành:

cat <input> | parallel –pipe sed ‘-e “s/\r//g” -e “s/^ *//” -e “s/ *$//”’ > <output>

Kết quả thu được:

Bước 2: Sắp xếp và lọc trùng

Mình sẽ chỉ sử dụng lệnh sort với tham số -us để sắp xếp và lọc trùng. Câu lệnh sẽ trở thành:

sort -us -o <output> <input>

Thời gian thực hiện:

Nhận xét

Việc tối ưu đã hoàn thiện hơn nhiều so với lần trước.