大数据平台建设思考

现在企业都有建设自己大数据平台，大数据平台（包含传统数据仓库）架构基本上也大同小异，基本架构如下：

架构包含三个层级：数据采集层，数据计算层，数据应用层。数据采集支持T+1,实时同步；数据存储以Hadoop的HDFS为主，计算主要以MR及Spark为主；数据仓库构建在Hive之上，实时查询构建在Presto或Impala之上。数据应用层会提供查询接口，报表产品，数据产品供分析及业务部门来使用。这样貌似都OK了，可以High起来，实际上随着公司业务及人员的增长，可能会出现如下几个问题：

1、业务在获取数据便捷性及个性化需求方面仍然会不满意。因为平台建设之初，更多的是提供通用服务，个性化服务满足考虑较少。比如，想快速地获取我想要的数据以便快速支持决策，业务想自己DIY数据，比如数据自我探查，个性化的仪表盘等。

2、数据平台仍然只是个服务于业务运营的平台，无法给整体IT系统赋能，带来更大溢出效应。

3、平台业务大部分都是基于T+1业务，对于(准)实时计算需求仍然没有很好的解决方案，对于用户行为日志固然可以通过SparkStreaming来做批次计算，但是对于一些统计逻辑复杂，比如整个计算过程有1千多条SQL，要关联几十个表这种情形，显然目前是没有很好的解决方案。假如说要实现实时与T+1的Cross分析，基本就没法玩了。

4、数仓的核心是数据仓库建模，这是数仓的血肉。如果没有专门岗位为整体数仓建模负责，没有人为从数据产生到转换到消费负责，整个数仓最终有可能走向烟囱式开发，指标重复，计算重复，最终用户越来越不满意。

基于此，提出大数据服务平台理念，当然数据平台本身就应含有服务之意，但这里为什么又要提服务平台呢，目的之一是重视平台服务的本质，之二是重视把平台能力抽象成到处可用的通用服务能力。实践中，建设服务型大数据平台需要着重关注以下几点：

1、统一数据标准。指标的统计口径，字段，表的命名在整个数仓中只有一个，以保证数据服务的一致性。与之配套研发指标体系管理工具，通过工具来保证从开始到结束的命名规范和统计口径的一致性，同时与元数据系统打通，可以跟踪到字段，表，指标的血缘关系，每个指标的使用和资源占用情况。

2、公共处理逻辑下沉。以便端在使用时只需关注指标数据，具体复杂的转换逻辑不用关注，提升数据使用的便利性。

3、把关键业务基础指标，数据分析实践方法及算法模型抽象成服务，调用者只关注如何调用，而不用理会具体处理逻辑过程，在什么地方处理等。

4、重视数据获取便利性，让每个人都能快速获取想要数据，以形成整个公司数据驱动文化。

5、实时与离线统一平台原则。

基于此，重新思考大数据平台，架构如下：

首先，我们将以TiDB NewSQL数据库为技术核心建设数据平台的ODS层，这层有三个基础服务：

1）成为整个集团的数据分发中心，包括各小型财务，风控数据仓库系统，可连接我们TIDB同步数据，也可以订阅我们Kafaka消息组件的数据。

2）可以使用TIDB提供OlAP方析引擎TiSpark,进行快速数据聚合，以减轻应用系统存储和计算压力，目前有多个应用系统明细报表在使用我们的服务。

3）可提供实时与T+1 Cross分析解决方案，在Presto查询引擎上，使用TiDB的库表就像在本地使用一样，比较方便。

其次，我们将所有算法模型服务和指标体系都做成RestFul Api服务的形式，以方便应用系统随时调用，形成数据生产力。

最后，我们将建设灵活的数据分析平台和数据算法平台，让我们运营人员，数据分析师，算法工程师都可来DIY自己想要的数据，DIY算法模型，进一步降低数据使用的门槛，以便形成人人都是数据分析师，人人都是数据运营专家的局面。

总之，大数据平台建设需要一个过程，不可能一蹴而就，但在建设伊始，就确立正确的建设目标，按正确方法，科学实施，就能达到少走弯路，事半功倍的效果。

当然，服务型数据平台也不是建设的终点，在打牢服务的基础上，方向是朝智能（AI）数据平台发展，比如实现自动ETL，任务自动降级下线，平台自动运维等。

以上文字谨代表个人对大数据平台一些思考，受制个人经验，不当之处难免，欢迎各位同仁或专家一起商榷。