数据中台之结构化大数据存储设计
数据中台（架构篇）
数据中台（架构篇）声明：本⽂归属所有。
@⼀⼨HUI在上⼀篇⽂章中主要介绍了建设数据中台要建设哪些内容、建设的步骤以及建设过程中需要遵循⼀定的规范并符合公司的战略。
也提及到了阿⾥巴巴数据中台的全景图，有了上⾯的基础，现在更能⽅便的理解数据中台的架构了。
先来回顾下数据中台的概念。
数据中台是⼀套可持续“让企业的数据⽤起来”的机制，是⼀种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施⽅法论⽀撑，构建的⼀套持续不断把数据变成资产并服务于业务的机制。
数据中台是处于业务前台和技术后台的中间层，是对业务提供的数据能⼒的抽象和共享的过程，数据中台通过将企业的数据变成数据资产，并提供数据能⼒组件和运⾏机制，形成聚合数据接⼊、集成、清洗加⼯、建模处理、挖掘分析，并以共享服务的⽅式将数据提供给业务端使⽤，从⽽与业务产⽣联动，⽽后结合业务系统的数据⽣产能⼒，最终构建数据⽣产>消费>再⽣的闭环，通过这样持续使⽤数据、产⽣智能、反哺业务从⽽实现数据变现的系统和机制。
数据中台功能定位数据中台的功能定位是完成公司内部数据能⼒的抽象、共享和复⽤，因此，数据中台的架构必须围绕这三个功能来设计。
与传统的⼤数据平台不同，数据中台搭建于⼤数据平台及数据仓库之上，将⼤数据平台和数据仓库所实现的功能以通⽤数据能⼒的形式提供给企业的所有部门。
因此，单从功能上来讲，⼤数据平台实现具体的数据能⼒，数据仓库是业务建模、数据治理发⽣的地⽅，⽽数据中台则需要把⼤数据平台、数据仓库的数据和接⼝组织起来，通过打通数据提升数据能⼒，通过共享提⾼全局使⽤效率。
因此数据中台的架构设计应该考虑如何有效地完成抽象、共享和复⽤的功能。
数据中台的建设应该贯穿数据处理的全⽣命周期，即从原始数据到最后产⽣数据价值的整个流程，且整个流程都处于数据中台的管理之下。
下图显⽰了从原始数据到实现数据价值的完整流程，其中每⼀步都是数据中台建设需要考虑的：数据发现/探索，数据采集/导⼊，数据建模/治理，数据转换/分析，数据发现/探索，数据采集/导⼊，数据建模/治理，数据转换/分析数据中台要做的就是把上述流程在全局标准化、规范化，让这个流程产⽣的结果和能⼒能够在全局共享和复⽤。
数据中台架构设计方案
数据中台架构设计方案随着大数据时代的到来，数据中台架构设计成为了企业不可忽视的重要环节。
本文将从数据中台的概念、架构设计要点以及实施步骤等方面进行探讨，为读者提供一个完整的数据中台架构设计方案。
一、数据中台概述数据中台是指将企业内外部数据进行整合和共享，构建一个统一的数据中心平台，能够满足企业内部各业务部门和外部合作伙伴对数据的需求。
数据中台的核心目标是提高数据的价值和利用率，促进数据驱动决策的实现。
二、数据中台架构设计要点1. 数据采集与存储数据中台的第一步是采集和存储各类数据源的数据。
在数据采集方面，可以通过数据管道将数据从各类业务系统中抽取出来，并进行数据清洗和转换，确保数据的准确性和一致性。
在数据存储方面，可以采用分布式存储技术，如Hadoop、Spark等，以满足大数据量和高并发的需求。
2. 数据标准化与治理数据中台的第二个要点是对数据进行标准化和治理。
通过定义统一的数据标准和数据字典，实现不同数据源之间的数据对齐和交互。
同时，建立数据质量监控机制，对数据进行质量评估和纠正，确保数据的准确性和完整性。
3. 数据计算与分析数据中台的核心价值在于数据的计算和分析。
通过建立统一的数据计算和分析平台，实现对数据的实时计算和深度分析。
可以利用机器学习和人工智能等技术，挖掘数据中的关联规律和价值洞察，为企业决策提供有力的支持。
4. 数据开放与共享数据中台的最终目标是实现数据的开放和共享。
可以通过开放API接口，将企业的数据资源对外开放，与合作伙伴进行数据交换和共享。
这样可以促进产业链上下游合作，实现资源的共享和协同创新。
三、数据中台架构设计实施步骤1. 确定数据中台的战略目标和价值主张，明确数据中台的定位和定位。
2. 分析现有数据资源和数据需求，建立数据清单和需求清单，明确数据中台的范围和边界。
3. 设计数据中台的整体架构和模块划分，确定数据中台的技术栈和解决方案。
4. 开展数据采集和存储的工作，制定数据采集和存储的规范和流程，实施数据清洗和转换。
数据中台解决方案
数据中台解决方案随着互联网和数字化时代的发展，数据的重要性日益凸显。
企业在业务运营中积累了大量的数据，但如何高效地管理和利用这些数据成为了一个亟待解决的问题。
数据中台解决方案应运而生，为企业提供了一个完整的数据管理和分析平台，帮助企业实现数据驱动的决策和业务增长。
数据中台的概念数据中台是指建立在企业内部，集中管理和共享各种数据资源的平台。
它通过统一的数据管理、数据处理和数据分析能力，建立一个高效、可靠和安全的数据中心，服务于企业内部的各个部门和业务。
数据中台与传统的数据仓库和数据湖不同，它不仅仅是一个存储数据的技术架构，更是一个将数据纳入企业核心管理的体系。
数据中台的价值1. 提升数据质量和一致性：数据中台通过统一数据标准和清洗规则，确保企业中的数据质量和一致性。
它可以监控数据的采集、存储和处理过程中的异常，提供数据质量评估和校验手段，帮助企业识别和排除数据质量问题。
2. 提高数据利用效率：数据中台将企业内部的各类数据资源整合起来，提供一站式的数据访问接口，方便企业员工快速获取所需的数据。
通过数据中台，企业可以摆脱数据孤岛的困扰，实现数据的共享和交流，提高数据利用效率。
3. 支持数据分析和业务决策：数据中台提供了强大的数据处理和分析能力，可以根据企业的需求，进行数据挖掘、数据建模和数据可视化等工作。
这些分析结果可以为企业的业务决策提供有力的支持，帮助企业更好地了解市场、产品和用户。
4. 实现业务创新和增长：数据中台可以帮助企业快速响应市场变化，迅速开展产品创新和业务拓展。
通过对数据的深入挖掘和分析，企业可以发现潜在的商机和市场需求，从而驱动业务的创新和增长。
数据中台的实施步骤1. 数据收集和整合：首先，企业需要收集和整合内部各类数据资源，包括结构化数据和非结构化数据。
这些数据可以来自企业的各个系统和业务部门，如销售、采购、人力资源等。
通过数据中台的数据采集工具和数据接口，将这些数据收集到一个统一的数据存储库中。
大数据平台架构设计指南：数据采集、存储与分析
大数据平台架构设计指南：数据采集、存储与分析随着社会的科技发展和计算机技术的进步，海量的数据被采集、存储、分析和利用，大数据的概念也随之提出。
大数据的平台架构设计已经成为企业发展的重要组成部分，它不仅能够帮助企业有效地收集、管理和分析海量数据，还能够帮助企业提高效率、减少成本，从而提升企业的核心竞争力。
数据采集是大数据平台架构设计的第一步，它是指从各种来源获取数据的过程。
数据采集可以由传感器、移动设备、网络服务器、社交网络等多种方式实现。
传感器可以采集实时数据，移动设备可以采集移动用户的行为数据，网络服务器可以采集网络流量数据，社交网络可以采集社会化媒体中的网民评论等。
数据存储是大数据平台架构设计的第二步，它是指将采集的数据存储起来的过程。
数据存储可以通过云存储、数据库、磁盘存储等多种方式实现。
云存储可以帮助企业实现安全可靠的数据存储，数据库可以帮助企业实现高效的数据查询，磁盘存储可以帮助企业实现海量数据的存储。
数据分析是大数据平台架构设计的第三步，它是指从存储的数据中提取洞察信息的过程。
数据分析可以通过机器学习、自然语言处理、数据挖掘等多种方式实现。
机器学习可以帮助企业从海量数据中发现模式和规律，自然语言处理可以帮助企业从文本中提取有价值的信息，数据挖掘可以帮助企业从复杂数据中发现有价值的知识。
大数据平台架构设计是一个复杂的过程，需要企业从多个方面进行综合考虑。
首先，应该从数据采集、存储和分析的角度考虑数据平台的架构设计。
其次，应该考虑数据平台的性能和可扩展性，以便能够满足企业的未来发展需求。
最后，应该考虑数据平台的成本，以确保企业在投入资源的同时能够获得最大的效益。
综上所述，大数据平台架构设计需要企业从数据采集、存储和分析的角度出发，同时考虑数据平台的性能、可扩展性和成本，以便更好地支持企业的发展。
企业应当充分利用大数据技术，不断优化数据平台，以提高企业的核心竞争力，获得更多的商业成果。
2023-大数据中台技术架构方案V2-1
大数据中台技术架构方案V2“大数据中台技术架构方案V2”是一个关于数据处理的技术解决方案，旨在为企业提供一个通用、高效、灵活的数据处理中心。
本文将从以下几个方面分步骤阐述该技术架构方案：第一步：数据采集数据采集是大数据中台的第一步，其目的是从各个数据源中收集到企业所需的数据，为后续的数据处理提供基础。
在大数据中台技术架构方案V2中，数据采集可以通过实时流数据和批量数据两种方式实现。
实时流数据可以通过Kafka、MQTT等消息中间件进行采集，而批量数据则可以通过各种ETL工具实现。
第二步：数据存储数据存储是大数据中台的核心，其用途是将采集到的数据进行持久化存储，为后续的数据处理和分析提供基础。
在大数据中台技术架构方案V2中，数据存储可以选择Hadoop的HDFS、NoSQL数据库等多种存储方式。
同时，为了提高数据存储的安全性，建议使用分布式存储方案。
第三步：数据处理数据处理是大数据中台的核心技术，其主要对采集到的数据进行清洗、整合、分析等操作，为企业提供实时的业务支持和决策分析。
在大数据中台技术架构方案V2中，数据处理可以选择Spark、Flink等流式计算框架进行实时处理，也可以使用Hadoop、MapReduce等离线计算框架进行批量处理。
第四步：数据可视化数据可视化是大数据中台的最终目的，其主要将处理后的数据通过图表、地图、关系图等各种方式展示出来，以便企业管理层进行决策分析。
在大数据中台技术架构方案V2中，数据可视化可以选择Tableau、Power BI等可视化工具进行实现。
综上所述，大数据中台技术架构方案V2是一个通用、高效、灵活的数据处理方案，它可以在数据采集、数据存储、数据处理和数据可视化等方面提供多种解决方案，为企业提供全方位的数据支持和决策分析。
如果你正在寻找一个适合自己的大数据中台技术架构方案，那么大数据中台技术架构方案V2是一个值得考虑的选择。
2023-大数据平台数据中台建设方案V3-1
大数据平台数据中台建设方案V3随着信息化技术的高效发展，大数据已成为各行业中不可或缺的一部分，企业需要通过建设数据中台来解决数据的统一管控和加速数据应用，提出可行性方案是数据中台建设的第一步。
本文将从四个方面进行阐述，提供数据中台建设方案V3。
一、数据中台建设的目的数据中台的核心是围绕数据建设的，其目的在于：将原本分散的数据平台集中起来，数据统一管理，保障数据质量，提高数据共享和协同，实现数据的重复利用，同时为企业订制应用程序提供数据支持，支持智能决策。
二、数据中台的建设步骤1.需求分析：对数据平台现有状态进行分析，圈定需求分析范围，了解数据架构、业务规范以及数据管理流程。
2.方案设计：围绕机构当前及未来的数据需求，确定数据架构模型，规划数据建设规范，设计数据平台的安全性、可扩展性和技术可行性。
3.实施与测试：方案实施包括新数据平台和既有数据平台的升级迁移，测试包括功能测试、性能测试、安全测试等。
4.数据治理：对中台数据状况进行分析，制定数据规范，保障数据质量、数据安全等需要的标准。
三、数据中台的架构设计1.数据接入层：包括数据采集、清洗、抽样、传输等流程，保障数据的规范与准确。
2.数据处理层：对原始数据进行处理，包括数据转换、数据转历史等处理流程，减轻后续处理的压力。
3.数据存储层：建立数据管理体系，包括数据存储结构、数据备份与恢复、性能调优等流程，确保数据的可靠性、高效性以及安全性。
4.数据应用层：支持自有的和第三方应用程序，也能够提供数据展示、查询、分析和决策等支持。
四、数据中台的益处1.数据管理能力强：数据中台可以更好地解决数据的统一管理，对企业数据应用的合理性和合规性进行监督，并加强对数据的安全、准确性的监管。
2.提高数据应用效率：数据中台不仅支持数据展示、查询、分析和决策等数据应用场景，而且还能够为企业订制应用程序提供数据支持，从而提高数据应用效率。
3.促进业务协同创新：数据中台支持跨部门协同共享数据，提高企业资源利用效率，并加速业务协同创新。
数据中台与业务中台架构设计方案(46页 PPT)
提供一些通用的技术开发工具包，减少重复造轮子，提高开发效率
节点组
服务器节点与租户、用户、服务的关系，帮助租户、用户能找到对应服务的节点
主数据
指系统间共享的数据，比如供应商、客户、物料等
基础数据
主要指变化较慢的数据，基础数据包含主数据，比如用户、角色、消息、参数配置等
功能架构
基本功能
辅助
IoT服务
……
设备管理服务
MQTT服务
连接管理服务
AI服务
……
语音识别连接
文本关键字段提取
OCR连接
平台简介
基于微服务架构模式每项服务都是独立而灵活的，可以提高服务的重用性
业务模块化，加快迭代速度随着各业务共享服务的沉淀积累，可帮助企业加快业务场景的迭代实现，支撑企业快速变革
包含许多开箱即用的通用服务组件如权限认证服务，数据一致性服务等都已包含在框架中。其中应用数据一致性服务去解决微服务间组合调用引发的不一致问题。
数据加密存储
客户端
组件
EXCEL导出
文件管理客户端
统一编码规则应用
消息应用客户端
调度执行应用
文件导入客户端
……
服务治理
通用服务
门户管理服务
调度服务
服务治理服务
工作流服务
数据分发服务
报表服务
登录&注册
用户管理
消息管理短信管理邮件管理站内消息管理
数据多语言TL语言表字段多语言
主数据管理
HR组织架构
业务组织架构
数据分发管理
系统配置
个人首选项
静态文本管理
编码规则
租户管理
报表展现
门户管理
SQL数据集定义、参数定义、数据模型可视化定义；套打报表报表访问权限控制
大规模数据存储与数据仓库架构设计
大规模数据存储与数据仓库架构设计随着信息时代的到来，大规模数据存储和管理变得越来越重要。
随着互联网的快速发展，我们迎来了数据爆炸的时代，传统的数据存储方式已经无法满足我们对数据的处理需求。
因此，设计一个高效可靠的大规模数据存储和数据仓库架构至关重要。
大规模数据存储的基本需求是能够存储海量的数据，并且能够高效地对数据进行读写操作。
为了实现这一目标，我们需要考虑以下几个方面：首先，我们需要选择合适的存储系统。
目前市场上有许多成熟的大规模数据存储系统，如Hadoop和Apache Cassandra 等。
这些系统能够提供高可扩展性和高容错性，能够支持海量数据的存储和处理。
选择合适的存储系统需要考虑我们的业务需求和预期的数据增长。
其次，我们需要设计合理的数据架构。
一个好的数据架构能够有效地组织和管理数据，提高数据的访问效率。
常见的数据架构模式包括关系型数据库、NoSQL数据库和分布式文件系统等。
根据实际需求，我们可以选择适合的数据架构模式，例如使用关系型数据库进行结构化数据的存储和查询，使用NoSQL数据库进行半结构化和非结构化数据的存储和查询。
此外，数据安全也是大规模数据存储必须考虑的重要问题。
在设计架构时，我们需要合理地设计数据安全策略，例如数据加密、访问控制和审计等。
同时，我们还需要定期进行数据备份和灾备方案的设计，以确保数据的可靠性和可恢复性。
对于数据仓库架构设计，我们需要将不同数据源中的数据整合到一个统一的数据仓库中，为用户提供方便快捷的数据查询和分析服务。
在设计数据仓库架构时，需要考虑以下几个方面：首先，我们需要进行数据模型设计。
数据模型是数据仓库的基础，能够描述数据之间的关系和属性。
根据实际需求，我们可以选择不同的数据模型，如星型模型、雪花模型和事实表模型等。
其次，我们需要设计ETL（数据抽取、转换和加载）流程。
ETL流程是将不同数据源中的数据抽取出来，经过转换和加载后存储到数据仓库中的过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据中台之结构化大数据存储设计一.前言任何应用系统都离不开对数据的处理，数据也是驱动业务创新以及向智能化发展最核心的东西。
这也是为何目前大多数企业都在构建数据中台的原因，数据处理的技术已经是核心竞争力。
在一个完备的技术架构中，通常也会由应用系统以及数据系统构成。
应用系统负责处理业务逻辑，而数据系统负责处理数据。
传统的数据系统就是所谓的『大数据』技术，这是一个被创造出来的名词，代表着新的技术门槛。
近几年得益于产业的发展、业务的创新、数据的爆发式增长以及开源技术的广泛应用，经历多年的磨炼以及在广大开发者的共建下，大数据的核心组件和技术架构日趋成熟。
特别是随着云的发展，让『大数据』技术的使用门槛进一步降低，越来越多的业务创新会由数据来驱动完成。
『大数据』技术会逐步向轻量化和智能化方向发展，最终也会成为一个研发工程师的必备技能之一，而这个过程必须是由云计算技术来驱动以及在云平台之上才能完成。
应用系统和数据系统也会逐渐融合，数据系统不再隐藏在应用系统之后，而是也会贯穿在整个业务交互逻辑。
传统的应用系统，重点在于交互。
而现代的应用系统，在与你交互的同时，会慢慢的熟悉你。
数据系统的发展驱动了业务系统的发展，从业务化到规模化，再到智能化。
业务化：完成最基本的业务交互逻辑。
规模化：分布式和大数据技术的应用，满足业务规模增长的需求以及数据的积累。
智能化：人工智能技术的应用，挖掘数据的价值，驱动业务的创新。
向规模化和智能化的发展，仍然存在一定的技术门槛。
成熟的开源技术的应用能让一个大数据系统的搭建变得简单，同时大数据架构也变得很普遍，例如广为人知的Lambda架构，一定程度上降低了技术的入门门槛。
但是对数据系统的后续维护，例如对大数据组件的规模化应用、运维管控和成本优化，需要掌握大数据、分布式技术及复杂环境下定位问题的能力，仍然具备很高的技术门槛。
数据系统的核心组件包含数据管道、分布式存储和分布式计算，数据系统架构的搭建会是使用这些组件的组合拼装。
每个组件各司其职，组件与组件之间进行上下游的数据交换，而不同模块的选择和组合是架构师面临的最大的挑战。
本篇文章主要面向数据系统的研发工程师和架构师，我们会首先对数据系统核心组件进行拆解，介绍每个组件下对应的开源组件以及云上产品。
之后会深入剖析数据系统中结构化数据的存储技术，介绍阿里云Tablestore选择哪种设计理念来更好的满足数据系统中对结构化数据存储的需求。
二.数据系统架构1.核心组件上图是一个比较典型的技术架构，包含应用系统和数据系统。
这个架构与具体业务无关联，主要用于体现一个数据应用系统中会包含的几大核心组件，以及组件间的数据流关系。
应用系统主要实现了应用的主要业务逻辑，处理业务数据或应用元数据等。
数据系统主要对业务数据及其他数据进行汇总和处理，对接BI、推荐或风控等系统。
整个系统架构中，会包含以下比较常见的几大核心组件：（1）关系数据库：用于主业务数据存储，提供事务型数据处理，是应用系统的核心数据存储。
（2）高速缓存：对复杂或操作代价昂贵的结果进行缓存，加速访问。
（3）搜索引擎：提供复杂条件查询和全文检索。
（4）队列：用于将数据处理流程异步化，衔接上下游对数据进行实时交换。
异构数据存储之间进行上下游对接的核心组件，例如数据库系统与缓存系统或搜索系统间的数据对接。
也用于数据的实时提取，在线存储到离线存储的实时归档。
（5）非结构化大数据存储：用于海量图片或视频等非结构化数据的存储，同时支持在线查询或离线计算的数据访问需求。
（6）结构化大数据存储：在线数据库也可作为结构化数据存储，但这里提到的结构化数据存储模块，更偏在线到离线的衔接，特征是能支持高吞吐数据写入以及大规模数据存储，存储和查询性能可线性扩展。
可存储面向在线查询的非关系型数据，或者是用于关系数据库的历史数据归档，满足大规模和线性扩展的需求，也可存储面向离线分析的实时写入数据。
（7）批量计算：对非结构化数据和结构化数据进行数据分析，批量计算中又分为交互式分析和离线计算两类，离线计算需要满足对大规模数据集进行复杂分析的能力，交互式分析需要满足对中等规模数据集实时分析的能力。
（8）流计算：对非结构化数据和结构化数据进行流式数据分析，低延迟产出实时视图。
对于数据存储组件我们再进一步分析，当前各类数据存储组件的设计是为满足不同场景下数据存储的需求，提供不同的数据模型抽象，以及面向在线和离线的不同的优化偏向。
我们来看下下面这张详细对比表：2.派生数据体系在数据系统架构中，我们可以看到会存在多套存储组件。
对于这些存储组件中的数据，有些是来自应用的直写，有些是来自其他存储组件的数据复制。
例如业务关系数据库的数据通常是来自业务，而高速缓存和搜索引擎的数据，通常是来自业务数据库的数据同步与复制。
不同用途的存储组件有不同类型的上下游数据链路，我们可以大概将其归类为主存储和辅存储两类，这两类存储有不同的设计目标，主要特征为：（1）主存储：数据产生自业务或者是计算，通常为数据首先落地的存储。
ACID等事务特性可能是强需求，提供在线应用所需的低延迟业务数据查询。
（2）辅存储：数据主要来自主存储的数据同步与复制，辅存储是主存储的某个视图，通常面向数据查询、检索和分析做优化。
为何会有主存储和辅存储的存在？能不能统一存储统一读写，满足所有场景的需求呢？目前看还没有，存储引擎的实现技术有多种，选择行存还是列存，选择B+tree还是LSM-tree，存储的是不可变数据、频繁更新数据还是时间分区数据，是为高速随机查询还是高吞吐扫描设计等等。
数据库产品目前也是分两类，TP和AP，虽然在往HTAP方向走，但实现方式仍然是底层存储分为行存和列存。
再来看主辅存储在实际架构中的例子，例如关系数据库中主表和二级索引表也可以看做是主与辅的关系，索引表数据会随着主表数据而变化，强一致同步并且为某些特定条件组合查询而优化。
关系数据库与高速缓存和搜索引擎也是主与辅的关系，采用满足最终一致的数据同步方式，提供高速查询和检索。
在线数据库与数仓也是主与辅的关系，在线数据库内数据集中复制到数仓来提供高效的BI分析。
这种主与辅的存储组件相辅相成的架构设计，我们称之为『派生数据体系』。
在这个体系下，最大的技术挑战是数据如何在主与辅之间进行同步与复制。
上图我们可以看到几个常见的数据复制方式：（1）应用层多写这是实现最简单、依赖最少的一种实现方式，通常采取的方式是在应用代码中先向主存储写数据，后向辅存储写数据。
这种方式不是很严谨，通常用在对数据可靠性要求不是很高的场景。
因为存在的问题有很多，一是很难保证主与辅之间的数据一致性，无法处理数据写入失效问题；二是数据写入的消耗堆积在应用层，加重应用层的代码复杂度和计算负担，不是一种解耦很好的架构；三是扩展性较差，数据同步逻辑固化在代码中，比较难灵活添加辅存储。
（2）异步队列复制这是目前被应用比较广的架构，应用层将派生数据的写入通过队列来异步化和解耦。
这种架构下可将主存储和辅存储的数据写入都异步化，也可仅将辅存储的数据写入异步化。
第一种方式必须接受主存储可异步写入，否则只能采取第二种方式。
而如果采用第二种方式的话，也会遇到和上一种『应用层多写』方案类似的问题，应用层也是多写，只不过是写主存储与队列，队列来解决多个辅存储的写入和扩展性问题。
（3）CDC（Change Data Capture）技术这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最友好的，只需要与主存储打交道。
主存储到辅存储的数据同步，则可以再利用异步队列复制技术来做。
不过这种方案对主存储的能力有很高的要求，必须要求主存储能支持CDC技术。
一个典型的例子就是MySQL+Elasticsearch的组合架构，Elasticsearch的数据通过MySQL的binlog来同步，binlog就是MySQL的CDC技术。
『派生数据体系』是一个比较重要的技术架构设计理念，其中CDC技术是更好的驱动数据流动的关键手段。
具备CDC技术的存储组件，才能更好的支撑数据派生体系，从而能让整个数据系统架构更加灵活，降低了数据一致性设计的复杂度，从而来面向高速迭代设计。
可惜的是大多数存储组件不具备CDC技术，例如HBase。
而阿里云Tablestore具备非常成熟的CDC技术，CDC技术的应用也推动了架构的创新，这个在下面的章节会详细介绍。
一个好的产品，在产品内部会采用派生数据架构来不断扩充产品的能力，能将派生的过程透明化，内部解决数据同步、一致性及资源配比问题。
而现实中大多数技术架构采用产品组合的派生架构，需要自己去管理数据同步与复制等问题，例如常见的MySQL+Elasticsearch，或HBase+Solr等。
这种组合通常被忽视的最大问题是，在解决CDC技术来实时复制数据后，如何解决数据一致性问题？如何追踪数据同步延迟？如何保证辅存储与主存储具备相同的数据写入能力？3.存储组件的选型架构师在做架构设计时，最大的挑战是如何对计算组件和存储组件进行选型和组合，同类的计算引擎的差异化相对不大，通常会优先选择成熟和生态健全的计算引擎，例如批量计算引擎Spark和流计算引擎Flink。
而对于存储组件的选型是一件非常有挑战的事，存储组件包含数据库（又分为SQL和NoSQL两类，NoSQL下又根据各类数据模型细分为多类）、对象存储、文件存储和高速缓存等不同类别。
带来存储选型复杂度的主要原因是架构师需要综合考虑数据分层、成本优化以及面向在线和离线的查询优化偏向等各种因素，且当前的技术发展还是多样化的发展趋势，不存在一个存储产品能满足所有场景下的数据写入、存储、查询和分析等需求。
有一些经验可以分享给大家：（1）数据模型和查询语言仍然是不同数据库最显著的区别，关系模型和文档模型是相对抽象的模型，而类似时序模型、图模型和键值模型等其他非关系模型是相对具象的抽象，如果场景能匹配到具象模型，那选择范围能缩小点。
（2）存储组件通常会划分到不同的数据分层，选择面向规模、成本、查询和分析性能等不同维度的优化偏向，选型时需要考虑清楚对这部分数据存储所要求的核心指标。
（3）区分主存储还是辅存储，对数据复制关系要有明确的梳理。
（主存储和辅存储是什么在下一节介绍）（4）建立灵活的数据交换通道，满足快速的数据搬迁和存储组件间的切换能力，构建快速迭代能力比应对未知需求的扩展性更重要。
另外关于数据存储架构，我认为最终的趋势是：（1）数据一定需要分层（2）数据最终的归属地一定是OSS（3）会由一个统一的分析引擎来统一分析的入口，并提供统一的查询语言4.结构化大数据存储结构化大数据存储在数据系统中是一个非常关键的组件，它起的一个很大的作用是连接『在线』和『离线』。