奋斗足迹|崔玉松 » 应用架构

淘宝在数据处理领域的项目及开源产品介绍

崔玉松 — Sat, 17 Sep 2011 01:11:19 +0000

淘宝在数据存储和处理领域在国内互联网公司中一直保持比较靠前的位置，而且由于电子商务领域独特的应用场景，淘宝在数据实时性和大规模计算及挖掘方面一直在国内保持着领先，因此积累了很多的实践的经验和产品。

TimeTunnel

基于Hbase打造的消息中间件，具有高可靠、消息顺序、事务等传统特性，还能按时间维度反复订阅最近历史的任意数据
高性能的broker，单节点达2万TPS，实际支持上千长链接并发
承载海量的数据传输，日同步数据达10TB，并且包含淘宝主营收入等关键性数据
在各IDC内，部署了超过2000个客户端，覆盖全网日志传输
Scribe、flume、activemq、ZeroMQ？我们可以做得更强大

TBFS

基于Hdfs 0.20进行全面改造，设计目标：单个集群可达10000台服务器，支持10亿文件、100PB的数据的存储
领先于社区的全新设计，彻底解决namenode单点问题，并可实现集群在线升级
期待你来挑战：snapshot、异地数据复制、多级的cache、软硬链接支持

Hbase

基于Hbase0.90.3进行改造，目前有上百台的Hbase服务器，支淘宝7个online应用，online数据存储达100T
支持本地化数据计算、二级引索
期待你来挑战：无阻塞的compact、更多的事务支持、更短的请求响应时间、更强大的索引（Lucene for hbase）

Mapreduce

基于Hadoop0.19改造，最大单个集群规模达2000台服务器，兼容hadoop0.20 绝大多数API
实际存储数据超过10PB，日运行mapreduce job达5万个
期待你来挑战：更高效任务调度、更优雅的计算资源管理、更灵活的分布计算模型

Hive

基于hive0.6改造，修改的patch达上百个，支持SQL中间结果复用等众多特性
支持淘宝几乎所有的商业数据分析任务，是各行业数据分析师和数据开发工程师必备的技能
期待你来挑战：Hive & Pig能混合编程？现在不能，你敢想就可以来做！

Taobao-pamirs-schedule

taobao-pamirs- schedule是一个基于分布式环境的多线程任务处理框架。目的是让一种批量任务或者不断变化的任务，能够被动态的分配到多个主机的JVM，不同的线程组中并执行。所有的任务能够被不重复，不遗漏的快速处理。它将需要执行的任务抽象成一致的任务模型，进行统一的管理和监控。运用schedule，任务能够比较均匀的分发到多台机器上进行处理，并且可以动态的进行水平扩展。

QLExpress

一个轻量级的脚本引擎，作为一个嵌入式规则引擎在业务系统中使用。让业务规则定义简便而不失灵活。让业务人员就可以定义业务规则。支持标准的JAVA语法，还可以支持自定义操作符号、操作符号重载、函数定义、宏定义、数据延迟加载等。

UIC

Uic是个海量数据的高稳定高并发高响应高可靠高一致性的系统。海量数据：现在整个用户中心的注册用户数接近6亿，加上地址，支付宝绑定数据，接近20亿。现在通过分库分表存在了16个库1024张表里面。高稳定,高可靠：用户中心是淘宝最为核心的系统之一，一个完整的交易流程需要访问UIC高达几十次，所以UIC的稳定是整个淘宝的重中之重，我们为了UIC的稳定做了很多容灾的方案，包括多机房的备份，缓存的容灾，mysql的容灾，流量的控制等等，可以说UIC的核心就是各种容灾体系和在各种极端情况的下解决措施高并发,高响应：每天访问UIC的数据在200亿左右，我们使用了tair做为缓存，使用protobuf序列化，尽可能的提高缓存的命中率，现在用户数据的命中率在99%。

Prom

海量数据实时计算框架。基于搜索技术对海量明细数据做实时计算。目前主要对交易数据做分析，应用于数据魔方中特点：

多维索引组合查询
支持任意维度的计算
实时响应(秒级)
结果精确

Andes

Andes是基于HBase的任意数据长时间维度高性能数据查询集群系统。解放数据魔方在查询时间段上的限制。采用key-list存储方式，对于任何时间长度的查询均仅需一次数据库访问即可完成，规避查询时间对于查询性能的影响。

KeyKeys

用户搜索query数据分析系统。应用于淘词中，提供实时匹配用户输入query做关键query、关键热词的查询计算。

Myfox/Nodefox

MyFOX是一个针对海量统计数据设计的高性能分布式MySQL集群中间层，承担着数据魔方90%以上的数据存储和查询需求。MyFOX能够提供： • 1) “表字段+数据行数”相组合的数据切分规则； • 2) 完全透明的标准SQL查询接口 • 3) 同样的SQL语句，在10亿数据量下，与1000万数据量时完全相同的查询性能 • 4) 每份数据跨机房冗余，单机故障时受影响分片在集群内迅速自我复制； • 5) 冷热数据分离；实时监控查询频繁的数据分片，必要时在集群内进行扩充性的自动复制。

Glider

Glider是建立在MyFOX、Prom以及Keykeys等异构数据源之上的统一的数据中间层，是数据魔方、淘宝指数以及开放API等数据产品的统一的数据查询出口。 Glider对各个异构数据源进行高度抽象，并在此基础上进行通用的JOIN、UNION、排序、去重、表达式求值等计算。这一复杂过程仅通过简单的配置即可实现。 Glider目前承担着单机每天超过2000万的数据查询请求，8月25日的平均响应时间126毫秒。

Node.js

Node.js是一个基于V8引擎的服务器端JavaScript运行环境，提供非阻塞、事件驱动、异步等特性。对于高负载应用服务场景，以及最大化利用服务器硬件资源具有很大实用价值。我们是国内最早将Node.js引入互联网商业开发领域的团队，已应用此技术开发了taojob（http://taojob.tbdata.org）、数据魔方俱乐部等一系列Web产品。目前正在使用Node.js对Myfox、Glider进行升级改造，并将其应用于“淘宝指数”的产品开发。

数据可视化

数据可视化是关于使用图形化的手段，清晰有效地传达与沟通信息的研究。淘宝数据可视化实验室自2010年成立以来，使用最新的数据可视化技术对淘宝海量商业数据进行研究分析，通过一系列可视化应用向外界展示淘宝数据蕴藏的价值，展现数据之美，为用户提供了了解数据、分析数据的全新的方式。

体感交互

通过对最新体感交互技术的研究，我们将在数据可视化及数据产品中为用户提供革命性的交互体验，帮助用户更方便的使用互联网数据产品。

分布式推荐系统

基于HADOOP-MAHOUT分布式机器学习技术、面向个性化主题的数据处理平台（PDP）核心应用之一；应用架构为offline计算+online两层推荐引擎；数据分为采集中心、算法中心、发布中心、评价中心。淘宝网消费者购物模式挖掘淘宝网消费者购物模式挖掘是淘宝指数项目中的一个子项目，通过分析消费者历史购物行为，挖掘和识别消费的购物模式和购物心理。项目中我们采用购物类目关联图分析的手段，通过图论技术来实现消费者相似购物模式的挖掘。其中类目相似连接图构造，相似购物团簇发掘是其中的核心点。

商品评论情感分析打分

商品评论情感分析打分系统是基于淘宝网海量商品评论数据，采用关联规则挖掘的方法，构建高频特征词；通过语义分析、消费者情感趋向分析，并结合评论者本人的评论习惯（评论者得分）给出商品评论分，以此得出该商品的最终评论打分。该得分反映商品对于购买者的满意程度。

银河流数据处理平台

通用的流数据实时计算系统，以实时数据产出的低延迟、高吞吐和复用性为初衷和目标，采用actor模型构建分布式流数据计算框架（底层基于akka），功能易扩展、部分容错、数据和状态可监控。银河具有处理实时流数据（如TimeTunnel收集的实时数据）和静态数据（如本地文件、HDFS文件）的能力，能够提供灵活的实时数据输出，并提供自定义的数据输出接口以便扩展实时计算能力。银河目前主要是为魔方提供实时的交易、浏览和搜索日志等数据的实时计算和分析。

开放式数据体系

真正基于云平台的数据体系及数据处理平台，秉承透明、标准、隐私保护的设计理念，实现了包括主题研究、挖掘算法、实时计算数据组合的开放式数据体系。

极限存储

数据仓库应用与分布式计算的经典结合，在云梯1上实现了数据高达120:1的压缩比，迄今为止已有30余种业务数据完成应用，累积节省存储达15PB，此外，在提高数据访问效率，降低计算消耗方面也有十分显著的效果。

Dbsync

用于实时同步数据库数据到HDFS的产品，通过解析各类RDBMS的log文件来提取相应的数据库动作，进而达到数据库到HADOOP的数据同步，供相关部门提取增量数据，通过dbsync，能够了解并得到所有数据的任意变化轨迹。

DataX

DataX是一个在异构的数据库/文件系统之间高速交换数据的工具。
采用Framework+plugin架构构建，Framework处理了缓冲，流控，并发，上下文加载等高速数据交换的大部分技术问题，插件仅需实现对数据处理系统的访问。
运行模式：stand-alone / on hadoop
数据传输过程在单进程内完成，全内存操作，不读写磁盘，也没有IPC。
开放式的框架，开发者可以在极短的时间开发一个新插件以快速支持新的数据库/文件系统。

SKYNET

天网调度系统（SKYNET）作为淘宝数据平台的核心调度系统，承载着淘宝数据跨部门/数十条业务线/超过一万个作业的调度和运维工作，具有图形化、跨平台、自动部署、线上运维、智能容灾的特点，是淘宝数据平台的中枢系统。

数据开发服务平台

数据开发服务平台整合IDE、调度、监控、告警、元数据、成本优化、权限控制、审计、用户管理能功能。平台将复杂的技术细节屏蔽在平台内部，为使用者提供简单便捷的用户体验，使开发者能够专注于商业领域的需求，降低用户在云梯上进行数据应用开发和数据分析的门槛。

SuperMario

海量数据的实时处理能力：SuperMario，基于erlang语言和zookeeper模块开发的高性能数据流处理框架，使用订阅者模式构建流节点间的流关系，支持高性能的数据流式实时处理。

Openresty

以更低的成本支持更高的并发处理能力：Openresty，基于Nginx构建的量子web服务框架，让web server成为量子网站核心容器，通过nginx_lua_mod的扩展，能够高效、便捷的开发高性能web服务。

LzSQL

更高效、敏捷的数据开发能力：LzSQL，基于perl：：parser模块构建的量子数据库小语言，封装了数据库分库、分表，以及异构数据实时融合（数据库和第三方引擎）的功能，便于进行快速的REST数据接口开发。

Burstnet VPS 主机评分

崔玉松 — Fri, 28 Jan 2011 02:45:33 +0000

前些日子搞特惠，买了一个最低配置的，512M内存

VPS PACKAGE #1
VPS Software: vePortal™ / OpenVZ™
CPU: 1000MHZ GUARANTEED
Memory: 512MB GUARANTEED
Disk Space: 20GB (RAID BASED CONFIG)
Bandwidth: 1000GB/MONTH
IP Addresses: 2 (IPv4) + IPv6
Management: BASIC MANAGED
DDOS Protection: CISCO™ GUARD
FREE SETUP $5.95/MONTH

================================================================
BYTE UNIX Benchmarks (Version 5.1.3)

System: 200689.www.foxapp.com: GNU/Linux
OS: GNU/Linux — 2.6.18-194.26.1.el5.028stab070.14 — #1 SMP Thu Nov 18 16:34 :01 MSK 2010
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap=”UTF-8″, collate=”UTF-8″)
CPU 0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (4788.1 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
05:07:23 up 6 min, 1 user, load average: 0.08, 0.02, 0.01; runlevel 3

————————————————————————
Benchmark Run: Fri Jan 28 2011 05:07:23 – 05:37:17
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 12759700.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2797.2 MWIPS (10.0 s, 7 samples)
Execl Throughput 3383.2 lps (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 506737.3 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 142917.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1087584.1 KBps (30.0 s, 2 samples)
Pipe Throughput 948149.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 277958.2 lps (10.0 s, 7 samples)
Process Creation 10813.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 4151.6 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 583.2 lpm (60.1 s, 2 samples)
System Call Overhead 862516.8 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 12759700.9 1093.4
Double-Precision Whetstone 55.0 2797.2 508.6
Execl Throughput 43.0 3383.2 786.8
File Copy 1024 bufsize 2000 maxblocks 3960.0 506737.3 1279.6
File Copy 256 bufsize 500 maxblocks 1655.0 142917.2 863.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 1087584.1 1875.1
Pipe Throughput 12440.0 948149.4 762.2
Pipe-based Context Switching 4000.0 277958.2 694.9
Process Creation 126.0 10813.4 858.2
Shell Scripts (1 concurrent) 42.4 4151.6 979.2
Shell Scripts (8 concurrent) 6.0 583.2 972.0
System Call Overhead 15000.0 862516.8 575.0
========
System Benchmarks Index Score 883.3

883.3的评分相当彪悍，相对于其价格来说，相当不错了，Burst有个很大的Bug是他的统计流量的系统，那玩意一点也不靠谱，我发过ticket给他们，回复说是已知的Bug，目前不限制流量，也就是显示多少无所谓了。

软件构建中的理想设计特征

崔玉松 — Wed, 13 Jan 2010 11:55:22 +0000

1、最小复杂度。设计的手艺好目标就是要复杂度最小，避免作出“聪明的”设计，因为“聪明的”设计常常难以理解

2、易于维护。易于维护意味着在设计时为做维护的程序员着想。

3、松散耦合。松散耦合意味着在设计时让程序各个组织称部分之间的管理关系最小。通过应用类接口中合理还凑向、封装及信息隐藏等原则设计出相互关联尽可能小的类。减少关联也就是减少了集成、测试和维护时的工作量。

3、可扩展性。可扩展性是只可以增强系统功能而无须改变底层结构，可以改变某一个方面功能而不影响其他部分。

4、可重用性。可重用意味着代码可以在其他系统的组成部分中重复使用，降低整体的成本和提高生产效率。

5、高扇入。高扇入就是说让大量的类是有那个某个给定的类。这就是意味着设计出的系统很好的利用较低层次上的工具类。

6、低扇出。低扇出就是让一个类里少量或者适中的使用其他的类。高扇出说明了一个类使用了大量其他的类，因此可能变得过于复杂。

7、可移植性。可移植性是说应该设计的系统很方便的移植到其他的环境中。

8、精简性。精简就意味着系统没有多余的部分。这样有利于后面的单元测试。

9、层次性。层次性就意味着尽量保持系统各个层次保持可分解，使你能在任何层面观察系统。

10、标准技术。一个系统所依赖的外来的，古怪的东西越多，别人在第一次想要理解它的时候就越头痛。尽量使用标准化，常用的方法，让整个系统给人一种熟悉的感觉。

会话状态模式

崔玉松 — Mon, 16 Nov 2009 13:21:18 +0000

个人觉得会话状态模式其实算不得一种模式，因为无非就两种，而且必须是其中的一种，一种存放在客户端，一种存放在服务端。两者都有风险和优点。

通常将会话保存在客户端是为了获得服务端的高度无状态特性，即服务端可以做到完全的无状态。Java中通常使用传输对象来进行数据传输，因为传输对象可以在网上进行序列化，即使是很复杂的数据也可以进行传输。当然序列化是有风险和代价的，不是所有的序列化数据都能够被反序列化回来，虽然出现反序列化回来的出错的概率很小。

如果使用HTML的话，选择相对多一点，URL参数，隐藏表单域和Cookie，URL对于较小数据量还是比较容易使用的，现代浏览放开了对URL长度的限制，但我们不得不考虑一些古董用户的需求，毕竟IE6及以下版本的浏览器还主导着WEB世界，而且URL过长，也不符合REST原则，更不美观。

隐藏表单域适合于POST方式的请求，POST方式可以避免因浏览器限制URL长度而导致的被截断的问题。隐藏表单域在我曾经的代码中经常使用，主要是为了跟踪和referer的referer，也就是跳转到一个页面之前的原来页面。

Cookie方式是最优争议的一种方式，PHPWind采用了这一种方法，从开发者口中得知，是为了减少服务器的负载，因为服务器不用维护session状态。通过把数据序列化或者加密后以文本方式放到Cookie中，我没有测试过，PHPWind这样做是不是真的能降低服务器的负载，根据我以前的测试，session维护成本对于服务器的影响是微乎其微的，还不如优化一条SQL来得更痛快，更有效，而且放在Cookie中会导致用户请求的流量变大，在很多上下带宽不对称的机房中，这是个严重的问题，比如blogbus之前存放在上海的**机房就是这样。而且为了获得Cookie中的数据还需要进行一些列运算，未必比维护session的成本小，而且会导致严重的安全问题。只要算法是可逆的，就一定能被人破解，何况我等庸人搞的算法。

服务器会话状态最简单的一种就是把会话数据放到应用服务器的内存中，可以将会话数据以会话标识号作为键标识放到内存映射表中，现在很多工具可以做到，比如memcache等key-value 的内存存储工具。

另一种是持久化，持久化也可以分为两种，一种以二进制序列化形式存放，但这样做的缺点是不容易阅读，更新起来成本有点高，如果每个会话都一个文件的话，在高并发的时候还得解决文件系统的巨量小文件查找效率问题。还有一种就是持久化到数据库，这个存放会话的模式，可能会因为维护会话状态而带来巨大的数据库开销问题，而且为了及时清除过期的会话，往往配合触发器来进行。

总结起来每种会话管理都有天生的缺陷，如果能多种结合能够提升一些效率，比如内存缓存配合持久化数据库，就是眼下很多高负载网站正在使用的模式，也许还有其他的更多的模式和方法有待探寻~~

数据源架构模式笔记(一)

崔玉松 — Sat, 31 Oct 2009 04:02:14 +0000

数据源架构模式笔记
一、表数据入口
表数据入口半酣了用于访问单个表的或视图的所有SQL，如CRUD操作，其他代码调用它的方法来实现所有与数据库的交互。
表数据入口很简单，一般包括几个从数据库中干活去数据的查找方法以及更新删除放放风每个方法都将输入参数映射为一个SQL调用并在数据库链接上执行改语句。由于表数据入口用于数据读写，所以通常是无状态的。

使用时机：
1、可以和表模块一起很好的使用，它称身隔一个记录集数据结构由表模块处理。
2、特别适用于事务脚本。
3、通常表数据入口和领域模型很少一起使用，因为数据映射器更好地分离了领域模型和数据库。

二、行数据入口

行数据入口充当数据源中单条记录入口的对象，每行一个实例。行数据入口和单条记录机器相似的对象，如数据库中的一行。在该对象中数据库中每一列变成了一个域。行数据入口一般能实现从数据源类型到内存中类型的任意转换，这种转换很简单。这个模式保持一行中的数据以便客户可以直接访问行数据入口，行数据入口是每一个数据行的良好接口。这种方法尤其适用于事务脚本。

使用行数据入口通常非为两步：第一步是否真的需要用入口；第二步，是使用行数据入口还是表数据入口。

行数据入口能和数据映射其一起配合使用，尽管这样看起来有点多此一举，当行数据入口从元数据自动生成，而数据映射器由手动实现时，这种方法会很有效。

如果把事务脚本和行数据入口一起使用，可能会发现业务逻辑在多处脚本中重复出现，这些逻辑可能在行数据入口中有族谱那个，不断移动这些逻辑会使行数据入口演变成活动记录，活动记录很好，因为他减少了业务逻辑中的重复。

《企业应用架构模式》笔记一

崔玉松 — Fri, 09 Oct 2009 12:42:50 +0000

企业应用

定义：企业应用一般都涉及到持久化数据。

企业应用一般都涉及大量数据

企业应用还涉及很多人同时访问

企业应用还涉及大量操作数据的用户界面屏幕。

企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。（技术多样化，协议多样化）

可伸缩性：

响应时间

响应性

等待时间

吞吐率

负载

负载敏度

效率

领域逻辑组织方式：

1.事务脚本
2.领域模型
3.表模块

服务层：

表现逻辑和领域逻辑之间的交互完全通过服务层，就像应用程序API一样。
如果确实需要，使用最小化的服务层

映射到关系数据库：

1. 为查询语句返回的每一行产生一个它的实例，种种行数据入口就行是面向对象方式来看待数据。
2.许多环境提供记录集，这种表和数据行的一种通用数据结构，用来模拟数据库的表格属性。
如果使用记录集，对于数据库的每个表只需要一个对象来管理。

并发：

解决方案有两个，一个是隔离，一个是不变性
隔离是学习操作系统分配内存的方式，让一个单元只允许一个进程访问
只有共享数据可以被修改的情况下并发问题才会出现。

事务属性：

1.原子性在事务里面所有的动作要么全部完成，要么全部回滚
2.一致性在事务开始和结束的时候，所有的资源要保持一致
3.隔离性在事务完成之后，他的结果对于其他事务才是可见的
4.持久性已提交的事务必须是可持久性的，即任何崩溃都是可以保存下来的

事务资源：

定义：用事务来控制并发的过程
长事务：跨越多个事务请求的事务
请求事务：在请求开始时启动，在请求结束时完成的事务
延迟事务：在外界事务读取或加载完成时，启动的事务，即在更新时才启动的事务

事务建议：

1.使用事务的时间应尽可能的短，尽量避免长事务，因为事务进行时间越长，锁定的东西越多，
在没有任何并发控制的情况下，事务时间越长越有机会导致数据的不一致，造成事务的无效回滚，使用延迟事务能够提供事务的性能。
2.使用事务时应该清楚的知道锁定的到底是什么，对于数据库来说，锁定的是被访问的行级数据。
3.如果一个事务要求锁定的行数超过数据库最大可支持事务锁定，那么会上升为表级锁，即锁升级。锁升级显然对并发造成很大的影响。
这也是为什么不能在领域层超类型级别上使用“对象”表的原因。
4.尽可能的减少事务隔离

事务隔离级别（由低到高）：

1.读未提交
2.读已提交
3.可重复读
4.可串行化

业务事务和系统事务

系统事务：关系数据库系统和事务监视所支持的事务
业务事务：业务事务是保证用户操作行为完整的事务

离线并发控制模式：

1.应该尽可能让事务系统自己来处理并发问题。
这样做会损失部分系统伸缩性
2.乐观离线锁
优点：易于编程实现，提供最好的灵活性
缺点：只能在提交数据时才发现事务将要失败
3.悲观离线锁：
优点：尽可能早的发现错误
缺点：不利于编程实现，丧失部分灵活性

应用服务器并发：

1.显式多线程
缺点：构建复杂，难以调试
2.每个会话一个进程，配合进程池来提高效率
3.每个会话一个线程，线程崩溃可能会导致整个进程垮掉
4.中间层屏蔽，比如J2EE中的EJB