Chúng ta đang sống trong một thời đại tuyệt vời khi bạn có thể kết nối nhanh chóng và dễ dàng một số công cụ nguồn mở làm sẵn, thiết lập chúng với “ý thức đã tắt” theo lời khuyên của stackoverflow mà không cần đi sâu vào “nhiều chữ cái” và khởi chạy chúng vào hoạt động thương mại. Và khi bạn cần cập nhật/mở rộng hoặc ai đó vô tình khởi động lại một vài máy - bạn nhận ra rằng một loại giấc mơ tồi tệ ám ảnh nào đó đã bắt đầu, mọi thứ trở nên phức tạp đến mức không thể nhận ra, không có đường quay lại, tương lai mơ hồ và an toàn hơn, thay vì lập trình, hãy nuôi ong và làm pho mát.
Không phải vô cớ mà những đồng nghiệp giàu kinh nghiệm hơn, với cái đầu đầy lỗi và do đó đã xám xịt, đang dự tính triển khai cực kỳ nhanh chóng các gói “container” trong “khối” trên hàng chục máy chủ bằng “ngôn ngữ thời trang” với sự hỗ trợ tích hợp cho I/O không chặn không đồng bộ, hãy mỉm cười khiêm tốn. Và họ âm thầm tiếp tục đọc lại “man ps”, đào sâu vào mã nguồn “nginx” cho đến khi chảy máu mắt, và viết, viết, viết unit test. Các đồng nghiệp biết rằng điều thú vị nhất sẽ đến khi “tất cả những điều này” một ngày nào đó được đặt cược vào đêm giao thừa. Và họ sẽ chỉ được trợ giúp nhờ sự hiểu biết sâu sắc về bản chất của unix, bảng trạng thái TCP/IP được ghi nhớ và các thuật toán tìm kiếm sắp xếp cơ bản. Để hệ thống hoạt động trở lại khi tiếng chuông vang lên.
Ồ vâng, tôi hơi mất tập trung một chút, nhưng tôi hy vọng mình có thể truyền tải được trạng thái mong đợi.
Hôm nay tôi muốn chia sẻ kinh nghiệm của chúng tôi trong việc triển khai một ngăn xếp tiện lợi và không tốn kém cho DataLake, giải quyết phần lớn các nhiệm vụ phân tích trong công ty cho các bộ phận cấu trúc hoàn toàn khác nhau.
Cách đây một thời gian, chúng tôi đã hiểu rằng các công ty ngày càng cần thành quả của cả phân tích sản phẩm và kỹ thuật (chưa kể đến việc đóng băng dưới hình thức học máy) và để hiểu các xu hướng cũng như rủi ro - chúng tôi cần thu thập và phân tích ngày càng có nhiều số liệu hơn.
Phân tích kỹ thuật cơ bản trong Bitrix24
Vài năm trước, đồng thời với việc ra mắt dịch vụ Bitrix24, chúng tôi đã tích cực đầu tư thời gian và nguồn lực để tạo ra một nền tảng phân tích đơn giản và đáng tin cậy giúp nhanh chóng phát hiện các vấn đề trong cơ sở hạ tầng và lên kế hoạch cho bước tiếp theo. Tất nhiên, nên sử dụng những công cụ làm sẵn đơn giản và dễ hiểu nhất có thể. Kết quả là, nagios được chọn để theo dõi và munin để phân tích và trực quan hóa. Hiện tại, chúng tôi có hàng nghìn séc ở nagios, hàng trăm biểu đồ ở munin và các đồng nghiệp của chúng tôi sử dụng chúng thành công mỗi ngày. Các số liệu rõ ràng, biểu đồ rõ ràng, hệ thống đã hoạt động đáng tin cậy trong vài năm và các thử nghiệm và biểu đồ mới thường xuyên được thêm vào hệ thống: khi chúng tôi đưa một dịch vụ mới vào hoạt động, chúng tôi sẽ thêm một số thử nghiệm và biểu đồ. Chúc may mắn.
Bắt nhịp - Phân tích kỹ thuật nâng cao
Mong muốn nhận được thông tin về các vấn đề “càng nhanh càng tốt” đã dẫn chúng tôi đến những thử nghiệm tích cực với các công cụ đơn giản và dễ hiểu - pinba và xhprof.
Pinba đã gửi cho chúng tôi số liệu thống kê trong các gói UDP về tốc độ hoạt động của các phần của trang web bằng PHP và chúng tôi có thể thấy trực tuyến trong bộ lưu trữ MySQL (Pinba đi kèm với công cụ MySQL riêng để phân tích sự kiện nhanh) một danh sách ngắn các vấn đề và phản hồi cho họ. Và xhprof tự động cho phép chúng tôi thu thập biểu đồ về việc thực thi các trang PHP chậm nhất từ khách hàng và phân tích điều gì có thể dẫn đến điều này - một cách bình tĩnh, rót trà hoặc thứ gì đó mạnh hơn.
Cách đây một thời gian, bộ công cụ đã được bổ sung một công cụ khá đơn giản và dễ hiểu khác dựa trên thuật toán lập chỉ mục ngược, được triển khai hoàn hảo trong thư viện Lucene huyền thoại - Elastic/Kibana. Ý tưởng đơn giản về việc ghi tài liệu đa luồng vào chỉ mục Lucene nghịch đảo dựa trên các sự kiện trong nhật ký và tìm kiếm nhanh qua chúng bằng cách sử dụng phép chia khía cạnh hóa ra lại thực sự hữu ích.
Bất chấp sự xuất hiện khá kỹ thuật của trực quan hóa trong Kibana với các khái niệm cấp thấp như “xô” “chảy lên” và ngôn ngữ được phát minh lại của đại số quan hệ vẫn chưa hoàn toàn bị lãng quên, công cụ này đã bắt đầu giúp chúng tôi rất tốt trong các nhiệm vụ sau:
- Máy khách Bitrix24 có bao nhiêu lỗi PHP trên cổng p1 trong một giờ qua và đó là những lỗi nào? Hiểu, tha thứ và nhanh chóng sửa chữa.
- Có bao nhiêu cuộc gọi video được thực hiện trên các cổng ở Đức trong 24 giờ trước, với chất lượng như thế nào và có gặp khó khăn gì với kênh/mạng không?
- Chức năng hệ thống (tiện ích mở rộng C dành cho PHP của chúng tôi), được biên dịch từ nguồn trong bản cập nhật dịch vụ mới nhất và triển khai cho khách hàng, hoạt động tốt như thế nào? Có lỗi phân tách không?
- Dữ liệu khách hàng có vừa với bộ nhớ PHP không? Có bất kỳ lỗi nào về việc vượt quá bộ nhớ được phân bổ cho các tiến trình: “hết bộ nhớ” không? Tìm và vô hiệu hóa.
Đây là một ví dụ cụ thể. Mặc dù đã kiểm tra kỹ lưỡng và đa cấp, nhưng khách hàng, với trường hợp rất không chuẩn và dữ liệu đầu vào bị hỏng, đã nhận được một lỗi khó chịu và không mong muốn, tiếng còi báo động vang lên và quá trình khắc phục nhanh chóng bắt đầu:
Ngoài ra, kibana cho phép bạn sắp xếp thông báo cho các sự kiện cụ thể và trong một thời gian ngắn, công cụ này trong công ty đã bắt đầu được hàng chục nhân viên từ các bộ phận khác nhau sử dụng - từ hỗ trợ và phát triển kỹ thuật đến QA.
Hoạt động của bất kỳ bộ phận nào trong công ty đã trở nên thuận tiện để theo dõi và đo lường - thay vì phân tích thủ công nhật ký trên máy chủ, bạn chỉ cần thiết lập nhật ký phân tích cú pháp một lần và gửi chúng đến cụm đàn hồi để thưởng thức, ví dụ như chiêm ngưỡng trong kibana bảng điều khiển số lượng mèo con hai đầu được in trên máy in 3-D trong tháng âm lịch vừa qua.
Phân tích kinh doanh cơ bản
Mọi người đều biết rằng phân tích kinh doanh trong các công ty thường bắt đầu bằng việc sử dụng Excel một cách tích cực. Nhưng điều quan trọng là nó không kết thúc ở đó. Google Analytics dựa trên đám mây cũng đổ thêm dầu vào lửa - bạn nhanh chóng bắt đầu làm quen với những thứ hay ho.
Trong công ty đang phát triển hài hòa của chúng tôi, đây đó những “nhà tiên tri” về công việc chuyên sâu hơn với dữ liệu lớn hơn bắt đầu xuất hiện. Nhu cầu về các báo cáo chuyên sâu và đa diện hơn bắt đầu xuất hiện thường xuyên và nhờ nỗ lực của những người từ các bộ phận khác nhau, cách đây một thời gian, một giải pháp đơn giản và thiết thực đã được tổ chức - sự kết hợp giữa ClickHouse và PowerBI.
Trong một thời gian khá dài, giải pháp linh hoạt này đã giúp ích rất nhiều, nhưng dần dần người ta bắt đầu hiểu rằng ClickHouse không phải là cao su và không thể bị chế giễu như vậy.
Ở đây, điều quan trọng là phải hiểu rõ rằng ClickHouse, như Druid, như Vertica, như Amazon RedShift (dựa trên postgres), là các công cụ phân tích được tối ưu hóa cho các phân tích khá thuận tiện (tổng, tổng hợp, tối thiểu-tối đa theo cột và một số phép nối có thể có ), bởi vì được tổ chức để lưu trữ hiệu quả các cột của bảng quan hệ, không giống như MySQL và các cơ sở dữ liệu (định hướng hàng) khác mà chúng ta đã biết.
Về bản chất, ClickHouse chỉ là một “cơ sở dữ liệu” có dung lượng lớn hơn, với tính năng chèn từng điểm không thuận tiện lắm (đó là mục đích của nó, mọi thứ đều ổn), nhưng có những phân tích thú vị và một tập hợp các chức năng mạnh mẽ thú vị để làm việc với dữ liệu. Có, bạn thậm chí có thể tạo một cụm - nhưng bạn hiểu rằng việc đóng đinh bằng kính hiển vi là không hoàn toàn chính xác và chúng tôi bắt đầu tìm kiếm các giải pháp khác.
Nhu cầu về python và nhà phân tích
Công ty chúng tôi có nhiều nhà phát triển viết mã gần như hàng ngày trong 10-20 năm bằng PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ngoài ra còn có nhiều quản trị viên hệ thống có kinh nghiệm đã trải qua nhiều thảm họa hoàn toàn khó tin không phù hợp với quy luật thống kê (ví dụ: khi phần lớn các đĩa trong cuộc đột kích-10 bị phá hủy do sét đánh mạnh). Trong hoàn cảnh như vậy, trong một thời gian dài người ta vẫn chưa rõ “nhà phân tích trăn” là gì. Python giống như PHP, chỉ có điều tên dài hơn một chút và có ít dấu vết của các chất gây thay đổi tâm trí hơn trong mã nguồn của trình thông dịch. Tuy nhiên, khi ngày càng có nhiều báo cáo phân tích được tạo ra, các nhà phát triển có kinh nghiệm bắt đầu ngày càng hiểu được tầm quan trọng của việc chuyên môn hóa hẹp trong các công cụ như numpy, pandas, matplotlib, seaborn.
Rất có thể, vai trò quyết định thuộc về sự ngất xỉu đột ngột của nhân viên do sự kết hợp của từ “hồi quy logistic” và việc trình diễn báo cáo hiệu quả về dữ liệu lớn bằng cách sử dụng, vâng, vâng, pyspark.
Apache Spark, mô hình chức năng của nó mà đại số quan hệ hoàn toàn phù hợp và khả năng của nó đã gây ấn tượng với các nhà phát triển đã quen với MySQL đến mức nhu cầu tăng cường thứ hạng với các nhà phân tích có kinh nghiệm đã trở nên rõ ràng như ngày nay.
Những nỗ lực tiếp theo của Apache Spark/Hadoop để thành công và những gì không diễn ra theo đúng kịch bản
Tuy nhiên, mọi người sớm nhận ra rằng có điều gì đó không ổn về mặt hệ thống với Spark hoặc đơn giản là bạn cần phải rửa tay kỹ hơn. Nếu ngăn xếp Hadoop/MapReduce/Lucene được tạo ra bởi các lập trình viên khá có kinh nghiệm, điều này là hiển nhiên nếu bạn nhìn kỹ vào mã nguồn trong Java hoặc các ý tưởng của Doug Cut trong Lucene, thì Spark đột nhiên được viết bằng ngôn ngữ kỳ lạ Scala, đó là rất gây tranh cãi về mặt thực tiễn và hiện chưa phát triển. Và việc thường xuyên giảm số lượng tính toán trên cụm Spark do công việc phi logic và không minh bạch với việc phân bổ bộ nhớ cho các hoạt động rút gọn (nhiều phím đến cùng một lúc) đã tạo ra vầng hào quang xung quanh nó về một thứ gì đó có chỗ để phát triển. Ngoài ra, tình hình còn trở nên trầm trọng hơn do có một số lượng lớn các cổng mở lạ, các tệp tạm thời phát triển ở những nơi khó hiểu nhất và vô số phụ thuộc vào jar - khiến các quản trị viên hệ thống có một cảm giác quen thuộc từ thời thơ ấu: lòng căm thù mãnh liệt (hoặc có thể là họ cần rửa tay bằng xà phòng).
Kết quả là, chúng tôi đã “sống sót” được một số dự án phân tích nội bộ sử dụng tích cực Apache Spark (bao gồm Spark Streaming, Spark SQL) và hệ sinh thái Hadoop (v.v.). Mặc dù thực tế là theo thời gian, chúng tôi đã học cách chuẩn bị và giám sát “nó” khá tốt và “nó” gần như ngừng hoạt động đột ngột do những thay đổi về bản chất của dữ liệu và sự mất cân bằng của hàm băm RDD thống nhất, mong muốn chuẩn bị sẵn một thứ gì đó , được cập nhật và quản lý ở đâu đó trên đám mây ngày càng mạnh mẽ hơn. Vào thời điểm này, chúng tôi đã cố gắng sử dụng tập hợp đám mây được tạo sẵn của Amazon Web Services - và sau đó cố gắng giải quyết các vấn đề bằng cách sử dụng nó. EMR là Apache Spark do Amazon chuẩn bị với phần mềm bổ sung từ hệ sinh thái, giống như các bản dựng Cloudera/Hortonworks.
Lưu trữ tệp cao su để phân tích là một nhu cầu cấp thiết
Kinh nghiệm “nấu” Hadoop/Spark bị bỏng ở nhiều bộ phận khác nhau trên cơ thể không phải là vô ích. Nhu cầu tạo một bộ lưu trữ tệp duy nhất, rẻ tiền và đáng tin cậy có khả năng chống lại các lỗi phần cứng và trong đó có thể lưu trữ các tệp ở các định dạng khác nhau từ các hệ thống khác nhau và tạo các mẫu hiệu quả và tiết kiệm thời gian cho các báo cáo từ dữ liệu này ngày càng trở nên phổ biến. thông thoáng.
Tôi cũng muốn rằng việc cập nhật phần mềm của nền tảng này không trở thành cơn ác mộng trong năm mới khi đọc dấu vết Java dài 20 trang và phân tích nhật ký chi tiết dài hàng km của cụm bằng Spark History Server và kính lúp có đèn nền. Tôi muốn có một công cụ đơn giản và minh bạch, không yêu cầu phải tìm hiểu sâu thường xuyên nếu yêu cầu MapReduce tiêu chuẩn của nhà phát triển ngừng thực thi khi trình xử lý dữ liệu rút gọn hết bộ nhớ do thuật toán phân vùng dữ liệu nguồn không được chọn kỹ lưỡng.
Amazon S3 có phải là ứng cử viên cho DataLake không?
Kinh nghiệm với Hadoop/MapReduce đã dạy chúng tôi rằng chúng tôi cần một hệ thống tệp đáng tin cậy, có thể mở rộng và các nhân viên có thể mở rộng trên đó, “đến” gần hơn với dữ liệu để không điều khiển dữ liệu qua mạng. Công nhân phải có khả năng đọc dữ liệu ở các định dạng khác nhau, nhưng tốt nhất là không đọc những thông tin không cần thiết và có thể lưu trữ trước dữ liệu ở các định dạng thuận tiện cho công nhân.
Một lần nữa, ý tưởng cơ bản. Không có mong muốn “đổ” dữ liệu lớn vào một công cụ phân tích cụm duy nhất, điều này sớm hay muộn sẽ bị nghẹt thở và bạn sẽ phải phân chia nó một cách xấu xí. Tôi muốn lưu trữ các tệp, chỉ các tệp, ở định dạng dễ hiểu và thực hiện các truy vấn phân tích hiệu quả trên chúng bằng các công cụ khác nhau nhưng dễ hiểu. Và sẽ ngày càng có nhiều tệp ở các định dạng khác nhau. Và tốt hơn hết là không nên phân mảnh động cơ mà là dữ liệu nguồn. Chúng tôi cần một DataLake có thể mở rộng và phổ quát, chúng tôi đã quyết định...
Điều gì sẽ xảy ra nếu bạn lưu trữ các tệp trong bộ lưu trữ đám mây có khả năng mở rộng quen thuộc và nổi tiếng Amazon S3 mà không cần phải chuẩn bị các phần của riêng mình từ Hadoop?
Rõ ràng là dữ liệu cá nhân ở mức “thấp”, nhưng còn những dữ liệu khác thì sao nếu chúng ta lấy nó ra và “điều khiển nó một cách hiệu quả”?
Hệ sinh thái phân tích dữ liệu lớn theo cụm của Amazon Web Services - nói một cách rất đơn giản
Đánh giá theo kinh nghiệm của chúng tôi với AWS, Apache Hadoop/MapReduce đã được sử dụng tích cực ở đó trong một thời gian dài dưới nhiều loại nước sốt khác nhau, chẳng hạn như trong dịch vụ DataPipeline (Tôi ghen tị với các đồng nghiệp của mình, họ đã học được cách chuẩn bị nó một cách chính xác). Ở đây chúng tôi thiết lập bản sao lưu từ các dịch vụ khác nhau từ bảng DynamoDB:
Và chúng đã chạy thường xuyên trên các cụm Hadoop/MapReduce được nhúng như kim đồng hồ trong vài năm nay. "Chấp nhận nó và quên nó đi":
Bạn cũng có thể tham gia chủ nghĩa satan dữ liệu một cách hiệu quả bằng cách thiết lập máy tính xách tay Jupiter trên đám mây cho các nhà phân tích và sử dụng dịch vụ AWS SageMaker để đào tạo và triển khai các mô hình AI vào trận chiến. Đây là những gì nó trông giống như đối với chúng tôi:
Và vâng, bạn có thể lấy một chiếc máy tính xách tay cho chính mình hoặc một nhà phân tích trên đám mây và gắn nó vào cụm Hadoop/Spark, thực hiện các phép tính và sau đó hoàn thiện mọi thứ:
Thực sự thuận tiện cho các dự án phân tích riêng lẻ và đối với một số dự án, chúng tôi đã sử dụng thành công dịch vụ EMR để tính toán và phân tích quy mô lớn. Còn giải pháp hệ thống cho DataLake thì sao, liệu nó có hoạt động được không? Lúc này chúng tôi đang trên bờ vực hy vọng và tuyệt vọng và tiếp tục cuộc tìm kiếm.
AWS Glue - Apache Spark được đóng gói gọn gàng trên steroid
Hóa ra AWS có phiên bản riêng của ngăn xếp “Hive/Pig/Spark”. Vai trò của Hive, tức là Danh mục tệp và loại của chúng trong DataLake được thực hiện bởi dịch vụ “Danh mục dữ liệu”, không che giấu khả năng tương thích của nó với định dạng Apache Hive. Bạn cần thêm thông tin vào dịch vụ này về vị trí tệp của bạn và định dạng của chúng. Dữ liệu không chỉ có trong s3 mà còn có trong cơ sở dữ liệu, nhưng đó không phải là chủ đề của bài đăng này. Đây là cách tổ chức thư mục dữ liệu DataLake của chúng tôi:
Các tập tin đã được đăng ký, tuyệt vời. Nếu các tệp đã được cập nhật, chúng tôi sẽ khởi chạy trình thu thập thông tin theo cách thủ công hoặc theo lịch trình, trình thu thập thông tin này sẽ cập nhật thông tin về chúng từ hồ và lưu chúng. Sau đó dữ liệu từ hồ có thể được xử lý và kết quả được tải lên đâu đó. Trong trường hợp đơn giản nhất, chúng tôi cũng tải lên s3. Việc xử lý dữ liệu có thể được thực hiện ở mọi nơi nhưng bạn nên định cấu hình quy trình xử lý trên cụm Apache Spark bằng các khả năng nâng cao thông qua API AWS Glue. Trên thực tế, bạn có thể lấy mã python cũ và quen thuộc bằng thư viện pyspark và định cấu hình thực thi nó trên N nút của một cụm có dung lượng nhất định có giám sát mà không cần đào sâu vào Hadoop và kéo các thùng chứa docker-moker và loại bỏ xung đột phụ thuộc .
Một lần nữa, một ý tưởng đơn giản. Không cần định cấu hình Apache Spark, bạn chỉ cần viết mã python cho pyspark, kiểm tra cục bộ trên máy tính để bàn của bạn và sau đó chạy nó trên một cụm lớn trên đám mây, chỉ định vị trí của dữ liệu nguồn và nơi đặt kết quả. Đôi khi điều này là cần thiết và hữu ích và đây là cách chúng tôi thiết lập nó:
Do đó, nếu bạn cần tính toán điều gì đó trên cụm Spark bằng cách sử dụng dữ liệu trong s3, chúng tôi sẽ viết mã bằng python/pyspark, kiểm tra nó và chúc may mắn cho đám mây.
Thế còn dàn nhạc thì sao? Điều gì sẽ xảy ra nếu nhiệm vụ bị rơi và biến mất? Đúng, chúng tôi đề xuất tạo một quy trình đẹp mắt theo phong cách Apache Pig và chúng tôi thậm chí đã thử chúng, nhưng hiện tại, chúng tôi đã quyết định sử dụng cách phối hợp được tùy chỉnh sâu trong PHP và JavaScript (Tôi hiểu, có sự bất đồng về nhận thức, nhưng nó hoạt động, vì năm và không có lỗi).
Định dạng của các tập tin được lưu trữ trong hồ là chìa khóa cho hiệu suất
Điều rất quan trọng là phải hiểu thêm hai điểm chính nữa. Để các truy vấn trên dữ liệu tệp trong lake được thực thi nhanh nhất có thể và hiệu suất không bị giảm khi thông tin mới được thêm vào, bạn cần phải:
- Lưu trữ các cột của tệp riêng biệt (để bạn không phải đọc tất cả các dòng để hiểu nội dung trong các cột). Để làm điều này, chúng tôi đã sử dụng định dạng sàn gỗ có tính năng nén
- Điều rất quan trọng là chia nhỏ tập tin vào các thư mục như: ngôn ngữ, năm, tháng, ngày, tuần. Các công cụ hiểu được loại phân đoạn này sẽ chỉ xem xét các thư mục cần thiết mà không sàng lọc tất cả dữ liệu liên tiếp.
Về cơ bản, theo cách này, bạn sắp xếp dữ liệu nguồn ở dạng hiệu quả nhất cho các công cụ phân tích được đặt ở trên cùng, mà ngay cả trong các thư mục được chia nhỏ cũng có thể nhập và chỉ đọc có chọn lọc các cột cần thiết từ tệp. Bạn không cần phải "lấp đầy" dữ liệu ở bất cứ đâu (bộ lưu trữ sẽ đơn giản bùng nổ) - chỉ cần đặt nó ngay lập tức một cách khôn ngoan vào hệ thống tệp ở định dạng chính xác. Tất nhiên, ở đây cần nói rõ rằng việc lưu trữ một tệp csv lớn trong DataLake, trước tiên phải được đọc từng dòng theo cụm để trích xuất các cột, là không nên lắm. Hãy suy nghĩ lại về hai điểm trên nếu vẫn chưa rõ tại sao tất cả những điều này lại xảy ra.
AWS Athena - chiếc hộp độc đáo
Và rồi, khi đang tạo ra một cái hồ, không hiểu sao chúng tôi lại vô tình bắt gặp Amazon Athena. Đột nhiên, hóa ra là bằng cách sắp xếp cẩn thận các tệp nhật ký khổng lồ của chúng tôi thành các phân đoạn thư mục theo định dạng cột (sàn gỗ) chính xác, bạn có thể nhanh chóng đưa ra các lựa chọn cực kỳ thông tin từ chúng và tạo báo cáo KHÔNG CÓ, mà không cần cụm Apache Spark/Glue.
Công cụ Athena được hỗ trợ bởi dữ liệu trong s3 dựa trên huyền thoại - một đại diện của nhóm phương pháp tiếp cận xử lý dữ liệu MPP (xử lý song song lớn), lấy dữ liệu ở nơi nó nằm, từ s3 và Hadoop đến Cassandra và các tệp văn bản thông thường. Bạn chỉ cần yêu cầu Athena thực hiện một truy vấn SQL và sau đó mọi thứ “hoạt động nhanh chóng và tự động”. Điều quan trọng cần lưu ý là Athena rất “thông minh”, nó chỉ đi đến các thư mục được phân chia cần thiết và chỉ đọc các cột cần thiết trong yêu cầu.
Giá cho các yêu cầu tới Athena cũng rất thú vị. Chúng tôi trả tiền cho . Những thứ kia. không phải cho số lượng máy trong cụm mỗi phút, mà... cho dữ liệu thực sự được quét trên 100-500 máy, chỉ dữ liệu cần thiết để hoàn thành yêu cầu.
Và bằng cách chỉ yêu cầu các cột cần thiết từ các thư mục được phân chia chính xác, hóa ra dịch vụ Athena khiến chúng tôi tốn hàng chục đô la mỗi tháng. Chà, thật tuyệt, gần như miễn phí, so với phân tích trên các cụm!
Nhân tiện, đây là cách chúng tôi phân chia dữ liệu của mình trong s3:
Kết quả là, trong một thời gian ngắn, các bộ phận hoàn toàn khác nhau trong công ty, từ bảo mật thông tin đến phân tích, bắt đầu tích cực đưa ra yêu cầu tới Athena và nhanh chóng, chỉ trong vài giây, nhận được câu trả lời hữu ích từ dữ liệu “lớn” trong khoảng thời gian khá dài: hàng tháng, nửa năm, v.v. P.
Nhưng chúng tôi đã đi xa hơn và bắt đầu lên đám mây để tìm câu trả lời : một nhà phân tích viết một truy vấn SQL trong một bảng điều khiển quen thuộc, trên 100-500 máy “cho từng xu” sẽ gửi dữ liệu đến s3 và thường trả về câu trả lời sau vài giây. Thoải mái. Va nhanh nhẹn. Tôi vẫn không thể tin được.
Do đó, khi quyết định lưu trữ dữ liệu trong s3, ở định dạng cột hiệu quả và phân chia dữ liệu hợp lý vào các thư mục... chúng tôi đã nhận được DataLake và một công cụ phân tích nhanh và rẻ - miễn phí. Và anh ấy trở nên rất nổi tiếng trong công ty, bởi vì... hiểu SQL và hoạt động theo thứ tự cường độ nhanh hơn so với việc bắt đầu/dừng/thiết lập các cụm. “Và nếu kết quả giống nhau thì tại sao phải trả nhiều tiền hơn?”
Một yêu cầu gửi tới Athena trông giống như thế này. Tất nhiên, nếu muốn, bạn có thể tạo đủ , nhưng chúng ta sẽ giới hạn ở việc phân nhóm đơn giản. Hãy xem khách hàng có mã phản hồi nào vài tuần trước trong nhật ký máy chủ web và đảm bảo không có lỗi:
Những phát hiện
Trải qua, không phải nói là một con đường dài nhưng đầy đau đớn, liên tục đánh giá đầy đủ rủi ro, mức độ phức tạp cũng như chi phí hỗ trợ, chúng tôi đã tìm ra giải pháp cho DataLake và phân tích không bao giờ ngừng làm chúng tôi hài lòng cả về tốc độ và chi phí sở hữu.
Hóa ra việc xây dựng một DataLake hoạt động hiệu quả, nhanh chóng và rẻ tiền cho nhu cầu của các bộ phận hoàn toàn khác nhau trong công ty là hoàn toàn nằm trong khả năng của ngay cả những nhà phát triển giàu kinh nghiệm, những người chưa từng làm kiến trúc sư và không biết cách vẽ hình vuông trên hình vuông bằng mũi tên và biết 50 thuật ngữ từ hệ sinh thái Hadoop.
Khi bắt đầu cuộc hành trình, trong đầu tôi như tách ra khỏi vô số vườn thú hoang dã của phần mềm đóng mở và hiểu biết về gánh nặng trách nhiệm đối với con cháu. Chỉ cần bắt đầu xây dựng DataLake của bạn từ các công cụ đơn giản: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., thu thập phản hồi và hiểu sâu sắc về tính chất vật lý của các quá trình đang diễn ra. Mọi thứ phức tạp và âm u - hãy giao nó cho kẻ thù và đối thủ cạnh tranh.
Nếu bạn không muốn truy cập vào đám mây và muốn hỗ trợ, cập nhật và vá lỗi các dự án nguồn mở, bạn có thể xây dựng một sơ đồ tương tự như sơ đồ của chúng tôi tại địa phương, trên các máy văn phòng rẻ tiền có Hadoop và Presto ở trên cùng. Điều chính là không dừng lại và tiến về phía trước, tính toán, tìm kiếm các giải pháp đơn giản và rõ ràng, và mọi việc chắc chắn sẽ ổn thỏa! Chúc mọi người may mắn và hẹn gặp lại!
Nguồn: www.habr.com