• 推荐：QPS亿级、RT毫秒级

• 报表：QPS低、RT秒级、报表数量2w+

• 大屏：QPS低、RT毫秒级，数据推送实时更新

• 营销圈人：QPS要求低、RT要求低，圈人数据量大(千万甚至亿级)

• 数据产品：数据产品服务多样化，数据服务10w+

• 销售指标

• 流量指标

• 用户特征

如图所示，大数据平台的演进之路主要分为三个阶段：

接下来讲述一下大数据服务平台的核心架构。

数据服务平台能够解决数据服务统一化，便于数据服务的治理、指标口径的统一。能够提升业务的开发效率，更快的面对业务的变化。数据服务平台主要分如下三层：

旁边的话主要是对平台的管控，比如权限管理、监控、限流熔断、元数据管理、服务编排等，这一块后面会展开给大家讲一下。

• 数据应用接入层：主要是针对外部应用接入，包含：HTTP服务、RPC服务、Client 服务、流服务、文件服务

• 数据服务解析层：主要通过SQL方式访问各种数据存储，然后生成对应数据服务。基于Apache Calcite。核心功能：SQL解析、SQL校验、SQL路由、SQL优化、SQL执行、SQL诊断限流

这里简单解释一下SQL诊断限流。比如说我们很多报表都在用同一个库里的某一张表，然后可能有些人写的SQL不是很准确或者说有问题，但它也能跑出来数据。比如BI，他们的SQL能力可能没有那么强，不会优化SQL，可能写的SQL就有问题。然后跑出来的数据就非常慢，可能会导致它的请求一直在挡这个表，把这个表拖垮，甚至可能导致这个库被拖垮，这样的话我们就需要对它进行诊断。当我们发现它超过一个耗时还没有返回数据，我们就需要把它的请求截断，避免影响其他业务。

• 数据存储层：主要包含数据的存储管理，MySQL、Redis、Hive等等。都能很好的支持、提供API服务

接下来我们来看一下数据服务生产的整体流程：

• 选择数据存储(Hbase、MySQL等等)

• 配置查询SQL和参数

//统计某一天的每个店铺的销售额select shop_id,sum(gmv) as total_gmv from (select * from table where dt=#{dt}) tgroup by shop_id;

• 根据选择数据存储引擎，将SQL转化成可执行的语言进行执行

• 生成原子接口服务

至此一个API服务就完完整整的生成了，可以理解为一个原子服务。

但是问题仍然来了，生产了一个根据用户id查询订单的原子服务A，生产一个根据订单id查询商品的信息的原子服务B。流程图如下：

如果需要查询出某个用户下某个订单的所有商品信息，就需要先调用订单服务API，然后根据返回的结果调用商品服务API，最后才能拿到想要的信息。

这个过程可能需要调两个服务。大家可能会想：我自己用代码写一个不就完了嘛。现在是两个服务，以后可能是三个服务、四个服务，服务之间可能有一些业务逻辑，这样的话你是用代码能够写出来。但是如果需求再变更，你是不是还要修改自己的代码或修改自己的业务逻辑？然后加上上线、测试等等，这种耗时是非常长的

当调用的服务越来越多，需要手动开发的成本越来越高，上线、发版还有测试这种时间是非常长的。中间的数据转化成本也越来越高，像上文所说，一个接口的出参不一定是另一个接口的入参，这样的话你可能需要做一些参数的转换。

因此，低代码平台(Low Code)服务编排应运而生。

服务编排：指对于原子服务进行串接、参数转换，以及一些业务逻辑的判断进行处理，只需要编写少量的代码即可完成

下面用例子来讲解一下：

服务串行：

订单服务的出参经过数据格式的转换作为商品服务的入参，将服务串联起来。

服务并行：

C接口需要等待AB接口同时调完才能进行。

服务不同逻辑处理：

这里需要进行一个逻辑的判断。

本次演讲内容介绍大数据服务平台整体建设思路和实践，但仍然难免有些疏漏：

• 随着国内数据库发展迅速，比如：国产IOT相关的数据库，Tdengine，如何将IOT相关的场景引入进来，更快地支持更多的数据存储。

• 数据平台服务化在大数据整体建设中如何扩大其服务对象，包括对：数据分析人员、运营人员甚至算法训练师，而不仅仅是针对数据人员和开发人员；

• 面向算法人员：支持算法服务化、算法编排、策略编排；

• 面向分析师和运营人员：支持报表数据管控。