关于分布式计算:实时-OLAP-从-0-到-1

简介：BTC.com 团队在实时 OLAP 方面的技术演进过程及生产优化实际。

作者|高正炎

本文次要介绍 BTC.com 团队在实时 OLAP 方面的技术演进过程及生产优化实际，内容如下：

1. 业务背景
2. 时机挑战
3. 架构演进
4. 架构优化
5. 将来瞻望

一、业务背景

1.1 业务介绍 – ABCD

BTC.com 是一家区块链技术计划提供者，咱们的业务次要分为四个局部，总结来说就是 ABCD：A 是人工智能机器学习，B 是区块链，C 代表云，D 是数据。这些模块不仅互相独立的，也能够相互联合。近几年人工智能、区块链的减速倒退与大数据在背地提供的反对非亲非故。

1.2 业务介绍 – 区块链技术计划提供商

区块链艰深来讲能够了解为一个不可逆的分布式账本，咱们的作用是让大家能更好的浏览账本，开掘账本背地的信息数据。目前比特币的数据量级大略在几十亿到百亿，数据量大略在数十 T，当然咱们也有其余的一些业务，如以太坊货币、智能合约剖析服务等。

整体而言咱们是一家区块链技术计划的提供商，提供挖矿的服务。与金融行业的银行一样，咱们也有很多的 OLAP 需要，比方当黑客攻击交易所或供应链进行资产转移或者洗钱时，须要通过链上的操作，咱们能够在链上对其进行剖析，以及交易上的跟踪，统计数据等，为警方提供帮助。

二、时机挑战

2.1 之前的架构

大略 2018 年的时候，竞争对手比拟少，咱们整体的架构如上。底层是区块链的节点，通过 Parser 一直的解析到 MySQL，再从 MySQL 抽取到 Hive 或者 Presto，从 Spark 跑各种定时任务分析数据，再通过可视化的查问，失去报表或者数据。架构的问题也是不言而喻的：

• 不能做到实时处理数据
• 存在单点问题，比如某一条链路忽然挂掉，此时整个环节都会呈现问题

2.2 遇到的需要与挑战

• 效率 ，效率问题是十分常见的。咱们的表大略在几十亿量级，跑这种 SQL，可能须要很长时间，SQL 查问比较慢，重大影响统计效率。
• 实时 ，数据不是实时的，须要等到肯定的工夫才会更新，如昨天的数据明天能力看到。
• 监控 ，实时需要，如实时风控，每当区块链呈现一个区块，咱们就要对它进行剖析，然而区块呈现的工夫是随机的。不足残缺的监控，有时候作业忽然坏了，或者是没达到指标，咱们不能及时晓得。

2.3 技术选型咱们须要思考什么

在技术选型的时候咱们须要思考什么呢？首先是缩容，2020 年行情不太好，大家都在尽力缩减老本，更好的活下去。在老本无限的状况下，咱们如何能做更多的货色，必须进步本身的效率，同时也要保证质量。所以咱们须要找到一种均衡，在老本效率还有品质这三者之间进行肯定的均衡。

三、架构演进

3.1 技术选型

俗话说，工具选的好，上班下的早，对于是否引入 Flink，咱们想了很久，它和 Spark 相比劣势在哪里？

咱们理论调研当前，发现 Flink 还是有很多劣势，比方说灵便的窗口，精准的语义，低提早，反对秒级的，实时的数据处理。因为团队自身更纯熟 Python，所以咱们过后就抉择了 PyFlink，有业余的开发团队撑持，近几个版本变动比拟大，实现了很多性能。在实时 OLAP 方面，数据库咱们采纳了 ClickHouse。

3.2 为什么应用 ClickHouse

为什么要应用 ClickHouse？首先是快，查问的效率高。字节跳动，腾讯，快手等大公司都在用。同时咱们也有 C++ 方面的技术积攒，应用起来比拟容易，老本不是太高。

3.3 实时 OLAP 架构

基于以上的技术选型，咱们就造成了上图的架构，底层是数据源，包含区块链的节点，通过 Parser 解析到 Kafka，Kafka 负责对接 Flink 和 Spark 工作，而后 Flink 把数据输入到 MySQL 和 ClickHouse，反对报表导出，数据统计，数据同步，OLAP 统计等。

数据治理方面，咱们参考了业界的分层，分成了原始层、明细层、汇总层以及应用层。咱们还有机器学习的工作，这些都部署在 K8s 平台之上。

3.4 架构演进历程

咱们的架构演进过程如下图，从 2018 年的 Spark 和 Hive，到起初的 Tableau 可视化，往年接触了 Flink，下半年开始应用 ClickHouse，起初 Flink 工作比拟多了，咱们开发了繁难的调度平台，开发者只须要上传工作，就会定时或者实时的跑工作。

3.5 架构演进思考

• 为什么演进这么慢，因为区块链的倒退还没有达到一定量级，无奈像某些大公司有上亿级别或者 PB 级别的数据量。咱们的数据量没有那么大，区块链是一个陈腐的事物，没有肯定的历史。另外的问题就是资源问题，因为人员不足，人员老本上也有所管制。
• 方才讲的架构，咱们总结了它适宜怎么的企业。首先是有肯定的数据规模，比说某个企业 MySQL 只有几千万的数据，用 MySQL , Redis , MongoDB 都能够，就不适宜这套架构。其次是须要肯定的老本管制，这一整套老本算下来比 Spark 那一套会低很多。要有技术储备，要开发理解相干的货色。
• 区块链数据的特点。数据量比拟多，历史数据基本上是不变的，实时数据相对来说是更有价值的，数据和工夫存在肯定的关联。

3.6 实时 OLAP 产生的价值

在实时 OLAP 上线后，根本满足了业务需要，同时老本也在可控的范畴内。

• 适宜的是最好的，不要自觉谋求新技术，比方数据湖，尽管好，然而咱们的数据量级实际上用不到。
• 咱们不思考建设技术中台，咱们的公司规模是中小型，部门沟通起来比拟容易，没有太多的隔膜，没有倒退到肯定的组织规模，所以咱们没有打算倒退技术中台，数据中台，不自觉跟风上中台。
• 咱们达到的成果是缩短了开发的时长，缩小作业的运行工夫。

四、架构优化

4.1 Flink 和 ClickHouse

Flink 和 ClickHouse 之间有一些联动，咱们自定义了三个工作。

• 自定义 sink。
• ClickHouse 要一次性插入很多数据，须要管制好写入的频次，优先写入本地表，耗时比拟多。
• 咱们次要用在智能合约的交易剖析，新增的数据比拟多，比拟频繁，每几秒就有很多数据。数据上关联比拟多。

4.2 ClickHouse 遇到的问题

• 批量导入时失败和容错。
• Upsert 的优化。
• 开发了罕用 UDF，大家晓得 ClickHouse 官网是不反对 UDF 的吗？只能通过打补丁，保障 ClickHouse 不会挂。

咱们也在做一些开源方面的跟进，做一些补丁方面的尝试，把咱们业务上，技术上罕用的 UDF，汇合在一起。

4.3 批量导入策略

• 历史数据，能够认为是一种冷数据，相对来说不会常常扭转。导入的时候依照大小切分，依照主键排序，相似于 bitcoind，底层的 Checker 和 Fixer 工作，导入过程中及时进行报警和修复。比方导入某一数据失败了，如何更好的及时发现，之前就只能人肉监控。
• 实时数据，咱们须要一直解析实时数据，大家可能对重组，51% 的概念不太熟悉，这里简略讲一下，上图最长的链也是最重要的链，它下面的一条链是一个重组并且分叉的一条链，当有一个攻击者或者矿工去挖了下面的链，最终的后果会导致这条链被废除掉，拿不到任何处分。

如果超过 51% 的算力，就会达到这样的成果，成为最长的链，这个是累计难度比拟高的，此时咱们会认为数据导入失败，同时咱们会利用回撤的性能，一直将其回滚和重组，直到满足最残缺的链。当然咱们也会设置一些记录和 CheckPoint，这里的 CheckPoint 和 Flink 的 CheckPoint 的概念也有所区别。

它是区块链方面的 CheckPoint，区块链有一个币种叫 bch，会定义 CheckPoint，当满足肯定的长度时，它就无奈再进行回滚，防止了攻击者的攻打。咱们次要是利用 CheckPoint 记录信息，避免回滚，同时还会依照级别 / 表记录批量插入的失败或者胜利，如果失败则会进行重试，以及报警回滚等操作。

4.4 Upsert 的优化

ClickHouse 不反对 Upsert，次要在 SDK 方面做兼容，之前是间接往 MySQL 写数据，指标是通过 SQL 语句批改对应的 SDK 减少长期小表的 join，通过 join 长期小表，进行 Upsert 的操作。

举个例子，区块链地址账户余额，就像银行的账户余额，必须十分准确。

4.5 Kubernetes 方面优化

Kubernetes 方面的优化。Kubernetes 是一个很残缺的平台。

• 高可用的存储，在晚期的时候，咱们就尽可能的将服务部署在 Kubernetes，包含 Flink 集群，根底业务组件，币种节点，ClickHouse 节点，在这方面 ClickHouse 做的比拟好，不便兼容，反对高可用操作。
• 反对横向扩大。
• 服务发现方面，咱们做了一些定制。

4.6 如何保障一致性？

• 采纳 Final 进行查问，期待数据合并实现。
• 在数据方面的话，实现幂等性，保障唯一性，通过主键排序，整理出来一组数据，再写入。
• 写入异样时就及时修复和回填，保障最终一致性。

4.7 监控

应用 Prometheus 作为监控工具。使用方便，老本较低。

五、将来瞻望

5.1 从 1 到 2

• 扩大更多的业务和数据。之前咱们的业务模式比拟繁多，只有数据方面的统计，之后会开掘更多信息，包含链上追踪，金融方面的审计。
• 赚更多的钱，尽可能的活下去，咱们能力去做更多的事件，去摸索更多的盈利模式。
• 跟进 Flink 和 PyFlink 的生态，积极参与开源的工作，优化相干作业。摸索多 sink 方面的工作，原生 Kubernetes 的实际。

5.2 从 2 到 3

• 数据建模的标准，规定伎俩，操作。
• Flink 和机器学习相结合。
• 争取拿到实时在线训练的业务，Flink 做实时监控，是十分不错的抉择。大公司都曾经有相干的实际。包含报警等操作。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。