科技后时代

据Gartner研究表明，人工智能、物联网等助力下一代商业创新，由此产生大量数据，2020年前企业将使用超过75亿台联网设备。这种转变或将推动从联网汽车、智能无人机到制造、智能零售等下一代科技发展。更多数据需要实时分析，IDC发布的“数据时代2025”研究表明，到2025年，约20%的数据将是实时数据，无需发回到网络中心进行处理。这意味着企业将建立自己的集中式云计算架构，并加强在边缘处理和存储更多数据的能力。

全球创新存储公司希捷研究认为，在边缘计算模型下，由于大多数知识来自靠近数据源的本地，数据分析仅部分依赖于网络带宽。以往，大型传统数据中心一直是网络计算和连接的支柱，几乎所有数据都在一个核心集中处理。然而，物联网技术和支持AI的应用需要在边缘进行计算，由此影响未来数据中心的建设规模与位置。随着边缘计算的兴起，更多小型数据中心将建在靠近城市和商业区等地方。区域市场和较小的城市可能会有更多存储中心，以及固定在电信塔等现有通信基础设施上的微型数据中心。另外，微型数据中心可以部署在现有无线网络的电信塔和其他重要位置上。未来大量的数据中心也将不再像如今的数据中心般拥有大型仓库的规模。

（文/广州日报全媒体记者文静）

亲爱的读者，如果你知道任何关于科技前沿的猛料，欢迎将新闻线索发至：gzrbkc@126，我们将有专人进行回复和处理。

对于个人而言，数据可视化是我们在日常工作中常常能够接触到的一项重要技能，通常，我们会使用Excel进行简单的图表制作，通过这些图表，我们进而就对这些数据有了一个直观的了解和认识。

而对于企业来说，想要“读懂”存储在服务器上的大量业务数据，绝不是Excel能够完成的，这需要数据处理、分析、可视化呈现等一整套解决方案。因此，在实施大数据战略，或者说部署数据分析产品时，很多企业都会有这样的疑问：如何处理海量的业务数据？借助什么样的分析手段才能发现数据价值？如何确保数据可视化分析过程中的实时性？在第九届中国数据库技术大会（DTCC 2018）现场，DataHuner CTO马珂就针对这些问题进行了讲解。

本次分享，马珂从企业内的真实业务场景出发并结合测试实例，逐步介绍大数据时代下，数据可视化分析的技术架构与组成。同时，马柯详细介绍了探索式分析、实时数据分析的技术原理及企业应对海量数据分析的处理方法。

谈谈数据库性能优化

近些年，数据库技术不断推陈出新，从传统的关系型数据库到NoSQL，或者说从行存储发展到列存储，数据库的查询方式发生了根本性的变化。

关系型数据库，基于存储结构，其在模型定义（ORM）、数据关联（TableJoin）、聚合计算（Group）等方面具有优势，关系型数据库的特性往往也是非关系型数据库的短板；而非关系型数据库在处理海量数据（千万行以上）方面则性能突出。

谈到数据库性能，从算法层面来讲，其实无论哪种数据存储结构，基于算法的优化都已达到极限。目前提升数据库性能的途径，主要集中在IO层面，例如DFS系统、MPP的架构。内存数据库（如Redis）虽然在性能上是一种质的提升，但其持久化所引发的一系列问题，可能会使架构复杂度增加，不一定适用于所有场景。

另外，非关系型数据库向关系型数据库查询（T-SQL）的兼容，例如Hive，确实已经取得了长足的发展，但目前看还不够成熟，暂时无法做到平滑迁移。

还有一个隐含的问题，我们可以以一种娱乐的心态观察一下，即：分布式计算。对于以统计学为基础的数据分析，是一种基于全量数据的计算。所以在这种前提下，分布式计算极有可能是一个伪命题。

在MPP架构中下的RDB中，分布式计算应当是耦合在某些查询当中的，例如count(*)，这实际上是由分布式存储所带来的算法优化。是否也可以通过某种加权算法，来协调其他的聚合算法？然后用架构性能来抵消加权算法所带来的新的复杂度？我相信答案是肯定的。

可视化技术的演进

相对而言，数据分析技术有比较成熟、丰富的理论和实践支撑，而可视化技术则比较匮乏。从定义上来讲，数据可视化主要是为了增强数据的显示效果，方便用户以更加直观的方式查看数据，进而发现数据中隐藏的价值。

近几年，随着显示技术的突飞猛进，包括从显示器、投影仪，到现在的LED巨幅屏幕，VR/AR，全息技术，乃至移动设备和性能的升级，使得数据可视化领域有大量有趣的事情可以做。回到企业场景，我们可以把可视化分为两个层面的问题：即数据分析中的可视化：从报表到分析、数据展示中的可视化：从平面到多维。

大数据时代的到来，也让数据可视化技术得到了更多的关注，但面对海量数据，可视化技术目前仍然存在很多亟待解决的问题，包括海量数据的ETL处理、实时数据处理等。未来，随着人工智能和机器学习技术的快速发展，其与可视化的结合，相信也会是一个重要挑战。

探索式分析技术

数据分析当中的可视化，最直接的表现就是各类图表。其实，我们在借助Excel或其他工具生成图表时，实际上已经在可视化这条路上迈出了第一步。

在数据分析层面，传统的数据分析有明确的目的性，从数据来源、分析方式、输出结果等方面，都是有传统的业务逻辑支持的，按部就班地进行分析即可。但是进入集约化生产之后，如何调优生产、降低成本，这些事情就不是那么明确了。

与此同时，由于前期的数据积累，数据分析师所面对的数据体量也越来越大。如果我们将传统的数据分析称为粗放式分析，那么当前企业所面临的挑战，是对所拥有数据的精耕细作。这种集约化分析就是对数据金矿的深度挖掘，是企业的必经之路。其背后的分析方式，也就自然进入了探索式分析阶段。

在探索式分析中，可视化（或者说各类图表）此时是用户快速捕捉数据特点最有效的途径，在这种场景下，可视化对象是一个结果集（分析结果，小数据），虽然数据量较小，但人类依然无法直接处理。

同时，因为探索式分析需要协同决策，所以对可视化表现的合理性有较高的要求，背后应该有统一的绘图标准，来实现可视化方式的切换。狭义的数据可视化，也就是图表，我们将其抽象为以下几个部分：

坐标系

1. Rectangular Coord(Q-1, Q-All)

2. Polar Coord

3. GEO

度量(Metric)的图形表达

1. Size(Distance, Radian)

2. Direction

3. Extreme(SUM,MAX,MAXMIN)

4. 色彩饱和度

维度(Dimension)的图形表达

1. Delta(Position, Angle)

强调（基于维度）

1. Color

2. Animation

在这个体系下，可以将我们熟悉的几种图表进行建模。这里我们先不考虑“色彩饱和度”和“强调”两方面的参数。

柱图：

Rectangle: [0, 0, 400, 300]

Coordination = Rectangular:Q1

坐标系：第一象限

Metric = Size:Distance;

Direction =[Left, Up];

Extreme = MAXMIN

度量：距离的Size；左向右排列，下到上为正像；参考极值：最大最小值差。

Dimension = Delta:Position, Offset =[0, 0.8];

纬度：位置偏移，位置矫正：0，视觉矫正：0.8（该参数具体表现为柱图的宽度内缩）

饼图：

Rectangle: [0, 0, 200, 200]

Coordin+tion = Polar

坐标系：极坐标系

Metric = Size:Radian; Direction =[Clockwise]; Extreme = SUM

度量：弧度Size；顺时针排列；参考极值：总和

Dimension = Delta:Angle, Offset = [0,1];

纬度：角度偏移，位置矫正：0，视觉矫正：1

极柱图：

Rectangle: [0, 0, 300, 300]

Coordination = Polar

坐标系：极坐标

Metric = Size:Radian, Direction =[Clockwise]; Extreme = MAXMIN

度量：弧度尺寸，顺时针，差极值参考

Dimension = Delta:Position, Offset =[0, 0.8];

纬度：位置偏移，0位置矫正，0.8视觉矫正

在这种可视化体系下，我们首先可以对各类图表的适配能力进行归纳，并对图表的表现能力进行量化，从而形成基于数据集特点的图表推荐算法。前面提到，每一个图表实际是一个模型。我们在基于SaaS的数据分析产品中，会将这个模型与行业、用户使用习惯结合，借助机器学习，最后产生图表的AI算法。

实时的数据可视化分析

如果说探索式分析的可视化，是OLAP的可视化，那么实时数据可视化，可以说是OLTP的可视化。这种情况下，时间维度往往是基础维度，因为OLTP对实时性有较高的要求。所谓实时性，具体体现在时间切面的密度、采样精度等问题上，从而决定了数据窗口的大小。基于B/S的产品结构，我们对像素绘图的性能进行了测试。浏览器端的绘图分2D和3D两种，基本数据如下：

Mac Pro i7 8G Inter Graphic-card

类型|复杂度|FPS

Canvas 2D 400,000 11FPS

Canvas 3D 1,000,000 30FPS

这里面的复杂度，为一次最简绘图，即描绘一个点的动作。由于Canvas3D（WebGL）调用了显卡计算，所以点绘图方式和2D有所不同，这其中还包含了线绘图和自旋计算。WebGL接口所使用的GL是OpenES，与OpenGL同源。

当然，2D和3D绘图可比性不是很高，但通过这两组数据，我们可以基本了解在浏览器端，2D和3D绘图方面我们能够达到的性能上限。在我们实际遇到的客户场景中，有个上限8万点绘图，2FPS刷新率的案例。根据上面的测试数据，我们可以看到，2D性能完全可以满足需求，富裕的算力可以放在优化视觉效果和用户体验上。

此外，三维甚至多维空间中的可视化还处在萌芽的阶段，在这种场景下，会让数据可视化变得更加困难。未来，随着可视化技术的不断发展，我相信三维空间下的可视化理论会有大幅升级，同时由于显卡GPU的支持，其渲染能力也会大幅度提升。

今天的分享就到这里，感谢大家聆听。

日前，位于纽约的人工智能领域创业企业奇丽（cherre）公司宣布从天使投资组织那里获得了900万美元的种子资金，用于其拓展北美市场。

该公司是一家房地产行业数据智能分析平台公司，能够帮助客户提高其购买房地产的成功率，它能够即时采集来自公共部门、个人部门等的房地产信息数据，并对其进行分析，帮助保险公司、银行、投资人或其他潜在客户，决定是否对看中的房地产项目进行投资。

通过该平台，客户能够准确地了解某个房地产项目的历史背景、过往交易记录、周边人口资源、价格、未来影响因素等信息，以帮助客户优化自己的决策，提高投资成功率。

本轮投资由纳维塔斯投资公司（navitas capital）领投，另外四家创业投资公司跟投。位于加州纳维塔斯投资公司成立于2011年，专注于投资包括智能建筑设计在内房地产科技企业。在天使轮，沃顿天使投资组织、哈佛天使投资组织和纽约天使投资组织等六个区域性天使投资组织支持了奇丽公司的早期发展。

纳维塔斯投资公司管理合伙人吉姆·佩蒂特（Jim Pettit）高兴地说：“奇丽房地产人工智能平台推出刚刚一年，但它已经革命性地改变了这个行业大数据分析、处理的方式，为金融机构、保险公司、房地产经纪公司和其他需要跟房地产领域合作的大型企业提供了前所未有的解决方案。我们愿意跟所有的投资机构一起，支持这家创业企业进一步提高其服务效率，拓展市场空间，给所有与房地产相关的企业带来更多福音”。

这家新成立的公司于2017年12月才推出他们的服务平台，但是，他们迅速被业内大客户所接受，纽约房地产管理委员会、全球最大的房地产经销商凯勒·威廉斯（Keller Williams）公司、斯特莱特系统公司（Stratus Data Systems，为房地产行业提供信息服务的企业）、铂金不地产经纪公司（Platinum Properties）、奥格斯特公司（August Partners，为房地产企业提供战略咨询和策划的企业）等使用了该公司的平台。

奇丽公司联合创始人、首席执行官萨尔曼森（L.D. Salmanson）说，公司将利用这笔资金满足客户激增的需求，并拓展美国其他城市和加拿大市场。

奇丽公司联合创始人、首席执行官萨尔曼森（L.D. Salmanson）

“世界上许多大行业都开始重视即时大数据的力量，重新评估即时大数据对于提高行业核心竞争力的作用。”萨尔曼森说，“我们看到金融机构、保险公司、房地产投资公司等利用即时大数据后对他们的业绩的极大改善，以及我们核心服务在其它领域的应用潜力，这使我们倍受鼓舞。现在，新的投资人进来了，我们会快速提升我们的服务质量，把即时大数据应用，提高到新的水平”。

纽约房地产管理委员会（Real Estate Board of New York，REBNY）是纽约房地产行业的商会组织，成立于1896年，目前，该委员会的17000名成员单位管理的建筑物达到110万栋，其中有住宅350万套。2017年10月，在该委员会组织的一次技术竞赛中，奇丽公司脱颖而出；2018年4月，该委员会采用奇丽公司的即时数据分析系统服务自己的会员单位。

萨尔曼森2000年~2004在以色列国防军服兵役4年，2013年获得沃顿商学院MBA，此后在投资机构工作。沃顿校友天使投资组织（The Wharton Alumni Angel Network，WAAN）是支持宾夕法尼亚大学和沃顿商学院校友创业的天使投资组织。正是由于在投资行业从业的经历，他跟投资界保持密切的联系，2016年，他创立奇丽公司时，就获得了WAAN、纽约天使投资组织等六家天使投资组织的共同支持。

奇丽公司还获得过包括“2017亚裔金融行业年度金融技术奖”等荣誉称号。到2020年，房地产领域大数据应用的市场规模超过万亿美元。

大数据时代所分析的数据的最主要特征是“多源异构”，其分析过程是逐层抽象、降维、概括和解读的过程。从数据采集的源头进行划分，可将大数据时代分析处理的数据对象划分为以下几个类别：

（1）各网页中用户的浏览次数、点击率，各种社交网站、动态网站网页内容信息的变化，搜索引擎中关键词的搜索量、网络实时监控数据等互联网数据。

（2）可以用于分析用户行为、对系统的操作、以及系统运行状态的日志数据。

（3）在通信领域中的各种信号、信令数据，用户的个人信息以及通话位置、时长等数据。

（4）国民经济中各领域、各行业的统计分析数据。

对于这些数量庞大的，来自不同源头的非结构化数据。其分析模式的特点如下：对于互联网产生的数据，其最主要的应用是建立搜索引擎，通过搜索引擎进行数据检索、处理。

随着技术的不断发展，个性化推荐引擎以及大数据分析引擎的问世能够更加高效的在海量数据中分析得出更有价值的信息;

对于日志数据，可对用户点击浏览的行为日志和系统运行行为日志进行分析。使得系统能够根据实际情况产生出更加智能的结果。日志数据与网页数据的分析处理模式较为类似，都是通过细致分析从而探寻出数据中蕴藏的价值。

这种数据分析处理模式称为“离线批处理模式”;对于通信领域的数据分析，分析决策人员会对经过细致分析的数据进行统计归纳和查询，并且在最短的时间内获得最有价值的信息。

以此来确保系统的交互性并最大限度地提升用户体验。这种数据分析处理模式称为“查询式分析”模式;对于互联网以及国民经济中重要行业的数据进行实时监控，这种模式称为“实时数据分析处理“模式。

以上为依据时间特征划分的数据分析模式。而实现这些分析模式的主要方法有：分类、回归分析、聚类、关联规则、神经网络、WEB数据挖掘等。

要想从急剧增长的数据资源中挖掘分析出有价值的信息，需要先进的分析技术作支撑。从宏观上看，大数据分析技术发展所面临的问题均包含三个主要特征：

（1）数据量庞大并以惊人的速度增长;

（2）数据种类与结构多样化，并以半结构化和非结构化的数据为主;

（3）需要具备及时快速的分析速度，即实时分析。这些特征使得传统的数据分析技术无法满足要求，更加先进的数据分析平台才是大数据时代更好的选择。

为了有效应对大数据时代数据分析问题的三个主要特征以及满足大数据分析的基本需求，当前以及未来一段时期内将主要通过分布式数据库或者分布式计算集群来对存储于其内的海量数据进行由浅入深的分析和分类汇总。

例如，为满足实时分析的需求通常会采用Qracle的Exadata 和EMC的GreenPlum。而目前分析处理大数据的应用最广泛的核心技术为Hadoop。

Hadoop是由Apache基金会所开发的一个基于Java的分布式数据处理和分析的软件基础架构。

在这种架构下，用户可以在不了解分布式底层细节的情况下，开发分布式程序。Hadoop能够将数量庞大的数据分解成规模较小、易访问的数据集并发送到多台服务器上进行分析，以此获得高效的分析速率。

该架构主要由文件系统以及数据处理两部分功能模块组成

首先恭喜你，当你看到这篇文章的时候，不管你是小白还是大咖，你都将直接获得一个高级技能：轻松上手可实时刷新的酷炫大屏。

制作可视化大屏，一般有这么几种方案：

写代码调用数据和图表，比如写JS+Echarts ；直接的数据可视化工具

前者对于大部分人来说门槛较高，而且尤其是大屏需求比较多，比方说要做10个的情况下，亲身试验写代码容易崩溃。如果涉及大量的动态可视化，涉及大数据量，没有底层技术，性能就会大打折扣。而且投到不同尺寸的屏幕，调试起来非常麻烦。

那么有没有一种简单的可视化大屏方案，可以快速的设计样式呈现效果、自适应不同大小的屏幕、而且还可以实时刷新数据？

有，选择后者，直接用数据可视化工具。

市面上能做到直接呈现在LED屏幕的大屏可视化工具并不多，多数需要代码调试，报表工具FineReport和FineBI工具可直接实现，相对来讲FineBI使用更简单，本文也是基于FineBI，来教大家做可实时刷新的数据大屏。

先来看看我们今天即将要教大家做的大屏效果（请接受一波酷炫可视化的冲击！）

不懂代码，如何做出实时刷新的数据大屏？

1、快速上手学习BI工具

FineBI是一个可视化的自助式BI工具，整个操作就是导数据/连数据库——处理数据（可视化ETL）选择图表——拖数据字段——可视化展现&美化，操作简单上手快。多数情况下，这个工具都是拿来做可视化报表，对接企业大数据平台，做企业数据运营分析用。

关于他的入门教程，小编之前曾发过一个视频《30分钟，教你零基础用BI搭建可视化大屏！》

2、构建数据模型

掌握了finebi的基础功能：怎么连接数据，怎么趋势，怎么做图表。接下来就到了正式做大屏步骤，先是构建数据模型。

大屏也是有主题的，本质是对一类业务的分析，然后综合展示，比如销售大屏。像这类业务分析一般要用到多张维度表和事实明细表的数据（例如下图中的分公司维度表和合同事实表）。常规操作是将不同业务系统的sql表拼接、宽表拼接，构成一个星型数据模型，需要你有专业的数据仓库技能。那这里化繁为简，可以直接用工具自带的敏捷数据模型去替代上述的工作，原理是自动构建雪花型模型，跨数据源关联。

搭建好上图的销售demo业务包的数据表和关联模型之后，下一步就可以进行正式的销售管理驾驶舱大屏搭建。

3、大屏布局设计

在给大家介绍具体制作过程之前先讲解一下通常管理驾驶舱的布局方式。管理驾驶舱往往展现的是一个企业全局的业务，一般分为主要指标和次要指标两个层次，主要指标反映核心业务，次要指标用于进一步阐述分析。所以在制作时给予不一样的侧重，这里推荐几种常见的版式。

上面几个版式不是金科定律，只是通常推荐的主次分布版式，能让信息一目了然。实际项目中，不一定使用主次分布，也可以使用平均分布，或者可以二者结合进行适当调整。比如下图所示，指标很多很多，存在多个层级的，就根据上面所说的基本原则进行一些微调，效果会很好。

4、实际分析制作过程

有了以上的布局设计，每一个模块就单独用一类图表分析一块内容，比如销售分布、签单分布、回款金额分析......整体呈现一个主题（在这里是销售业务）的分析。

那具体如何用工具操作呢？

首先，既然是销售管理驾驶舱，那么我们可以先从领导和高层最为关注的公司签单金额和回款金额入手。对于这样的汇总指标，选择仪表板进行数据展示再合适不过了。选择拖入合同事实表中的合同金额和合同回款表中的回款金额两个指标，样式这里选择圆环仪表盘，同时两个指标的单位都设置成亿，最大刻度输入当前合同金额，2.78亿。这样一来，2.78亿的合同回款，2.25亿的回款金额以及80.87%的总的回款率也就统计出来了,企业的签单金额和回款金额/回款率都一目了然。

其他部分也是一样的原理，篇幅原因不多介绍，核心是要知道展现哪些数据指标。

5、实时刷新功能

如何做出实时刷新的数据大屏，本篇还有一个重点内容就是大屏的实时刷新功能，也是大家问得比较多的。

所谓实时刷新，即你展示出来的酷炫大屏上面的数据将是动态刷新，能够实时反映数据库中的数据。我们的大屏通常连接着数据库，我们打开报表的时候，会读取数据库中的数据，但数据库中的数据可能是动态变化的，如果要读取变化的数据的话，不需要我们重新打开刷新报表，报表中的数据将动态自动刷新。

FineBI实时刷新的底层技术和性能:

实时刷新的实现所依靠的一个重要支撑，是FineBI自带的FineDirect直连引擎。FineDirect直连引擎给出了数据端到应用端的完整解决方案，支持连接企业已有的大数据计算平台，如Hadoop、Kylin、Greenplum、Vertica等，在充分利用平台计算性能的同时，也解决了TB至PB级超大数据量多维分析的难题。

FineDirect是FineBI推出的大数据直连引擎功能模块，用于更好地处理超大数据量的分析要求和数据源实时性的需求。通过FineDirect直连引擎可以直接对接现有的数据源，无论是传统的关系型数据库（Oracle，Sqlserver），还是日益成熟的Hadoop生态圈，Mpp架构的解决方案，都可以直接进行自助取数分析，实现更敏捷的、更及时的决策分析。

FineDirect引擎核心特点

①PB级别数据量多维分析

FineDirect直连引擎给出了数据端到应用端的完整解决方案，支持连接企业已有的大数据计算平台，如Hadoop、Kylin、Greenplum、Vertica等，在充分利用平台计算性能的同时，也解决了TB至PB级超大数据量多维分析的难题。

②实时大数据分析

FineDirect能够连接实时数据进行分析，及时返回分析结果。基于FineDirect的可视化引擎，可以将用户拖拽分析的操作，实时地转化为经过处理的查询语言，实现对企业数据库实时分析的效果。

③双引擎模式灵活搭配

FineBI已有FineIndex引擎（原cube）和新的FineDirect直连引擎可以搭配使用，来满足不同的应用场景。企业可以根据实际需求的不同准备两种类型的数据，通过FineIndex模式配置那些不经常更新、实时性要求不高的数据；通过FineDirect直连引擎配置大数据量且有实时分析需求的数据，双管齐下。

在短时间内爆发大量数据，这时数据资源的采集、存储和分析和应用等，都是大数据行业的难点。行为数据、日志数据的处理，往往成为企业数据建设首先面对的瓶颈，这些数据不易保存，实时获取分析难度较大，但是数据价值却不可估量。

在大数据中，90% 以上的数据爆发来自于行为数据，就像现在的互联网、移动互联网、甚至在产生于物联网中用来描述人和物的每一分每一秒的变化的数据状态，这些都是行为数据。

行为数据能用做什么？

行为数据能做什么？有一个简单的例子 —— 分析访客行为的路径，我们拿一个网站的数据进行分析，针对网站的访客，我们可以通过分析其访问前期、中期、后期的行为习惯去了解哪些引流的渠道需要加强投入，以及使用这些来指导内容编辑和竞品研究分析工作。

实际上在做需求时，还有更多的细节要求如：对数据的实时性的要求比较高、要求数据的热点情报的准确性、与客户数据的协同分析等。

行为数据的处理方式

用户行为数据通常具备以下特征：

用户基数大；

高基数维度比较多；

数据量大；

时序的特征。

我们用到的高基维，其中有些维度都是上千万的高基维参数。用户行为数据的处理，在支持原始数据查询的同时，也要支持原始数据的聚合能力。

原始数据的聚合分析这块又分为两种，一种是过去常用的做法，通过一个固化的业务模型或者主题，提前计算好的数据，叫做物化视图。

第二种是基于原始数据存储之后，在实时查询的过程中进行多维交叉的计算，这个称为实时聚合。

在查询过程中对实时聚合的一个分析，也是大家在进行数据挖掘分析中共同面临的一个问题，就是针对海量数据。

首先，针对这些数据，需要快速的检索出所需要的数据的行号。其次，在获取数据所在位置之后，如何快速地把数据装载到内存里，最后是装载到内存之后通过分布式计算的方式，怎么去把我们的结果计算出来。

这些就是在做数据的实时查询过程中的需要具备的基本技术条件。

挖掘数据新的价值

面对海量实时行为数据的技术思考，主要是从四个角度来进行：

第一，必须要以原始数据存储。为什么要基于原始数据存储？因为在整个的数据分析阶段，可以细分为三个阶段。第一个就是传统的是 BI 阶段。第二个是数据的挖掘，第三个是数据的预测分析。

想解决这三个阶段的过程，以传统的方法是建一个数仓，基于数仓来实施的时，只能面向比较固化的业务报表模式，产生一些数据的分析结果，得到决策结果。如果想做数据挖掘时，基于固化业务模式计算的结果的很难满足数据挖掘需求，所以必须从初始阶段基于原始数据去提取其特征。

基于固化的的业务报表模型所获取数据计算的结果，对数据挖掘分析的价值不高。存储引擎必须以原始数据进行存储，才能既满足 BI 阶段的需求，又可以解决未来数据挖掘与数据预测分析的需求。

第二，要满足实时多维的查询，是为了在数据基于原始数据存储之后，去做到聚合结果能够满足用户对海量增量数据快速查询的需求。

第三，快速响应需求，在企业内部，其实数据部门的需求量是最大的，各个业务部门的需求都往数据中心提，所以数据部门必须去解决好如何快速地响应业务需求。

第四，数据的探索分析，以往把数据，按照固化的业务报表模式所获取的结果，做二次分析的空间量比较小。所以必须要基于原始多维的数据进行数据的探索，挖掘数据新的价值，而不是按照已有的固化的业务模式，只是生产出一些固化的业务模型的数据。

平台架构

数果现在基于之前做过的一些技术的预言跟验证，自行研发了一个基于 Hadoop 加速引擎，称为 Tindex。之前我也在网络上做过万亿级日志与行为数据存储查询技术剖析http://infoq/cn/articles/trillion-log-and-data-storage-query-techniques 的文章 ，也讲解了 Tindex 是如何实现的。Tindex 的实现主要基于三点，第一点基于索引，第二点基于类似存储的方式，第三点做了分布式内存计算的框架在 Tindex 中，使之能够支持数据的实时的多维分析的能力。

基于加速引擎这块，在其上层做了一个适配层，有 SQL引擎。SQL 引擎支持 SQL 语句和表达式，还有大数据生态技术，目前已经是完全支持。基于适配层，来做不同的行业应用。这是数果整个平台技术架构的一个图。

平台特性

平台的特性方面，支持海量增量数据实时接入。在数据接入这块，现在提供可视化埋点，跟文件、MR 的一些数据的采集，就像我们目前在做的单进程的接入式，基本上在 3 万以上，从数据的产生，到数据显示、出现查询结果，在 5 秒以内即可实现。

第二个特性，基于明细数据的存储与预聚合的存储分别去搭建。为什么不仅要基于原始数据存储，还需要预聚合存储？因为其有两种不同的需求。第一个是面向固化的高频查询的数据，我们可以基于预聚合存储的方式，去查询其周期跨度比较长的需求，一年两年都可以进行查询。但是基于近半年或者一年的数据需要进行深度数据探索分析的，便可以基于原始明细数据做实时聚合分析。还有在基于原始明细数据进行分析的时候，他会更佳灵活。

第三，海量数据中怎么去实现快速检索，是基于搜索引擎的索引技术进行改造的。但是在筛选方式上，目前只能支持时间筛选、文本筛选和数值筛选，例如文本筛选中支持分词与模糊匹配，数值筛选中，数值的分组和数值的范围这些均可支持。

这个展示的是灵活多维的分析，在这个界面中，左边的这一列中是基于原始明细数据产生的所有的维度，可以根据权限去进行显示。而在指标方面通过界面拖拽进行多维实时分析，选择想要的数据分析结果，进行可视化的展示，可以自由地数据探索。因为数据是基于原始明细数据的存储，所以不需要提前预计算。可以在界面上进行任意数据交叉分析，去了解数据的分布态是非常便捷的。

通过指标的灵活定义，来实现实时响应的业务需求，这个指标定义这块有几个指标，一种叫单指标，即按照某一个维度进行一个聚合计算，通过界面可以简单、快速完成。另一种叫复合指标，需要进行一些四则运算，可以通过这个界面定义出来。

在指标这方面还有比较复杂的，需要通过多个维度进行定义的，可以通过一些表达式，进行快速的定义，定义完成后就通过界面，直接看到结果，获得图形显示，进行数据分析。

支持实时监控与跟踪告警，在多维分析界面中把分析结果定义出来后，可以直接形成一个实时监控大屏，不需要重新开放，多站完成各类需求。

最后一个也是最重要的一个特性，是支持二次的开发。数果的平台提供普通类查询，有 Timeseries、TopN、select、groupby、firstN、scanQuery。也提供像用户分组，用户漏斗查询，用户留存查询这类高级查询，还支持多种条件的过滤，像日期范围、数值范围、地理坐标范围，还有字符串的精准匹配。还支持多种聚合的方式。如统计，分组，还有聚合再聚合，这类业务场景，也是在业务需求中经常出现的。

基于平台我们做了什么？

基于这个平台实现了指标任意定制，因为数据是基于原始明细记录存储的，所以指标的定制这方面，不需要提前预计算，直接通过界面，通过一些表达式便可以轻松实现。

维度的自由的筛选，可以通过界面，自由地拖拽数据，就可以完成交叉分析。

基于平台提供用户行为分析模型，例如实时的用户分群，可以通过界面快速的完成。再例如实时的路径分析，实时的流程分析，实时的漏斗分析。提供了一个智能算法模型，相当于在这个模块实现了，将机械学习跟深度学习的算法吸收进来，跟我们的平台打通，就可以实现通过界面的简单拖拽，来完成大部分算法的模型。用户也有一些固化的模型，像用户的扩群，用户 RFM 细分的模型，用户流失预测的模型。基于这方面也提供了一个实时大屏的模块，能够由用户自由拖拽完成其实时监控的需求。

导语：在这个数据爆炸的时代，组织正在以不断增长的速度收集和存储数据。但是，仅为您的组织收集数据并不具有任何业务价值。这些大数据的实时分析和可视化将这些大量数据转化为有价值的统计数据。虽然这种实时洞察对您的组织具有重要价值，但它确实有利有弊。

在进一步讨论之前，让我们讨论大数据，究竟是什么？传统上，数据存储起来要容易得多，因为它的数量要少得多。当需要以更大的数量存储数据集时，大数据才出现。它不仅是数据或数据集，还包括工具，技术，方法和框架的组合。大数据几乎可以来自任何产生数据的东西，包括搜索引擎和社交媒体，以及一些不太明显的来源，如电网和交通基础设施。该数据可以分为三种类型：结构化，半结构化和非结构化。

通常以预定义的间隔收集和分析大数据。然而，通过实时大数据分析，收集和分析是连续的，为企业提供最新的洞察力。Hadoop是用于分析大数据的最着名的工具，但它不适合处理实时大数据分析。一些实时大数据工具包括： 这是一个实时分布式计算系统，可与任何编程语言配合使用，并且可扩展。它目前由Twitter拥有。这是一个企业开源网格计算工具。

现在让我们讨论实时大数据分析的一些优点。快速识别错误，假设发生了错误，需要尽快解决。通过实时大数据分析，可以立即识别此错误并快速解决。这可以帮助防止更多和/或更严重的故障。从长远来看，这也有助于企业的声誉 - 快速纠错可以帮助赢得更多客户。节省，即使实时大数据分析的实施成本很高，立即数据分析的高价值也可以弥补这一支出。渐进式服务，通过大数据分析监控产品和服务可以提高客户的转换率，从而可以带来更高的利润。通过分析可以轻松预测即将发生的错误和问题，这也有助于更多地关注客户需求。

实时欺诈检测，管理系统和服务器安全性的团队可以快速，轻松地通知欺诈行为，一旦检测到欺诈行为，就可以实时采取措施。针对竞争对手的策略 - 竞争吓跑了当今市场中的许多人，大数据分析有助于提供竞争对手的详细信息，例如推出新产品，降低/提高特定时间段的价格或关注特定地点的用户。洞察力销售见解对于了解销售情况至关重要。这些见解可以带来额外的收入，例如不会长期失去客户，检查跳出率并通过分析实时大数据分析找到增加销售的最佳方式。趋势，通过分析客户趋势做出的决策可以通过实时大数据分析来完成。这可能包括产品，广告，客户需求，特定季节和其他可用的优惠。因此，它也可以改善长期决策。

现在让我们来看看缺点。如前所述，Hadoop是最广泛使用的大数据分析工具，目前无法处理实时数据。因此，需要一些其他工具，期望未来Hadoop将为实时方法添加功能。需要新方法，一些组织习惯于每周一次接收见解。但是，随着实时大数据的不断流入，需要采用完全不同的方法。这对某些组织来说可能是一个挑战，并可能导致某些决策和计划的重塑。可能的失败，一些组织可能会将实时大数据分析视为一个闪亮的新玩具，并希望立即实施。但是，如果没有正确实施，这可能会导致许多问题。如果企业不习惯以如此快的速度处理数据，则可能导致错误的分析，这可能会给组织带来更大的问题。

总结：实时大数据分析对于企业来说可能非常重要，但企业必须首先确定专业人员在特定情况下是否超过缺点，如果是，那么这些缺点将如何克服。这仍然是一项相对较新的技术，因此有望在未来发展，并有望解决目前的一些挑战。

1 引言

大数据技术的广泛应用使其成为引领众多行业技术进步、促进效益增长的关键支撑技术。根据数据处理的时效性，大数据处理系统可分为批式(batch)大数据和流式(streaming)大数据两类。其中，批式大数据又被称为历史大数据，流式大数据又被称为实时大数据。

目前主流的大数据处理技术体系主要包括Hadoop[1]及其衍生系统。Hadoop技术体系实现并优化了MapReduce[2]框架。Hadoop技术体系主要由谷歌、推特、脸书等公司支持。自2006年首次发布以来， Hadoop技术体系已经从传统的“三驾马车”(HDFS[1]、MapReduce和HBase[3])发展成为包括60多个相关组件的庞大生态系统。在这一生态系统中，发展出了Tez、Spark Streaming[4]等用于处理流式数据的组件。其中，Spark Streaming是构建在Spark基础之上的流式大数据处理框架。与Tez相比，其具有吞吐量高、容错能力强等特点，同时支持多种数据输入源和输出格式。除了Spark开源流处理框架，目前应用较为广泛的流式大数据处理系统还有Storm[5]、Flink[6]等。这些开源的流处理框架已经被应用于部分时效性要求较高的领域，然而在面对各行各业实际而又差异化的需求时，这些开源技术存在着各自的瓶颈。

在互联网/移动互联网、物联网等应用场景中，个性化服务、用户体验提升、智能分析、事中决策等复杂的业务需求对大数据处理技术提出了更高的要求。为了满足这些需求，大数据处理系统必须在毫秒级甚至微秒级的时间内返回处理结果。以国内最大的银行卡收单机构银联商务为例，其日交易量近亿笔，需对旗下540多万个商户进行实时风险监控，在确保这些商户合规开展收单业务的同时，最大限度地保障个人用户的合法权益。这样的高并发、大数据、高实时应用需求给大数据处理系统提出了严峻的挑战。银联商务以前使用的T+1事后风控系统存在风险侦测迟滞高(次日才能发现风险，损害已经造成)、处理时间长(十几个小时之后才能完成风险识别)、无法处理长周期历史数据(只能分析最近几日的流水数据)以及无法支持复杂规则(仅能支持累积求和等简单规则)等重大缺陷。为此，亟须研发全新的事中风控系统，以重点实现低迟滞(在1 min内甄别突发风险)、高实时(100 ms内返回处理结果)、长周期(可处理长达10年以上的历史周期数据)以及支持高复杂度规则(如方差、标准差、K阶中心矩、最大连续统计等)等目标。这一目标可以抽象为一个大数据处理科学问题：如何在一个完整的大数据集上，实现低迟滞、高实时的即席(Ad-Hoc)查询分析处理。

2 技术解析

现有的大数据处理系统可以分为两类：批处理大数据系统与流处理大数据系统。以Hadoop为代表的批处理大数据系统需先将数据汇聚成批，经批量预处理后加载至分析型数据仓库中，以进行高性能实时查询。这类系统虽然可对完整大数据集实现高效的即席查询，但无法查询到最新的实时数据，存在数据迟滞高等问题。相较于批处理大数据系统，以Spark Streaming、Storm、Flink为代表的流处理大数据系统将实时数据通过流处理，逐条加载至高性能内存数据库中进行查询。此类系统可以对最新实时数据实现高效预设分析处理模型的查询，数据迟滞低。然而受限于内存容量，系统需丢弃原始历史数据，无法在完整大数据集上支持Ad-Hoc查询分析处理。因此，研发具有快速、高效、智能且自主可控特点的流式大数据实时处理技术与平台是当务之急。

实现一个融合批处理和流处理两类系统且对应用透明的系统级方案，需要攻克以下几个技术难点。

(1)复杂指标的增量计算

尽管计数、求和、平均等指标能够依靠查询结果合并实现，然而方差、标准差、熵等大部分复杂指标无法依靠简单合并完成查询结果的融合。再者，当查询涉及热点数据维度及长周期时间窗口的复杂指标时，多次重新计算会带来巨大的计算开销。

(2)基于分布式内存的并行计算

采用粗放的调度策略(例如约定在每天的固定时间将流数据导入批处理系统)会造成内存资源的极大浪费，亟须研究实现一种细粒度的基于进度实时感知的融合存储策略，以极大地优化和提升融合系统的内存使用效率。

(3)多尺度时间窗口漂移的动态数据处理

来自业务系统的数据查询请求会涉及多种尺度的时间窗口，如“最近5笔刷卡交易的金额”“最近10 min内密码重试次数”“过去10年的月均交易额”等。每次查询请求都重新计算结果会对系统性能造成极大的影响，亟须研究实现一种支持多种时间窗口尺度(数秒到数十年)、多种窗口漂移方式(数据驱动、系统时钟驱动)的动态数据实时处理方法，以快速响应来自业务系统的即席查询请求。

(4)高可用、高可扩展的内存计算

基于内存介质能够大大提升数据分析及处理能力，然而由于其易挥发的特性，一般需要采用多副本的方式来实现基于内存的高可用方案，这使得“如何确保不同副本的一致性”成为一个待解决的问题。此外，在集群内存不足或者部分节点失效时，“如何让集群在不间断提供服务的同时重新平衡”同样是一个待解决的技术难题。亟须研究分布式多副本一致性协议以及自平衡的智能分区算法，以进一步提升流处理集群的可用性以及可扩展性。

“流立方”流式大数据实时处理技术在上述领域取得了一系列突破，该技术提供基于时间窗口漂移的动态数据快速处理，支持计数、求和、平均、最大、最小、方差、标准差、K阶中心矩、递增/递减、最大连续递增/递减、唯一性判别、采集、过滤等多种分布式统计计算模型，并且实现了复杂事件、上下文处理等实时分析处理模型集的高效管理技术。

3 平台纵览

基于“流立方”流式大数据实时处理技术，研发了“流立方”流式大数据实时处理平台。其应用框架如图1所示，具有良好的灵活性和适应性。平台的数据装载模块负责从具体业务系统中接入实时流数据，数据抽取模块负责批量抽取历史数据，模型装载模块负责将分析处理模型集中的计算模型和脚本加载到平台中。当收到业务系统发出的实时查询请求时，“流立方”平台能够根据分析处理模型在完整大数据集上实时计算出相应的指标，并进行判断，将结果反馈给业务系统。

图1 “流立方”平台应用框架

在测试环境为8台服务器(每台服务器配置24核 CPU、256 GB内存)，同时计算16个统计指标(涉及4个维度，包含计数、求和、平衡、最大、最小、标准差、过滤、去重、排序、复杂事件处理等多种算法)的性能测试中，“流立方”平台达到了单节点写入大于43 000 TPS、8节点读取大于100万TPS、平均时延为1～2 ms的优异性能，如图2所示。

图2 “流立方”平台性能指标

“流立方”平台在解决批式大数据和流式大数据融合实时处理技术难题，实现优异性能的同时，还解决了流式大数据处理平台面临的两大工程化难题。一是作业的编排效率问题。大部分开源流处理平台在完成一个流处理编排时，都需要经过拓扑设计、代码编写、功能测试、打包部署等环节，一般需要一周的时间才能完成。“流立方”平台通过基于“所见即所得”的在线作业编排管理，将上线任务耗时降低到分钟级，大大提升了流处理作业的编排效率。二是流处理作业的灵活变更问题。流处理平台擅长进行逻辑预先定义的增量计算，尽管其计算效率极高，但计算灵活度受到限制。例如，某业务需要统计过去3个月的数据，现有的流处理平台在该业务上线3个月后才能完全生效，这样的工作方式使流处理技术在实际应用中受到很大的局限。“流立方”平台创新性地引入流媒体播放器的录制与重放思路，在原始数据进入流处理平台时，通过顺序写的方式持久化一份原始数据，在需要上线新的计算作业时，即刻重发指定时间窗口内的原始数据，从而实现快速(分钟级甚至秒级)计算作业上线。

“流立方”平台引入了一系列创新技术，在性能、可用性、可扩展性等多个层面提升了流处理平台的处理能力，满足金融领域在内的众多领域的业务及运维需求。引入数据冲突智能规避技术，解决了流式处理中的热点数据处理问题，从而解决了大颗粒数据维度的处理效率问题;引入Paxos一致性协议，解决内存存储计算时多副本一致性问题，提供了面向运维人员透明的一致性解决方案;引入智能分区技术，基于一致性散列技术，进一步将散列值拆解为散列块，通过散列块的平滑迁移解决存储集群的可伸缩性设计问题，确保对于运维人员的集群变更透明性;引入计算作业的动态运行时加载技术，规避了作业手工打包部署的问题，进一步提升了开发人员的工作效率。

在国内某大型银行卡收单机构组织的招标测试中，测试环节为两台低配置虚拟机，测试数据为该机构的数千万笔交易流水，计算逻辑包括50多条规则，涉及30多个统计指标。在该测试环节下，两家国外著名厂商中，一家厂商的计算时间长达24 h，另一家老牌数据库软件提供商则未能在一天内完成计算。相较于这些国外著名厂商的大数据处理平台，“流立方”平台能够在3 h内完成所有计算，且正确率为100%。

4 应用场景

“流立方”流式大数据实时处理系统在金融、交通、电信、公安等行业具有广泛的应用场景。以金融风控反欺诈为例，部署“流立方”风控系统仅需在交易前端增加风控探头，将实时交易数据旁路接入系统。“流立方”风控系统根据融合了专家知识和机器学习结果的数百条规则对每笔交易进行风险评估，判断是否允许进行该笔交易，流程如图3所示。该系统平均响应时间在6 ms以下，并发数超过50 000笔/s。同时，实现这一性能仅需要4台服务器。

图3 基于“流立方”的金融风控反欺诈流程

基于“流立方”的金融风控反欺诈技术体系包含技术(如设备指纹、代理侦测、生物识别、关联分析、机器学习等技术)、知识(如盗卡反欺诈、伪卡反欺诈、信用卡套现、营销反欺诈等规则与模型)、数据(如虚假手机数据、代理IP数据、P2P失信数据等标识数据)三大板块。技术部分中的设备指纹技术通过主被动混合的形式采集设备中软硬相关要素，结合概率论等算法为每一个设备颁发一个全球唯一的指纹编码，这些指纹编码在反欺诈的整个过程中起到非常积极的作用;代理侦测技术通过短时间内扫描IP相关端口来识别那些开启代理的IP，并在这些IP访问金融服务时进行识别;生物识别技术通过采集设备上用户的鼠标点击、触摸、键盘敲击等行为识别操作者是人还是机器以及是否操作者本人的问题;关联分析技术在底层通过图数据库存储不同节点以及关系信息，最终在界面上通过图的形式进行欺诈者关联分析及复杂网络分析;机器学习技术通过有监督、无监督的机器学习算法提升欺诈识别的准确率及覆盖率，并结合流立方技术提供模型的事中预测能力。

基于上述技术体系，研发了银行业务风险实时监控系统、互联网支付业务风险实时监控系统、电商业务风险实时监控系统等金融风控反欺诈系列解决方案。这些方案已应用到银行、第三方支付机构、互联网金融等领域的上百家企业。目前50%以上的线下交易都在“流立方”的保护下进行，基于“流立方”的金融风控反欺诈解决方案每天为我国的金融机构抵御上亿次的攻击。该技术已经成为我国金融安全领域基础设施必不可少的组成部分。

此外，在互联网机器防御系统中，“流立方”同样能发挥巨大作用。如今网络机器人遍布票务、电商、招聘、银行、政府、社交等各类网站，消耗了40%～60%的网络流量。网络机器人不仅消耗网络资源、影响正常客户访问、增加网站运营成本，还会爬取产品、价格信息，形成不正当竞争，甚至混淆网站用户生态，影响营销分析。传统的控制策略通过采取屏蔽频繁访问、设置验证码等方式防御网络机器人，无法应对日益智能化的新型网络机器人。基于“流立方”的互联网机器防御系统通过在Web服务器上嵌入插件或者独立的嗅探器(sniffer)程序，将全流量的Web访问请求旁路到独立的机器防御集群，进行实时的流量分析及防御决策，并将决策后的结果实时回馈到Web服务器插件中。Web服务器插件在判定当前访问的设备或者IP地址等是机器人时，能够自动改写响应内容，根据不同的风险级别自动拒绝交易或将访问者引导到第三方图形验证码服务商进行机器人验证。访问者在通过验证后可以继续正常访问Web服务。该系统还创新地将设备指纹以及人机识别服务运用到机器防御系统中，不仅增加了可分析维度，提升了控制颗粒度，同时能够对基于浏览器内核的高级爬虫进行防护。此外，将机器防御规则、数据服务、设备指纹、人机识别以及图形验证码以软件即服务(software as a service，SaaS)的形式提供服务，进一步降低了互联网网站客户的运维门槛，提升了产品竞争力。该机器防御系统工作过程如图4所示。

基于“流立方”的实时机器防御系统通过多服务器访问流水关联决策、长周期数据决策、复杂规则爬虫识别、设备维度爬虫识别、人机识别等技术，实现了微秒级(400～800μs)的识别时延，同时具有机器人识别管控一体化、轻量级接入等优点。根据已经接入机器防御服务的几十家客户的反馈，基于“流立方�...

作为世界上最成功的职业联赛之一，NBA一直运用着各种各样的高科技。不论是全明星赛中使用的VR直播技术，使用SportVU的赛场动态追踪系统，还是能够追踪球员身体状态的Athos压力衣，NBA联盟已经不仅仅是运动员的战场了，它更是科技与数据的比拼地。

如今，另一项可能改变NBA训练和比赛的“黑科技”又要出现了。北京时间5月17日，根据美国财经媒体福布斯的报道，“魔术师”埃尔文·约翰逊以及前NBA主席大卫·斯特恩已经注资了一家位于美国堪萨斯的科技公司，该公司开发了一款名叫ShotTracker的平台，其目的在于实时追踪球场上球员们的数据，并提供表现分析。

ShotTracker系统由两个部分组成，第一个部分是一系列装在球场顶上的传感器，它可以实时将球场绘制成3D地图。与此同时，装载在球员身上的微型传感器能够追踪球场上的一举一动。

通过这两个系统的联动，ShotTracker可以即时传送球员的数据到教练手上，而教练也可以据此对球队战术和人员进行调整。除此之外，系统还会在比赛或训练结束以后，自动生成比赛报告和总结，以供球员和教练针对弱点进行改进。举例来说，教练可以实时观看到球员在比赛中的投篮热区，以此来安排战术。教练还可以看到球队在低位、中远距离以及转换进攻中的强点和弱点，以此来对人员进行调整。

在球场下的电脑和平板上，教练能够随时观看球员位置和数据（图片来源：ShotTracker官网）

目前，此项技术已经在美国篮坛获得了广泛应用。在过去的两年之中，全国大学校际体育协会（NAIA）在旗下的篮球比赛中已经使用了此项技术，取得的效果也非常好。随着现代篮球球场上的形势越发瞬息万变，未来将会有更多职业篮球队寻求类似于ShotTracker这样的技术来搜集球场数据，并实时调整球队战术。

目前，ShotTracker已经获得了NBA专业人士的青睐，包括大卫·斯特恩和“魔术师”约翰逊在内的NBA人士和机构已经对这一项目投资了接近2100万美元，并有可能在未来几年内运用到NBA赛场之上。

前NBA主席大卫·斯特恩表示，通过实时传递数据和生成报告，ShotTracker有可能会成为一项“彻底改变篮球运动”的技术。对球员和教练而言，ShotTracker能够提供足量的信息和洞见，让他们体验到与以往完全不同的篮球比赛。

未来，高科技将会全面渗透进NBA领域。VR和SportVU能够提供给观众全新的观战体验，低温冷冻技术和纳米科技能让运动员减少伤病的困扰。而ShotTracker能够帮助教练和球员改善训练，加强赛场表现。在这些高科技的武装下，NBA也将会给球迷们呈现更多精彩的比赛。

一 数据分析处理需求分类

1 事务型处理

在我们实际生活中，事务型数据处理需求非常常见，例如：淘宝网站交易系统、12306网站火车票交易系统、超市POS系统等都属于事务型数据处理系统。

这类系统数据处理特点包括以下几点：

一是事务处理型操作都是细粒度操作，每次事务处理涉及数据量都很小。

二是计算相对简单，一般只有少数几步操作组成，比如修改某行的某列;

三是事务型处理操作涉及数据的增、删、改、查，对事务完整性和数据一致性要求非常高。

四是事务性操作都是实时交互式操作，至少能在几秒内执行完成;

五是基于以上特点，索引是支撑事务型处理一个非常重要的技术。

在数据量和并发交易量不大情况下，一般依托单机版关系型数据库，例如ORACLE、MYSQL、SQLSERVER，再加数据复制(DataGurad、 RMAN、MySQL数据复制等)等高可用措施即可满足业务需求。

在数据量和并发交易量增加情况下，一般可以采用ORALCE RAC集群方式或者是通过硬件升级(采用小型机、大型机等，如银行系统、运营商计费系统、证卷系统)来支撑。

事务型操作在淘宝、12306等互联网企业中，由于数据量大、访问并发量高，必然采用分布式技术来应对，这样就带来了分布式事务处理问题，而分布式事务处理很难做到高效，因此一般采用根据业务应用特点来开发专用的系统来解决本问题。

2 数据统计分析

数据统计主要是被各类企业通过分析自己的销售记录等企业日常的运营数据，以辅助企业管理层来进行运营决策。典型的使用场景有：周报表、月报表等固定时间提供给领导的各类统计报表;市场营销部门，通过各种维度组合进行统计分析，以制定相应的营销策略等。

数据统计分析特点包括以下几点：

一是数据统计一般涉及大量数据的聚合运算，每次统计涉及数据量会比较大。

二是数据统计分析计算相对复杂，例如会涉及大量goupby、 子查询、嵌套查询、窗口函数、聚合函数、排序等;有些复杂统计可能需要编写SQL脚本才能实现。

三是数据统计分析实时性相对没有事务型操作要求高。但除固定报表外，目前越来越多的用户希望能做做到交互式实时统计;

传统的数据统计分析主要采用基于MPP并行数据库的数据仓库技术。主要采用维度模型，通过预计算等方法，把数据整理成适合统计分析的结构来实现高性能的数据统计分析，以支持可以通过下钻和上卷操作，实现各种维度组合以及各种粒度的统计分析。

另外目前在数据统计分析领域，为了满足交互式统计分析需求，基于内存计算的数据库仓库系统也成为一个发展趋势，例如SAP的HANA平台。

3 数据挖掘

数据挖掘主要是根据商业目标，采用数据挖掘算法自动从海量数据中发现隐含在海量数据中的规律和知识。

数据挖掘主要过程是：根据分析挖掘目标，从数据库中把数据提取出来，然后经过ETL组织成适合分析挖掘算法使用宽表，然后利用数据挖掘软件进行挖掘。传统的数据挖掘软件，一般只能支持在单机上进行小规模数据处理,受此限制传统数据分析挖掘一般会采用抽样方式来减少数据分析规模。

数据挖掘的计算复杂度和灵活度远远超过前两类需求。一是由于数据挖掘问题开放性，导致数据挖掘会涉及大量衍生变量计算，衍生变量多变导致数据预处理计算复杂性;二是很多数据挖掘算法本身就比较复杂，计算量就很大，特别是大量机器学习算法，都是迭代计算，需要通过多次迭代来求最优解，例如K-means聚类算法、PageRank算法等。

因此总体来讲，数据分析挖掘的特点是:

1、数据挖掘的整个计算更复杂，一般是由多个步骤组成计算流，多个计算步骤之间存在数据交换，也就是会产生大量中间结果，难以用一条sql语句来表达。

2、计算应该能够非常灵活表达，很多需要利用高级语言编程实现。

二 大数据背景下事务型处理系统相关技术

在google、facebook、taobao等大互联网公司出现之后，这些公司注册和在线用户数量都非长大，因此该公司交易系统需要解决“海量数据+高并发+数据一致性+高可用性”的问题。

为了解决该问题，从目前资料来看，其实没有一个通用的解决方案，各大公司都会根据自己业务特点定制开发相应的系统,但是常用的思路主要包括以下几点：

(1)数据库分片，结合业务和数据特点将数据分布在多台机器上。

(2)利用缓存等机制，尽量利用内存，解决高并发时遇到的随机IO效率问题。

(3)结合数据复制等技术实现读写分离，以及提高系统可用性。

(4)大量采用异步处理机制，对应高并发冲击。

(5)根据实际业务需求，尽量避免分布式事务。

1相关系统介绍

1) 阿里CORBAR系统

阿里COBAR系统是一个基于MYSQL数据库的分布式数据库系统，属于基于分布式数据库中间件的分布式数据库系统。该系统是前身是陈思儒开发的“变形虫”系统(以前调研过)，由于陈思儒离开阿里去了盛大，阿里当心“变形虫”稳定性等问题，重新开发该项目。

该系统主要采用数据库分片思路，实现了：数据拆分、读写分离、复制等功能。由于此系统由于只需要满足事务型操作即可，因此相对真正并行数据库集群(例如TeraData等)，此类系统提供操作没有也不需要提供一些复杂跨库处理，因此该系统存在以下限制：

(1)不支持跨库的join、分页、排序、子查询。

(2)insert等变更语句必须包括拆分字段等。

(3)应该不支持跨机事务(以前变形虫不支持)。

说白了此类系统不具备并行计算能力,基本上相当于数据库路由器!

另外此类系统的在实际应用的关键问题是，根据什么对数据进行切分，因为切分不好会导致分布式的事务问题。

2) 阿里OceanBase系统

该系统也是淘宝为了解决高并发、大数据环境下事务型处理而定制开发的一个系统。该系统主要思路和特点如下：

(1)他们发现在实际生成环境中，每天更新的数据只占总体数据的1%不到，因此他们把数据分为：基线数据和增量更新数据。

(2)基线数据是静态数据，采用分布式存储方式进行存储。

(3)只在一台服务器上存储和处理增量更新数据，并且是在内存中存储和处理更新数据。

(4)在系统负载轻的时候，把增量更新批量合并到基线数据中。

(5)数据访问时同时访问基线数据和增量更新数据并合并。

因此这样好处是：

(1)读事务和写事务分离

(2)通过牺牲一点扩展性(写是一个单点)，来避免分布式事务处理。

说明：该系统虽然能处理高并发的事务型处理，号称很牛逼，但其实也只是根据电商的事务处理来定制开发的专用系统，个人认为其技术难度小于oracle等通用型的数据库。该系统无法应用到银行或者12306等，因为其事务处理的逻辑远远比电商商品买卖处理逻辑复杂。

在目前的大数据时代，一定是基于应用定制才能找到好的解决方案!

3) 基于Hbase的交易系统

在hadoop平台下，HBASE数据库是一个分布式KV数据库，属于实时数据库范畴。支付宝目前支付记录就是存储在HBASE数据库中。

HBASE数据库接口是非SQL接口，而是KV操作接口(基于Key的访问和基于key范围的scan操作)，因此HBASE数据库虽然可扩展性非常好，但是由于其接口限制导致该数据库能支持上层应用很窄。基于HBASE应用的设计中，关键点是key的设计，要根据需要支持的应用来设计key的组成。

可以认为HBASE数据库只支持作为KEY的这一列的索引。虽然目前HBASE有支持二级索引的方案，二级索引维护将会比较麻烦。

2并发和并行区别

并发是指同时执行通常不相关的各种任务，例如交易型系统典型属于高并发系统。

并行是通过将一个很大的计算任务，划分为多个小的计算任务，然后多个小计算任务的并行执行，来缩短该计算任务计算时间。

两者主要区别在于：

(1)通讯与协调方面：在并行计算中，由于多个小任务同属一个大的计算任务，因此小任务之间存在依赖关系，小任务之间需要大量通讯和协调;相反，并发中的多个任务之间基本相互独立，任务与任务之间相关性很小。

(2)容错处理方面：由于并发任务之间相互独立，某个任务执行失败并不会影响其它的任务。但是并行计算中的多个任务属于一个大任务，因此某个子任务的失败，如果不能恢复(粗粒度容错与细粒度容错)，则整个任务都会失败。

3本章总结

数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量

三 大数据背景下数据统计分析技术介绍

随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计算方式来加快单个统计分析任务执行速度。

1并行查询与并行计算技术介绍

在大数据背景下的数据统计分析技术门类很多，常见的有：

n MPP并行数据库 : TeraData、GreenPlum、Vertica等。

n 基于MapReduce并行计算框架的数据仓库：

HIVE(Hadoop平台) 、Tenzing(Google公司)

n 基于Hbase的Phoenix系统

n HadoopDB系统

n EMC公司的hapt系统

n MPP分布式查询引擎： Dremel、Impala、Presto、Shard query、Citusdb。

n 基于SPARK的Shark、基于Dryad的SCOPE、基于Tez的stinger。

n 基于hadoop+index的JethroData系统

n 基于内存计算的Druid系统

这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了SQL或者类SQL接口。

为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。

首先所有的系统都可以分为三个层次: 语义层、并行计算引擎层、分布式存储层。语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。

对于提供类SQL接口并行计算系统，语义层可以认为是SQL解析层。

1) 语义层

SQL语言是一种声名式语言，SQL只是表达了要做什么，而没有表达怎么做。为此，SQL解析层主要作用是：将用户提交的基于SQL的统计分析请求，转化为底层计算引擎层可以执行的执行计划。也就是解决“怎么做”的问题。

SQL解析层工作主要包括两个大方面:

(1) 通过语法分析技术来理解要做什么。在关系数据库中，一般会把SQL语言分析后，形成树型结构的执行计划。

(2) 在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。

优化可以分为两个方面：一是逻辑层面优化、二是物理执行层面优化。

(1) 逻辑层优化

逻辑层面个人认为主要是因为同样表达一个分析请求，有的人SQL写的好，有的人SQL写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的sql变换为好的写法。

比较典型优化是：“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。

(2) 物理层优化

物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。生成物理查询计划的工作包括:

ü 增加一些操作符： 包括扫描和排序等。

ü 确定各个操作符实现算法。例如扫描是全表扫描还是利用索引;Join是采用HASH连接、索引连接、合并排序等实现算法中的那一种。

ü 确定操作符之间的数据流转方法：物化还是流水线方式。

ü 采用基于代价估算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的IO量。另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。

在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。传统数据库在数据Load过程中会事先计算好这些统计信息。并行计算中还需要考虑通讯代价。

需要指出是，由于imapla、Presto、HIVE等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在HDFS系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规则静态优化。根据SHARK论文，SHARK系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。

(3) 物化与流水线执行方法

一条SQL语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条SQL语句执行其实是有多个操作符组合而成的的树型结构计算流。如下图：

针对该计算流有两种执行方式：一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。

第一种方法的过程是： 把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所...