共计 3849 个字符，预计需要花费 10 分钟才能阅读完成。
简介：BTC.com 团队在实时 OLAP 方面的技术演进过程及生产优化实际。
作者|高正炎
本文次要介绍 BTC.com 团队在实时 OLAP 方面的技术演进过程及生产优化实际，内容如下：
业务背景
时机挑战
架构演进
架构优化
将来瞻望
一、业务背景
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 做实时监控，是十分不错的抉择。大公司都曾经有相干的实际。包含报警等操作。
总的来说的话，路漫漫其修远兮，应用 Flink 真不错。
原文链接
本文为阿里云原创内容，未经容许不得转载。
