基于 易观CTO 郭炜 文章 Lambda架构已死，去ETL化的IOTA才是未来 和 易观方舟IOTA架构实践整理而成
在过去，Lambda数据架构成为每一个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构如下：
数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。
每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验
单纯的N小时缓存失效的机制，会导致数据刷新不及时，造成数据理解上的偏差：
现象：在相同指标在不同图表数据不一致，尤其是在同一个DashBoard内时，让人难以理解；
原因：图表在不同时间创建和缓存的，在时间差内，相关的数据发生了变更
特性：
项目地址：
Clickhouse表引擎决定了：
当读取数据时, 引擎只需要抽取必要的列簇. 然而，在一些场景下,引擎可以半处理数据
对于大多数场合下，应该使用 MergeTree家族 引擎
以下包括官方介绍的17种表引擎的介绍：
clickhouse支持从各种数据源添加自己的字典。字典的数据源可以是本地文本、可执行文件
、HTTP（s）资源或其他DBMS。有关更多信息，请参阅“外部词典的来源”。
外部词典的配置位于一个或多个文件中。 配置的路径在dictionaries_config参数中指定。
字典配置：
1 | <dictionaries_config>*_dictionary.xml</dictionaries_config> |
当前配置文件目录下，以_dictionary.xml结尾的均作为字典配置文件进行字典加载。
字典可以在服务器启动时或首次使用时加载，具体取决于dictionaries_lazy_load设置。
Clickhouse允许从不同的源构造外部字典，配置文件通常像这样：
1 | <yandex> |
数据源则是通过source项进行配置
其中支持的数据源的类型有(source_type):
Clickhouse支持多种方式将字典存储在内存中
一般推荐flat、hashed和 complex_key_hashed，这些提供了最佳的处理速度，但是不推荐使用cache，因为可能会出现性能差且难以选择最佳参数的问题。
有以下几种方式提升字典的使用性能：
字典键值配置说明
字典键、值的配置是在配置文件中的structure节点
整体的配置结构
1 | <dictionary> |
Columns are described in the structure:
<id> - key column.<attribute> - data column. 这里可以配置很多数据列Update your browser to view this website correctly. Update my browser now
