1、我们的我们的Virtual Observatory 报告人：傅衍杰 单位：中科院空间中心 时间：2008.08.29outline 1，Why？2，Overview 3，基于SPIDR的体系结构扩展分析 4，思考 5，进一步工作为什么我们需要VO？1，VO的分布式布局满足当前海量数据的需要，而不需要一个单一的大容量主机。2，VO提供的服务（tool）能够对数据（单数据库，多数据库交叉）进行分析（纯数值分析，数值-图形分析，图片分析），而不需要人工计算。3，VO提供各种模式的搜索，使得用户可以快速检索所需的服务和数据，摒弃图书馆检索式的人工低效劳动。4，VO的注册式的动态资源添加方式使得新数据库
2、和新开发的服务在发布即能及时被发现，不会出现存在宝贝而无法发现的现象。5，VO分布式布局能够架构起更廉价快速的计算力6，VO对数据搜索，服务发现，数据分析进行无缝链接（pineline技术），提供“一条龙”服务。7，VO对数据以及图像的虚拟化图像化，使得普通老百姓和孩子可以接触到这些遥远的科学。VO的定义 一个基于internet的集成的在线环境。为用户提供对科学数据的统一接入方法,包括数据发现，搜索，比较，提取等 为用户提供针对服务和工具，实现对数据的分析，作图，模拟 提供数据和资源的注册和自动搜集机制，为分布式网络中的数据和资源的发现提速。提供一个对数据和图像的虚拟观测环境（参见Googl
3、e Earth，搜狗地图）概要性的VO图形表示理解VO前所需要明确的概念 portal=门户，也就是介于用户和数据以及数据分析工具之间的Interface，是一个基于web的集成环境 resource(资源)=data(数据)+service(服务)registry(注册处)=一个保存整个分布式VO资源的元数据的地方，它具有三种特性：对外公开资源元数据 支持对元数据各种模式的搜索 支持对整个VO的资源元数据的搜集、维护、更新 repository(存储处)=一个能够将VO资源（包括数据data和服务service）保存为一种可获取的格式的地方或设备。repository存放的大部分是数据，其次
4、是服务。Overview of VO第一，面向用户，为用户提供数据和元数据的检索，查询，提取接口以及提供数据分析服务展现平台的web 门户。web 门户不仅允许数据和服务的提供者注册其数据和服务的描述，还允许用户通过web门户提供的不同搜索方式，包括基本和高级搜索模式，来进行元数据搜索，以获取用户需要的资源，同时门户将为用户检索所得的数据，根据用户的进一步重排工作流，无缝把检索的数据输出接入到数据分析工具(service)，进行进一步的分析第二，以可检索格式存储元数据，支持元数据的搜索,能自动完成对其他的分布式的节点上已公开的数据和服务的描述信息的搜集的Registry。Registry使用支
5、持检索的编码格式把整个vo的可用数据和服务的描述信息完整的保存在数据库中，用以支持用户从门户发出的搜索请求，同时由于VO里资源和数据的分布性和动态性，所以往往出现新资源在分布式VO中可用之时，其元数据仅仅存于发布节点的本地Registry，而其他节点的Registry没有发现该资源。故，Registry还应具有自动搜集其他节点上Registry的新的可用资源功能。第三，以可接入可获取的格式存储VO中的数据和服务的repository。repository是既是一个可存储数据和服务的地方，也是一个提供外界对这些数据和服务接入操作接口的设备。每一个资源不仅仅是保存在repository里，同时还对
6、应配套有一个描述信息（Description）基于SPIDR的VO架构的扩展分析SPIDR（Space Physics Interactive Data Resource）是为美国国家地球物理数据中心（NGDC）与俄罗斯地球物理数据研究中心（CGDS）合作开发的科学数据共享服务系统。SPIDR 是一个分布式的数据库和应用服务网络。通过建立SPIDR，实现对历史上的空间天气数据的选择下载，虚拟化，并重新建模。设计SPIDR的目的在于，允许一个对太阳地球物理感兴趣的用户，智能地获取和管理历史上的空间物理数据，并将环境模型和空间天气预报归一起来。SPIDR体系结构在VO基本架构上，增加了两个的关键技
7、术概念：一个叫做“data basket”的概念和一个叫做“space weather event”的概念。“data basket”在用户面前就是一个盒子，一个表格，该盒子里展现了不同的数据库名称，这些数据是分布式的，并不是在同一个机器上的。用户可以选择一个数据库，然后选择多个不同的参数，进行查找后，数据再分别从不同的节点的数据库上返回到这个盒子，对于用户而言，仿佛此刻所有用户需要的数据就装在这个虚拟的盒子里，然后用户可以根据需要，传递到数据作图工具，进行联合作图，或者下载space weather event允许用户通过模糊的语义来指定自己所需要的空间，时间和参数标准或者具体准确的词汇来挖
8、掘数据文档，并获取一个排行的空间天气时间列表，该列表按照排序的序列，从最优到最差的顺序来显示符合用户要求的数据文档。第一部分：门户web-portalWeb portal等同一个介于user和web service之间的代理商。有三大主要功能：第一，对catalog-level（XML schema)的元数据（Metadata）进行管理维护，支持对catalog-level级别的元数据（Metadata）进行搜索。第二，获取，提取用户所要求的数据，返回给用户。第三，提供数据的挖掘和分析，数据虚拟化和可视化接口Protal是Registry（一存储数据和服务的元数据的地方）和Repository
9、（存放数据和服务的地方）的纽带，对于Registry而言，Portal是一个元数据接入的接口，对于Repository而言，Portal是服务展示的平台。第二部分：RegistryRegistry可以分为full Registry和local Registry第一，Full Registry 包含了整个vo所有节点上的资源（Resource）的信息，而且通常是可检索查询的(searchable)，但是Full Registry却不对外公开（publishing）。所以又叫searchable full Registry（主节点）第二，Local Registry 仅仅包含整个VO某个节点上的资
10、源（Resources）的一个子集，所有的对外公开的Registry（publishing Registry）都是local Registry。（从节点）Registry按照功能分成三个模块：1，publishing(对外公开模块)：可在线通过Portal手工的增加、修改、删除、下载SPIDR系统中service和data的元数据（SPIDR没有提供）Registry提供API接口用以支持对元数据进行查找、插入、删除、更新Registry里的元数据分为catalog-level和granule-level。前者是使用xml数据库以可检索的xml格式保存，后者是使用关系数据库保存。可以把其元数据
11、（Metadata）保存到自己建立的数据库中去，如果外界需要下载的时候，再把需要下载部分查找出来，然后按照某种特定格式写成一个文件，再提供该文件URL给外界。架构的第二部分：Registry continue2，Search（搜索模块）SPIDR的搜索已经把搜索能力扩张，通过使用REST web service API支持对一个指定的元数据（Metadata）中的某一个元素的查询，比如针对provider，title等。REST（Representaional state transfer）是一个web-service体系结构风格。和SOAP（simple Object Access Prot
12、ocol）相比，SOAP更加复杂，SOAP需要一个server端(提供数据)，需要一个client端（Access数据），但是SOAP功能更强大。元数据是用xml文档并遵循IVOA所制定的规则来表达的。使用规则格式的xml来保存元数据（Metadata）的原因是，使用了XML数据库对元数据入库，该能够为机器所识别，从而实现搜索。提供给外部一个搜索接口，支持搜索元数据和 支持依据资源ID，获取某一资源的描述信息，或者支持直接获取该Registry（如果把Registry也看成一种资源的话）的描述信。通过搜索，搜索接口将会接收用户输入的搜索条件，然后返回一个包含该资源描述信息的xml格式文档。搜索
13、功能支持多种工作模式：基于物理参数的搜索，比如时间跨度，温度等基于字符串的搜索架构的第二部分：Registry continue3，Harvest功能自动收集其他的对外公开（Publishing）的Registry里的对resource的描述信息，简称收割（Harvest）。收割（Harvest）指代一个Registry从另外一个Registry上去搜集资源的记录。通常，由于全局可检索（full searchable）的Registry需要获得整个分布式VO的资源信息，所以full searchable Registry需要搜集其他Registry上的资源信息。又或者，两个Registry之间
14、需要同步资源记录的时候也要使用到收割。只有可检索的Registry才可能有harvest功能，因为可检索的Registry，既然要被用户检索，说明它对整个分布式的vo里的资源，包括数据和服务，都是了解得一清二楚的，也就是无论这些资源分布在何节点，本地节点或者是远程节点都能获得它们的元数据。要实现这个目标就必须具有Harvest的功能也就是具备从自己的Registry上去搜集其他Registry上搜集其他未知资源的元数据的能力。架构的第三部分：RepositoryRepository可以理解为一个能够将VO资源（包括数据data和服务service）保存为一种可获取的格式的地方或设备。repos
15、itory存放的大部分是数据，其次是服务。由于VO里的数据是采用某一个数据模型的，比如 common data model，SPACE，PDS等数据模型，使用数据模型的作用，就在于能让数据变得，在其他中间件进行数据分析时，数据能为这些中间件所用。同时，也因为数据模型的采用，导致每一个资源不仅仅是保存在repository里，同时还对应配套有一个描述信息（Description）。描述信息有两种存放方式：第一，和自己对应的资源一起，存放在同一个repository里。第二，另外开辟一个新的repository，专门存放资源的描述信息（Description）。但是Repository的描述信息与
16、存放在Registry的元数据关系是：1，虽然资源的元数据，是同个登记注册其描述信息得来的。但是元数据有着其特定的表示格式。使用xml文件，保存在xml数据库中，还可以被检索。而资源描述信息（Description）仅仅是对资源的字符描述。不能等同于资源元数据（Metadata）2，描述信息（Description）可以转化为元数据（Metadata），必须通过一个分析器，格式化成元数据（Metadata）的格式Registry里的有一个机制，就是Registry自动搜集注册资源的元数据，其实就是通过对进入repository的新资源的描述信息（Description）的搜集，然后使用分析器将
17、该资源的描述信息格式化为标准的元数格式。我们应从SPIDR吸取和摈弃什么？，SPIDR系统基本上包含一个标准VO的要素：用户，向用户展现应用的Portal，分布式网络中主节点的Registry，分布式网络中主节点的Repository，分布式网络中从节点的数据和服务。SPIDR的元数据获取，管理和维护，是自动的，不需要人工进行注册，人工进行更新。（吸取）但是SPIDR没有把各个从节点上的资源（数据和服务），转化为更高的模式（Registry+repository），所以SPIDR进行元数据搜集的时候，只能请求各个节点提供其资源的描述信息，而不能直接要求各个节点提供资源的元数据，主节点获得资源描
18、述信息再通过分析器来格式化成元数据格式，再把元数据入库。（X），SPIDR系统中Portal模块里的元数据搜索和Registry模块里的搜索是相互关联对应的，protal的元数据搜索是Registry的搜索功能的对用户的应用展现。SPIDR虽然提供了基于字符串的搜索模式和基于物理参数和基站的搜索模式，还有基于时间跨度的搜索模式 不难看出，其所使用的搜索机制：仍然是把用户的搜索限制条件转化为SQL搜索语句，对数据库进行搜索，但是没有提出一种相关性排序算法，使得用户希望得到的结果排在前列。更没有使用到类Google和Baidu一样的搜索引擎机制。（X）3，SPIDR的元数据搜索过于简单，通过使用发
19、现，其新意仅仅在于提供了多种搜索模式但是返回的结果仅仅是表达在网页上的资源描述信息，比如如果查到几个相关的数据库，仅仅返回一堆文字，这些文字描述了这几个数据库。也没有提供引用几个数据库的链接，更没有提供对这些数据库的数据进行搜索、分析的操作。（X）4，SPIDR采用的data basket理念：把多个分布式的数据库集合在一起，屏蔽了数据库分布式的特点，用户以为是在同一个服务器上，这就是虚拟化的效果（吸取）SPIDR做到把多个数据库集成在一个basket里，支持选定单个数据库后，再展现数据库中表项，再选定表项以时间轴作图。（吸取）我们希望多个数据库可以并行的进行多个数据库查询，同时的提取多个数据
20、库的数据文件并把它们一起打包下载，同时把多个数据库中不同的数据联合进行作图（SPIDR没有做到，但是我们希望做到）（扩充）记录用户的搜索记录，SPIDR是用于方便用户添加数据。但是我们可以拓展，把搜索记录下来进行统计，比如，用户输入的关键词是什么，选择的数据库是什么，频率是多大，方便搜索结果排序（不但Metadata搜索，连数据库和数据库的项目展现都进行排序），为此必须考虑出一个搜索结果相关性排序算法，针对科学数据却最能反应用户需求的算法。（扩充）单从数据搜索到作图服务来看，SPIDR实现了pineline技术。但是SPIDR的服务仅仅限于作图而且是以时间为x轴，其中一个参数作为y轴作图。我们
21、可以拓展到，任由用户选定两个参数进行作图。我们还准备将pineline技术不仅仅用于作图服务，还用于其他服务，比如图像分析。需要建立某一个数据库和服务的关联关系，当用户选定了该数据库的数据，那么自动排出对应的服务，并自动把数据pineline到该服务去。（扩充）basket里显示的数据库是实时变化的。因为允许一个分布式的数据掉线，或者崩溃了，但是这个时候该数据库就不应该在basket里显示（吸取）5，坚持分布式的主从节点模式。6，在门户增加对Registry的操作，允许资源提供者，能够自主添加，删除，更改资源到VO（集合大众的智慧）一些值得深思和完善的技术问题1，对Registry的元数据搜索
22、除了：基于字符串、基于物理参数、基于station、基于时间跨度的四种搜索模式，还能基于数据库中的科学数据特点，提出一些有价值的基于XX的搜索否？2，对上述四种查询可以归类：基于参数，station，时间跨度的对Registry的元数据搜索，是精确查询。都是对数据库中的项的某一个值，采用SQL语法来表达查询。基于字符串的查询，是对Registry的Metadata里的description项的文字进行字符串匹配的查询，是串匹配算法+SQL语法的结合。我们还可以增加对search log的辅助查询，还可以增加Top N热门的资源和Top N热门的查询词，对于这些我们把查询结果缓存到search
23、log里，一旦出现，直接出结果3，针对元数据搜索能否提出一种针对科学数据搜索特定环境下更高效的搜索排序算法？（依据资源的引用次数？依据搜索词汇的出现频率？还是？）如何在数学上证明在科学数据特定环境下，你的算法是最优的或者比当前Relevance Scoring 算法优秀呢？4，对data basket实现的一些个人思考：data basket中的数据库列表是实时变化的，如果有数据库新加入或者数据删除，那么应该及时反映在列表的变化上。我所考虑的实现方法是：在Registry的Metadata里，找出：同意加入databasket的数据库。此类数据库的Metadata应包含：数据库类型，数据库所在
24、节点的ip，接入用户名，接入的密码 Registry的Metadata是实时的。每次用户使用data basket的时候，后台在此前自动扫描Registry，提取可用的数据库信息，按固定格式写入到本地的一个文档 data basket 弹出前扫描该文档，输出数据库列表。每一个数据库列表对应一个链接，该链接通过http get&post的方式向该数据库所在的节点发送接入请求，参数为动作ID+用户名+密码，当该数据库所在的节点接收到用户名+密码后，对比自身数据库的用户名和密码，若相同授权接入。返回该节点上数据库的表项上对应的参数名，写到data basket中，此时用户看到一列参数列表用户选定一个
25、或n个参数，提出单参数或多参数作图的请求，再次用http get&post的方式发往该数据库所在的节点，参数为动作ID+用户名+密码+参数名1到n数据库节点接收到作图请求后，提取数据库中的数据以一定格式写入本地文件，再调动作图程序，读取作图数据输入文件，作图生成图片，以http方式再把图片写入网页，返回到用户的Portal界面 5，对Registry的自动Harvest功能实现的一些个人思考：有些资源不是发布在主节点而是发布在从节点上，怎么办？该资源的注册信息仅仅保存在从节点上，而主节点上的Registry没有。那访问的主节点Portal的用户如何能发现并使用这些新资源呢？毕竟此新资源确实存在
26、于VO网络里 这就要求主节点的Registry能够主动实时的搜集整个VO系统里的所有节点的Registry上的资源信息 新增资源又要分成两类问题去思考：a，节点数不变，仅仅是某一节点上的资源改变；对此情况，首先默认该资源的改变已经在其所在节点的Registry里体现（如何保证以后再解决）。主节点设立后台守护程序，检索自己Registry中有关该节点的资源记录的最近日期，把该日期以某一个传输协议（HTTP？）的参数发送到该从节点上去，从节点接收到该参数，激活其检索服务，检索是否存在比此时间更晚的资源登记在册，如果有，则从本地Registry里提取出Metadata，以固定格式写入到文件，再传输到
27、主节点，主节点通过分析器和过滤器确定后以Metadata的标准格式写回主节点的Registryb，节点数改变，新资源在新增加的节点上新节点加入的时候必然是要人工主动的告知主节点和其他节点。只需要提供一个半自动服务，导入新节点的Registry的Metadata即可。又或者主节点有一个VO分布式网络的节点IP列表，新节点加入时，修改该节点列表，主节点发现新节点进入节点列表后，自动动用Harvest功能导入新节点的Registry。6，对针对数据分析、虚拟的服务开发：请问如果你是一个astronomer或者其他Xer，你认为对某一类数据库的数据手工分析时，你什么样的数值计算是反复而有固定计算流程的
28、？如果能发掘这些服务开发点，就很容易实现某些服务和某些数据库的关联，从而实现前面提出的当用户选定感兴趣的数据（单个数据库）之后，VO自动完成“工具发现和pineline”。7，多个数据库的联合并行查询，交叉匹配如何实现？还没想。8,增加计算平台，可以提交计算任务到服务器，由服务器跑，返回结果。（量力而行）9,增加一个针对空间天气数据的查询语言，削减纯SQL语言的繁杂度下一步的工作 1，不断对单个现存几大VO进行分析，通过对不同VO的架构进行比较，通过“吸取好的idea”和“分析不足如何弥补”来丰满以自己的VO设想。2，继续阅读VO里关于某一个部分的技术文章，争取将最先进的技术应用在自己的VO设想中。3，在看文论形成硕士论文的前面的理论部分新想法-分布式多媒体数据库 图像数据库：比如从卫星或者天文台获取一个图片，如何对图片进行匹配，采用特征匹配，比如对于人图片库，采用人脸识别。采用数据挖掘+信息检索的搜索引擎
