星环科技吕品：创新架构推动大数据的行业应用

导读：日前，在星环大数据技术峰会上，星环的资深架构师吕品分享了《创新架构推动大数据的行业应用》的主题演讲，小编为大家推出了速记版干货！

以下为全文：

今天主要给大家介绍用hadoop做创新的架构在各个行业中的应用。首先，我想先简单的介绍一下星环的产品，以便于大家更好理解后面的这些应用是如何构建的。

可以从图中看到，这就是星环的整个产品架构，下面浅蓝色的部分是基础服务，比如常见的HDFS，存储数据的模块；比如YARN，管理资源的模块；剩下的部分是hadoop生态圈的其他组件，这些部分构成了我们的基础模块。而我们真正的产品是上面的四大块，这四个产品分别面对着大数据的四个问题，Inceptor应对数据量大的问题；Discover应对数据挖掘方面的问题；Hyperbase主要应对数据检索方面的问题，以及多种数据类型的存储问题；Stream应对的就是实时的问题。最后还有一个叫做Guardian的模块，意思就是守护者。这个平台在大公司里要供很多部门一起使用的，存在多租户的问题，所以这个Guardian专门用来认证用户身份，管理各个数据资源的权限。

Inceptor的特点是提供把hadoop包装成类似数据库的东西供大家使用。对外提供SQL接口，我们现在对SQL2003的支持程度达到99%，也就是基本不需要做什么改动就可以把传统的关系型数据库迁移到星环的产品上。实际上的案例就是，我曾经面对过8万多行的SQL，如果要把它重做成hadoop的应用，需要花费很多的时间，但最后迁移到我们的产品上只花了1个月不到的时间，由此可见我们的兼容程度是很高的。除此之外我们还提供PL/SQL的功能，例如银行的大量业务模型是写在Oracle里面的PL/SQL里面的，迁移到我们的平台上只需要1-2个月的时间。除此之外，我们还提供增删改查的功能，开源hadoop是没有的。

Discover，就是提供数据挖掘服务的。其实现在数据挖掘的应用场景越来越多，很多新的应用都是基于数据挖掘构建的。一些老的技术已经比较成熟，而Discover可以帮助客户去挖掘出一些新的模型，运用他们进一步提升业务的价值。比如一些用户画像，推荐系统等等都可以放在这一块。

Hyperbase主要是对象存储。以前可能结构化数据占80%-90%，但现在非结构化数据越来越多，特别是互联网，非结构化数据占到60%-70%，例如图片和视频，其实它们都是很有用的，像这一类的数据存在我们的平台上是非常方便检索的。

Stream流处理，能够处理数据量很大，又需要实时的接入进来。很多数据需要实时处理才有价值。举个例子，一辆车已经上了黑名单，那就需要摄像头拍到它的时候尽快通知拦截，但是如果数据没有实时处理，而是事后反馈的话，这辆车早就不知道跑到哪里了。所以我们的Stream会实现实时的处理，而且星环对Stream这个组件进行了加强，我们的产品只需要用SQL去操作就可以了，节省了很多开发成本。

以上就是我们的第一条产品线TDH。接下来我们的第二条产品线是TOS，我在这里只做简单的介绍。刚刚提到多租户的问题，现在的企业特别是大企业，数据量很大，他们千辛万苦的做出一个平台，希望每个部门都可以应用起来的。我们的TOS就是应对多租户的问题，把所有的硬件资源都管理起来，需要新应用的时候，只需要在TOS上申请一个新的容器和一定的计算资源，我们就可以把discover等等放进这个容器里，之后就可以直接运行起来。

最后我们的第三条产品线，我们不仅有软件产品，还有硬件产品，就是超融合一体机TxData。它是搭载我们的TDH和TOS的，它是预装产品，出场之后就可以快速交付，客户拿到手就可以立刻用。星环针对软硬件进行了特殊的优化，性能相比价格来说，优化了2倍以上。那么总体来说，它是可以降低成本的。

▷接下来介绍几个行业案例：

1、数据仓库的案例

这是我们某个客户的核心报表系统简介。它有上百个数据加载接口，其中部分每个接口每天加载数千万条记录。业务类型主要是报表类和分析类。另外还有一些交易处理应用的场景，例如交互类的应用以及即席查询，日均查询量达到550万左右。那么它遇到了什么问题呢？首先，它存储空间不足，他原来的平台使用了两年就达到了85%的使用率。第二，是处理性能的不足。分析类数据准备时间为6小时（每日凌晨0-6点）增长到目前的11小时（21-次日8点），占用了很多的工作时间。第三，它要做很多表的关联，也需要大量的时间。最后，还有一些非结构化数据例如图片视频音频等，他们没办法处理。

现在它们的整个平台已经基本成功迁移到星环了，我们利用现在服务器的高效和低成本已经解决了这些问题。硬件对比情况是这样的，原来他们用TD的小型机打造这个平台，整个硬件成本是千万级。而现在用我们可以达到相同性能的硬件，成本只有百万级。软件费也是类似的情况。

2、自助分析平台

这是一个银行的场景，业务部门发起一个数据需求，他会先看自己的平台上是不是有所需数据，如果有，就提交数据需求申请等待审批。如果没有他会找科技部门新建报表等。这个流程很繁琐而且比较长，第一个问题是时间延迟长，第二个问题是数据安全没有办法保证，另外还有数据一致性等的问题。

经过星环的规划，现在这个流程变成了如下的情况：我们打造了一个大数据自助分析平台，业务部门直接找专门管理信息的部门申请权限，申请通过即可自己去平台上使用数据自助查询。这个过程比较简洁，而且数据是没有办法下发的，只能上传，所以没有安全问题。另外就是一致性问题，所有人都在同一个平台上看，可以保证数据的一致性。最后是性能，所有人在同个平台上用，使用的是集群性能，这种分布式的集群性能要比单机版的好很多。

3、交通稽查布控

举个例子，我们有很多摄像头，深圳一共有3万多个摄像头，比如宝安区有一个，福田区有一个，罗湖区有一个。假如有一辆上了黑名单的车被摄像头拍下来了，那么实时处理就会让这个信息快速传送到我们的平台上，通知相关人员去拦截，而不是事后反馈，等我们看到这辆车被这个摄像头拍过的时候，它已经不知道去哪了。另外一种情况，就是套牌车。例如一辆车它出现在了宝安区的摄像头里，但是5分钟之后它又出现在了罗湖区的另一个摄像头里，那么就说明它是有问题的，因为它不可能用5分钟从宝安区跑到罗湖区。这种情况以前一般是把所有的摄像头信息传输到oracle的平台上，但是现在有几万个摄像头，处理的话我们希望是秒级的反馈，如果过10分钟反馈的话，可能这些信息就没有价值了。我们的平台架构是所有的摄像头信息传输到Kafka的分布式集群上，产生一个分布式消息队列，这是可以支撑住所有的数据的，然后我们做一个实时的消费，输入到Stream里面，我们拉出来历史的数据，一些黑名单等等，和实时的信息进行比对，最后在秒级以内就可以返回结果了。

4、BI结合hadoop发展

原来大家用数据的时候用BI非常多，因为它可以提供一个可视化的东西。在关系型数据库的时代，它的逻辑是原始的数据存在数据库里面，然后在另外一台服务器上进行提数，提到BI这边的服务器上进行一系列的操作，最后是展示，就是各种报表，然后可以通过JDBC在把报表传回来。在这种模式里面，数据库的作用是非常单一的，只是一个简单的存储，并没有用到计算功能。在数据量少的时候，这个模式也是没有问题的。但是到了大数据时代，这个路线是走不通的。数据库这端的数据量非常大，就导致会有大量的数据通过JDBC进行传输。

我们想要做的是把所有的数据操作转到数据库这一端，把处理逻辑写在数据库端，只把结果返回到上面一层。那么Hadoop BI的逻辑是我们把原始的表存在hadoop这边，在BI端做一个虚拟的关联，然后在BI端发送一些操作命令，通过SQL发送命令道hadoop端，进行底层的计算。最后所有的操作结果就是报表还是在hadoop这端，如果想要展示的话，可以在发送展示命令把结果传回BI端，那么就可以把小量的展示数据提取出来。这个模式是非常好的新模式，现在BI的厂商也都在向这个大数据BI方向努力。

5、数据挖掘在金融行业应用

这是一个小微在线融资征信的场景，小微企业选择服务之后，小微贷款服务平台会向税务等部门发送授权请求，然后得到反馈将这些信息发送给银行，银行进行审批，审批过后就可以直接把结果告诉小微企业了。这个过程背后还用到一些数据挖掘的算法，我们对每家企业选取200财务指标，用分类算法回归算法等对它进行评估，这样的步骤可以非常快速的完成。

6、企业关系分析

现在的企业非常多，他们之间的关系很复杂，从图中可以看出这些企业之间可能有供应商的关系，投资的关系，自然人之间也可能有亲属关系等等，我们可以运用图计算对这一系列的关系进行刻画。比如右边的图，我们发现大部分企业只有一家公司有关系，有100家公司和它有关系的公司很少。原来用mapreduce对这种关系进行计算的时候用时很长，但是用我们transwarp Graph就可以很快的计算，而且结果很清晰。

总结来说，第一，hadoop技术的应用场景会更加复杂化。原来它只用于ETL，但是现在hadoop已经进入数据仓库领域了。第二，数据的集成能力持续化。第三，数据类型多结构化，不仅仅是关系型数据，像互联网的图片视频等等信息都可以统一到hadoop的平台上来。第四，数据源更加统一透明。原来程序员需要学习多种语言技术来进行开发，未来我们只需要精通一种语言算法，把更多的时间投入到业务上。第五，数据获取更加灵活自由。第六，数据使用实时化。最后一点，如果以后SQL接口统一的话，开发运维门槛会大大下降。

来源：星环科技