标签：存储 可以 数据仓库 Cirdan 嵌入式 引擎 使用 我们
Mark Papadakis.
9分钟阅读
Cirdan是一个嵌入的“数据仓库”。通过嵌入式，我的意思是它是可以与程序链接以使用它提供的功能的库，并且由“数据仓库”是指可以编程和/或通过使用SQL更新和访问的数据存储库。
考虑 BigQuery, SnowFlake, RedShift，除了云或多台机器上没有运行，而不作为服务运行（代表客户端接受连接和过程请求），而是与任何其他库（像 RocksDB或SQLite）一起使用在mysql或aws aurora）。
它非常适合分析，数据探索，报告和仪表板等。多得多。
它也被Presto，Clickhouse和Cloudera Impala的激励。他们都是梦幻般的项目，你肯定会考虑使用它们。
它是在过去的4个月内开发的，作为一个侧面项目，它现在准备就绪，虽然有许多计划的功能和改进（主要优化）将根据对他们和空闲时间的需求而追求（我几乎总是需要划分我在这些方面的工作和致力于我们两家公司的产品和服务之间的时间。
它支持连接，子查询，聚合，并且由于其设计和使用语义（库）而具有一些独特的功能。
理由
我们一直在努力重建我们的广告服务器技术，并一旦大多完成，我们必须弄清楚如何处理分析。我们的“遗产”服务使用一堆数据商店，包括一些特定目的的ad-hoc那些，而这效果很好，我们想做更好。具体来说，我们想脱离聚合/卷起，而是保留所有事件并依赖于维度，过滤器和指标来访问它们;我们将不再限制为特定的维度。我们希望能够询问数百万或数十亿的事件，而不是依赖于汇总，例如（广告商，广告，网站，日期）。
我们都同意这就是我们希望能够为客户提供的（特别是，我们想为数字营销专业人员提供“Google Analytics”）。
我最初建立了谷歌Mesa的克隆。它仍然基于聚合，但它使得可以轻松定义新的聚合。它强大而且非常快，但由于它依赖于聚合，因此无法使用。我们仍将在其他需要毫秒级别响应时间的其他项目中使用它。
我们可以使用现有的解决方案（OSS，OSS，或专有）或滚动我们自己的东西。不久前，当我们面对这样的困境时，我们会倾向于建立内部的一切。我仍然不确定这是正确的呼唤，但截至几年前，除非我们自己为客户和用户提供真正的利益，否则我们一直在积极地采用OSS，并将成为我们业务的真正利益，并将成为我们业务的竞争优势（我们也受到资源的限制，因此我们必须充分利用这些资源）。
我想了解这些系统的工作原理，我有一堆无法实际工作的想法，除非我们可以将功能嵌入程序，所以我决定我们自己建立技术。
我们都站在巨人的肩膀上;研究如此简单。有这么多的Codebases和论文学习，你可以联系在网上的人，他们可以帮助您了解他们是专家的，这是一个令人尴尬的财富。唯一的问题，这是一个真正的问题，是一个人可以花太多时间研究而不是做出任何真正的进步。繁琐，有很多OSS（图书馆，框架）可以使用，而不完全重新发明轮子，所以要说。我很感激那些回答我的问题的人（特别是Todd，Alexey和我的朋友在Dist-sys Slack Communition的朋友），对那些发布的代码和论文的人，我学习和否则直接或间接帮助我建造Cirdan。
设计
Cirdan是用C ++（C ++ 20）写的。粗略地说，它由SQL解析器，存储“引擎”，执行引擎和各种“变换器的实现”组成，实现各种功能（包括聚合函数），用于数据存储的编解码器和数据类型处理。
概念上，仓库由数据库组成。数据库由表组成，每个表都与模式和存储引擎相关联。SQL语句可以参考这些表的表和列。
有一堆现有的存储引擎。一个持续存在于内存中的数据，磁盘上的另一个持续存在（分区本身被分段为“微分区”），另一个访问储码分区以用于实时事件，用于访问CSV文件，另一个用于访问MySQL数据库。
应用程序可以通过实现一个接口来实现专业存储引擎 - 这是可能的，因为Cirdan是一个库（这是我想要将其构建为库的原因之一）。例如，我们有一些服务持续到RockSDB，因此对于其中任何一个，我们可以构建基于RockSDB的存储引擎，该存储引擎与这些数据集接口。SQL语句可以涉及数百个表，每个表都使用其模式和存储引擎。（Cirdan可以访问数据的PBS和数万亿行）。
这只是冰山一角。对于其他程序，人们可以构建新的编解码器，新功能（UDFS，见稍后），即使是新的变换。如果Cirdan未实施为图书馆，这将是不可能的或非常涉及的并且笨重。另一方面的另一个副作用是康丹的试验是微不足道的。您可以将程序链接到库中，本地访问文件，毫不费力地迭代自定义存储引擎实现等。
由于实现的简单性（至少，当我感知时），扩展SQL语法也是微不足道的。如果我们要需要另一个运营商，我们只会为它构建支持（例如，在下个月的某个时间计划的窗口函数，时间允许）。（更新：实施）当前，内部，左和交叉连接，因为这就是我们现在需要的，但是将支持扩展到其他类型，即使是非传统的，加入也很容易。根据我们的开发人员和产品的需求，我们将落实我们所需要的任何缺失。
目前，没有涉及代码生成（JIT），但可能会更改（请参阅上一段）。它会使聚合受益。但是，这是一个优先事项。Cirdan非常速度，距离0.7s的速度为10亿行速度。我们不会在我们的数据中心中使用GPU，但是，根据时间和需求，我们可能会结束支持GPU执行，以实现更大的性能。
Cirdan支持签名和无符号整数（从8到128位），单个和双精度浮点数和字符串。如果需要它们，我们可能会将数据类型扩展到阵列和路径上的元组。各种编解码器（存储引擎可以使用）负责序列化和反序列化列行数据。目前有两个不同的编码器，用于字符串和数字。
对于数字，具体而言，我们尝试使用可以保存列行集的[MIN，MAX）值范围的类型持久。例如，列的数据类型可以是UINT32，但是值可以存储为UINT8。我们考虑字典编码，RLE，POR（我们将在未来的更新中使用StreamVbyte，谢谢Daniel）。字典编码可以与RLE或PFOR组合。我们考虑到压缩收益，并稍后解压缩“成本”并选择最佳编解码器。
对于字符串，我们确定列行中的常见前缀，如果有一个，则剥离它，然后我们识别常见前缀，如果有的话，也可以使用字典，RLE和P for编码，以便在可能的情况下对这些前缀/字符串进行编码。
对于任何类型，我们还尝试使用LZ4进行压缩，如果压缩已经更早地压缩（使用我们的编解码器）列行会导致超过20％的增益，我们保留LZ4压缩数据（这是特定于“磁盘”存储引擎的压缩数据;每个发动机实现都不同）。
存储，访问和计算
希望，以前的段落说明了存储从访问中解耦。查询和存储之间的唯一耦合特定于谓词的下推。对于每个选择查询，将生成并将其传递给存储引擎的谓词推动状态，并且存储引擎可以使用该状态基于谓词推动状态快速过滤数据的分区/段。
每个存储引擎都负责管理数据集。实际上，可以直接使用存储接口访问该数据。您可以获得指向表的存储引擎并使用各种成员函数来访问数据。这可能对某些专业应用有意义。
有时您可能希望以SQL无法支持的方式处理数据。在这种情况下，您可以创建一个用户定义的函数（UDF）。由于Cirdan是一个库，您只需实现API，请使用Cirdan SQL解析器和执行子系统注册函数，然后可以在SQL查询中使用该函数。例如，您可能希望为聚合编写新函数，它接受各种列，并在聚合数据上运行一些ML模型，同时使用该数据同时执行其他数据，并最终使用每个聚合集的操作结果生成JSON（String）。这是非常强大的。对于使用可用的SQL函数和设施，可以优选使用这种UDF的使用。
独特的功能
可以配置模式列，以便构建特殊的绽放过滤器以改进前缀（例如，用于类似操作或正则表达式）区分大小写和不敏感的查询。用于编码列行的字符串编码器将在行中的字符串中确定公共前缀，并且还将构建特殊的绽放过滤器。这两者都可以由存储引擎持续到微分区（在盘“存储引擎的情况下）。存储引擎可以与谓词的推动状态一起使用，以快速跳过/忽略微分区。这是强大的。
当我尝试Cirdan时，我建立了一个涉及“http：// ％”的URL的Barebones Google Analytics的服务。这具有按幅度顺序提高性能。
目前未使用此操作，但流水线执行支持异步地“调度”数据检索，并且当该数据可用时，将通知管道变换（源），以便将该数据推回管道以进行处理以进行处理。这可以涉及C ++ 20 Coroutines，使用其他操作系统线程，任何东西都应该起作用。例如，数据可以存储在S3上，在没有阻止流水线执行的情况下异步检索，并且当返回该数据时，要将其推回到管道（流水线本身在节点图上运行，并且可以改变图形本身在运行时）。
from子句可以指定多个来源。源可以是表，子选择，一个命名（使用）SELECT语句，并且（最终，当实现时）实现了物化视图。这是语义上等同于在多个源重复同一选择查询的所有内部。但是，包括从子句中的多个来源更快。您还可以使用“*”将所有表包含来自特定仓库数据库或具有共同前缀的表。这样，您可以拥有例如使用“磁盘”存储引擎的表，用于定期更新数据，而另一个表直接访问储行或内存，尚未提交磁盘，列行，以及您的那种方式有效获得实时查询。
未来
Cirdan将是定期的更新，不仅是新的功能和性能还是新的工具和延期。我们将为新产品使用它，并为我们的公司（最好的公司和Phaistos网络）改进现有产品。
我希望我们能尽快开源Cirdan。它真的是时间和优先事项的函数。我们已经开放了一些最重要的项目（例如坦克，三位一体，公里）。我们从OSS受益匪浅，我们又想反过来贡献。我们最不可能。
> Cirdan
Cirdan是托尔金的指环王故事中的最聪明，最前瞻性，也是唯一已知的胡子精灵。
我们一直在矩阵字符后命名项目，但我们耗尽了名字，所以我们正在向Legendarium角色分支。我不认为我们很快就会有名称可用性的问题。
标签：存储,可以,数据仓库,Cirdan,嵌入式,引擎,使用,我们 来源： https://www.cnblogs.com/ebuybay/p/15859900.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。