ITEC - Qua trinh phat trien he thong BigData
•Als PPTX, PDF herunterladen•
9 gefällt mir•2,964 views
ITEC - Quá trình phát triển của hệ thống BigData @ niconico
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie ITEC - Qua trinh phat trien he thong BigData
Ähnlich wie ITEC - Qua trinh phat trien he thong BigData (20)
ITEC - Qua trinh phat trien he thong BigData
- 1. Quá trình phát triển của hệ thống BigData @ niconico Bùi Hồng Hà 1 http://bit.ly/itec-bigdata-event
- 2. Nội dung • Giới thiệu bản thân • Giới thiệu qua về nicovideo • Quá trình phát triển hệ thống bigdata (hệ thống X) • Bối cảnh lịch sử - quá trình phát triển • Thiết kế dữ liệu • Một số bài học thu được 2
- 3. Giới thiệu bản thân • Bùi Hồng Hà • Kỹ sư hệ thống (infrastructure engineer) • Dwango (2012 – 2016) • Thiết kế vận hành Nicovideo (và các dịch vụ nhỏ khác) • Thiết kế - xây dựng - vận hành hệ thống X • Sở thích • Đọc sách • Viết lách http://kipalog.com/users/BuiHongHa/mypage 3
- 4. Giới thiệu về niconico • Ra đời năm 2006 • “Youtube” Nhật Bản. • Website rank 8 toàn Nhật Bản. Alexa rank: 78 • Quy mô người dùng • 55 triệu người dùng đăng ký • 2.5 triệu người dùng trả tiền • Mô hình kinh doanh • Subscription • 5$ / tháng • Tổng số dịch vụ: ~ 50 5
- 5. Nicovideo 6
- 6. Truyền hình trực tiếp 7
- 7. Tranh ảnh – truyện tranh 8
- 9. Công nghệ nicovideo (2006 ~ 2014) • Kiến trúc monolithic • LAMP (Linux – Apache – Mysql – PHP) • Máy chủ on-premises • 4000 – 5000 máy chủ • 3 datacenters 10
- 10. Công nghệ nicovideo (2014 ~ 2016) • Kiến trúc • Chuyển từ monolithic sang hướng dịch vụ (service oriented) • Công nghệ • PHP Scala • MySQL MariaDB • Apache / Varnish -> nginx • Máy chủ • On-premises-> Cloud (Amazon / Azure) 11
- 11. Quá trình thiết kế và phát triển của hệ thống X 12
- 12. Tại sao bài nói này lại về quá trình? • Không có kiến thức tổng quan • Chia sẻ case-studies • Phân tích sự việc dựa trên ngữ cảnh • Không có hệ thống ”lởm” • “Those who do not learn history are doomed to repeat it” • Quyết định của người thiết kế hệ thống là bài học vô giá 13
- 14. Định nghĩa của Gartner • Đặc điểm dữ liệu • High-volume • High-velocity • High-variety • Hệ thống: cần hệ thống xử lý dữ liệu mang tính đột phá • Khả năng phân tích thông tin • Hỗ trợ quá trình ra quyết định • Tự động hoá quy trình 15
- 15. Hệ thống X để làm gì? • Xu hướng bigdata • 2011 – 2012 buzzword • Các cty công nghệ Nhật trong giai đoạn này đều xây dựng hadoop cluster • Nhu cầu phân tích dữ liệu của chính công ty • Thời gian người dùng xem 1 video là bao lâu? • Nhóm người dùng (độ tuổi, vùng miền, sở thích, thiết bị) • Thông tin thanh toán • Người dùng của hệ thống X? • Nhân viên kế hoạch • Nhân viên kinh doanh 16
- 16. Lược sử • 2012: 10 nodes • 4T * 10 ~ 40TiB • cuối 2013: 24 nodes tính toán • CPU Intel Xeon 12 cores (HT), 8T * 24 ~ 192TiB • 2014: 48 nodes • Intel Xeon 24 cores (HT), 10T (1*10) * 48 nodes ~ 480TiB • 2015: 96 nodes • ToR (Top of Rack) 10G • Xeon 24 cores (HT), 30T (3T * 10) * 48 nodes • 1.9PB 19
- 17. 2012 - 2013 20
- 18. Bối cảnh năm 2012 - 2013 • BigData buzzword • I keep saying that the sexy job in the next 10 years will be statisticians – Hal Varian • Hadoop release (2011) • BigData là lĩnh vực hoàn toàn mới • Chưa có công ty ở Nhật nào triển khai chưa có knowhow • Tài liệu không có nhiều 21
- 19. Vấn đề năm 2012 - 2013 • Xem con số ở đâu? • Bộ phận kinh doanh / kế hoạch không có nguồn số liệu • SRE là người đảm nhận trích xuất dữ liệu • Không phải nhiệm vụ • Dùng các tools: sed / awk / grep / count / SQL... Chạy trực tiếp trên máy chủ ảnh hưởng trực tiếp đến dịch vụ • Không đảm bảo được tính chính xác của con số 22
- 20. Giải pháp của năm 2012 - 2013 • Xây dựng “data warehouse” riêng phục vụ cho việc phân tích dữ liệu • Start small • Không tính đến high-availability • Front không tính đến tính phát triển. • Không dùng tool opensource 23
- 21. Kiến trúc năm 2012 - 2013 24 • 1 batch server • Storage gắn ngoài RAID-5 15T • 1 front server chuyên compile pig ra Java jar. • Chạy webapp tự viết (CakePHP) • User dùng web interface để chạy job • 1T storage • 30 users • 10 nodes tính toán • 8T * 10 ~ 80TiB • CDH2
- 22. 2014 (Năm ít biến động) 26
- 23. Bối cảnh năm 2014 • Kỳ vọng ngày càng tăng cao • 1 dịch vụ nhiều loại log gây áp lực lên dung lượng storage • Thời gian chạy job đòi hỏi ngắn lại đòi hỏi nâng cấp cluster • Hợp đồng với datacenter kết thúc 27
- 24. Các vấn đề của năm 2014 • Dự toán eo hẹp • Các máy tính đời 2012 hết hạn bảo hành cần thay mới • Log tích luỹ trong hơn 3 năm (360T / 480T) • Số lượng máy chủ nhiều (1 máy * 10 đĩa cứng SATA * 48 máy == 480) • Hỏng đĩa cứng trở thành việc hàng tuần • Khi đĩa cứng hỏng máy ngừng phục vụ dịch vụ số lượng cores không đủ • Network / CPU bắt đầu trở thành bottleneck của hệ thống 28
- 25. Kiến trúc năm 2014 29 • 48 nodes tính toán • 10TiB * 48 ~ 480TiB • 12 cores * 48 = 576 cores • CDH5.3 • Provision tools • Chef • Một phần các cài đặt tại OS layer được thực hiện ở PXE kickstart • Vấn đề CRC
- 26. 2015 – 2016 (Đột phá) 32
- 27. Bối cảnh 2015 - 2016 • Hầu hết các log file đều đã được lưu trữ trên hệ thống X • Đến lúc cải tiến và nâng cấp hệ thống • Knowhow việc nâng cấp vận hành hệ thống • Stream processing • Công nghệ container trở thành tâm điểm • docker • Cloud computing 33
- 28. Vấn đề gặp phải • Tính sẵn sàng của hệ thống chưa được cải thiện • Stream processing là công nghệ hoàn toàn mới • Docker là công nghệ mới • Các dịch vụ mới bắt đầu được triển khai trên cloud 34
- 29. Giải quyết 1: sử dụng lxc container 36 Container là công nghệ không mới. Chi tiết: http://kipalog.com/tags/LXC
- 30. 37
- 31. Giải quyết 2: sử dụng đĩa cứng 3T • Tránh việc nâng cấp hệ thống qua từng năm • Việc xin kinh phí rất phiền phức • Quá trình nâng cấp và mở rộng tốn rất nhiều cost. • Tránh dùng công nghệ cũ • Đĩa cứng 3T dần trở nên phổ biến. • 1 máy chủ có thời gian khấu hao là 5 năm dùng công nghệ cũ trong 5 năm 38
- 32. Giải quyết 3: thêm streaming layer • Streaming layer được phát triển mang tính thử nghiệm • Streaming layer dùng fluentd • Fluentd do người Nhật phát triển • “Người người nhà nhà” dùng fluentd knowhow có nhiều • Cấu hình và sử dụng đơn giản 39
- 33. Kiến trúc hệ thống 2015 - 2016 40
- 34. Các vấn đề còn tồn đọng • Vấn đề của streaming layer • Fluentd không được thiết kế để phục hồi khi có sự cố • Fluentd không đáp ứng đủ hiệu năng • Fluentd không được thiết kế để routing log qua internet • Không join được với master data • Vấn đề batch • SPOF ở batch server • Thiếu cơ chế quản lý job batch • Vấn đề của lxc • Vấn đề về chuẩn hoá kiểu dữ liệu 42
- 35. Star-Schema trong Data warehouse 43 ** The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling
- 36. Thiết kế schema • Dữ liệu như access log là dữ liệu “thô” • Không có schema • Gây khó khăn trong việc phân tích • Sử dụng storage như kudu để tăng tốc 44
- 37. Bài học cá nhân • The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow. – Fred Brooks • Nguyên tắc 40% cho các hệ thống đang phát triển • Thiết kế để hệ thống phát triển • Không có SPOF • Có phương án phục hồi khi gặp sự cố • Định kỳ viết ra knowhow của mình và chia sẻ cho mọi người 45
- 38. Tương lai của BigData? 46
- 39. I asked Doug that question 47
- 40. He said he doesn’t know … 48
- 41. Một số nguồn tài liệu • https://amplab.cs.berkeley.edu/ • https://databricks.com/blog • Hadoop / Spark Mailing list • https://dancres.github.io/Pages/ • Gartner / McKinsey / … Reports 49
- 42. Cảm ơn các bạn đã lắng nghe ! 50
Hinweis der Redaktion
- Để tránh tham gia vào cuộc chiến tôn giáo của các ngôn ngữ lập trình thì mình sẽ không nói rõ các ngôn ngữ mà mình thích.
- Hỏi về background của người nghe. Bao nhiêu người là lập trình viên Bao nhiêu người là sysadmin Bao nhiêu người giữ các vị trí quản lý (PM, PO)
- 55 triệu người dùng Con số này là con số ảo Có người dùng dùng rất nhiều nick (spam / kiếm tiền / lừa đảo)
- http://www.nicovideo.jp/watch/sm29259018
- Vision: TV trên internet truyền hình tương tác live.nicovideo.jp
- Con số máy chủ là ước lượng Nicovideo máy chủ riêng Nicovide live máy chủ riêng Framework tự phát triển
- Tại sao lại chuyển từ PHP Scala Hiệu năng của JVM cao hơn PHP MariaDB có galera cluster multi master (mysql 5.7 cũng có)
- Nhóm người nghe đa dạng Cần chủ đề tất cả nghe đều hiểu Nhiều chi tiết kỹ thuật đi sâu rất dễ buồn ngủ Tuy vậy nếu anh em nào thắc mắc kỹ thuật cứ tự nhiên hỏi. Kinh nghiệm == hiểu biết “cái gì hoạt động cái gì không”
- Big data is high-volume, high-velocity and/or high-variety information assets that demand cost-effective, innovative forms of information processing that enable enhanced insight, decision making, and process automation.
- Sysadmin sẽ phải dùng các tool chia sẻ
- Map-Reduce 2005 Knowhow Cấu hình máy chủ ra sao
- Batch chạy PHP: nội dung của batch là upload log + chỉnh hình lại log. đặt lịch = cron Monitoring == zabbix Log upload viết = PHP Các hệ thống gửi log lên vào lúc 4h sáng hàng ngày == scp (tại sao lại 4h sáng) thì log-rotate lúc 4h sáng Hadoop lưu dữ liệu dưới dạng lzo Một số lựa chọn thiết kế gây ra vấn đề cho sau này: Batch server 1 máy, storage gắn ngoài Front server: để chạy job Tạo account cho từng user trên máy chủ thắt quota (2G/người) Người dùng cuối không quan tâm đến công nghệ Quy trình trước đây: - Thống nhất con số cần lấy Liên lạc sysadmin để lên phương án Nhận số liệu, phân tích và tổng hợp Cần training người dùng cuối
- Vấn đề rời tất cả các máy chủ sang datacenter mới
- OS: kickstart Chef dùng trong các công việc sau: Cấu hình máy chủ (OS layers) Cài đặt Java, Hadoop, pig ... Cài đặt zabbix ...
- Thời gian launching ngắn, các dự án thử nghiệm đều được triển khai trên cloud
- Công ty chưa hề có knowhow Docker Chưa ổn định OS tiêu chuẩn của công ty là Centos6 không tương thích 100% với docker
- Tại sao lại chuyển provision tool từ chef ansible Chuyển đổi việc quản lý cluster từ chef sang cloudera manager Các setup liên quan đến cluster trước đây viết bằng chef không còn cần thiết Team có nhiều thay đổi đòi hỏi việc training. Một trong những training tốt nhất là cài đặt máy chủ == cách viết ansible script Công ty có thay đổi nhân sự. Người quản lý mới thích ansible (CRC32)
- Lý do chọn LXC: Công ty không có knowhow sử dụng openvz. Trước khi triển khai ở hệ thống này, công ty có lauch 1 dự án và có sử dụng thí điểm LXC Về cơ bản LXC giống openvz nên không có yếu tố performance gì trong này cả
- Các middleware opensource lưu trữ trên HDFS thay vì OS File System
- Nói về vấn đề latency – traffic tradeoff Global gate chạy webserver nhận file upload từ cloud Tại sao lại nhận file mà ko phải là đi lấy file khác? Hợp đồng IP với bên cloud tốn cost Tại sao lại không phải từ batch server đi mà lại từ một server riêng? Chuyện buồn: CRC = CRC32 Thiếu phương án join giữa dữ liệu ở stream layer và dữ liệu trên HDFS
- Đĩa cứng hỏng bay mất toàn bộ dữ liệu, không thể phục hồi Bài toán: Các máy chủ web phục vụ dịch vụ cho người dùng Log (Apache/App) được ghi ra file fluentd tail log file và gói mỗi “buffer size” dữ liệu và gửi đi dưới dạng 1 message Performance của fluentd có hạn a regular PC box can handle 18,000 messages/second with a single process. Bài toán: Máy chủ web sử dụng back network để liên lạc với back network (1G bonding) Nếu để buffer size quá cao back network sẽ có burst. Peak time có thể bị ảnh hưởng latency Nếu để buffer size thấp back network từ từ gửi. latency thấp nhưng số lượng msg tốn
- Ví dụ thực tế BUT (Big User Table): 48 trường dữ liệu, lưu trữ rất nhiều - Simpler queries - star schema join logic is generally simpler than the join logic required to retrieve data from a highly normalized transactional schemas. - Simplified business reporting logic - when compared to highly normalized schemas, the star schema simplifies common business reporting logic, such as period-over-period and as-of reporting. - Query performance gains - star schemas can provide performance enhancements for read-only reporting applications when compared to highly normalizedschemas. - Fast aggregations - the simpler queries against a star schema can result in improved performance for aggregation operations. - Feeding cubes - star schemas are used by all OLAP systems to build proprietary OLAP cubes efficiently; in fact, most major OLAP systems provide a ROLAPmode of operation which can use a star schema directly as a source without building a proprietary cube structure. The main disadvantage of the star schema is that data integrity is not enforced as well as it is in a highly normalized database. One-off inserts and updates can result in data anomalies which normalized schemas are designed to avoid
- Khi hệ thống vận hành với 40% năng lực của nó, đấy là lúc nên tính đến việc nâng cấp và mở rộng Giám sát chặt chẽ các tài nguyên hệ thống: I/O, Memory, CPU (sys/user), FileSystem (storage, inode), interrupt Am hiểu cách thức hoạt động của phần mềm Hadoop: CPU 100% là bình thường Cơ thể sống thay đổi hàng ngày Code cập nhật hàng ngày Server thay đổi hàng ngày Đĩa cứng hỏng hàng ngày Câu chuyện về Streaming. Người thiết kế và lựa chọn middleware không tính đến việc phục hồi khi có sự cố Một kỹ sư viết sai file cấu hình 2 log khác nhau ghi chung ra cùng 1 buffer directory log bị gửi không toàn vẹn và không thể phục hồi Một kỹ sư đưa ra phương án: cho máy chủ của tất cả các hệ thống khác dùng nfs mount để mount máy chủ batch của hệ thống bigdata. Các máy chủ web chỉ việc ghi dữ liệu vào phân vùng này loại bỏ việc scp / upload hàng ngày Phá sản vì cách làm này làm tăng tính phụ thuộc của tất cả các hệ thống khác vào batch module.
- Spark? Spark Streaming? SparkR? YARN? Mesos?
- Kể cả các công ty như cloudera không biết đâu là tương lai… Doug Cutting nói rằng ông không biết. Ông nói tương lai quyết định bởi cộng đồng