星环科技是一家成立于三年前的致力于大数据基础平台的高科技软件公司，公司目前主要有三条产品线，第一个是Transwarp Data Hub，其中包括Inceptor（PL/SQL引擎交互分析、图计算）、Stream（流处理引擎）、Discover（数据挖掘、机器学习）和Hyperbase（NoSQL数据库综合搜索）等。

 

　　第二个是TOS，是基于现在比较热门的容器技术来做的，TDH上的各个组件加上TOS的话就能够使它做成一个微服务架构。像集装箱的运输，能够标准化，并且能够把我们的资源做隔离。这样的好处是能够把这种服务做到快速启动部署，第二个是能够做到弹性扩容，就是按需要来做。

 

　　第三个是大数据超融合一体机TxData，实现软硬一体交互，预装产品，能够实现快速交付。并且软件针对硬件优化，相同价格下大概能够实现2倍以上的性能，大大提高性价比。

 

　　其次，再来看下基于这些底层平台技术落地的案例以及架构设计：第一个是数据仓库的架构，这是我们客户的一个核心报表系统，他原来也是一个传统的架构，但是随着他的数据量不断增加，传统架构已经无法满足他业务上的需求。可以从三个方面来看一下，第一个是生产数据的加载，随着数据量和业务系统不断增加，会有上百个数据加载接口，每天有数千万条记录。第二在分析处理类的应用，上面有数百个数据报表，包括经营分析、运营监控等等。第三交易处理应用，交互类应用和即席查询，每天有550万左右的查询，峰值达到30万/小时。这种传统的架构不能满足业务的需求，所以客户要把数据仓库从传统数仓迁移到基于Hadoop的新一代数仓。

 

　　传统数仓存在的问题总结一下：第一是存储空间不足，原先设计的架构是存储三年的量，但是因为数据增长太快，两年就存不下了，大部分报表只能使用半年历史数据。第二是处理性能不足，它原来的数据是6个小时把跑批、计算分析都要做出来，现在是11小时，这是很影响业务系统的。客户的架构原先是MPP架构，扩容成本是非常高的。第三是传统的架构会用到一些像星型雪花型的数据模型，但这些模型不适用于大数据时代，大表之间的关联操作会消耗非常多的资源，也会消耗非常多的时间。但是在大数据时代hadoop平台架构是这样设计的：我们对数据做预处理，提前将数据表做关联，拉成一个大宽表。查询操作直接访问这些宽表，这样就不需要每次查询再去关联。还有一个是我们对于非结构化数据的支持，刚才也提到了。因此，随着hadoop技术的不断成熟，这种基于普通X86服务器上的低成本高效率的数据开发方案已经应用成熟了。在相近性能下，这是两种方案硬件上的对比，TD上使用了6+4的一体机，而使用我们TDH平台是19台×86PC机，2管理节点和17计算节点，成本只是前者的零头而已。

 

　　第二个案例是我们做的自助分析平台，这是当前的数据请求逻辑，业务部门需要向科技部门申请数据需求，如果有则再做相应的权限审批等等，如果不存在则需要根据需求来建立报表、系统等，然后根据权限再做相应的处理。而这一系列的逻辑操作是存在一些明显的不足的。第一个是时间延迟，因为经过反复的逻辑处理，涉及多个部门之间交互；第二个是数据安全性，以提数为例，科技部门会直接把数据下放到业务部门，但是业务部门拿到这个数据就可以做任何操作了，这样就失去了对数据的管控，存在安全性的问题；第三是一致性，业务部门拿到数据之后有可能第二天科技部门就已经把数据更新了，而他们两者之间的结果是不一样的；最后是分析性能问题，如果业务部门拿到数据之后做相应的单点分析计算，就没有利用到科技部门现有的集群或内部的计算资源。

 

　　所以一个改进后的数据请求逻辑简化为只涉及到业务部门和信息管理部门，信息管理部门对于业务部门提出的数据需求进行权限审批，如果通过了之后，业务部门就可以做相应的自主查询，从而就解决了前面提到的时间延迟、数据安全、一致性和分析性能的问题。这是自助分析平台的架构。

 

　　第三个案例是交通稽查布控平台，这个系统比较大，这是交通稽查布控平台示意图，主要实现的是两个业务逻辑。第一个是对于黑名单车辆的追踪，第二个是对于套牌车辆的稽查。今天的活动在深圳举办，我们就以深圳作为场景举例。摄像头在宝安区捕获到一个粤B·12345进了黑名单的车牌信息，通过摄像头捕获的数据进入统一稽查布控平台，然后通过实时数据处理技术进行业务规则的实现来判断是不是已经进入了黑名单，然后再向收费站、公安局或派出所发送报警信息。对于套牌信息也是一样的，但是时间的延迟需要注意，套牌是在两个地方，宝安区或罗湖区，空间上是相差很远的。举例，如果在10分钟之内一样的车牌出现在两个地方，这在物理上是不可能的，也就是一个套牌车。

 

　　回过来，看看传统的架构是什么样的实现逻辑？把成千上万个摄像头的数据拉过来，然后放到数据处理中心里面，然后再在非业务时间（一般是晚上）来计算，看是不是套牌或者进入黑名单。但是往往事后追查的机制是没有很大意义的。因为拿到结果的时间可能会是晚上，而卡口检测到的数据的时间可能是白天，所以车辆实际已经离检测地点可能都很远了。再来看基于大数据平台的交通稽查布控平台架构设计，是这样来做的：通过摄像头捕获到的数据作为生产者入到分布式消息队列里面Kafka集群。然后对接上我们的Stream组件，做业务规则的实现，做到实时数据的研判，从而判断是不是黑名单车、套牌车发出告警信息。另一方面，也可以将这部分数据持久化到我们的hyperbase实时数据库中供后续的检索插叙。

 

　　以上是我们三个引擎落地的案例，下面再来看一下行业案例。我们要做到的是一个轻前端、重后端的架构。先看关系型数据库与BI结合的逻辑，通常第一步BI都是从关系数据库里面把数据拿过来，第二步然后做相应的加工处理，然后做相应的报表展示，最后如果还有相应的需求在将数据写入关系型数据库持久化以备后面的查询，这是一个传统的，轻对轻的这么一个架。但是随着数据量不断增加，相应的业务逻辑的转变。原来是把数据拉到BI应用服务器上，随着数据量不断增大，我们会发现，慢慢的我们拥有的是一个轻对重的架构，而如果仍然把数据从底层拉到上层的话，大量的数据交互就会造成性能瓶颈，也是不可取的。所以在大数据阶段要做的是轻对重的架构，需要把数据以及计算下压到大数据平台。再来看看hadoop和BI的结合，第一步做的是从应用服务器BI上到底层的hadoop平台是一个关联的操作，没有任何的数据交互。第二步如果做相应的加工操作的话，应用服务器只是发布一条SQL指令到底层，然后做加工处理制作成所需要的表格。如果需要做相应的展示操作发布指令，通过hadoop底层把数据推送到上层的，最后给业务人员做渲染展示。

 

　　第二行业案例是一个企业投资任职关系的分析，底层应用的技术就是图计算。企业A对企业B进行投资，企业B对企业C进行投资，可以从中分析出是否存在关联交易的情况。还有我们经常能够看到的担保链的分析，互相担保是存在信用欺诈风险的，反映到底层的技术，要求计算出来是不是存在这么一个逻辑的闭环，如果没有的话就没有这种欺诈。

 

　　最后是我们给出的大数据时代的一些发展趋势。这里不再详细讲述。

 

　　实际上，正是有了这些客户的需求，才会反过来推动技术的变革以及创新架构的设计，进而推动我们的大数据技术在各种行业的应用。