1. 데이터 플랫폼을 구축하는 이유는 무엇인가요?
비즈니스가 잘 운영되고 있고 시스템이 안정적으로 운영되고 있습니다. 왜 엔터프라이즈 데이터 플랫폼을 구축해야 하나요?
이런 질문은 입으로 물어보지 말고 마음속으로만 생각해보세요. 기업이 일반적으로 어떤 상황에서 데이터 플랫폼을 구축하고 다양한 데이터를 재구성해야 하는지 직접적으로 답변해드리겠습니다.
비즈니스 관점에서:
1. 비즈니스 시스템이 너무 많고 서로의 데이터가 연결되어 있지 않습니다. 이 경우 분석가는 여러 시스템에서 데이터를 추출한 다음 분석하기 전에 데이터를 통합해야 할 수 있습니다. 한두 번은 참을 수 있지만 매일 하는 일은 참을 수 있습니까? 수동 통합의 높은 오류율을 어떻게 제어해야 할까요?
시스템 관점에서 보면:
2. 비즈니스 시스템은 큰 압박을 받고 있으며 안타깝게도 데이터 분석은 상대적으로 리소스 집약적인 작업입니다. 그러면 비즈니스 시스템에 대한 부담을 덜기 위해 데이터를 추출하고 독립된 서버를 사용하여 데이터 쿼리 및 분석 작업을 처리하는 것을 생각하는 것이 당연합니다.
3. 실적 문제 회사는 점점 더 커질 수 있고, 동일한 데이터도 점점 더 커질 것입니다. 이는 과거 데이터의 축적일 수도 있고 새로운 데이터 콘텐츠의 추가일 수도 있습니다. 원래 데이터 플랫폼이 더 많은 양의 데이터 처리를 감당할 수 없거나 효율성이 이미 매우 낮은 경우 빅데이터 처리를 재구축해야 합니다. 플랫폼.
위에서 세 가지 상황을 나열했지만, 두 가지, 심지어 세 가지 상황이 동시에 발생하는 경우가 많습니다. 데이터 플랫폼의 출현은 데이터 분석의 부담을 견딜 수 있을 뿐만 아니라 비즈니스 데이터를 통합하고, 데이터 처리 성능을 다양한 수준으로 향상시키며, 데이터 플랫폼을 기반으로 보다 풍부한 기능적 요구 사항을 실현할 수 있습니다.
2. 데이터 플랫폼 구축에 사용할 수 있는 옵션은 무엇입니까?
아래의 장점과 단점은 솔루션 자체의 기술적인 관점이 아닌 기업 선택의 관점에서 볼 수 있습니다.
한 문장으로 답하자면, 너무 많지만(말도 안되는 소리인 것은 인정합니다) 선택할 수 있는 옵션이 정말 많습니다. , 따라서 모두 다룰 수는 없으므로 다음과 같은 범주로 나누어져 있으며 대부분의 기업의 요구 사항을 어느 정도 충족한다고 생각합니다.
1. 기존 데이터웨어하우스:
데이터 분야에 종사하시는 분이라면 저보다 더 잘 아시리라 믿습니다. , Baidu로 이동할 수 있습니다. 데이터 통합에 중점을 두고 있으며 비즈니스 로직을 분류하는 역할도 합니다. 데이터 읽기 성능을 향상시키기 위해 SSA와 같은 큐브로 패키징할 수도 있지만, 데이터 웨어하우스의 역할은 단순한 성능 문제가 아닌 회사의 비즈니스 문제를 해결하는 데 더 가깝습니다. 이에 대해서는 나중에 자세히 소개하겠습니다.
이 솔루션의 장점과 단점에 대해 핵심 사항에 대해 직접 이야기해 보겠습니다.
장점:
아키텍처와 관련하여 솔루션이 성숙합니다. Inmon 아키텍처이든 Kimball Architectures이든 데이터 웨어하우스에는 매우 광범위한 응용 프로그램이 있으며 이 두 아키텍처를 구현할 수 있는 사람들이 많이 있다고 생각합니다.
구현은 간단하며 관련된 기술적 측면은 주로 웨어하우스 모델링 및 ETL 처리입니다. 많은 소프트웨어 회사는 데이터 웨어하우스를 구현하는 능력을 갖추고 있으며 구현의 어려움은 비즈니스 로직의 복잡성에 따라 달라집니다. 기술적 구현보다는.
이 문장은 시나리오에 부합해야 합니다. 필요한 경우 웨어하우스 모델과 ETL 로직을 변경 요구 사항에 맞게 수정할 수 있습니다. 물론 디자인 초기에는 신중하게 고려하는 것이 가장 좋습니다.) 동시에 상위 수준 분석을 위해 SQL 또는 MDX를 통한 웨어하우스 데이터 분석 및 처리는 유연성이 뛰어납니다.
단점:
"긴 구현 주기", 아래의 Agile 데이터 마트에 해당하는 따옴표를 추가했다는 점에 유의하세요. 이 점은 상대적이며 긴 구현 주기는 다음과 관련이 있습니다. 부족함은 주로 비즈니스 로직의 복잡성에 따라 달라지며, 기술적인 병목 현상이 아닌 비즈니스 로직을 정리하는 데 시간이 소요됩니다. 이 점은 나중에 자세히 소개하겠습니다.
이러한 제한도 상대적입니다. 대용량 데이터를 처리하는 데는 확실히 좋지 않고, 비관계형 데이터를 처리하는 데도 좋지 않습니다. (사용하는 데이터베이스 시스템에 따라 다릅니다.) 이 수준의 데이터, 그리고 상당수 기업의 데이터는 여전히 이 수준을 초과하기 어렵습니다.
2. 비즈니스 민첩한 데이터 마트:
기본 데이터 제품은 분석 계층에 바인딩되어 애플리케이션 계층이 데이터에 대한 드래그 앤 드롭 분석을 직접 수행할 수 있습니다. 기본 데이터 제품. 이러한 유형의 제품이 등장한 원래 의도는 비즈니스 데이터를 간단하고 빠르게 통합하고 민첩한 모델링을 달성하며 데이터 처리 속도를 크게 높이는 것입니다. 현재 이들 제품은 위의 목적을 달성했습니다. 그러나 장점과 단점도 분명합니다.
장점:
이러한 유형의 제품은 간단한 배포와 민첩한 개발이 가장 큰 장점이며, 데이터 웨어하우스에 비해 구현 주기가 훨씬 짧습니다. 실제로 이러한 유형의 제품은 분석해야 하는 데이터와 부분적인 상관 관계만 수행하고 해결해야 할 즉각적인 문제만 고려하며 더 강력한 반복 기능을 갖기 때문에 구현에 대한 엄격한 개념이 없습니다.
상위 분석 도구와 잘 통합되어 있으며, 상위 분석 도구가 이러한 데이터 제품에 연결되면 데이터의 그래픽 표시 및 Olap 분석을 직접 실현할 수 있습니다. 데이터 처리 성능을 향상시키기 위해 메모리 매핑 파일 스토리지, 분산 아키텍처, 컬럼 데이터 스토리지 등의 방식이 다르지만 모두 데이터 분석 성능을 다루고 있습니다. 하지만 데이터 처리 성능이 어느 정도 향상되었다는 점에는 의심의 여지가 없습니다.
단점:
우선 수수료가 필요합니다.
복잡한 비즈니스 로직을 처리할 수 없습니다. 이는 단지 도구일 뿐 비즈니스 문제를 해결할 수 없습니다. 이러한 유형의 도구에는 간단한 데이터 처리 및 통합을 달성하기 위한 간단한 etl 기능이 포함되어 있습니다. 그러나 과거 데이터와 전체 데이터 간의 논리 및 관계를 고려하면 확실히 해결할 수 없습니다. 간단한 예를 들어, 특정 테이블에 두 개의 필드가 있는 경우 하나는 기록 데이터를 유지해야 하고 다른 하나는 기록 데이터를 업데이트해야 하며 자동 처리를 구현하는 방법입니다. 명확해야 할 한 가지 개념이 있습니다. 비즈니스 문제를 해결하기 위해 하나의 도구에만 의존할 수는 없습니다. 이런 종류의 데이터 제품은 단순히 현재 비즈니스 데이터를 통합한 것에 불과합니다. 첫째, 데이터가 부분적이며, 둘째, 시간이 현재적입니다(수반되는 증분 업데이트 또는 전체 업데이트는 복잡한 논리에 대처할 수 없습니다. , etl은 이 프로세스가 얼마나 복잡한지 알고 있습니다.) 물론 일부 기업의 경우 현재 비즈니스 데이터에 대한 통합 분석만 필요한 경우도 있으므로 이 유형의 제품이면 충분합니다. (솔직히 많은 기업은 너무 게으른 나머지 장기적으로 생각하지 않습니다. 언젠가는 그런 일이 일어날지 누가 장담할 수 있을까요?)
l 낮은 유연성은 피할 수 없습니다. 작업이 단순할수록 도구의 유연성은 캡슐화되어 있고 제품이 불투명하기 때문에 일반 요구 사항에 사용하기 매우 편리합니다. 그러나 복잡한 도구를 접하면 그 내용을 이해하지 못한다는 것을 알게 됩니다. 내부는 수정할 수 없으며 계란만 사용할 수 있습니다.
내 관점에서는 기업의 데이터센터가 되기 어렵다.
3. MPP(대량 병렬 처리) 아키텍처 데이터 제품, 최근 오픈 소스인 그린플럼을 예로 들어보겠습니다.
기존 호스트 컴퓨팅 모델은 대용량 데이터에 취약합니다. 비용이 매우 비싸고 기술적으로 고성능 컴퓨팅을 충족할 수 없습니다. SMP 아키텍처는 확장이 어렵고, 독립 호스트의 CPU 컴퓨팅이나 IO 처리량 모두 대규모 데이터 컴퓨팅의 요구를 충족할 수 없습니다. 분산 스토리지와 분산 컴퓨팅은 이 문제를 해결하는 핵심입니다. 후속 MapReduce 컴퓨팅 프레임워크와 MPP 컴퓨팅 프레임워크는 모두 이러한 배경에서 제작되었습니다.
Greenplum의 데이터베이스 엔진은 postgresql을 기반으로 하며 Interconnnect 아티팩트를 통해 동일한 클러스터에 있는 여러 Postgresql 인스턴스의 효율적인 협업 및 병렬 컴퓨팅을 실현합니다.
동시에 Greenplum 기반의 데이터 플랫폼 구축은 두 가지 수준의 처리를 달성할 수 있습니다. 분명한 것은 Greenplum의 백과사전이 주장하는 처리 성능은 50PB 수준의 처리를 지원한다는 것입니다. 대용량 데이터 자랑하는 요소가 있는데, 현재 그린플럼의 실제 적용에 대한 이해를 바탕으로 보면 100테라바이트 정도의 데이터를 매우 쉽게 얻을 수 있다. 다른 하나는 Greenplum에 데이터 웨어하우스를 구축할 수 있다는 점입니다. 이 수준에서는 비즈니스 로직도 정리되고 회사의 비즈니스 데이터가 통합됩니다.
장점:
대량의 데이터와 다수의 성숙한 적용 사례를 지원하므로 이에 대해서는 의심의 여지가 없다고 생각합니다.
확장성은 10,000개 노드까지 선형적으로 확장할 수 있으며, 노드가 추가될 때마다 쿼리 및 로딩 성능이 선형적으로 증가한다고 합니다.
사용하기 쉽고 복잡한 튜닝 요구 사항이 필요하지 않으며 병렬 처리가 시스템에 의해 자동으로 완료됩니다. SQL은 여전히 단순하고 유연하며 강력한 통신 언어로 사용됩니다.
고급 기능인 greenplum은 널리 사용되는 외부 테이블, 기본/미러 미러 보호 메커니즘, 행/열 혼합 스토리지 등과 같은 많은 고급 데이터 분석 및 관리 기능도 개발했습니다.
안정성, 그린플럼은 원래 오랜 역사를 지닌 순수 상용 데이터 제품으로, 다른 제품이나 애자일 데이터 마트보다 안정성이 보장됩니다. Greenplum은 많은 적용 사례를 보유하고 있으며 나스닥, 뉴욕 증권 거래소, Ping An Bank, 중국 건설 은행, Huawei 등은 모두 greenplum을 기반으로 한 데이터 분석 플랫폼을 구축했습니다. 2015년 9월 오픈소스화 이후 주요 인터넷 기업들도 크게 기뻐하고 있으며, 현재는 그린플럼을 사용하고 있는 여러 고객들에게 호평을 받고 있다.
단점:
그 자체로는 Olap 분야에 위치하며 OLTP 거래 시스템에는 좋지 않습니다. 물론, 우리 회사에 구축하는 데이터 센터는 거래 시스템에 사용되지 않습니다.
비용, 두 가지 고려 사항이 있습니다. 하나는 하드웨어 비용입니다. Greenplum에는 메모리 및 네트워크 카드에 대한 요구 사항이 있는 권장 하드웨어 사양이 있습니다. 물론 하드웨어를 선택할 때 균형이 이루어져야 하며, 결국 성능, 용량, 비용 등 여러 측면을 고려해야 합니다. 다른 하나는 구현 비용으로, 주로 인력이 필요합니다. greenplum의 기본 설치 및 구성과 greenplum의 데이터 웨어하우스 구축에는 모두 인력과 시간이 필요합니다. (하지만 남의 소프트웨어는 오픈소스라 비용도 많이 절약된다고 해야 할까요)
이전의 애자일 데이터 마트에 비하면 기술적인 기준점은 확실히 조금 더 높습니다. .
4. Hadoop 분산 시스템 아키텍처
Hadoop은 이미 큰 인기를 누리고 있으며 greenplum의 오픈 소스는 그것과 분리될 수 없습니다. 높은 신뢰성, 높은 확장성, 고효율 및 높은 내결함성이라는 평판을 얻고 있습니다. Yahoo, Facebook, Baidu, Taobao 등 인터넷 분야에서 널리 사용됩니다. hadoop 생태계는 매우 규모가 크며 기업이 hadoop을 기반으로 구현하는 것은 데이터 분석에 국한되지 않고 기계 학습, 데이터 마이닝, 실시간 시스템 등을 포함합니다.
기업 데이터의 규모가 일정 수준에 도달하면 대기업이 선호하는 솔루션은 하둡이 될 것이라고 생각한다. 이 수준에 도달하면 기업은 성능 문제뿐만 아니라, 또한 적시성 문제, 보다 복잡한 분석 및 마이닝 기능 구현 등 매우 일반적인 실시간 컴퓨팅 시스템도 Hadoop 생태계와 밀접한 관련이 있습니다.
최근에는 hadoop의 사용 편의성도 크게 향상되었으며, hive, impala, Spark-sql 등을 포함하여 sql-on-hadoop 기술이 대거 등장했습니다.
처리 방법은 다르지만 원본 파일 기반 Mapreduce에 비해 성능과 사용 편의성이 전반적으로 향상되었습니다. 이는 또한 MPP 제품 시장에 압력을 가하고 있습니다.
기업이 데이터 플랫폼을 구축하는 데 있어 Hadoop의 장점과 단점은 매우 분명합니다. 빅 데이터 처리 기능, 높은 신뢰성, 높은 내결함성, 오픈 소스 및 저렴한 비용(왜 저비용이라고 합니까? 동일한 크기의 데이터를 처리하려면 다른 해결 방법을 시도해 보세요.) 단점은 시스템이 복잡하고 기술적 한계가 상대적으로 높다는 점이다(하둡을 다룰 수 있는 기업은 일반적으로 규모가 꽤 크다).
Hadoop의 장점과 단점은 회사의 데이터 플랫폼 선택에 거의 영향을 미치지 않습니다. hadoop을 사용해야 할 때 다른 옵션은 없습니다(너무 비싸거나 실행 가능하지 않음). 데이터의 양이 이 수준에 도달하지 않으면 아무도 이것을 건드리려고 하지 않습니다. 즉, 빅데이터를 위해 빅데이터를 수행하지 마십시오.
3. 선택지가 많은데 기업은 어떻게 선택하는가?
환경이 너무 복잡하지만 최소한 다음과 같은 측면은 고려해야 한다고 생각합니다.
1. 목적:
글 시작 부분에 있는 세 가지 상황은 무엇입니까? (죄송합니다. 다른 상황도 있을 텐데요. 환영합니다." Jiago Wang" ” 보충) 또는 이들 중 여러 가지를 조합한 것입니다.
대낮에 밥 먹으러 나가더라도 목적을 염두에 두어야 한다. 이 식사는 포만감을 위한 것인지, 아니면 남에게 아첨을 위한 것인지. 당신은 무엇을 먹을지 선택합니다.
물론, 데이터 플랫폼을 구축하는 목적을 명확히 하는 것은 쉽지 않습니다. 논의를 거쳐 확정된 목표와 원래 의도가 일치하지 않을 수도 있습니다.
데이터 플랫폼을 구축하려는 회사의 원래 의도는 매우 간단할 수 있습니다. 단지 비즈니스 시스템에 대한 부담을 줄이고 분석을 위해 데이터를 꺼내는 것입니다. 정말 전쟁에 나갈 필요가 없습니다. 독립된 시스템이라면 비즈니스 시스템의 데이터베이스를 복사하면 되고, 여러 시스템이라면 Finecube 같은 Agile 비즈니스 데이터 제품을 선택하면 됩니다. 시각화 및 Olap 분석이 가능합니다.
그렇다면 데이터 플랫폼을 독립화하기로 했으니, 현재는 여러 시스템의 데이터를 정리하고 통합하는 기회를 좀 더 생각해 보는 것은 어떨까요? , 우리는 비즈니스 데이터만 분석하면 됩니다. 앞으로는 과거 데이터가 고려되지 않을 것입니다. 이 민첩한 솔루션이 내년과 그 다음 해의 요구 사항을 지원할 수 있습니까?
데이터 구축 플랫폼은 어느 회사에게나 사소한 문제가 아니며 구현하는 데 한두 달이 더 걸릴 수 있습니다. 피곤함을 느낄 수도 있으니 한두 주 정도 더 시간을 들여 진지하게 생각해도 괜찮습니다. Lei Jun이 이렇게 말하지 않았나요? 전략적 게으름을 은폐하기 위해 전술적 근면을 사용할 수는 없습니다.
2. 데이터 양:
회사의 데이터 크기에 따라 적절한 솔루션을 선택하세요.
3. 비용:
물론 시간 비용과 돈도 포함됩니다. 하지만 여기서 언급하고 싶은 질문이 있는데, 많은 기업이 데이터 플랫폼을 사용하지 않고, 일단 그러한 계획이 있으면 플랫폼을 구축하고 즉시 사용하려고 하지 않는다는 것을 알았습니다. 이러한 상황에서는 고려가 부족하기 쉬우며 데이터 구현 당사자에게도 속기 쉽습니다.
솔루션 선택에 대한 제안을 위해 다음 3가지 시나리오가 제공됩니다.
시나리오 a:
비즈니스 데이터의 신속한 추출 및 분석을 달성하기 위해 여러 비즈니스 시스템 대용량 데이터가 없고, 과거 데이터를 고려하지 않으며, 비즈니스 로직에 따라 데이터를 체계적으로 분류할 필요가 없는 경우 Agile bi 도구와 함께 제공되는 데이터 하위 레이어를 고려할 수 있습니다.
간단히 말하면 이 시나리오는 기술 수준의 데이터를 통합하고 속도를 높이는 것일 뿐 비즈니스 수준의 데이터를 모델링하지는 않습니다. 특정 분석 요구 사항을 충족할 수 있지만 회사의 데이터 센터가 될 수는 없습니다.
시나리오 b:
다양한 시스템 간 데이터를 연결하기 위해 기업 차원의 데이터센터 구축이 필요하다. 데이터 웨어하우스를 구축해야 한다는 것은 매우 분명합니다. 이때 기업 데이터의 규모를 더 고려해야 합니다. 데이터의 양이 TB 수준 이하인 경우에는 기존 데이터베이스에 이러한 데이터 웨어하우스를 구축하는 것으로 충분합니다. 또는 수백 TB에 달하거나 가시화될 수 있습니다. 앞으로 몇 년 안에 데이터는 Greenplum에 창고를 지을 수 있을 만큼 규모에 도달할 것입니다.
이 시나리오는 대부분의 회사에 적용 가능합니다. 대부분의 회사에서 데이터 양은 PB 수준이 아니지만 TB 수준보다 낮은 경우가 많습니다.
시나리오 c:
회사의 데이터가 폭발적으로 증가하고 있고, 기존 데이터 플랫폼으로는 대용량 데이터를 처리할 수 없으므로 Hadoop과 같은 빅데이터 플랫폼을 고려하는 것이 좋습니다. 그러한 역할을 위해서는 회사의 데이터센터가 반드시 필요하며, 원래의 창고를 하이브(hive)로 직접 이동할 수 있습니다. 상대적으로 많은 양의 데이터로 이 상황을 표현하는 방법은 무엇입니까? hive의 성능이 낮기 때문에 impala 또는 greenplum에 임시 쿼리를 연결할 수 있습니다. 왜냐하면 impala의 동시성이 그다지 높지 않고 greenplum에 외부 테이블이 있기 때문입니다. , greenplum은 테이블을 생성합니다. 테이블의 기능을 외부 테이블이라고 하며 읽은 내용은 Hadoop의 하이브에 있습니다. 이는 Hadoop과 완벽하게 통합됩니다(물론 외부 테이블은 필요하지 않습니다).
시나리오 d:
이것은 나중에 추가됩니다. 회사에 원래 데이터 웨어하우스가 있지만 과거 데이터가 너무 많이 축적되어 분석 성능이 저하되면 어떻게 해야 할까요? 옵션 장기적으로 웨어하우스와 데이터를 greenplum으로 마이그레이션하여 더 많은 가능성을 창출할 수 있는 독립적인 데이터 플랫폼인 새로운 데이터 플랫폼을 형성할 수 있으며, Finecube와 같은 민첩한 데이터가 될 수 있다고 생각됩니다. 데이터 처리 성능을 향상하고 분석 요구 사항을 충족하기 위해 원래 창고에 연결됩니다.
4. 솔루션 선택 시 발생할 수 있는 오해
(비즈니스의 복잡성을 무시하고 도구를 사용하여 이를 해결하거나 비즈니스 로직을 우회합니다.)
최근 제가 접한 상황은 고객이 보고 플랫폼을 구축하고 싶어했고 세 가지 비즈니스 시스템의 데이터를 통합해야 했습니다. 하지만 저는 사업을 통해 수익을 창출하고 싶었고 전통적인 데이터 웨어하우스를 구축하고 싶지 않았기 때문에 Agile Bi 도구를 선택했습니다. 데이터 제품에 대한 도구 제조업체의 설명은 일반적으로 신속한 구현, 성능 최적화 및 기본 ETL 기능에 중점을 둡니다. 이는 고객의 오해를 불러일으킬 수 있습니다. 본 제품은 최상위 데이터 요구 사항을 충족하기 위해 기업 수준의 데이터 센터를 신속하게 구축할 수 있습니다.
그러나 나중에 이 도구가 해결한 것은 기술적인 수준에서 도구 사용의 복잡성을 단순화하고 ETL과 데이터 마트를 캡슐화하며 데이터 성능을 향상시키는 것임을 문득 깨달았습니다. 그러나 데이터 모델링은 비즈니스 수준에서 구현되지 않으며 세부적인 문제를 처리할 수 없는 경우가 많습니다.
애자일 개발은 매우 유혹적이지만 비즈니스 시스템이 단순하거나 비즈니스 데이터의 현재 상태만 분석하면 되고 회사 수준의 데이터 센터가 필요하지 않다면 실제로는 매우 어렵습니다. 좋은 해결책. 그러나 이러한 문제는 명확하게 고려되지 않았으며 Agile 제품에 대한 기대가 너무 높으면 나중에 몇 가지 문제에 직면하게 됩니다.
또 빅데이터를 위해 빅데이터를 활용하는 분들도 계시겠지만, 실제 업무에서는 이런 분들을 접해본 적이 없습니다.
마지막으로, 기업이 데이터 플랫폼 솔루션을 선택하는 이유는 다양합니다. 합리적인 선택을 위해서는 데이터 플랫폼 구축 목적을 충분히 고려할 뿐만 아니라 완전한 이해가 필요합니다. 다양한 솔루션의 .
개인적인 관점에서 볼 때 저는 데이터 센터가 회사에 너무 중요하고 스스로 완전히 제어할 수 있는 투명성을 선호하기 때문에 여전히 데이터 수준에서 매우 유연한 솔루션을 선호합니다. , 데이터 센터를 최대한 활용할 수 있도록 합니다. 앞으로 어떤 역할을 해야 할지 모르기 때문이다.
도움이 되길 바라며 채택하시길 바랍니다