近年来，随着IT技术和大数据、机器学习、算法的不断发展，越来越多的公司意识到重视数据价值，将数据作为自身的宝贵资产进行管理，利用大数据和机器学习能力挖掘、识别和利用数据资产。如果缺乏有效的整体数据架构设计，或者缺少某些能力，就会导致业务层难以直接使用大数据和大数据。大数据和商业之间会有巨大的鸿沟。针对数据不可知、需求实现难、数据共享难等一系列问题，本文介绍一些数据平台设计思路，帮助企业降低数据开发的痛点和难点。为了写这篇文章，我研究了10家公司。1.大数据技术栈大数据整个过程涉及到很多模块，每个模块都比较复杂。下图列出了这些模块和组件及其功能特性。会有专题详细介绍相关模块的领域知识，比如数据采集。、数据传输、实时计算、离线计算、大数据存储等相关模块。2.Lambda架构和kappa架构目前大数据架构基本上都是基于lambda和kappa架构。不同的公司基于这两种架构模型设计符合公司的数据架构。lambda架构使开发人员能够构建大规模的分布式数据处理系统。它具有很好的灵活性和可扩展性，对硬件故障和人为错误也有很好的容错能力。您可以在Internet上找到许多有关lambda架构的相关文章。kappa架构解决了lambda架构中存在的两套数据处理系统带来的各种成本问题。这也是目前流批集成的研究方向。许多公司已经开始使用这种更先进的架构。Lambda架构Kappa架构3.kappa架构和lambda架构下的大数据架构目前各大公司基本都采用kappa架构或者lambda架构模式。在这两种模式下，大数据在发展初期的整体架构可能是这样的：4.数据端到端的痛点尽管上述架构看似是将多个大数据组件串联起来，实现一体化管理，但人们接触过数据开发的人，感受会更强烈。这样的裸架构业务数据开发需要注意很多基础工具的使用和实际数据开发中存在很多痛点和难点，具体体现在以下几个方面。缺少一个数据开发IDE来管理整个数据开发流程，无法管理长期流程。没有标准的数据建模体系，导致不同数据工程师对指标的理解存在误差，计算口径也不同。大数据组件开发要求高，普通业务直接使用Hbase、ES等技术组件会出现各种问题。基本上每个公司的大数据团队都会非常复杂，涉及到很多环节。遇到问题很难定位，很难找到相应的负责人。数据孤岛难以打破，跨团队跨部门数据共享难，对方有什么数据不清楚。需要维护两套计算模型，批计算和流计算，开发上手难度大。需要为流和批提供一套统一的SQL。公司层面缺乏元数据系统规划，同一份数据难以实时离线复用和计算，需要梳理每一个开发任务。基本上，大部分企业在数据平台治理和提供开放能力方面都存在上述问题和痛点。在复杂的数据结构下，对于数据适用方来说，各个环节的不明确或者某个功能的不友好都会让复杂的环节变化变得更加复杂。解决这些痛点，需要细心打磨每一个环节，无缝衔接以上技术组件，让业务端到端使用数据像写SQL查询数据库一样简单。5.优秀的大数据整体架构设计提供多种平台和工具助力数据平台：多数据源数据采集平台、一键数据同步平台、数据质量与建模平台、元数据系统、统一数据接入平台、实时和离线计算平台，资源调度平台，一站式开发IDE。6、元数据——大数据体系的基石元数据是打通数据源、数据仓库和数据应用，记录数据从产生到消费的完整链路。元数据包含静态表、列和分区信息（即MetaStore）。动态任务和表依赖映射；数据仓库模型定义、数据生命周期；ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如，元数据可用于构建任务、表、列和用户之间的数据图；构建任务DAG依赖，安排任务执行顺序；构建任务画像，进行任务质量管理；为个人或BU提供资产管理和计算资源消耗概览等。可以认为整个大数据数据流都是由元数据管理的。如果没有一套完整的元数据设计，就会出现上述数据难以追踪、权限难以控制、资源难以管理、数据难以共享等问题。很多公司都依赖hive来管理元数据，但是我个人认为在一定的发展阶段，我们还是需要搭建一个元数据平台来匹配相关的架构。7.流批一体计算如果维护两套计算引擎，比如离线计算Spark和实时计算Flink，会给用户带来很大的麻烦，需要同时学习流计算知识和批计算领域知识.如果你实时离线使用Spark或者Hadoop配合Flink，你可以开发自定义的DSL描述语言来匹配不同计算引擎的语法。上层用户无需关注底层的具体执行细节。他们只需要掌握一门DSL语言就可以完成Spark。接入Hadoop、Flink等计算引擎。8、实时和离线ETL平台ETL，即Extract-Transform-Load，用于描述数据从源到目的的抽取、转换、加载过程。ETL这个词在数据仓库中比较常用，但它的对象并不局限于数据仓库。总的来说，ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面起着重要作用。作为重要的数据清洗中间层，一般来说，ETL至少要具备以下功能：支持多种数据源，如消息系统、文件系统等支持多种算子、过滤、分段、转换、输出、查询数据源完成等运算符功能支持动态更改逻辑。比如上面的operators可以通过动态jar提交，在不停止服务器的情况下发布变更。九。智能统一查询平台上的大部分数据查询都是由需求驱动的。针对一个需求开发一个或多个接口，编写接口文档并开放给业务方。大数据体系下这种模式存在很多问题：这种架构简单，但是接口粒度很粗，灵活性不高，可扩展性差，复用率低。随着业务需求的增加，接口数量大幅增加，维护成本高。同时开发效率不高，对于海量数据系统显然会造成大量的重复开发，难以复用数据和逻辑，严重降低业务用户的体验。如果没有统一的查询平台将HBase等库直接暴露给业务，后续的数据权限运维管理会比较困难。访问大数据组件对于业务用户来说也是非常痛苦的，一不小心就会出现各种问题。.通过一套智能查询解决上述大数据查询痛点10.数据仓库建模标准体系随着业务复杂度和数据规模的增加，数据调用和复制混乱，重复构建造成资源浪费，数据索引定义各不相同。歧义和数据使用门槛越来越高。以笔者亲眼目睹的实际业务埋点和数仓使用为例，同品名的表字段有的是good_id，有的叫spu_id，还有很多其他的名字，会给想要的人带来很大的麻烦使用这些数据。因此，缺乏完整的大数据建模体系会给数据治理带来很大困难，具体表现在以下几个方面：数据标准不一致，即使命名相同，但定义不一致。比如uv这样的一个指标有十几种定义。问题是：都是uv的，我该用哪个？都是uv，为什么数据不一样？造成巨大的研发成本。每个工程师都需要从头到尾了解研发过程的每一个细节。大家又会踩到同一个“坑”，浪费了研发人员的时间和精力成本。这也是目标作者遇到的问题。实际开发和提取数据太难了。没有统一规范的标准管理，造成重复计算等资源浪费。数据表的层级和粒度不清晰，也造成重复存储严重。因此，大数据开发和数据仓库表设计必须坚持设计原则。数据平台可以开发平台来约束不合理的设计，比如阿里巴巴的OneData本体。一般来说，数据开发是按照以下准则进行的：
