这些应用程序通常由提供常用功能的标准构建块构建而成。例如，许多应用程序需要：
- 存储数据，以便它们或其他应用程序以后能再次找到（数据库）
- 记住昂贵操作的结果，以加快读取速度（缓存）
- 允许用户按关键字搜索数据或以各种方式过滤数据（搜索索引）
- 一旦事件和数据变更发生就立即处理（流处理）
- 定期处理累积的大量数据（批处理）
分析型与事务型系统
- 事务型系统 由后端服务和数据基础设施组成，在这里创建数据，例如通过服务外部用户。在这里，应用程序代码基于用户执行的操作读取和修改其数据库中的数据。
- 分析型系统 服务于业务分析师和数据科学家的需求。它们包含来自事务型系统的只读数据副本，并针对分析所需的数据处理类型进行了优化。
数据工程师 和 分析工程师。数据工程师是知道如何集成事务型系统和分析型系统的人，并更广泛地负责组织的数据基础设施。分析工程师对数据进行建模和转换，使其对组织中的业务分析师和数据科学家更有用。
事务处理与分析的特征
表 1-1. 事务型系统和分析型系统特征比较
| 属性 | 事务型系统（OLTP） | 分析型系统（OLAP） |
|---|---|---|
| 主要读取模式 | 点查询（通过键获取单个记录） | 对大量记录进行聚合 |
| 主要写入模式 | 创建、更新和删除单个记录 | 批量导入（ETL）或事件流 |
| 人类用户示例 | Web 或移动应用程序的最终用户 | 内部分析师，用于决策支持 |
| 机器使用示例 | 检查操作是否被授权 | 检测欺诈/滥用模式 |
| 查询类型 | 固定的查询集，由应用程序预定义 | 分析师可以进行任意查询 |
| 数据代表 | 数据的最新状态（当前时间点） | 随时间发生的事件历史 |
| 数据集大小 | GB 到 TB | TB 到 PB |
为了OLAP的目标专门做的数据库产品，包括 Pinot、Druid 和 ClickHouse。小心理解OLTP系统和OLPT产品、OLAP系统和OLAP产品，其中包括了数据库产品、缓存产品、搜索索引产品、流批处理产品。虽然他们有非常多的重叠，但这里为了方便理解严格区分“系统”和“产品”的概念，所以划分成每种系统有自己独立的产品。
数据仓库
一家大型企业可能有几十个甚至上百个联机事务处理系统：为面向客户的网站提供动力的系统、控制实体店中的销售点（收银台）系统、跟踪仓库中的库存、规划车辆路线、管理供应商、管理员工以及执行许多其他任务。这些系统中的每一个都很复杂，需要一个团队来维护它，因此这些系统最终主要是相互独立地运行。
业务分析师和数据科学家直接查询这些 OLTP 系统通常是不可取的。
在某些情况下，ETL 过程的数据源是外部 SaaS 产品，如客户关系管理（CRM）、电子邮件营销或信用卡处理系统。将这些外部系统的数据导入你自己的数据仓库可以实现通过 SaaS API 无法实现的分析。SaaS API 的 ETL 通常由专门的数据连接器服务（如 Fivetran、Singer 或 AirByte）实现。
一些数据库系统提供 混合事务/分析处理（HTAP），目标是在单个系统中同时支持 OLTP 和分析，而无需从一个系统 ETL 到另一个系统。它在同一应用程序既需要执行扫描大量行的分析查询，又需要以低延迟读取和更新单个记录的场景中很有用。例如，欺诈检测可能涉及此类工作负载。
在风控特征服务中HTAP会是一种比较好的选择，风控特征的数据加工自数仓同事要直接服务于整个风控环节。类似的产品会像阿里云mysql duckdb版本。
从数据仓库到数据湖
数据湖：一个集中的数据存储库，保存任何可能对分析有用的数据副本，通过 ETL 过程从事务型系统获得。与数据仓库的区别在于，数据湖只是包含文件，而不强制任何特定的文件格式或数据模型。数据湖中的文件可能是数据库记录的集合，使用 Avro 或 Parquet 等文件格式编码，但它们同样可以包含文本、图像、视频、传感器读数、稀疏矩阵、特征向量、基因组序列或任何其他类型的数据。除了更灵活之外，这通常也比关系数据存储更便宜，因为数据湖可以使用商品化的文件存储，如对象存储。
除了从数据湖加载数据到单独的数据仓库之外，还可以直接在数据湖中的文件上运行典型的数据仓库工作负载（SQL 查询和业务分析），以及数据科学和机器学习的工作负载。这种架构被称为 数据湖仓，它需要一个查询执行引擎和一个元数据（例如，模式管理）层来扩展数据湖的文件存储。Apache Hive、Spark SQL、Presto 和 Trino等。
分析系统的输出被提供给事务型系统（这个过程有时被称为 **反向 ETL),**这种分析系统的部署输出也被称为 数据产品
权威数据源与派生数据
**权威记录系统,**也称为 权威数据源，保存某些数据的权威或 规范 版本。如果另一个系统与权威记录系统之间存在任何差异，那么权威记录系统中的值（根据定义）是正确的。
派生数据系统中的数据是从另一个系统获取一些现有数据并以某种方式转换或处理它的结果。如果你丢失了派生数据，你可以从原始源重新创建它。
权威记录系统是数据首先被写入的主数据库，而派生数据系统是加速常见读取操作的索引和缓存，特别是对于权威记录系统无法有效回答的查询。
云服务与自托管
对于软件，需要做出的两个重要决定是谁构建软件和谁部署它。
云服务的利弊
如果你的数据集如此之大，以至于快速查询需要大量的计算资源，使用云可以节省资金，因为你可以将未使用的资源返回给供应商，而不是让它们闲置。对于较小的数据集，这种差异不太显著。
云服务的最大缺点是你无法控制它：
- 如果它缺少你需要的功能，你所能做的就是礼貌地询问供应商是否会添加它；你通常无法自己实现它。
- 如果服务宕机，你所能做的就是等它恢复。
- 如果你以触发错误或导致性能问题的方式使用服务，你将很难诊断问题。
- 此外，如果服务关闭或变得无法接受的昂贵，或者如果供应商决定以你不喜欢的方式更改他们的产品，你就受制于他们
- 云供应商需要被信任以保持数据安全，这可能会使遵守隐私和安全法规的过程复杂化。
云原生系统架构
原则上，几乎任何你可以自托管的软件也可以作为云服务提供，实际上，许多流行的数据系统现在都有托管服务。 然而，从头开始设计为云原生的系统已被证明具有几个优势：在相同硬件上具有更好的性能、从故障中更快恢复、 能够快速扩展计算资源以匹配负载，以及支持更大的数据集
| 类别 | 自托管系统 | 云原生系统 |
|---|---|---|
| 事务型/OLTP | MySQL、PostgreSQL、MongoDB | AWS Aurora 25、Azure SQL DB Hyperscale 26、Google Cloud Spanner |
| 分析型/OLAP | Teradata、ClickHouse、Spark | Snowflake 27、Google BigQuery、Azure Synapse Analytics |
相比之下，云原生服务的关键思想是不仅使用由操作系统管理的计算资源，还基于较低级别的云服务构建更高级别的服务。
作为一般规则，更高级别的抽象往往更面向特定的用例。如果你的需求与为其设计更高级别系统的情况相匹配，使用现有的高级别系统可能会比自己从较低级别系统构建更轻松，且更能满足您的需求。另一方面，如果没有满足你需求的高级系统，那么从较低级别的组件自己构建它是唯一的选择。
从实际业务目标出发，从高级别抽象开始，往下找低级别的组建构建系统。
存储与计算的分离
作为本地磁盘的替代方案，云服务还提供可以从一个实例分离并附加到另一个实例的虚拟磁盘存储。它还使应用程序对网络故障非常敏感，因为虚拟块设备上的每个 I/O 实际上都是网络调用。
我们实际业务中，网络带宽成为了瓶颈，这是一个需要被密切监控的指标。
云原生的在实际 使用过程中，要考虑到成本，业务场景（通常是稳定性、可用性等指标），使用效率等等。
云时代的运维
许多组织已经尝试将软件开发和运维的角色整合到团队中，共同负责后端服务和数据基础设施；DevOps 理念引导了这一趋势。站点可靠性工程师（SRE）是 Google 对这个想法的实现。
云服务的客户仍然需要运维，但他们专注于不同的方面，例如为给定任务选择最合适的服务、将不同服务相互集成，以及从一个服务迁移到另一个服务。即使计量计费消除了传统意义上的容量规划需求，了解你为哪个目的使用哪些资源仍然很重要，这样你就不会在不需要的云资源上浪费金钱：容量规划变成了财务规划，性能优化变成了成本优化。
采用云服务可能比运行自己的基础设施更容易、更快，尽管学习如何使用它也有成本，也许还要解决其限制。随着越来越多的供应商提供针对不同用例的更广泛的云服务，不同服务之间的集成成为一个特别的挑战。
ETL只是故事的一部分；事务型云服务也需要相互集成。目前，缺乏促进这种集成的标准，因此它通常涉及大量的手动工作。
无法完全外包给云服务的其他运维方面包括维护应用程序及其使用的库的安全性、管理你自己的服务之间的交互、监控服务的负载，以及追踪问题的原因，例如性能下降或中断。虽然云正在改变运维的角色，但对运维的需求比以往任何时候都大。
从ETL开始，到服务与服务之间的复杂集成，这是企业数据平台核心挑战之一
分布式与单节点系统
涉及多台机器通过网络通信的系统称为 分布式系统。参与分布式系统的每个进程称为 节点。你希望采用分布式系统的原因可能有多种：云服务之间的请求，固有的分布式系统，容错/高可用性，可伸缩性，延迟，弹性，使用专用硬件，法律合规，可持续性。
分布式系统的问题
在处理大量数据时，与其将数据从其存储处传输到处理它的单独机器，将计算带到已经拥有数据的机器上可能更快。
即计算向数据转移
可观测性技术可以用来对分布式系统中的问题进行诊断。追踪工具允许你跟踪哪个客户端为哪个操作调用了哪个服务器，以及每次调用花费了多长时间。
当每个服务都有自己的数据库时，维护这些不同服务之间的数据一致性就成了应用程序的问题。分布式事务是确保一致性的一种可能技术，但它们在微服务上下文中很少使用，因为它们违背了使服务彼此独立的目标，而且许多数据库不支持它们。
当与 DuckDB、SQLite 和 KùzuDB 等单节点数据库结合使用时，许多工作负载现在可以在单个节点上运行。
分布式事务处理会比分布式存储、分布式计算复杂许多，使用分布式事务并不是好主意。在某些场景下，类似DuckDB配合虚拟磁盘或者分布式存储或许可以尝试。数据文件将以对象块形式存储，将不再需要数据库服务。
微服务与 Serverless
微服务主要是人员问题的技术解决方案：允许不同的团队独立取得进展，而无需相互协调。这在大公司中很有价值，但在没有很多团队的小公司中，使用微服务可能是不必要的开销，最好以最简单的方式实现应用程序。
serverless 方法正在为代码执行带来计量计费：你只为应用程序代码实际运行的时间付费，而不必提前配置资源。
诸如K8S提交sparksql任务，pod用完就释放。
云计算与超级计算
数据系统、法律与社会
法律考虑正在影响数据系统设计的基础。例如，GDPR 授予个人在请求时删除其数据的权利（有时称为 被遗忘权）。
一般来说，我们存储数据是因为我们认为其价值大于存储它的成本。然而，值得记住的是，存储成本不仅仅是你为 Amazon S3 或其他服务支付的账单：成本效益计算还应该考虑到如果数据被泄露或被对手入侵的责任和声誉损害风险，以及如果数据的存储和处理被发现不符合法律的法律成本和罚款风险。
一旦考虑到所有风险，可能合理地决定某些数据根本不值得存储，因此应该删除。这个 数据最小化 原则（有时以德语术语 Datensparsamkeit 为人所知）与“大数据”哲学相反，后者是投机性地存储大量数据，以防将来有用。
