Talaria
这个仓库包含了 TalariaDB 的一个分支,它是一个分布式、高可用、低延迟的时间序列数据库,适用于大数据系统。它最初是在 Grab 公司设计和实现的,每天处理数以百万计的交易和连接,这需要一个可扩展的数据驱动决策平台。
简介
TalariaDB 帮助我们克服了从大量数据中检索和处理信息的挑战。它满足了我们每小时需要查询至少 2-3 TB 数据的需求,同时保持可预测的低查询延迟和低成本。最重要的是,它与不同工具的生态系统非常兼容,让我们能够使用 SQL 查询数据。
基于原始设计,我们将 Talaria 扩展为两种可能的设置方式:
- 作为事件摄取平台。这允许你从几乎任何地方使用简单的 gRPC 端点来跟踪事件。
- 作为热数据存储。这允许你查询热数据(例如最近 6 小时),这些数据会经过数据管道并最终在压缩后存储到你的数据湖中。
Talaria 围绕事件数据模型设计。事件本质上是一组键值对,但为了保持一致性,我们需要定义一组常用的键。 每个事件将包含以下内容:
- 哈希键(例如:使用 "event" 键)。这代表事件的类型,可以用源作用域(例如 "table1")作为前缀,并使用点作为逻辑分隔符。分隔和命名空间不是必需的,但强烈建议使用,以使你的系统更易于使用。
- 排序键(例如:使用 "time" 键)。这代表更新发生的时间,以 Unix 时间戳(精确到源允许的程度)表示,编码为 64 位整数值。
- 其他键值对将表示各列的不同值。
以下是描述表更新事件的有效负载示例:
键 | 值 | 数据类型 |
---|---|---|
event | table1.update | string |
time | 1586500157 | int64 |
column1 | hello | string |
column2 | { "name": "roman" } | json |
Talaria 支持 string
、int32
、int64
、bool
、float64
、timestamp
和 json
数据类型,这些类型用于构建可以暴露给 Presto/SQL 的列。
使用 Talaria 进行事件摄取
如果你的组织需要一个可靠且可扩展的数据摄取平台,你可以将 Talaria 设置为这样的平台。主要优势是这种平台成本效益高,不需要复杂的 Kafka 设置,甚至还提供实时查询功能(如果你同时指向一个 Presto)。基本设置允许你从几乎任何地方使用简单的 gRPC 端点来跟踪事件。
要将 Talaria 设置为摄取平台,你需要指定一个表(在本例中为 "eventlog"),并在配置中启用 compaction
,类似于以下内容:
mode: staging
env: staging
domain: "talaria-headless.default.svc.cluster.local"
storage:
dir: "/data"
tables:
eventlog:
compact: # 启用压缩
interval: 60 # 每60秒压缩一次
nameFunc: "s3://bucket/namefunc.lua" # 文件名函数
s3: # 输出到 Amazon S3
region: "ap-southeast-1"
bucket: "bucket"
...
设置完成后,你可以直接将 gRPC 客户端(参见 protobuf 定义)指向摄取端点。请注意,我们还在此仓库中提供了一些预生成或预制的摄取客户端。
service Ingress {
rpc Ingest(IngestRequest) returns (IngestResponse) {}
}
以下是当前支持的输出接收器及其示例配置列表:
- Amazon S3 使用 [s3 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/s3。
- DigitalOcean Spaces 使用 [s3 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/s3,自定义端点和 us-east-1 区域。
- Google Cloud Storage 使用 [gcs 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/gcs。
- 本地文件系统使用 [文件接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/file。
- Microsoft Azure Blob Storage 使用 [azure 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/azure。
- Minio 使用 [s3 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/s3,自定义端点和 us-east-1 区域。
- Google Big Query 使用 [bigquery 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/bigquery。
- Talaria 本身使用 [talaria 接收器](https://github.com/talariadb/talaria/blob/master/./internal/storage/writer/talaria。
对于 Microsoft Azure Blob Storage 和 Azure Data Lake Gen 2,我们支持跨多个存储账户进行写入。 我们支持两种模式:
- 随机选择,每次写入随机指向一个存储账户,你只需指定存储账户列表即可。
- 加权选择,为每个存储账户分配一组权重(正整数),每次写入根据指定的权重指向一个存储账户。
以下是加权选择的示例:
- azure:
container: a_container
prefix: a_prefix
blobServiceURL: .storage.microsoft.net
storageAccounts:
- a_storage_account
- b_storage_account
storageAccountWeights: [1, 2]
随机选择和加权选择对某些关键场景特别有用:
- 高吞吐量部署,其中Talaria生成的I/O超过了存储账户的限制。
- 在具有多个VPN链接的内部端点上部署时,您希望将网络流量分散到多个网络链接上。
使用Talaria进行热数据查询
如果您的组织需要查询热数据(例如最近n小时的数据)或正在传输的数据(即正在摄入的数据),您还可以配置Talaria使用内置的Presto Thrift连接器将其提供给Presto。
在下面的示例配置中,我们设置了一个s3 + sqs
写入器,用于从S3存储桶持续摄取文件,并设置了一个将暴露给Presto的"eventlog"表。
mode: staging
env: staging
domain: "talaria-headless.default.svc.cluster.local"
writers:
grpc:
port: 8080
s3sqs:
region: "ap-southeast-1"
queue: "queue-url"
waitTimeout: 1
retries: 5
readers:
presto:
schema: data
port: 8042
storage:
dir: "/data"
tables:
eventlog:
ttl: 3600 # 数据保留1小时
hashBy: event
sortBy: time
...
设置好Talaria后,您需要使用Thrift连接器配置Presto与其通信。您需要确保:
- 在属性文件中,您已配置通过kubernetes负载均衡器与Talaria通信。
- Presto可以直接访问节点,无需通过负载均衡器。
完成这些操作后,您应该能够通过Presto查询您的数据。
select *
from talaria.data.eventlog
where event = 'table1.update'
limit 1000
将文件摄入Talaria
要从存储URL(如S3或Azure Blob Storage)摄入现有的ORC、CSV或Parquet文件,请使用Talaria文件摄入客户端:
https://github.com/atris/TalariaFileIngestionClient
快速开始
最简单的入门方式是使用提供的helm chart。
贡献
我们欢迎贡献,请随时提交拉取请求,我们会尽快审核。TalariaDB由以下人员维护:
- Roman Atachiants
- Yichao Wang
- Chun Rong Phang
- Ankit Kumar Sinha
- Atri Sharma
- Qiao Wei
- Oscar Cassetti
- Manoj Babu Katragadda
- Jeffrey Lean
许可证
TalariaDB根据MIT许可证授权。