组织数据的指南¶
简介¶
我们经常被问及如何在 ArcticDB 中最好地组织数据。这个问题没有单一的答案——它取决于许多因素，尤其是数据本身及其使用方式。
ArcticDB 在数据排列方式上提供了高度的灵活性。虽然这是系统的优点，但有时选择范围太广，以至于难以知道从何入手。
在本指南中，我们旨在概述一些设计原则和经验法则，以帮助您为您的数据、系统和用户决定最佳方案。
我们首先从设计的角度审视 ArcticDB 组织数据的方式和系统设计考虑因素，然后基于这些考虑，评估和平衡一些典型组织策略的权衡。
ArcticDB 的数据层级¶
让我们回顾一下 ArcticDB 提供的数据组织结构，如下图所示
对象存储¶
可用的对象存储通常由外部因素决定，例如
- 环境：生产/UAT/研究
- 权限：向不同用户/系统组授予/拒绝读写权限的环境
- 记账：不同的云存储桶可能会计入不同的内部账户
- 存储配额：可能为不同目的分配不同数量的存储空间
- 存储性能：根据需求和成本，为不同应用提供更快/更慢的存储
库¶
ArcticDB 每个对象存储可以处理大量库——多达 50,000 个是完全合理的。
一个库将一组相关数据归类在一起。其主要目的通常是帮助对数据进行编目——命名良好/文档齐全的库有助于人们找到所需数据。
Symbol¶
Symbol 是 ArcticDB 中的基本存储单元。每个 Symbol 都是一个 DataFrame，并在 DataFrame 的列和索引上具有优化的数据访问能力。
因此，如何使用 (Symbol, columns, index) 的选择对于系统性能至关重要。它也是从 DataFrame 访问特定单个数据项（在需要时包括版本）的完整键。
版本¶
每个 Symbol 在修改时都会获得一个新版本。如何处理版本的考量是一个关键的设计选择——特别是它将对存储使用量产生很大影响。最常见的选择是
- 仅保留最新版本。使用 `prune_previous_version` 或通过后台进程删除旧版本（参见企业功能）。
- 仅保留关键版本。通常使用快照实现。
- 保留所有版本。如果数据修改频繁，这会占用大量存储空间，但对于完整归档数据非常强大。
系统设计考虑因素¶
运行系统时，以下主题是必须考虑的问题。因此，数据组织计划必须考虑到这些因素。
初始数据填充¶
这通常是一个一次性过程，用于启动和运行系统。理想情况下，可以使用相同的脚本进行初始数据填充和定期更新，只需调整不同参数。
数据更新过程¶
定期更新数据是大多数系统的常态。我们的设计中必须考虑
- 交付格式（数据源使用的格式）与数据存储格式的对比。权衡如下
- 以接近交付格式的格式存储数据更容易与源数据核对
- 交付格式通常不是下游过程的最佳格式
- 数据更新频率
- 随时间的存储增长特性
- 随时间的系统性能
高效的下游访问¶
数据通常被下游用户和系统访问的频率远远高于其更新频率。如果情况如此，值得组织数据以优化下游访问性能。
数据问题：调查与修复¶
系统问题通常由可疑的坏数据引起。值得思考如何调查和修复此类问题。例如
- 查找和检查可疑坏数据的工具
- 考虑如何将可疑坏数据与原始数据源进行核对
- 手动覆盖修复坏数据，以便在数据重新获取期间系统能有效运行
- 版本控制和快照使得轻松恢复到上次已知的良好状态
维护¶
需要进行一些日常维护，以保持系统高效运行并处理问题，其中一些问题可能源于系统外部。
对于 ArcticDB 而言，以下问题值得考虑
- 版本管理（参见版本）
- 碎片整理
- 数据复制/备份
有一些企业功能可以帮助解决这些问题以及更多。
ArcticDB 的通用性能指南¶
本节中，我们希望重点介绍一些有助于您从 ArcticDB 获得最佳性能的通用经验法则。
ArcticDB 的特性¶
值得理解并记住系统的这些特性
索引¶
- 主要且高性能的索引是第一个 DataFrame 行索引。
- 列名也是一个高性能的索引。
- 没有二级行索引或列索引。
- 压缩后，symbol 列表是一个很好的索引。
- 压缩后，版本列表是一个很好的索引。
数据¶
- DataFrame 数据总是以列式存储并压缩。ArcticDB 经过优化以读取和写入这些数据。
- DataFrame 数据被分块并存储在对象中（默认是 100,000 行 x 127 列）
- 不同 DataFrame 中的数据存储在不同的对象中
ArcticDB 针对大型 DataFrames 进行了优化¶
- 优先使用数量较少但每个 Symbol 数据量较大的组织方式
- 访问日期范围和列子集非常高效
- 从大量 Symbol 中收集数据可能较慢
规划您的版本管理¶
- 特别是规划要保留哪些版本以及如何删除其他版本
- 快照对于版本管理很有用
- 快照和版本之间存在相互作用：快照会阻止版本被删除
请参阅快照文档和快照 Notebook了解更多详情。
大量的小型追加或更新会使您的数据碎片化¶
追加（Append）和更新（Update）是高效的，因为它们总是添加新的数据块，而不是重组现有数据（实际上，更新会在必要时进行重组，但这通常只涉及少量数据）。
这意味着大量的小型追加或更新会导致大量的小数据块，从而使读取变慢。
您可以使用`defragment_symbol_data` 库函数手动对 Symbol 进行碎片整理。此外，企业功能提供了后台进程来为您处理碎片整理。
基于市场数据的示例¶
每个证券使用单独的 Symbol¶
单个证券的数据将是市场数据的时序数据。在这组样本数据中，这将是 AAPL 的所有价格数据。
每个证券都有自己的 Symbol，具有相同的数据形状。
优点¶
- 非常适合单个证券分析
- 数据的交付格式通常是按证券划分的
- 更新过程简单
缺点¶
- 涉及多个证券的分析需要读取多个 Symbol
- 原始数据的时序索引在不同证券之间可能不匹配。
通过时间索引对齐，数据更容易使用。
所有证券使用单个 Symbol¶
所有证券的数据被合并到一个单个 Symbol 中。
证券标识符作为额外的索引列包含在内。请注意，带有 Pandas MultiIndex 的 DataFrame 可以正确地进行往返，这很有用。然而，ArcticDB 的高性能索引仅作用于主索引级别。
优点¶
- 适用于一次性涉及多个证券的分析，例如：投资组合分析
- 单个大型 DataFrame 往往能提供非常好的读取性能
缺点¶
- 更新过程更复杂。可能需要读取、修改、写入的操作序列（尽管请参阅未来功能）
- 原始数据的时序索引在不同证券之间可能不匹配。
通过时间索引对齐，数据更容易使用。
每个数据项使用单个 Symbol¶
一个 Symbol 包含所有证券的单个字段的时序数据。在下面的示例中，是所有证券随时间的收盘价。
优点¶
- 适用于一次性涉及多个证券的分析，例如：投资组合分析
- 单个大型 DataFrame 往往能提供非常好的读取性能
- 更新过程相对简单。
缺点¶
- 原始数据的时序索引在不同证券之间可能不匹配。
通过时间索引对齐，数据更容易使用。
时间索引对齐¶
原始数据可能未按时间对齐
- 底层 tick 数据在任意时间到达
- 不同产品有不同的交易时间
- 某些证券交易可能不够频繁
对于许多用途而言，时间对齐的数据要么是必需的，要么能使任务简单得多。
重采样（Resampling）是数据对齐的一种方式。Pandas 有一个重采样函数，ArcticDB 中计划提供一个更快的函数（参见未来功能）。
企业功能¶
本指南中推荐的许多内务和维护程序由 ArcticDB 企业版软件包中提供的进程负责。如果您想进一步了解，请联系我们。点击我们网站上的 获取 ArcticDB 按钮即可联系我们。
计划中的未来功能和改进¶
我们一直在改进 ArcticDB 并添加新功能。以下是我们计划中的一些相关新功能
- 多重索引（Multi-Index）：支持对多重索引 Symbol 进行更灵活的数据更新。
- Arrow：支持基于 Arrow 的 Pandas 和 Polars DataFrames。
如果您对新功能有建议，请在我们的 github 上提出问题。请尽可能详细地说明。