下载掌阅APP，畅读海量书库
立即打开
服务层代表了对事件流处理平台生成的实时分析进行消费的主要途径。该层可以是键值存储（例如NoSQL数据库）或实时OLAP数据库，具体取决于我们的需求。服务层为各种应用提供了数据接入点，包括实时仪表盘、数据应用和推荐引擎，并支持即时数据探索的功能。
然而，我们可能会问，为何需要服务层？难道不能仅通过事件流处理平台和流处理器直接向下游提供数据吗？
理解事件价值随时间变化的本质，有助于我们领会服务层所满足的核心需求。如图2-13所示，单个事件的商业价值会随着时间的流逝而逐渐减少。
以一个数字化事件为例，假设有用户在外卖应用中搜索了“比萨”这一关键词。那么，对于这个事件的全部信息，了解它的价值究竟有多大呢？
图2-13：随着时间推移，单个数据点的价值逐渐减少
当这一事件首次发生时，它蕴含着很高的价值：意味着某个地方的某位用户正在积极寻找比萨。如果我们能够实时捕捉到这一行为，就有机会向该用户提供附近比萨店的优惠信息。
但是，这些信息的价值会迅速衰减。了解昨天甚至几个小时前有人想要购买比萨，可能已经没有多大用处。等你意识到这一点时，用户很可能已经从别的竞争者那里购买了比萨并享用完毕。
相比之下，随着时间的推移，汇总后的事件信息的价值却会逐渐增加，正如图2-14所展示的那样。
设想我们不将焦点放在单个个体寻找附近比萨的行为上，而是对一段时间内在特定区域内所有搜索比萨的个体感兴趣。通过分析累积的数据，我们能够洞察到新的趋势。例如，我们可以追踪这一趋势并据此预测未来的需求，这对于库存管理尤为重要。
聚合数据的价值走向与单次事件数据截然不同：对于任何独立事件，其价值或许并不显著，但随着时间的积累，其价值会显著攀升，因为它能提供更准确的预测。
图2-14：随着时间推移，数据点总体的价值不断增加
正是在实时分析的技术栈中，服务层（如图2-15所示）为理解聚合事件的重要性提供了附加价值。
图2-15：服务层
服务层向内外部用户敞开大门，既服务于人类用户，也满足软件实体的需求，它们共同追求的是迅速且精准的大规模分析能力。因此，服务层必须确保以下几点：
摄取延迟
数据摄取过程需要达到极速。任何数据的更新与变化都应瞬间映射至服务层。
查询延迟
一旦数据被拉取，我们需要保证其能在网络响应时间内完成查询——这里所说的时间，是以毫秒计而非秒。
并发性
服务层需要具备同时处理众多查询任务的能力。每秒处理数十万次查询并非罕见。能够对新数据执行大规模查询，意味着为数据开辟了新的使用场景。这些场景可能会增强用户互动，甚至可能为我们已搜集的数据解锁更多商业潜力。
在服务层的选择上，我们面对众多选项。对于键-值存储的NoSQL数据库，MongoDB、Elasticsearch和Redis是流行的技术。而针对实时OLAP数据库，我们可以选择Apache Pinot、Apache Druid、Rockset以及ClickHouse等方案。
决策使用哪一个服务层组件时，首要考虑因素是对服务层可能执行的查询类型的分析。若主要操作是基于键的检索（例如，通过ID获取最新数据），那么支持键-值存储的服务层将是不错的选择。反之，若需要在多个维度对数据进行复杂的交叉分析，实时OLAP数据库则可能更符合需求。在本节接下来的内容中，我们将假定使用的是实时OLAP数据库。
下一步，我们需要评估数据摄取的便捷性：
·是通过API还是标准SQL来完成？
·支持哪些流处理平台作为数据来源？是否与我们所选的流处理平台兼容？
·从事件在流处理平台上发生到能够被查询到，这之间的时间延迟是多少？
·数据库能否应对数据生成的体量和速率？
数据摄取一旦完成，我们的注意力便需要转向数据的存储和查询效率。需要了解的是，对于常规查询，响应速度是否达标，若未达标，是否可以通过增加索引或实施预聚合策略来提升性能。
虽然供应商常会提供基准测试以展示他们的技术在数据摄取及查询方面的性能，但为了确保所选技术能够满足我们具体的性能要求，建议进行独立的性能测试验证。