매우 효율적이고 저렴한 DataLake를 구성한 방법과 그 이유

우리는 기성 오픈 소스 도구 여러 개를 빠르고 쉽게 연결하고, “여러 글자”를 깊이 파고들 필요 없이 stackoverflow의 조언에 따라 “의식을 끈 상태”로 설정하고 출시할 수 있는 놀라운 시대에 살고 있습니다. 상업적인 운영에 들어갑니다. 그리고 업데이트/확장이 필요하거나 누군가 실수로 몇 대의 컴퓨터를 재부팅한 경우, 현실에서 일종의 강박적인 나쁜 꿈이 시작되었고 모든 것이 갑자기 인식할 수 없을 정도로 더 복잡해졌고 되돌릴 수 없으며 미래가 막연하다는 것을 깨닫게 됩니다. 프로그래밍하는 대신 꿀벌을 키우고 치즈를 만드는 것이 더 안전합니다.

머리에 버그가 흩뿌려져 이미 회색인 경험 많은 동료들이 내장된 지원 기능을 갖춘 "유행 언어"로 된 수십 개의 서버에 "큐브"에 "컨테이너" 팩을 엄청나게 빠르게 배포하는 것을 고려하는 것은 아무것도 아닙니다. 비동기 비차단 I/O, 겸손하게 웃으세요. 그리고 그들은 조용히 계속해서 "man ps"를 다시 읽고, 눈물이 나올 때까지 "nginx" 소스 코드를 조사하고, 쓰고, 쓰고, 단위 테스트를 작성합니다. 동료들은 어느 날 "이 모든 것"이 새해 전날 밤에 결정될 때 가장 흥미로운 일이 올 것이라는 것을 알고 있습니다. 그리고 유닉스의 본질, 기억된 TCP/IP 상태 테이블 및 기본 정렬 검색 알고리즘에 대한 깊은 이해를 통해서만 도움이 될 것입니다. 차임벨이 울리면 시스템에 다시 생명을 불어넣습니다.

아 네, 조금 정신이 혼미해지긴 했지만, 기대감이 잘 전달되었으면 좋겠습니다.
오늘 저는 완전히 다른 구조적 부서에 대한 회사의 대부분의 분석 작업을 해결하는 편리하고 저렴한 DataLake용 스택을 배포한 경험을 공유하고 싶습니다.

얼마 전 우리는 기업이 점점 더 제품 분석과 기술 분석(기계 학습의 형태로 금상첨화는 말할 것도 없고)의 성과를 필요로 하고 추세와 위험을 이해해야 한다는 점을 이해하게 되었습니다. 수집하고 분석해야 합니다. 점점 더 많은 측정항목이 추가되었습니다.

Bitrix24의 기본 기술 분석

몇 년 전 Bitrix24 서비스 출시와 동시에 인프라의 문제를 신속하게 확인하고 다음 단계를 계획하는 데 도움이 되는 간단하고 안정적인 분석 플랫폼을 만드는 데 시간과 자원을 적극적으로 투자했습니다. 물론, 가능한 한 간단하고 이해하기 쉬운 기성 도구를 사용하는 것이 좋습니다. 결과적으로 모니터링에는 nagios가, 분석 및 시각화에는 munin이 선택되었습니다. 이제 우리는 nagios에 수천 개의 수표를, munin에 수백 개의 차트를 보유하고 있으며 동료들은 이를 매일 성공적으로 사용하고 있습니다. 측정 기준이 명확하고 그래프도 명확하며 시스템은 수년 동안 안정적으로 작동해 왔으며 새로운 테스트와 그래프가 정기적으로 추가됩니다. 새로운 서비스를 운영할 때 여러 테스트와 그래프를 추가합니다. 행운을 빌어요.

펄스에 손가락 - 고급 기술 분석

"가능한 한 빨리" 문제에 대한 정보를 받고자 하는 열망으로 인해 우리는 pinba 및 xhprof라는 간단하고 이해하기 쉬운 도구를 사용하여 적극적인 실험을 하게 되었습니다.

Pinba는 PHP 웹 페이지 일부의 작동 속도에 대한 통계를 UDP 패킷으로 우리에게 보냈고, 우리는 MySQL 저장소에서 온라인으로 볼 수 있었습니다(Pinba는 빠른 이벤트 분석을 위해 자체 MySQL 엔진과 함께 제공됨). 짧은 문제 목록을 보고 이에 대응할 수 있었습니다. 그들을. 그리고 xhprof를 사용하면 자동으로 클라이언트로부터 가장 느린 PHP 페이지의 실행 그래프를 수집하고 이로 이어질 수 있는 원인(침착하게 차를 따르거나 더 강한 것)을 분석할 수 있었습니다.

얼마 전 이 툴킷에는 전설적인 Lucene 라이브러리인 Elastic/Kibana에서 완벽하게 구현된 역방향 인덱싱 알고리즘을 기반으로 하는 상당히 간단하고 이해하기 쉬운 또 다른 엔진이 추가되었습니다. 로그의 이벤트를 기반으로 문서를 역 Lucene 인덱스에 멀티 스레드로 기록하고 패싯 분할을 사용하여 이를 빠르게 검색하는 간단한 아이디어가 정말 유용한 것으로 나타났습니다.

"버킷"과 같은 하위 수준 개념과 아직 완전히 잊혀지지 않은 관계형 대수학의 재창조된 언어를 사용하여 Kibana에서 시각화가 다소 기술적으로 나타남에도 불구하고 이 도구는 다음 작업에서 우리에게 큰 도움이 되기 시작했습니다.

• 지난 한 시간 동안 Bitrix24 클라이언트가 p1 포털에서 몇 개의 PHP 오류를 겪었으며 어떤 오류가 발생했습니까? 이해하고 용서하고 신속하게 수정하십시오.
• 지난 24시간 동안 독일 포털에서 얼마나 많은 영상 통화가 이루어졌습니까? 품질은 어떠했으며 채널/네트워크에 어려움은 없었습니까?
• 최신 서비스 업데이트의 소스에서 컴파일되어 클라이언트에 출시된 시스템 기능(PHP용 C 확장)이 얼마나 잘 작동합니까? 세그폴트가 있나요?
• 고객 데이터가 PHP 메모리에 맞나요? 프로세스에 할당된 메모리를 초과하여 "메모리 부족" 오류가 발생합니까? 찾아서 무력화하세요.

여기에 구체적인 예가 있습니다. 철저한 다단계 테스트에도 불구하고 매우 비표준적인 케이스와 손상된 입력 데이터가 있는 클라이언트는 짜증나고 예상치 못한 오류를 수신했으며 사이렌이 울리고 이를 신속하게 수정하는 프로세스가 시작되었습니다.

또한 Kibana를 사용하면 특정 이벤트에 대한 알림을 구성할 수 있으며 짧은 시간 내에 기술 지원 및 개발에서 QA에 이르기까지 다양한 부서의 수십 명의 직원이 회사의 도구를 사용하기 시작했습니다.

회사 내 모든 부서의 활동을 추적하고 측정하는 것이 편리해졌습니다. 서버의 로그를 수동으로 분석하는 대신, 한 번만 구문 분석 로그를 설정하고 탄력적 클러스터로 보내면 됩니다. 지난 달에 3D 프린터로 인쇄한 머리 두 개 달린 새끼 고양이의 판매량을 대시보드에 표시합니다.

기본 비즈니스 분석

기업의 비즈니스 분석은 Excel을 극도로 적극적으로 사용하는 것에서 시작되는 경우가 많다는 것은 누구나 알고 있습니다. 그러나 가장 중요한 것은 그것이 끝나지 않는다는 것입니다. 클라우드 기반 Google Analytics는 또한 불에 연료를 추가합니다. 좋은 일에 빨리 익숙해지기 시작합니다.

조화롭게 발전하는 우리 회사에서는 더 큰 데이터를 사용하여 더 집중적으로 작업하는 "예언자"가 여기 저기 나타나기 시작했습니다. 보다 심층적이고 다각적인 보고서에 대한 필요성이 정기적으로 나타나기 시작했으며, 여러 부서의 사람들의 노력을 통해 얼마 전 ClickHouse와 PowerBI의 조합이라는 간단하고 실용적인 솔루션이 구성되었습니다.

오랫동안 이 유연한 솔루션은 많은 도움이 되었지만 ClickHouse는 고무가 아니며 그렇게 조롱할 수 없다는 사실이 점차 이해되기 시작했습니다.

여기에서는 Druid, Vertica, Amazon RedShift(포스트그레 기반)와 같은 ClickHouse가 상당히 편리한 분석(합계, 집계, 열별 최소-최대 및 몇 가지 가능한 조인)에 최적화된 분석 엔진이라는 점을 잘 이해하는 것이 중요합니다. ), 왜냐하면 MySQL 및 우리에게 알려진 다른 (행 중심) 데이터베이스와 달리 관계형 테이블의 열을 효율적으로 저장하도록 구성되었습니다.

본질적으로 ClickHouse는 매우 편리한 지점별 삽입이 아닌(의도한 대로 모든 것이 정상임) 더 넓은 "데이터베이스"이지만 유쾌한 분석과 데이터 작업을 위한 일련의 흥미롭고 강력한 기능을 갖추고 있습니다. 예, 클러스터를 만들 수도 있습니다. 하지만 현미경으로 못을 두드리는 것이 완전히 정확하지 않다는 것을 이해하고 우리는 다른 솔루션을 찾기 시작했습니다.

Python 및 분석가에 대한 수요

우리 회사에는 PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash 등을 사용하여 10~20년 동안 거의 매일 코드를 작성하는 개발자가 많이 있습니다. 또한 통계 법칙에 맞지 않는 절대적으로 놀라운 재난을 두 번 이상 경험한 숙련된 시스템 관리자도 많이 있습니다(예를 들어, raid-10의 디스크 대부분이 강한 낙뢰로 인해 파괴되는 경우). 이러한 상황에서 오랫동안 "파이썬 분석가"가 무엇인지 명확하지 않았습니다. Python은 PHP와 같습니다. 이름만 조금 더 길고 인터프리터의 소스 코드에 마음을 바꾸는 물질의 흔적이 조금 적습니다. 그러나 점점 더 많은 분석 보고서가 생성됨에 따라 숙련된 개발자는 numpy, pandas, matplotlib, seaborn과 같은 도구에 대한 좁은 전문화의 중요성을 점점 더 이해하기 시작했습니다.
결정적인 역할은 "로지스틱 회귀"라는 단어와 예, 예, pyspark를 사용하여 대규모 데이터에 대한 효과적인 보고 시연의 조합으로 인해 직원이 갑자기 기절한 것이었을 가능성이 높습니다.

관계형 대수학이 완벽하게 들어맞는 기능적 패러다임인 Apache Spark와 그 기능은 MySQL에 익숙한 개발자들에게 깊은 인상을 주었기 때문에 숙련된 분석가와 함께 순위를 강화해야 할 필요성이 날로 분명해졌습니다.

Apache Spark/Hadoop의 추가 시도와 스크립트에 따라 진행되지 않은 사항

그러나 스파크에 시스템적으로 문제가 있거나 손을 더 잘 씻는 것이 필요하다는 것이 곧 분명해졌습니다. Hadoop/MapReduce/Lucene 스택이 상당히 숙련된 프로그래머에 의해 만들어진 경우(Java의 소스 코드나 Lucene에 대한 Doug Cutting의 아이디어를 자세히 살펴보면 분명히 알 수 있음) Spark는 갑자기 이국적인 언어인 Scala로 작성됩니다. 실용성 측면에서 매우 논란의 여지가 있으며 현재 개발 중이 아닙니다. 그리고 축소 작업을 위한 메모리 할당(한 번에 많은 키가 도착함)에 대한 비논리적이고 투명하지 않은 작업으로 인해 Spark 클러스터에서 계산이 정기적으로 감소하여 주변에 성장할 여지가 있는 후광이 생겼습니다. 게다가, 수많은 이상한 열린 포트, 가장 이해할 수 없는 곳에서 증가하는 임시 파일, 엄청난 jar 종속성으로 인해 상황이 더욱 악화되었습니다. 이로 인해 시스템 관리자는 어린 시절부터 잘 알려진 한 가지 감정을 갖게 되었습니다. 비누로 손을 씻어야 했습니다.)

그 결과, 우리는 Apache Spark(Spark Streaming, Spark SQL 포함) 및 Hadoop 에코시스템(등)을 적극적으로 사용하는 여러 내부 분석 프로젝트를 "생존"했습니다. 시간이 지남에 따라 우리는 "그것"을 아주 잘 준비하고 모니터링하는 방법을 배웠고 데이터 특성의 변화와 균일한 RDD 해싱의 불균형, 이미 준비된 것을 가져오려는 욕구로 인해 "그것"이 갑자기 충돌하는 것을 실질적으로 멈췄다는 사실에도 불구하고 , 클라우드 어딘가에서 업데이트되고 관리되는 것이 점점 더 강력해졌습니다. 이때 우리는 Amazon Web Services의 기성 클라우드 어셈블리를 사용하려고 했습니다. EMR 그리고 이를 이용해 문제를 해결하려고 노력했습니다. EMR은 Cloudera/Hortonworks 빌드와 마찬가지로 Amazon에서 에코시스템의 추가 소프트웨어를 사용하여 준비한 Apache Spark입니다.

분석을 위한 고무 파일 스토리지가 시급히 필요합니다.

신체 여러 부위에 화상을 입히면서 Hadoop/Spark를 '요리'한 경험은 헛되지 않았습니다. 하드웨어 오류에 강하고 다양한 시스템의 다양한 형식으로 파일을 저장하고 이 데이터에서 보고서용 효율적이고 시간 효율적인 샘플을 만들 수 있는 저렴하고 안정적인 단일 파일 스토리지를 생성해야 할 필요성이 점점 더 커졌습니다. 분명한.

또한 저는 이 플랫폼의 소프트웨어 업데이트가 20페이지 분량의 Java 추적을 읽고 Spark History Server와 백라이트 돋보기를 사용하여 클러스터의 킬로미터 길이의 상세한 로그를 분석하는 새해의 악몽으로 바뀌지 않기를 바랐습니다. 잘 선택되지 않은 소스 데이터 분할 알고리즘으로 인해 축소 데이터 작업자가 메모리 부족으로 인해 개발자의 표준 MapReduce 요청 실행이 중지된 경우 내부적으로 정기적인 다이빙이 필요하지 않은 간단하고 투명한 도구를 갖고 싶었습니다.

Amazon S3는 DataLake의 후보입니까?

Hadoop/MapReduce에 대한 경험을 통해 우리는 확장 가능하고 신뢰할 수 있는 파일 시스템과 그 위에 확장 가능한 작업자가 필요하며 네트워크를 통해 데이터를 이동하지 않도록 데이터에 "더 가까이 다가가"야 한다는 사실을 알게 되었습니다. 작업자는 다양한 형식의 데이터를 읽을 수 있어야 하지만, 불필요한 정보를 읽지 않는 것이 바람직하고 작업자에게 편리한 형식으로 미리 데이터를 저장할 수 있는 것이 좋습니다.

다시 한 번 기본 아이디어입니다. 단일 클러스터 분석 엔진에 빅 데이터를 "쏟아넣고" 싶지는 않습니다. 그러면 조만간 질식하게 되고 보기 흉하게 파쇄해야 할 것입니다. 나는 파일을 이해할 수 있는 형식으로 저장하고 다양하지만 이해할 수 있는 도구를 사용하여 효과적인 분석 쿼리를 수행하고 싶습니다. 그리고 다양한 형식의 파일이 점점 더 많아질 것입니다. 그리고 엔진이 아닌 소스 데이터를 샤딩하는 것이 좋습니다. 확장 가능하고 보편적인 DataLake가 필요하다고 결정했습니다...

Hadoop에서 직접 준비할 필요 없이 친숙하고 잘 알려진 확장 가능한 클라우드 스토리지 Amazon S3에 파일을 저장한다면 어떻게 될까요?

개인 데이터가 '낮다'는 것은 분명하지만, 다른 데이터를 꺼내서 '효과적으로 구동'하면 어떻게 될까요?

Amazon Web Services의 클러스터-빅데이터-분석 생태계 - 매우 간단한 말로

AWS에서의 경험으로 판단하면 Apache Hadoop/MapReduce는 DataPipeline 서비스와 같은 다양한 소스에서 오랫동안 적극적으로 사용되어 왔습니다(저는 동료들이 부럽습니다. 그들은 올바르게 준비하는 방법을 배웠습니다). 여기서는 DynamoDB 테이블의 다양한 서비스에서 백업을 설정합니다.


그리고 그들은 몇 년 동안 시계처럼 내장된 Hadoop/MapReduce 클러스터에서 정기적으로 실행되어 왔습니다. “설정하고 잊어버리세요”:

또한 분석가를 위해 클라우드에 Jupiter 노트북을 설정하고 AWS SageMaker 서비스를 사용하여 AI 모델을 훈련하고 전투에 배포함으로써 데이터 악마주의에 효과적으로 참여할 수도 있습니다. 우리에게 보이는 모습은 다음과 같습니다.

그리고 그렇습니다. 클라우드에서 자신이나 분석가를 위해 노트북을 선택하여 Hadoop/Spark 클러스터에 연결하고 계산을 수행한 다음 모든 것을 정리할 수 있습니다.

개별 분석 프로젝트에 매우 편리하며 일부의 경우 대규모 계산 및 분석에 EMR 서비스를 성공적으로 사용했습니다. DataLake용 시스템 솔루션은 어떻습니까? 작동할까요? 지금 이 순간 우리는 희망과 절망의 경계에 서서 탐색을 계속했습니다.

AWS Glue - 스테로이드로 깔끔하게 패키지된 Apache Spark

AWS에는 "Hive/Pig/Spark" 스택의 자체 버전이 있는 것으로 나타났습니다. Hive의 역할, 즉 DataLake의 파일 및 해당 유형 카탈로그는 Apache Hive 형식과의 호환성을 숨기지 않는 "데이터 카탈로그" 서비스에 의해 수행됩니다. 파일의 위치와 형식에 대한 정보를 이 서비스에 추가해야 합니다. 데이터는 s3뿐만 아니라 데이터베이스에도 있을 수 있지만 이는 이 게시물의 주제가 아닙니다. DataLake 데이터 디렉터리가 구성되는 방식은 다음과 같습니다.

파일이 등록되었습니다. 훌륭합니다. 파일이 업데이트된 경우 수동으로 또는 일정에 따라 크롤러를 실행하면 레이크에서 파일에 대한 정보가 업데이트되고 저장됩니다. 그런 다음 호수의 데이터를 처리하고 결과를 어딘가에 업로드할 수 있습니다. 가장 간단한 경우에는 s3에도 업로드합니다. 데이터 처리는 어디에서나 수행할 수 있지만 AWS Glue API를 통해 고급 기능을 사용하여 Apache Spark 클러스터에서 처리를 구성하는 것이 좋습니다. 실제로 Hadoop의 내부를 파헤치고 docker-moker 컨테이너를 드래그하여 종속성 충돌을 제거하지 않고도 pyspark 라이브러리를 사용하여 오래되고 친숙한 Python 코드를 가져와 모니터링을 통해 일정 용량의 클러스터의 N 노드에서 실행을 구성할 수 있습니다. .

다시 한 번 간단한 아이디어입니다. Apache Spark를 구성할 필요가 없습니다. pyspark용 Python 코드를 작성하고 데스크톱에서 로컬로 테스트한 다음 클라우드의 대규모 클러스터에서 실행하고 소스 데이터의 위치와 결과를 저장할 위치를 지정하기만 하면 됩니다. 때로는 이것이 필요하고 유용하며, 설정 방법은 다음과 같습니다.

따라서 s3의 데이터를 사용하여 Spark 클러스터에서 무언가를 계산해야 하는 경우 python/pyspark에 코드를 작성하고 테스트한 후 클라우드에 행운이 있기를 바랍니다.

오케스트레이션은 어떻습니까? 과제가 떨어져서 사라진다면 어떨까요? 예, Apache Pig 스타일로 아름다운 파이프라인을 만드는 것이 제안되었고 우리는 그것을 시도하기도 했습니다. 하지만 지금은 PHP와 JavaScript에서 심층적으로 맞춤화된 오케스트레이션을 사용하기로 결정했습니다(인지 부조화가 있다는 것을 이해하지만 작동합니다. 년 및 오류 없음).

레이크에 저장되는 파일의 형식이 성능의 핵심

두 가지 핵심 사항을 더 이해하는 것이 매우 중요합니다. 레이크의 파일 데이터에 대한 쿼리가 가능한 한 빨리 실행되고 새로운 정보가 추가될 때 성능이 저하되지 않도록 하려면 다음을 수행해야 합니다.

• 파일의 열을 별도로 저장합니다(열의 내용을 이해하기 위해 모든 줄을 읽을 필요가 없도록). 이를 위해 우리는 압축을 통해 쪽모이 세공 마루 형식을 사용했습니다.
• 파일을 언어, 연도, 월, 일, 주와 같은 폴더로 분할하는 것이 매우 중요합니다. 이러한 유형의 샤딩을 이해하는 엔진은 모든 데이터를 연속적으로 조사하지 않고 필요한 폴더만 살펴봅니다.

기본적으로 이러한 방식으로 소스 데이터를 상단에 매달린 분석 엔진에 대해 가장 효율적인 형식으로 배치합니다. 분할된 폴더에서도 파일에서 필요한 열만 선택적으로 입력하고 읽을 수 있습니다. 어디에서나 데이터를 "채울" 필요가 없습니다(스토리지가 갑자기 터질 것입니다). 즉시 현명하게 올바른 형식으로 파일 시스템에 넣기만 하면 됩니다. 물론, 열을 추출하기 위해 먼저 클러스터에서 한 줄씩 읽어야 하는 대용량 csv 파일을 DataLake에 저장하는 것은 그리 바람직하지 않다는 점을 여기서 분명히 해야 합니다. 이 모든 일이 왜 일어나는지 아직 명확하지 않다면 위의 두 가지 사항을 다시 생각해 보십시오.

AWS Athena - 잭인더박스

그러다가 호수를 만들다가 우연히 Amazon Athena를 발견하게 되었습니다. 갑자기 대규모 로그 파일을 올바른(마루) 열 형식의 폴더 샤드에 조심스럽게 배열하면 매우 빠르게 해당 파일에서 유용한 정보를 선택하고 Apache Spark/Glue 클러스터 없이도 보고서를 작성할 수 있다는 사실이 밝혀졌습니다.

s3의 데이터로 구동되는 Athena 엔진은 전설적인 프레스토 악장 - s3 및 Hadoop에서 Cassandra 및 일반 텍스트 파일에 이르기까지 데이터가 있는 곳에서 데이터를 가져오는 데이터 처리에 대한 MPP(대규모 병렬 처리) 접근 방식 제품군을 대표합니다. Athena에게 SQL 쿼리 실행을 요청하기만 하면 모든 것이 "빠르고 자동으로 작동"합니다. Athena는 "스마트"하며, 필요한 샤딩 폴더로만 이동하고 요청에 필요한 열만 읽습니다.

Athena에 대한 요청 가격도 흥미롭습니다. 우리는 비용을 지불합니다 스캔 데이터의 양. 저것들. 분당 클러스터의 머신 수가 아니라... 100-500 머신에서 실제로 스캔된 데이터의 경우 요청을 완료하는 데 필요한 데이터만 있습니다.

그리고 올바르게 샤딩된 폴더에서 필요한 열만 요청함으로써 Athena 서비스 비용이 한 달에 수십 달러라는 사실이 밝혀졌습니다. 글쎄요, 클러스터 분석에 비해 거의 무료입니다!

그런데 s3에서 데이터를 샤딩하는 방법은 다음과 같습니다.

그 결과, 짧은 시간 내에 정보 보안부터 분석까지 회사의 완전히 다른 부서가 Athena에 적극적으로 요청하기 시작했고 몇 초, 몇 초, 몇 달, 반년 등 P.

하지만 우리는 더 나아가 클라우드에서 답변을 찾기 시작했습니다. ODBC 드라이버를 통해: 분석가는 친숙한 콘솔에 SQL 쿼리를 작성합니다. 이 쿼리는 100-500대의 머신에서 "3페니용"으로 데이터를 sXNUMX에 보내고 일반적으로 몇 초 안에 답변을 반환합니다. 편안한. 그리고 빠르다. 나는 아직도 그것을 믿을 수 없다.

결과적으로 데이터를 효율적인 열 형식과 폴더로의 합리적인 분할을 통해 s3에 저장하기로 결정하면서 우리는 DataLake와 빠르고 저렴한 분석 엔진을 무료로 받았습니다. 그리고 그는 회사에서 매우 인기가 많았습니다. 왜냐하면... SQL을 이해하고 클러스터 시작/중지/설정보다 훨씬 빠르게 작업합니다. "그리고 결과가 같다면 왜 더 많은 비용을 지불합니까?"

Athena에 대한 요청은 다음과 같습니다. 물론 원하는 경우 충분히 형성할 수 있습니다. 복잡하고 다중 페이지 SQL 쿼리, 그러나 우리는 단순한 그룹화로 제한하겠습니다. 몇 주 전에 웹 서버 로그에서 클라이언트의 응답 코드를 확인하고 오류가 없는지 확인해 보겠습니다.

조사 결과

길고 고통스러운 길은 말할 것도 없고 위험과 복잡성 수준, 지원 비용을 지속적으로 적절하게 평가하면서 우리는 속도와 소유 비용 모두에서 우리를 결코 만족시키지 않는 DataLake 및 분석을 위한 솔루션을 찾았습니다.

회사의 완전히 다른 부서의 요구에 맞게 효율적이고 빠르며 저렴하게 DataLake를 운영하는 것은 건축가로 일한 적이 없고 사각형에 사각형을 그리는 방법을 모르는 숙련된 개발자의 능력 내에 있는 것으로 나타났습니다. 화살표를 사용하고 Hadoop 생태계의 50개 용어를 알고 있습니다.

여행이 시작될 때 내 머리는 개방형 및 폐쇄형 소프트웨어의 수많은 야생 동물원과 후손에 대한 책임의 부담에 대한 이해로 갈라졌습니다. 간단한 도구(nagios/munin -> elastic/kibana -> Hadoop/Spark/s3...)에서 DataLake 구축을 시작하고 피드백을 수집하고 진행 중인 프로세스의 물리학을 깊이 이해하세요. 복잡하고 어두운 모든 것을 적과 경쟁자에게 제공하세요.

클라우드로 이동하고 싶지 않고 오픈 소스 프로젝트를 지원, 업데이트 및 패치하고 싶다면 Hadoop 및 Presto가 탑재된 저렴한 사무용 컴퓨터에서 로컬로 유사한 체계를 구축할 수 있습니다. 가장 중요한 것은 멈추지 않고 앞으로 나아가고, 계산하고, 간단하고 명확한 해결책을 찾는 것입니다. 그러면 모든 것이 확실히 잘 될 것입니다! 모두들 행운을 빌고 다시 만나요!

출처 : habr.com