DeepFashion:服装公开数据集

Large-scale Fashion (DeepFashion) Database
Large-scale Fashion (DeepFashion) Database

DeepFashion 是香港中文大学开放的一个 large-scale 数据集。包含 80 万张图片,包含不同角度,不同场景,买家秀,买家秀等图片。

每张图片也有非常丰富的标注信息,包括 50 种类别,1000 种属性,Bbox,特征点。

还有约 30 万的不同姿势/不同场景的图片 pairs。

实际上 DeepFashion 是由4个子集组成的。它们分别是:

1. Category and Attribute Prediction Benchmark

这个子集是用来做分类和属性预测的。共有 50 分类标记,1000 属性标记。包含 289,222 张图像。每张图像都有 1 个类别标注,1000 个属性标注,Bbox 边框,landmarks。数据集下载后可以直接使用。

 Category and Attribute Prediction Benchmark
Category and Attribute Prediction Benchmark

2. In-shop Clothes Retrieval Benchmark

这个是卖家秀图片集,每个商品 id,有多张不同角度的卖家秀,放在同一个文件夹内。7982 件商品,共 52712 张图像,每张图片都有 463 中属性,Bbox,landmarks,以及店铺描述。数据集下载后解压需要密码,密码需要邮件联系作者获取。

In-shop Clothes Retrieval Benchmark
In-shop Clothes Retrieval Benchmark

3. Consumer-to-shop Clothes Retrieval Benchmark

这个子集是卖家秀买家秀对应的数据集,每个商品id对应的文件夹中包含一张卖家秀和几张买家秀。33 881 种商品,共 239 557 张图片。每张图片都有 Bbox,303 种属性,以及来源说明(卖家,买家)。数据集解压同样需要密码。

Consumer-to-shop Clothes Retrieval Benchmark
Consumer-to-shop Clothes Retrieval Benchmark

4. Fashion Landmark Detection Benchmark:

这个子集主要是做 landmark和 Bbox 用的,包含 123 016 张图片,每张图片都有 landmarks 和 Bbox 的标记,还有类别标注(上衣,下装,全身),以及姿态(正常姿势,大幅度姿势等)信息。数据集可直接使用。

Fashion Landmark Detection Benchmark
Fashion Landmark Detection Benchmark

Google 机器学习数据库:SageDB

近日,Google 联合 MIT、布朗大学的研究人员共同推出了新型数据库系统 SageDB,并撰写了一篇论文详述 SageDB 的设计原理和性能表现。他们在论文中提出了一个观点:学习模型可以渗透到数据库系统的各个方面 ——

基于机器学习的组件可以完全取代数据库系统的核心组件,例如索引结构、排序算法,甚至是查询执行器。

在 17 年的论文中,谷歌研究团队尝试通过实验论证:与基于缓存优化的 B-tree 结构相比,使用神经网络在速度上可以提高 70%,并且大大节省了内存。“机器学习模型有可能比目前最先进的数据库索引有更显著的好处”。而今天我们要介绍的 SageDB,就是研究团队在该研究基础之上得出的更进一步的成果。

SageDB 背后的核心思想是构建一个或多个关于数据和工作负载分布的模型,并基于它们自动为数据库系统的所有组件构建最佳数据结构和算法。我们称之为『数据库融合』的这种方法,将使我们能够通过将每个数据库组件的实现专门化到特定的数据库、查询工作负载和执行环境来实现前所未有的性能。

SageDB Overview
SageDB Overview

数据湖概念与应用

日前,IBM 发布博文,从数据湖的定义,数据湖的优势,数据湖的演变,数据湖的应用等方面,多角度的阐述了近期日渐火爆的『数据湖』概念。

基本概念

  • 数据仓库:数据仓库是一种存储架构,旨在保存从多个数据源提取的数据,这些数据源包括操作数据存储、事务数据存储,以及企业内的部门数据集市。数据仓库将数据组合为一种聚合、摘要形式,适合于进行企业级数据分析以及针对业务需求定制报告。
  • 数据湖:数据湖是一种存储库,它以原生格式保存大量原始数据或细化的数据,以供按需访问。这个词有时与 Apache Hadoop 对象存储有关,但数据科学家越来越多地开始使用数据湖这个词来描述任何具有不明确的模式和数据需求的大型数据池。分析师仅在查询数据时定义这些参数。
  • 数据沼泽:数据沼泽是一种设计不良、未充分归档或未有效维护的数据湖。这些缺陷损害了检索数据的能力,用户无法有效地分析和利用数据。尽管数据已经存在,但如果没有上下文元数据,数据沼泽就无法检索数据。

为什么我们真的需要数据湖?

  • 用作原始数据存储库来满足合规和审核用途(例如录音和录像、文档扫描、文本和日志文件)。
  • 作为一个平台,供数据科学家和分析师访问结构化和非结构化数据来进行验证,并在沙箱中运行新的分析模型。
  • 作为一个平台,集成来自操作或事务系统的实时数据,并越来越多地集成来自 IoT 设备的传感器数据。

数据仓库提供的聚合和摘要数据对大部分 BI 用户已足够。数据湖的用户可以是审核人员、专业分析师和数据科学家(占少数)。有什么其他令人信服的让企业选择创建数据湖的原因?因此,了解数据湖与数据仓库有何不同是值得的。

数据仓库与数据湖之间有何区别?

数据仓库是一种具有正式架构的成熟的、安全的技术。它们存储经过全面处理的结构化数据,以便完成数据治理流程。数据仓库将数据组合为一种聚合、摘要形式,以在企业范围内使用,并在执行数据写入操作时写入元数据和模式定义。数据仓库通常拥有固定的配置;它们是高度结构化的,因此不太灵活和敏捷。数据仓库成本与在存储前处理所有数据相关,而且大容量存储的费用相对较高。

相较而言,数据湖是较新的技术,拥有不断演变的架构。数据湖存储任何形式(包括结构化和非结构化)和任何格式(包括文本、音频、视频和图像)的原始数据。根据定义,数据湖不会接受数据治理,但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比,数据湖缺乏结构性,而且更灵活;它们还提供了更高的敏捷性。在检索数据之前无需执行任何处理,而且数据湖特意使用了便宜的存储。

尽管有这些优势,但数据湖在安全、治理和管理方面仍需要完善。但是,它还有一个重要优势,这也是一个富有吸引力的驱动因素。

机器学习和深度学习都是驱动因素

在采用数据湖的原因中,讨论最少但或许最有吸引力的是数据挖掘和分析中越来越多地开始采用机器学习和深度学习技术。传统搜索和分析方面的软件审核是一个成熟领域,但用于数据挖掘和分析的机器学习和深度学习技术的软件审核还处于起步阶段。

语音转录、光学字符识别、图像和视频识别等等,现在经常使用机器学习或深度学习技术。数据科学家需要访问原始的非结构化数据来训练这些系统,以便执行系统验证,并确保审计跟踪。类似地,深度学习执行数据挖掘等任务来查找维度与时序数据之间的模式和关系。

另一种深度学习应用是提取以前无法访问的、无法通过查询来检索的数据。这些数据称为暗数据,是本系列下一期的主题。在数据挖掘和分析应用中,机器学习和深度学习的出现是迁移到数据湖架构的一个非常有吸引力的理由。

数据湖的优势

  • 轻松地收集和摄入数据:企业中的所有数据源都可以送入数据湖中。因此,数据湖成为了存储在企业内部服务器或云服务器中的结构化和非结构化数据的无缝访问点。通过数据分析工具可以轻松地获得整个无孤岛的数据集合。此外,数据湖可以用多种文件格式存储多种格式的数据,比如文本、音频、视频和图像。这种灵活性简化了旧有数据存储的集成。
  • 支持实时数据源:数据湖支持对实时和高速数据流执行 ETL 功能,这有助于将来自 IoT 设备的传感器数据与其他数据源一起融合到数据湖中。
  • 更快地准备数据:分析师和数据科学家不需要花时间直接访问多个来源,可以更轻松地搜索、查找和访问数据,这加速了数据准备和重用流程。数据湖还会跟踪和确认数据血统,这有助于确保数据值得信任,还会快速生成可用于数据驱动的决策的 BI。
  • 更好的可扩展性和敏捷性:数据湖可以利用分布式文件系统来存储数据,因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格,因此天生具有更高的灵活性,从而提高了敏捷性。数据科学家可以在数据湖内创建沙箱来开发和测试新的分析模型。
  • 具有人工智能的高级分析:访问原始数据,创建沙箱的能力,以及重新配置的灵活性,这些使得数据湖成为了一个快速开发和使用高级分析模型的强大平台。数据湖非常适合使用机器学习和深度学习来执行各种任务,比如数据挖掘和数据分析,以及提取非结构化数据。

数据湖的演变

与其说数据湖在演变,不如说是一种技术融合。数据仓库是从其前身(关系数据库)演化而来,迈出了革命性的一步,但对于数据湖和数据仓库,我们不能这么说。

数据湖汇集了各种技术,包括数据仓库、实时和高速数据流技术、数据挖掘、深度学习、分布式存储和其他技术。但是,人们感觉数据湖在专业数据科学家或分析师中拥有有限的用户群。另一种常见的误解是,将数据湖概念与一种特定的支持技术(比如 Hadoop)联系起来。

数据湖概念拥有比任何一种基础技术更大的潜力,而且还在不断演化,供应商也在不断在添加特性和功能。潜在的增长领域包括:

  • 架构标准化和互操作性
  • 数据治理、管理和综合处理
  • 整体数据安全性

与大部分不断演化的技术一样,供应商之间的竞争和业务驱动因素扩大了应用边界。数据湖在诸多数据存储技术中获得广泛接受只是时间问题。

数据湖的应用

数据湖可以帮助解决电子医疗记录 (EMR) 的互操作性问题。联邦任务的意图是,通过使用 EMR,让医生能够访问跨多个系统的患者医疗记录,并在各个医院之间轻松地交接患者护理。在实际中,许多记录(包括保险索赔和临床数据)要么无法互操作,要么具有机器不可读的数据格式。在检索前,数据湖会存储任何格式的记录。所以,患者记录可能也包含医生手写的笔记、医学图像等。随着医疗领域中越来越多地开始使用医学设备遥测和 IoT,数据湖还能够从实时数据流中提取和存储数据。

银行和金融业通常会处理多个数据源。它也会处理高速的交易数据(从股票市场到信用卡)和其他银行交易。银行和金融机构经常存储法律和其他文档,以满足合规性和审核需求。数据湖非常适合存储这些混合数据格式,并以数字方式存储旧有数据,以方便检索。数据湖充当着一个敏捷平台来摄入多个数据流,以供这个行业垂直领域中的大量分析工具进行使用。

Apache Kylin 实践:链家数据分析引擎

Apache Kylin™ 是一个开源的分布式分析引擎,提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由 eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的 Hive 表。

Apache Kylin
Apache Kylin

其特征包括:

  • 可扩展超快 OLAP 引擎:Kylin 是为减少在 Hadoop/Spark 上百亿规模数据查询延迟而设计
  • Hadoop ANSI SQL 接口:Kylin 为 Hadoop 提供标准 SQL 支持大部分查询功能
  • 交互式查询能力:通过 Kylin,用户可以与 Hadoop 数据进行亚秒级交互,在同样的数据集上提供比Hive更好的性能
  • 多维立方体(MOLAP Cube):用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体
  • 与 BI 工具无缝整合:Kylin  提供与BI工具的整合能力,如 Tableau,PowerBI/Excel,MSTR,QlikSense,Hue 和 KXCY-BD-VIZ(跨象乘云™大数据可视化探索平台)

其他特性还包括:Job 管理与监控 / 压缩与编码 / 增量更新 / 利用 HBase Coprocessor / 基于 HyperLogLog 的 Dinstinc Count 近似算法 / 友好的 Web 界面以管理,监控和使用立方体 / 项目及表级别的访问控制安全 / 支持 LDAP、SSO 等。

同时,伴随链家业务线的拓宽和发展,以及数据生态的建设,数据规模快速增长。从 2015 年大数据部门成立至今,集群数据存储量为 9PB,服务器规模为 200 台 +。与此同时,数据需求也随着业务的发展落地不断增长,如统计分析、指标 API、运营报表等,不同业务需求差异较大,维度越来越多,需要定制化开发。面对数十亿行级别的数据,低延迟响应的特性,保障服务稳定、数据准确,链家的数据分析引擎经历了如下的发展历程。

链家 OLAP 平台及 Kylin 使用

链家 OLAP 平台结构(By 邓钫元),于 2016 年底搭建。Kylin 采用集群部署模式,共部署 6 台机器,3 台用于分布式构建 Cube,3 台用于负载均衡查询,query 单台可用内存限制在 80 G。同时,计算集群一旦运行大任务,内存压力大的时候,Hbase 就会性能非常差,为避免和计算集群互相影响,Kylin 集群依赖独立的 Hbase 集群。同时,对 Hbase 集群做了相应的优化,包括:读写分离、SSD_FIRST 优先读取远程 SSD、并对依赖的 HDFS 做了相应优化。

由于 Kylin 只专注预计算,不保存明细数据,对于即席查询和明细查询,通过自研 QE 引擎实现,底层依赖 Spark、Presto、HIVE,通过特定规则,路由到相应查询引擎执行查询。多维分析查询,由 Kylin 集群提供查询服务,可实现简单的实时聚合计算。

当前 Kylin 主要查询方为指标 API 平台,能根据查询 SQL 特征,做相应缓存。指标 API 作为数据统一出口,衍生出其他一些业务产品。使用统计,如下:Cube 数量 350+,覆盖公司 12 个业务线。Cube 存储总量 200+ TB,数据行万亿级,单 Cube 最大 40+ 亿行。日查询量 27 万+,缓存不命中情况下,时延 < 500ms (70%), < 1s (90%),少量复杂 SQL 查询耗时 10s 左右。

Kylin 应用场景及使用规范

适用场景:数据规模大,非实时,目前能支持小时级别;维度组合和查询条件组合在可预见的范围内;查询条件扫描范围不会太大;不适合需要大范围模糊搜索排序的场景(类似 Search)。 如何能规范的使用 Kylin 很重要,在 Kylin 建设初期,踩过很多坑。并不是程序的错误,而是未能详细了解 Kylin 使用流程及规范,逐渐摸清积累了一些经验,沉淀到公司 wiki,供相关人员参考。大致如下:

一、维度优化,预计算的结果需要存储到 Hbase,且支持实时查询,因此,在配置维度时,要考虑到存储和查询的优化。包括:维度的编码,根据维度的值类型,选择合适的存储类型,可节省空间,加快 Hbase scan 效率;可根据业务需要,对维度进行分片存储,增加查询的并发度,缩短查询时间;基数允许范围内的维度,尽量采用字典编码;对于分区字段,一般格式为 yy-MM-dd hh:mm:ss,若只需要细化到天级别,可保存为数字类型 yyMMdd,极大降低维度基数。

二、根据 Hbase 的查询特性,rowkeys 是由维度组合拼接而成,因此要考虑到以后查询场景:对于查询频繁的维度,在设置 rowkeys 时,优先放在前面。

三、维度组合优化,由于维度的组合影响最终的数据量,因此如何能减少维度的组合,是 Cube 配置时所要考虑的。根据业务需要,及 Kylin 支持的特性,可进行的维度组合优化有:使用衍生维度,只物化维度表的主键,牺牲部分运行时性能进行实时 join 聚合;使用聚合组,将相关维度内聚成一组,并在聚合组内,根据维度的特征,配置强制维度、层级维度、联合维度。聚合组的设计可以非常灵活,例如,高基数的维度,可以单独一个 group。

四、及时清理失效数据。由于构建过程出错或者集群故障,会导致一些垃圾文件,随着时间积累的一些无用 segment,不但占用存储空间,增加 namenode 内存压力,以及占用 Hbase、HIVE 及 Kylin 元数据空间,因此需要定期清理掉,保持存储环境干净。

应该实时监控集群状态,重点关注 Cube 构建和查询的低延迟,不断优化数据模型及 Cube 的设计和存储,根据用户真正的需求,在存储、构建及查询性能间找到最佳的平衡点。

教学工具:迷你电影数据库

通常学习了 Python 入门课程之后,初学者会开始思考如何编写一个很酷的 Python 程序,来演示一些高级的语言能力,比如使用网页抓取或数据库操作。在《手把手搭建迷你 IMDB 数据库》教程(中文翻译)中,Tirthajyoti Sarkar 向我们展示了如何使用简单的 Python 库和其内置功能来获取网上的电影信息,并将它们存储在本地的 SQLite 数据库中,之后还可以查询电影数据并进行数据分析。我们可以将它看作是一个构建自己迷你 IMDB 数据库的项目!

这种类型的数据工程任务 —— 从网上收集数据并建立与数据库的关联;通常是数据分析项目的第一步。在做任何预测建模之前,你都需要掌握这一步骤。这一步的数据通常是凌乱且非结构化的,也就是说,没有能够帮你一步到位完成这些工作的方案或代码库。因此,你必须从网页上提取数据,检查它的结构,并构建你的代码,以便成功地抓取它。具体来说,这个演示程序将展示以下功能的用法:

通过在本地部署电影数据库,学生能更为贴近真实的业务需求的《数据库设计》逻辑,并基于该数据库实现高级机器学习,部署推荐系统,数据分析,算法模型及算子优化实践,并进一步完成端到端的网络大数据分析项目流程。

GitHub地址项目GitHub地址

Hive+HBase集成模型

伴随着大数据的应用,Google, 亚马逊,国内 BAT 等正在彻底的颠覆我们的生活。作为消费者,我们期望智能的应用程序能预知,建议,预测我们的每一个行为;筛选数百万种可能性后向我们推荐最适合我们的选择;借助智能应用在无尽的可能中挑选出最具个性化的配搭。—— 如此的个性化配搭要求系统存储并在短时间内分析处理海量数据源,这便是 Hadoop 诞生第一天所要完成的使命。

同时,大数据企业正在使用更为广泛的数据处理技术来构建具有深度分析的应用程序,常见的模式包括:

  • 使用 HBase 作为在线操作数据存储,以便快速更新热数据,例如当前的小时/分钟等
  • 使用 Apache Phoenix 直接对 HBase 执行操作查询
  • 使用标准 ETL 模式在 HBase 到 Hive 表中将数据老化(Aging)
  • 使用 Hive 执行深层次的 SQL 分析

Hive 和 Hbase 有各自不同的特征:

  • Hive 是高延迟、结构化和面向分析的
  • Hbase 是低延迟、非结构化和面向编程的
  • Hive 数据仓库在 Hadoop 上是高延迟的

Hive 集成 HBase,可以有效利用 HBase 数据库的存储特性,如:行更新和列索引等。在集成的过程中需要注意维持 HBase jar 包的一致性。Hive 集成 HBase 需要在 Hive 表和 HBase 表之间建立映射关系,也就是 Hive 表的列和列类型与 HBase 表的列族及列限定词建立关联。每一个在 Hive 表中的域都存在与 HBase 中,而在 Hive 表中不需要包含所有 HBase 中的列。下图显示了 Hive 与 Hbase 集成的几种常见集成模型:

hive-hbase-integration
hive-hbase-integration

企业正在使用广泛的数据深度分析架构组合,如:Apache HBase,Apache Hive,Apache Phoenix 等来处理对大量数据集的当前数据和分析的快速更新,这些数据集都存储在 HDFS 中,以实现闭环分析系统。

扩展阅读:Hortonworks HBASE AND HIVE – BETTER TOGETHER

MySQL数据库管理与性能调优(90学时)

本课程面向初次接触数据库的学生,通过直观易懂的MySQL数据库,了解数据库基本原理与操作。MySQL是全球第二大企业级数据库系统,具有安全控制、数据对象操作、数据备份恢复等主要功能。这些功能保证了MySQL作为企业级数据库的可靠性、高性能和可维护性。本课程针对MySQL系统管理进行详细介绍,包括系统的安装、配置、数据库及表的创建、系统安全管理、数据库备份恢复、系统日志管理等方面的知识。学员通过本课程的学习,可以系统性了解如何正确安装MySQL数据库、创建和执行备份策略、创建安全的存储过程以更新和访问数据等等,还可以掌握MySQL数据库的安全知识、了解如何为用户正确分配访问权限、设置资源限制及访问控制等。在管理使用过程中,管理员将不可回避地遇到如何管理MySQL应用程序不断增长的数据、如何监控、诊断问题区域并调节MySQL以优化性能、如何配置、使用集群等诸多问题,管理员应通过这些高级方法来确保数据库的可靠性、高性能和可维护性。本课程还介绍了性能调优方面的知识,包括如何充分利用MySQL增强特征来编写查询语句以处理查询和索引,教授学员如何评估架构、使用调优工具、配置数据库性能、调优应用程序和SQL代码、调优服务器、检查存储引擎等常用调优知识。

数据库基础(90学时)

在当今以数据为推动力的经济中,计算机科学和业务课程如果没有数据库和数据管理方面的课程,就不能说是完善的。应了解计算机如何组织、使用和处理数据,这对于了解如何使用我们掌握的数据以及如何寻求创新方式以更好地管理和使用数据都至关重要。数据库出现由来已久,不过总会出现新的内容需要学习。《数据库基础》是第一门入门课程,本课程向学生介绍基本关系数据库概念。本课程向学生教授关系数据库术语以及数据建模概念,构建实体关系图 (ERD) 及映射 ERD 等知识。使用 Oracle SQL Developer Data Modeler 构建 ERD,使用结构化查询语言 (SQL) 与关系数据库进行交互并处理数据库中的数据。使用 Oracle Application Express 提供动手参与的实践活动。利用基于项目的学习技术,学生将创建和处理项目,这对他们提出了为企业或组织设计、实施和演示数据库解决方案的挑战。本课程通过一个学术数据库/学校信息数据库的建模与创建的综合案例,为项目贯穿整个课程的多个知识点。同时也包含了多个包括:电子图书馆,酒店,保险,零售,租赁等多个行业的业务分析。

数据库设计(90学时)

在本课程中,学生将学习分析复杂的业务方案并创建数据模型 - 组织的信息的概念化表示形式。学生 将实施其数据库设计:使用 SQL创建一个物理数据库。 在此期间会讲解基本的 SQL 语法以及构造有效 SQL 语句的规则。本课程最后是创建一个项目,让学生设计、实施和演示企业或组织的数据库解决方案。本课程最后是创建一个项目,让学生设计、实施和演示企业或组织的数据库解决方案。HealthOne 医疗数据库建模项目为一家专门为医疗行业开发数据库的小型数据库咨询公司,不久前签下了一份合同,为中型医疗保险公司开发数据库应用程序系统的数据模型,以跟踪记录医疗索赔,其中包括患者信息、提供方(医生)信息、患者就诊信息以及医生为患者所开的处方药。需要记录患者姓名、地址、电话、电子邮件等信息,以及每名患者的主治医生、患者保险标识号和保险公司名称。此外,还需记录每名医生的相关信息,例如:专业及其隶属医院、电话和地址等。对于医院本身,需要掌握具体位置和联系方式。同时,还需要在这一特定数据库中跟踪医护人员为每名患者所开的处方,以便确定索赔资格,其中包括所开药品的一些基本信息,从而确保不会与患者的其他处方相冲突。需要了解每种药品的名称、用途以及可能的副作用。最后,该数据库将用于跟踪趋势,并根据累积的数据进行推断预测建模。

数据库建模与编程(90学时)

在本课程中,学生将学习分析复杂的业务方案并创建数据模型 - 组织的信息的概念化表示形式。学生 将实施其数据库设计:使用SQL创建一个物理数据库。 在此期间会讲解基本的SQL语法以及构造有效SQL语句的规则。本课程结合全球快餐连锁行业,人力资源管理,流行音乐行业等项目案例,贯穿数据库设计与建模内容。最后通过OFlix在线租赁综合案例作为本课程的结业最终项目。