ClickHouse为Dassana的安全数据湖提供动力

Gaurav Kumar

2023年1月23日

我们很高兴今天邀请Dassana的创始人兼首席执行官Gaurav Kumar作为我们博客的嘉宾。继续阅读，了解他们为何选择ClickHouse作为其安全数据湖，该数据湖整合了不同的数据源，以提供情境化数据洞察。

近年来，由于网络风险的增加及其对企业的影响，现代企业在安全产品方面进行了大量投资。从几乎没有可见性到如今拥有超过其管理能力的可见性。如今，典型的企业使用十多种安全技术。这些工具以各种形状和大小发出数据，这使得理解数据变得更加困难。

例如，如果您需要创建一个简单的执行仪表板，显示各个业务部门的网络安全态势，您将如何操作？也许您想展示每个业务部门解决安全问题所需的时间（平均修复时间）？或者根据SLA违规情况对业务部门进行排名？

在上图中，Dassana提供了一个有趣的见解：中级严重性问题的SLA违规事件有所激增。我们还可以看到哪个团队可能对此负责（财务团队）。Dassana中的所有可视化都是细化，因此我们可以找出根本原因。如果没有Dassana，安全团队将花费无数时间从不同的来源获取数据并对其进行规范化。

这些看似简单的问题在今天通过编写复杂的SIEM查询才能痛苦地得到解答（如果您幸运的话，所有数据都已发送到SIEM）。但是，即使是现代SIEM也专为不可变的时间序列事件数据（例如日志）而设计。但安全数据远不止日志。例如，警报状态可以是“打开”或“关闭”。假设您想了解有多少警报处于“打开”状态，您将如何操作？如果警报一小时前处于“打开”状态，并且您将该事件发送到SIEM，但现在警报状态已更改为“关闭”，您可以向SIEM发送更新请求，将警报状态从“打开”更新为“关闭”吗？当然，您不能，这就是它被称为不可变的原因。因此，此问题的解决方案是重新插入更新后的数据，然后仅查询最新数据。这些称为最后一点查询，在SIEM等追加式系统上运行时臭名昭著。

不仅安全数据的根本“可变”特性使得SIEM难以操作，而且SIEM公司也停止了创新和投资于解决数据规范化等基本问题。AWS称之为“账户”ID，GCP称之为“项目”ID，Azure称之为“订阅”ID。如果我们能够将这些内容规范化并将其称为“AssetContainerId”，那不是很好吗？这样，如果系统支持SQL，您就可以编写如下查询 -

select count(*) as count,assetContainerID from findings where status='open' group by assetContainerID

在以上示例中，我们显示了按规范化资产类型分组的资产数量。

Dassana就是这样的梦想。Dassana从各种安全来源（如CSPM工具、IDS等）摄取数据并对其进行规范化 - 这使您能够以无模式的方式查询和可视化数据，这都要归功于ClickHouse强大的功能。

在确定使用ClickHouse之前，我们评估了十多种不同的大数据系统。在ClickHouse提供的灵活性方面，没有哪个系统能与之匹敌。具体而言，以下功能和架构优势赢得了我们的青睐

不同的表引擎允许我们以适合用例的格式存储数据。
能够使用异步插入频繁插入数据。大多数大数据系统强制您批处理数据，这会增加应用程序端的大量复杂性。
内置会计系统来跟踪查询成本，例如读取的行数等。
能够自动将数据移动到不同的存储层。这是数据归档的重要功能，内置存储层系统为我们节省了宝贵的开发时间。锦上添花的是，ClickHouse还支持行级和列级TTL（生存时间）。
高级外部字典选项，例如能够从Postgres数据库和HTTP服务器填充（和刷新）字典。

作为一家种子轮融资的初创公司，我们还对成本节约进行了深入评估，发现与其他大数据系统相比，ClickHouse的成本将只是一小部分。

当我们刚开始时，在幕后，Dassana大量使用了ReplacingMergeTree表引擎来存储可变数据。当发现（警报）的状态需要更新时，我们为同一警报插入了一行具有更新状态值的新行，并让表引擎处理去重逻辑。但当我们想要提供近乎实时的去重结果时，这并没有解决问题。这就是高级功能（如带有物化视图的AggregatingMergeTree）发挥作用的地方。

如果您想知道数据是否存储了两次，一次在ReplacingMergeTree中，另一次在AggregatingMergeTree中，答案是否定的，这要归功于ClickHouse的TTL功能。

为了查询重复数据，我们使用了“group by”聚合查询。虽然这种方法在一段时间内有效，但随着我们的数据增长，我们开始遇到性能问题。您可以在此处阅读更多有关此去重方法的信息针对Upsert和频繁更新的行级去重策略

建议的方法都没有在我们的规模上发挥作用，这时我们意识到了ClickHouse字典功能的神奇力量。

让我们举个例子。考虑以下模式

CREATE TABLE default.foo (
   tenant UUID,
   record_id UInt64,
   insert_ts UInt64,
   data String,
   insert_ts_dt DateTime MATERIALIZED toDateTime(divide(insert_ts,1000))
)
Engine = ReplacingMergeTree(insert_ts)
ORDER BY (tenant, record_id);

这里，record_id是我们想要查询去重数据的唯一“资产ID”或实体ID。“data”只是record_id的任意值。

现在，让我们像这样创建一个字典

CREATE OR REPLACE DICTIONARY default.foo_last_point_dict
(
   `record_id_hash` UInt64,
   `insert_ts` UInt64
)
PRIMARY KEY record_id_hash
SOURCE(CLICKHOUSE(
   QUERY '
           SELECT cityHash64(tenant, record_id) as record_id_hash, max(insert_ts)
           FROM table_x
           WHERE {condition}
           GROUP BY record_id_hash
           ORDER BY record_id_hash
       '
   update_field 'insert_ts_dt'
   update_lag 120
))
LIFETIME(5)
LAYOUT(SPARSE_HASHED(PREALLOCATE 0));

这里需要注意的最重要的事情是查询

SELECT cityHash64(tenant, record_id) as record_id_hash, max(insert_ts)
           FROM table_x
           WHERE {condition}
           GROUP BY record_id_hash
           ORDER BY record_id_hash

此查询根据 ClickHouse 的 LIFETIME（上面显示为 5 秒）定期运行。通过 `update_field` 配置的 `insert_ts_dt` 值被注入到 `WHERE` 子句中，以确定返回的数据。此查询返回用于填充字典的每个 `record_id_hash` 的最大 `insert_ts`。要查询数据，我们运行类似这样的 SQL 查询

SELECT * FROM foo
WHERE equals(insert_ts, dictGet('default.foo_last_point_dict, 'insert_ts', cityHash64(tenant, record_id)))

此查询选择主表中 `insert_ts` 与字典中最后一个点（最新）值相同的行。

与任何系统一样，总复杂度保持不变——你只需将其重新排列。在本例中，我们希望获得出色的性能，但随之而来的是以下必须注意的挑战

如果 `record_id` 的基数非常高，则内存消耗会更高。幸运的是，我们发现我们可以在 32GB RAM 的机器上存储数亿个资产（不同的 `record_id`）数据。
在 5 秒（字典加载频率）的短时间窗口内，查询将匹配陈旧数据。这在我们准确度预算范围内，因为无论如何数据都是以流式方式加载的，并且我们用例中的大多数分析查询都与趋势和近似值有关。

值得一提的是，我们也尝试过“Join”表引擎，但发现我们基于字典的方法的性能要高得多。

虽然这篇文章向您展示了一些 ClickHouse 的强大功能，但我们也希望强调一些我们的经验教训。ClickHouse 拥有其所有辉煌和强大的功能，它是一股需要谨慎处理并注意细节的力量。我们的一些经验教训是

生产环境一致性。您很可能在 Intel CPU 上运行 ClickHouse。不要在 Apple Silicon 上运行测试，并期望在 Intel CPU 上也能获得相同的结果。在所有 ClickHouse 版本中，Intel 版本是最稳定的。同样，尝试为测试集群分配与生产集群相同的资源。这听起来可能很昂贵，但您可以在不使用时关闭测试集群。某些问题只有在系统被大量使用时才会出现。
不要手动管理 ClickHouse。如果您没有使用 ClickHouse Cloud，那就是犯罪，因为这消除了扩展和复制数据的大量复杂性。
不要在生产环境中使用实验性功能。这应该是显而易见的经验教训，但有时使用实验性功能很诱人。例如，我们在这些功能几乎投入生产时就开始使用投影，但我们应该等待。等待训练轮移除。

由一群成功的连续创业者和云安全专家团队创立，我们正在构建一个安全数据湖，以整合不同的数据源并提供情境化的数据洞察。我们的目标是简化大规模数据访问，同时不影响性能并优化成本，使客户能够专注于战略业务重点。

了解更多关于 Dassana 的信息，请点击这里。

分享此文章