淘宝海量数据产品的技术架构

淘宝的海量数据产品的技术架构是什么，它如何应对“双十一”上的海量访问？首先看图片:

根据数据流，我们将淘宝数据产品的技术架构分为五个层（如图1所示），分别是数据源，计算层，存储层，查询层和产品层. 体系结构的最顶层是我们的数据源层. 淘宝主站点上有用户，商店，商品和交易的，以及用户浏览，搜索和其他行为日志. 这一系列数据是数据产品最原始的生命力.

在数据源层实时生成的数据通过淘宝独立开发的数据传输组件DataX，DbSync和Timetunnel实时传输到具有1500个节点的Hadoop集群中. 它是计算层的主要组成部分. 在“阶梯”上，我们每天大约有40,000个工作，以根据产品要求对1.5PB的原始数据执行不同的MapReduce计算. 该计算过程通常可以在凌晨两点之前完成. 相对于前端产品看到的数据，此处的计算结果很可能是处于中间状态的结果，这通常是数据冗余与前端计算之间取得适当平衡的结果.

我不得不提到一些需要高效性的数据，例如搜索字词的统计数据，我们希望将其尽快推向数据产品的前端. 这种需求然后再使用“云梯”来计算，效率会相对较低，为此，我们制作了一个实时的数据流计算平台，称为“ Galaxy”. “ Galaxy”也是一个分布式系统. 它从TimeTunnel接收实时消息，在内存中执行实时计算，并在最短时间内调用前端产品将计算结果刷新到NoSQL存储设备.

不难理解，“易来”或“银河”不适合直接向产品提供实时数据查询服务. 这是因为，对于“梯形图”，其定位仅用于脱机计算，并且不能支持更高的性能和并发性要求. 对于“ Galaxy”来说，尽管所有的代码都掌握在手中，但必须将数据接收，实时计算，存储和查询功能完全集成在分布式系统中，并且无法避免分层. 最终，它仍然取决于当前的体系结构.

因此，我们为前端产品设计了特殊的存储层. 在这个级别上，我们有基于MySQL的分布式关系集群MyFOX和基于HBase的NoSQL存储集rom. 在下面的文本中，我将重点介绍这两个集群的实现原理. 此内. 存储层中异构模块的增加为前端产品的使用带来了挑战. 为此，我们设计了一个通用的数据中间层滑翔机来屏蔽这种影响. 滑翔机通过HTTP协议提供了与外界的宁静接口. 数据产品可以通过唯一的URL获取所需的数据.

以上是对淘宝海量数据产品技术架构的总体介绍.

淘宝数据产品选择了MySQL的MyISAM引擎作为底层数据存储引擎. 在此基础上，为了处理海量数据，我们设计了分布式MySQL群集MyFOX的查询代理层，以使该分区对前端应用程序透明.

目前，存储在MyFOX中的统计结果数据已达到10TB，占数据立方体总数据量的95％以上，并且每天以超过6亿的增量递增（如图2所示）. ）. 这些数据大约由我们均匀分布到20个MySQL节点，并在查询过程中通过MyFOX透明地提供:

值得一提的是，并非MyFOX中的所有20个节点都是“相等的”. 一般来说，数据产品的用户只关心“最近几天”的数据. 数据越早，越容易被遗漏. 因此，出于硬件成本考虑，我们将“热节点”和“冷节点”划分为20个节点（如上所示）

顾名思义，“热节点”存储最新和经常访问的数据. 对于这部分数据，我们希望为用户提供最快的查询速度，因此在硬盘方面，我们选择了15,000 rpm的SAS硬盘，该硬盘是根据一个节点上的两台计算机计算的，存储成本为单位数据约为4.5W / TB. 相应地，对于“冷数据”，我们选择了7,500 rpm的SATA硬盘，它可以在单个磁盘上存储更多数据，存储成本约为1.6W / TB. 分离冷数据和热数据的另一个好处是，它可以有效地提高内存与磁盘的比率. 从图4可以看出，“热节点”上的单台机器只有24GB的内存淘宝云梯分布式计算平台整体架构，并且磁盘已满，大约有1.8TB（300 * 12 * 0.5 / 1024），内存与磁盘的比率约为4 : 300，远低于MySQL服务器的合理值. 低内存磁盘比率的结果是，有一天，即使所有内存都用完了，也无法保存数据的索引-这一次，需要大量查询请求才能从磁盘读取索引，大大降低了效率.

在MyFOX出现之后，一切看起来都非常完美，开发人员甚至都不会意识到MyFOX的存在，没有任何特殊修饰的SQL语句就可以满足需求. 这种状态持续了很长时间，直到一天，我们遇到了传统关系无法解决的问题-完整属性选择器（如下图所示）.

这是一个非常典型的例子. 为了说明问题，我们仍然使用关系的思想来描述. 对于笔记本计算机的类别，用户为某个查询选择的过滤条件可以包括一系列属性（字段），例如“笔记本大小”，“笔记本位置”和“硬盘容量”，并且可以使用在每种过滤条件下，就属性而言，属性值的分布极为不均匀. 在图5中，我们可以看到笔记本电脑大小的属性具有10个枚举值，而“蓝牙功能”的属性值是布尔值，并且数据筛选非常差.

在用户选择不确定的过滤条件的情况下，有两种解决全属性问题的想法: 一种是用尽所有可能的过滤条件组合，对“梯形图”执行预先计算，然后存储在中查询；另一种是存储原始数据，并根据过滤条件过滤出相应的记录，以便用户查询时进行现场计算. 显然，由于滤波器条件的排列和组合几乎是无穷尽的，因此第一种方案实际上是不可取的. 在第二种方案中，原始数据存储在哪里？如果您仍然使用关系，您打算如何索引该表？

这一系列问题使我们想到了“为定制存储，现场计算和提供查询服务创建引擎”的概念，即Prometheus（如下图所示）.

从图片中可以看到，我们选择了HBase作为Prom的基础存储引擎. 选择HBase的主要原因是它基于HDFS构建，并且具有针对MapReduce的良好编程接口. 尽管Prom是解决常见问题的通用服务框架，但是在这里，我们仍然以所有属性的选择为例来说明Prom的工作原理. 这里的原始数据是前一天在淘宝上的交易明细. 在HBase集群中，我们使用属性对（属性和属性值的组合）作为要存储的行键. 对于与行键相对应的值，我们设计了两个列族，即存储交易ID列表的索引字段和原始交易明细的数据字段. 在存储时，我们自觉地使每个字段中的每个元素具有固定的长度，这是为了支持通过偏移量快速查找对应的记录，以避免复杂的搜索算法和来自磁盘的大量随机读取请求.

上图使用一个典型示例来描述Prom在提供查询服务时的工作原理，该方法仅限于空间，此处不再赘述. 值得一提的是，Prom支持的计算不限于求和SUM操作，而是支持统计意义上的常用计算. 在现场计算方面，我们扩展了HBase. 舞会要求每个节点返回的数据是已“本地计算”的本地最佳解决方案. 最终的全局最优解只是每个节点返回的局部最优解之一. 简单总结. 显然，这种设计思想是充分利用每个节点的并行计算能力，避免大量详细数据的网络传输开销.

如上所述，MyFOX和Prom为数据产品的不同需求提供数据存储和低级查询解决方案，但是随之而来的问题是，各种异构存储模块被用于前端产品. 带来了巨大的挑战. 而且，通常仅从一个模块就无法获得请求前端产品所需的数据.

例如，我们想查看昨天在数据多维数据集中制作的热门商品. 首先，我们从MyFOX获取了一个热门列表的数据，但是这里的“商品”只是一个ID，而没有ID产品说明，图片和其他数据. 这时，我们需要从淘宝总站提供的界面中获取这些数据，然后与热点列表一一对应，最后呈现给用户.

从本质上讲，从广义上讲，这是异构“表”之间的JOIN操作. 那么，谁对此事负责？容易想到的是，在存储层和前端产品之间添加一个中间层，该层负责计算各种异构“表”之间的数据JOIN和UNION，并隔离前端产品和后端产品. 端存储，并提供统一的数据查询服务. 中间层是滑翔机（如图所示）.

除了隔离正面和背面以及异构“表”之间的数据集成的角色外，另一个不可忽视的滑翔机角色是缓存管理. 如上所述，我们相信在一定时间内，数据产品中的数据是只读的，这是使用缓存提高性能的理论基础.

滑翔机中有两层缓存，分别是基于各种异构“表”（数据源）的第二层缓存和基于集成后的独立请求的第一层缓存. 除此之外，每个异构“表”还可以具有自己的缓存机制. 细心的读者一定已经注意到了图3中的MyFOX缓存设计. 在汇总计算之后，我们没有选择缓存最终结果，而是为每个分片进行了缓存. 其目的是提高缓存命中率并减少数据. 冗余.

大量使用高速缓存的最大问题是数据一致性. 如何确保基础数据的更改在最短的时间内反映给最终用户？这必须是一个系统的项目，尤其是对于具有更多层的系统.

用户的请求必须具有带有缓存控制的“命令”，其中包括URL中的查询字符串和HTTP标头中的“ If-None-Match”信息. 并且，该缓存控制“命令”将通过各层，最后到达底层存储的异构“表”模块. 除了返回自己的数据之外，每个异构“表”还将返回它们自己的数据高速缓存到期时间（ttl），并且滑翔机最终输出的到期时间是每个异构“表”的到期时间的最小值. 该到期时间还必须从底层存储层传递，最后通过HTTP标头返回到用户的浏览器.

缓存系统必须考虑的另一个问题是当缓存穿透并发生故障时的雪崩效应. 高速缓存渗透是指查询某些不存在的数据. 因为高速缓存在未命中时是被动写入的，并且出于容错目的，如果无法从存储层找到数据，则不会将其写入高速缓存，这将导致这种不存在. 每个数据请求都必须转到要查询的存储层，失去了缓存的含义.

有很多方法可以有效地解决缓存渗透问题，最常见的方法是使用Bloom过滤器，将所有可能的数据散列到足够大的位图中，某些不存在的数据将被该位图拦截，因此避免对基础存储系统的查询压力. 在数据多维数据集中，我们使用一种更简单，更粗糙的方法. 如果查询返回的数据为空（无论数据不存在还是系统出现故障），我们仍将缓存该空结果，但其到期时间将很短，不超过五分钟.

缓存失败时的雪崩效应对基础系统产生了可怕的影响. 不幸的是，目前还没有完美的解决方案. 大多数系统设计人员考虑锁定或排队以确保缓存的单线程（进程）写入避免在失败时大量并发请求落入底层存储系统. 在数据立方体中，我们设计的缓存过期机制可以在一定程度上在时间轴上分配每个客户端的数据过期时间，从而避免了同时缓存过期引起的雪崩效应.

基于本文所述的体系结构功能，Data Cube当前可以在压缩之前提供80TB的数据存储空间. 数据中间层滑行器每天支持4000万个查询请求，平均响应时间为28毫秒（6月1日）（数据），足以满足未来一段时间的业务增长需求. 但是，整个系统仍然存在很多缺陷. 一个典型的示例是使用短连接模式HTTP协议进行层之间的通信. 这样的策略直接导致了高峰流量期间大量的单机TCP连接. 因此，好的架构可以大大降低开发和维护成本，但是它必须随着数据量和流量的变化而不断变化. 我相信几年之内，淘宝数据产品的技术架构肯定会有所不同.

其他文章摘要:

【1】海量数据领域涵盖了多个技术方向，例如分布式，分布式存储，数据实时计算和分布式计算.

对于海量数据处理，从级别来说，无非就是两点: 1.如何分担压力，分发的目的是将集中式更改为分布式. 2.采用多种存储方案. 对于不同的业务数据和不同的数据特​​征，使用RDBMS或KV Store，选择不同的软件，并使用集中式或分布式存储，或其他一些存储方案.

【2】拆分，包括水平拆分和垂直拆分.

水平分割主要解决两个问题: 1.基础存储的不相关性. 2.要线性增加机器，请支持数据量和访问请求的增加，包括TPS（每秒事务）和QPS（每秒查询）压力增长. 方法是以某种方式将大数据表拆分为不同的服务器. 从集中到分散的海量数据可能涉及多个IDC的灾难恢复功能.

【3】阿里巴巴针对不同地区数据的数据处理方法.

由以下三种产品密切解决: 埃罗莎（Erosa），埃罗曼加（Eromanga）和水獭（Otter）. Erosa会不时对MySQL（或其他库）进行Bin-Log分析，并在分析后将其放入Eromanga. Eromanga是用于增量数据的发布和订阅产品. Erosa生成的数据会不时更改并发布到Eromanga. 然后，每个业务端（搜索引擎，数据仓库或关联的业务方）都会通过Push或Pull将更改后的数据不时拉到其业务端，以通过订阅执行一些业务处理. Otter正在跨IDC同步数据，以将数据及时反映到不同的AA站. 数据同步中可能存在冲突. 目前，该站点的数据是优先级. 例如，对A室的场所的数据进行优先排序. 无论如何淘宝云梯分布式计算平台整体架构，它将覆盖B.

【4】用于缓存.

1. 注意切割强度，并根据业务选择切割强度. 高速缓存强度划分得越细，高速缓存命中率越高. 2.确认缓存的有效生命周期.

【5】分裂策略

1. 按字段划分（最薄的强度）. 如果您删除表格的“公司”字段，请按COMPANY_ID将其删除.

2. 根据表进行分解，将表分解为MySQL，然后将表分解为MySQL群集，这与垂直拆分更为相似.

3. 与应用程序相关的按架构拆分. 例如，将某个模块提供的数据放入某个群集，而另一模块提供的数据放入其他MySQL群集. 但是，外界提供的整体服务就是这些舰队的整体组合，而Cobar则用于协调处理过程.

垂直应用程序架构，分布式服务架构，移动计算架构

总体性能比较: 套接字（BIO / NIO / Netty / MINA）> RMI> HTTP Invoker> = Hessian> REST >> Burlap> EJB >> Web Service

如果协议设计更好，则Socket性能无疑是最高的，同时灵活性和复杂性也最高. 如果使用高效的网络框架，例如: Mina，Netty等可以降低开发复杂性，通常在性能非常苛刻的条件下使用. RMI的性能相对较低，但仍与Socket处于相同的数量级，并且只能在Java系统之间进行通信. 如果它是基于Internet的，还存在穿越防火墙的问题. 使用Spring封装的性能略高于原始RMI方法. 主要原因是Spring使用了代理和缓存机制，从而节省了对象重新获取的时间. HTTPInvoker是Spring特有的，只能在客户端和服务器上的Spring框架下使用. 它与RMI基本相同. Java的序列化技术用于传输对象. 两者之间的性能差异很小. 当数据量很小甚至比RMI高时，Hessian的性能会很好. 当数据结构复杂或有大量数据对象时，它比RMI慢20％左右. Hessian的优点是它精简高效，并且可以在多种语言中使用. 支持Java，C ++ 、. net，python，ruby等语言. 此外，Hessian可以充分利用Web容器的成熟功能，这在处理大量用户访问方面非常有利. Web容器可以保证资源分配，线程排队和异常处理. RMI本身不提供多线程服务器.

REST体系结构也是一种相对简单高效的Web服务体系结构. 与Hessian相比，其性能略低，但仍处于相同的数量级. 它也基于HTTP协议. 当前有许多成功的案例. 当数据量非常小时，粗麻布的性能是可以接受的，并且随着数据量的增加，性能会急剧下降. 通常，能耗约为RMI的3倍. 主要原因是: Hessian使用二进制传输数据，而Burlap使用XML格式，而XML有太多的描述，相同的结构，传输量要大得多，同时XML解析会占用更多的资源，特别是在大量数据的情况下. EJB基于RMI协议，性能低下. 同时，它只能在Java系统中使用，不能跨语言使用. 目前，它的使用越来越少. 目前，阿里巴巴已经完全放弃了EJB. 在这些远程调用协议中，Web Service的性能最低. 通常，Web Service的性能比Hessian的性能慢约10到20倍. 同时，对于相同的访问请求，Web Service传输的数据量约为Hessian的6倍，这会占用大量网络带宽. 同时，XML的性能通常不高. XML <-> Java Bean的编码和解码非常耗费资源，对于并发和高负载来说，它不是一个很好的网站. 选择. 同时，使用Web服务不是很方便.

摘要: Hessian和REST体系结构个人认为这是一种出色的高性能通信协议. 如果对性能的要求特别严格，则可以直接使用Socket方法. 目前，阿里巴巴的内部远程通话主要使用Hessian和Dubbo（基于Mina / Netty Framework），经受了苛刻的高并发和高负载的测试.

（原件: ）

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-171033-1.html