数据平台设计思路：跨越大数据与业务的鸿沟，解决数据开发痛点

hwyzw

    近年来，随着IT技术、大数据、机器学习、算法的不断发展，越来越多的企业认识到了数据的价值，将数据作为自己的宝贵资产进行管理，并利用大数据和机器学习的能力挖掘、识别和利用数据资产。如果缺乏有效的整体数据架构设计或者某些能力的缺失，业务层将很难直接利用大数据。大数据和商业将会产生巨大的差距。这种差距的出现，就会导致企业在使用大数据的过程中出现问题。数据不可知，需求难以实现，数据难以共享。本文介绍了一些数据平台的设计思路，帮助企业减少数据开发的痛点和难点。

    本文主要包括以下章节：

    本文第一部分介绍了大数据的基本组成和相关知识。

    第二部分将介绍架构和kappa架构。

    第三部分将介绍kappa架构模型下的通用大数据架构。

    第四部分介绍了暴露的数据架构体系下数据的端到端难点和痛点。

    第五部分介绍优秀大数据架构的总体设计

    从第五部分开始，我们将介绍如何通过各种数据平台和组件，将这些大数据组件组合起来，打造高效易用的数据平台，提高业务系统的性能，让业务开发不再是害怕复杂的数据开发组件。无需关注底层实现。您只需要能够使用SQL完成一站式开发，完成数据回流，让大数据不再是数据工程师的专属技能。

    1. 大数据技术栈

    大数据的整体流程涉及多个模块，每个模块都比较复杂。下图列出了这些模块和组件及其功能特性。会有专题详细介绍相关模块领域的知识，如数据采集、数据传输、实时计算等。 、离线计算、大数据存储等相关模块。

    2.架构和kappa架构

    目前基本上所有的大数据架构都是基于kappa和kappa架构。不同的公司根据这两种架构模型来设计适合自己公司的数据架构。该架构使开发人员能够构建大规模分布式数据处理系统。它具有良好的灵活性和可扩展性，对硬件故障和人为错误的容忍度也很高。你可以在网上找到很多关于该架构的相关文章。 kappa架构解决了架构中两套数据处理系统带来的各种成本问题。这也是目前批量集成的研究方向。许多公司已经开始使用这种更先进的架构。

    建筑学

    卡帕建筑

    3、Kappa架构及架构下的大数据架构

    目前各大公司基本都采用kappa架构或者架构模式。这两种模式下，发展初期的大数据整体架构可能如下：

    4.数据端到端痛点

    虽然上面的架构看似将多种大数据组件串联起来进行集成管理，但是接触过数据开发的人都会强烈感受到，这样的裸架构进行业务数据开发需要注意很多基础工具的使用。在实际的数据开发中存在很多痛点和难点，具体体现在以下几个方面。

    如果没有数据开发IDE来管理整个数据开发流程，长期流程就无法管理。

    没有标准的数据建模体系，导致数据工程师对指标的理解不同、计算口径不同。

    大数据组件的开发要求较高，普通业务直接使用Hbase、ES等技术组件会出现各种问题。

   

    基本上每个公司的大数据团队都很复杂，涉及很多环节。遇到问题时，很难定位并找到相应的负责人。

    数据孤岛难以突破，跨团队、跨部门共享数据困难，彼此不知道对方有什么数据。

    需要维护批计算和流计算两套计算模型，开发上手困难。需要提供一套统一的流式和批式的SQL。

    缺乏公司级元数据系统规划，导致实时和离线相同数据的复用和计算困难，每个开发任务都需要进行各种梳理。

    基本上，大多数企业在数据平台治理和提供开放能力方面都存在上述问题和痛点。在复杂的数据架构中，对于数据应用方来说，每一个环节的不清晰或者某个功能的不友好都会让复杂的环节变更变得更加复杂。如果想要解决这些痛点，就需要精心打磨每一个环节，将上述技术组件无缝连接起来，让业务能够像编写SQL查询数据库一样轻松地端到端使用数据。

    5.优秀的大数据整体架构设计

    提供多种平台和工具辅助数据平台：多数据源数据采集平台、一键式数据同步平台、数据质量与建模平台、元数据系统、统一数据接入平台、实时与离线计算平台、资源调度平台，一站式开发IDE。

    6、元数据——大数据系统的基石

    元数据连接数据源、数据仓库和数据应用，记录数据从产生到消费的完整环节。元数据包含静态表、列、分区信息（即动态任务与表依赖映射关系；数据仓库模型定义、数据生命周期；以及ETL任务调度信息、输入输出等元数据）是数据管理、数据处理的基础。例如，元数据可用于构建任务、表、列和用户之间的数据图；构建任务DAG依赖关系并安排任务执行顺序；并提供个人或BU的管理；资产管理和计算资源消耗概述等。

    可以认为整个大数据的数据流都是通过元数据来管理的。没有一套完整的元数据设计，就会出现数据难以追踪、权限难以控制、资源难以管理、数据难以共享等问题。

    很多公司都是依靠Hive来管理元数据，但我个人认为，发展到一定阶段，还是需要搭建自己的元数据平台来匹配相关架构。

    关于元数据，可以参考饿了么的一些实际例子：

    7、流量与批次综合计算

    如果维护两套计算引擎，比如离线计算的Spark和实时计算的Flink，会给用户带来很大的麻烦。他们既需要学习流计算知识，又需要学习批计算领域知识。如果你实时和离线使用Flink和Spark，你可以开发自定义的DSL描述语言来匹配不同计算引擎的语法。上层用户无需关注底层的具体执行细节。他们只需要掌握一门DSL语言就可以完成Spark和Flink等计算引擎的接入。

    8.实时、离线ETL平台

    ETL代表--Load，用于描述从源到目的地提取()、转换()、加载数据的过程。 ETL这个术语更常用于数据仓库，但它的对象并不限于数据仓库。总体而言，ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面发挥着重要作用。 ETL作为重要的数据清洗中间层，一般来说至少必须具备以下功能：

    支持多种数据源，如消息系统、文件系统等。

    支持多种算子，包括过滤、切分、转换、输出、查询数据源补全等算子能力

    支持动态变化逻辑。例如上面的算子可以通过动态jar方式提交，在不停止服务器的情况下发布变更。

    9、智能统一查询平台

    大多数数据查询都是由需求驱动的。针对每一个需求，开发一个或多个接口，编写接口文档，开放给业务方调用。该模型在大数据系统中存在很多问题：

    这种架构简单，但接口粒度很粗，灵活性不高，扩展性差，复用率低。随着业务需求的增加，接口数量大幅增加，维护成本较高。

   

    同时，开发效率不高，这显然会造成海量数据系统的大量重复开发，导致数据和逻辑难以复用，严重降低业务用户的体验。

    如果没有统一的查询平台将Hbase等库直接暴露给业务，后续的数据权限运维管理将会更加困难。访问大数据组件对于业务用户来说也是痛苦的，一不小心就会出现各种问题。 。

    通过一套智能查询解决大数据查询的上述痛点

    10.数据仓库建模标准体系

    随着业务复杂度和数据规模的增大，数据调用和复制混乱、重复建设造成的资源浪费、数据指标定义不同造成的模糊性、数据使用门槛越来越高。以笔者亲眼目睹的实际业务埋点和数据仓库使用为例，同产品名的表字段有的是命名的，有的是命名的，还有很多其他的名字，这会给想要使用的人带来很大的麻烦这些数据。因此，如果没有完整的大数据建模体系，将会给数据治理带来很大的困难，具体体现在以下几个方面：

    数据标准不一致，即使命名相同，定义也不一致。例如，仅 uv 指标就有十多个定义。出现的问题是：两者都是紫外线，我应该使用哪一种？都是UV，为什么数据不一样？

    这导致巨大的研发成本。每个工程师都需要了解研发过程自始至终的每一个细节。大家都会再次经历同样的“坑”，这对研发人员来说是浪费时间和精力成本。这也是目标作者遇到的问题。实际开发和提取数据太困难了。

    没有统一标准管理，造成重复计算等资源浪费。数据表层次和粒度不清晰也导致重复存储严重。

    因此，大数据开发和数据仓库表设计必须遵循设计原则。数据平台可以开发平台来约束不合理的设计，比如阿里巴巴的系统。一般来说，数据开发按照以下准则进行：

    有兴趣的可以参考阿里巴巴的设计系统。

    11、一键集成平台

    非常简单，一键收集各种数据到数据平台，并通过数据传输平台将数据无缝连接到ETL平台。 ETL与元数据平台对接，标准化定义，然后将数据转换、导流到实时、离线计算平台。后续任何对数据的离线和实时处理，只需申请元数据表权限即可开发任务并完成计算。数据采集​​支持多种数据源，如日志采集、前端埋点、kafka消息队列等。

    12、数据开发IDE——高效的端到端工具

    高效的数据开发一站式解决工具。通过IDE可以完成实时计算和离线计算任务的开发，并连接上述所有平台，提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量、数据服务等全方位的产品服务。拥有一站式开发管理界面，通过数据IDE完成数据传输、转换、集成等操作。引入不同数据存储的数据，进行改造和开发，最后将处理后的数据同步到其他数据系统。通过高效的大数据开发IDE，大数据工程师基本上可以屏蔽掉各种痛点，结合上述多平台能力，让大数据开发像写SQL一样简单。

    数据开发工具请参考阿里云。

    解决端到端的困难还需要其他几个能力的协助，这里不再赘述。有兴趣的同学可以自行研究。

    13. 其他

    完整的数据系统研发还包括报警监控中心、资源调度中心、资源计算隔离、数据质量检验、一站式数据处理系统等，这里不再赘述。

    技术原创、架构实践文章，欢迎通过公众号“联系我们”菜单提交。

    高可用架构

    改变互联网的构建方式