应用科学

Article捷克共和国医疗保健中的大数据分析与处理平台

马丁·什图菲 1,*,博里斯·巴契´奇 2和莱昂尼德·斯托伊梅诺夫 3
1 Solutia公司，捷克共和国布拉格101002奥克兰理工大学工程、计算机与数理科学学院，新西兰奥克兰 1010；boris.bacic@aut.ac.nz3尼什大学电子工程学院计算机科学系，塞尔维亚尼什18000； leonid.stoimenov@elfak.ni.ac.rs*通讯作者：martin.stufi@solutia.cz
收到日期：2020年2月1日；接受日期：2020年2月24日；发表日期：2020年3月2日

摘要：

医疗保健领域的大数据分析（BDA）在推动人工智能（AI）发展并提升分析能力方面发挥了积极作用，同时降低了医疗成本。本研究旨在通过部署大数据分析（BDA）平台来改进现有的医疗电子系统，并满足捷克共和国国家卫生服务的要求（招标编号VZ0036628，编号Z2017‐035520）。
除了在支持当前及近期未来人工智能应用的Linux平台上提供数据分析能力，包括机器学习和数据挖掘算法外，还需考虑伦理问题，要求采用新的方法保护隐私，而这受到日益增多的法规和公众期望的制约。所提出的大数据分析平台已满足所有要求（N> 100），包括符合欧盟（EU）和捷克共和国法律法规的医疗行业标准——事务处理性能委员会(TPC‐H)决策支持基准测试。目前，该概念验证（PoC）已升级至生产环境，在过去七个月中实现了捷克共和国医疗保健各个孤立部分的整合。本文报告的概念验证BDA平台、成果及相关理念，可推广至其他有意以成本效益高、安全、可扩展且高性能的方式建设或升级本国医疗系统的国家。
关键词 :TPC‐H；NoSQL数据库集群；Vertica；实时疫情制图；实时大流行追踪与集成；疫情传播与风险数据可视化

1.引言

大数据已经影响了我们收集、管理、分析、可视化和利用数据的方式。在医疗保健领域，通过采用实施了大数据分析（BDA）的医疗电子系统，人们期望现代、稳健、高性能且成本效益高的BDA技术能够在增强对医务人员以及更广泛患者群体的数据驱动支持的同时，保护患者隐私。目前，捷克共和国正在推进其医疗电子系统的采用和逐步升级，利用大数据分析提升医疗质量，并提供整合的国家和区域支持。
本文的目的是报告影响捷克共和国医疗保健系统中实施大数据分析平台的先决条件和测试，以满足支持大数据分析国家采用战略所需的性能。所报告的医疗保健解决方案必须通过100多项复杂需求（N= 119，包括13项加分功能）、先决条件和系统条件的测试，且需符合欧盟要求。
应用科学2020，10，1705；doi:10.3390/a pp 10051705 www.md p i.com/ j ournal/a pp lsci
本文档由funstory.ai的开源PDF翻译库BabelDOCv0.5.10(http://yadt.io)翻译，本仓库正在积极的建设当中，欢迎star和关注。
应用科学2020, 10, 1705 2共23 页
以及捷克共和国法规和事务处理性能委员会(TPC‐H)基准[1]。根据作者的观点，该观点与全球趋势和欧盟倡议一致[2–6]：（1）医疗保健领域数据量的不断增长、数据流式物联网设备和移动应用的发展，使得大数据分析技术在现代社会中的采用不可避免；（2）将大数据分析、数据挖掘和人工智能与医疗应用相结合，是迈向下一代医疗电子系统的关键步骤[7,8]；以及（3）在一个欧盟成员国实施大数据分析平台将影响其他正在转型其医疗系统的欧盟成员国在可复制性和知识转移方面的决策[2]。
大数据技术已被广泛应用于交通、银行业、汽车业、保险业、媒体、教育和医疗保健等多个行业[9–13]。随着互联网流量呈指数级增长的趋势相同，现代医疗保健中每天产生的数据量也在呈指数级增加 fic，当数据量超过一定限度时，传统系统和方法将无法再满足数据处理需求，也无法将数据转换为所需任务的格式。传统上，在线事务处理（OLTP）系统以受控方式收集小部分数据，称为短原子事务 [15]。相比之下，在大数据集群环境中，存在流式和批处理数据处理的需求，这些都需要更高的灵活性，以适应各种数据分布模式并匹配电子系统可扩展性[16]。
通常，对于大数据电子系统而言，流处理涉及（近）实时分析和数据预测，而批处理数据处理则涉及使用先进且专用的算法实现复杂业务逻辑。
小数据系统通常通过向同一台机器添加更多资源来垂直扩展；这种方式成本较高，且最终会达到可能的最大升级限度。相比之下，大数据系统是基于集群的，因此主要依赖水平可扩展架构，从长远来看，通过使用商用硬件，能够在降低成本的同时提高性能效率。

1.1.大数据技术视角

将大数据集群应用于处理和分析医疗数据的想法并不新鲜[17–20]。例如，2009年在一个由100个节点组成的集群上进行的早期实验，通过一组基准测试揭示了在选定的并行系统中存储和处理用于医疗保健的数据时在性能方面的各种权衡[21]。
最近，人们对电子系统平台和基于云的技术的兴趣和需求不断增长，强调使用各种数据挖掘、机器学习[22],和其他人工智能技术的新型创新大数据工具，这些工具有助于知识发现、个性化以患者为中心的 modeling、识别具有相似特征的群体、预测分析、改进药物安全以及增强诊断能力。

1.2.挑战与机遇

大数据技术在医疗保健领域的整合与治理在挑战和机遇方面具有本地和全球的影响[6,8,12,23]。
医疗保健领域的挑战包括“数据结构、安全、数据标准化、存储与传输以及管理技能（如数据治理）等方面的问题”[24]。
为了推进医疗保健服务的发展，实施大数据分析平台并结合数据分析[25],具有以下潜力：
•提高个性化护理和医疗服务的质量；
•降低治疗成本；
•使用预测分析来分析例如患者每日（收入损失）和疾病进展；
•使用实时可视化和分析进行即时护理和再入院案例分析；
•通过处理满意度评估数据和自我报告的健康状况，加强患者与其医疗服务提供者的患者参与[26,27]；
应用科学2020, 10, 1705 3（共23 页）
•集成小数据解析和知识发现，这些功能也可以与大数据集成[28]；
•整合视频、运动传感器、二维/三维运动学及其他保护隐私的运动数据，用于人体运动建模与分析 （HMMA），关联积极生活、福祉与健康益处[29–34]；
•提供近乎实时的疫情地理映射信息，促进协作、社区参与、数据透明度和数据交换[35,36]；并
•利用医疗数据识别趋势、进行战略规划、治理、改进决策和降低成本[24]
为了推动下一代大数据分析平台的发展，从而有助于改善医疗保健成果，本研究探讨了以下问题：
i.是否有可能设计并构建一个符合欧盟立法、TPC‐H[1]基准及其他法定要求的捷克共和国卫生服务大数据分析平台？ii.如果可能，哪种大数据分析平台能够在允许安装开源软件、多种机器学习算法、开发环境以及商业可视化与分析工具的同时，提供最佳的成本效益和性能特性？iii.此类基于大数据分析的电子系统在多大程度上能够面向未来，以保持可靠性、稳健性、成本效益和性能？

1.3.行业基准

行业基准在推动数据库系统的设计和工程解决方案方面发挥着重要作用。例如，事务处理性能委员会（TPC）[1],在促进计算领域采用行业基准方面具有重要作用，如今许多主要供应商广泛使用这些基准来展示其产品的性能。同样，大型采购商通常使用TPC基准测试结果[37,38]作为衡量新计算系统和技术之间性能的可量化比较点，以确保其计算环境[39]具备高性能水平。

1.4.大数据分析

大数据分析技术在管理医疗保健领域不断扩增的数据方面已显示出良好的前景。例如，麻省理工学院（MIT）2014年关于重症监护室中大数据的研究报告指出，数据分析能够有效预测关键信息，如住院时长、需要外科干预的患者数量，以及哪些患者可能面临败血症或医源性疾病的风险。对于此类患者，数据分析可挽救生命，或预防患者可能遇到的其他并发症。
利用大数据分析（BDA）的技术也已成功应用于医院之外的场景[41]。医学界和政府机构如今已认识到，使用大规模数据分析技术监测流感发病率的重要性[42]。季节性流感流行对公共卫生系统构成了重大问题，每年在全球范围内导致25万至50万人死亡[43–45]。此外，当新型病毒出现且人群缺乏免疫力时，可能引发大流行，造成数百万人死亡[43]。疾病活动的早期检测有助于更快响应，从而在挽救生命或减少全球范围内的呼吸道疾病方面减轻季节性流感和大流行流感的影响[43]。一种早期检测方法是监控与健康查询相关的互联网搜索行为，谷歌即采用了此类方法[22,45]。此外，研究发现某些查询与患者因出现流感症状而就诊医生的比例高度相关。这一相关性使得谷歌能够开发出一种算法，以一天的延迟估算美国不同区域的流感活动情况。除其他算法外，该方法使谷歌能够通过查询，在人口可常规访问互联网的地区，从类似流感的搜索中检测疫情。
应用科学2020, 10, 1705 4（共23 页）
鉴于最近的冠状病毒爆发以及从严重急性呼吸综合征和埃博拉疫情中吸取的教训[35,36,46,47],大数据分析电子系统可为大流行/流行病追踪以及疫情传播与风险数据可视化提供即席分析、数据交换和近实时地理映射功能/。对于大流行疫情，即席分析可被视为以人为本且主动的模式发现方法。例如，机会发现方法[28]可结合现有的数据分析、机器学习和数据挖掘方法。这种以人为本且主动的方法，通过减少样本量并强调相对少数部分，可用于提高对来自感染地区的入境旅客的选择性筛查效率 ffiencyofincomingtravellersfrominfectedregions[28,46]。

1.5.SQL与非仅SQL方法

结构化查询语言（SQL）是为关系型数据库开发的，而近年来，非仅SQL（NoSQL）则是为非关系型和分布式数据库开发的。数据可以以行式存储或列式存储的方式进行存储和处理。基于科德的 关系模型的行式存储原理在大多数数据库应用中已得到广泛应用[48–51]。然而，这种成熟的关系数据库管理系统（RDBMS）[50,52]在主要用于增删改查操作的分析型应用中效率不高。在过去几年中， NoSQL[38]数据库已被测试和研究，并在不同的研究[53,54],中对其性能进行了评估，其中一些研究重点关注了使用NoSQL技术[55]的优势。对于大数据分析平台（BDAplatform）的架构师而言，结构化查询语言（SQL）与NoSQL数据库管理系统之间的已知差异使得设计工作具有挑战性，需要做出多项决策来满足特定目的及相关需求集。相比SQL更晚出现的NoSQL数据库支持弹性扩展的概念，允许添加新节点以提高可用性、可扩展性和容错性[56]。
许多关于医疗保健中使用的大数据技术[57]和相关技术的文献与综述主要依赖于孤岛原则进行数据集成、数据处理和数据可视化。一种作用于数据集列的应用能够克服“NoSQL”或“非仅SQL”数据库[43,45]的性能问题。这些数据库可在本地部署或云环境中识别。云计算[49,58]也提供此类数据库服务。NoSQL数据库具备弹性及横向扩展功能，可添加新节点。新节点通常基于低成本（通用）硬件设计。
关于本工作的主要目标，即创建一个用于大数据集成、主数据管理、即席分析、数据存储、数据处理和可视化的实际平台，该平台基于NoSQL数据库进行数据存储，并基于Vertica集群进行数据处理。

2.材料和方法

本横断面研究使用的数据集包括由捷克共和国卫生信息与统计研究所(IHIS)提供的匿名化真实生活数据样本。为符合两阶段IHIS验收测试的要求，需求分析与设计科学研究方法相结合[53]，以构建可扩展平台、架构、软件和硬件基础设施。在招标投标及系统采购严格性的背景下，IHIS要求集包含基于加权评分系统的招标评审标准，涵盖总体拥有成本、强制性要求（例如TPC‐H）以及13项加分功能。
基于循环实验设计方法所生成的解决方案满足了所有要求，同时实现了最高的性能排名。
第一阶段及第一阶段+II评估中的渐进式性能和功能改进包括：
i.符合第一阶段的大数据电子系统需求及影响架构设计的设计决策；ii.验收测试需求的分解
应用科学2020, 10, 1705 23中的 5
iii.根据一组要求（N= 119）对硬件基础设施进行优化，以进行加权评分，包括TPC‐H决策支持和最小系统性能；以及iv.利用可用的测试数据集进行以性能为导向的电子系统优化。v.性能评估基于
能够处理大数据的数据库管理系统[44]，例如Cassandra、CouchDB、HBase、Impala[59],
MongoDB[50],和Vertica[60]。

2.1.IHIS要求

IHIS要求可以按以下方面进行分组：
可扩展性：电子系统必须允许通过增加和可访问的计算技术（包括商用硬件产品）来提升性能。
模块化、开放性和互操作性：系统组件必须根据明确的需求规格通过指定的接口进行集成。同时，必须确保各类供应商能够方便地使用系统组件。
•可替换性：电子系统解决方案必须支持安装开源操作系统，并包含用于非营利和教育用途的工具。
该电子系统必须符合标准的数据仓库（DWH）系统。某些组件必须能够与大规模高数据量分析（ MHDA）系统的组件互换。
可扩展性：电子系统的所有工具和组件必须为未来的升级提供空间，包括功能和能力提升。
•质量保证：需要一种用于验证数据和元数据完整性的工具，以确保处理后的数据在整个分析过程中保持准确。
•安全：该电子系统必须能够在本地服务器上运行，而不依赖于云或外包备份系统。电子系统必须确保所有数据免受外部或内部威胁，因此授权、存储访问和通信至关重要。必须在数据库、表或列级别设置用户访问权限，以限制仅有少数高级用户可访问数据。电子系统必须记录所有执行和读取操作，以供未来审计使用。电子系统必须支持版本控制和开发工具，同时满足元数据和数据版本控制、备份和归档的要求。
•简洁性：电子系统必须允许多个团队并行协作处理所有过程、数据流和数据库模式。所有任务都必须完全可编辑，允许提交和撤销数据及元数据的更改。电子系统必须具备简洁易用的特性，并且稳定且能抵御子系统故障。
•性能：电子系统必须针对指定的最小并发用户数进行设计。数据源的批处理和复杂的数据挖掘分析被视为基本要求。季度数据增量的完整数据集成处理不得超过一小时。
最重要的IHIS要求规定：
i.概念验证（PoC）测试中使用的所有工具、许可证和环境特性必须与在公共合同中提交并记录的电子系统报价相一致。为满足合同义务，所提议的解决方案不得存在：虚假提高系统性能、更改可用许可证条款，或以其他方式相对于最终交付解决方案的结果进行改进或修改。环境配置必须满足所提议电子系统的通用要求（使用类型、输入数据大小、处理速度要求）。
ii.所提出的电子系统不能针对特定查询和测试中的单个任务步骤进行显式（手动）优化。测试查询不应基于通用元数据（缓存、分区、补充索引、派生表和视图），除非在需要优化大量数据加载的特殊情况下。基于通用元数据的技术将来可能用于提升性能，但目前并非必需。
作为系统可用性的前提条件。为了加载大量数据，可以手动调整环境配置为非标准配置，以进行后续测试步骤（图1）。
iii.在测试期间不得手动更改配置以优化单个任务——电子系统需要对可能在时间上重叠的任务具有通用性。
应用科学2020，10，x同行评审 23中的 6
配置 在测试期间，不得手动更改离子以进行优化 单项任务——eSystem需要对可能的任务具有通用性
ove在规定时间内完成。

2.2TPC‐H性能要求和测试

满足TPC‐H基准测试包括对最低要求进行测试，包含一组 valu和参数。TPC‐H基准测试™中规定的标准化测试条件 可在线获取（http://www.tpc.org/tpch）。IHIS要求，在开发阶段测试期间，任何提议的电子系统都必须满足与标准TPC‐H工作负载相一致的性能指标（Fi gure 1).

图1.数据仓库eSystem配置的测试活动图。
数据存储基准测试 ,数据m ustbestoredoninde p依赖的磁盘，具有重新plication
比2更大的因子。该解决方案还必须支持有关数据安全和数据保护的最佳实践，包括热备份、冷备份和恢复。表1显示了IHIS为其初始测试数据库（1TB和3TB）设定的预定义参数，以及第一次运行（系统冷重启后）和第二次运行（数据库后）性能测试的值 重启）。在开始和测试TPC‐H基准测试之前，不允许针对特定查询对系统进行优化（如手动或其他非标准优化）。T able1.T PC‐H参数 for database（尺寸T1 B and 3 TB) and limitingva lues f or性能测试在第一次和第二次运行中的结果，由IHIS提供。

参数	限制[小时]	达到的结果[小时]
TPC‐H1TB初始导入	24	2.94*
TPC‐H3TB初始导入	96	5.99*
功率测试TPC‐H1TB—1st run	1.5	1.4**
功率测试TPC‐H1TB—2nd run	1.5	1.36**
功率测试TPC‐H3TB—1st次运行	5	4.2**
功率测试TPC‐H3TB—2nd次运行	5	4.17**

*—1TB和3TB数据初始导入结果（表2）；**—TPC‐H基准测试（表3）。
TPC‐H测试旨在模拟未来生产电子系统的行为。对于所有竞标者（招标 编号VZ0036628，编号Z2017‐035520），提供的测试数据由模拟的医疗文档组成
图1.数据仓库eSystem配置的测试活动图。

2.2.TPC-H性能要求和测试

满足TPC‐H基准测试需要测试最低要求，包括一组值和参数。TPC‐H基准测试中规定的标准化测试条件TM可在线获取（http://www.tpc.org/tpch）。IHIS要求，在开发阶段测试期间，任何提议的电子系统都必须满足与标准TPC‐H工作负载相对应的性能指标（图1）。
对于数据存储基准测试，数据必须存储在独立的磁盘上，且复制因子大于二。该解决方案还必须支持有关数据安全和数据保护的最佳实践，包括热备份、冷备份和恢复。
表1显示了IHIS为其初始测试数据库（1TB和3TB）设置的预定义参数，以及第一次运行（系统冷启动后）和第二次运行（数据库重启后）的性能测试值。在开始和执行TPC‐H基准测试之前，不允许针对特定查询对系统进行优化（如手动或其他非标准优化）。

表1。由IHIS提供的数据库TPC‐H参数（大小为1TB和3TB）以及第一次和第二次运行中性能测试的限制值。

参数	限制[小时]	取得的结果[小时]
TPC‐H1TB初始导入	24	2.94*
TPC‐H3TB初始导入	96	5.99*
TPC‐H1TB性能测试—第一次运行	1.5	1.4**
TPC‐H1TB性能测试—第二次运行	1.5	1.36**
TPC‐H3TB性能测试—第一次运行	5	4.2**
TPC‐H3TB性能测试—第2次运行	5	4.17**

注：*—1TB和3TB数据的初始导入结果（表2）；**—TPC‐H基准测试（表3）。
应用科学2020, 10, 1705 23中的 7

表2。符合TPC‐H基准测试的1TB和3TB测试数据库初始导入的测量结果。

数据大小	1TB数据		3TB数据
表名	行数	持续时间在 [s] / 小时	行数	持续时间在 [s] / 小时
客户	150,000,000	1185.00 / 0.33	450,000,000	4,100.00 / 1.14
国家	25	0.10 / 0.00	25	0.20 / 0.00
订单	1,500,000,000	2533.00 / 0.70	4,500,000,000	5423.00 / 1.51
Part	200,000,000	272.00 / 0.08	600,000,000	865.00 / 0.24
零件供应	8亿	1342.00 / 0.37	24亿	4240.00 / 1.18
区域	5	0.07 / 0.00	5	0.07 / 0.00
供应商	10,000,000	105.00 / 0.03	30,000,000	266.00 / 0.07
行项目	5,999,989,709	10,594.00 / 2.94	18,000,048,306	21,548.00 / 5.99
总加载时长	2.94* 小时		5.99** 小时

*—使用DBGEN生成并导入NoSQLVertica数据库的1TB数据集的测量结果；**—使用DBGEN生成并导入NoSQL Vertica数据库的3TB数据集的测量结果。

表3.针对1TB和3TB测试数据库大小的TPC‐H基准测试查询。

数据大小	1TB数据				3TB数据
查询编号	3个节点		5个节点		3个节点		5个节点
	第一次运行	第二次运行	第一次运行	第二次运行	第一次运行	第二次运行	第一次运行	第二次运行
Q1	267	51	232	161	427	383	441	457
Q2	23	22	19	15	52	42	36	40
Q3	64	65	55	40	128	109	121	125
Q4	470	480	287	320	918	897	914	900
Q5	177	114	71	70	484	462	465	454
Q6	0.6	0.7	0.8	0.5	1.2	1	1.4	1
Q7	119	129	65	65	144	129	140	140
Q8	37	34	40	22	375	361	270	263
Q9	2576	2551	1555	1397	16,015	15,173	3791	3824
Q10	52	130	44	72	65	58	64	64
Q11	6	7	5	3.8	13	10	10	11
Q12	13	13	8	11	24	20	23	23
Q13	221	237	180	136	296	251	325	301
Q14	49	55	41	36	111	102	105	105
Q15	7	7	4	4	9	7	9	10
Q16	42	42	29	30	87	78	86	88
Q17	11	12	8	6	23	19	23	22
Q18	376	380	517	554	741	721	743	746
Q19	58	58	41	41	112	104	111	110
Q20	129	131	87	73	156	137	150	147
Q21	2850	1763	1703	1787	7278	7021	7196	7085
Q22	67	60	62	35	107	88	110	106
∑的查询执行时间在秒	7614.6	6341.7	5053.8	4879.3	27,566.2	26,173	15,134.4	15,022
∑的查询执行时间（小时）	2.12	1.76	1.4	1.36	7.66	7.3	4.2	4.17

注（Q#—查询名称）：Q1—价格汇总报告，Q2—最低成本供应商，Q3—货运优先级，Q4—订单优先级检查，Q5—本地供应商交易量，Q6—收入变化预测，Q7—批量运输，Q8—全国市场份额，Q9—产品类型利润测算，Q10—退货物品报告，Q11—重要库存识别，Q12—运输方式与订单优先级，Q13—客户分布，Q14—促销效果，Q15—顶级供应商，Q16—零部件/供应商关系，Q17—小批量订单收入，Q18—大客户交易量，Q19—折扣收入，Q20—潜在零部件促销，Q21—导致订单滞留的供应商，Q22—全球销售机会。
TPC‐H测试旨在模拟未来生产环境中的电子系统行为。对于所有竞标方（招标编号VZ0036628，编号Z2017‐035520），提供的测试数据包括来自三家虚构保险公司的模拟医疗文档记录：三家保险公司的各自三个标准季度数据包，外加一份更正数据（模拟某保险公司提供数据不充分的情况）。数据批次以ZIP格式压缩后实时交换，包含以逗号分隔（CSV）格式存储的图像和结构化字母数字数据。
每个标准输入数据包最大为30GB，总计达3TB。测试数据包含与预期数据大致相同的数据行数，但列数较少，并增加了冗余属性。
应用科学2020, 10, 1705 23中的 8
以反映问题的维度和预期的数据量。与患者药物使用相关的数据已通过解剖治疗化学分类系统[61]。
为了进行TPC‐H基准测试，参测方的MHDA系统必须在私有网络上本地部署。该本地部署的多用户MHDA系统必须在并行化应用环境中运行。一旦元数据加载完成，系统需在无人干预的情况下运行，以防止任何配置被手动修改，从而保证TPC‐H测试的完整性。
在原型开发、测试和报告结果过程中，我们安装了CentOSLinux(7.3)。我们的解决方案（作为概念验证）满足了MHDA系统所有大规模并行处理（MPP）的要求。所提出的**大数据分析平台**及其架构还支持根据指定的服务等级协议（SLA）进行远程支持以实现故障更正数据，并满足下一个工作日（NBD）的要求。在概念验证交付后，于IHIS场所选定、安装并重新测试的操作系统为Red HatEnterpriseLinuxServer6.8版本（Santiago）。
在测试活动的第一步（图1）中，我们配置了系统架构，使用五个节点运行Vertica9.0.1‐1数据库集群。第二步，通过DBGEN程序生成1TB或3TB的数据库。此时，初始数据被加载到系统中，我们进行了1TB和3TB的性能测试与吞吐量测试。这些测试产生了各个测量结果的记录。在一个集群测试完成后，我们删除数据并生成另一个3TB数据库。我们对五个节点中的每一个都重复进行了这些性能测试，并记录了测量结果。
为了计算给定规模数据库的查询处理能力（TPC−H_Power@Size)，我们使用了公式(1)，符合最新版TPCBenchmark™H标准规范（版本2.18.0，第99页）[1]：
TPC−H_Power@Size= 3600 ∗ e{− 1 24[∑ 22 i=1 ln(QI(i,0)+∑ 2 j=1 ln(RI(j,0))]} ∗ SF (1)
其中，QI(i,0)表示在TPC‐H功率测试的单个查询流中，查询Qi的时间间隔，单位为秒；RI(j,0)表示在功率测试的单个查询流中，刷新功能RFj的时间间隔，单位为秒；SF表示数据库大小[1]对应的规模因子。
业务流程组织和数据流（图2）展示了Talend、Vertica和Tableau的集成。提供的测试数据集的处理流程从数据管理层（通过数据集成、数据质量管理以及即席分析子部分）开始，连接到数据存储与处理层。最后阶段是数据可视化层（用于预处理数据的数据可视化和分析）。

图2.业务流程组织和测试数据流。

3.结果

所提出的解决方案作为概念验证（PoC）已实施并移交至IHIS委员会，该委员会与社会和劳动安全部、国防部、内政部、医疗保险部以及欧盟统计局（欧洲联盟统计办公室）集成。IHIS要求同时符合基于欧盟的通用数据保护条例（GDPR）。

3.1.大数据分析（BDA）平台和基于Vertica的架构

在所提出的BDA平台中，我们区分了系统的以下逻辑子组件：数据集成层（DI）、数据存储（ DS）、即席分析准备（AAP）、数据质量管理（DQM）和元数据管理（MDM）。基于Vertica的整个电子系统解决方案旨在支持大规模并行处理（MPP）数据库需求的处理[58,60,62]。由于大数据处理需要高性能计算，我们采用了集群计算架构，以利用大规模并行和NoSQL数据库的优势[56,63,64]。
Vertica分析数据库实现了C‐Store项目[52],的原则，该原则被广泛用作关键业务系统的商业关系型数据库系统。Vertica数据库具备多项重要特性，可确保系统性能超越预期并满足所有IHIS要求，例如：（1）大规模并行处理（MPP）系统，（2）列式存储，（3）高级压缩，（4）扩展的云集成，（5）用于数据库设计和管理的专用工具，以及（6）针对分析型工作负载（例如每秒几次到十次）而非事务型工作负载（例如每秒数百到数千次）的内置功能。
为了满足我们客户的需求，我们还考虑了以下选择Vertica的优势： 提供SQL层，以及支持连接Hadoop和快速访问ORC、Parquet、Avro和JSON格式的列式数据；
•高数据压缩比，包括高并发度和用于处理任务的大规模并行处理（MPP）系统；
•分析型数据库对Kafka、Spark的支持； 面向IHIS要求优化的企业解决方案定价模型； 未来分析工作负载的巨大需求潜力；
•用于未来开发的云集成；以及
•能够处理并为PB级数据集提供高速结果的压缩能力。

3.2.关键组件概述

所提出的BDA平台作为一个分布式大规模系统，是基于商用具有千兆以太网互连的硬件（图3）。通过添加节点，Vertica数据库允许系统性能根据IHIS要求和普遍期望的性能提升 onsfor医疗数据的指数级增长[63]

图3.大数据分析（BDA）平台结果：展示关键组件的架构和基础设施图。
大数据分析平台统一了th三个关键组件：Talend（版本6.4）、Vertica（版本9.0.1） 以及TableauDesktop和Server（版本10.5）。作为面向大数据分析平台的专用数据集成环境， Talend提供了即席分析准备、元数据管理、数据质量管理以及数据集成功能。VerticaNoSQL数据库基于五个节点构建，提供数据存储和数据处理能力。数据可视化由TableauDesktop（专业版）实现。

3.2.1.数据集成（DI）层

数据集成（DI）层代表一个系统模块，能够实现参数化操作功能，包括转换、处理控制与层次结构、读取、写入以及并行或顺序任务/线程处理。我们使用“元数据”一词来描述所产生的统计、分类或数据聚合任务。DI为开发、测试和生产环境提供元数据。数据集成（DI）层还以数据流图的形式对其过程进行可视化。另一个DI专用工具可从预处理数据生成输出，该工具还支持快速流程开发，包括在并行多线程执行中对大量原始数据进行选择和转换。为应对即将到来的技术和操作挑战，DI模块还包含用于软件开发、测试和维护的调试工具。

3.2.2.数据存储（DS）

数据存储（DS）代表一个系统模块，该模块包含基于集群的、水平可扩展的物理架构，构建于NoSQLVertica数据库之上。数据存储（DS）运行在具备分布式存储能力的商用硬件上，从而实现对全部数据集合的大规模并行处理（MPP）。

3.2.3.数据质量管理（DQM）

数据质量管理（DQM）模块支持数据质量控制，包括趋势和数据结构。DQM为最终用户生成复杂模型，以支持数据分析中的错误检测与纠正，以及实现高质量所需的高级可视化和报告控制任务。它以结构化形式创建、排序、分组和搜索输入的验证规则。验证规则可在用户定义数据集上执行，并进行集中管理。

3.2.4.元数据管理（MDM）

元数据管理（MDM）模块支持对用户、技术和操作元数据的管理。MDM从MDHA系统的每个组件中集中处理元数据，并将其统一存储在数据仓库中。
MDM可以比较不同版本的元数据并显示输出结果，包括用于数据报告的可视化内容。MDM能够创建动态、活动的图表和表格，实现多维和交互式视图。MDM使用沙箱技术来测试临时的输入和输出，并可生成HTML、PDF和PPT格式的输出。MDM组件利用联机分析处理（OLAP）操作作用于多维数据模型。此外，它还包含术语表和概念链接，以支持影响和血缘分析。

3.2.5.即席分析准备（AAP）

对于即席分析准备（AAP）过程，我们在TalendOpenStudio集成工具中编程实现了两个不同版本。在第一个版本中，MHDA使用集成工具的提取转换加载（ETL）组件。这些组件将数据从数据仓库结构（维度和事实表）读取到内存中，然后通过过滤和聚合组件将数据处理为输出表。第二个版本使用集成工具的提取加载转换（ELT）组件。ETL和ELT组件均能够在后台生成用户友好的、未经修改的SQL数据操作语言（DML）语句。AAP模块通过避免将大量元数据加载到程序内存中，从而加快了处理时间。

图4。基于IHIS提供的测试数据的时间序列预测预测模型示例。该示例展示了数据处理和可视化层（图2）的一部分，显示为在TableauDesktop（版本10.5）中生成的截图。

3.2.6.数据可视化（DV）

数据可视化（DV）模块包含用于描述数据视角和从数据中进行知识发现的工具。DV组件以可视化方式呈现数据和元数据，并对可能的洞察提供解释。此外，我们将DV组件嵌入Tableau中，以图表和图像的形式提供数据和元数据的可视化。Tableau是一种流行的交互式分析和数据可视化工具，可以帮助将原始数据简化为易于理解的仪表板和工作表。例如，图5描绘了来自数据可视化的一部分从一的I HIS案例研究与地理地图叠加。

图5.使用TableauDesktop（版本10.5）在捷克共和国进行区域数据可视化的10秒内的实际诊断示例。除了数据集成外，地理映射功能还提供接近实时的大流行/流行病制图、追踪、疫情传播和风险数据可视化。

3.3.TPC-H测试配置

TPC‐H要求使用指定的规模因子（SF）为八个表生成数据，该因子决定了以千兆字节为单位的大致数据量（图6）。我们使用了TPC‐H功率测试，用于测量22个查询序列的吞吐量/响应时间（定义见第29页）/[1]。Vertica支持ANSISQL‐99标准，所有查询均无需语法更改即可执行。测试数据集由 TPC‐HDBGEN程序创建（图1）。在我们的测试中，发现查询Q9和Q21相比通常预期的查询更为复杂。为了功率基准测试的目的，我们共享了TPCH_SF1000，包含行大小x1000（数十亿元素）。

图6.由八个表组成的TPC‐H的组件（改编自第13页）。[1]。
使用TPC‐H预定义数据集（图1）所实现的性能表明，所开发的电子系统（作为概念验证）在具有类似产品特性的竞争者中表现更优[66–68]。政府还对所提出的3）、报告的性能（表2和3、图7和8）进行了测试。所开发的电子系统以本地集中模式部署在捷克共和国境内，其数据通信通道在物理上与现有的互联网基础设施相分离。

表2.符合TPC‐H基准测试的1TB和3TB测试数据库初始导入的测量结果。

数据大小	1TB数据		3TB数据
表名	行数	持续时间在 [s] / 小时	行数	持续时间在 [s] / 小时
客户	150,000,000	1185.00 / 0.33	450,000,000	4,100.00 / 1.14
国家	25	0.10 / 0.00	25	0.20 / 0.00
订单	1,500,000,000	2533.00 / 0.70	45亿	5423.00 / 1.51
Part	2亿	272.00 / 0.08	6亿	865.00 / 0.24
零件供应	8亿	1342.00 / 0.37	24亿	4240.00 / 1.18
区域	5	0.07 / 0.00	5	0.07 / 0.00
供应商	10,000,000	105.00 / 0.03	30,000,000	266.00 / 0.07
行项目	59.99989709亿	10,594.00 / 2.94	180.00048306亿	21,548.00 / 5.99
总负载持续时间	2.94* [小时] (16,031.17 [秒])		5.99**[小时] (36,442.27 [秒])

*—使用DBGEN生成的1TB数据集并导入NoSQLVertica数据库测得的结果；**— 使用DBGEN生成的3TB数据集并导入NoSQLVertica数据库的测量结果。

图7.在1TB测试数据库上的TPC‐H查询持续时间（从Q1到Q22）。

图8.3TB测试数据库上的TPC‐H查询持续时间（查询Q1到Q22）。

在Vertica集群上运行的TPC‐H测试针对1TB和3TB数据库规模（表3）的性能如图7和8所示，显示出复杂查询和常见预期查询具有相似的持续时间模式。
根据客户的要求，我们的报告中还需包含在相同硬件配置下的两次测试运行。第一组TPC‐H查询执行时间是在冷系统重启后完成的。第二组测试运行则仅在数据库重启后，用以表明性能提升的情况。
监控I/O请求以准确捕捉工作负载行为对于存储子系统的设计、实现和优化至关重要。我们进行分析所用的TPC‐H跟踪数据集是在运行于CentOSLinux7.3（安装在ext4文件系统上）的Vertica 9.0.1数据库集群上收集的，该集群包含五个节点， 2 × 10核CPUIntel® XeonE5‐2660v3@2.66 GHz， 16 × 8GB= 128 GB内存， 6×块900GBHDD（15Krpm）， 2 × 1 Gb以太网， 2 × 10 Gb以太网， 2 × 16 Gb光纤通道适配器。由于客户设定的性能价格比限制，我们无法推荐更快的磁盘I/O技术。
如前所述，TPC‐H还可作为衡量NoSQLVertica数据库系统处理查询能力多个方面的指标。不同数据库规模和系统扩展的性能提升方面在表4以及图9–11中综合体现。因此，可以根据在1TB和3 TB数据库上测试的三到五个节点的测量性能提升结果，推断未来系统升级的预期需求和性能表现。

表4。在1TB和3TB测试数据库上，三节点和五节点配置下第一次和第二次运行的TPC‐H查询摘要。

	3个节点		5个节点
	第一次运行	第二次运行	第一次运行	第二次运行
1TB的结果为[秒]	7614.6	6341.7	5053.8	4879.3
3TB的结果为[秒]	33,099.26	27,566.2	15,134.4	15,022.0

图9.TPC‐H查询执行时间的性能提升可视化。在Vertica集群中，针对1TB和3TB测试数据库规模，三个和五个节点上第一次和第二次运行的比较。

图10.在Vertica集群中，针对1TB测试数据库的三到五个节点上，22个TPC‐H测试查询执行时间的总和。仅通过数据库重启以及通过增加额外节点进行横向扩展后，第二次运行时性能提升明显。

图11.在Vertica集群中，针对1TB数据库规模，三到五个节点的性能提升比较。

在比较性能提升和可扩展性视角时，结果表明，在1TB数据库规模上使用低成本商用硬件，从3个节点扩展到5个节点可实现至少25%的性能提升（图11）。通过增加额外计算资源所获得的查询执行时间和性能提升，为横向扩展设计提供了充分证据，证明其未来能够有效处理更大数据集。

4.讨论

旨在推进医疗电子系统的大数据技术应用，可从实现的性能、隐私、安全、互操作性、合规性、成本以及前瞻性设计（如对增量式硬件集成、分析工具和数据增长的可扩展性）等方面进行评估。在捷克共和国国家招标（编号VZ0036628，编号Z2017‐035520）中，厂商独立解决方案必须满足大量要求，涵盖上述所有标准，旨在在欧盟框架内实现国家医疗保健系统的现代化。由于与IHIS存在合同义务，作为参与方，我们无法获取或传播竞争对手信息，包括其系统性能基准或其他提议的大数据分析平台架构。然而，我们的合同允许在移交IHIS之前公开概念验证的结果及作者身份。捷克共和国采纳的该大数据分析解决方案已满足所有要求，并展示了远超要求阈值的系统性能结果。
可转移至其他医疗系统的概念和见解基于本案例研究以及专家观点、已发表文献和公共领域现有知识的共识。作者对未来医疗电子系统中大数据的应用观点和愿景是基于专业经验、基于Vertica的电子系统开发成果以及大数据概念。因此，我们希望强调未来数据扩展和性能提升的可扩展性、对近期机器学习算法和分析工具的支持、安全性和战略医疗规划的重要性。鉴于此，超越本项目的主要范围，我们提出疑问：这对医疗及其他大数据行业的专业人士意味着什么？首先，VerticaBDA平台可在亚马逊、Azure、谷歌和VMware云平台上运行，提供用户敏捷性和可扩展性，能够快速部署、定制和集成各种软件工具。Vertica支持数据仓库向云环境和本地部署迁移，具有灵活性，可从小规模起步，并随客户业务需求增长而扩展。在本案例中，我们的客户（IHIS）根据本地部署原则设定了所提议解决方案的实施条件，要求该解决方案必须物理隔离于互联网之外，因此无法提出基于云的解决方案。
然而，Vertica提供端到端安全，并支持行业标准协议，所以我们认为未来的基础设施将演变为多云和混合解决方案，即本地部署与云环境的结合。此类数据分析和管理方法不应局限于单一类型的环境。例如，Vertica宣布了针对本地工作负载分配，推出业界首个采用计算与存储架构分离的分析型数据库解决方案 EonModeforPureStorage（https://www.vertica.com/purestorage/）。
其他可用的大数据可扩展技术与框架[69–73]包括Hadoop，一种开源生态系统（具有专有文件系统HDFS）；以及基于Java的MapReduce框架，用于存储和批处理大量数据。ApacheSpark也旨在很好地融入大数据生态系统。例如，ApacheSpark以将大量数据（RDD—弹性分布式数据）保留在内存中而闻名，并提供比Hadoop高出几十到一百倍的计算性能。然而，ApacheSpark的内存计算引擎在其框架内不具备如Hadoop在HDFS或NoSQL数据库中的键值存储功能。
ApacheSpark和NoSQL数据库通常集成在一个生态系统中，部署在Hadoop安装之上。在考虑 ApacheSpark与Hadoop生态系统时，数据移动会带来开销和延迟。此外，此类生态系统需要额外的管理开销，特别是在存在独立集群和数据冗余的情况下。
作为所提出解决方案的一部分，使用了开源产品TalendOpenStudio（版本6.4），旨在实现数据集成，以批处理或实时处理模式将数据抽取‐转换‐加载（ETL）到各种数据源（包括文件系统、Hadoop、非仅SQL、关系数据库管理系统）。
VerticaBDA平台推荐的操作系统是LinuxCentOS7.3。Vertica还支持其他基于Linux的操作系统，例如（按作者偏好顺序）：RedHat企业Linux（RHEL）7.3、Oracle企业Linux（OEL） 7.3、SUSE12SP2、Debian8.5和Ubuntu14.04LTS。对于我们部署在IHIS场所的电子系统，我们额外安装了开源软件NagiosCore（版本4.1），用于网络基础设施和集群监控。
关于我们在2021年对大数据分析解决方案的计划，我们正在考虑通过医疗物联网设备和移动应用（包括智能手表传感器等可穿戴设备）的流数据处理，进一步提升国家医疗保健和隐私保护水平。目前，我们正在一个扩展了其他平台组件的开发环境中进行测试（使用EclipseMosquitto开源代理，通过MQTT协议实现物联网设备的流数据传输）。来自物联网设备的采集的测试数据通过MQTT Mosquitto代理（https://mosquitto.org）以流数据形式传输，利用ApacheSpark（ https://spark.apache.org）进行转换，并存储在Hadoop中用于未来数据操作用途。从该层开始，数据将在VerticaNoSQL集群中进行进一步处理。为了实现物联网平台管理，我们使用Node.js（ https://nodejs.org/）构建快速且可扩展的网络应用，并使用Angular平台（https://angular.io）构建移动和桌面应用。

5.结论

由近期物联网和移动设备产生的医疗记录和数据量不断增长，促使医疗保健及相关领域必须采用大数据分析（BDA）。作为捷克共和国医疗保健领域BDA应用国家战略的一部分，捷克共和国卫生研究所（IHIS）已将其战略与欧盟保持一致。在符合法定法规的国家公共招标中，包含了100多项复杂需求，其中报告了一组关于性能、成本效益、稳健性和容错性的标准。该大数据分析解决方案需运行于基于Linux的开源软件（如TalendOpenStudio、Python、R、Java、Scala环境）之上，并能够在整体系统性能评估方面达到具有竞争力且高于预期阈值的结果。
此处报道的中标BDA解决方案代表了一个时间节点，其在针对医疗保健的TPC‐H基准测试中的表现超过了预期运行效果。该BDA解决方案及其控制权已移交至IHIS，过去七个月中，IHIS已将孤立的医疗系统整合为一个电子系统。除了已展示的测试和实际性能外，当前的电子系统在改善捷克共和国国家医疗保健方面具有巨大潜力，并能够容纳不断发展的期望和未来的数据需求。基于Vertica分析型数据库管理软件构建的电子系统在流式与高容量处理、可扩展性（基于消费级/通用硬件）以及容错性（例如，关闭集群节点不会导致数据丢失）方面具备面向未来的特性。使用通用硬件进行的横向可扩展性测试表明，将集群节点数量从三个增加到五个后，性能提升了超过25%，为基于高性价比通用硬件的横向扩展设计提供了充分证据。
目前，所开发的大数据分析医疗电子系统通过在国家地理边界内以本地部署模式安装，从而在物理上与互联网基础设施隔离，因此被认为具有高度安全性，并符合数据安全和协议方面的行业标准。
该大数据分析医疗电子系统支持多种开源软件，包括各种Linux发行版，并不断集成越来越多的机器学习库以及Tableau等商业工具。鉴于近期冠状病毒爆发，该电子系统可在10秒内更新并提供捷克共和国区域数据的地理映射可视化，并能与其他医疗电子系统进行数据交换。除了数据集成外，地理映射功能还支持近实时的疫情/流行病追踪、疫情传播监测和风险数据可视化。
未来对该医疗大数据分析平台的进一步开发步骤包括：（1）扩展支持医疗物联网和移动应用数据流的大数据分析平台，以确保现有解决方案保持为“蓝图”架构；（2）在高流量事件期间支持数据驱动决策；（3）持续进行横向扩展，并将处理能力从100TB提升至1PB（拍字节）；（4）采用新方法实现最小延迟的数据清洗、存储和检索；（5）与其他国家登记系统集成（例如，用于管理和优化药品分发物流）；以及（6）利用医疗数据进行战略规划。
作者贡献： M.Š.是首席研究员。他提出了研究思路并制定了方案设计，进行了测试实验并撰写了初稿；B.B.在进一步撰写、重组和增量编辑稿件的基础上完成了本文档，并构思了研究；L.S.对稿件进行了最终批准。所有作者均已阅读并同意稿件的已发表版本。
资金支持： 本研究未获得外部资金。
利益冲突： 作者声明不存在利益冲突。