#230 - Tìm hiểu về WebRTC và cơ chế peer to peer networking
Trong số này, chúng ta cùng tìm hiểu về:
NGAC Vs RBAC Vs ABAC các cơ chế phân quyền cơ bản
Tìm hiểu về WebRTC và cơ chế peer to peer networking
Druid, ClickHouse, and Pinot vs data lakes and data warehouses
Lời giải bài Minimum Knight Moves
Ngoài ra các bạn vẫn có thể tiếp tục đặt mua ấn phẩm Dijkstra tập 2 tại đây nhé.
Những bài viết hay
Để đảm bản việc kiểm soát người dùng cuối (user) truy xuất khai thác các tài nguyên và các chức năng của tổ chức hoặc ứng dụng, đã có một vài cách tiếp cận để kiểm soát phân quyền được khởi xướng như :
Kiểm soát truy cập theo danh sách quyền được phép truy cập (DAC)
Kiểm soát truy cập bắt buộc ( Mandatory Access Control - MAC)
Kiểm soát truy cập dựa trên vai trò (Role-Based Access Control - RBAC)
Kiểm soát truy cập dựa trên thuộc tính (Attribute-Based Access Control - ABAC)
Tuy nhiên, về bản chất bất kể mô hình kiểm soát truy cập nào cũng dựa trên ba yếu tố cơ bản:
user
system / application
policy
Đối với RBAC, hướng tiếp cận là giới hạn quyền truy cập khai thác tài nguyên dự trên vai trò (role) của user trong tổ chức. Mỗi role sẽ có những quyền hạn khác nhau. Nhưng khi số lượng role trở nên quá lớn, có thể do tổ chức mở rộng quy mô hoặc việc kiểm soát role không chặt chẽ việc kiểm soát sẽ trở nên khó khăn và khó có thể mở rộng thêm được.
Đối với ABAC, hay còn được biết đến với cái tên khác là Policy-based Access Control, là một mô hình quản lý truy cập mà ở đó quyền truy cập sẽ được cấp cho users thông qua việc sử dụng các “chính sách” (policies). ABAC là một mô hình phân quyền chi tiết (fine-grained model) vì ta có thể gán bất kỳ thuộc tính nào cho user, nhưng đồng thời chính vì thế mô hình này lại trở thành gánh nặng và khó quản lý vì 3 lý do:
Khi xác định quyền hạn, khó để hình dung được mối quan hệ giữa các user và đối tượng được phép truy cập.
Nếu các quy tắc (rules) được định nghĩa phức tạp hoặc được thiết kế khó hiểu, quản trị viên sẽ gặp khó khăn khi duy trì vận hành và theo dõi giám soát
Khi các permissions càng lớn sẽ dẫn đến hiệu suất xử lý phân quyền càng giảm.
Đối với NGAC (Next Generation Access Control - NGAC), phương án tiếp cận của mô hình này là mô hình hóa việc quyết định truy cập data dưới dạng đồ thị. Hướng tiếp cận của NGAC là hướng tiếp cận có hệ thống, nhất quán về chính sách để kiểm soát việc truy cập, cho phép quản trị viên có thể phân quyền hoặc ngăn chặn và quản trị quyền truy cập của user ở mức độ chi tiết cao hơn. Các yếu tố cấu thành NGAC
User
Các đối tượng (object)
Thuộc tính user (user attributes) chẳng hạn như phòng ban (organization unit)
Thuộc tính của đối tượng (object attributes) chẳng hạn như các folders
Các phân lớp chính sách, chẳng hạn như quyền truy cập file system, vị trí và thời gian.
Bài viết sẽ giới thiệu sơ lược về ABAC, RBAC và một phương thức kiểm soát truy cập mới NGAC đồng thời so sánh các điểm tương đồng và khác nhau giữa 03 phương thức trên. Để có thêm thông tin chi tiết hơn bạn có thể tham khảo thêm tại bài viết.
How JavaScript works: WebRTC and the mechanics of peer to peer networking
(by n^4)
Trong đại dịch Covid, chúng ta đã được chứng kiến làn sóng làm việc tại nhà diễn ra một cách mạnh mẽ. Kèm theo đó là các ứng dụng video call, hangout, meeting online, conference online, web chat được ứng dụng mạnh mẽ. Đằng sau các ứng dụng này là Web RTC, viết tắt bởi Web Real-time Communication.
Là một trong các dự án Open Source được sự hậu thuẫn của các tập đoàn công nghệ lớn như Apple, Microsoft, Google, Mozilla, .... WebRTC là đặc tả mở nhằm định nghĩa các giao thức, thư viện, API giúp cho các ứng dụng kết nối peer-to-peer trực tiếp thay vì phải thông qua server.
Tưởng tượng bạn đang cần xây dựng hệ thống video call trên browser giữa 2 người. Nếu quá trình call này phải thông qua server thì rõ ràng sẽ khó mở rộng khi có thêm nhiều người dùng tham gia vào hệ thống. Chính vì vậy chuẩn WebRTC là nền tảng rất cần thiết.
Trong bài blog này, tác giả giới thiệu lại một số đặc tính của WebRTC như:
- Peer-To-Peer communication: việc thiết lập peer-to-peer communication có gì đặc biệt
- Firewalls và NAT Traversal: mô tả cơ chế để các ứng dụng chạy trên nền trình duyệt có thể tìm kiếm được phần mềm peer để kết nối
- WebRTC APIs: giới thiệu qua 3 nhóm APIs được dùng trong WebRTC:
Media Capture and Streams: các API này dùng để truy cập vào các thiết bị đầu vào như microphone, camera.
RTCPeerConnection: các API này dùng để stream audio và video ở thời gian thực qua mạng internet. Các API này cũng đồng thời cung cấp cơ chế tạo, đóng và theo dõi kết nối p2p
RTCDataChannel: Các API này dùng để gửi và nhận các loại dữ liệu khác (ko phải audio và video).
Mời các bạn cùng đọc bài viết để hiểu thêm về cơ chế vận hành của WebRTC.
Druid, ClickHouse, and Pinot vs data lakes and data warehouses
Chúng ta luôn muốn có một Data Warehouse (DW) có thể thỏa mãn tất cả các yêu cầu. Tuy nhiên điều này thường không khả thi và dễ dàng. Với nhiều công ty, để hỗ trợ cho nhu cầu phân tích, tạo báo cáo, dashboard, ... họ thường cần ít nhất một Data Lake (DL), một Data Warehouse (DW) và có thể là một vài loại database chuyên biệt.
Vậy bạn nên chọn đúng công cụ phân tích như thế nào? Để tìm ra câu trả lời phù hợp cho mỗi trường hợp cụ thể, bạn cần trả lời được 3 câu hỏi sau:
Bạn yêu cầu hiệu suất như thế nào?
Bạn cần dữ liệu nào?
Bạn cần thực hiện các loại phân tích nào?
Phân tích với Data lakes
Chúng ta thường thiết kế một DL đi kèm với một DW. Lý do chính là hầu như những triển khai data warehouse đều có 2 thách thức lớn:
Đầu tiên, việc triển phát triển một ETL pipeline để phục vụ một nhu cầu phân tích mới thường mất quá nhiều thời gian. Phải mất vài tuần để thu thập yêu cầu, vài tuần cho đội ETL tìm và đổ đúng dữ liệu và sau đó 1-3 tháng để nhận kết quả cuối cùng phù hợp. Tuy nhiên, những người làm kinh doanh luôn mong muốn nhận kết quả phân tích mới ngày hôm qua.
Với data lake, chúng ta có để sử dụng SQL để xây dựng luồng dữ liệu ELT chỉ mất khoảng vài ngày hoặc vài giờ và có thể dễ dàng truy cập truy tiếp đến những dữ liệu mới mà không cần chờ đến team ELT.
Tại sao chúng ta thường có một DL đi kèm với một DW?
Đầu tiên, việc triển phát triển một ETL pipeline, lưu trữ output vào một DW, để phục vụ một nhu cầu phân tích mới thường mất quá nhiều thời gian. Có thể mất hàng tuần để thu thập các yêu cầu, thiết kế, phát triển pipeline và triển khai lên production.
Với một Data Lake với khả năng hỗ trợ các truy vấn SQL-like, chúng có thể chỉ tốn vài ngày hoặc vài giờ để có thể dễ dàng truy cập truy tiếp đến những dữ liệu mới thay vì phải phụ thuộc vào một team Data khác để phát triển một ETL pipeline.
Các ứng dụng phân tích hiệu năng cao sử dụng analytics databases
Các databases với khả năng phân tích chuyên biệt đã xuất hiện để cung cấp hiệu suất cho các loại dữ liệu và phân tích cụ thể. Nó bao gồm cơ sở dữ liệu chuỗi thời gian (timeseries databases): InfluxDB và TimescaleDB, hay kết hợp chuỗi thời gian (hybrid timeseries databases): Pinot, Druid, Clickhouse. ClickHouse hay Druid cũng cung cấp thực hiện các truy vấn phân tích với độ trễ thấp, hữu ích với các synchronous requests.
Đối với việc tìm kiếm (Search), Elastic thật sự là một công cụ hữu ích nhưng nó trở nên quá đắt đỏ cho việc thực hiện phân tích bởi vì Elastic không lưu trữ dữ liệu theo dạng cột (columnar). Quá trình indexing trong Elastic gây tốn chi phí và thời gian cho mỗi lần load dữ liệu.
Đối với các phân tích thông thường, tác giả đã gợi ý và đề cập đến Firebolt. Đây là giải pháp giúp chúng ta có thể đạt được tốc độ của ClickHouse hay Druid, sự đơn giản, tính linh hoạt của Snowflake và chi phí chỉ bằng 1/10 so với Snowflake khi scale lượng dữ liệu từ GB -> PB. Từ đó chúng ta chỉ cần một Data Warehouse duy nhất, thay vì phải maintain nhiều Data Warehouse khác nhau.
Việc chọn công cụ phân tích phù hợp ngày càng dễ dàng hơn, một phần vì các data warehouse ngày càng nhanh và có thể hỗ trợ nhiều yêu cầu phân tích hiệu suất cao hơn. Tuy nhiên, có 2 quy tắc chúng ta nên lưu ý trước khi tìm kiếm một giải pháp phù hợp với doanh nghiệp:
Đầu tiên, cần hiểu về những công cụ phân tích khác đang được sử dụng trong nội bộ, qua đó học hỏi và tận dụng kiến thức chuyên môn.
Thứ 2, cần xây dựng lộ trình phân tích 1-3 năm trước khi bạn chọn một công cụ phân tích khác.
Góc Lập Trình
Đề ra tuần này: Find Root of N-Ary Tree
(by phucnh)
Cho một N-ary tree được biểu diễn bởi một list của các nút, ta có giá trị của các nút là duy nhất. Hãy trả về nút gốc của N-ary tree.
Lời giải đề bài tuần trước: Minimum Knight Moves
(by ndaadn)
Đề bài yêu cầu tìm số lần di chuyển nhỏ nhất để quân mã đi từ vị trí (0, 0) tới vị trí (x, y) trên bàn cờ. Nếu ta coi các vị trí mà quân mã có thể di chuyển tới được như các đỉnh của đồ thị, thì ta có thể mô hình hoá bài toán dưới dạng tìm đường đi ngắn nhất giữa 2 đỉnh trong đồ thị không có trọng số (unweighted graph). Duyệt theo chiều rộng (BFS) là cách tiếp cận thông dụng nhất để tìm đường đi ngắn nhất giữa 2 đỉnh trong đồ thị không có trọng số.
Giải thuật dựa trên BFS được thực hiện như sau: https://pastebin.com/eNF9e8rj
Độ phức tạp về thời gian và không gian của cách giải thuật này là O(max(|x|, |y|)^2). Với BFS, để đi được tới đích, ta cần phải duyệt tất cả các vị trí mà quân mã có thể di chuyển được tại vị trí hiện tại. Để dễ hình dung cách tính độ phức tạp của giải thuật, ta có thể vẽ 1 đường tròn với bán kính là (0, 0), (x, y), như vậy các điểm mà quân mã có thể di chuyển tương đương với diện tích của hình bao của đường tròn. Đây là một hình vuông có cạnh bằng max(2|x|, 2|y|).
Số lượng các vị trí sẽ xấp xỉ diện tích của hình vuông, bằng (max(2|x|, 2|y|))^2 (Diện tích của hình vuông bằng bình phương của 1 cạnh).
Ngoài ra, bài toán này có một cách tiếp cận khá thú vị. Bởi bàn cờ có tính chất đối xứng, thay vì sử dụng BFS để duyệt toàn bộ các vị trí xung quanh quân mã, thực tế, ta cho cần duyệt theo 1 hướng (thay vì 4 hướng) như sau:https://pastebin.com/Jt5jf9N2
Với cách tiếp cận trên, độ phức tạp về thời gian và không gian chỉ là O(|x*y|).
Code & Tools
Open Metadata - Là một công cụ cung cấp tiêu chuẩn mở cho việc lưu trữ metadata của các tập dữ liệu khác nhau trong một data platform. Open metadata được thiết kế là nơi duy nhất chứa các thông tin cần thiết giúp data users khám phá, tìm kiếm, hiểu chính xác và có được data mà họ cần.
Feedback
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)
Grokking mang lại cho các bạn những kiến thức mới mẻ và hữu ích thông qua:
Tech Talk: Là một hoạt động thường xuyên của Grokking từ những ngày đầu thành lập. Tại đây các diễn giả chia sẻ kiến thức xoay quanh Computer Science và Software Engineer. Các buổi Tech Talk đều được record và upload lên kênh youtube của Grokking.
Grokking Knowledge Graph: Tập hợp những nguồn kiến thức phong phú với hơn 1000 bài viết chọn lọc, các đầu sách, khóa học, v.v… Các bài viết đều được gán nhãn để giúp bạn đọc dễ dàng tìm kiếm.
Webinar: Là chương trình kết nối các kỹ sư Việt Nam và các kỹ sư đang làm việc tại các công ty công nghệ hàng đầu thế giới.
Dijkstra: Một ấn phẩm được xuất bản bởi các thành viên của Grokking. Với những bài viết đào sâu vào kỹ thuật và kiến thức khoa học máy tính.
Kipalog: Nền tảng chia sẻ kiến thức dành cho các lập trình viên.
Newsletter: Những bài viết hay về công nghệ sẽ được gửi tới bạn hàng tuần qua email.
Chúc các bạn sẽ tìm được nhiều điều mới mẻ khi đến với Grokking và xin hẹn gặp lại các bạn vào tuần sau.
Quotes
“Sufficiently advanced trolling is indistinguishable from thought leadership.”
— Hall’s Law