중국 1위 쇼핑몰 타오바오 (Taobao) 프레임워크 분석자료

알리바바가 운영중인 쇼핑몰은 여러가지가 있다. 그 중 중국에서 가장 유명한 사이트는 타오바오(taobao.com) 이라고 할 수 있다.

타오바오는 C2C 기반으로 가짜 물건을 올리는 사람이 많아서 문제가 되기도 하지만 여전히 많은 중국인들이 사용하고 있다.

(가짜 문제로 tmall.com이라는 알리바바의 B2C 사이트도 타오바오와 연결이 되어 있기도 하다.)

어쨌든 쌍십절이라고 하는 중국 국경일에는 타오바오의 트래픽이 어마어마하게 늘어난다. 미국의 블랙 프라이데이는 비교할 수도 없을

만큼 수많은 사람들이 쇼핑몰을 이용하고 수량의 제한 때문에 다들 장바구니에 상품들을 담아뒀다가 12시 땡하자 마자 결제를 하기

때문에 대용량 시스템에 관심이 많은 사람들이나 중국에서 크게(?) 사업을 해보고 싶은 사람은 관심을 가질 수 밖에 없다.

그래서 중국의 구글이라고 할 수 있는 바이두에서 타오바오에서 어떻게 쌍십절을 대비하여 대용량 데이터 처리를 준비하는지

찾아봤다. 번역기를 돌린거라 내용이 매끄럽진 않지만 이해는 할 수 있을 정도이다.

Taobao의는 "더블 11"기술 프레임 워크 분석 처리합니다

作者: TJ发布时间: 2013-11-20 18:10 阅读: 24881 次 推荐: 164 原文链接 [收藏] 저자 : TJ는 발행일 : 2013년 11월 20일 18시 10분 읽기 : 24881 번 추천 : 164 설명 링크 [즐겨 찾기]

双“11”最热门的话题是TB ，最近正好和阿里的一个朋友聊淘宝的技术架构，发现很多有意思的地方，分享一下他们的解析资料： 더블 "11"가장 인기있는 주제는 흥미로운 장소를 많이 찾을 자신의 분석 데이터를 공유, 최근 알리 Taobao의 기술 아키텍처의 친구와 이야기 TB입니다 :

淘宝海量数据产品技术架构 Taobao의 대용량 데이터 기술 아키텍처

数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。 제품의 가장 중요한 특징은 비 실시간 데이터는 데이터를 기록하고, 이에 따라 일정 시간에, 시스템 전체의 데이터를 읽기 전용으로 말할 수있다. 这为我们设计缓存奠定了非常重要的基础。 이것은 우리의 디자인 캐시 매우 중요한 토대를 마련했다.

图1 淘宝海量数据产品技术架构 그림 1 Taobao의 대용량 데이터 기술 아키텍처

按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图1所示），分别是数据源、计算层、存储层、查询层和产品层。 분할하는 데이터의 흐름에 따라, 우리는 오 (도 1)에 기술 아키텍처 Taobao의 데이터 제품을 가지고, 각각의 데이터 소스, 연산 층, 기록 층, 쿼리 층과 생성물의 층. 位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。 우리의 데이터 아키텍처의 상단에 사용자, 상점, 상품 및 무역 Taobao의 마스터와 다른 데이터베이스뿐만 아니라 사용자 찾아보기, 검색 및 다른 행동 기록이있다, 소스 레이어입니다. 这一系列的数据是数据产品最原始的生命力所在。 데이터의이 시리즈는 가장 원시적 인 데이터 제품의 활력이다.

在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。 하둡 클러스터 노드 (1500)로 실시간 전송 근처 Taobao의 자체 개발 한 데이터 전송 컴포넌트 DATAX, DbSync 및 Timetunnel 통해 실시간으로 생성되는 데이터 소스 층, 우리는 "사다리"호출 클러스터의 층을 산출한다 주요 구성 요소입니다. 在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。 "사다리", 우리는 매일에게 맵리 듀스 다른 제품 요구 사항에 따라 계산 원시 데이터의 1.5PB 약 40,000 작업을해야합니다. 这一计算过程通常都能在凌晨两点之前完成。 이 계산은 보통 2시 전에 완료 할 수있다. 相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。 데이터를 볼 프런트 엔드 제품에 대해, 여기에 결과 데이터 중복성 및 적절히 균형 수행 결과 프런트 엔드 컴퓨팅 사이 종종 중간 결과의 상태에있을 가능성이 높다.

不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。 I는 검색어에 대한 통계 데이터로서, 요구의 효과에 대한 일부 데이터가, 우리는 데이터 자마자 제품 전면에 푸시 할 것인지 언급한다. 这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。 이러한 요구는 상대적으로 낮을 것이다 효율을 계산하는 "사다리"라고 우리는 데이터 컴퓨팅 플랫폼, 스트리밍 실시간 함 "은하수." “银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。 「은하는 "TimeTunnel 실시간으로 메시지를 수신하고, 메모리에 리얼 타임 계산을 수행하고, 최단 시간에 결과를 호출 프런트 엔드 제품 NoSQL의 저장 장치를 갱신하는 분산 시스템이다.

容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。 "래더"또는 "갤럭시"를 이해하기 쉬운 제품으로 직접 실시간 데이터 질의 서비스를 제공하기에 적합하지 않다. 这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。 "사다리"를, 그것은 단지 높은 성능과 동시성 요구 사항을 지원하지 않는 계산에 위치해있어, 때문이고, "갤럭시"에 대한, 우리의 손에 비록 모든 코드,하지만 계층화를 피할 수없는 분산 시스템에 통합 된 실시간 컴퓨팅, 스토리지 및 쿼리 기능에서 수신 한 데이터를 완료 끝은 여전히​​ 현재의 구조에 떨어졌다.

为此，我们针对前端产品设计了专门的存储层。 이를 위해, 기록 층을 위해 특별히 설계된 프런트 엔드 제품에 초점을 맞추었다. 在这一层，我们有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点介绍这两个集群的实现原理。 이 수준에서, 우리는 텍스트의 뒤에, 나는 MySQL의 두 클러스터를 기반으로이 원칙의 실현에 초점을 맞출 것이다, 관계형 데이터베이스 클러스터 MyFOX 기반 HBase를, NoSQL에 저장 클러스터 댄스 파티를 배포. 除此之外，其他第三方的模块也被我们纳入存储层的范畴。 또한, 타사의 모듈은 또한 우리의 기록 층의 범위에 포함된다.

存储层异构模块的增多，对前端产品的使用带来了挑战。 이기종 스토리지 계층 모듈 증가 과제 프런트 엔드 제품의 용도. 为此，我们设计了通用的数据中间层——glider——来屏蔽这个影响。 이를 위해, 우리는이 효과를 보호하기 위해 --glider-- 공통 데이터 중간층을 설계했다. glider以HTTP协议对外提供restful方式的接口。 글라이더 HTTP 프로토콜은 외부 인터페이스에게 편안한 방법을 제공합니다. 数据产品可以通过一个唯一的URL获取到它想要的数据。 고유 한 URL을 통해 제품 데이터는 원하는 데이터를 취득했다.

以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍，接下来我将重点从四个方面阐述数据魔方设计上的特点。 이러한 일반의 대용량 데이터 제품 Taobao의 기술 아키텍처의 도입, 그리고 그때는 데이터 큐브 디자인의 특징을 네 가지 측면에 초점을 맞출 것이다.

关系型数据库仍然是王道 관계형 데이터베이스는 여전히 왕

关系型数据库（RDBMS）自20世纪70年代提出以来，在工业生产中得到了广泛的使用。 산업 생산에서, 1970 년대 이후 관계형 데이터베이스 (RDBMS)는 널리 사용되어왔다. 经过三十多年的长足发展，诞生了一批优秀的数据库软件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。 급속한 발전의 삼십년 후, 오라클, MySQL은, DB2, 사이베이스 및 SQL Server와 같은 우수한 데이터베이스 소프트웨어의 숫자의 탄생.

图2 MyFOX中的数据增长曲线 그림 2 MyFOX의 데이터 성장 곡선

尽管相对于非关系型数据库而言，关系型数据库在分区容忍性（Tolerance to Network Partitions）方面存在劣势，但由于它强大的语义表达能力以及数据之间的关系表达能力，在数据产品中仍然占据着不可替代的作用。 비 관계형 데이터베이스를 기준에도 불구하고, 관계형 데이터베이스는 단점 파티션 허용 오차 (네트워크 파티션에 대한 내성) 측면을 존재하지만, 때문에 데이터 제품의 강력한 기능의 표현과 의미 론적 데이터 사이의 관계를 여전히 점유 대체 할 수없는 역할.

淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。 기본 데이터 스토리지 엔진으로 Taobao의 데이터 제품 선택의 MySQL의 MyISAM의 엔진. 在此基础上，为了应对海量数据，我们设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。 이를 기초로, 대량의 데이터를 처리하기 위해, 우리는 분산 질의 프록시 층 디자인 --MyFOX MySQL 클러스터, 프론트 - 엔드 애플리케이션에 대해 투명하게 파티션.

图3 MyFOX的数据查询过程 그림 3 MyFOX 데이터 쿼리 프로세스

目前，存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上，并且正在以每天超过6亿的增量增长着（如图2所示）。 현재 MyFOX에 저장된 데이터의 통계, 10TB 도달 데이터의 총량 데이터 큐브의 95 % 이상을 점유하고 상당히 일일 증분 증가 (도 2)의 이상 600,000,000로 성장하고있다. 这些数据被我们近似均匀地分布到20个MySQL节点上，在查询时，经由MyFOX透明地对外服务（如图3所示）。 이러한 데이터는 약 고르게 MyFOX 투명 외부 서비스 (그림 3 참조)를 통해 쿼리에 20 MySQL의 노드에서 우리에게 배포됩니다.

图4 MyFOX节点结构 MyFOX 4 노드 구조 다이어그램

值得一提的是，在MyFOX现有的20个节点中，并不是所有节点都是“平等”的。 또한, 노드가 모든 "동일"없는 20 노드를 기존 MyFOX에, 그 언급 할 가치가있다. 一般而言，数据产品的用户更多地只关心“最近几天”的数据，越早的数据，越容易被冷落。 단지 더 많은 관심을 일반 사용자 데이터 제품에서 "최근에,"데이터, 이전 데이터, 가능성은 생략 할 수 있습니다. 为此，出于硬件成本考虑，我们在这20个节点中分出了“热节点”和“冷节点”（如图4所示）。 이를 위해, 하드웨어 비용 고려를 위해, 우리는 "핫​​ 노드"및 노드 (20)에서 "콜드 접합부"(도 4)를 분리 하였다.

顾名思义，“热节点”存放最新的、被访问频率较高的数据。 이름에서 알 수 있듯이, 현재까지 높은 주파수 데이터를 저장하는 "핫 노드는"액세스 할 수 있습니다. 对于这部分数据，我们希望能给用户提供尽可能快的查询速度，所以在硬盘方面，我们选择了每分钟15000转的SAS硬盘，按照一个节点两台机器来计算，单位数据的存储成本约为4.5W/TB。 데이터의이 부분에 대해 저장된 데이터의 단위 비용을 계산하기 위해 노드에 두 기계에있어서, 우리는 가능한 신속하게 사용자에게 질의 속도를 제공하기 희망 때문에 하드 드라이브, 우리는 15,000 RPM SAS 하드 드라이브를 선택한 4.5W / TB. 相对应地，“冷数据”我们选择了每分钟7500转的SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。 이에 대응하여, "콜드 데이터는"우리는 1.6W / 결핵에 대한 자세한 데이터 스토리지 비용을 저장할 수있는 7500 RPM SATA 하드 드라이브 플래터를 선택했다.

将冷热数据进行分离的另外一个好处是可以有效提高内存磁盘比。 냉온수 데이터를 분리하는 또 다른 이점은 효과적으로 메모리 디스크 비율을 향상시킬 수있다. 从图4可以看出，“热节点”上单机只有24GB内存，而磁盘装满大约有1.8TB（300 * 12 * 0.5 / 1024），内存磁盘比约为4:300，远远低于MySQL服务器的一个合理值。 300까지 MySQL 서버 아래 그림 4에서 알 수있는 바와 같이, "핫 노드는"약 4의 1.8TB에 대한 (300 * 12 * 0.5 / 1024), 메모리, 디스크 비율 가득 전용 메모리의 24기가바이트 및 디스크 독립형 합리적인 값. 内存磁盘比过低导致的后果是，总有一天，即使所有内存用完也存不下数据的索引了——这个时候，大量的查询请求都需要从磁盘中读取索引，效率大打折扣。 그 결과보다 낮은 메모리 디스크는, 어느 날, 메모리 부족 모든 실행은 또한 어떤 인덱스 데이터 저장해도 - 그리고, 쿼리 많은 수의 디스크에서 인덱스를 읽는 데 필요한이 시간, 효율이 크게 감소.

NoSQL是SQL的有益补充 NoSQL에는 SQL에 대한 유용한 보완

在MyFOX出现之后，一切都看起来那么完美，开发人员甚至不会意识到MyFOX的存在，一条不用任何特殊修饰的SQL语句就可以满足需求。 MyFOX 표시 한 후, 모든 개발자는 심지어 SQL 문의 요구를 충족하기 위해 특별한 수정없이 MyFOX, 하나의 존재를 인식하지 않습니다, 너무 완벽 보인다. 这个状态持续了很长一段时间，直到有一天，我们碰到了传统的关系型数据库无法解决的问题——全属性选择器（如图5所示）。 전체 속성 선택기 (도 5) -이 상태는 어느 날, 우리는 전통적인 관계형 데이터베이스는 문제를 해결할 수없는 만족 장시간 계속된다.

图5 全属性选择器 5 완전 속성 선택자

这是一个非常典型的例子。 이것은 매우 전형적인 예이다. 为了说明问题，我们仍然以关系型数据库的思路来描述。 문제를 설명하기 위해, 우리는 여전히 관계형 데이터베이스를 설명하는 생각. 对于笔记本电脑这个类目，用户某一次查询所选择的过滤条件可能包括“笔记本尺寸”、“笔记本定位”、“硬盘容量”等一系列属性（字段），并且在每个可能用在过滤条件的属性上，属性值的分布是极不均匀的。 이 카테고리 필터 노트북의 경우, 사용자는 필터 조건의 "노트북 크기"및 "노트북 위치", "하드 드라이브 용량"및 특성 (필드)의 시리즈 및 모든 가능한 사용을 포함하는 쿼리를 선택할 수있다 재산에, 속성 값의 분포는 매우 고르지입니다. 在图5中我们可以看到，笔记本电脑的尺寸这一属性有着10个枚举值，而“蓝牙功能”这个属性值是个布尔值，数据的筛选性非常差。 그림 5에서 우리가이 속성은 10 열거 값이 노트북 및 "블루투스"이 속성 값의 크기가 부울 값입니다 볼 수있는 데이터의 선택은 매우 좋지 않습니다.

在用户所选择的过滤条件不确定的情况下，解决全属性问题的思路有两个：一个是穷举所有可能的过滤条件组合，在“云梯”上进行预先计算，存入数据库供查询；另一个是存储原始数据，在用户查询时根据过滤条件筛选出相应的记录进行现场计算。 불확실한 사용자에 의해 선택된 필터 기준의 경우, 전체의 속성의 문제를 해결하는 아이디어는 두 가지있다 :, 다른 하나는 미리 계산 된 쿼리에 대해 데이터베이스에 저장된에 "사다리"의 필터 조건들의 모든 가능한 조합들의 소모적 인 하나는 원시 데이터를 저장할 수 있으며, 사용자의 질의는 필터 기준 필드 계산에 기초하여 대응하는 레코드를 필터링. 很明显，由于过滤条件的排列组合几乎是无法穷举的，第一种方案在现实中是不可取的；而第二种方案中，原始数据存储在什么地方？ 두 번째 시나리오 동안, 원래의 데이터가 어디에 저장되어 필터 조건의 순열 및 조합을 총망라하는 것은 거의 불가능하기 때문에 당연히, 첫 번째 옵션은 실제로 바람직하지 않다? 如果仍然用关系型数据库，那么你打算怎样为这个表建立索引？ 당신은 여전히​​ 관계형 데이터베이스를 사용하는 경우, 당신은 어떻게 테이블에 대한 인덱스를 구축하는 건가요?

这一系列问题把我们引到了“创建定制化的存储、现场计算并提供查询服务的引擎”的思路上来，这就是Prometheus（如图6所示）。 질문이 시리즈는 우리를 인도 "사용자 정의 저장소를 만들고, 현장 컨설팅 서비스를 제공하는 컴퓨팅 엔진,"아이디어는 그 프로 메테우스 (그림 6)의 최대했다.

图6 Prom的存储结构 도의 저장 구조. 6 댄스 파티

从图6可以看出，我们选择了HBase作为Prom的底层存储引擎。 도 6에서 알 수있는 바와 같이, 우리는 댄스 파티 HBase를 기본 스토리지 엔진으로 선택했다. 之所以选择HBase，主要是因为它是建立在HDFS之上的，并且对于MapReduce有良好的编程接口。 HBase를 그것이 좋은 프로그래밍 인터페이스에 대한 HDFS와 맵리 듀스의 상단에 내장되어 주로하기 때문에 선택했다. 尽管Prom是一个通用的、解决共性问题的服务框架，但在这里，我们仍然以全属性选择为例，来说明Prom的工作原理。 비록 댄스 파티는 서비스의 일반적인 문제를 해결하기위한 일반적인 프레임 워크이지만, 여기에 우리가 댄스 파티 작동 설명하기 위해 예를 들어 전체 속성 선택에서 아직도. 这里的原始数据是前一天在淘宝上的交易明细，在HBase集群中，我们以属性对（属性与属性值的组合）作为row-key进行存储。 HBase를 클러스터의 Taobao의에 거래 내역, 우리는 행 키 저장소로 (속성의 조합과 속성 값) 속성 전에 여기에 원시 데이터는 날. 而row-key对应的值，我们设计了两个column-family，即存放交易ID列表的index字段和原始交易明细的data字段。 행 키에 대응하는 값, 우리는 즉, 데이터를 저장하는 필드 트랜잭션 ID 목록 인덱스 필드와 거래의 원본 목록에 두 개의 열 가족을 설계했습니다. 在存储的时候，我们有意识地让每个字段中的每一个元素都是定长的，这是为了支持通过偏移量快速地找到相应记录，避免复杂的查找算法和磁盘的大量随机读取请求。 저장하는 경우, 우리는 의식적으로 각 필드가 레코드를 빠르게 대응하여 오프셋 찾을 지원하는 각 요소의 고​​정 길이되도록 무작위 읽기 요청 정교한 검색 알고리즘과 많은 수의 디스크를 피하는 .

图7 Prom查询过程 그림 7 댄스 파티 쿼리 프로세스

图7用一个典型的例子描述的Prom在提供查询服务时的工作原理，限于篇幅，这里不做详细描述。 전형적인 예와 무도회는 공간이 제한 될 때 7 일이 없다 여기서 상세히 설명, 쿼리를 처리도에서 설명. 值得一提的是，Prom支持的计算并不仅限于求和SUM运算，统计意义上的常用计算都是支持的。 그것은 것을 언급 할 가치가, 무도회 컴퓨팅 지원 유의성의 계산에 사용 합 SUM 동작에 한정되지 않고 지원된다. 在现场计算方面，我们对HBase进行了扩展，Prom要求每个节点返回的数据是已经经过“本地计算”的局部最优解，最终的全局最优解只是各个节点返回的局部最优解的一个简单汇总。 각 노드가 반환 된 데이터는 "로컬 컴퓨팅"지역 OPTIMA는, 최종 글로벌 최적의 솔루션은 각 로컬 노드를 반환하기위한 최적의 솔루션입니다 통과 한 것을 현장 컴퓨팅, 우리는 HBase를 확장, 댄스 파티가 필요 간단한 요약. 很显然，这样的设计思路是要充分利用各个节点的并行计算能力，并且避免大量明细数据的网络传输开销。 분명히, 이러한 설계 개념은 각 노드의 병렬 계산 능력을 활용하고, 네트워크 트래픽 오버 헤드 정보 데이터를 많이 피하는 것이다.

用中间层隔离前后端 이전과 중간층 아이솔레이션 포트 후

上文提到过，MyFOX和Prom为数据产品的不同需求提供了数据存储和底层查询的解决方案，但随之而来的问题是，各种异构的存储模块给前端产品的使用带来了很大的挑战。 위에서 언급 한 데이터 제품의 다양한 요구에 대한 MyFOX 및 댄스 파티는 데이터 저장 및 기본 쿼리에 대한 솔루션을 제공하지만, 다양한 이기종 스토리지 모듈은 프론트 - 엔드 제품을 사용하는 교환 문제 제기 큰 도전. 并且，前端产品的一个请求所需要的数据往往不可能只从一个模块获取。 또한, 프론트 - 엔드 제품에 필요한 데이터에 대한 요구는 종종 단지 하나의 모듈로부터 얻을 수 없다.

举个例子，我们要在数据魔方中看昨天做热销的商品，首先从MyFOX中拿到一个热销排行榜的数据，但这里的“商品”只是一个ID，并没有ID所对应的商品描述、图片等数据。 예를 들어, 우리는 제 MyFOX 데이터의 핫리스트를 얻을 어제 상품 판매 본 데이터 큐브 싶지하지만 "상품"이 단지 ID이며, 해당하는 ID 정보가 없다 , 사진 및 기타 데이터. 这个时候我们要从淘宝主站提供的接口中去获取这些数据，然后一一对应到热销排行榜中，最终呈现给用户。 마스터 스테이션으로부터 이번에 우리들은 Taobao 이러한 데이터를 획득하고, 핫리스트에 대응하는 인터페이스, 및 최종 사용자에게 프리젠 테이션을 제공한다.

图8 glider的技术架构 그림 8 글라이더의 기술 아키텍처

有经验的读者一定可以想到，从本质上来讲，这就是广义上的异构“表”之间的JOIN操作。 경험이 풍부한 독자는 작업 사이에 "테이블"을 가입 광범위하게 이기종 인 본질에서 생각 할 수있을 것입니다. 那么，谁来负责这个事情呢？ 그래서,이 일에 대한 책임 누구인가? 很容易想到，在存储层与前端产品之间增加一个中间层，它负责各个异构“表”之间的数据JOIN和UNION等计算，并且隔离前端产品和后端存储，提供统一的数据查询服务。 이는 통합 데이터 액세스 서비스를 제공하는, 결합하고 UNION 컴퓨팅 사이 다양한 이기종 데이터 "테이블"을 담당 중간층을 증가시키고, 선단을 분리 및 스토리지 제품 백엔드 저장 층 및 프런트 엔드 제품 간의 생각하기 쉽다 . 这个中间层就是glider（如图8所示）。 중간층은 글라이더 (그림 8)입니다.

缓存是系统化的工程 캐시는 체계적인 프로젝트

除了起到隔离前后端以及异构“表”之间的数据整合的作用之外，glider的另外一个不容忽视的作用便是缓存管理。 전방 및 후방 단부와 분리 이외에 다른 무시할 수없는 캐시 관리는 외부 글라이더의 역할 사이에서 이종 데이터 "표"의 통합을한다. 上文提到过，在特定的时间段内，我们认为数据产品中的数据是只读的，这是利用缓存来提高性能的理论基础。 특정 시간에, 상기 언급 된, 우리는 제품 데이터가 이론적 기초의 성능을 향상시키기 위해 사용되는 캐싱, 읽기 전용 믿는다.

在图8中我们看到，glider中存在两层缓存，分别是基于各个异构“表”（datasource）的二级缓存和整合之后基于独立请求的一级缓存。 그림 8에서, 우리는 각각의 이성질체 "테이블"(데이터 소스) 독립 요구에 기초하여 보조 캐시와 통합 한 후 캐시를 기반으로 캐시, 두 글라이더의 존재를 참조하십시오. 除此之外，各个异构“表”内部可能还存在自己的缓存机制。 또한, 개별 이성질체 "표"의 자체 내부 캐싱 메커니즘을 가질 수있다. 细心的读者一定注意到了图3中MyFOX的缓存设计，我们没有选择对汇总计算后的最终结果进行缓存，而是针对每个分片进行缓存，其目的在于提高缓存的命中率，并且降低数据的冗余度。 조심 리더는 우리가 최종 계산 된 결과에 여지 캐시에 요약되어 있지만, 캐시 히트 율을 향상시킬 목적으로, 각 조각에 대한 캐시가없는,도 MyFOX 3 캐시 설계를 발견하고, 데이터를 감소 있어야 중복.

大量使用缓存的最大问题就是数据一致性问题。 가장 큰 문제는 캐시 데이터 일관성 문제가 광범위하게 사용된다. 如何保证底层数据的变化在尽可能短的时间内体现给最终用户呢？ 어떻게 짧은 시간에 기본 데이터의 변화가 최종 사용자에게 반영 할 수 있도록? 这一定是一个系统化的工程，尤其对于分层较多的系统来说。 특히 더 많은 계층 시스템, 체계적인 프로젝트를해야합니다.

图9 缓存控制体系 9 캐시 제어 시스템

图9向我们展示了数据魔方在缓存控制方面的设计思路。 그림 9는 우리에게 캐시 제어 디자인 아이디어의 데이터 큐브를 보여줍니다. 用户的请求中一定是带了缓存控制的“命令”的，这包括URL中的query string，和HTTP头中的“If-None-Match”信息。 사용자 요청 URL 쿼리 스트링을 포함 캐시 "명령"및 HTTP 헤더 "IF-없음 매치"정보로 제어되어야한다. 并且，这个缓存控制“命令”一定会经过层层传递，最终传递到底层存储的异构“表”模块。 또한,이 캐시 제어 "명령"층을 통과 할 것이며, 마지막으로 기본 스토리지 이종 "테이블"모듈로 전달. 各异构“表”除了返回各自的数据之外，还会返回各自的数据缓存过期时间（ttl），而glider最终输出的过期时间是各个异构“表”过期时间的最小值。 데이터로 돌아 외에 이성질체 "표"는 의지는 데이터 캐시 만료 시간 (TTL)로 복귀하고, 만료 시간 글라이더 최종 출력은 최소 개별 이성질체 "테이블"만료 시간입니다. 这一过期时间也一定是从底层存储层层传递，最终通过HTTP头返回给用户浏览器的。 유효 시간은 또한 하부 저장 층에서 전달 될, 궁극적 HTTP 헤더 브라우저를 통해 사용자에게 반환한다.

缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。 캐시 시스템의 또 다른 문제가 고려하는 것은 캐시의 애벌란 효과 침투 및 실패이다. 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。 캐시 침투 캐시 내결함성을 위해 수동형 쓰고 대가 충돌하지 않기 때문에 존재하지 이어질 것이다 캐시에 기록되지 않은 기록 층에서 데이터를 찾을 수없는 경우, 존재하지 않는 특정 데이터를 쿼리 지칭 데이터 요청이 쿼리 저장 층에 갈 때마다, 캐시의 의미를 잃었다.

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 효과적으로 캐시 통해 문제를 해결할 수있는 여러 가지 방법으로, 가장 일반적인 블 필터의 사용은, 특정 데이터의 부재에 충분히 큰 비트 맵에 대한 모든 가능한 데이터 해시 맵 것 따라서 기본 스토리지 시스템 쿼리 압력을 회피 오프 채기. 在数据魔方里，我们采用了一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 쿼리 (데이터가 존재, 또는 시스템 장애하지 않습니다 여부), 우리는 여전히, 빈 결과 캐시를 볼 수 있지만 만료 시간을 빈 데이터를 반환하는 경우 데이터 큐브에서 우리는, 더 간단하고 원유 방법을 채택하고있다 그것은 매우 짧은, 더 이상 5 분 이상이 될 것입니다.

缓存失效时的雪崩效应对底层系统的冲击非常可怕。 기본 시스템에 눈사태 캐시 실패에 미치는 영향은 매우 끔찍하다. 遗憾的是，这个问题目前并没有很完美的解决方案。 불행하게도,이 문제는 더 완벽한 솔루션은 없습니다. 大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。 대부분의 시스템 설계자들은 동시 요청의 다수의 기본 스토리지 시스템에서 떨어질 때 고장을 피하기 위해, 로킹 작성 또는 단일 스레드 큐 보장 캐시 (프로세스)에 의한 방법을 고려한다. 在数据魔方中，我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均匀地分布在时间轴上，一定程度上能够避免缓存同时失效带来的雪崩效应。 데이터 큐브에서, 각각의 클라이언트의 데이터를 위해 할 수있는 캐시 만료기구 설계 이론 균일 시간축상에서 분산 시간 실패, 어느 정도까지는 동시에 실패에게에서 캐시 의한 애벌랜치 효과를 피할 수.

结束语 결론

正是基于本文所描述的架构特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，数据中间层glider支持每天4000万的查询请求，平均响应时间在28毫秒（6月1日数据），足以满足未来一段时间内的业务增长需求。 그것은 본원에 기술 된 구조적 특징에 기초하고, 데이터 큐브 이제 데이터 글라이더 중간층 지원 28 밀리 세컨드의 평균 응답 시간과 하루 당 40,000,000 쿼리의 미리 압축 된 데이터 저장 공간 80TB를 제공 할 수있다 (6 월 1 데이터)를 시간에 대한 미래의 수요 증가를 충족하기에 충분.

尽管如此，整个系统中仍然存在很多不完善的地方。 그럼에도 불구하고, 여전히 시스템에 많은 결함이있다. 一个典型的例子莫过于各个分层之间使用短连接模式的HTTP协议进行通信。 전형적인 예는 다양한 계층 모드 HTTP 프로토콜 간의 짧은 연결의 사용이다. 这样的策略直接导致在流量高峰期单机的TCP连接数非常高。 독립형 TCP 연결의 피크 트래픽 기간에 직접 인도이 전략은 매우 높다. 所以说，一个良好的架构固然能够在很大程度上降低开发和维护的成本，但它自身一定是随着数据量和流量的变化而不断变化的。 그래서, 당연히, 양호한 구조는 큰 정도의 개발 및 유지 보수 비용을 줄일 수 있지만, 그 자체가 데이터 트래픽과 끊임없이 변화의 양에 따라 변화한다. 我相信，过不了几年，淘宝数据产品的技术架构一定会是另外的样子。 나는 몇 년, 기술 아키텍처 Taobao의 데이터 제품은 다른 방법이 될 것으로 판단된다.

其他文章摘要 다른 기사 요약

　　 【1】 海量数据领域涵盖分布式数据库、分布式存储、数据实时计算、分布式计算等多个技术方向。 [1] 분산 데이터베이스, 분산 된 다수의 저장 기술에 의해 덮여 방대한 데이터 영역은 실시간 데이터 계산, 컴퓨팅 방향 분포.

对于海量数据处理，从数据库层面来讲无非就是两点：1、压力如何分摊，分摊的目的就是为了把集中式变为分布式。 대용량 데이터 처리의 경우, 그것의 측면에서 데이터베이스 레벨에서, 두 지점에 지나지 않는다 : (1) 압력을 공유하는 방법, 목적은 주 분배에 중앙 집중화한다. 2、采用多种的存储方案，针对不同的业务数据，不同的数据特点，采用RDBMS或采用KV Store，选择不同数据库软件，使用集中式或分布式存储，或者是其他的一些存储方案。 도 2는 다른 비즈니스 데이터, 다른 데이터 특성, RDBMS 또는 KV 저​​장소를 사용하는 다양한 저장 솔루션을 이용하여, 중앙 집중 형 또는 분산 형 기억 장치, 또는 다른 저장 용액을 사용하여, 다른 데이터베이스 소프트웨어를 선택한다.

【2】将数据库进行拆分，包括水平拆分和垂直拆分。 [2] 수평 및 수직 스플릿 스플릿을 포함한 데이터베이스를, 분할.

水平拆分主要解决两个问题：1、底层存储的无关性。 1, 독립의 기본 스토리지 : 수평 분할은 주로 두 가지 문제를 해결합니다. 2、通过线性的去增加机器，支持数据量以及访问请求包括TPS（Transaction Per Second）、QPS（Query Per Second）的压力增长。 도 2는 선형 기계 증가 할뿐만 아니라, TPS (초당 트랜잭션) 압력, QPS (쿼리 초당)의 증가를 포함하여 데이터 액세스 요청의 크기를 지원한다. 其方式如把一张大数据表按一定的方式拆分到不同的数据库服务器上。 다른 방식으로, 데이터베이스 서버에 분할 큰 데이터 테이블을 특정 방식과 같은.

海量数据从集中式走向分布式，可能涉及跨多个IDC容灾备份特性。 분산에 중앙에서 대규모 데이터는 여러 속성에서 IDC의 재해 복구를 포함 할 수있다.

【3】阿里巴巴的数据对不同地域数据的处理方法。 [3] 다른 지리적 데이터 알리바바 데이터 처리 방법.

由三个产品密切配合解决：是Erosa、Eromanga和Otter。 해결과 긴밀하게 협력 세 가지 제품으로 구성 : Erosa, Eromanga과 달입니다.

Erosa做MySQL（或其他数据库库）的Bin-Log时时解析，解析后放到Eromanga。 Erosa는 빈 로그는 항상 Eromanga에 해석 해결 MySQL을 (또는 다른 데이터베이스 라이브러리)를 않습니다. Eromanga是增量数据的发布订阅的产品。 Eromanga 증분 데이터 구독 제품을 출시한다. Erosa产生了时时变更的数据发布到Eromanga。 Erosa 수시로 Eromanga에 데이터를 게시로 변경했다. 然后各个业务端（搜索引擎、数据仓库或关联的业务方）通过订阅的方式，把时时变更的数据时时的通过Push或Pull的方式拉到其业务端，进行一些业务处理。 그리고 가입의 방법으로 각 사업 종료 (검색 엔진, 데이터웨어 하우스 또는 비즈니스 관련 당사자), 자주는 비즈니스 측면에 의해 수시로 변경 데이터는 푸시를 당기거나, 어떤 비즈니스 프로세스 방식을 당깁니다. 而Otter就是跨IDC的数据同步，把数据能及时反映到不同的AA站。 오터 데이터는 다른 AA 스테이션에 반영 할 수 있고, 크로스 IDC 데이터 동기화이다.

数据同步可能会有冲突，暂时是以那个站点数据为优先，比如说A机房的站点的数据是优先的，不管怎么样，它就覆盖到B的。 데이터 동기화 위치의 방은 B의 커버에 어떤 상관없이, 그러한 우선 순위없는 데이터로서 일시적으로 우선 순위와 같은 사이트 데이터에 기초하여 충돌을 일 수있다.

【4】对于缓存。 [4] 캐시.

1、注意切分力度，根据业务选择切分力度。 도 1을 참조하면, 서비스 선택 세그멘테이션 노력에 따라, 분할 노력을 참고. 把缓存力度划分的越细，缓存命中率相对会越高。 캐시는 미세한 노력을 분할되어, 캐시 히트 율이 상대적으로 높을 것이다.
2、确认缓存的有效生命周期。 2, 검증 된 라이프 사이클 캐시.

【5】拆分策略 [5] 해결 정책

1、按字段拆分（最细力度）。 1, 필드 분할 (최고의 노력)에 따라. 如把表的Company字段拆掉，就按COMPANY_ID来拆。 이러한 제거 테이블의 회사 필드로, 다음 해체 COMPANY_ID를 누릅니다.

2、按表来拆，把一张表拆到MySQL，那张表拆到MySQL集群，更类似于垂直拆分。 2, 철거에 표에 따라, MySQL의에 테이블의 철거, MySQL은 그 테이블은 수직 분할에 더 가깝다 클러스터로 분할.

3、按Schema拆分，Schema拆分跟应用相关的。 스키마에 의해 분할 3, 스키마는 응용 프로그램과 관련된 분할합니다. 如把某一模块服务的数据放到某一机群，另一模块服务的数据放到其他MySQL机群。 다른 MySQL 클러스터 서비스에 다른 모듈에서 함대 데이터로 모듈에 데이터 서비스를 제공합니다. 但对外提供的整体服务是这些机群的整体组合，用Cobar来负责协调处理。 그러나 코바,이 클러스터의 전체 조합 외부에 제공하는 전체 서비스는 조정 과정에 대한 책임을 져야합니다.

Cobar类似于MySQL Proxy，解析MySQL所有的协议，相当于可以把它看成MySQL Server来访问的。 MySQL의 프록시 같은 코바는, MySQL은이 액세스에 MySQL 서버의 등가로 볼 수있다, 모든 프로토콜을 해결.