1.数据价值随期间的变动
如上图所示，可以看出，关于单个事情来说，数据价值会随着期间逐渐降落，比如，用户对小红书上某个帖子或淘宝上的产品出现了点击行为，之后就会有相关的产品或广告的介绍，以及启动步更多的链接、视频等各式各类的介绍，介绍的成果在点击出现过后最有用，之后成果会递减。同时，因为有很多人有相似的数据，咱们可以在这些数据上做一些聚合剖析，这类聚合剖析的价值会随着期间和数据量的参与而参与。之前咱们会把大局部的期间和精神都聚焦在这类批式的后处置的剖析上，而对实时数据剖析的关注较少。
随着实机遇器学习以及数据剖析运行的开展，实时数据的价值越来越多地被开掘进去。
过去，数据剖析更多是面向公司外部的剖析，比如运营数据剖析等；未来，数据剖析将更多用来服务最终用户。比如，介绍算法，自身就是用户自己的数据来训练模型，经过把用户的数据变为产品又给用户经常使用，成功整个数据的生命周期，并且能给用户更好的体验。
2.实时数据剖析边界拓展
实时数据剖析的边界也在不停地拓展。比如：
3.典型的数据剖析技术栈
上图是一个典型的数据剖析技术栈。左边是数据的生成端，在各种设备上，生成各种原始数据；两边是基于用户或产品特性的数据，比如，电商的订复数据，广告的事情数据，这些数据存到 OLTP，如 MySQL 数据库中，或 Kafka 的信息队列；接上去，OLAP 剖析端，离线剖析端普通会将 ETL 来的数据，存入数仓或数据湖里，实时剖析端普通从 Kafka 间接生产进入实时数据库中。这里的指标是低数据查问延时、高数据查问精度，并允许更大的查问量。
Apache Pinot 是一个允许高可用、高并发、低延时的极速实时散布式 OLAP。为了繁难处置互联网上的用户数据，Apache Pinot 是驳回列式存储的 OLAP，并且可以与 Kafka 集成起来，启动实时数据处置。
Apache Pinot 已在一些大公司里被经常使用。在 LinkedIn 允许每秒上百万事情，20万 QPS 的毫秒级查问；在 stripe 上，允许单表 1 千亿行，数据量超 PB，2 万 QPS，25 毫秒查问延时；Uber 也是对实时性要求很高的运行，用 Pinot 来成功天文信息的查问。
Pinot 是 Apache 基金会的名目，一切内容都齐全开源，很多公司都在经常使用，如上图所示。大家假设有兴味，也欢迎试用，并在社区中交换。
Pinot 驳回 Lambda 架构，架构图所示，包括：
为了允许低延时、高并发的查问，Pinot 的工程提升指标是尽量增加单次查问须要扫描的数据量。
为此 Pinot 成功了很多索引来协助增加查问范围，包括经常出现的反向索引、排序索引，以及关于不凡数据格局和类型的索引，如区间范围的索引、半结构化 Json 数据的索引、天文信息的索引等。
同时，关于聚合查问，相比于关于全维度的预聚合，Pinot 外部可以依据维度的，灵活的聚合结果，使得查问效率更高。
Pinot 驳回可插拔架构，查问层、索引层、存储层都允许 SPI 接口，用户可以繁难地在 Pinot 上启动二次裁减开发。
上图展现了 Pinot 的可插拔架构。基于 Pinot SPI 包，开发者可以性能开发自己的数据存储、输入格局、流式引擎、索引、查问等。开发者只有要写一些繁难的成功，就可以构建、打包而后运行，十分繁难。比如，作者仅花一周左右期间，就成功了向量索引性能。
上方将引见在 AI 时代，Pinot 如何允许 AI 运行。
Pinot 可以作为一个向量数据库为 AI 提供 Embedding 数据存储以及向量检索。
Embedding 可以看成一个浮点数的数组，存到数据库中。有了 Embedding 向量后，当一个向量出去，须要查问和这个向量最相似的 K 个结果。
这类运行场景有很多，如经常出现的搜查场景和介绍场景。
例如二手车搜查场景。用户或许会去二手车网站，搜查想要的车。在搜查环节中，用户会有很多偏好，比如喜好品牌、年份区间、多少钱区间、色彩、天窗等。间接经常使用挑选的话，结果或许过多或过少。咱们可以把用户搜查的偏好形容，作为一个 Embedding，存入数据库。而后依据用户偏好形容，前往一个与形容相似的 topK 排序，展现给用户。
用户介绍餐厅场景。可以依据用户历史青睐吃的物品，同时联合用户的形容，生成一个 Embedding，存储起来。而后依据 Embedding，给用户介绍和他偏好相近的产品，这可以失掉更好的用户产品体验。
为什么须要实时呢？比如问 ChatGPT，“在足球界，药厂是什么梗？”，回答“勒沃库森”“但至今未能取得联赛冠军”，而相熟足球的小同伴会知道，“勒沃库森”在 2024 年第一次性取得德甲联赛冠军。
因此，可以看出 LLM 模型和数据都是有时效性的，假设没有最准确最实时的数据，或许失掉不到准确的结果。经过 RAG 和实时向量数据库的协助，模型可以提供更实时和准确的结果。
为了实事实时 RAG，在向量数据方面，咱们须要经过将原始数据变成 Embedding，存到向量数据库中，从而提供应用户查问。
上图是一个普通的流程，用来成功用户回复中关于实时数据的要求。
将原始文本文件、音频或照片依据 Embedding 模型，失掉他们的 Embedding 示意，写入 Kafka 并存入 Pinot，这样实时的数据流就变成向量进入了向量库。
关于一个用户，将他的疑问，也转换成对应的 Embedding，而后经过向量相似性搜查，就可以找到一堆相似的数据；这些数据称为增强高低文（Enhance Context），也就是把相关的文本和用户自身的疑问合在一同，交给 Prompt，再经过 LLM，生成给用户的回答。
经过这样的数据处置，可以将实时数据流与 RAG 联合起来，到达更好的准确性。
Pinot 提供了很多向量计算的允许，比如距离计算函数，允许 L1、L2、余弦、点积等距离。可以依据不同的用户场景，选用不同的距离计算方法，到达不同的成果。
Pinot 经过向量索引可以提高查问效率。驳回 HNSW 算法，来建设向量索引，而后经过多层迭代的模式，协助用户输入的向量，找到离它最近的 n 个向量。这样相关于全表扫描对每个向量都计算一个距离的方法，计算复杂度大幅降落。
而关于开发者来说，这个查问也很繁难。如上图左边代码所示，定义了算法经常使用的距离，以及向量相似度查问的语句，前往 10 条最近的结果。
算法在不同数据集上的性能体现如上图所示。咱们经常使用了 Lucene Benchmark，驳回 Lucene 的 HNSW 算法的成功。大家也可以点击链接去看看不同算法的成功和性能，因 Lucene 也是开源的，咱们会跟社区一同启动性能提升。
经过混合负载，可以将 OLAP 和向量数据库联合起来，以成功维度数据的过滤，并联合其它数据，提高 prompt 的准确度。
比如，用户可以有产品评估数据的 Embedding，也有产品自身的特色，比如 SKU_ID，类别等。在做向量查问时，须要依据类别等维度特色过滤，再做相似性查问，查完的结果合起来，输入给 Prompt，启动前面的反应生成。
最后，对本次分享的关键内容启动一下总结。